Offline-first retail: designing for the connectivity you cannot control
Why retailers in Africa need POS systems that keep selling through outages, what works offline and what cannot, and how to test that your system really does.
The reality on the ground
Anyone who runs stores across African cities and towns knows the pattern. The internet drops at the worst moment, a mobile network slows to a crawl, or the power fails for a few minutes and then an hour. A retailer cannot choose when this happens, only how well the stores cope.
A POS that depends on a live cloud connection for every sale fails in exactly the moments that matter, such as a busy Saturday or month-end. Queues form, shoppers leave and cashiers resort to paper. Recovering the paper sales into the system later is slow and error-prone.
Four ways systems handle connectivity
| Approach | How it works | Weakness |
|---|---|---|
| Cloud only | Every action calls the cloud | Stops completely when the connection drops |
| Cloud with a short cache | Caches some data and tries to carry on | Limited and unpredictable behaviour offline |
| Local-first with sync | Till and branch use a local database and sync to head office in the background | Needs careful sync design to avoid conflicts |
| Standalone | Each till is isolated | No central visibility or consistent data |
For multi-branch retailers, local-first with reliable sync is usually the right balance. Stores operate at full speed regardless of connectivity, and head office still gets one consistent picture once data arrives.
What should work offline
At the till, these functions should continue without a network:
- Scanning items and looking up prices from the local database
- Cash sales and cash tender, with change calculated and receipts printed
- Credit-account sales with limit checks against the last known data
- Local stock lookup
- Till opening, closing and cashier switching
- Authentication of staff against locally stored credentials
- Holding and resuming sales
What cannot, and how to handle it
Some functions depend on a third party and cannot complete without a connection.
- Mobile money prompts and card terminals. These need the provider's network. The till should tell the cashier clearly and offer cash or another method.
- Real-time loyalty redemption. Allowing redemption offline invites abuse, so many systems block it until the connection returns.
- ERP posting and head office sync. These wait and replay when the connection is back.
- Cloud-based fiscal signing. Where signing depends on a remote service, the invoice must be queued and signed later, within the tax authority's rules.
The goal is not to pretend everything works, but to keep the most important thing working, which is taking the sale, and to make the limits obvious to staff.
Design principles for safe offline operation
1. A local source of truth. Sales are saved to a local database first. The till never waits on the network to complete a transaction.
2. An outbox queue. Anything that needs to reach head office goes into an outbox. If the push fails, it stays in the queue and retries automatically.
3. Idempotent replay. A message sent twice must have the same effect as once. Without this, a retry after a flaky connection can post a sale twice to the ledger.
4. Safe numbering. Receipts and invoice numbers must stay unique and sequential where required, even when tills are offline. This usually means number series per till or branch.
5. Clear master data flow. Products, prices and users flow from head office to the branch. Transactions flow back. Keeping those directions distinct avoids most conflicts.
6. Visibility. Staff and head office should see sync status, queue depth and time since last sync, so problems are noticed before they grow.
7. Controlled degradation. When features are unavailable, the till should say so and offer the next best option rather than failing silently.
Fiscal compliance when the line is down
Tax systems add a constraint. In Kenya, for example, each invoice must be signed for KRA eTIMS. A design that signs through a local agent at the branch, queues unsigned invoices when the signer or network is unavailable and retries automatically keeps the store trading while staying compliant. An escalation path for invoices that stay unsigned too long gives finance a way to act. Check the rules in each market you operate in.
Test it like you mean it
Do not rely on a vendor's statement that the system works offline. Test it.
- Unplug the network at the till during a sale. Does the sale complete?
- Cut power to a till mid-transaction and restart it. Is the sale recovered or clearly flagged?
- Run a store offline for several hours, trade normally and then reconnect. Do all sales arrive once and only once?
- Change a price at head office during an outage. What happens when the store reconnects?
- Try mobile money and card payments offline. Is the message clear and is there a sensible fallback?
- Check the timestamps, receipt numbers and totals after the sync.
Run these drills in a pilot store before roll-out and repeat them after major updates.
The business case in one line
Estimate how many minutes of outages each store has in a month, multiply by average sales per minute and then by the share of sales that would be lost without offline capability. Even a conservative estimate usually exceeds the cost of choosing a system designed to cope. Add the trust you protect with shoppers and the finance time you save by not reconstructing paper sales.
Questions to ask any vendor
- Does the till keep a local database, and what exactly continues offline?
- How do queued transactions replay, and how are duplicates prevented?
- How does the system handle numbering and fiscal signing offline?
- Which payment methods fail offline, and what does the cashier see?
- How do we monitor sync health across branches?
- Can you demonstrate an outage test on our hardware?
Pair software resilience with hardware resilience
A resilient system also needs resilient equipment: a properly sized UPS, wired fixed tills and a failover connection for card terminals. See our buyer's guide to POS hardware.