We had a routing rule that read well on paper: if acquirer A declines, retry on acquirer B. The goal was a higher approval rate.
The rule looked at the HTTP outcome and the generic "declined" flag. It never looked at the response code. So a card reported lost (43), a stolen card (41) and an invalid card number (14) all got sent to a second acquirer. All of them were declined again, and each attempt was a separate authorization in the scheme's eyes.
The approval rate didn't move. Issuers logged repeated attempts on cards they had already told us were dead. Our decline ratio per acquirer went up. The failover also added about 1.5 seconds of latency to every one of those checkouts.
The fix was a table of response codes in three buckets:
- Technical (timeout, 91 issuer unavailable, 96 system malfunction): fail over immediately.
- Soft (51 insufficient funds, 05 do not honor): retry later or ask for another payment method, but not on another acquirer right now.
- Hard (04, 07, 14, 41, 43, 54): stop, and tell the customer to use a different card.
After that change, failover volume dropped by roughly 60% and approval rate stayed flat. That tells me most of the old retries were never recovering anything.
How do you classify codes when different acquirers map the same issuer response to different values? Do you normalize them at the gateway layer, or keep per-acquirer tables?
Payneteasy builds exactly this kind of orchestration layer for PSPs — see how it works.
Top comments (0)