Most cloud POS systems treat offline as a degraded mode. QuickPOS inverts that: the device is the source of truth in the moment, and the cloud is a place things catch up to. That single decision is why a dropped connection is a non-event instead of a disaster.
Every sale is written to a dedicated durable store before anything else, indexed by idempotency key and status — independent of the sync queue.
An append-only black box for stock-critical operations, so nothing is lost even if a sync attempt is interrupted mid-flight.
Each queued operation carries a key so retries can never double-charge or double-count.
Stock events (restock, sale, refund, resale) replay one-by-one in the exact order they happened.
When a path opens, the queue drains intelligently. On a shared network, one device can hold a host lease so branches sync locally over Wi-Fi, then that host forwards to the cloud. Inventory comes back as deltas — only changed rows, by row-version and watermark — so even a very large shop stays responsive.
If two devices touch the same stock, QuickPOS doesn't silently pick a winner — it records the conflict on the Sync screen for a human to resolve. Duplicate sales that already reached the server are recognised and quietly closed, so a flaky connection doesn't create phantom transactions.
The sale is already written to the local vault and queue before the receipt prints, so it completes normally. When a network path returns, it syncs automatically in order.
Yes. On a shared Wi-Fi network one device can act as a LAN host, so tills sync to each other locally and the host forwards to the cloud when it can.
Every operation carries an idempotency key. If a sale already reached the server, the retry is recognised as a duplicate and closed rather than re-inserted.
The conflict is surfaced on the Sync screen instead of being silently overwritten, so a person decides the correct result.