Payment gateway downtime and the orders you lose

Gateways go down. So do the banks and wallet providers behind them, which means a gateway can be perfectly healthy while one of its payment methods is not.

The reason this is worth planning for is not the outage itself, which is short. It is that your store keeps taking traffic throughout, and every visitor who reaches checkout during it is a sale you paid to acquire and did not complete.

What an outage looks like from the customer's side

Almost never an error message saying the payment system is unavailable.

More often the customer clicks to pay and nothing happens. Or they are redirected to a bank page that does not load. Or the page loads, they authorise, and they are never returned to your store. Or the whole thing simply takes long enough that they give up.

From your side, your store is up. Your monitoring is green. Traffic looks normal. Orders have stopped, and nothing in your dashboard says why.

Partial failures are more common than total ones and considerably harder to spot. One bank unavailable inside FPX, or one wallet failing, while everything else works. Your order count dips by a fraction and looks like a slow afternoon.

The orders that half-happened

Every outage leaves debris, and it lands in the reconciliation rather than in the operations queue.

Payments taken with no order recorded. The charge succeeded at the gateway, the confirmation never got back to your store. The customer has paid and you do not know it — see failed payments and the orders they leave behind.

Orders recorded with no payment taken. The reverse, where an optimistic redirect marked an order paid and the charge never completed.

Duplicate attempts. The customer tried three times because nothing seemed to work. If two succeeded, one needs refunding, and the customer will notice before you do.

Authorisations that were never captured because the capture step failed too, and which quietly expire later.

All four appear in your settlement report and none of them match your sales records cleanly. An outage on a Tuesday is a reconciliation exception queue on the Friday.

Failover is not free

The instinctive answer is a second gateway ready to take over. It works, and it costs more than the switch itself suggests.

A standby gateway means a second onboarding, a second set of credentials, a second fee schedule, a second settlement stream and a second reconciliation — see reconciling two gateways into one bank account. It also means the standby has to be exercised occasionally, because a failover path that has never been tested is a failover path that will not work when needed.

There is a cheaper option that covers most of the risk: payment method diversity through one provider. If cards, FPX and wallets are separate rails inside your existing gateway, an outage in one usually leaves the others working, and the customer has somewhere else to go. That is not protection against the gateway itself failing, but gateway-level outages are rarer than method-level ones — see why your checkout needs more than one payment method.

Full failover earns its cost at high volume, where an hour of lost checkout is measurable in real money. Below that, method diversity plus fast detection is the sensible position.

Detecting it before your customers tell you

The useful signal is not uptime. It is completion.

Watch the checkout completion rate on a short window, not order volume on a daily one. A daily total hides a two-hour outage completely. Completion rate over the last fifteen minutes, compared against the same window last week, surfaces it immediately.

Alert on zero. No successful payments in a period where you normally have several is the single highest-value alert in ecommerce operations, and it is trivial to build.

Watch failure rate by method. A spike on one method is a method-level outage, and it tells you where to look and what to switch off — see Malaysian payment gateways and how they actually differ.

Subscribe to your providers' status pages. Free, and frequently faster than your own detection.

Know who to contact and how, before you need to. During an outage is a bad time to discover that support is a web form.

Reconciling a day with an outage in it

Do not treat it as a normal day, because the exception count will be higher than your process expects and the temptation will be to force the match.

Pull the gateway's own transaction list for the affected window and compare it against your orders in both directions: gateway transactions with no order, and orders with no gateway transaction. Both lists will have entries and both need working through individually.

Refund the duplicates before the customer asks. Contact the customers whose payments succeeded without an order and ship what they bought — that conversation is much easier when you initiate it.

Then record what the outage cost, in completed orders against a normal window. That figure is the only honest input into whether failover is worth paying for, and without it the decision is made on feeling — see settlement timing and your cash forecast.

Common questions

How do you know when a payment gateway is down?

By monitoring checkout completion rate over a short window rather than daily order volume, and alerting when successful payments drop to zero in a period that normally has several. Daily totals hide a multi-hour outage entirely, and your store itself stays up throughout, so nothing in normal uptime monitoring will flag it.

What is a partial payment outage?

One payment method failing while the rest work — a single bank unavailable within FPX, or one wallet provider down — while the gateway itself is healthy. These are more common than total outages and much harder to notice, because the effect is a fractional dip in orders that looks like an ordinary quiet spell.

Do you need a backup payment gateway?

At high volume, where an hour of lost checkout is measurable money, a tested failover path earns its cost. Below that, offering several payment methods through one provider covers most of the risk more cheaply, since method-level outages are considerably more common than gateway-level ones, and a standby gateway brings a second settlement stream to reconcile permanently.

What should you check after an outage?

The gateway's own transaction list for the affected window, compared against your orders in both directions: transactions with no matching order, and orders with no matching transaction. Both lists will have entries after an outage, including duplicate charges from customers who retried, and each needs resolving individually rather than being forced to match.

Related: failed payments and the orders they leave behind · why your checkout needs more than one payment method · running more than one payment gateway