Your internet will go down during service eventually. What happens next depends on how your POS was built — here’s what offline mode really covers, and how to test it before an outage tests it for you.
July 11, 2026
Every restaurant eventually faces a connectivity interruption. What remains usable depends on the device, its preparation, enabled workflows and the payment processor. This guide separates cash order continuity from card acceptance and shows how to ask for evidence instead of relying on a broad “offline” label. Novaryq’s current boundary is explicit: on a supported, prepared terminal with the Beta offline-cash workflow enabled, cash order entry can continue during a connectivity interruption. Card payments require connectivity.
A cloud POS keeps its brain on remote servers — menus, orders, payments and reporting all live in the cloud, and the terminal talks to them constantly. That design is why you can update a menu from your laptop and watch sales from your phone, and on a good day it is strictly better than the on-premise systems it replaced. The question is what the terminal can still do on its own when the connection drops. Some platforms keep a full local copy of the menu and the day’s open orders on the device, so service continues and everything syncs when the internet returns. Others treat the terminal as a thin window into the server: lose the connection and you lose some or all of the register. Vendors describe both of these as “offline mode,” which is why the phrase alone tells you almost nothing.
“Offline-first” and “offline mode” are marketing labels, not acceptance criteria. Ask which device was prepared, which workflow was enabled, which actions were tested, how persistence failures appear, and what happens after reconnect. A useful evaluation separates each capability:
Some processor-certified systems offer deferred card authorization, which can create later-decline and loss-allocation risk. Ask the processor to document certification, transaction and cumulative limits, expiry, retry behavior and who bears a failed authorization. Novaryq does not currently offer offline card acceptance; card payments require connectivity.
Internet-dependent channels cannot be assumed to continue. New online orders, marketplace intake, cloud reporting, loyalty lookups and gift-card balance checks may be unavailable. Kitchen routing, printing and multi-terminal coordination each need their own proof. Do not infer them from a cash-entry capability.
| Capability | Question for any vendor | Novaryq current boundary |
|---|---|---|
| Cash order entry | Which prepared devices and enabled workflows were tested? | Beta; supported, prepared terminal with the workflow enabled |
| Card payments | Which processor certification and risk limits apply? | Connectivity required |
| Kitchen tickets and KDS | Is outage routing proven separately? | Do not infer from offline cash |
| New online orders | What happens while the guest channel is unreachable? | Internet-dependent |
| Reconnect | How are replay conflicts and cash variances reviewed? | Manager review may be required |
Ask the vendor to prepare the supported terminal exactly as production requires, disconnect connectivity and run only the actions it claims are supported. For Novaryq, enable the Beta offline-cash workflow, record a cash order, interrupt and reload the app, reconnect, then verify the server outcome and any manager-review state. Confirm separately that card payment is blocked while disconnected. Kitchen, printer and multi-terminal behavior require their own tests.
Novaryq treats offline cash as a Beta capability. On a supported, prepared terminal with the offline-cash workflow enabled, cash order entry can continue during a connectivity interruption. Card payments require connectivity. The enabled native Android offline-cash workflow uses encrypted local storage and attempts replay after reconnect; conflicts and cash variances may require manager review. Browser/PWA, kiosk, kitchen routing and printer continuity are not implied by this statement.
Some functions can, but the boundary must name the device, preparation, enablement and tender. On a supported, prepared terminal with the offline-cash workflow enabled, cash order entry can continue during a connectivity interruption. Card payments require connectivity.
Not on Novaryq — card payments require connectivity. Some processor-certified systems offer deferred authorization, which creates later-decline and loss-allocation risk; require written certification and risk limits from the processor before relying on it.
The labels are not enough to compare systems. Ask which supported device is prepared, which workflow is enabled, which tender is allowed, how persistence failures surface and how replay conflicts are reviewed.
New online orders depend on the guest’s internet path and cannot be assumed to arrive during an outage. Existing kitchen routing and terminal continuity also need separate proof; the Novaryq offline-cash boundary does not imply those channels.