How it works
A customer submits a payment. The transaction goes to the primary PSP. If the primary returns a decline, the orchestration layer evaluates the decline reason. If it's a soft decline — retryable — the transaction automatically routes to a secondary PSP. If the secondary approves, the customer sees a successful payment. The entire retry happens within the same checkout session.
If the decline is hard — stolen card, insufficient funds, invalid card number — the cascade stops. Retrying hard declines wastes processing capacity and can trigger scheme monitoring. The intelligence is in knowing which declines to retry and which to accept.
What counts as a soft decline
- Issuer rate-limiting — the bank temporarily throttles approvals for that BIN or merchant category
- Intermittent processor outages — the acquirer's system had a momentary failure
- Anti-fraud false positives — the issuer's fraud model flagged the transaction but a retry through a different acquirer often passes
- BIN-specific routing failures — certain card ranges fail on one acquirer but succeed on another
- Do-not-honor responses without a specific hard-decline reason code
Soft declines are the recoverable share. They represent transactions where the customer has money, the card is valid, and the intent to pay is real. The decline came from a system-level issue, not a customer-level one. A different rail often resolves it.
What it requires
Cascading isn't a setting you toggle on a single PSP. It requires infrastructure.
- Multiple PSPs configured per region — you need at least two active processors to cascade between
- Decline-reason intelligence — parsing response codes to distinguish soft from hard declines
- An orchestration layer that manages the retry within the customer's checkout session
- Latency management — the retry has to complete fast enough that the customer doesn't abandon
- Monitoring to track cascade recovery rates and identify when a PSP's decline rate spikes
The recovery numbers
Cascading typically recovers 5-15% of transactions that would otherwise decline. The exact recovery rate depends on the merchant's vertical, geography, and the decline profile of their primary PSP. High-risk verticals with elevated decline rates often see the upper end of that range because a larger share of their declines are soft.
On a merchant processing $5M per month, recovering 10% of declines is $500K in monthly revenue that would have disappeared at checkout. Over a year, that's $6M. The cost of running a second PSP and a payment orchestration layer is a fraction of what cascading recovers. The recovery share runs higher for iGaming operators specifically, because gaming-coded transactions face elevated decline rates from issuing banks — meaning more of those declines are soft and recoverable on a different acquirer.
Key Takeaways
- Cascading retries soft-declined transactions on a secondary PSP before the customer sees a failure.
- It requires multiple PSPs per region, decline-reason intelligence, and an orchestration layer.
- Hard declines (stolen card, insufficient funds) are not retried — only soft declines cascade.
- Recovery rates run 5-15% of declined transactions — significant revenue on high-volume merchants.
- High-risk verticals benefit most because their baseline decline rates are higher.