Card Authorisation Rate

A customer may want to buy but the card payment can fail, and not all failures reach the issuer. Card authorisation rate focuses on attempts submitted into the authorisation process and the approvals returned.

For example, 9,300 approvals from 10,000 eligible network attempts give 93%, and the numerator and denominator must cover the same period and payment population. Stripe distinguishes network authorisation rate from payment success rate, and its authorisation denominator excludes attempts blocked before reaching the network, such as some authentication failures or processor blocks.

This matters because a merchant can improve issuer approvals while losing more customers before submission, so review both metrics before claiming that customers can pay more easily. Authentication and authorisation are also separate steps, as a customer can fail a 3-D Secure challenge before the issuer receives an authorisation request, and other payment methods and regions may have different steps.

Issuer declines can reflect insufficient funds, expired credentials, suspected fraud or restrictions on a transaction, and some response codes are generic. Not every decline is a lost valid sale, because some attempts are fraudulent or should be rejected, so the goal is to reduce false declines while keeping risk controls appropriate.

Segment the rate by card country, issuer, product, amount, transaction type and time, since a blended average can hide one route with unusually low approvals, and compare enough volume to avoid chasing random noise. Recurring billing needs special attention, because stored card details can become outdated and a renewal may occur without the customer present, although card updater services or network tokens may help in some cases.

Retries should follow response advice and programme rules: a temporary insufficient-funds decline might support a later retry with customer permission, whereas a lost or stolen card response does not, and repeated blind attempts can create fees or harm approval performance. Stripe's analytics can show a raw rate and a deduplicated rate that groups attempts for one purchase, since a customer fixing a mistyped security code may create multiple raw attempts but one eventual successful purchase.

Authorisation is not the same as settlement, since an approved transaction may later fail capture, be refunded or disputed, and payment gateways and acquirers may report slightly different definitions, so check whether both include retries, pre-network blocks and test transactions alike before comparing two processors. Use a funnel from checkout start to successful paid order that counts attempts that never reached authorisation, network declines and post-approval failures.

A merchant might correct address or card data collection and see fewer avoidable declines, or adjust fraud settings, but lowering checks without evidence can raise chargebacks, so test changes with risk and approval metrics together. Local routing can affect results because cross-border transactions may have different issuer responses, so investigate actual issuer and acquirer data rather than assuming every foreign card fails for the same reason.

A good rate depends on industry, geography, amount, customer mix and fraud profile, and a two-point increase in approvals does not automatically equal a two-point increase in revenue, since ticket sizes, retries and fraud matter, so estimate net successful orders and contribution instead. For a subscription business, track involuntary churn separately, because a failed renewal might later recover through a valid retry or updated card, and the first failed attempt and the recovered subscription should not both be counted as permanent lost revenue, while the rate itself remains a diagnostic for one stage of payment acceptance whose value comes from a clear denominator, sensible segmentation and fixes that do not weaken protection against invalid transactions.