Failover in payments is an automated redundancy mechanism that immediately redirects a transaction to a secondary payment service provider, payment gateway, or acquiring bank when the primary processor experiences a system outage, high latency, or technical failure, ensuring continuous payment processing and preventing checkout disruption.
How does Failover work?
Failover operates within a multi-processor or payment orchestration architecture where a merchant integrates with two or more acquiring banks or payment service providers (PSPs). During normal operations, the routing engine sends transactions to the primary provider based on predefined rules, such as processing cost or regional performance. The orchestration layer continuously monitors the health of this primary connection by tracking API response times, HTTP error codes (such as 500 Internal Server Error or 504 Gateway Timeout), and technical decline codes (such as ISO 8583 code 91 for issuer or switch inoperative, or code 96 for system malfunction).
When a transaction encounters a timeout or technical error, the system triggers an immediate, synchronous failover within the same checkout session. A central vault or network token repository supplies the payment credentials so the secondary processor can format and submit a new authorization request without prompting the customer to re-enter card details. If the primary processor crosses a threshold of consecutive failures, a circuit breaker trips, automatically routing all subsequent traffic directly to the backup acquirer until health checks confirm the primary system has stabilized.
Why does Failover matter for payment teams?
Relying on a single payment processor creates a critical single point of failure that directly threatens revenue and customer retention. When an acquirer or gateway goes down, every synchronous checkout attempt fails, leading to immediate cart abandonment and lost sales, while recurring billing batches stall completely. In a bid to address cost and outages without resiliency, half of all enterprise merchants have opted for multi-acquirer setups (Oliver Wyman, 2023).
Beyond preventing total downtime during catastrophic outages, automated failover protects authorization rates from localized degradation and micro-outages. Payment engineers do not have to wake up to manually flip routing switches during off-hours incidents. Automated switching contains the blast radius of processor instability and keeps payment acceptance invisible to the end user.
What are common use cases for Failover?
- Ecommerce retail: High-volume retailers rely on synchronous failover during peak flash sales like Black Friday, automatically shifting checkout traffic to a secondary acquirer when the primary gateway throttles requests or times out under heavy load.
- SaaS and subscription merchants: Subscription platforms reroute scheduled renewal batches to a backup processor when their primary acquirer experiences a regional outage, preventing involuntary churn and billing delays.
- Travel and OTAs: Online travel agencies use cross-border failover to redirect high-ticket airline and hotel bookings to a global backup PSP if a local acquiring connection drops, saving time-sensitive reservations.
- Digital goods and gaming: Gaming platforms execute instant mid-session failover for in-app microtransactions when a processor returns system error codes, ensuring players complete purchases without interrupting gameplay.
Failover vs Cascading
| Attribute | Failover | Cascading |
|---|---|---|
| Primary Trigger | Technical failure, API timeout, HTTP 5xx error, or processor downtime. | Soft issuer decline (e.g., Do Not Honor, Insufficient Funds) on a healthy connection. |
| Core Objective | Infrastructure availability, uptime continuity, and operational resilience. | Authorization rate optimization and conversion recovery across different acquirers. |
| Routing Scope | Can shift entire traffic cohorts via circuit breakers until health is restored. | Evaluates and retries on a strictly transaction-by-transaction basis. |
What are best practices for Failover?
- Maintain processor-agnostic tokenization: Store payment credentials in an independent vault or use network tokens so backup processors can decrypt and authorize transactions without re-collecting PAN data.
- Enforce strict idempotency and timeout thresholds: Cap primary API wait times (typically at 3 to 5 seconds) and pass unique idempotency keys to ensure a timed-out request does not result in a double charge when retried on the backup rail.
- Never failover hard declines: Restrict failover triggers strictly to infrastructure errors, network timeouts, and system malfunction codes; rerouting hard declines wastes processing fees and triggers card network retry penalties.
- Keep backup MIDs warm: Route a small, steady percentage of baseline traffic (such as 5% to 10%) to secondary acquirers daily so the connections remain tested and issuers recognize the merchant IDs during a full failover event.
How does SmartRetry help with Failover?
SmartRetry complements infrastructure failover by separating technical gateway errors from issuer-level declines in real time. When a processor returns system malfunction codes or experiences degradation, SmartRetry helps payment teams route around the disruption while applying machine learning to schedule and execute compliant retries for recoverable soft declines across multiple acquirers. Explore the SmartRetry Intelligent Retries engine to see how dynamic routing and automated recovery protect your revenue.
