Offline-first POS that works without Wi-Fi.

This is the question to be most careful with, so here is the straight version rather than the marketing one. Taking a card with no connection at all is not the same act as taking a card online, and it should not be sold as if it were. The technique that makes it possible is usually called store-and-forward: the terminal captures the card at the window, holds the transaction on the device, and submits it for authorisation later, once a connection returns. It can keep your line moving when the signal drops — but it carries real risk that lands on you, not on us. Because the card is not authorised at the moment of sale, a payment can be declined when it finally submits: insufficient funds, a blocked or expired card, a fraud flag. By then the customer has their food and is long gone, and that loss, and any chargeback that follows, is yours to wear. Whether store-and-forward is available to you at all depends on your payment processor and the card schemes supporting it, and they often cap the value or the number of offline transactions you can hold precisely because of that risk. Cash is unaffected — it never needed a network — and some contactless flows behave differently again. So the honest answer is: sometimes, conditionally, and with strings attached that are set by your processor rather than by us. Do not treat guaranteed offline card capture as a feature you already have. Take the specifics to our sales team in writing — which processors are supported, what limits apply, and where the settlement risk sits — and decide with your eyes open.

The design of an offline-first till is built to make loss less likely, and it is worth understanding how, but no system can honestly promise you will never lose anything, so we are not going to. Here is the mechanism. As you ring up a sale it is written to storage on the device, not held only in the app's memory, so an order that has been placed has already been saved locally before it is ever sent to the cloud. If the app crashes and reopens, or the tablet reboots, the orders that were already committed to that on-device storage are still there waiting to be synced. That covers the common failures — a frozen app, a flat battery that gets recharged, a device that restarts — and those are the ones that bite most often on a busy service. What it cannot cover is the device itself being destroyed. If a tablet is dropped in a fryer, stolen, run over, or factory-reset before it has had a chance to sync, the orders that lived only on that device and were never uploaded go with it. There is no cloud copy of something that never reached the cloud. So the sensible operating habits are the boring ones. Keep the device charged and carry a way to charge it mid-shift. Get it back into signal to sync at reasonable intervals rather than letting a whole day's takings sit unsynced on one tablet. And do not wipe, reset or trade in a device until you have confirmed everything on it has actually synced. The software reduces the odds of loss; those habits close most of the rest of the gap.

This is a genuine limit of any offline-first system, so it is worth explaining honestly rather than waving at with the word “automatic”. When two devices are both offline, neither one can see what the other is doing. Each keeps its own local record and its own view of stock, and they only find out about each other when they sync. The system handles this with versioning and conflict detection: as offline changes upload, it compares them, works out what happened in what order, and reconciles the two records into one consistent picture — most edits merge cleanly because they simply do not touch the same thing. What it cannot do is rewrite what already happened at the window. If you have one portion of a special left and two terminals, each offline, each sell that last portion to a different customer, the reconciliation on sync will see both sales — but the food is already handed over. The system will flag the conflict and reconcile the count so your records are honest; it will not travel back in time to un-sell one of them. In other words it prevents your data from silently disagreeing with itself, not the physics of two people selling the same last unit while out of contact. The practical guidance follows from that. For genuinely scarce items, keep the trucks or terminals that share that stock in sync as often as you reasonably can, and treat true one-of-a-kind counts with a little manual care during long offline stretches. When the sync does surface a conflict, it is showing you a real event that already occurred so you can settle it — a refund, a substitution, a note — rather than pretending it never happened.

Take the printing part first, because that answer is clean. Kitchen and receipt printing over Bluetooth or USB does not need the internet. The connection between the device and the printer is a direct local link — cable or short-range wireless between two things sitting a foot apart in the same truck — so when a sale is rung up offline, the kitchen ticket still prints and the customer's receipt still prints. That is the point of the workflow shown on this page: the order is created, stored on the device, sent to the printer over that local link, and the receipt and tax are worked out, all without a signal. Nothing in that chain reaches out to a server, so nothing in it depends on one. The broader hardware question — which specific printers, card readers, cash drawers, tablets and mounts are supported, and which combinations are tested and recommended for a truck — is one to put to our sales and implementation team rather than one this page can answer, because it depends on your region, your payment processor and what you already own. Do not buy hardware off the back of this page. Ask sales for the current supported-hardware list in writing, tell them what you are already running, and confirm the specifics before you spend anything — especially the card reader, which has to satisfy your processor as well as fit your setup. And note that card acceptance offline is its own topic, covered in the store-and-forward answer above; a reader working over Bluetooth is not the same thing as a card being authorised with no connection.

You can keep trading offline through a normal service, and typically well beyond it, but “forever” is not an honest answer, so here are the two real limits. The first is storage on the device. Everything you take offline is held on the tablet until it can be uploaded, and a device has finite space — the 4.2MB shown on this page is sample data illustrating how compact a batch of orders is, not a cap we are quoting you. In ordinary use orders are small and a long day fits comfortably; the limit only becomes a live concern over an unusually long stretch with no connection at all. The second is simply arithmetic: the longer you stay offline, the bigger the queue of un-uploaded orders grows, so the first sync after a long gap has more to send and takes correspondingly longer. Neither of these is a reason for anxiety on a normal shift — they are reasons to sync when you conveniently can rather than deliberately running dark for days. When you do reconnect, the sync reconciles the things that changed while you were away: the orders you took, the inventory those orders drew down, any loyalty or customer activity attached to them, and the figures that feed your reports and the sync dashboard. Once it completes, your other devices and your back-office reflect the offline trade as if it had been online all along. If anything genuinely conflicts — see the conflicting-terminals answer above — it is flagged for you at that point rather than quietly overwritten. For exact storage limits and sync behaviour on the specific hardware you plan to run, confirm the numbers with our sales team.