On a Thursday in September 2023, Square went down around noon Pacific and stayed down for roughly 19 hours. Sellers across the US couldn’t take card payments. Some switched to cash. A few wrote card numbers on paper and hoped for the best. Most just lost the sale.
Those businesses didn’t do anything wrong, exactly. They’d sent every payment through one door, and the door closed.
That’s the problem failover exists to solve. It’s the part of payment routing nobody thinks about on a normal day and the only part that matters on a bad one.
Outages Aren’t Rare, and They Aren’t Always Total
Square isn’t some outlier. In April 2025, Adyen, which processes payments for companies like Uber and eBay, got hit by three waves of DDoS traffic in one evening, and its European checkout services threw errors and delays until the early hours of the next morning. If processors that size have bad nights, yours will too.
The full blackouts make the news. The partial ones usually don’t, and honestly they can be worse. A processor that’s slow, or suddenly approving far fewer transactions than usual, won’t always post a scary status update. Your checkout just converts a little less, and you find out from the weekly report.
That slow bleed is the scenario most payment routing setups are least prepared for.
What Failover Actually Does in the Moment
Strip away the jargon and it’s simple. You have more than one payment service provider connected. Something watches how each one is performing. When one starts failing, traffic moves to another.
The “something watching” is where it gets interesting. Good setups track error rates, timeouts, response times and authorization rates, not just whether a provider’s API answers at all. And they act on two levels. A single payment that times out can be retried through a second provider before the customer ever sees an error. Separately, once a provider crosses a failure threshold, new payments stop going there until it recovers.
That second part is what separates real failover from a glorified retry button. Payment routing that reacts one transaction at a time but keeps sending fresh traffic into a broken processor just burns time, and patience.
The Prep Work Nobody Puts on the Slide
Plenty of payment routing setups look great on an architecture diagram and fall apart on the night they’re actually needed. Usually it’s the boring stuff.
Your backup provider has to be live, not just signed. A PSP that has never processed real traffic is a guess. Some teams send it a small, steady slice of payments all year for exactly this reason.
Saved cards are the real trap. If customer card details sit in one processor’s vault, those tokens often can’t be used anywhere else, so returning shoppers and subscription renewals get stuck even with a backup in place. Network tokens or a processor-independent vault solve this (but only if you set them up before you need them).
Then there’s the small stuff that breaks at 2 a.m.: 3D Secure configured on both providers, fraud rules that don’t block a rerouted payment as suspicious, and idempotency keys so a retried charge can’t hit the same card twice. You won’t see any of this in a vendor demo, yet it’s usually what decides whether failover holds up.
Single Provider vs. Failover-Ready, When Things Break
Here’s roughly how the two setups behave once a processor starts failing:
| Moment | Single-PSP setup | Failover-ready setup |
| First failed payments | Customers see errors and many leave | Timed-out payments retried on a second PSP |
| The next 30 minutes | Team scrambles and refreshes status pages | Traffic shifts automatically once thresholds trip |
| Returning customers | Saved cards may be unusable | Portable tokens let saved cards run elsewhere |
| Partial slowdown | Often unnoticed for hours | Caught by success-rate and latency monitoring |
| Recovery | Manual switch back, if anyone remembers | Traffic returns gradually as health improves |
Conclusion
If you run on one processor today, don’t try to build everything at once. Get a second provider live and push a little real traffic through it. Sort out where your saved cards live. Then set your thresholds and test the switch on a quiet Tuesday, on purpose, before an outage tests it for you.
For a broader look at the strategies underneath all this, from fixed rules to real-time decisions, this explainer on how payment routing works is a useful primer.
Failover won’t stop processors from having bad nights. What good payment routing changes is who has to deal with it, your customers at checkout or your team in the incident log the next morning
