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 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, 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% |
- 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. - 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). - 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.
- 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. - 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. - 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.
- 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 | The aggregate; this card is the breakdown. |
aut_success_rate | Complement view. |
aut_threedsecure_abandon_rate | 3DS abandon (different from 3DS-failed). |
aut_top_payment_methods | Network-specific decline patterns (Amex declines differ from Visa). |
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 → 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. |
| 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 doesDO_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- 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.