Payment Failover

What Is Payment Failover?

Payment failover is the automated mechanism by which a payment system detects a failed or declined transaction at one provider and re-attempts it—at the same provider after a delay, or at a different provider (cascade failover)—without manual intervention or the customer re-entering payment details. In a multi-acquirer architecture, failover ensures that a single provider outage, capacity limitation, or technical error does not translate into a lost sale.

Types of Failures and the Appropriate Response

Hard Declines: Do Not Retry

A hard decline is a definitive refusal from the issuing bank. Common hard decline codes include 05 (Do Not Honour), 14 (Invalid Account Number), and 41 (Lost Card). These signal that the issuer has made a final decision; retrying at the same or a different acquirer will not produce a different outcome and may trigger fraud flags at the issuer. Hard declines should route to customer communication—not to retry logic.

Soft Declines: Retry with Intelligence

A soft decline indicates a temporary condition: insufficient funds (51), exceeds withdrawal limit (61), or card activity limit exceeded (65). These may resolve after a short delay, with a reduced transaction amount, or by routing through a different acquiring bank that has a stronger approval rate relationship with that issuer. Intelligent retry logic retries soft declines once after a brief interval and, if still unsuccessful, offers the customer an alternative payment method.

Technical Errors: Cascade Immediately

Technical errors—connection timeouts, API 5xx responses, PSP-reported service degradation—trigger immediate cascade failover: the transaction is reformatted for the secondary acquirer and resubmitted, typically in under two seconds. A PSP abstraction layer handles the reformatting transparently without the merchant's application being aware of the provider switch.

Cascade Failover Architecture

A cascade is an ordered list of providers to try for a given routing scenario. Sequential cascades optimise for cost by preferring the cheapest provider first. Parallel cascades (fire both simultaneously, accept the first valid response) optimise for availability and latency. The cascade terminates when a provider returns either an approval or a definitive hard decline.

How Hellgate Hub Manages Payment Failover

Hub includes native cascade failover configuration. Payment operations teams define primary and fallback providers per routing scenario in Hub's flow builder—without writing code. Link's PSP abstraction reformats the transaction payload for each provider in the cascade transparently. Providers can be marked degraded manually or automatically based on real-time error rate monitoring.

Pulse surfaces cascade events in real time—showing which providers triggered cascades, how often, and what the cascade success rate was. This data informs both incident response (escalating to a PSP account team) and strategic routing decisions (a provider with a persistently high cascade trigger rate warrants demotion in the priority order).