📈 Payment success rates and what drives them

One ratio, four denominators

“Success rate” refers to several distinct metrics that share a name but are calculated differently. All of them divide a number of completed payments by a set of attempts, and the numerator varies little from one definition to the next. The denominator, however, reflects a choice of scope, and that choice determines the level you get. Comparing two rates therefore requires identical denominators, which can't be verified as long as neither one is written down.

Four denominators are in common use. The first counts authorization requests sent to the network; the second, payment attempts initiated by the payer; the third, sessions that reached the payment form; the fourth, orders actually placed. The same day of traffic yields four different figures, each correct by its own definition. Each one answers a different question. So identify the denominator before you interpret the level.

1,000 payers reach the payment form.

  1,000  sessions at the form
 -   60  leave before submitting                 -> 940 attempts
 -   25  blocked by the merchant's rules         -> 915 sent to authentication
 -   55  abandon or fail authentication          -> 860 authorization requests
 -   70  declined by the issuer                  -> 790 approved on first attempt
 +   20  recovered by retries (55 retries sent)  -> 810 approved payments
 -    5  authorizations not captured             -> 805 payments collected

  Gross authorization rate        810 / 915  = 88.5%   (860 + 55 retries)
  First-attempt authorization     790 / 860  = 91.9%
  Payment success rate            810 / 940  = 86.2%
  Completion rate                 805 / 1000 = 80.5%

  Gap between the most flattering and the most honest figure: 11.4 points.
  One day of data, four results, no calculation errors.

Beyond cards, the metric measures something else

A push payment rail is a system in which the payment order starts in the payer's banking app, with no prior request from the merchant. Success-rate vocabulary comes from cards, where the merchant sends an authorization request and gets back a response carrying a verdict. On a push rail, that dialogue doesn't exist. The merchant waits for a credit that either arrives or doesn't, and the decision to execute the payment is made in the payer's app, out of the merchant's sight and outside its technical logs. A metric built on card response codes therefore has no equivalent on these rails.

Annual volume on these rails ranges from a few billion to several hundred billion transactions, depending on the country. Unified Payments Interface (UPI), operated by the National Payments Corporation of India since 2016, processed 241.62 billion transactions in fiscal year 2025–26. Pix, operated by the Banco Central do Brasil since 2020, processed 79.8 billion in 2025 alone. PromptPay in Thailand, QRIS in Indonesia, DuitNow in Malaysia, PayNow in Singapore, BLIK in Poland, and Bizum in Spain hold the same position in their home markets. PayNow has been operated by the Association of Banks in Singapore since 2017, and Bizum by Sociedad de Procedimientos de Pago since 2016. In these countries, a card-only success-rate dashboard therefore covers only a minority of the payments available to the merchant.

UPI distinguishes two families of failure in its return codes. An account-related decline stems from insufficient funds, a limit being reached, or a wrong PIN, and the cause lies on the payer's side. A technical failure stems from a system outage at a participating institution or in the central switch. A single percentage that lumps both families together leaves the source of any change undetermined. An account-related decline is handled by offering another payment method. A technical failure calls for escalation to the operator.

Why two markets don't produce the same figure

The success-rate gap between two markets is the difference in level observed on the same portfolio depending on the card's country of issuance. It sometimes reaches several points. Payment teams often blame local issuers, local fraud, or local shopping habits. Five structural causes account for most of the gap: the acquiring setup, the payment method mix, the foreign-currency position of issuing banks, the authentication regime, and the routing of co-badged cards. None of these five causes can be fixed by tuning the risk score. All of them are decided upstream of the risk engine, and none is an attribute of the transaction it evaluates.

In Nigeria, issuing banks' foreign-currency position played out across the entire banking system. Between 2022 and 2023, most of the country's major banks suspended international transactions on their naira cards for lack of foreign-currency liquidity. Service was restored only from July 4, 2025, under a quarterly cap, set at $1,000 per quarter at GTBank. The success rate of a cross-border subscription sold to Nigerian cardholders then depends on the issuing bank's foreign-currency balance sheet, regardless of the scheme and provider chosen.

Authentication: what it adds, what it takes away

Strong customer authentication verifies the payer's identity with at least two independent factors before the authorization request is sent. It has two opposite effects on success rates. An authenticated transaction reaches the issuer with additional data about the cardholder and the session, and its decline rate is lower. The same flow loses payers before authorization, when the verification code doesn't arrive or the challenge screen interrupts the purchase. The first effect shows up in the authorization rate; the second doesn't.

That second effect biases how the authorization rate is read. An abandoned authentication challenge triggers no authorization request, so the sale is lost while the authorization rate rises, because its denominator has lost a transaction that might have been declined. A deteriorating authentication chain therefore improves the most closely watched metric, while collected revenue falls over the same period.

• Transaction risk analysis exemption (EEA): available up to €100 if the requesting provider's fraud rate stays below 0.13%, up to €250 below 0.06%, and up to €500 below 0.01%. What counts is the provider's rate, not the merchant's.
• Low-value exemption (EEA): below a per-transaction cap, with a cumulative counter that an authentication resets to zero. The counter lives at the issuer, so the merchant never knows whether it's close to the limit.
• Merchant-initiated transactions: outside the scope of authentication, provided the first transaction was authenticated and the link to it is carried correctly in subsequent messages.
• India: after the first transaction on a mandate, authentication isn't required up to ₹15,000 per transaction; the threshold rises to ₹1 lakh (₹100,000) for insurance premiums, mutual fund subscriptions, and credit card bill payments.
• Markets that rely on SMS one-time passcodes: there is no exemption, and performance depends on the quality of the contact details the issuer holds, not those entered on the website.

In markets where the second factor is still a one-time passcode sent by text message, the authentication chain determines the outcome more than the risk score does. The code goes to the phone number registered with the issuing bank, not the one the customer entered on the merchant's site. A roaming cardholder, an outdated number on the issuer's file, or slow delivery all lead to the same failure. The merchant records these failures as declines, even though no issuer made a decision. Separating authentication failures from authorization declines in the technical logs is a precondition for any valid analysis later on.

Network tokens, and the missing identifier

A network token is a substitute number issued by a card network that replaces the card number in exchanges between the merchant and that network. From a success-rate standpoint, it works as an identifier that carries context all the way to the issuer. An issuer that receives a token knows how it was provisioned, which merchant it is bound to, and its intended channel. These elements add to the usual authorization data, and declines driven by uncertainty about the transaction's origin go down. The mechanism therefore lies in the content of the authorization message, not in the fraud-prevention figures the networks promote.

A second mechanism concerns the lifespan of the stored payment credential. The token survives reissuance of the physical card, because the network updates the token-to-card-number mapping in its vault without any action by the cardholder or the merchant. In a subscription model, the “expired card” decline reason disappears from the retry file and recurring revenue is preserved. The effect can be measured from the first billing cycle after the switch. India is the only major market where this architecture isn't optional, since merchants there have been barred from storing card numbers since October 1, 2022.

These figures come from internal measurements, published by an interested party, on a scope it defines itself and that no third party audits. The size of the gain depends on the makeup of the card portfolio. A portfolio of very recent cards, in a market with low reissuance, shows a smaller effect than an aging portfolio. A measurement run on the merchant's own traffic is the only figure that holds up in a commercial negotiation.

• Build two comparable cohorts on the same segment: tokenized traffic and card-number traffic, with the same BINs, the same amount bands, and the same period.
• Measure on the first attempt, before any retry; otherwise the retry policy absorbs the gap you're trying to isolate.
• Isolate the “expired card” reason in the decline distribution: that's where the token delivers its clearest and fastest gain.
• Require the Payment Account Reference in reports: without it, one cardholder counts as two separate customers, and both loyalty analyses and promotion-abuse checks go wrong.
• Check who owns the token requestor ID before any change of provider: if it's in the provider's name, the tokens don't follow you, and the stored card file has to be rebuilt customer by customer.

Currency, acquiring setup, and statement descriptor

Three transaction attributes that the payer can't see at the time of purchase weigh heavily on the issuer's decision: the acquirer's country, the currency of the sale, and the descriptor that will appear on the statement. None of the three is set in the fraud engine. All three stem from the acceptance contract and the initial configuration, which are set once and rarely revisited.

In several markets, this setup determines access to the domestic scheme rather than merely optimizing a cost. Accepting mada cards in Saudi Arabia requires a merchant ID opened by a locally licensed institution, settlement in riyals within the Kingdom, and a Saudi commercial registration. A contract signed with a foreign acquirer opens only international cards, a minority of the market. The same access logic applies to markets with a dominant domestic scheme, including RuPay in India, Elo in Brazil, TROY in Turkey, and Mir in Russia.

False positives in fraud prevention

A false positive is a legitimate transaction blocked by a fraud control. A fraud engine makes two kinds of errors, and only one of them produces an accounting entry. Undetected fraud comes back as a dispute, with an amount, a date, a case file, and an identified owner. A rejected honest customer abandons the purchase without leaving a trace in the merchant's books. That asymmetry in visibility leads to an asymmetry in tuning, which tightens the rules year after year.

A false positive costs more than the lost sale. A payer declined for no understandable reason doesn't always try again, and blames the brand rather than the risk engine that blocked the payment. The loss then covers the current order, its margin, and the value of purchases that will never happen. None of those three components appears in a fraud report.

# None of the terms below has a standard value. All are measured
# on the merchant's traffic, segment by segment, over a given period.

  N_blocked    = transactions blocked by the rule over the period
  p_fraud      = share of those actually fraudulent   <- MEASURED
  order        = average order value for the segment
  margin       = gross margin on that order
  dispute_cost = full cost of a dispute (fees + handling)
  CLV          = customer lifetime value for the segment
  return_rate  = share of blocked customers who come back and pay another way

  Gain = N_blocked *      p_fraud  * (order + dispute_cost)
  Loss = N_blocked * (1 - p_fraud) * (1 - return_rate) * (margin + CLV)

  The rule pays off if Gain > Loss.

# p_fraud can't be guessed. It is measured with a CONTROL GROUP:
# let through a small, randomly drawn share of the traffic the rule
# would have blocked, then watch what comes back as disputes.
# Without a control group, p_fraud is only as good as its author's gut feeling.

A control group is a slice of traffic, drawn at random from the transactions a rule would have blocked, that is let through to see what happens to it. Its cost is a deliberate amount of fraud, in a chosen and capped volume. In return, it reveals the share of the blocked traffic that is actually fraudulent. Without a control group, a fraud-prevention setup has no data on whether any of its rules is useful, in either direction. Rules then stay in place indefinitely, because nothing would justify removing them.

• Count internal declines separately. They don't appear in any network report, and their volume almost always comes as a surprise the first time someone looks.
• Track the recovery rate of blocked payers: do they come back within the hour, within the day, or never? The answer completely changes the cost assessment.
• Date every rule and give it a named owner. A rule written for a 2023 attack rarely survives a 2026 review.
• Review by segment, not globally: a threshold that protects a risky segment often chokes the most profitable one.
• Separate internal declines from issuer declines in logs and on customer-facing screens; otherwise neither population can be managed.

Comparing two providers honestly

Comparing two providers means measuring the performance gap between two acceptance routes fed with the same traffic. A rate announced by a provider, by contrast, covers its own portfolio, over the period it chooses, under the definition it applies. That figure can be accurate without being comparable to a competitor's or to the merchant's own. A usable comparison rests on four conditions: a definition frozen before the test, traffic split into homogeneous segments, random allocation, and a duration long enough for the gap to rise above the noise. These four conditions are rarely all met, and their absence explains most disappointing migrations.

The most common mistake concerns how traffic is allocated during the test itself. Out of caution toward an unproven system, a team sends the new provider the clean orders, known customers, and locally issued cards. The new provider then shows a rate three points higher, a gap that comes from the makeup of the traffic it received, not from its processing. Random allocation within each segment removes that bias. Keeping it in place beyond the first week requires someone in the organization to own it.