What happens to your POS when the internet goes down — vendor by vendor

It's 7:40 on a Friday night, every table is sat, and the internet drops. What happens in the next sixty seconds depends entirely on decisions you made months earlier — which platform you bought, how your network was wired, and whether anyone ever read the offline-mode documentation before they needed it.

I've lived this twice as an operator: once during a neighborhood fiber cut, once during a vendor's own cloud outage. Two different failures, two very different nights. This post is the breakdown I wish someone had handed me before the first one — what "offline mode" actually means, how the major platforms behave with the cord cut, and who carries the risk on every card you swipe in the dark.

First, know which outage you're having

Operators say "the internet is down" about two unrelated failures, and the distinction matters more than any feature list:

1. Your connection is down. The ISP, your router, a backhoe down the street. Your building is offline; the vendor's cloud is fine. This is the failure offline modes are designed for, and the one you can engineer around with backup connectivity.
2. The platform is down. Your internet works; the system doesn't. These are rarer but real, and no LTE failover helps: Square's DNS misconfiguration in September 2023 took merchants offline for the better part of a day. A ransomware attack on NCR's data center in April 2023 knocked out Aloha's cloud back-office services for weeks. The AWS us-east-1 outage in October 2025 degraded a long list of dependent platforms — trade press documented restaurants keying card numbers by hand while their cloud POS struggled. The CrowdStrike update failure in July 2024 crashed payment systems across whole industries in a morning.

The first failure tests your POS's offline mode. The second tests your vendor's architecture — and your contract's uptime clause, which is one of the red flags worth reading before you sign.

What "offline mode" actually has to cover

A restaurant POS does four jobs during service, and each degrades differently offline:

• Order entry. Can terminals and handhelds keep ringing? This is pure software design: systems that cache locally keep working; systems that phone home on every action freeze.
• Kitchen routing and printing. Printers and a kitchen display sit on your local network. If orders route locally, tickets keep flowing with no internet at all. If they route through the cloud, your expo station goes dark even though the printer is ten feet from the terminal.
• Card payments. The genuinely hard part. With no path to the card networks, the terminal can't get an authorization — so systems fall back to store-and-forward: encrypt the card data, approve the sale on the spot, and submit for real authorization after reconnecting.
• Everything else. Online ordering, gift cards, loyalty lookups, reporting, clock-outs — cloud features that simply pause on every platform until connectivity returns.

Store-and-forward deserves one more sentence, because vendors say it quietly and operators discover it loudly: a stored payment is not an authorized payment. If the card declines when it's finally submitted — insufficient funds, canceled card, expired authorization — that's your loss, not the vendor's. The documentation is unambiguous across the industry. Toast: "You are responsible for any declined, expired, or disputed offline payment transactions." Square: "You're responsible for any expired, declined, or disputed payments accepted while taking offline payments." Every serious platform carries an equivalent line.

Vendor by vendor: what their own docs say

What follows comes from each vendor's published documentation, not from sales decks. Verify against your own contract — configurations vary.

Toast

Toast devices drop into Offline Mode after roughly forty seconds without connectivity. With background card processing enabled, you can keep taking orders, accepting card payments with tips, printing, and opening cash drawers — provided your Ethernet stays connected. Hardwired kitchen displays keep receiving tickets if the local network holds. What stops: gift cards, loyalty, online ordering, menu edits, and closing out shifts. Stored payments submit automatically on reconnect, but Toast warns that some card networks expire authorizations in as little as 24 hours and recommends getting back online within a day, three at the outside — and it recommends a cellular backup solution for exactly that reason. More context in our Toast review.

Square

Square's offline payments are now enabled by default (as of April 2026) and the windows depend on hardware: current docs give you 24–72 hours to take and upload offline payments depending on the device, with a hard 72-hour expiry — expired offline payments "cannot be retrieved or reprocessed." You set your own per-transaction cap. Chip and tap work offline; manually keyed cards, gift cards, and Tap to Pay on phones don't. Our Square review covers where the platform fits overall.

Clover

Clover Mini and Flex take offline payments for up to seven days by default — the longest window in the group — with merchant-configured guardrails: a per-transaction cap, a total stored-amount cap per device, and an approval threshold. Clover's developer docs are refreshingly direct that looser settings equal more risk you're choosing to accept.

Lightspeed Restaurant

Lightspeed's lines differ. The base cloud product keeps core selling working offline with locally cached data, but integrated card authorization needs connectivity — the documented fallbacks are "standalone mode" on the payment terminal (payments processed outside the POS, reconciled separately) or, on some product lines, an optional local server appliance that mirrors the cloud for essential functions. If you're evaluating Lightspeed, make the rep demonstrate the exact line you'd be buying.

TouchBistro

TouchBistro is the architectural outlier: multi-iPad installs run off a local Mac server in the building, so most operations need only local Wi-Fi — internet is required for card processing, cloud reporting, and emailed receipts. That hybrid design is genuinely resilient against ISP outages; the trade-off is that you're now also maintaining an on-site server.

SpotOn

SpotOn's offline mode keeps stations, handhelds, and kitchen screens talking over the local network, stores payments for automatic sync, and — notably — ships a 4G backup router with its restaurant package, which addresses the most common outage before offline mode is even needed. Online orders stop reaching the kitchen during an outage, so pause your channels.

Legacy on-premise (Aloha, Oracle Micros)

The old client-server systems keep their entire database in the building, so a WAN outage barely touches core function — terminals keep ringing, tickets keep printing, and Oracle's Simphony even ships an on-premise posting service so workstations are "largely unaffected" by cloud disconnection. Card authorization still needs a path out, and as the 2023 NCR incident showed, the cloud back-office half of these "on-prem" systems is just as outage-prone as anyone else's. On-prem is not a free lunch; it's a different lunch.

The setup that actually saves the night

Across every platform, the operators who shrug off outages have the same four things in place — none of them expensive:

1. Wired, single-subnet local network. Printers, KDS, and terminals on Ethernet, one subnet. Most "offline mode failed us" stories are actually "our Wi-Fi mesh segmented the network" stories — Toast's own docs warn that multiple subnets can break offline kitchen routing.
2. Cellular failover. An LTE/5G backup router turns the most common outage into a non-event for a modest monthly cost. The math is unforgiving: weigh that subscription against one Friday of card volume you couldn't capture, or captured and lost to expired authorizations.
3. A written outage drill. Who pauses online ordering, who checks the vendor status page, what the per-card offline cap is, and the one rule staff reliably violate under stress: don't restart the router — you may sever the local network your offline mode is running on.
4. An offline payment policy you chose on purpose. Caps and approval thresholds are configurable on every major platform. Decide deliberately how much store-and-forward exposure you'll accept per card and per night, the same way you'd set a comp budget.

If you run a concept where connectivity is structurally unreliable — festivals, stadium lots, anywhere a food truck parks — offline behavior stops being a contingency feature and becomes the purchase decision, a point I made in the business-type buyer's guide a few days ago.

Where Katalyst stands

Disclosure, as always: I work here — so here is our own answer to the Friday-at-7:40 question, stated the same way I'd demand it from any vendor above. When the connection drops, Katalyst keeps taking card payments in store-and-forward mode: swipe the card at the terminal, or key the number in manually if you have to, and the encrypted payment data queues locally on the device. When connectivity returns, the queue submits automatically and the payments process — reconciliation happens on its own, with no re-keying at close.

And the same honesty applies to us as to everyone else in this post: store-and-forward is store-and-forward. Until a queued payment clears, the decline risk sits with the house, and manually keyed entries carry more of it than swiped ones — so set your offline caps deliberately and get back online fast, same as you would on any platform. The difference I'll claim is that we put this behavior in writing before you buy, which is the standard I'd hold any vendor to: not "do you have offline mode?" but "walk me through Friday at 7:40pm, step by step, and show me where the risk sits." If you want that walkthrough on your own menu and your own floor plan, book it here — bring your worst outage story.

Related Katalyst products

• See Katalyst Flex POS