The short answer
An offline restaurant POS can take orders, send them to the kitchen and complete cash sales with no internet connection, because the software and the menu run on hardware inside the restaurant rather than in a data centre. When the connection returns, queued orders sync to the cloud without being lost or duplicated.
Offline mode is not offline-first
This is the distinction that decides what actually happens at 7:30 on a Friday.
- Offline mode. A cloud POS caches some data in the browser or app and lets you keep ringing sales for a while. The kitchen display often cannot be reached, the full menu may not be available, discounts and lookups fail, and reconciliation afterwards is manual. It is a lifeboat, and it is sold as a feature.
- Offline-first. The store holds the authoritative copy of the menu and the order queue while service is running. Stations talk to local hardware by design, and the cloud is a downstream consumer of what the store already decided. Losing the connection changes nothing about how orders flow, because nothing in the order path ever depended on it.
The tell is architectural, not marketing: ask what the kitchen display talks to. If the answer involves the internet, the system is a cloud POS with a lifeboat.
How does an offline POS work?
The mechanism is called store-and-forward, and it has four parts.
- A local device holds the data. A small hub, server or dedicated station inside the restaurant stores the menu and a durable queue of orders — durable meaning written to disk, so a power cut does not erase the evening.
- Stations talk to it over the LAN. Counter, kiosk, kitchen display and printers reach the hub over your own network, which keeps working when the connection to the world does not.
- Orders get an identifier minted locally. Each order is stamped with a unique id created in the store, before any cloud system sees it.
- Sync replays the queue. When connectivity returns, the hub forwards queued orders. Because the id was minted locally, the cloud recognises a repeat as the same order rather than a new one — so a flaky connection that causes three delivery attempts still results in exactly one order.
That last point is where most implementations actually fail. Queuing orders is easy. Replaying them exactly once across an unreliable connection is the hard part, and it is worth asking a vendor to explain how they do it.
What cannot work offline, whatever anyone claims
- Card payments. Authorising a card means reaching the issuing bank. No POS can do that without a connection. Some systems offer store-and-forward card capture, which is not the same thing — it defers the authorisation and you carry the risk of a decline after the guest has left.
- New orders from outside the building — delivery apps, your web storefront, off-site QR scans. They travel over the internet by definition.
- Anything cloud-side: AI features, cross-site reporting, back-office menu edits.
A vendor who claims card payments work offline is describing deferred capture. Ask who absorbs a decline.
Does your restaurant need it?
Weigh two things: how reliable your connection genuinely is — not how reliable you assume it is — and what an hour of stopped service costs during your busiest window.
It matters most for older buildings and shared retail connections, food courts and malls with contended links, event and festival trading, single-provider areas where an outage takes the whole street, and any operation where the busiest two hours pay for the week.
It matters less for restaurants with genuinely redundant business connectivity and low peak concentration — though redundancy costs more per month than most people expect once you price a second provider.
Where ThaliPOS fits: ThaliPOS is offline-first in the second sense above, and verifies it with an automated test on every release that severs the connection, drives orders through the store and asserts that each one reaches the cloud exactly once. How ThaliPOS implements it →