How Wameed keeps selling when the internet does not

"Works offline" is claimed by almost every point of sale and means something different in each. Here is precisely what it means in ours, including where it stops.

Local-first, not cloud-with-a-cache

The distinction matters.

Cloud with a cache means the application lives on a server and the terminal holds a copy of some data so the screen does not go blank. When the connection drops, you may be able to look at things; you generally cannot complete a compliant sale.

Local-first means the full application and the data it needs live on the terminal. The terminal is complete on its own. The cloud is where terminals synchronise with each other and with the back office — it is not on the critical path for a sale.

The practical consequence: a Wameed terminal does not behave differently when the network drops. It carries on, because the network was never what was making the sale work.

The ZATCA part

This is the piece that makes offline selling legally meaningful rather than just convenient.

Under Phase 2, every invoice carries a cryptographic stamp produced with a certificate issued to that specific device. Two architectures are possible:

• Sign on a server. The terminal sends invoice data up, the server signs, the signature comes back. Simple to build, and completely dependent on connectivity.
• Sign on the device. The production certificate and its private key live on the terminal. The stamp is computed locally in milliseconds.

Wameed signs on the device. So an invoice issued while disconnected is a complete, valid invoice at the moment it prints — correct XML, correct hash chain, correct QR with the stamp and public key. Not a placeholder to be fixed later.

Reporting to the authority happens when connectivity returns, inside the 24-hour window that simplified invoices have. Seeoffline rules.

The hash chain across an outage

Each invoice references the hash of the previous one from the same device. Offline invoices continue that same chain — they do not start a parallel one that has to be merged later, because a merge is exactly what produces a visible break.

When the device reconnects, it reports the already-signed documents in order.

Two terminals, both disconnected

This is the genuinely hard engineering problem in local-first design, and it is why fewer vendors build this way.

Two terminals, both offline, both selling the last unit of the same product. Both are locally correct; together they are wrong.

How we handle it:

• Sales are never rejected. A sale that happened, happened. Reversing a completed transaction because of a sync conflict is not acceptable behaviour at a till.
• Stock reconciles to reality on sync, which may produce a negative figure. A negative is a true statement — you sold more than you had — and it surfaces as an exception to investigate rather than being silently rounded to zero.
• Invoice sequences are per device, so two terminals cannot collide on numbering or on the hash chain.
• Last-write-wins is not used for anything that matters. Price changes, stock adjustments and configuration are ordered by the server, not by whichever terminal syncs last.

The browser cashier

Unusually, the browser cashier is also offline-capable. It holds its data locally and signs ZATCA invoices the same way the native app does.

The practical value is a failure plan: when a terminal dies on a busy evening, any laptop becomes a working till in about five minutes, and it works whether or not the internet is up. Seedowntime procedures.

The limit: the kitchen display

The kitchen display needs the local server. When the network between the till and the screens is down, the KDS is down.

We say this plainly because it matters operationally. Sales, signing and printing continue; the kitchen screens do not. The fallback is printed tickets, which is why we recommend keeping a wired kitchen printer even after moving to screens, and rehearsing the switch once. Seekitchen display systems.

Of the systems in our comparison set, NCR and Revel are marked as having offline KDS. If uninterrupted kitchen display is critical to you, that is a real difference and we would rather name it.

How long

Twenty-four hours of offline operation. The limit exists because reporting obligations do not pause, and a terminal that has been disconnected for days accumulates a reporting backlog that needs attention rather than silence.

The terminal shows the pending-report count where staff can see it, and reporting resumes automatically on reconnection.

How to verify any of this

Do not take our word for it. Unplug the router, complete a sale with a modifier and a discount, take a card payment, print the invoice, scan the QR with your phone, ring up nine more, reconnect, and check all ten arrived once each.

The ten-minute protocol is in theoffline comparison, and it works on any vendor's demo, including ours.