Can a POS system work without the internet?

The short answer

Yes, if the till was built for it. A point of sale keeps working without internet when the product catalogue, the prices and the arithmetic of a sale all sit on the device. It stops the moment any one of those has to be fetched. The dividing line is not the brand, the price or the word “cloud” in the marketing. It is where the sale is calculated.

That is the whole answer, and it is worth being precise about it, because “works offline” is written on almost every product page and means at least four different things in practice. The rest of this is how to tell them apart before you have a queue at the counter and no line.

What a sale needs the network for

Take one item across a counter and break it into steps. It is a shorter list than it feels like:

1. Turn a scanned barcode into a product.
2. Price it, and apply whatever discount applies.
3. Add it to the basket and total the basket.
4. Take the payment.
5. Print or send the receipt.
6. Reduce the stock figure for that product, in that branch.
7. Tell the other registers, the other branches and the owner.

Steps one, two, three and six are lookups and arithmetic over data you already own. A barcode table, a price list and a stock figure are small. A ten thousand line catalogue is a few megabytes, which is less than the photographs on the same tablet. None of it needs to travel anywhere to be correct.

Step five is local too, since the printer is on the counter, sometimes on the same USB hub as the scanner.

That leaves two steps that genuinely need a network. Step four, if the customer is paying by card, because authorisation is a conversation with their bank. And step seven, which is not part of the sale at all: it is what happens afterwards, and it can wait.

Three architectures, three outages

Almost every system on the market is one of three shapes. The shape tells you exactly what your staff will see at 9pm on a Thursday when the line drops.

A fourth shape is still common in pharmacies and supermarkets across the region: a server in the back office, with the tills on the local network. That survives an internet outage well, and it fails at everything else. The switch, the cable, the power supply on one machine and the person who is meant to be backing it up all become part of your till. It also gives you no chain wide view without extra plumbing, which is usually why people leave it.

What “offline mode” usually means

The phrase is doing a lot of quiet work on most product pages. In descending order of how often it is true:

• The basket in front of you finishes. Whatever is on screen can be completed. Nothing new can be scanned. This is the most common meaning and the least useful one.
• Recently used products still scan. A cache, warmed by what you happen to have sold. Fine for a corner shop with forty lines, useless for a pharmacy with twelve thousand.
• Everything scans, until the app is reloaded. The data was in memory, not in storage. This is the one that catches people out, because it passes a casual test and fails a real outage, when someone eventually refreshes a tab or the tablet sleeps.
• Everything scans, and survives a restart. The catalogue is in on-device storage. This is the only version that is worth anything at 9pm.

Four questions separate them, and they are worth asking in writing:

• Can I scan a product I have not touched today, with the line down?
• Does that still work after the app is closed and reopened, or the device is restarted?
• How long can the device stay offline before it refuses to sell?
• When it reconnects, what stops a queued sale being counted twice?

The last one matters more than it sounds. A queue that retries without an identity on each sale will happily post the same transaction twice when a reconnect is flaky, and you will find it at the month end as stock that has vanished.

Card payments are the real exception

Everything above is about the till. Card payments are a separate system with separate rules, and no point of sale can honestly promise you they will work offline.

Authorisation is a live request to the customer’s bank. With no line there is nobody to ask. Some terminals support a store and forward mode with a floor limit, holding small transactions and submitting them when the connection returns, and in that arrangement the merchant carries the loss if one is later declined. That behaviour belongs to the terminal’s kernel and the card scheme rather than to your till: offline authorisation and floor limits are written down in the EMVCo specifications. Whether any of it is available to you is a question for your acquirer and your terminal supplier, not for your software vendor.

What you can plan for:

• Cash and account sales complete offline, every time.
• Card depends entirely on the terminal. Ask your acquirer what yours does at zero bars, and get the floor limit in writing.
• Decide the policy before you need it. Staff should know whether the answer at the counter is “cash only for now” or something else, rather than deciding in front of a queue.
• Whatever you agree, nobody should be writing card numbers down to key in once the line is back. That is squarely against PCI DSS, and an outage is not an exemption from it.

A till that keeps selling is still worth having when cards are down. The basket, the stock movement and the receipt are correct and recorded, and the payment method is a line on the sale rather than a precondition for it.

What happens across several branches

With one shop, offline is a question about one device. With four branches it becomes a question about who is allowed to be wrong, and for how long.

The useful distinction is between a number being wrong and a number being stale. While a branch is offline:

• That branch’s own stock stays correct. It is spending its own shelf. Nobody else can sell those units.
• The chain wide view goes stale. The owner’s dashboard is missing whatever the disconnected branch has sold. It is behind, not incorrect, and it catches up on reconnect.
• Transfers are the one genuine conflict. Two branches asking a third for the same twenty units is a real double spend. Reserving those units has to happen centrally, when the line is up. A transfer that is approved optimistically offline is a promise you may not be able to keep.

That gives a simple rule to hold vendors to: selling is allowed to be local, and claiming somebody else’s stock is not.

Notes for the Gulf and for Europe

The engineering is the same everywhere. What differs is how often the line drops and what you are obliged to do about it.

Across the Gulf and the wider Middle East, the common pattern is not a dead connection but an unreliable one: fine most of the day, unusable for twenty minutes in the evening, and a router that is one shared building supply away from a reboot. Mobile data as a failover helps and does not fix it, because the failover itself takes time to come up. Trading hours are long and the outage rarely lands during anyone’s support window. Two other things travel with this market: the interface has to be genuinely mirrored for Arabic rather than translated in place, and receipts have to print Arabic product names on the hardware you already own.

Across Europe, connectivity is steadier and the constraint moves to compliance. Several countries require receipts to be signed, recorded in certified hardware or software, or reported on a schedule, and those rules, not your vendor, decide what a till may do while it is offline and what it must do when it comes back. The European Commission’s VAT in the Digital Age package is moving more of this reporting onto a common schedule. The rules differ by country and they change. Confirm what applies to you locally before you rely on queued receipts, and ask any vendor which specific national requirements they have already been through.

In both markets the same closing question does the work. Put a number on it: how many hours can this branch keep selling with the line down, and what breaks in hour one, hour four and hour twenty four?

Test the claim in ten minutes

You do not need a trial period to find this out. Ask for a demo device or a trial account, then do this in order. Most systems fail at step three.

1. Scan a few items into a basket, then cut the network properly. Aeroplane mode, or unplug the cable. Not the browser’s offline checkbox.
2. Scan five more items, including one you have not touched today, and complete a cash sale.
3. Still offline, reload the page or restart the app. Then scan again. This is the step that separates data in storage from data in memory.
4. Receive stock, or start a count. Not everything that sells offline will.
5. Restart the device entirely and sell one more item.
6. Reconnect. Check every sale you made arrived, and that none of them arrived twice.
7. If you run more than one branch, repeat on two devices at once and check the chain wide figure afterwards.

Anything that clears all seven will hold a counter through a bad evening. Anything that fails step three will look fine in a sales demo and fail on the day you needed it, which is the outcome worth ten minutes of testing.

This is the test we build Solnay against. How it works walks through what happens on the device and what happens in the cloud, and in the branch lists what the counter does between opening and closing.