Point of Sale that keeps selling when the internet drops

A shop does not close because the router does. Every counter product in this category takes cash sales with the network down, and until this month ours took none, because a sale was one call to the server and there was nothing to catch it when that call failed.

That is fixed. The till now sells offline, opens offline, and settles up when the connection comes back without ever charging anyone twice. This post explains what it does and the decisions behind it.

What happens when the connection drops

Nothing visible. You keep scanning, the total keeps adding up, you take the money and the customer leaves with a document.

The sale is written to the device rather than sent. When the connection returns, queued sales replay oldest first, so the order they happened in is the order they land in. Nobody has to remember to do anything, and there is no separate "sync" button to forget.

Why the till still works after a reload

Selling offline only helps if the page was already open. A tablet switched on before the router, or a reload on a bad connection, used to meet the browser's offline page.

The till now keeps its own application shell on the device. Page loads try the network first and fall back to the last good copy. The code and styles it needs are kept from the first time it opens with a signal, and the list of what to keep comes from the build itself rather than being typed by hand, so it cannot drift out of date as the product changes.

Only the application is cached. Your data, the queue of unsent sales and anything that talks to the server are left alone deliberately, because a stale price or a cached stock figure is worse than no figure at all.

Why a sale cannot be charged twice

This is the part that matters most, and it is the reason offline selling is harder than it looks.

Two things can go wrong. A sale is sent twice because the till retried. Or a sale reaches the server, the reply never arrives, and the till believes it failed.

Both are solved the same way. Every sale is given its own reference before the first attempt, not after. That reference travels with it, and the counter already had a rule that no two sales on the same counter can share one. So if the same sale arrives again, the server returns the document the first one created rather than creating a second sale. A retry is safe by construction rather than by someone remembering to check.

What time the sale happened

A sale taken at half past four and sent at six o'clock is a half past four sale.

The order, the receipt and the invoice's supply date all carry the time the sale was actually made on the device, not the time it was received. That time is held inside the shift, so a device with a wrong clock cannot date a sale outside the day it was taken.

This is not tidiness. A supply date is what a tax return is built from, and a sale dated by when the network recovered would put takings in the wrong period.

What the till knows with no connection

Before it goes offline, the counter takes one snapshot of everything it is allowed to sell at that counter, in that counter's currency, with every code each item can be scanned by. Barcodes, internal codes, whatever is on the box.

So scanning works offline, prices are right, and an item that is not sold at that counter is not sellable there by accident.

The tax invoice is not optional

In the UAE this is where most counter software quietly fails.

The authority's position on simplified tax invoices is explicit: offering to print a tax invoice on request does not satisfy the requirement. Delivery is mandatory. A till that generates a receipt number and hands over nothing is in breach, not merely incomplete.

So the counter issues a real document every time. It renders on screen first and prints second, because delivery is required and a printer is not. The seller on that document is the legal entity that owns the counter, with its registered name, address and tax registration, and the till already knows which entity it belongs to without being asked.

Receipts render in Arabic as well as English, because a document a customer cannot read is not much of a document.

Money going back the other way

A counter that only takes money is half a counter. The till gives change, handles a return at the point of sale, and produces the credit document that goes with it, so a refund is a recorded transaction rather than an adjustment somebody makes later in the accounts.

Who is buying

A counter sale can now name its customer. That matters less for a bottle of water and a great deal for anything a business buys, because the document a business needs is different from the one a walk-in needs, and it turns on one fact: whether the buyer holds a tax registration.

What we have not done yet

Commerce is marked Alpha in the product and the counter is part of that. It is in daily use and still moving.

Card terminals are not integrated at the counter; cash and manually recorded payment work today. The offline queue holds sales, not stock movements, so stock figures catch up when the connection does rather than being reserved while you are offline. And the decision about whether a document is a full or a simplified tax invoice is answered from whether the buyer holds a registration, which means a buyer recorded without one gets the simplified document.

If you run a counter and want to try it, we would rather hear what breaks than have you find out quietly.