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.
| What it counts | COUNT(charges WHERE status='succeeded') ÷ COUNT(charges) × 100. The denominator is every charge attempt Stripe saw in the window, including failed and pending. |
| API resource & field | GET /v1/charges, field status. The engine reads the snapshot at sync time. |
| Currency | n/a, this is a rate. The denominator and numerator span all currencies a merchant accepts; multi-currency stores get a single, valid percentage. |
| Fees / processing cost | n/a (rate metric). Fees are charged on successes only, irrelevant to the calculation. |
| Refunds | NOT a factor. A charge that succeeded then was refunded still has status = succeeded and counts as authorised. Refund volume sits on /v1/refunds. |
| Disputes / chargebacks | NOT a factor. Disputed charges still authorised; the dispute came later. |
| Failed / declined payments | INCLUDED in the denominator (this is the whole point). status = failed is the bulk of the “no” side. |
| 3DS abandons / SCA-required | INCLUDED if Stripe ever attempted to charge. status = canceled (SCA abandoned mid-flow) and status = requires_action are denominator-eligible but not numerator-eligible, so they pull the rate down. |
| Capture mode | Authorisation-only flows count if Stripe ultimately marked them succeeded. Auth-only holds that were never captured remain pending and pull the rate down. |
| Page cap | 1,000 charges per refresh (10 pages × 100). High-volume merchants (>1,000 charges/day) see the rate computed on the latest 1,000, not the full daily set. |
| Time window | T/7D vsP (today and rolling 7 days vs the prior 7) |
| Alert trigger | < 92%, mirrors the Stripe-published “healthy auth rate” floor |
| Roles | owner, finance, operations |
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):| Charge | amount | status | outcome.type | outcome.reason | Notes |
|---|---|---|---|---|---|
| ch_a01 | 4900 | succeeded | authorized | - | Standard new-customer charge |
| ch_a02 | 4900 | succeeded | authorized | - | Subscription renewal |
| ch_a03 | 4900 | failed | issuer_declined | do_not_honor | Issuer-side soft decline |
| ch_a04 | 4900 | failed | issuer_declined | insufficient_funds | Customer-side, recoverable next billing cycle |
| ch_a05 | 4900 | succeeded | authorized | - | Smart Retry win, original charge ch_a04-prior |
| ch_a06 | 9900 | failed | blocked | highest_risk_level | Radar blocked, NOT issuer-declined |
| ch_a07 | 4900 | requires_action | - | - | 3DS challenge sent, customer never returned |
| ch_a08 | 4900 | succeeded | authorized | - | Apple Pay, no 3DS |
- 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
| Card | Why merchants reach for it next to Auth Rate |
|---|---|
| Decline Rate | The mathematical complement (100 − auth_rate − pending_share). When auth rate drops, this is the second card to open. |
| Decline Reasons | When auth rate falls, this card tells you whether the cause is issuer-side (do_not_honor, insufficient_funds), Radar-side (highest_risk_level), or 3DS-side (authentication_required). |
| Recoverable Declines | Of the failed charges dragging the rate down, which would Smart Retries / dunning recover anyway? |
| Top Declining Issuers | Ranks the issuer banks declining you most. A single bad issuer can tank a regional auth rate by 5+ points. |
| 3DS Success Rate | If 3DS-attempted charges have a much lower success rate than non-3DS, the merchant is paying SCA in conversion. |
| Decline Rate by Card Country | Geographic split, often the auth-rate culprit when the merchant just opened a new market. |
| Payment Health Score | Auth rate carries 35% of the composite. The single biggest lever on overall health. |
| Shopify Conversion Rate / BC Conversion Rate | The upstream funnel view. A drop in auth rate that coincides with a drop in commerce conversion is a checkout-blocking incident; auth-rate-only drop means issuer-side. |
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.
| Reason | Direction | Why |
|---|---|---|
| Page cap (1,000 charges per refresh) | Ours based on the latest 1,000 | High-volume merchants (>1,000/day) see the rate computed on the most recent slice, not the full daily set. Sampling bias is small unless the merchant has very different auth rates across the day. |
| Time zone | Boundary days drift | Stripe Dashboard uses the account-level time zone setting; we use UTC. The “Today” cell can be 5, 8 hours behind what the merchant sees in Stripe. |
| Authorised vs captured | Ours lower when delayed-capture is heavy | Stripe Dashboard’s “Authorisations” view counts auth-only holds; we only count status = succeeded. Fraud-review flows that hold for 24 hours show on Stripe as authorised but on us as pending. |
| Refresh lag | Ours 5, 15 min behind real-time | The latest hour is always slightly stale; the rest of the window is caught up. |
| Outcome reason backfill | Ours slightly off on the most recent 24h | Stripe’s outcome.type and outcome.reason can be backfilled hours after the charge as Radar feedback loops settle. We read at sync time. |
| Comparison | Expected relationship | When divergence is legitimate |
|---|---|---|
stripe_auth_rate ↔ shopify.checkout_completion_rate | If auth rate is healthy and checkout completion drops, the issue is upstream (page errors, shipping, validation). If both drop together, payments are the culprit. | Different denominators. Shopify counts sessions; Stripe counts charge attempts. The two move together but not exactly. |
stripe_auth_rate + paypal.pp_auth_rate | Should be similar bands (90, 96%). PayPal slightly higher typically (Express Checkout reduces issuer friction). | A large gap means one processor’s traffic has different risk characteristics, e.g. PayPal users skew older and pay with debit, Stripe sees more credit and more fraud attempts. |
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.