Most merchants assume a declined transaction means the customer's card was bad. Often, it means the gateway had a bad moment — and a different route through a different processor would have approved it seconds later.
What we were doing before we learned this
Early payment integrations we built connected a merchant to a single primary gateway, with a backup configured for manual failover during outright outages. Declines that weren't outages were treated as final — a customer's problem, not an infrastructure one.
What changed our mind
Logging decline reason codes across gateways revealed that a meaningful share of "hard" declines were actually soft, transient failures specific to one processor's relationship with one issuing bank at that moment — not a real problem with the card. Routing the same transaction through a different PSP, automatically and immediately, approved it a large share of the time.
- Decline reason codes vary by processor, and treating them as equivalent hides recoverable failures
- Issuing-bank-to-PSP relationships vary geographically, so the "best" gateway isn't fixed — it depends on where the card was issued
A decline isn't always a verdict on the customer. Sometimes it's just a bad match between two systems that had nothing to do with them.
What we do differently now
Payment orchestration now routes dynamically across multiple PSPs based on issuing bank location and real-time gateway health, retrying a soft decline through an alternate route before it ever reaches the customer as a failure. Across the merchants we've measured this on, it recovers roughly 14% of transactions that would otherwise have been lost.