Failover
Failover is the automatic switching of payment traffic from a provider that is failing — an acquirer, a gateway, a processor, a 3-D Secure server — to a second one, so an outage on one side does not stop the checkout. It needs two integrations, tokens usable on both, health checks that decide when to switch, and a plan for the switch back; it is why large merchants run two PSPs.
- Also known as
- Payment failover, Acquirer failover, Redundant routing
- Used at
- any merchant whose revenue per hour of outage exceeds the cost of a second integration — large e-commerce, marketplaces, subscription businesses at renewal peaks, ticketing on sale days
- Binding
- no rule requires it; PSP service levels typically promise 99.9–99.99% availability, which is 9–90 minutes of outage a year, and pay small credits for breaches
- Typical architecture
- primary and secondary acquirers or PSPs behind an orchestration layer or the merchant's own routing; network tokens or a token vault portable across providers; health monitoring on error rates and latency; automatic switch on thresholds and manual switch-back
- Typical cost
- a second provider's minimums and integration, the token portability work, and the ongoing traffic split needed to keep the secondary warm — often 10–20% of volume routed to it in normal operation
- Parties
- the merchant, its providers, the orchestrator, and the customers who never see the outage
How failover works in practice
A merchant's primary PSP begins returning errors on 30% of authorisations — an incident on its side. The merchant's orchestration layer sees the error rate cross its threshold within a minute and routes new transactions to the secondary acquirer; stored cards are charged through network tokens the secondary can use; 3-D Secure runs on the secondary's server; the checkout's conversion dips for two minutes and recovers. When the primary's status page confirms resolution, the operations team shifts traffic back in stages. Revenue lost: a few minutes' worth. Without failover the merchant would have been down for the primary's incident — which lasted 85 minutes — and would have learned about it from customers.
The hard part is not the switch but the readiness. A secondary that carries no traffic in normal operation has stale integrations, untested edge cases and certificates that expired; the discipline is to run 10–20% of volume through it always, so it is known to work. Tokens are the other problem: cards stored as a PSP's own tokens cannot be charged through another PSP, so failover for stored credentials needs network tokens or a merchant-controlled vault. And settlement, reporting and reconciliation must handle two providers on every day, not just the bad ones.
For a PSP the merchant's failover is its competitor's foothold; for the merchant it is insurance whose premium is the second contract.
Example
A ticketing platform sells 40% of its annual volume in twelve on-sale hours a year. Its primary PSP has had 99.95% availability — 4 hours of outage a year — and one of those hours hit an on-sale in 2023: €2.1m of sales lost, and a press story. It adds a secondary acquirer through an orchestrator: €180,000 of integration, network tokens for the 3 million stored cards, a permanent 15% traffic split, quarterly failover drills. In the following year's on-sales the primary degrades once for 25 minutes; the switch happens in 70 seconds; sales continue at 92% of normal throughput on the secondary. The €200,000 of annual cost bought €1.9m of the €2.1m back, and the operations team's on-sale runbook now has a step that is not "call the PSP".
Common mistakes
- A secondary provider integrated and never used, discovered to be broken during the outage. - Stored cards as one PSP's proprietary tokens, so failover covers new customers only. - Switching automatically and never switching back, so the secondary becomes the primary by accident. - Reconciliation that assumes one provider per day. - Reading a PSP's 99.99% as safety; the 0.01% arrives on the day that matters.