Payment Success Rate Is More Than Authorization

TL;DR: Payment success rate answers a different question than authorization rate. Authorization measures issuer approvals; success measures whether money actually reached a usable end state. Pick one terminal state, dedupe retries, and compare clean cohorts before you trust the number.

Your dashboard says payments are healthy. Finance says revenue is late. Both are looking at "successful" payments and counting different things. Measuring payment success beyond authorization rates starts with a boring problem: nobody agreed on which transaction state counts as success.

This guide gives you a payment outcome dictionary you can paste into your tracking spec, shows why success and authorization rates diverge, and walks through the retry and cohort traps that make the number lie. It is written for growth, merchant operations, and revenue operations leads at fintech and payment businesses, and it treats outcome measurement as a data-definition job, not decline-recovery advice.

What counts as payment success

A payment is successful when it reaches the terminal state your business treats as money earned — not when a screen says so. The customer-facing "Payment Successful" message is not the same as a settled transaction; the metric should track the final confirmed backend status, as payment practitioners point out.

Three candidate end states exist, and each answers a different question:

For growth teams deciding where to spend, authorized is the wrong end state. It tells you the bank said yes, not that you got paid. For most fintech and payment businesses, captured is the practical success definition for day-to-day funnel work, with settled used as the finance-grade check that feeds downstream payment reconciliation automation.

Many providers deliver the final state asynchronously. Adyen, for example, sends webhook event messages when an outcome is final — some methods like iDEAL can take seconds to days — so the initial API response is not the outcome, per Adyen's webhook documentation. If your "success" counter fires on the first response, it will overcount.

This is the same measurement discipline you apply when you calculate business process automation ROI: define the unit, define the end state, then count.

A data dictionary for payment outcome states

Use this dictionary as the shared contract between product analytics, the payment integration, and finance. Adjust the trigger events to your provider's event names; keep the terminal flags stable.

* Failed is terminal per attempt, not per purchase — the same purchase can retry.

Three fields make this dictionary operational instead of decorative:

• Attempt ID vs purchase ID. A purchase is the customer's intent to pay once; an attempt is each try. Every event must carry both, or retries corrupt the denominator.
• Terminal-state timestamp. Record when the state became final. A payment authorized on Monday and captured on Tuesday belongs to both days in different reports — store both timestamps.
• Success flag owner. One system flags success. If checkout, the gateway, and the warehouse each compute their own, you get three "success rates" that never reconcile.

Payment success rate vs authorization rate

The two rates use different denominators, so they cannot diverge "by error" — they diverge by design.

Stripe publishes both side by side and documents the formulas in its acceptance analytics documentation:

• Payment success rate — in Stripe's payment success rate definition, charges authorized by the card network ÷ unique payment attempts submitted through the provider. The denominator includes failed 3DS authentications, fraud-tool blocks, and issuer declines — everything except invalid API calls.
• Authorization rate = issuer approvals ÷ attempts that actually reached the card network. Failed authentication and blocked payments are excluded because they never got to the issuer.

Stripe's own worked example shows the gap: 103,000 total requests, minus 3,000 invalid, minus 1,000 failed authentication and 1,000 blocked, leaves 98,000 reaching the network; 93,000 authorized. That is a 93% payment success rate but a 94.9% authorization rate — same payments, different question.

Your payment approval rate (the issuer-facing number, sometimes called approval or payment authorization rate) isolates bank behavior from what your fraud rules, authentication flow, and checkout did upstream. When the success rate falls but authorization holds, the losses happened before the network — that is your stack's problem, not the banks'. Vendors like Corgi Labs describe the same split for exactly this diagnostic reason.

The decline rate formula mirrors the success rate: declined attempts over eligible attempts, sliced by refusal reason. Track the payment decline rate next to success rate, not instead of it.

Stop retries from inflating your attempts

Raw rates count every retry as a fresh attempt. A customer who fixes a typo and pays on the third try is one successful purchase — and two manufactured failures in a raw report.

Stripe's published example makes the distortion concrete: three attempts ending in one approval score 33.3% on the raw rate and 100% on the deduplicated rate, which groups retries of the same purchase and scores the final outcome, per the same acceptance documentation. Stripe groups retries by invoice, or by the same customer or card with the same amount close in time.

Apply the same rule in your own data:

1. Give every purchase a stable ID that survives retries.
2. Mark each attempt's final outcome.
3. Report both rates: raw for integration health (retries cost money and latency), deduplicated for customer reality.
4. Watch the observation window. Stripe warns that deduplicated rates dip temporarily in the current period because not all retries have finished — a subscription business running failed payment recovery and dunning will see this every cycle.

Adyen draws a parallel line: its gross authorization rate counts every authorization message sent to the issuer including failed attempts, while the net rate asks whether the order was eventually authorized — a distinction documented in payments-metric references. Same lesson, different label: decide whether your rate describes attempts or purchases before comparing numbers.

Compare like-for-like cohorts

A success rate is only comparable inside a stable mix. If this month's rate drops, the first question is what changed in the denominator, not what broke in the stack.

The usual mix shifts that fake a problem:

• Payment method. Wallets, cards, and bank redirects have different success mechanics and settlement speeds. A gateway-reported payment gateway success rate may also use the provider's own denominator — check before comparing.
• Geography and issuer. Cross-border traffic brings different decline codes and authentication rules.
• New vs returning customers. First payments carry more authentication friction than stored-credential repeats.
• Retry policy changes. Extending dunning raises deduplicated success while lowering raw success; both are "true."

Build the comparison as cohorts: same method, same corridor, same retry window, same observation period. This is the same cohort logic used to prove merchant onboarding activation with a first settled payment — an early "success" that never settles is not success at all.

Worked example: one synthetic week

Synthetic example — invented inputs, reproducible arithmetic, no client data. Assume a checkout week with:

Now the same week reads four different ways:

• Raw payment success rate (authorized ÷ valid attempts): 1,120 / 1,240 = 90.3%
• Authorization rate (authorized ÷ reached network): 1,120 / 1,190 = 94.1%
• Deduplicated success (purchases eventually captured ÷ purchases): 1,150 / 1,200 = 95.8%
• Settled rate (settled ÷ captured): 1,080 / 1,105 = 97.7%, with 25 captures still in the settlement batch

None of these is wrong. Each is correct for one decision: 90.3% flags integration friction, 94.1% flags issuer behavior, 95.8% describes whether customers actually paid, and 97.7% is what finance reconciles against. The failure mode is quoting one of them as "the" payment success rate in a deck.

What a good payment success rate looks like

Treat any published payment success rate benchmark as orientation, not a target. One payments KPI guide calls rates above ~95% healthy for card transactions and below ~90% a problem signal, with authorization rates below ~85% worth investigating — ConnectPay's KPI roundup. Your real benchmark is your own cohort baseline: method, market, and retry policy held constant.

If you publish one number to leadership, publish the deduplicated capture-based rate with the raw rate and authorization rate next to it, plus attempt volume and value-weighted success. Five lines beat one headline.

FAQ

What is payment success rate?

The share of payment attempts that reach your defined successful end state — usually captured or settled — divided by eligible attempts. It is broader than authorization rate, which only measures issuer approvals at the network step.

What is payment authorization?

The issuing bank's approval step: the issuer validates the card and reserves the funds, but the money has not moved. Authorization is necessary for a card payment and is not by itself a completed sale.

Is an authorized payment a successful payment?

Not yet. Authorization reserves funds; the payment can still fail at capture, expire, or be reversed. Count it as success only if authorization is explicitly your chosen end state.

Which rate should I report to the board?

A deduplicated rate based on captured (or settled) payments, paired with raw success and authorization rates. That combination separates customer reality, integration friction, and issuer behavior in one view.

Do retries belong in the denominator?

In the raw rate, yes — they measure integration health. In the customer-level rate, group them: one purchase, one outcome. Never mix the two conventions in the same trend line.

How does this differ by payment method?

Rails like UPI, wallets, and bank redirects have their own success mechanics and timing, so a single blended payment rate hides method-level problems. Compare within method cohorts and note that providers may define their denominators differently.

Answer clarity notes

• Dates: vendor definitions and examples were checked against the linked documentation on 2026-11-10; providers change their analytics definitions, so verify current formulas before rebuilding a report.
• Scope: written for growth, merchant ops, and RevOps leads at fintech and payment businesses measuring transaction outcomes; it is not decline-recovery or chargeback advice.
• Evidence: the worked weekly example uses synthetic inputs with reproducible arithmetic — it is not a measured client result or a benchmark. Stripe and Adyen formulas are public documentation; benchmark ranges cited are vendor-published rules of thumb, not guarantees for your traffic.
• Do not infer: threshold ranges are planning guidance, not guarantees; small samples and changing mixes can move the rate without any real change in performance.

Sources

• Stripe — Acceptance analytics
• Adyen — Webhooks
• Syntaqx — Payments metrics
• EnKash — What is payment success rate
• Cashfree — Authorization rate
• Corgi Labs — Payment analytics
• ConnectPay — Payment processing KPIs

---

Getting clean payment outcomes into one trustworthy report usually means fixing event plumbing, not buying another dashboard. If you want a second pair of eyes on your payment data flow, That'sGonnaHelp runs a bounded automation audit of workflows like this.