Approval-rate decay: how to read a payment cascade properly
A group approval rate is an average of averages, and it hides the only thing you need to see. Decomposition by issuer country, card scheme, and attempt index is where the money is.
Group approval rate is the most-watched and least-useful number in broker payments. It is an average over corridors that behave nothing like each other, weighted by volume that shifts underneath you. A corridor can fail completely while the headline moves by less than a point.
The aggregation problem
Approval is not one process. It is a chain of independent decisions, your gateway, the acquirer, the scheme, and finally the issuing bank, and only the last of those actually declines most transactions. Issuers behave differently by country, by card product, and by how they read the merchant descriptor. Averaging across them destroys the signal.
approval_group = Σ(approvals_i) / Σ(attempts_i) for every corridor iIf your alerting is on the group rate, you will find out at month end, from the finance team, in a variance report.
The decomposition that works
Split attempts along four axes and monitor the cells, not the total. Anything coarser hides the failure; anything finer produces cells too small to be significant.
| Axis | Why it matters | Typical cardinality |
|---|---|---|
| Issuer country | Local issuer risk policy dominates the decline decision | 10 to 40 |
| Scheme and product | Debit, credit and prepaid decline for different reasons | 4 to 8 |
| Acquirer or PSP | Isolates whether the problem is yours or theirs | 3 to 12 |
| Attempt index | Separates first-attempt failure from cascade behaviour | 1 to 4 |
The fourth axis is the one most often missing. A corridor with a 62% first-attempt rate and an 81% final rate after retry is healthy. A corridor at 62% and 63% is not, the cascade is not doing anything and you are paying scheme fees for the attempts.
Reading a cascade properly
- 01Attempt 1, primary acquirerBaseline issuer behaviour
- 02Soft decline05, 51, 61, retryable
- 03Attempt 2, alternate acquirerDifferent BIN routing, different descriptor
- 04Hard decline04, 14, 41, 43, never retry
- 05Attempt 3, local railDifferent rails entirely, if you have one
Response codes are the whole game
Treating declines as one category is what makes cascades useless. A 51 (insufficient funds) is worth retrying tomorrow, not in four seconds. A 05 (do not honour) is a generic issuer refusal and often clears through a different acquirer with a different descriptor. A 41 (lost card) must never be retried at all. The difference between a cascade that recovers 15 points and one that recovers two is almost entirely in this mapping.
| Corridor | Attempts / mo | Approval | Best alternative | Recoverable |
|---|---|---|---|---|
| BR · Mastercard | 14,200 | 52% | 69% (tested) | $19,400 |
| TR · Visa debit | 6,050 | 58% | 64% (tested) | $4,100 |
| VN · local rail | 3,400 | 41% | none live | unknown |
Illustrative figures, chosen to show the mechanism. Your own numbers will differ.
Detection is the easy half
Any competent analyst can find a broken corridor given a week and the right export. The difficulty is that the finding has a short shelf life and an unhelpful shape: it arrives as “this route is down 19 points” and what the business needs is “move this traffic here, today, and recover this much.”
That second sentence requires something the alert does not have, continuously maintained performance data for every alternative route on the same corridor, current contracted costs, and enough recent volume through the alternative to trust the number. Without it, a detection is a task for somebody. With it, it is a decision that takes ten seconds to approve.