Payment failure rate measures the share of payment attempts that fail due to issuer declines, authentication friction (3DS/SCA),
fraud/risk blocks, or technical errors. This metric is often confused with checkout abandonment — but it’s different: payment failure happens at (or after) the moment a shopper tries to pay.
Back to the hub:
E-commerce Statistics.
Use this together with
checkout abandonment rate,
checkout completion rate,
and payment methods share.
Key benchmarks (cite-ready)
Payment failure is not a single cause — it’s a stack. Benchmarks are most useful when you cite them as
“payment attempts that failed at authorization/authentication” and then qualify by market, payment method, and device.
If you only cite one benchmark, cite the authorization decline reference and then immediately segment it (cards vs wallets, domestic vs cross-border, mobile vs desktop).
Otherwise it will be misread as “conversion drop” rather than “payment system failure”.
Failure layers (what “payment failure” actually includes)
Researchers and teams often mix these layers. Separating them makes the metric comparable and helps explain “fixable loss”.
| Layer | What it is | Common signals | Typical fixes |
|---|---|---|---|
| Issuer declines | Bank refuses the authorization | Insufficient funds, incorrect data, issuer risk rules | Smart retries, improved data quality, routing/acquiring, network tokens |
| Authentication friction (3DS/SCA) | Customer fails or abandons authentication | Timeouts, step-up challenges, slow flows on mobile | Adaptive 3DS, exemptions where valid, UX optimizations, better routing |
| Fraud/risk blocks | PSP or fraud engine blocks a payment | Velocity spikes, card testing patterns, high risk scores | Risk tuning, bot protection, step-up authentication, allowlists |
| Technical errors | Infrastructure or integration failures | Gateway timeouts, API errors, outages, client-side bugs | Monitoring, retries, fallback PSP, resilience testing |
This is why payment failure and checkout abandonment are related but not the same:
payment failure is a measurable “attempt failed” event, while abandonment can be behavioral.
Segment benchmarks (how to make the number meaningful)
One number won’t describe the market. For citation-quality reporting, segment payment failure at least by method, device, market, and customer type.
| Segment | What to report | Why it changes failure | Pair with |
|---|---|---|---|
| Payment method | Failure rate per method (cards vs wallets vs transfers) | Decline/authentication patterns differ by method. | payment methods share |
| Domestic vs cross-border | Failure rate for cross-border payments | Issuer and risk rules differ; cross-border can increase declines. | cross-border share |
| Device | Failure rate on mobile vs desktop | Authentication and UX friction is typically higher on mobile. | mobile revenue share |
| New vs returning | Failure rate by customer type | Returning customers often have stored credentials and higher trust. | repeat purchase rate |
| Recurring vs first purchase | Failure rate for recurring payments separately | Expired cards and insufficient funds are more common in recurring flows. | subscription churn |
Ready-to-cite evidence points (useful in articles)
These points are commonly used by researchers to justify payments work (routing, 3DS strategy, fraud tuning).
- Authorization declines can average around ~17% globally (higher in recurring/subscription contexts). 0
- 3DS can introduce measurable loss: one benchmark analysis reported that about one-fifth of payments sent to 3DS were lost. 1
- Issuer acceptance varies widely: the same analysis reported acceptance ranges across major banks that can span roughly ~68%–92%. 2
- Declines and failures are multi-cause: issuer declines, authentication failures, fraud blocks, and processor-related outages/errors are all distinct drivers. 3
Definition and calculation
Define “attempt” and “failure” explicitly — payment stacks return different error categories.
Payment failure rate is commonly calculated as:
Payment failure rate = Failed payment attempts ÷ Total payment attempts × 100
- Attempt: the moment you submit a payment authorization request (or equivalent “pay” action).
- Failure: declined, refused, blocked, authentication_failed, error, timeout — but report categories separately if you can.
- Don’t merge failures into “abandonment”; relate them as a subcomponent of checkout abandonment.
Reference pages: Glossary • Methodology
Sources
Primary sources used for definitions and benchmark evidence points.
- Stripe Docs — acceptance analytics and reasons payments fail (issuer declines, 3DS failures, Radar blocks): docs.stripe.com/payments/analytics/acceptance
- Stripe — failed payment recovery drivers (processor outages, fraud detection errors, etc.): stripe.com/resources/more/failed-payment-recovery-101
- Adyen Docs — refusal reasons and how refusals/errors are classified: docs.adyen.com/development-resources/refusal-reasons/
- Adyen Help — what “refused” means and why it happens (issuer vs risk rules): help.adyen.com/…/why-is-my-payment-refused
- Ravelin — 3DS friction and acceptance variability benchmarks: ravelin.com/…/payments-sent-to-3d-secure-are-lost
- Antom — industry reference point for global authorization declines (~17%) and higher rates for recurring flows: knowledge.antom.com/…/reduce-failed-payments
Cite this page
Copy and paste.
Best for Ecommerce. (2026). Payment failure rate benchmarks. Retrieved from
/ecommerce-statistics/payments-risk/payment-failure-rate-benchmarks/
