Payment gateway fallbacks — what happens when Stripe has a bad day
Every PSP has downtime. Real payment resilience is not a monitoring dashboard — it is an automated fallback path wired into your checkout before you need it.
Every Payment Service Provider has bad days. Stripe has them. Razorpay has them. Tap, HyperPay, and Braintree have them. The question is not whether your PSP will fail — it is whether your checkout is still processing revenue when it does.
On every commerce project I ship, the checkout is designed around at least one automated fallback. Below is the pattern that has held up in production across four continents.
Design the checkout around the payment intent, not the PSP
The checkout page never talks to Stripe or Razorpay directly. It talks to a Payment Intent service inside your Node application. That service picks the PSP at runtime based on health-check state, currency, and country — and it is the only code that knows which PSP is live at any given moment.
Health checks — synthetic and real
Two probes run continuously. A synthetic probe posts a $0 authorisation to each configured PSP every 60 seconds and measures round-trip latency plus error rate. A real-user probe tracks the last two hundred checkout attempts and calculates the observed error rate per PSP. When either crosses a threshold, the routing table flips.
Idempotency is not optional
Every payment attempt carries a client-generated idempotency key derived from the cart hash. If the same request lands twice — network retry, browser back button, distributed timer — we return the original outcome, never charge twice. This is one of those things that seems obvious until you find a production bug where a customer was charged three times for the same order at 2 AM local time.
The fallback is a first-class code path, not a hack
Most teams that "have a fallback" have a
try/catch block that logs an error and shows a
generic failure page. That is not a fallback — that is a
placebo. A real fallback rewrites the client-side confirmation
step to use the secondary PSP, moves the cart into a
recoverable state, and either retries transparently or hands
the user a "Try again" button that hits the secondary PSP on
the very next click.
Reconciliation runs nightly, not never
A background job pulls settlements from every configured PSP each night and reconciles them against the orders table. Discrepancies get a Slack alert with the specific order IDs. Six years in, this is the single most useful backend service I wire up on commerce projects.
What this costs
Multi-PSP resilience is not free. You need contracts with two providers, KYC in two dashboards, and a settlement flow that handles two payout schedules. For most stores turning over under a million dollars a year, the cost outweighs the benefit. Above that, one bad Black Friday afternoon on a single PSP more than pays for the whole architecture.