How to Design a POS That Keeps Selling Offline
The core rule of an offline-capable POS
The core rule is this: the sale completes at the till and the head office learns about it afterwards. The till application writes the line to its local database, prints the receipt and queues the transaction for transmission. When the centre is unreachable, sales do not stop; only central visibility is delayed. In a design that waits for central approval, a link outage is a direct loss of revenue.
What must be held locally at the till
- Products, barcodes, units and tax rates
- The active price list and campaign rules with their start and end dates
- Customer card and point balance, with an offline limit defined for the balance
- Cashier permissions and the rules for returns and voids
- Open receipts, opening float and cash count data
Price and campaign data must be distributed to the till in advance. Asking the centre for a price at the moment of sale invalidates any claim of offline capability.
Where should campaign rules run?
The campaign engine belongs at the till, with the centre distributing only the rule set. That creates two requirements: rules must be versioned, and it must be recorded which till applied which version. When a campaign is calculated incorrectly, the logs must be able to answer "which till was running which rule version".
Payment and fiscal device integration
Card payments and fiscal transactions live in a different world from the application's own queue: they happen on the device and at the bank, and reversing them follows their own rules. The critical scenario is a payment that succeeds while the till application fails to receive the response. The application must mark the transaction as indeterminate, be able to query the device for the status of the last transaction, and warn the cashier against collecting a second time. Without testing this scenario, double collection and end-of-day variance are inevitable.
End-of-day reconciliation
Four sets are compared at close: the application's sales total, the fiscal device report, the bank POS total and the physical cash count. To trace a variance, every sale must be stored with its till identifier, cashier, payment type, device transaction number and any return reference. If these fields are not designed in from the start, variance analysis becomes manual work.
Expected behaviour at the centre
Queued sales may not arrive in order. The centre needs duplicate detection based on sale identifier, and it must be able to post a late-arriving sale into the correct period even after that day's reports have closed. The detail of this behaviour is covered in our [API integration guide](/en/blog/api-integration-guide).
Three things that change when you go multi-store
Stock becomes per-store with an inter-store transfer process; pricing needs store or region variance with delegated authority; and permissions must define which discount a store manager can approve and which transaction requires regional approval. A data model written for a single store breaks at these three points.
Frequently asked questions
How does stock stay correct while the till is offline?
The till decrements its local counter and the centre updates its own balance as sales arrive. Short-lived divergence is expected. What matters is that a negative stock condition warns and flags the record rather than blocking the sale, otherwise the purpose of offline operation disappears.
How long can a till stay offline?
The limit is set by queue size and the freshness of price and campaign data. Define an upper bound and warn the manager when it is exceeded; unlimited offline operation increases the risk of selling at stale prices.
Can returns be processed offline?
Yes, when the original receipt reference is available locally. Returning a sale made in another store is not safe offline and should require central access.