Cascading

When a customer submits a payment, the transaction is first routed to your primary PSP based on smart routing logic. If that PSP declines the transaction, it returns a decline code (typically an alphanumeric string like "05 - Do Not Honor" or "59 - Suspected Fraud"). The cascading engine immediately analyzes this code to determine if it's a soft decline worth retrying.

For soft declines, the system evaluates backup routing options: it checks which backup PSPs are available, reviews their recent approval rates for similar transactions, and confirms they use different acquirers or fraud screening parameters than the primary PSP. The goal is to find a meaningfully different processing path that might approve the transaction the first PSP declined.

The retry happens automatically and instantly - typically within 500-1,500 milliseconds. From the customer's perspective, there's no indication their payment was initially declined; they simply see a slightly longer loading time (1-3 seconds total vs. 1 second for a direct approval). If the second attempt is also declined, the system may try a third route, though success rates drop significantly after the second attempt.

Intelligent timing is critical: some decline codes benefit from immediate retry (technical errors, fraud filter blocks), while others need a slight delay (velocity limits may clear after 30-60 seconds) or shouldn't be retried at all (hard declines). The system applies rules-based + ML-driven logic to determine optimal retry strategy for each decline code and transaction type.

All cascade attempts are logged with timestamps, decline codes, and PSP identifiers to ensure compliance with card network rules (typically limiting retries to 4 attempts within 24 hours for the same card). The system also monitors for retry abuse patterns that could indicate fraud, such as multiple rapid retries with slightly different transaction amounts (a common technique used by fraudsters testing stolen cards).

For high-risk merchants, cascading typically recovers 10-15% of initially declined transactions, which translates directly to bottom-line revenue recovery with zero customer acquisition cost. A merchant processing $3M monthly with a 20% initial decline rate faces $600K in declined transactions. If cascading recovers even 12% of those declines, that's $72K in monthly recovered revenue or $864K annually - pure profit since the customer already wanted to buy and you've already paid acquisition costs.

The conversion rate impact is even more significant than the raw revenue numbers suggest. When customers experience payment declines, 60-75% abandon the purchase entirely rather than attempting a different payment method or card. This means every declined transaction represents not just lost immediate revenue, but potentially a lost customer relationship and negative brand perception. Cascading prevents this by converting what would be visible customer-facing declines into invisible backend retries that result in approvals.

For high-risk merchants operating near their chargeback rate thresholds, intelligent cascading provides a critical balancing act: it recovers legitimate transactions that were incorrectly declined by overly aggressive fraud filters, while avoiding the cascading of truly fraudulent transactions that would increase chargeback rates. The ML models learn to identify which declined transactions are likely legitimate customer mistakes vs. actual fraud, cascading only the former category.

The strategic value extends to business continuity. When your primary PSP experiences technical issues, rate changes, or sudden approval rate degradation, cascading automatically shifts traffic to backup PSPs without requiring manual intervention or customer impact. This resilience prevented millions in lost revenue for MIDs clients during acquirer outages and account freezes that would have completely halted sales for single-acquirer merchants.

Illustrative example — not a specific client engagement.

• A $6M/month dating platform implemented cascading and recovered 14% of declined transactions, converting $126K monthly in declined revenue. Their analysis showed "Suspected Fraud" and "Do Not Honor" codes had 38% success rates on first retry.
• An iGaming operator experienced a 35% decline spike when their primary PSP implemented aggressive fraud filters. Cascading automatically rerouted 82% of these declines to a backup PSP with less restrictive filters, recovering $420K in revenue during a single weekend.
• A nutra merchant with high chargeback sensitivity implemented ML-driven cascading that only retried declined transactions with fraud scores below 45. This recovered 11% of declines while actually reducing their chargeback rate from 1.2% to 1.0% by avoiding retry of high-risk transactions.

• Cascade only soft decline codes worth retrying: "Do Not Honor," "Suspected Fraud," "Velocity Exceeded," "Issuer Unavailable," "Technical Error"
• Use backup PSPs with different acquirer relationships and fraud screening parameters to maximize approval chances on retry
• Implement strict network compliance limits: maximum 4 retry attempts per card in 24 hours, logged with timestamps and decline codes
• Add exponential backoff for certain decline types: retry "Insufficient Funds" after 2 hours, 12 hours, 24 hours rather than immediately
• Monitor cascading success rates by decline code weekly, adjusting retry strategies based on which codes convert best on retry
• Implement fraud scoring thresholds for cascade attempts: only retry transactions below certain fraud scores to avoid increasing chargebacks
• Use geographic routing for cascades: if a US PSP declines a European card, cascade to a European PSP with different issuer relationships

• Cascading all declines including hard declines like "lost/stolen card" - this violates card network rules and can result in fines
• Using the same acquirer for primary and backup PSPs, eliminating the benefit since the issuer will decline for the same reason
• Implementing unlimited retry attempts without network compliance controls - Visa/Mastercard limit retries to 4 attempts per card in 24 hours
• Not distinguishing between decline codes: retrying "insufficient funds" immediately is pointless, but retrying after 24 hours has 30-40% success rates
• Cascading suspected fraud declines without additional verification, leading to increased chargebacks when actual fraud gets approved on retry
• Using backup PSPs with identical fraud rules and risk parameters as your primary PSP - you need meaningfully different processing paths