When your payment gateway goes down: how to detect and respond before you lose a single sale

A payment gateway outage is one of the few failures that costs you money every single minute it goes undetected. Your site loads fine. Product pages look normal. Customers add items to their carts, reach checkout, and hit a wall: a spinning button, a cryptic error, or a silent failure that just refreshes the page. They leave. Most don't email you. They just buy from someone else.

The cruel part is that everything upstream of checkout looks healthy. Your analytics show traffic. Your site monitor shows green. The only signal that something is wrong is the thing nobody watches in real time: whether orders are actually completing.

Why gateway failures hide in plain sight

Payment processing involves more moving parts than most store owners realize. Your storefront talks to your platform (Shopify, WooCommerce, or BigCommerce), which talks to a payment gateway (Stripe, PayPal, Authorize.net, or a platform-native processor), which talks to card networks and banks. A failure at any link in that chain can block checkout while leaving the rest of your store untouched.

Common causes include expired API credentials, a gateway provider's own outage, a plugin or app update that breaks the checkout integration, SSL or certificate issues on the payment page, rate limiting from unusual traffic patterns, or a silent API change on the processor's end that nobody on your team was notified about. That last scenario is common enough that it deserves its own playbook; see your payment processor changed its API and nobody told you for how those updates sneak past store owners.

The common thread: none of these failures take your site down. A standard uptime monitor that pings your homepage will report everything is fine while your checkout is quietly rejecting every card.

The detection gap: why you find out last

Think about how a typical gateway failure actually gets discovered. A customer tries to buy, fails, maybe tries again, then gives up or emails support. That email sits in a queue. Someone reads it an hour or two later, tries to reproduce the issue, and only then realizes it's affecting everyone, not just one shopper with a weird browser.

By the time you've confirmed the problem, you may have lost three, four, six hours of sales. For a store doing $200,000 a month, that's roughly $280 to $550 in lost revenue per hour at a typical margin, and that's before accounting for the customers who simply never come back.

This is the same blind spot covered in zero orders in an hour: how to tell a slow day from a broken storefront: a drop in orders is ambiguous on its own, but a drop in orders combined with steady traffic is a strong signal that checkout, not demand, is the problem.

Build a detection system that watches the right signal

The fix isn't to check your dashboard more often. It's to monitor the thing that actually matters: whether orders are completing, continuously, without you having to look.

A few practical approaches, roughly in order of effort:

Watch order flow against a baseline. Compare orders in the last hour to your typical volume for that day and time. A sudden drop to zero, especially during normal business hours, is the clearest signal of a checkout failure. This is the core idea behind order-flow monitoring (what Cassian calls Order Pulse): it doesn't guess at causes, it flags the symptom that matters most, missing orders, and lets you investigate from there.

Run synthetic checkout tests. Periodically simulate a test transaction through your actual payment flow, not just a ping to your homepage. This catches gateway errors that only appear at the final step, like a declined-by-default response from a misconfigured API key.

Monitor your gateway provider's status page. Stripe, PayPal, and other processors publish status pages during major incidents, but they won't always catch store-specific misconfigurations like an expired key or a broken webhook.

Set alert thresholds, not just alert existence. An alert that fires after 50 failed transactions is too late. The useful threshold is usually one deviation from your normal pattern, caught within minutes.

What to do in the first ten minutes after you're alerted

Once you know checkout is failing, speed and order of operations matter more than heroics.

First, confirm it's real. Try a test purchase yourself, ideally with a card you know works, and check if the failure is universal or limited to one payment method, device, or region.

Second, check your gateway's status page. If Stripe or PayPal is reporting a known incident, you don't need to debug your own integration, you need to communicate and wait.

Third, check recent changes. Did an app update, theme change, or plugin install happen in the last 24 hours? Checkout breakage often traces back to something that changed recently rather than something that simply broke on its own, a pattern also common with orphaned app code left behind after an uninstall.

Fourth, check API credentials and webhooks. Expired keys and failed webhook deliveries are among the most common root causes of a payment processor failure, and they're usually fixable in minutes once identified.

Fifth, communicate if the outage extends beyond a few minutes. A simple banner acknowledging a temporary checkout issue, with an alternative payment method if you have one, preserves more trust than silence. This is the same principle behind handling shipping rate calculator errors that empty carts at checkout: acknowledge visibly, fix quietly.

Build the playbook before you need it

The stores that recover fastest from a checkout down event aren't the ones with the most technical staff. They're the ones who wrote the plan before the crisis, not during it.

At minimum, document: who gets alerted and how, what the first three diagnostic steps are, who has access to gateway dashboards and API keys, and what the customer-facing message looks like for an outage lasting under 15 minutes versus over an hour. Keep gateway support contacts and account IDs somewhere accessible that doesn't depend on the storefront being up.

It's also worth testing your checkout flow deliberately before high-traffic periods. A load-testing pass before a big sale, similar to the approach in stress-testing your Shopify theme and apps before Black Friday, can surface gateway timeout issues that only appear under volume, well before real customers hit them.

The bottom line

A payment gateway outage is unusual among ecommerce failures because it's invisible to every monitor except the one built to watch it: order flow itself. Your site can be fast, secure, and fully indexed by Google while every checkout attempt quietly fails behind the scenes.

The fix isn't more vigilance from you personally. It's a system that watches order volume continuously and tells you the moment it drops outside normal range, so you hear about the problem before your customers have to tell you themselves.