How to improve your Stripe authorization rate
About one in three online payment declines is caused by something on the merchant side, not the bank. This guide explains what drives avoidable declines, how to tell them apart from issuer decisions, and how to find them in your own Stripe data.
What is an authorization rate?
Your authorization rate is the percentage of payment attempts that are approved by the issuing bank. A charge attempt on Stripe has one of two outcomes: authorized (the issuer approved it) or declined (the issuer or Stripe refused it). The authorization rate is approved / total_attempts.
Most Stripe merchants see an overall authorization rate between 82–93%. The gap between you and the top of that range is your opportunity. Even a 2 percentage point improvement on €1M/month in payments is €20,000/month recovered.
Why do authorizations fail?
Declines fall into two buckets:
- Hard declines
- Permanent rejections: stolen card, account closed, card reported lost. Nothing you can do. Do not retry.
- Soft declines
- Temporary rejections: insufficient funds, generic issuer error, do-not-honor. Retrying after a delay can succeed. 3DS challenge can sometimes convert these.
- Friction declines
- The issuer would have approved the payment, but 3DS friction caused the customer to abandon. These are entirely merchant-controlled.
- Segment underperformers
- A specific slice of your traffic, such as a country, card brand, or session type, has a materially lower auth rate than the rest. The fix depends on why.
The four most common fixable leaks
1. Geographic underperformers
If you sell internationally, some card-issuing countries authorize at materially lower rates than others. Germany, the Netherlands, and several LATAM markets frequently underperform UK and US baselines. The cause is usually one of two things: 3DS preferences (local issuers require it), or network routing (cards issued in certain markets route via intermediaries with lower approval rates).
The fix: enable 3DS for the underperforming country, or work with Stripe to review network routing. Before you act, confirm the gap is statistically significant. A small sample can produce misleading rates.
2. Off-session charging without 3DS
Off-session payments (charging a stored card when the customer is not present) have lower auth rates than on-session payments in most markets. European issuers in particular apply Strong Customer Authentication (SCA) requirements more aggressively to off-session charges without prior 3DS consent.
The fix: ensure you are collecting 3DS consent at the time of card storage (setup_future_usage: 'off_session' when creating a PaymentIntent). This signals intent to the issuer and pre-authenticates the recurring relationship.
3. Soft-decline retries without pause
Retrying a soft decline immediately rarely works and can damage your merchant reputation with the issuer. The standard guidance is: wait 24 hours before the first retry, and no more than 3 retries total. Retrying a hard decline is worse: it will never succeed and counts against your decline rate.
Check your data: if you have a material volume of retries within minutes of the original decline, this is likely suppressing your overall auth rate.
4. Excess 3DS friction on low-risk transactions
3DS reduces fraud, but it also introduces abandonment. If you are triggering 3DS on transactions that your issuer would have approved without it, you are trading authorized revenue for fraud protection you did not need. Stripe Radar rules and payment method configuration both influence when 3DS is triggered.
The signal: compare your auth rate on three_d_s_outcome: not_required versus three_d_s_outcome: challenged in your analytics export. A significant gap points to 3DS over-use on a particular segment.
How to find leaks in your own data
The right method is a logistic regression across all dimensions simultaneously. This matters because authorization rates are correlated. A country that appears to underperform might actually be explained entirely by its card brand composition, or its mix of on-session versus off-session payments.
A raw rate comparison (country A has 78%, country B has 89%) does not control for these confounders. A regression does. Each coefficient tells you the independent effect of that segment after holding everything else constant.
Only report a finding if it clears the significance threshold: Wald test at p < 0.05 with at least 100 observations. Below that, the data does not support a conclusion.
Pliero does this automatically. Upload your Stripe Analytics export, and Pliero runs the regression, applies the significance test, and surfaces only the findings that clear the bar, ranked by monthly revenue at stake.
Run your free audit →What to measure after making changes
After implementing a fix, wait at least 30 days before evaluating the result. You need enough volume for the improvement to be statistically detectable. Then compare:
- →Overall authorization rate (before vs. after)
- →Authorization rate for the specific segment you targeted
- →Monthly revenue impact (improvement in auth rate × monthly volume for that segment × average amount)
Upload your new export to Pliero after 30 days. If the finding no longer clears significance, the fix worked. If the gap persists, the cause is something else.