Offline POS: why a till must keep selling without internet

It is Friday evening, the queue is out of the door and the internet goes down. Whether that becomes a minor inconvenience or a lost night depends almost entirely on decisions made long before, when the point-of-sale system was designed and chosen.

What actually fails during an outage#

"The internet is down" usually means several separate things fail at once, and each needs its own answer.

• The connection to the outside world: the line, the router or the provider. Anything that has to reach a server elsewhere stops.
• Card terminals: many need a connection to authorise a payment. Some fall back to their own mobile connection; others simply stop.
• Cloud-only systems: if the till is just a web page on a remote server, it has nothing to show without a connection.
• Kitchen printers and screens on the local network: these often keep working, because they talk to the till over your own Wi-Fi or cabling. But if the router itself has failed, the local network can go with it.

The last point is worth separating carefully. Losing the internet is not the same as losing the local network. A router that reboots takes both down; a provider fault often takes only the first.

Online-only, "offline mode" and offline-first#

Point-of-sale systems broadly fall into three designs, and marketing language can blur them.

1. 1Online-only: every action goes to a server. No connection, no sales.
2. 2Offline mode: the system is built to work online and has an emergency mode bolted on. Often it can take simple cash sales but loses features, such as discounts, customer lookups or kitchen routing, and sometimes it limits how long or how many sales it will hold.
3. 3Offline-first: the till is designed to work from its own local data all the time. The connection is used to keep it in step with the server, not to make each sale possible. An outage changes very little at the counter.

The local queue and why each sale carries a unique key#

An offline-first till saves each completed sale on the device and adds it to a queue of changes waiting to be sent. When the connection is available, the queue drains in the background. When it is not, sales simply wait.

Networks fail in messy ways. A sale might be sent, reach the server, be saved, and then the reply is lost on the way back. The till cannot tell whether it succeeded, so it tries again. Without protection, the server would now hold the same sale twice, and your revenue, VAT and stock would all be wrong.

Invoice numbering when the till is offline#

Tax invoices need sequential numbers. The FTA expects a tax invoice to carry a sequential number that identifies it, and a sequence with gaps or duplicates invites questions in an audit. This creates a real puzzle offline: if three tills are disconnected, how does each know which number to use next without asking the server?

Random identifiers solve the duplicate problem but break the sequence, so they are not acceptable as invoice numbers. A random string tells an auditor nothing about whether an invoice is missing. The sound answer is number blocks: while it is online, each device reserves a block of numbers from the server in advance. Offline, it issues numbers from its own block in order. No two tills can hand out the same number, and every number is accounted for.

A well-built system reserves a new block well before the current one runs out, and treats a number as used once it is printed on a receipt, so cancelled sales are voided with their number kept rather than silently reused.

Syncing on reconnect, and what to do about conflicts#

When the connection returns, two things happen. The till sends its queued sales, and it pulls down whatever changed on the server while it was away: new prices, new items, things marked unavailable. A good design sends and receives only the changes since the last successful sync, using a marker of where it got to. Downloading the entire database on every reconnect is slow, gets slower as you grow, and tends to fail at exactly the moment many tills reconnect together.

Conflicts are inevitable, so the rules for them should be decided in advance rather than discovered.

• Price changed while offline: the sale was made at the price the customer was charged. That sale stands; the new price applies from the next sync.
• Item sold out elsewhere: an offline till may sell the last portion that another till also sold. The sale still happened, so it is recorded, and stock shows the shortfall for someone to review.
• Records deleted on the server: a till should never be able to delete master records, and records retired on the server should be marked inactive rather than erased, so older offline sales can still refer to them.

Card payments without a connection#

This is the part no till can promise on its own. Whether a card can be accepted during an outage depends on the card terminal, its own connectivity and the rules set by your acquiring bank. Some terminals carry a mobile data connection as a backup. Some acquirers allow certain transactions to be stored and sent later, under limits and at your risk if a card later declines. Many allow neither.

Ask your acquirer directly what happens to your terminals when the network fails, and get the answer in writing. Plan on cash, or a backup connection for the terminal, if the answer is "nothing works".

What to keep on paper as a last resort#

Even an offline-first till can fail: a dead tablet, a power cut, a dropped device. Keep a small, boring kit in a drawer.

• A printed menu with current prices.
• A paper order pad for the kitchen, so orders can still be passed through.
• A simple sales log sheet: time, items, amount, payment method.
• A cash float and a written note of who is responsible for it.
• Instructions for entering paper sales into the system afterwards, so they are not forgotten.

An outage drill to run before you rely on any till#

Do not take offline capability on trust. Test it, during a real service if you can bear it, and certainly during a busy rehearsal.

1. 1Unplug the internet line from the router mid-service and keep selling for at least half an hour.
2. 2Ring sales with modifiers, discounts and split payments, not just simple cash sales.
3. 3Check that kitchen tickets still print or appear on screen.
4. 4Switch the router off entirely and see what still works on the local network.
5. 5Reconnect and confirm every offline sale appears on the server exactly once, with sequential invoice numbers.
6. 6Change a price on the server while a till is offline, and check what happens after it reconnects.
7. 7Restart a till while it is offline and confirm its queued sales survive.

Questions to ask any POS provider#

• Is the till offline-first, or does it have an emergency offline mode? What features are lost offline?
• Is there any limit on how long, or how many sales, a till can hold offline?
• How are tax invoice numbers issued offline, and can two devices ever produce the same number?
• How do you prevent a retried sale from being recorded twice?
• On reconnect, do you sync only changes, or reload everything?
• Do kitchen printers and screens keep working without internet?
• What happens to queued sales if the device is restarted or its battery dies?

For our part, the EXO NODES POS keeps selling offline and syncs each sale when the connection returns, using the unique-key and number-block approach described above.

Key takeaways#

• An outage breaks several things at once; plan for the connection, the card terminal and the local network separately.
• Offline-first design keeps working from local data; an "offline mode" may only cover the basics.
• Unique keys on each sale make retries safe and prevent duplicates.
• Tax invoice numbers must stay sequential; per-device number blocks achieve that offline, random IDs do not.
• Card payments offline depend on your terminal and acquirer, so ask them.
• Run an outage drill before relying on any till, and keep a paper fallback kit.