Store-and-forward: taking cards when the internet drops

Store-and-forward is a terminal mode that captures a card sale while the connection is down, holds it locally, and submits it once the link returns. The customer walks out with their goods and a receipt. What they do not get, and what your cashier does not get either, is an authorization — because there was nothing to authorize against.

That gap is the entire subject. Store-and-forward is not a way to process cards offline; it is a way to take a risk offline and settle it later.

What happens to a sale held in the terminal?

It sits in local storage until the terminal reconnects, then goes out for authorization like any other transaction. Most of them approve, because most cards are fine. The ones that do not approve are yours, and by then the customer is long gone with the merchandise.

Terminals typically cap how much can be held this way, both per transaction and in total, because the ceiling is the only real control. Find out what your caps are before you need them rather than during an outage.

When is it worth turning on?

When the alternative is refusing every card sale. A store that loses connectivity for twenty minutes on a Saturday afternoon and turns away forty customers has lost more than it would plausibly lose to a handful of declined offline sales.

When it is not worth it: high-ticket sales, unfamiliar customers, and any category that attracts fraud. The sensible configuration is a low per-transaction cap — enough to keep the coffee-and-sandwich trade moving, not enough to hand someone a case of cigarettes on a card that was cancelled last week.

Does an offline sale carry the same protections?

No, and this is the part most owners are never told. A transaction authorized after the fact does not carry the assurances of one authorized in the moment, and fraud losses on sales taken this way generally land on the merchant. The mechanics of EMV do give an offline chip transaction more evidence than a keyed one, but evidence is not the same as an approval.

Treat every offline sale as an extension of credit you decided to grant. That framing gets the caps set correctly.

What should the counter routine be during an outage?

Three rules, written down before the outage rather than during it. Cards under the cap go through offline. Anything above the cap is cash, or the customer comes back. And somebody watches the terminal for the reconnect and checks what came back declined.

That third rule is the one that gets skipped, and it is the only one that lets you act while the customer is still findable. A declined offline sale discovered three days later at statement time is a write-off; the same decline caught an hour later is sometimes a phone call.

What is the better fix?

Not losing the connection. A terminal with a cellular fallback, or a second internet path at the counter, removes the need to gamble at all. Store-and-forward is an emergency measure that has quietly become a permanent workaround in a lot of stores, which is how a risk control turns into a risk.

If your terminal drops out weekly, the answer is not a bigger offline cap. It is the connection, and that is usually a cheaper problem to solve than owners assume.

There is a bookkeeping consequence too. Offline sales settle on the day they are submitted rather than the day they were rung, so an outage that spans a batch close pushes revenue into the following day's deposit. A store reconciling a register day against a bank day will see a gap that looks like a shortage and is not.