How to measure what cascading recovers: the four numbers a PSP should watch per route group

Every orchestration vendor quotes a recovery rate. The honest number is the one you measure on your own route groups, with your own acquirers and your own merchants, and it changes every month. Here is what to count, how to count it, and which mistakes turn a good number into a misleading one.

What a cascade is, in numbers

A route group is an ordered list of terminals that can take a payment. The first terminal declines some share of the payments it sees; a part of those declines came from the payer (no funds, an invalid card) and a part from the terminal (a risk rule, a limit, an outage). The cascade retries the second part on the next terminal. What it recovers is the share of first-terminal declines that end approved somewhere in the group; what it costs is the time of the failed attempts, the fee of the terminal that finally approved, and the risk that a recovered payment comes back as a chargeback. Four numbers describe the trade.

The four numbers

1. Recovered share. Of the payments declined on the first terminal, how many ended approved on a later one. Count per route group and per decline reason; a group that recovers insufficient-funds declines is retrying what it should not.
2. Time to result. The payer waits through every attempt. Measure the median and the slowest tenth; a group of five slow acquirers recovers payments and loses payers.
3. Cost per approval. A cascade to an expensive acquirer may recover a payment that costs more than its margin. Put the fee per terminal in the rule and look at the cost of the approved payments, not the count.
4. Chargeback ratio per terminal. Recovered payments must not be the ones that come back. Compare the ratio of cascaded approvals with the ratio of first-attempt approvals, per acquirer.

How to count each one

The denominators matter more than the numerators. A recovered share counted over all declines, including the hard ones, is always small and tells you nothing; counted over retryable declines it tells you whether the second terminal is worth its fee. A chargeback ratio needs the lag the schemes’ timelines impose, so the number for a month is not final until two months later.

The mistakes that make the numbers lie

• Counting retries of hard declines. A stolen card declined three times is three declines, not two recoveries; classify first, cascade second.
• Comparing groups with different traffic. A group that gets large amounts will always show worse approval; compare the same merchants and amounts before and after a rule change.
• Ignoring abandonment. A redirect method cascaded to another redirect loses payers who close the tab; count them as declines of the cascade.
• One month only. Acquirers change rules without notice; watch the trend.
• Counting a payment twice. When two route groups overlap, a payment that moved from one group to another can be counted as recovered in both; count by the payment’s reference, not by the attempt.
• Trusting the first week. A new terminal gets the traffic the rule sends it, and the first week’s approval rate reflects the rule more than the acquirer; wait for a full cycle of the merchants’ billing before deciding.

A worked example

A route group for European cards has two acquirers. In a month the first terminal sees 100 000 payments and declines 12 000; the classification marks 7 000 of them retryable (risk rules, limits, timeouts) and 5 000 hard. The second terminal approves 2 800 of the 7 000: the recovered share is 40 percent of retryable declines, or 2.8 percent of all payments, which is the number that reaches the merchants’ revenue. The median time to result for cascaded payments is four seconds against one for first-attempt approvals; the second terminal’s fee is a third higher, so the cost per cascaded approval is known before the margin is counted; and sixty days later the chargeback ratio of the 2 800 is compared with the ratio of the 88 000 first-attempt approvals. If it is not higher, the cascade earned its place; if it is, the limits on the second terminal need work, not the cascade itself.

What to change when a number moves

A falling recovered share with a stable decline rate usually means the second terminal started declining the same reasons as the first: look at its reason codes and its limits. A rising time to result means an acquirer slowed down: move it down the priority list or give it a time window. A rising cost per approval means the weights shifted traffic to the expensive terminal: check the weights and the amount bands. A rising chargeback ratio on cascaded approvals means the cascade is recovering payments it should refuse: tighten the classification and the velocity limits per card.

Where the numbers live

In Tranzify the back office shows attempts, results and reasons per route group, terminal and merchant, from the journal that keeps every attempt for five years. The rules change in the flow builder; the numbers tell you whether they should. The product page on orchestration describes the rules, and the page on cascading payments the classification of declines; the industry pages show the typical route groups of iGaming, forex and e-commerce.