A point-of-sale system can face an interrupted connection at the busiest moment of the day. “Works offline” sounds simple, but it hides several separate decisions: what a cashier can do without a network, where a transaction is stored, and what happens when two devices reconnect with different stock information.

Define the offline promise precisely

Decide which actions must continue during an outage. A team may need to browse a cached catalog, create a sale, print a receipt, or accept a particular payment method. Other actions may require a connection. Make that boundary visible in the interface so staff know what is saved locally and what is still pending.

For browser-based applications, service workers can help cache application assets and handle network requests. IndexedDB can store structured data locally. These are building blocks; they do not decide the business rules for a sale.

Treat each sale as a traceable event

Give every locally created transaction a stable identifier. Keep the original time, device, operator, items, quantities, prices, and sync status. The server should recognize a retry so the same sale is not recorded twice. A receipt should tell the truth about whether the transaction has reached the central system.

Payment behavior needs separate review. An offline card payment is not automatically available just because the POS screen works offline; it depends on the payment provider and agreed operating rules.

Plan stock reconciliation before building the screen

Two counters may sell the last unit while both are disconnected. Decide whether stock is advisory, reserved, or strictly enforced at the point of sale. Define what happens when a late transaction conflicts with current stock. A clear exception queue is usually more useful than silently overwriting a value.

Test the less common paths too: returns, cancelled sales, price changes, device clock errors, and a device that is offline for several days. These cases shape the data model and staff procedures.

A useful discovery checklist

  • Which checkout actions must work during an outage?
  • How long can a device remain offline?
  • Which data must be available locally, and how is it protected?
  • How will duplicate sync attempts be detected?
  • Who resolves stock and payment exceptions?
  • What should a cashier see while transactions are waiting to sync?

Our POS, restaurant, and inventory service can help scope these decisions around your operation. If you have an existing system, tell us about its workflow.

References