--- title: "Offline POS Explained: What Working Offline Really Means | GoSufra" description: "Offline mode is easy to claim and hard to build. Here is what a till must keep doing without internet, what it cannot do, and how the queue catches up safely afterwards." url: "https://gosufra.com/en/blog/how-offline-mode-works/" language: "en" source: "https://gosufra.com" --- # What "works offline" actually means for a restaurant POS Offline mode is easy to claim and hard to build. Here is what a till must keep doing without internet, what it cannot do, and how the queue catches up safely afterwards. 2026-08-30 · 7 min read ![Illustration of a till still selling while the cloud link is cut](https://gosufra.com/blog/how-offline-mode-works.svg) ## Key points - The test is not whether the app opens offline. It is whether the queue lands correctly afterwards. - Every offline action carries its own id, so a retry can never create the order twice. - Some things genuinely cannot work offline — a card gateway is one. A good system says so. - Ask any vendor what happens when two tills go offline and both sell the last five portions. Every cloud POS says it works offline. Very few explain what that sentence covers, and the gap between the claim and the behaviour is only discovered on the worst evening of the year. ## Offline is a queue problem, not a screen problem Any app can cache a menu and render a screen without a connection. That is the easy half. The hard half is what happens to the twenty orders, four refunds and one closed shift that were created while the line was down. Those are not screens. They are **facts that other people’s numbers depend on** — stock, the kitchen, the books, the cashier’s drawer. Getting them back in the right order, exactly once, is the whole engineering problem. ## What the till must keep doing Without internet, a POS still has to: - Open a shift and take an opening float. - Show the full menu, with prices, modifiers, variants and combos. - Take orders, hold them, split bills, apply discounts and promo codes. - Take **cash** payment and print a receipt on a locally connected printer. - Void and refund with the same approval rules as normal. - Keep counting the drawer so the close still balances. That is a working restaurant. Nothing on that list needs a server to be true. ## What genuinely cannot work Honesty here is a feature, not a weakness: - **Card and online payments.** A gateway authorisation needs the gateway. You take cash, or you take the card when the line returns. - **Live cross-branch views.** Another branch’s stock is a fact that lives on the server. - **Anything a second device must see instantly.** A kitchen screen on the same local network can still be served, but a phone on mobile data cannot be told about a ticket by a till with no uplink. A system that claims all of this works offline is either wrong or redefining “offline”. ## How the catch-up is made safe When the connection returns, the device does not simply resend. Each action was written locally as an immutable record the moment it happened, carrying: | Field | Why it exists | | --- | --- | | `clientActionId` | A UUID minted on the device — the action’s identity | | `deviceId` | Which till created it | | `actionType` | Order created, payment taken, shift closed… | | `payloadJson` | The full action, frozen at the time it happened | | `localCreatedAt` | Used to replay actions in the order they really occurred | The server stores these with a **unique key on (deviceId, clientActionId)**. If the same action arrives twice — flaky wifi, an app restart, an impatient retry — the second one is recognised and the original result is returned instead of creating a second order. Payments carry an idempotency key for the same reason: a retry can never charge twice. Retries back off gradually rather than hammering the connection, and anything that still fails after the retry threshold is dead-lettered where a manager can see and resolve it, instead of silently disappearing. ## When two tills disagree This is the question worth asking any vendor. Two tills go offline. Both sell the last five portions of the special. Both come back at once. There is no magic answer — the portions do not exist. What matters is that the system is **deterministic** about it and tells you: - Stock that would go negative is rejected with an actionable error rather than quietly accepted. - Order status only moves along valid transitions, so a “served” ticket cannot be reopened by a late arrival. - A payment larger than the order total is rejected. - Table state takes the server’s authoritative version, because two people cannot be sitting at table 6. You will still have to comp a dish. But you will know, at the moment it lands, instead of finding a negative stock line three weeks later. ## The one-minute test Before you sign with anyone, do this in the demo: put the tablet in flight mode, take four orders, refund one, close the shift, then turn the connection back on. Then check three screens — stock, the kitchen history and the day’s sales — and see whether all four orders are there, once each, in the right order, with the refund reversed. That test takes a minute and tells you more than any feature list. - offline POS - restaurant POS software - POS sync - cloud POS ## In the product ### [Point of Sale & Orders](https://gosufra.com/en/features/restaurant-pos/) Explore ## Run all of this from one system POS, kitchen, inventory, recipe costing, staff and accounting — connected, and free to start. [Create your free account](https://app.gosufra.com/register?lang=en) ## Related articles ![Illustration of stacked screens sharing one system](https://gosufra.com/blog/what-is-a-restaurant-operating-system.svg) How it works 2026-09-01 · 8 min read ### [What a restaurant operating system is — and why a POS is only part of one](https://gosufra.com/en/blog/what-is-a-restaurant-operating-system/) A POS records the sale. A restaurant operating system records the sale and everything the sale sets in motion: the kitchen ticket, the stock, the plate cost, the wage and the journal entry. Read article ![Illustration of a signal reaching a kitchen screen and a phone at once](https://gosufra.com/blog/real-time-updates-and-notifications.svg) How it works 2026-08-10 · 7 min read ### [Real time, actually: how orders move without anyone refreshing](https://gosufra.com/en/blog/real-time-updates-and-notifications/) What a live push is, how a ticket reaches the kitchen and the driver without a reload, where notifications belong, and how this differs from offline mode. Read article [← All articles](https://gosufra.com/en/blog/) [Contact us](https://t.me/GoSufraSupport)