When You Can't Take Payments: Planning for the Outage

The terminal says "cannot connect" and there are six people in line. What happens next is decided in about ninety seconds, usually by whoever is standing there, usually without a plan. The right response depends entirely on which layer failed — your internet, your device, your gateway, or your processor — because a fallback that shares the broken layer isn't a fallback. And the option most terminals offer by default, accepting cards without authorization, is a decision to lend to strangers made by a machine on your behalf. Worth understanding before it happens rather than during.

Four layers, four failures

Layer	Symptom	Who fixes it	Typical duration
Your connection	Everything network-dependent is down	You	Minutes to hours
Your device	One terminal affected, others fine	You	Minutes
Your gateway or software	Payments fail, internet works	Provider	Minutes to hours
Your processor	Payments fail everywhere, others report it too	Nobody you can call	Unpredictable

The distinction that matters operationally: the first two you can fix and the last two you can't. Which means the response is entirely different — for your own failures, fix them; for provider failures, switch to something that doesn't depend on the failed provider, and there's no point waiting.

The layer structure is the one our gateway guide describes, and the reason it matters here is that most businesses' backup plan shares a layer with their primary. A second terminal is useless when the internet is down. A mobile reader from the same provider is useless when that provider is down.

Diagnosing in five minutes

In order, because each test rules out a layer:

1. Does anything else use the internet successfully? Load a page on a device on the same network. If nothing works, it's your connection — go to cellular.
2. Does a second terminal work? If one fails and another succeeds, it's the device.
3. Does a different payment method work? If cards fail and another rail succeeds, the problem is card-specific.
4. Check your provider's status page. Every processor and gateway has one, and it should be bookmarked on a phone before you need it — looking for it during an outage on a network that may be down is exactly the wrong time.
5. Check whether other businesses are affected. A quick call to a neighbouring business establishes whether it's you or everyone.

Five minutes of diagnosis beats thirty minutes of restarting things, and the sequence above is short enough to put on a card by the terminal. Staff who know which question to ask first will handle an outage far better than staff improvising.

What offline mode actually does

The feature most terminals offer and most businesses don't understand.

In offline or store-and-forward mode, the terminal accepts the card, stores the transaction, and submits it when connectivity returns. It cannot check whether the card has funds, is valid, or has been reported lost — because checking is the thing that isn't working.

So what you've done is: delivered goods against a card you couldn't verify, and you find out later whether it was good.

What that means concretely:

• Declines happen after the fact, and the customer has left.
• You bear the loss on anything that doesn't clear.
• Disputes are harder to defend, since the transaction lacks an authorization — and the liability considerations in our channel analysis shift against you.
• Limits apply — terminals cap offline transaction value and count, and exceeding them may mean transactions that simply don't store.
• Fraud is attracted to it. Somebody with a bad card benefits specifically from a merchant who can't check, and outages are visible from the queue.

Which yields a rule worth setting in advance rather than in the moment:

Situation	Offline acceptance
Low value, regular customer	Reasonable
Low value, stranger	Acceptable within a limit
High value, any customer	No — take another method or hold the order
Anything unusual	No

Set the value threshold before an outage and tell staff what it is. A decision made under queue pressure by someone who wasn't told is how businesses take a five-figure offline transaction that never clears.

Fallbacks and what each costs

Fallback	Handles	Cost or risk
Cellular backup on the terminal	Connection failure	Small monthly cost; the highest-return single arrangement
Mobile reader, different provider	Processor or gateway failure	Setup effort; genuinely independent
Payment link or invoice	Terminal failure	Card-not-present pricing and liability
Bank transfer	Card rails specifically	Slow; suits known customers — see our ACH guide
Cash	Everything	Handling and safety, per our cash guide
Offline mode	Short connection failures	You take the risk
Hold the order	Anything	Lost sale, or delayed

Two worth singling out.

Cellular backup is the highest-return arrangement on the list — it costs a small monthly amount, requires no operational change, and handles the most common failure automatically. Most terminals support it and most businesses haven't enabled it.

The payment link is underrated. Sending a customer a link they pay on their own phone works when your terminal doesn't, requires no hardware, and keeps the sale. It costs card-not-present pricing and shifts liability — a real cost, and far smaller than losing the transaction.

What makes a backup real

The test is one question: name what failed, then check whether the backup depends on it.

Backup	Survives connection failure?	Survives processor failure?
Second terminal, same network and provider	No	No
Cellular on same provider	Yes	No
Mobile reader, different provider, cellular	Yes	Yes
Cash	Yes	Yes

The third row is the only card-accepting arrangement that survives both, which is why a mobile reader from a second provider, on cellular, kept charged, is the standard robust fallback. The account can sit dormant; what matters is that it exists and someone knows how to use it.

A note on cost: maintaining a second provider relationship has a fixed cost, which per our effective rate guide matters more at low volume. For a small business the cellular backup plus payment links may be the right level of resilience, and a second provider may not be worth it. The decision should be made by comparing the monthly cost against an hour of revenue, which is usually a short calculation.

Telling customers

The cheapest thing on this list and the most frequently skipped.

What works:

• Say what's happening immediately — "our card system is down, we can take cash or send you a payment link" beats silence and visible fumbling.
• Offer the alternative in the same sentence, so the customer hears a solution rather than a problem.
• Put a sign up if it's lasting, so people entering know before they've shopped.
• Post it online for anything extended.
• For orders already placed, contact people rather than letting them discover a failure.

The reason this matters more than it seems: most of an outage's cost is abandoned sales, not lost transactions — customers who left rather than customers whose payment failed. A clear explanation with an alternative converts a large share of those, and it's free.

What doesn't work: pretending it's brief when it isn't, and letting customers wait without information.

Where the losses actually happen

The part that costs money, and it happens after the outage rather than during it.

What has to be checked once service returns:

1. Every stored offline transaction — did it submit, and did it clear? Declines here are your loss and they don't announce themselves.
2. Every manually recorded transaction — was it entered, correctly, once?
3. Every fallback-system transaction, which won't appear in your primary system's records at all.
4. Duplicates, from transactions attempted more than once during confusion.
5. The sales record against the settlement record, for the whole outage period.

The failure mode: an outage produces transactions in three places — the primary system, the fallback system, and on paper — and nobody combines them. The reconciliation process in our reconciliation guide assumes one source, so an outage day needs a deliberate manual pass.

Which produces one operational instruction worth more than the rest: write down every transaction taken during an outage, on paper, as it happens — amount, method, and a customer identifier. It takes seconds per sale and it's the only record that survives every failure mode. Businesses that skip it spend days afterward trying to establish what they sold.

What to arrange in advance

1. Enable cellular backup on your terminal.
2. Set up a second provider's mobile reader, if volume justifies it, and keep it charged.
3. Bookmark your provider's status page on a phone.
4. Set an offline acceptance threshold and tell staff.
5. Keep a paper log by each terminal, with a pen that works.
6. Write a one-page procedure: the five diagnostic questions, the fallback order, the offline threshold, and who to call.
7. Practise it once. Unplug the internet during a quiet period and see what staff do — the same holdout logic our measurement analysis applies elsewhere, and the only way to find out whether a plan works.
8. Keep some cash capability, even if you're mostly cashless.
9. Know your provider's support number and hours.
10. Check your agreement for what it says about outages and any credits.

Items one and five cost almost nothing and cover the majority of real incidents. Item seven is the one that reveals whether any of the rest works, and it's the one nobody does.

Frequently asked questions

---

This guide is educational and does not constitute financial or legal advice. Offline acceptance limits, liability allocation for unauthorized transactions, and dispute rights are governed by card network rules and your processing agreement, and vary. Review your own agreement and confirm current terms with your provider.