At a glance
The percentage of charge attempts on/v1/chargesthat ended instatus = succeeded. The single best “is my checkout working?” signal Stripe exposes, and the 35% weight inside Payment Health Score.
Calculation
Calculated automatically from your Stripe data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A US subscription brand processing through Stripe. The 7-day window covers 06 Apr 26 to 12 Apr 26 and the engine fetched 980 charges (under the 1,000 cap):- Healthy band, just above the floor. 93.5% is right inside the “92, 96%” healthy band Stripe publishes. Below 92% would trip the card alert; below 88% usually means something is actively broken (Radar mis-tuned, traffic source compromised, gateway misconfiguration).
- Radar blocks count against auth rate. ch_a06 was blocked by a Stripe Radar rule, not by the issuer, but it still ends with
status = failedand pulls the rate down. If a merchant complains “my real auth rate is fine, it’s Radar dragging the number”, the Decline Reasons breakdown shows the split. - SCA abandons (
requires_action) hurt the rate without anyone noticing. ch_a07 is invisible in Stripe Dashboard’s “Failed payments” tab (those filter onstatus = failed), but it sits in our denominator. UK and EU stores see this as the largest gap between Stripe Dashboard’s auth view and ours.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in Stripe Dashboard: The closest Stripe-native view is Stripe Dashboard → Payments → Overview at dashboard.stripe.com/payments. The “Successful payments” tile divided by the “All payments” tile (top filter set to the same window) gives the merchant’s own version of this card. A handful of nearby views can look like this card but aren’t:- Payments → Authorisations. This view includes uncaptured holds and excludes Radar-blocked charges. Higher than our auth rate by 1, 3 points typically.
- Payments → Failed payments tab. This is the complement of auth rate but only counts
status = failed. SCA-abandoned (requires_action) and uncaptured (pending) charges are missing, so 100 − this figure is NOT our auth rate. - Reports → Authorization rate report. This is Stripe’s own analytics layer and the single closest match to this card. Set the same date range and the figures should agree within ~1%.
- Realtime feed. The streaming feed shows live successes and failures but isn’t aggregated; useful during an incident, not for reconciliation.
Cross-connector reconciliation:
End-to-end: a merchant tracking checkout health should pair this card with one upstream conversion card and one parallel-processor card. Sustained drops in only Stripe auth rate point to issuer or Radar issues; drops on both Stripe and PayPal point to traffic-source or fraud-wave issues.
Known limitations / merchant FAQs
Reconciliation questions (“why doesn’t this match Stripe Dashboard?”) are answered in the Reconciling against the vendor’s own dashboard section above. Below are the questions that aren’t reconciliation.“What’s a healthy auth rate?” The Stripe-published healthy band is 92, 96%. Above 96% usually means a low-risk customer base (subscription renewals, returning customers, no high-ticket items). Below 90% is unusual outside of subscription dunning cycles or stores serving high-fraud verticals (digital goods, gift cards). Below 88% almost always means something is broken: a Radar rule firing on legitimate traffic, an SCA / 3DS misconfiguration, or a compromised traffic source. The card alert fires at < 92% so the merchant gets a nudge before it becomes a real problem. “Why are 3DS-failed charges counted in the denominator?” Because they were a charge attempt. Stripe routed the customer through 3DS, the customer either failed authentication or abandoned, and the charge ended
failed or requires_action. Either way the auth was attempted. If you want to isolate the 3DS-only effect, compare against the 3DS Success Rate card; the gap is your SCA cost.
“Are SCA-required charges that the customer abandoned counted?”
Yes, in the denominator only. They sit at status = canceled or status = requires_action and never reach succeeded, so they pull the rate down. UK and EU stores feel this most after the SCA mandate landed. Pair with the 3DS Abandon Rate card to see the size of the cost.
“What about delayed-capture authorisations that are still open?”
Excluded from the numerator until they’re captured. They sit at status = pending. Once you capture, the next refresh moves them into the numerator and the rate ticks up.
“My multi-currency store, does the rate work for me?”
Yes. Auth rate is currency-neutral (it’s a count of status = succeeded divided by total). The rate is valid even when the underlying charges are in GBP, EUR, USD, and AUD simultaneously. For currency-by-currency breakdowns use Revenue by Currency, which sits on amounts not statuses.
“My subscription store sees a weekly auth rate cycle, why?”
Stripe Smart Retries runs in a cycle, typically attempting do_not_honor and insufficient_funds declines 3, 4 times over a week before giving up. The first attempt of every billing cycle is high-volume; subsequent retries have lower auth rates because the easy ones already cleared. If you bill weekly, the cycle peaks on Monday and troughs on Wednesday or Thursday. Check Retry Success Rate to see the dunning effect isolated.
“Why is my auth rate dropping after a successful ad campaign?”
First-time buyers attracted by paid acquisition skew toward higher-risk profiles than your existing customer base: more prepaid cards, more international issuers, more cards with weak Verified-by-Visa enrolment. Auth rate dropping by 2, 4 points after a 200% spike in new-customer traffic is normal. Confirm by checking Top Declining Issuers and Decline Rate by Card Country, then decide whether to tighten Radar rules or accept the cost as part of acquisition.
“My number is 1, 2 points below Stripe Dashboard, is something broken?”
Usually no. The four most common reasons are (in order): page-cap sampling on >1,000-charge days, time-zone boundary effects, outcome-reason backfill on the latest 24h, and the difference between Stripe’s “Authorised” view (which includes uncaptured holds) and our “Succeeded” view. A 1, 2-point gap is well within normal. A >5-point gap on the same window in the same time zone is worth raising to support.
“Why isn’t refund rate in this calculation?”
A refunded charge is still a successful authorisation, the customer’s bank approved the funds. Refund rate measures fulfilment health, auth rate measures processor health. Two different signals; pair them with Refund Rate for the joint view.