Ask three people in a company for the payment success rate and you'll often get three different numbers, all correct by their own definition. Product counts customers who reached checkout. Engineering counts API calls that returned success. Finance counts orders that were eventually paid. Each answers a different question, and the trouble starts when they're compared as if they were the same thing.
This guide sets out the definitions worth keeping apart, the choices hidden inside every success-rate formula, the mistakes that make the number lie, and how to break it down so that when it moves, you know why. We deliberately don't quote industry benchmarks: published figures rarely say what's in their denominator, so they can't be compared with yours.
Four numbers that get called "success rate"
Pick names for these and use them consistently. Most arguments about payment performance are really arguments about which of these someone meant.
| Metric | Numerator | Denominator | Answers |
|---|---|---|---|
| Checkout conversion | Orders paid | Customers who reached checkout | Is our checkout losing customers? |
| Order-level success | Orders paid | Orders where a payment was attempted | Do customers who try to pay end up paying? |
| Attempt-level success | Successful attempts | Attempts that reached the provider | How well does this provider or method perform? |
| Approval or authorisation rate | Approved authorisations | Authorisation requests sent to the issuer | How often do banks say yes? (Mostly a card metric) |
Order-level success is the one the business feels. Attempt-level success is the one you use to compare providers and methods, because it isolates each try. They diverge whenever customers retry: an order that fails on card and succeeds on UPI is one successful order and a 50% attempt-level success rate.
The choices hidden in the formula
Even with a name agreed, every success-rate calculation makes choices. Write them down next to the dashboard, because each one moves the number:
- Where the denominator starts. Counting from when a payment is created includes customers who abandoned before ever authenticating. Counting from when the request reached the provider excludes them. For comparing providers, the second is fairer, since a provider can't be blamed for a customer who closed the tab first.
- What counts as success. Authorised, captured or settled? For cards these can differ; for UPI and net banking, success usually means the debit was confirmed.
- When you measure. A payment created a minute ago may still be pending. Measure each payment after a fixed maturity window, not as soon as it's created.
- What you exclude. Test payments, requests your own risk rules blocked before they reached a provider, and requests rejected as invalid before they left your system should be counted separately, not as provider failures.
- How you treat duplicates. Two attempts created by a double tap are one customer intent, not two.
Six ways the number lies
These are the distortions that most often send teams chasing the wrong problem:
- Measuring pending as failed. If you compute the rate at the end of each hour, payments still waiting for the customer's PIN or bank count as failures, and the latest hour always looks worst. Use a maturity window and report pending separately.
- Retries inflating attempts. Automatic retries add attempts. The attempt-level rate can fall while more orders succeed, because the extra attempts recover payments that would otherwise have failed. Always look at both levels.
- Customer behaviour counted as provider failure. A customer who never approves a UPI collect request, enters a wrong PIN or doesn't have the balance is a real failure, but not a technical one. Classify failures by cause before comparing providers.
- A blended rate hiding a mix shift. If customers move from a method with a high success rate to one with a lower rate, the overall rate falls even if every method performed exactly as before. Break it down by method before concluding anything.
- Small numbers. A bank with a few dozen payments a day will swing wildly by chance. Set a minimum volume before ranking banks or alerting on them.
- Late corrections ignored. A payment you marked failed after a timeout may succeed later and be corrected by reconciliation. If your metric isn't recomputed after corrections, it understates success and overstates failures.
Classify failures by cause
A failure rate is only actionable once failures are grouped by who or what caused them. Provider decline codes vary, so map them into a small set of categories you control:
| Category | Examples | Who can act |
|---|---|---|
| Customer | Abandoned before authenticating, wrong PIN or OTP, cancelled on the bank page | Checkout design, method choice, reminders |
| Issuer or bank decision | Insufficient funds, card blocked, limit exceeded, risk decline by the bank | Mostly the customer; sometimes another method or a later retry |
| Technical | Timeouts, provider errors, bank or switch unavailable | Provider choice, routing and retries |
| Merchant-side | Your risk rules, invalid requests, configuration errors | You |
UPI reporting commonly makes a similar split between business declines, such as a wrong PIN or exceeded limit, and technical declines, where a bank or system wasn't available. The distinction matters because only technical failures are improved by routing to another provider. Our guide to payment declines explains what common decline reasons mean.
The breakdowns that explain a change
When the rate moves, slice it until the change concentrates in one place. These dimensions explain most movements:
- Payment method, and the flow within it: UPI intent, collect and QR behave differently, as do cards with and without saved tokens.
- Provider, for anyone using more than one.
- Issuing bank, card network and card type, or for UPI the customer's bank and app.
- Amount band, since high-value payments meet more checks and limits.
- Platform and app version, which catch checkout bugs after a release.
- Hour of day and day of week, to compare like with like.
- Failure category, from the taxonomy above.
A drop that appears across every bank and method on one provider points at that provider. A drop on one bank across every provider points at the bank. A drop on one app version points at your release.
Computing it: a worked query
Here's one way to compute both levels for a day's cohort, measuring only payments old enough to have settled into a final state:
-- Attempts created yesterday, measured now (at least a day later), excluding
-- test traffic and requests that never reached a provider.
WITH cohort AS (
SELECT order_id, method, provider, status
FROM payment_attempts
WHERE created_at >= current_date - 1
AND created_at < current_date
AND is_test = false
AND reached_provider = true
)
SELECT
method,
count(*) AS attempts,
round(100.0 * count(*) FILTER (WHERE status = 'succeeded') / count(*), 1)
AS attempt_success_pct,
count(DISTINCT order_id) AS orders,
round(100.0 * count(DISTINCT order_id) FILTER (WHERE status = 'succeeded')
/ count(DISTINCT order_id), 1) AS order_success_pct,
count(*) FILTER (WHERE status = 'pending') AS still_pending
FROM cohort
GROUP BY method
ORDER BY attempts DESC;The still_pending column is a health check on the measurement itself: if it isn't close to zero a day later, either your status updates are being missed or the maturity window is too short.
Turning it into alerts
Success rate is a good alerting signal if you respect its noise:
- Compare like with like: the same hour last week, not the last hour, because traffic and customer mix change through the day.
- Alert per method and per provider, not only on the blend, so a sharp drop on one method isn't averaged away.
- Require a minimum number of attempts before an alert can fire.
- Alert on technical failures and timeouts separately; they move first when a provider or bank has a problem.
- Include pending age: a growing queue of pending payments often precedes a fall in success.
Success rate is a lagging signal compared with error rate and response time. The Google SRE book's "four golden signals" (latency, traffic, errors and saturation) are a good companion set for the technical side. When an alert does fire, our payment gateway incident runbook covers the first hour.
Improving it
Once failures are classified, the levers are clearer:
LILPE's provider performance page describes how it measures success rate per provider and method, with the definition it uses, and its intelligent routing page describes how those measurements feed routing.
- Technical failures: spread traffic across providers, route away from a struggling one quickly, and retry recoverable failures. Our guide to smart routing explains how routing decisions use these signals.
- Issuer declines: offer an alternative method at the moment of failure, and keep card details current with tokenised cards where available.
- Customer failures: shorten the checkout, prefer flows that keep the customer in one place (such as UPI intent on mobile), and show clear instructions while a payment is pending.
- Merchant-side failures: review your own risk rules and validation errors; they're often the easiest wins.
Frequently asked questions
How do you calculate payment success rate?
Divide successful payments by payment attempts over the same period, after deciding exactly what counts in each. For comparing providers, count attempts that reached the provider and measure them after a maturity window so pending payments have resolved. For business reporting, use orders: orders paid divided by orders where payment was attempted.
What is a good payment success rate?
It depends heavily on payment method, customer base, average amount and how the rate is defined, which is why benchmarks without a stated definition aren't useful. Compare yourself with your own history, by method and provider, and investigate changes rather than chasing a headline number.
What is the difference between success rate and conversion rate?
Conversion rate usually starts earlier, from customers who reached checkout, so it includes people who never attempted to pay. Payment success rate starts from customers who did attempt a payment. A checkout problem shows in conversion; a payment processing problem shows in success rate.
Why did our payment success rate drop?
Break the rate down by method, provider, bank, app version and failure category. A drop concentrated on one provider suggests a provider issue; on one bank, a bank issue; on one app version, your release. Check also whether the payment method mix changed, which can lower the blended rate even when nothing performed worse.
Should retries count as separate attempts?
For attempt-level metrics, yes: each retry is a real attempt with its own outcome. For order-level metrics, no: report whether the order was eventually paid. Showing both makes it clear when retries are recovering payments.
Go deeper
Official sources
- Google — Site Reliability Engineering, chapter 6: Monitoring Distributed SystemsThe four golden signals: latency, traffic, errors and saturation; alerting on symptoms that matter.
Last reviewed . Examples, amounts and screens marked illustrative are not LILPE figures.
