How to calculate payment approval rate correctly

Payment approval rate is the number of approved payments divided by the number of payments that reached a final answer, approved or declined. Payments still pending, payments the customer abandoned and payments that failed for technical reasons stay out of it, and each gets reported as its own rate.

Some providers call it authorization rate or acceptance rate. The formula below works whatever the name.

That definition sounds obvious. Most dashboards still get it wrong, and the error is rarely small. When pending payments sit in the denominator, the approval rate can look 20 points worse than it is. When technical errors are counted as declines, a broken integration looks like a strict bank.

What is the correct formula for approval rate?

Approval rate = Approved / (Approved + Declined)

It only works if every payment lands in exactly one of five buckets:

• Approved: the payment reached a final approved status. For cards, that is the authorization. For bank transfers and cash vouchers, that is the confirmed payment, not the creation of the reference. A later refund or chargeback does not change it.
• Declined: the issuer, the bank or the PSP risk engine looked at the payment and said no. Insufficient funds, do not honor, suspected fraud, limit exceeded, authentication refused by the issuer.
• Pending: no final answer yet. The customer has a reference but has not paid, or the provider has not confirmed.
• Expired or abandoned: the payment will never get an answer. The reference passed its expiry window unpaid, or the customer left the 3D Secure page without completing it.
• Technical error: the payment never reached a decision. Timeout, invalid request, missing configuration, a method not enabled for that country.

Then report these next to the approval rate:

Success rate = Approved / (Approved + Declined + Technical errors)

Pending rate = Pending / All attempts

Technical error rate = Technical errors / All attempts

Order conversion = Orders with an approved payment / Orders that started checkout

Approval rate answers one question: when a bank or provider made a decision, how often was it yes. Success rate adds your own failures, and shows what actually reached your revenue. The gap between the two is the cost of your integration problems.

Why should pending payments stay out of the approval rate?

A pending payment has no outcome yet. Putting it in the denominator treats every unpaid reference as a failure, which mixes two different questions: did the bank accept the payment, and did the customer pay at all.

The effect is largest with methods where the customer pays after checkout. A card payment resolves in seconds. A bank transfer reference or a cash voucher can stay open for hours or days, and many are never paid. In markets where these methods carry a large share of volume, a naive approval rate measures customer behavior far more than acceptance.

Pending also inflates volume. If created references count as attempts and are never closed, the attempt count grows with every unpaid voucher. That is why each payment method needs an expiry rule: once the window is over, the payment moves to Expired and leaves the pending bucket for good. Expired payments weigh on order conversion, never on approval rate.

Should technical errors count as declines?

No. A decline is an answer. A technical error is the absence of one.

When a request times out, when a required field is missing, or when the payment is sent to a method that is not configured, no bank looked at it. Counting these as declines lowers the approval rate for reasons the issuer never caused, and sends the team to negotiate acceptance with the PSP when the fix is in its own integration.

Keep technical errors in their own rate and split them by cause. A spike on one method or one country usually points to a configuration change, an expired credential or a provider incident. Those are fixed in hours. A drop in approval rate is a different conversation, about risk rules, data quality or the issuers you reach.

Bad customer data needs a careful split. If the provider rejects the request before sending it to the bank, because a name format, a postal code or a document number is invalid, it is a validation error and belongs with technical errors. If the bank received the payment and declined it because the data did not match, it is a decline, with its own data reason. In both cases the fix is on your checkout form, not with the bank.

Sorting payments into these buckets depends on reading the decline reason correctly, which is harder than it sounds when every provider spells it differently. We cover that in Why a declined payment rarely tells you why.

What does the calculation look like with real numbers?

Example, with illustrative numbers for one week:

• Orders that started checkout: 650
• Payment attempts: 1,000
• Approved: 520
• Declined: 180
• Technical errors: 60
• Pending at the time of the report: 240

For simplicity, each paid order has exactly one approved payment.

The naive calculation divides approved by all attempts:

520 / 1,000 = 52%

The correct calculation divides approved by approved plus declined:

520 / (520 + 180) = 74.3%

That is a 22 point gap on the same data. Nothing changed in the payments. Only the denominator did.

The other rates complete the picture:

• Success rate: 520 / (520 + 180 + 60) = 68.4%
• Pending rate: 240 / 1,000 = 24%
• Technical error rate: 60 / 1,000 = 6%
• Order conversion: 520 / 650 = 80%, provisional while 240 payments are still open
• Attempts per order: 1,000 / 650 = 1.54

Each number now points to a different action. 74.3% approval is the acceptance question, for the PSP and the issuers. The 6 points between approval and success rate are integration problems. 24% pending is an expiry and checkout question. 1.54 attempts per order says customers often retry or receive several references for one order, which pushes the naive rate down even further.

Why do attempts per order matter?

One customer can generate several attempts for one order. A card is declined and the customer tries another card. A bank transfer reference is created, then a cash voucher, then a card payment. Only one gets paid.

If attempts are counted without linking them to orders, every retry and every abandoned alternative reference looks like a failure. The rate looks worst in exactly the markets where offering several payment methods is the normal way to sell.

Attempts per order separates the two effects. If approval rate is stable and attempts per order rises, customers are retrying more: look at the checkout, the message shown after a decline, and the order in which methods are offered. If approval rate drops and attempts per order is flat, the problem is acceptance.

Retries also need rules. Some declines are soft, like a temporary issuer problem or insufficient funds, and a later retry can succeed. Others are hard, like a stolen card or a closed account, and retrying them only adds declines. Card networks set limits here: Visa, for example, forbids reattempting declines where the issuer will never approve, and caps reattempts on the others. Automatic retries should follow the decline code, not a fixed schedule.

All of this needs the merchant order ID on every attempt. Without it, five failed customers and one customer who tried five times look the same.

When should you calculate the approval rate for a period?

By creation date, and only once the payments of that period have had time to resolve.

If you report on Monday morning for last week, Sunday’s bank transfers and cash vouchers are still open. Two approaches work:

• Report a provisional rate with the pending rate next to it, and recompute it once the expiry window has passed.
• Lock the period only after the longest expiry window among the methods it includes.

What does not work is comparing a fresh week with an older one. The older week has resolved its pending payments, the fresh one has not, and every week looks worse than the one before.

Which breakdowns make the approval rate useful?

A single rate across all methods and countries hides more than it shows. Card authorization and cash voucher completion measure different things, and their average is a number nobody can act on. Break it down by:

• Payment method
• Country and currency
• PSP
• Card issuing country, for card payments
• Hour of day, to catch provider incidents and issuer maintenance windows
• Pay in and pay out, always kept apart

When we review a merchant’s numbers, the first breakdown is almost always by payment method. It is where the naive rate and the correct one drift furthest apart.

FAQ

Should pending payments be counted as declines?
No. A pending payment has no outcome yet. Report it in its own pending rate, and move it to Expired once the expiry window for that method has passed. Expired payments affect order conversion, not approval rate.

Is approval rate the same as authorization rate or acceptance rate?
Usually, yes. Providers use the three names for the same idea. Check how each one builds its denominator before comparing their numbers: some include technical errors or pending payments, which makes their rates look lower.

What is the difference between approval rate and success rate?
Approval rate only counts payments that received a decision from a bank or provider. Success rate also counts technical errors in the denominator. The gap between the two shows how much volume is lost to integration and configuration problems.

What is the difference between approval rate and conversion rate?
Approval rate measures how often a decided payment was accepted. Conversion rate measures how many orders ended with a successful payment. A merchant can have a high approval rate and a low conversion rate if many customers never complete the payment.

Is a failed 3D Secure authentication a decline?
If the issuer refused the authentication, yes. If the customer left the authentication page without completing it, it is an abandonment and stays out of the approval rate. Track both reasons separately.

What is a good payment approval rate?
It depends on the payment method, the country, the card mix and the risk profile of the business. The most reliable benchmark is your own rate over time, broken down by method and country, and calculated the same way every period.