Payment Failover

Payment failover is the automatic transfer of payment traffic from a component that has failed, or is responding too slowly, to a backup that is working. The failed component may be an acquirer, a payment processor, a payment gateway, a network link, a data centre or a cloud region. The aim is that customers can keep paying, and merchants keep selling, while the fault is fixed.

Failover is a resilience technique rather than a product. It overlaps with multi-acquirer processing, which gives a merchant several acquirers to switch between, and with payment gateway routing, which chooses a route for each transaction. The difference is purpose: routing picks the best route under normal conditions, while failover reacts when a route stops working. Banks and payment firms in many countries are now required by operational resilience rules to plan for exactly this kind of disruption.

Think of a hospital's power supply. If the mains electricity cuts out, a backup generator starts within seconds, so the operating theatres keep running. Patients may never notice the switch, and the electrician can fix the mains while the generator carries the load.

Payment failover is the backup generator for paying. A shop's website normally sends card payments through one provider. If that provider goes down or becomes very slow, the system notices and starts sending payments through a second provider instead. Customers at the checkout keep paying as usual. When the first provider recovers, traffic can be moved back. Without failover, every customer during the outage would see an error, and many would shop elsewhere.

1. Detection. The routing layer watches each route's health using timeouts, error codes, response times and sudden changes in approval rates. Some firms also send regular test calls.
2. Decision. When a route crosses a threshold, for example more than a set share of timeouts in a minute, it is marked unhealthy. A pattern known as a circuit breaker stops new traffic going to it.
3. Switching. New transactions go to the backup route. In active-active set-ups both routes already carry traffic, so the backup simply takes more; in active-passive set-ups the backup is idle until needed.
4. Recovery. Small amounts of traffic are sent back to the failed route to test it, and normal routing resumes once it is healthy.

The harder question is what to do with transactions caught mid-flight. If an authorization request timed out, the merchant does not know whether the issuer approved it. Sending it again through another acquirer risks charging the customer twice. Well-designed systems send a timeout reversal, use an idempotency key for internal retries and reconcile the outcome later through status queries or a webhook notification.

If two routes fail independently, the chance that both are down at the same moment is much lower than for either one alone. Combined availability is:

• $A_1$ is the availability of the main route, as a fraction of time it is working.
• $A_2$ is the availability of the backup route.
• $A_{\text{combined}}$ is the share of time at least one route is working.

For example, with $A_1 = 0.995$ and $A_2 = 0.99$, combined availability is $1 - (0.005 \times 0.01) = 1 - 0.00005 = 0.99995$, or 99.995%. Over a year of about 8,760 hours, expected downtime falls from roughly 44 hours on the main route alone to about 26 minutes. The formula assumes the two routes do not share a failure cause; if both depend on the same cloud region, card network link or third party, the real gain is smaller.

Failover should not be confused with retrying declined payments. An issuer's decline is an answer, not an outage. Card networks restrict reattempts, especially of a hard decline, and some charge fees for excessive retries. Re-sending a soft decline to a second acquirer can be acceptable in limited cases, but treating every decline as a reason to fail over can breach rules and annoy issuers. A sensible design separates technical failures (timeouts, connection errors, system-unavailable codes) from business responses, and applies failover only to the first. A planned payment retry strategy for declines is a separate policy.

Supervisors increasingly treat payment continuity as a regulatory matter. In the European Union, the Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, has applied since 17 January 2025 and requires financial entities, including payment and e-money institutions, to maintain ICT business continuity and recovery plans and to manage ICT third-party risk. In the United Kingdom, operational resilience rules from the Financial Conduct Authority (FCA) and the Prudential Regulation Authority (PRA) require firms to set impact tolerances for important business services, such as making payments, and to stay within them during severe disruption. The Basel Committee published Principles for Operational Resilience in 2021 for banks worldwide. Contracts with providers usually set uptime targets in a service level agreement (SLA), though an SLA credit does not replace lost sales.

• Shared dependencies. Two acquirers may rely on the same processor or network link, so a single fault takes both down.
• Stored cards. Saved card numbers held in one provider's vault may not work through another, unless the merchant uses a portable vault or network tokenization.
• Cost. Keeping a warm backup means extra contracts, minimum fees, testing and staff time.
• False alarms. Thresholds set too tight can switch traffic away from a healthy provider and lower approval rates.

• Regulation (EU) 2022/2554 (DORA) on EUR-Lex
• Basel Committee on Banking Supervision