At a glance
The percentage of attempted Authorize.Net transactions that failed (issuer-declined, voided pre-settlement, or FDS-rejected). High decline rates suppress revenue directly.
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.”, week 26 Apr 26 to 02 May 26.
What the merchant should notice:
- Blended at 8.1% triggers alert. Threshold is 8%; this is at the threshold edge. Open
aut_top_decline_reasonsimmediately. - Web channel at 10.4% is the cause. B2B at 3.4% is healthy; the drag is web. Likely candidates: a fraud-cluster spike (one BIN flagged as risky), a recent FDS rule tightening, or a marketing campaign attracting low-quality traffic.
- A wave of
DO_NOT_HONOR(reason code 2) from one BIN is the most common pattern. Issuer fraud-flag triggered by a velocity pattern. Whitelist the merchant in the issuer risk system, or work with the acquirer to push BIN-level Visa Stand-In Processing. - ARB at 6.7% hides expired-card and insufficient-funds. Enable Account Updater. The 3 declines on 45 attempts is normal but trending upward indicates aging stored cards.
- A single bad day with 30% web decline rate would push the 7-day average to 13%. That triggers
+25% relative spikealert. Operational pattern: gateway rotation incident or commerce-platform deploy break checkout for 60 to 90 minutes.
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 → Statistics by Submission Date, filter “Status: Declined” + “Status: Held” + “Status: Voided” plus the same Settled denominator. Or Risk Management → Fraud Detection Suite → Statistics for the FDS-side view. Why our number may differ:
Cross-connector reconciliation:
Known limitations / merchant FAQs
Decline rate spiked overnight, what to check first? Openaut_top_decline_reasons. Spike patterns: (1) a single reason code dominates (issuer-side fraud-filter wave on one BIN), (2) reason spread evenly across codes (ad campaign attracted high-risk traffic), (3) FDS-side spike (Authorize.Net’s Fraud Detection Suite tightened, visible in Risk Management dashboard).
Why is DO_NOT_HONOR (reason code 2) so common?
It’s the issuer’s generic “we declined and won’t tell you why” code, often issued for borderline-fraud signals. Some issuers use it for INSUFFICIENT_FUNDS to hide the true reason. A cluster from one BIN suggests fraud-flag at the issuer.
Are 3DS abandons declines?
No. A 3DS abandonment is the customer abandoning at the bank’s challenge prompt; tracked in aut_threedsecure_abandon_rate. Different fix (UX work) than issuer-decline (BIN routing).
Recurring rebill failures, do they count?
Yes. ARB rebill failure is transactionStatus = declined, counted here. Account Updater plus a smart retry strategy (3 attempts over 7 days, varying time of day) recovers 30 to 50% of initial declines.
eCheck.Net (ACH) decline rate, how counted?
ACH “decline” is delayed; the eCheck is initially settledSuccessfully then bank-returned (NACHA codes R01 = insufficient funds, R02 = account closed, R10 = unauthorised) within 2 to 60 days. The return is captured as a separate transaction reversing the original. ACH return rate (typically 0.5 to 1.5%) is tracked separately when the engine processes the return event.
FDS hold vs decline, what’s the difference?
Hold = “we don’t know yet, merchant please review”. Decline = “we definitely declined”. Held transactions are counted neither as success nor decline until released (success) or declined (failure) by merchant or by FDS auto-rule.
Visa ownership of Authorize.Net, decline-rate impact?
None observable. The gateway operates at parity with Stripe/Braintree on the Visa-card path. The Visa ownership does not give Authorize.Net merchants special “Visa-friendly” routing.