> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Top Decline Reasons, Authorize.net > Top Decline Reasons for Authorize.net stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Metrics type:** [Supporting Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Payment Gateway](/nerve-centre/connectors#connectors-by-type) ## At a glance > The top issuer-decline reason codes seen in the period, ranked by count. The diagnostic card to open when [`aut_decline_rate`](/nerve-centre/kpi-cards/authorize-net/decline-rate) jumps. Tells the merchant *why* cards declined, not just how many. | | | | ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | `GROUP BY responseReasonCode + responseReasonDescription` for `transactionStatus = declined`, ordered by count desc, top 10. | | **API endpoint** | [`getTransactionListRequest`](https://developer.authorize.net/api/reference/index.html#transaction-reporting), filtered to declined. | | **Reason-code source** | Issuer-returned reason codes mapped through Authorize.Net's response code dictionary (`responseCode` 2 = declined, with `responseReasonCode` 2 to 350+). Common: 2 (declined), 3 (referral), 4 (pickup), 11 (duplicate), 27 (AVS mismatch), 65 (exceeds withdrawal limit), 200 (3DS failed), 250 (3DS not enrolled). | | **Currency** | Currency-neutral. | | **3DS-failed** | Counts under reason 200 / 258. | | **AVS / CVV failures** | Counts under reason 27 / 44 / 45. | | **Voided pre-settlement** | Excluded (not a decline). | | **eCheck.Net (ACH) returns** | NACHA return codes (R01, R02, etc.) counted with the prefix `ACH-` in the reason field. | | **FDS-rejected** | Counted with reason `FDS_HELD_DECLINED`. | | **Time window** | `7D`. | | **Roles** | owner, operations | ## Calculation Calculated automatically from your Authorize.net data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading. ## Worked example "Heartland Hardware Co.", 7-day decline breakdown. | Rank | Reason code | Description | Count | Share | | ---- | ------------------- | --------------------------------------- | ----- | ----- | | 1 | 2 | DO\_NOT\_HONOR (issuer generic decline) | 18 | 30.0% | | 2 | 65 | EXCEEDS\_WITHDRAWAL\_LIMIT | 9 | 15.0% | | 3 | 27 | AVS mismatch | 7 | 11.7% | | 4 | 11 | DUPLICATE\_TRANSACTION | 6 | 10.0% | | 5 | 4 | PICK\_UP\_CARD | 5 | 8.3% | | 6 | 200 | 3DS\_FAILED | 5 | 8.3% | | 7 | 44 | CVV\_NO\_MATCH | 4 | 6.7% | | 8 | FDS\_HELD\_DECLINED | Authorize.Net FDS rule | 3 | 5.0% | | 9 | 250 | 3DS\_NOT\_ENROLLED | 2 | 3.3% | | 10 | ACH-R01 | Insufficient funds (eCheck) | 1 | 1.7% | Action map: 1. **Reason 2 (`DO_NOT_HONOR`) at 30% is normal.** It's the issuer's generic-reject. Above 50% suggests a fraud-flag wave on a specific BIN; check the BIN distribution within reason-2 declines. 2. **Reason 65 (`EXCEEDS_WITHDRAWAL_LIMIT`) at 15% suggests B2B traffic hitting card daily limits.** Common on B2B portals; coach customers to use ACH (eCheck.Net) for large orders, or implement card-on-file with multi-tender (split across two cards). 3. **Reason 27 (AVS mismatch) at 11.7% is high.** AVS-strict rules are rejecting addresses with PO boxes or apartment-number quirks. Loosen AVS rules in FDS, or fall back to "Address mismatch" warning instead of decline. 4. **Reason 11 (`DUPLICATE_TRANSACTION`) at 10% is deduplication.** A customer hit "submit" twice; the second is rejected. UX fix: double-submit prevention on checkout button. 5. **Reason 4 (`PICK_UP_CARD`) at 8.3% is real fraud.** The issuer is telling the merchant to retain the card. Don't retry; flag for fraud review and block the customer. 6. **Reason 200 (3DS\_FAILED) at 8.3%.** The 3DS challenge rejected the customer. Different from abandoned (where they bailed out). Issuer-side decision; rare patterns suggest BIN-specific 3DS issues. 7. **FDS\_HELD\_DECLINED at 5%.** Authorize.Net's FDS rules caught these. Review the FDS Statistics view for which rule fired; tune accordingly. ## Sibling cards merchants should reference together | Card | Why pair it with Top Decline Reasons | | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | [`aut_decline_rate`](/nerve-centre/kpi-cards/authorize-net/decline-rate) | The aggregate; this card is the breakdown. | | [`aut_success_rate`](/nerve-centre/kpi-cards/authorize-net/success-rate) | Complement view. | | [`aut_threedsecure_abandon_rate`](/nerve-centre/kpi-cards/authorize-net/3ds-abandonment-rate) | 3DS abandon (different from 3DS-failed). | | [`aut_top_payment_methods`](/nerve-centre/kpi-cards/authorize-net/top-payment-methods) | Network-specific decline patterns (Amex declines differ from Visa). | | Stripe [`stripe_top_decline_reasons`](/nerve-centre/stripe/stripe_top_decline_reasons) | Same archetype on Stripe rails. | ## Reconciling against the vendor's own dashboard **Where to look in the Authorize.Net Dashboard:** [account.authorize.net](https://account.authorize.net) → **Reports → Transaction Statistics**, filter "Status: Declined" then group by reason code in CSV export. The Dashboard shows reason-code totals at month boundaries; daily breakdowns require export. **Risk Management → Fraud Detection Suite → Statistics** shows FDS-rule-fired counts. **Why our number may differ:** | Reason | Direction | Why | | ------------------------ | ---------------- | --------------------------------------------------------------------------------------------------------------- | | **Reason mapping** | Either | We map a few codes via friendlier labels (e.g. "DO\_NOT\_HONOR" instead of raw "2"); Dashboard shows raw codes. | | **FDS vs issuer** | Different rows | Dashboard separates FDS holds in a different view; we merge them with prefix `FDS_*`. | | **eCheck NACHA returns** | Possibly missing | Some NACHA return events arrive on a delayed feed; if not processed yet, they don't show. | **Cross-connector reconciliation:** | Comparison | Expected | Why | | --------------------------------------------- | ------------------------- | --------------------------------------------------------------------------------------------------- | | `aut_top_decline_reasons` ↔ Stripe equivalent | Different code namespaces | Stripe uses its own `decline_code` strings; not directly mappable to Authorize.Net's numeric codes. | ## Known limitations / merchant FAQs **What does `DO_NOT_HONOR` (code 2) actually mean?** The issuer's generic-reject. The bank's risk system flagged this transaction but doesn't want to disclose why. Common patterns: card-not-present velocity hit, BIN-level fraud-flag wave, unusual merchant category for the cardholder. Don't retry the same card immediately; advise customer to call their bank or use an alternative card. **Why is AVS-mismatch (code 27) so frequent?** Customers mis-type addresses (PO box vs street, apartment number formats, "Saint" vs "St"). AVS verifies the numeric portion of street address and ZIP only, so partial matches still fail. Strict-AVS configurations decline anything less than full match; loosen to "decline only on full mismatch" to recover legitimate orders. **`PICK_UP_CARD` (code 4), should I retain the card?** Legally and operationally, no. The cardholder is not present (card-not-present transaction). Just decline; the issuer is signalling fraud. Block the customer email and any associated tokens. **`DUPLICATE_TRANSACTION` (code 11) keeps appearing, why?** Authorize.Net dedupes by `invoiceNumber` + amount + card + 2-minute window. A double-click on the checkout button hits the dedupe. UX fix: disable the submit button on click; show a spinner. Backend fix: tag invoices with a UUID per cart, not per session. **3DS-failed (200) vs 3DS-not-enrolled (250), what's the difference?** * 200: customer attempted 3DS, the issuer rejected (wrong OTP, biometric failure, or risk decision). * 250: card not enrolled in 3DS. Behaviour depends on merchant configuration; if 3DS is required, the transaction is declined; if optional, falls back to non-3DS. **ACH return codes, when do they appear?** NACHA returns arrive 2 to 60 days after the original submission. The most common: R01 (insufficient funds), R02 (account closed), R10 (unauthorised, customer dispute). The eCheck originally settled successfully, then is reversed. The reversal is what populates this card with `ACH-` prefix. **FDS\_HELD\_DECLINED, how to reduce?** Open Authorize.Net's **Risk Management → Fraud Detection Suite → Statistics** and see which FDS rule fired. Common offenders: AVS / CVV strict rules, IP-velocity rules, BIN blocks. Tune per rule; over-tightening FDS reduces fraud but suppresses revenue. **Visa ownership of Authorize.Net, do Visa-issuer declines look different?** No. Visa issuers see Authorize.Net traffic exactly the same as Stripe or Braintree traffic; the response codes and decision logic are identical. Visa's parent ownership of Authorize.Net is corporate, not technical-routing. *** ### Tracked live in Vortex IQ Nerve Centre *Top Decline Reasons* is one of hundreds of KPI pulses Vortex IQ tracks across Authorize.net and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.