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.
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.
Action map:
- 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
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:
Cross-connector reconciliation:
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.