Readiness and continuation: keeping payments running when systems fail

Every payment system fails at some point. A network link drops. A data center loses power. An issuer goes offline. Someone attacks the system.

The failure itself is not the real problem. The real problem is not knowing what happens next.

We split this work into two parts. Readiness is what you prepare before a failure. Continuation is what you do during and after it.

Readiness: decide the fallback before you need it

Readiness means every failure already has an answer. You don’t design the fallback during the outage. You design it now, test it, and write it down.

Start with three questions for each part of the system:

What happens if this part stops?
Who carries the risk while it’s down?
How do we know it has stopped?

Card payments have well-known fallbacks. Each one moves the risk to a different party. That’s the part people often get wrong.

Fallback 1: offline approval by the chip

A chip card can approve a payment on its own when the terminal can’t reach the network.

This only works under limits. The terminal has a floor limit. The card has its own offline limits, set by the issuer. If the amount is under both, the chip can approve it and create a cryptogram that proves it.

When this is done by the scheme rules, the issuer generally carries the liability. The issuer set the card’s limits, so the issuer owns that decision.

Above the limits, the card declines offline. The terminal can then fall back to a deferred authorization.

Fallback 2: stand-in processing by the network

Sometimes the merchant side is fine and the issuer is the one that’s down.

Card networks handle this with stand-in processing (STIP). The network approves or declines on the issuer’s behalf, using rules the issuer set in advance. When the issuer comes back, the network passes the decisions on.

The issuer carries the result. It must settle the transactions that stand-in approved. So the issuer’s stand-in rules are a real risk decision, not a default setting to leave alone.

Fallback 3: deferred authorization (store and forward)

The terminal or gateway can store the payment and send it for authorization later, once the connection is back.

This keeps the queue moving. But nothing has approved the payment yet. If the issuer declines it later, someone takes the loss.

That risk usually sits on the acceptance side. That means the merchant, unless the acquirer or processor has agreed to carry it in their contract. Check the contract, because this varies.

Deferred authorizations must be flagged as deferred in the message. Visa and Mastercard both require this. They also expect them to be sent within a short window after the sale.

Put limits on every fallback

A fallback without limits is just an open door. Fraudsters know when systems are down, and they test them.

Set clear limits:

A maximum amount per offline or deferred payment
A maximum total held at one terminal or store
A maximum time before stored payments must be sent
Card types or merchant categories that never get the fallback

Then watch those limits. An alert should fire long before you reach them.

Continuation: the plan after the outage starts

Continuation is about getting back to normal safely. It has its own steps.

Detect it fast. Monitor real payment success rates, not only whether servers respond. A server can be up while every payment fails.
Switch on purpose. Move to the fallback with a clear decision and a clear owner. Don’t let half the system fall back and half keep retrying.
Tell people. Merchants, support staff and partners need to know what is working and what isn’t.
Recover in order. When the link comes back, send stored payments in a controlled flow. A sudden flood can take the system down again.
Reconcile. Match every stored, offline and stand-in payment against what settled. Chase the declines.
Review. Write down what happened, how long it took, and what to change.

Build the system so outages are smaller

The best fallback is the one you rarely need. A resilient design keeps failures small and short.

Run in more than one place. Two regions or data centers that can each take the full load. Test the switch, not just the setup.
Make every request safe to repeat. Use an idempotency key, so a retried payment never charges twice.
Fail fast. Use timeouts and circuit breakers, so one slow dependency can’t freeze everything behind it.
Queue what can wait. Settlement files, receipts and notifications don’t need to block the payment itself.
Know your targets. Agree how long each service may be down (the recovery time objective) and how much data you can lose (the recovery point objective). Design to those numbers.
Practice failure. Switch off a dependency on purpose, in a controlled test. Find the weak spot before an attacker or an outage does.

In the EU, this is also a legal duty for most financial firms. The Digital Operational Resilience Act (DORA) has applied since January 2025. It asks for tested continuity plans, incident reporting and resilience testing.

Where to start

Pick one critical payment flow. List what it depends on. For each dependency, write the fallback, its limits, and who carries the risk.

Then test one of them. That single test usually teaches more than the whole document.

Sources

Scheme rules change and differ by region. Check the current rulebooks and your own contracts before you set any limit.