How to calculate approval rate correctly, with worked examples

Approval rate looks like the simplest number in payments: approvals divided by attempts. In practice two teams looking at the same data can report very different rates, because they count different things. One counts every authorization request, including retries. Another counts customers who tried to pay. A third removes fraud blocks from the denominator and a fourth does not.

This guide gives a formula you can defend, shows what belongs in the denominator, and walks through four worked examples. All the numbers in the examples are invented for illustration and are labelled as such.

What is approval rate?

Approval rate is the share of payments sent for authorization that the issuer or payment provider approved. Checkout.com’s documentation defines authorization rate as the percentage of successfully authorized payments out of all payments submitted to the card network for authorization. Stripe’s guide uses almost the same words: the percentage of transactions you submit that are accepted by the cardholder’s bank.

Three related metrics are often confused with it:

• Authorization rate: usually a synonym for approval rate, counted at the card network.
• Acceptance rate: a wider measure. Checkout.com calculates it from successfully requested payments minus risk-blocked transactions, authorization declines and authentication drop-offs, and recommends it for benchmarking providers because PSPs calculate authorization rates differently.
• Conversion rate: completed payments divided by customers who reached checkout. It includes people who never pressed pay.

None of these is wrong. The mistake is mixing them, or comparing one provider’s authorization rate with another provider’s acceptance rate.

What is the correct formula?

For decisions about routing and providers, use this:

Approval rate = approved payment intents ÷ payment intents submitted for authorization

A payment intent is one customer trying to pay one amount for one order. If the customer tries three cards in the same session, or your platform cascades the payment to a second provider, that is still one intent. Group attempts into intents by customer, amount and a short time window, or by the payment session ID your checkout creates.

Stripe’s documentation makes the same point from the other side: for a clearer view of authorization rates, analyse unique declines and exclude failed retries. Counting raw attempts punishes exactly the behaviour you want, because every retry or cascade adds to the denominator even when the customer eventually pays.

Keep two supporting rates next to the headline number:

• First-attempt approval rate: approvals on the first attempt ÷ intents. Checkout.com reports this as first attempt authorization success rate. It tells you how good your initial routing is.
• Recovery rate: approvals on second or later attempts ÷ intents that failed the first attempt. It tells you how much cascading and retries are worth.

Worked example 1: attempts versus intents

Example figures, for illustration only.

A merchant has 8,000 payment intents in a day.

Step	Attempts	Approved
First attempt at the primary provider	8,000	6,000
Soft declines cascaded to a second provider	1,200	480
Customers who retried with another card	900	300
Total	10,100	6,780

• Attempt-level rate: 6,780 ÷ 10,100 = 67.1%
• Intent-level approval rate: 6,780 ÷ 8,000 = 84.8%
• First-attempt approval rate: 6,000 ÷ 8,000 = 75.0%
• Cascade recovery rate: 480 ÷ 1,200 = 40.0%

The attempt-level number makes the merchant look worse the more it recovers. If it switched off cascading, its attempt-level rate would rise while it lost 480 approved payments a day. That is why the headline number must be intent-level.

What should you leave out of the denominator?

Only payments that actually reached an authorization decision belong in the approval-rate denominator. Report the rest as their own metrics:

• Blocked by your own risk rules. These never reached the issuer. Track them as a block rate, and review false positives separately. Stripe’s documentation, for example, treats payments blocked by its fraud tools as a separate failure type from issuer declines.
• 3-D Secure abandonment and failures. A customer who closes the authentication window has not been declined by the issuer. Track authentication success rate separately.
• Invalid requests and integration errors. Malformed requests and validation errors are bugs, not declines. Stripe classes them as invalid API calls.
• Test traffic and duplicates. Remove them before any calculation.

Technical declines that did reach a provider, such as timeouts or “issuer unavailable”, are a judgement call. Most teams include them, because the customer experienced a failure, and break them out in the decline-reason view.

Worked example 2: mixing in 3-D Secure drop-offs

Example figures, for illustration only.

Of 5,000 intents, 600 customers abandon the 3-D Secure challenge and 3,500 of the remaining 4,400 are approved.

• Including drop-offs: 3,500 ÷ 5,000 = 70.0%
• Excluding drop-offs: 3,500 ÷ 4,400 = 79.5%
• Authentication completion: 4,400 ÷ 5,000 = 88.0%

Both 70.0% and 79.5% are honest numbers, but they answer different questions. The first is closer to acceptance rate; the second is issuer approval rate. If the 3-D Secure flow gets worse, only the first number moves, and you would wrongly blame your acquirer.

How do you compare approval rates across providers?

Compare like with like, segment by segment. The most useful cuts are card issuing country, card brand and type (debit, credit, prepaid), new versus returning customer, amount band and, in high-risk verticals, merchant category code.

Without segmentation, traffic mix can make the worse provider look better.

Worked example 3: the mix trap

Example figures, for illustration only.

	Provider A	Provider B
Domestic cards	900 of 1,000 approved (90.0%)	2,640 of 3,000 approved (88.0%)
Foreign cards	1,800 of 3,000 approved (60.0%)	580 of 1,000 approved (58.0%)
Overall	2,700 of 4,000 (67.5%)	3,220 of 4,000 (80.5%)

Provider A is better in both segments, yet Provider B looks 13 points better overall because it received mostly domestic cards. Moving foreign-card traffic from A to B on the strength of the overall number would lower approvals. Routing decisions should use segment-level rates.

What do decline codes add?

The approval rate tells you how much you lose; decline codes tell you why. Group declines into a few buckets:

• Soft declines such as insufficient funds, generic “do not honor” and issuer unavailable, which may succeed later or elsewhere.
• Hard declines such as lost or stolen card, invalid account or closed account, which will not succeed anywhere and must not be retried.
• Authentication required, which should be retried with 3-D Secure. Adyen’s refusal reason list advises exactly that for its “Authentication required” code.
• Technical errors at the acquirer or issuer.

Stripe’s guide notes that many declines fall under the generic “do not honor” code, which is why a rising share of that code in one segment is often the first sign of an issuer tightening its rules.

What is one percentage point of approval rate worth?

Worked example 4: a high-volume online retailer

Example figures, for illustration only.

An online retailer has 8,000 payment intents a day with an average order of 50 euros. One percentage point of approval rate is 80 orders a day, or 4,000 euros of orders a day, or about 1.46 million euros a year. The value to the business is lower than the order volume, but the number shows why small, well-measured changes in routing matter. Omno’s approval rate calculator runs the same arithmetic on your own inputs.

How should you track it over time?

1. Fix the definition and write it down, including how attempts are grouped into intents.
2. Report intent-level approval, first-attempt approval and recovery rate together, daily, by segment.
3. Keep fraud blocks, authentication drop-offs and integration errors as separate metrics.
4. Watch the decline-code mix, not just the rate.
5. Annotate changes: a new routing rule, a new provider, a 3-D Secure change. Without annotations, nobody remembers why the line moved.

Omno reports real-time success metrics by provider and segment and writes every routing decision and cascade attempt to a routing-decision log, so each of these rates can be traced back to individual payments.