At a glance
The percentage of attempted Authorize.Net transactions that settled successfully. The complement of the decline-and-abandon view. The single best gauge of authentication quality, BIN routing, and FDS-rule sanity.
| What it counts | COUNT(StatusId = settledSuccessfully) / COUNT(all attempts) * 100. Numerator is settled; denominator is settled + declined + voided + FDS-held-then-declined. FDS-held-then-released-and-settled count as success. |
| API endpoint | getTransactionListRequest without a status filter. |
| Currency | Currency-neutral (rate). |
| 3DS treatment | 3DS-frictionless and 3DS-passed both count as success. 3DS-failed counts as failure. |
| Refunds | Not relevant (post-success). |
| Disputes | Not relevant (post-success). |
| Voided pre-settlement | Counts as failure (the merchant cancelled the capture). |
| eCheck.Net (ACH) | Counted; ACH success-rate higher than card (no real-time issuer decision). |
| Healthy baseline | 92 to 96% for US card-not-present mid-market merchants. Above 97% suggests very clean traffic; below 90% suggests issuer routing or BIN problems. |
| B2B vs B2C | B2B reorders run higher success (95-98%, repeat customers with stored CIM tokens); B2C web checkout lower (88-94%). |
| Time window | 7D vsP. |
| Alert trigger | <90% absolute, OR -3pp drop vsP. |
| Sentiment key | gauge: good>=95, warn<90 |
| Roles | owner, finance, 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 window 26 Apr 26 to 02 May 26.| Channel | Settled | Declined | Voided | FDS-held-declined | Success rate |
|---|---|---|---|---|---|
| Web (Accept.js) | 423 | 38 | 8 | 3 | 423 / 472 = 89.6% |
| B2B portal (CIM tokens) | 142 | 4 | 1 | 0 | 142 / 147 = 96.6% |
| ARB recurring | 42 | 3 | 0 | 0 | 42 / 45 = 93.3% |
| MOTO phone | 73 | 2 | 1 | 0 | 73 / 76 = 96.1% |
| Blended | 680 | 47 | 10 | 3 | 680 / 740 = 91.9% |
- Blended at 91.9% is borderline. The threshold is 90% absolute; one bad day pushes the rolling 7-day under. Time to investigate.
- Web channel at 89.6% is the drag. B2B (CIM tokens) is at 96.6% because cards are pre-validated and stored. Web checkout sees fresh cards including high-decline mobile-only debit. The biggest leverage is in web traffic quality.
- Voided 8 on web vs 1 on B2B. Voids are merchant-initiated; the merchant is voiding 8 web orders, likely because fraud-review flagged them post-capture. That suggests FDS rules are letting through high-risk transactions. Tighten FDS or add velocity rules.
- ARB at 93.3% is OK but not great. Card expiry and insufficient-funds are the main causes. Enable Account Updater (Visa Account Updater / Mastercard Automatic Billing Updater) on the merchant account for a 1 to 3pp lift.
- MOTO at 96.1% is healthy. Sales reps screen customers and the keyed-in card is usually a known business. Anything below 94% on MOTO suggests rep training issue.
Sibling cards merchants should reference together
| Card | Why pair it with Success Rate |
|---|---|
aut_decline_rate | The complement; success + decline + abandon = 100%. |
aut_top_decline_reasons | Reason-code breakdown; first card to open when success drops. |
aut_threedsecure_abandon_rate | The 3DS-side of failure (different fix from issuer-decline). |
aut_top_payment_methods | Network mix changes affect success rate (Amex declines slightly more). |
Stripe stripe_success_rate / PayPal pp_success_rate | Cross-PSP comparison. |
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 with all statuses included; success rate is calculated from “Settled” / total. Risk Management → Fraud Detection Suite shows the FDS-side breakdown. Why our number may differ:| Reason | Direction | Why |
|---|---|---|
| Voided treatment | Either | Some Dashboard views exclude voids; this card includes them as failures. |
| FDS-held boundary | Either | A held transaction released later flips state; snapshot vs retroactive. |
| Time zone | Boundary days off | Pacific batch cut-off vs UTC. |
| Comparison | Expected | Why |
|---|---|---|
aut_success_rate ↔ stripe.stripe_success_rate | Differ by 1 to 3pp | Different acquirer routing per BIN; Stripe’s network can route Visa via Visa, Authorize.Net (also Visa-owned) has near-identical routing for Visa. |
aut_success_rate ↔ paypal.pp_success_rate | PayPal usually higher | PayPal balance / Pay Later traffic does not require issuer decision, so success rate is structurally higher. |
Known limitations / merchant FAQs
What’s a healthy success rate? Mid-market US card-not-present runs 92 to 96%. B2B reorder portals (CIM-stored cards, repeat customers) run 96 to 99%. Pure new-customer web checkout runs 88 to 93%. ACH (eCheck.Net) runs 95 to 99% (no real-time decision; failure is bank-return after submit). Success dropped 4pp overnight, what to check? (1) Openaut_top_decline_reasons, see if a single reason dominates. A wave of DO_NOT_HONOR from one BIN is issuer fraud-flag; talk to the issuer or whitelist the merchant in the issuer’s risk system. (2) Check FDS recent rule changes; a tighter velocity rule will increase FDS-declined count. (3) Recent gateway certificate or API-key rotation; misconfiguration can cause 100% failure on one channel.
FDS-held transactions, do they help or hurt success rate?
Both. A held transaction that is later released and settles improves success rate; one that is declined hurts it. The key metric is FDS hold-rate (typically 0.5 to 2%); above 5% means rules are too tight.
Account Updater, does it help recurring success?
Yes. Visa Account Updater and Mastercard ABU automatically refresh stored card numbers when the issuer reissues (expiry, lost, stolen). Authorize.Net offers Account Updater on most acquirer accounts; enabling it typically lifts ARB rebill success by 1 to 3pp. Check with the acquirer (Elavon / Vantiv / Fiserv).
Visa-owned, does that help Visa-card success rate?
Marginally. Authorize.Net’s authorisation hop for Visa cards lands on Visa’s own network without an extra acquirer-to-network hop. The latency benefit is single-digit milliseconds; the success-rate benefit is observable only at the third decimal place. Don’t expect a meaningful boost.
Why does my web success rate keep dropping while B2B stays stable?
Web traffic quality drift. Marketing campaigns attract new (less validated) cardholders; B2B uses tokenised stored cards (already validated). Pin a baseline web success rate and alert on drops; do not blend channels for the alert.
Recurring rebill failures, retry strategy?
Authorize.Net ARB has built-in retry (configurable, typically 3 retries over 7 days). Beyond ARB, merchants typically run a separate dunning system (in commerce platform or third-party like Stunning / Recharge) for additional retries with smarter timing.