How VIND keeps selling when GO or Melita goes down

In our first week of trialling VIND with a Sliema café, the broadband cabinet at the end of the street went down for ninety minutes during the lunch rush. The owner found out because the laptop at the back stopped showing emails. The till — the part that matters — did not notice.

That’s the whole pitch for offline-first POS in one paragraph. Here’s how it works under the bonnet.

The Maltese context

If you’ve run a hospitality business in Malta for more than a year, you have a stories. GO had a 4-hour outage in 2023. Melita had a regional cabinet failure last summer. Your own venue has had a router that needed a reset, a power cut that took the modem with it, a fibre cut from someone digging a trench down the street. None of those are anomalies. They are the predictable cost of running a connected business in a real-world building.

A POS that depends on a live connection to bill a customer is a POS that has chosen to take the day off whenever the network does. That’s not what you signed up for.

What “offline-first” actually means

The phrase gets thrown around. We mean something specific: the till works without an internet connection, end-to-end, from the moment the day opens to the moment it closes. That includes:

• Adding items to a cart.
• Splitting bills, modifying lines, applying discounts.
• Charging the customer — cash, card via the local terminal, or whatever the venue accepts.
• Printing a sequentially-numbered fiscal receipt.
• Sending the ticket to the kitchen display.
• Issuing a Z-reading at end of day.

None of these depend on the network. All of them carry their full fiscal weight when the network comes back. The cashier doesn’t have to know whether they are online — the till just works.

How we built it

1. The cart, the receipt, the queue — all in IndexedDB

VIND’s POS PWA writes everything to IndexedDB before it touches the network. The cart is local. The receipt is local. The fiscal log is local. The “send to server” step is a separate, asynchronous queue.

That means a cashier can open a cart, ring up 30 items, take payment, print a receipt, and start the next order — with the network unplugged, indefinitely — and the system never blocks or shows a spinner.

2. Receipt numbers come from a pre-allocated range

The single hardest problem in offline POS is the receipt number. MTCA wants strictly monotonic numbers across all terminals. If two terminals each generate their own numbers, you have collisions. If one terminal asks the server for a number per receipt, you have a network dependency.

VIND solves this with range allocation. When a cashier clocks in for the day, the terminal asks the server for a block of numbers (say 5000–5099). That range lives in IndexedDB. As the cashier rings up sales, the terminal consumes numbers from the range locally. The next cashier on the next terminal gets 5100–5199. There is no overlap, no per-receipt network call, no collision.

When the link comes back and the day closes, we reconcile: range issued, range consumed, range released. If any numbers were skipped, we never silently fill the gap — we flag for review and let MTCA see the gap honestly. That’s the law, not a design choice.

3. Card payments stay local — Viva terminals are autonomous

This is the part most cloud POS vendors get wrong. A “cloud POS” usually means the card terminal talks to the cloud to authorise the payment. So when the cloud is down, the terminal is down, and you’re back to taking cash.

VIND integrates with Viva Wallet terminals that operate over the local Bluetooth/Wi-Fi link to the POS, and the terminal itself handles the network call to the acquirer. The POS just tells the terminal “charge €34.50” and waits for the receipt of approval. If the POS is offline and the terminal has a working mobile connection (4G fallback in the device), the payment still authorises. If the terminal is also offline, the cashier can fall back to cash and the offline-payment log records the customer’s intent.

4. The KDS doesn’t need the cloud

The kitchen display in VIND is a sibling PWA on the same local network. The POS sends the ticket over the local network directly to the KDS, not via the cloud. So even if both the POS and the KDS are cut off from the world, the order still hits the kitchen the moment it’s punched in.

(There is a cloud-mode for multi-site setups where one venue’s KDS sits at another location, but the default single-venue setup is fully local.)

5. Sync is server-authoritative for fiscal, last-write-wins for the rest

When the network returns, the queued mutations stream to the server. The reconciliation rule is:

• Fiscal data (receipts, voids, Z-readings) is server-authoritative on conflict — meaning the server is the audit truth, and the terminal can’t quietly mutate a number after it was assigned. If two terminals tried to use the same number (they can’t, but if they could), the server reports it and we flag for review rather than auto-resolving.
• Non-fiscal data (inventory counts, table assignments, kitchen modifiers) is last-write-wins with a vector clock so we know which device wrote last.

The cashier never sees this. They see “synced” go from a count down to zero.

What happens during a 90-minute outage

Concretely, here’s what an offline lunch service looks like in VIND:

Time	Network	What VIND does
12:30	up	Day opens, range allocated, 47 receipts so far
12:42	drops	Cashier notices nothing. New order rung up.
12:43	down	Receipt printed locally with the next number in range. Kitchen ticket sent over local Wi-Fi.
12:44–14:11	down	31 more orders processed identically. Card terminals stayed live via mobile fallback; 4 customers paid cash.
14:12	back	Queue drains over the next 90 seconds. 31 receipts visible in the backoffice. Audit log entries land.
16:00	up	Z-reading closes the day. Range reconciled. Zero gaps.

Total customer-visible impact: zero.

The honest caveats

We are not magicians. There are two things that don’t work offline:

1. Looking up product details that aren’t cached locally. If you scan a barcode for an item that’s never been sold at this terminal, the lookup fails. We mitigate by pre-syncing the full catalogue on clock-in.
2. Card payments through a network-only terminal. If your card terminal is the kind that requires its own internet to authorise, no POS can fix that. We recommend Viva for exactly this reason.

Everything else — the receipt, the kitchen, the cart, the Z-reading, the inventory decrement, the audit log — works.

What this means for you

Pick a POS that treats the network as a nice-to-have, not a load-bearing wall. We built VIND’s POS so that the day Melita decides to dig up the street outside your venue, you don’t have to apologise to your customers.

If you’d like to see the offline path in action, the demo walkthrough includes a “pull the plug” segment by default.