> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Authorisation Success Rate, Stripe > Authorisation Success Rate for Stripe stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Payment Gateway](/nerve-centre/connectors#connectors-by-type) ## At a glance > The percentage of charge attempts on `/v1/charges` that ended in `status = succeeded`. The single best "is my checkout working?" signal Stripe exposes, and the 35% weight inside [Payment Health Score](/nerve-centre/kpi-cards/stripe/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 | ```text theme={null} Window total: 980 charges succeeded 916 (93.5%) failed (issuer) 44 failed (Radar blocked) 12 requires_action (SCA abandoned) 8 Auth Rate = 916 ÷ 980 × 100 = 93.5% ``` Three things to read from this: 1. **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). 2. **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 = failed` and pulls the rate down. If a merchant complains "my real auth rate is fine, it's Radar dragging the number", the [Decline Reasons](/nerve-centre/kpi-cards/stripe/top-decline-reasons) breakdown shows the split. 3. **SCA abandons (`requires_action`) hurt the rate without anyone noticing.** ch\_a07 is invisible in Stripe Dashboard's "Failed payments" tab (those filter on `status = 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](/nerve-centre/kpi-cards/stripe/decline-rate) | The mathematical complement (`100 − auth_rate − pending_share`). When auth rate drops, this is the second card to open. | | [Decline Reasons](/nerve-centre/kpi-cards/stripe/top-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](/nerve-centre/kpi-cards/stripe/recoverable-declines) | Of the failed charges dragging the rate down, which would Smart Retries / dunning recover anyway? | | [Top Declining Issuers](/nerve-centre/kpi-cards/stripe/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](/nerve-centre/kpi-cards/stripe/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](/nerve-centre/kpi-cards/stripe/decline-rate-by-card-country) | Geographic split, often the auth-rate culprit when the merchant just opened a new market. | | [Payment Health Score](/nerve-centre/kpi-cards/stripe/payment-health-score) | Auth rate carries 35% of the composite. The single biggest lever on overall health. | | Shopify [Conversion Rate](/nerve-centre/shopify/ecommerce_conversion_rate) / BC [Conversion Rate](/nerve-centre/bigcommerce/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](https://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. **Why our number may legitimately differ from Stripe Dashboard:** | 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. | **Cross-connector reconciliation:** | Comparison | Expected relationship | When divergence is legitimate | | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `stripe_auth_rate` ↔ [`shopify.checkout_completion_rate`](/nerve-centre/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`](/nerve-centre/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. | 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.
Documentation cross-reference (for agencies running multiple processors) The auth-rate metric exists with the same definition on PayPal. This is **not** a reconciliation, your Stripe charges aren't running through PayPal in parallel. These references exist purely so an agency running clients across multiple processors can cross-link the same metric across docs. * [`paypal.pp_auth_rate`](/nerve-centre/paypal/pp_auth_rate)
## 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](/nerve-centre/kpi-cards/stripe/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](/nerve-centre/kpi-cards/stripe/3ds-challenge-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](/nerve-centre/kpi-cards/stripe/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](/nerve-centre/kpi-cards/stripe/smart-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](/nerve-centre/kpi-cards/stripe/top-declining-issuers) and [Decline Rate by Card Country](/nerve-centre/kpi-cards/stripe/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](/nerve-centre/kpi-cards/stripe/refund-rate) for the joint view. *** ### Tracked live in Vortex IQ Nerve Centre *Authorisation Success Rate* is one of hundreds of KPI pulses Vortex IQ tracks across Stripe and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.