How does an offline POS keep selling when the internet drops?

An offline point of sale keeps selling because it does not wait for the connection to make a sale. The till holds the product list, prices and tax rules on the device, writes each sale to local storage the moment it happens, and adds everything that needs the server, a stock update, a loyalty point, a report feed, to a queue. When the line returns, the queue syncs in the background and central stock catches up. The hard part is not selling with no connection. It is deciding what happens when two branches sell the same last unit while both are offline, and that is a data design choice you make before the outage, not during it.

A till that survives an outage is built to do its core job entirely on the device. That means four things are already present before the connection drops.

• A local copy of the catalogue: products, prices, taxes, discounts and the rules that apply them.
• A way to write a completed sale to storage on the device, not to the server.
• A receipt path, print or on screen, that does not call out to the network.
• A queue that holds everything bound for the server until it can be sent.

This is where a real offline design parts company with a cloud till that merely caches a few pages in the browser. A cached page lets a cashier look at yesterday's menu. It does not let the business take money, reduce stock and keep a trustworthy record while the line is down. Offline capability is an architecture, decided at the start, not a setting switched on at the end. Our guide to what affects the cost of a POS and warehouse system explains why adding it late is so much harder than planning for it.

It helps to split the work into what lives on the device and what waits in the queue.

Stored on the till so selling never stops:

• The catalogue snapshot the till sells from.
• The sales journal: every transaction made since the last sync, with its items, prices and payment type.
• The cash drawer state and any open or parked tickets.

Queued for the server and sent when the line returns:

• The stock decrement for each item sold, so central inventory can catch up.
• The feed that consolidated reporting reads.
• Loyalty points, customer account changes and anything an integration consumes, such as an accounting tool or an online store.

This split is a well understood pattern in software that has to work away from the network. Cloud databases built for mobile use the same idea: they cache the data the app is using on the device and synchronise local changes to the backend when the connection returns. A POS applies that pattern to a shop counter. The sale is real the instant it is saved locally. The sync is a background chore that happens later, and the cashier never waits for it.

Card payments are the one part of a sale that does not fully belong to the shop. Taking cash offline is simple, because nothing outside the till has to agree. A card is different, because approval normally needs the bank on the other end of the connection. When the line is down, a retailer has two honest options.

The first is to fall back to cash and other offline methods and decline cards until the connection returns. Plain, and free of risk.

The second is store and forward. The terminal captures the card, stores the transaction on the device, and forwards it to the processor when it reconnects. This keeps the counter moving, but it moves the risk onto the merchant, because a stored payment can be declined after the sale has already completed, for an expired card or insufficient funds. Systems that allow it usually cap the value per transaction and in total while offline, so the exposure is bounded.

There is a compliance point underneath both options. The moment a till stores card details to forward them, it is holding payment data, and any system that stores, processes or transmits that data falls under the card industry's baseline of technical and operational requirements designed to protect payment account data. That is a reason many retailers keep offline card acceptance off by default and simply take cash when the line is down.

This is the question the generic explanations skip. Picture one unit of an item left in the shared stock, and a connection that drops at two branches at the same moment. Here is what happens, stage by stage.

Both sales are real, because the goods left both shops. The server cannot pretend one of them did not happen. What a well designed system does is detect that the two offline decrements together take the count below zero, hold that as a named conflict rather than hiding it, and surface it for a decision. That is the moment the conflict rule you chose earlier decides what the staff see next. We describe how this reconciliation worked in practice in our note on running one POS across twelve branches.

Engineers who build sync systems talk about this as conflict detection and resolution, with strategies such as optimistic concurrency and automatic merge. For a retail counter it comes down to two rules you can choose between, and the choice is a business decision, not a technical one.

Rule one, accept both and correct after. Both completed sales stand, central stock nets to the real shortfall, and the system raises a loud negative stock exception that triggers a transfer from another branch or a reorder. This matches what actually happened in the shops: two customers walked out with goods, and no software can un-sell them. It is the right default for fast moving, low value stock, as long as the exception is impossible to miss.

Rule two, first reconnect is authoritative. The earliest terminal to sync commits its deduction, and a later conflicting deduction is held for a person to resolve, by fulfilling from another branch, placing a backorder, or arranging a refund, rather than merged silently. This gives more control at the cost of more manual steps, and it suits high value or serialised items, where quietly overselling one unit is expensive to put right.

Most retailers are better served by rule one with a reliable alert, because it keeps the counter honest about physical reality. Choose rule two where a single oversell matters enough to justify a human checking it every time.

Offline behaviour is only as good as the day you proved it. Before you rely on it, run these tests on the real system, not on a promise in a brochure.

• Pull the connection in the middle of a sale and confirm the sale completes and is kept.
• Sell past the last unit at two tills at once, then reconnect, and watch how the system reports and resolves the shortfall.
• Leave a till offline for a long stretch, then reconnect, and check that nothing is lost and nothing is counted twice.
• Test the card fallback you chose, whether that is cash only or store and forward, and read what the cashier is told to do.
• Confirm that reports and every integration catch up correctly after a sync, with no duplicated figures.
• Check that staff see a clear indicator when the till is offline, so nobody assumes a sync has happened when it has not.

A business that has run these tests knows what its offline mode does. A business that has not is trusting a feature it has never seen under the one condition it was bought for.

Does offline mode work for card payments or only cash?

Cash always works offline, because nothing outside the till needs to agree. Cards work only if the system supports store and forward, which holds the transaction and sends it to the processor on reconnect. That carries the risk of a decline after the sale, so some retailers keep it off and take cash when the line is down.

How long can a till stay offline before data is at risk?

The sale itself is safe the moment it is saved on the device, so a long outage mainly delays the sync rather than threatening recorded sales. The practical limits are the device's storage, any cap the system sets on stored card value, and how stale the catalogue becomes if prices change centrally while the till is offline.

Do stock counts stay accurate during an outage?

Each till stays accurate for its own sales. Central stock goes stale during the outage because the decrements are still queued, and it becomes accurate again after every branch reconnects and reconciles. The one case that needs a rule is two branches selling the same unit while both are offline, which reconciliation surfaces as an exception.

Is offline capability a reason to choose custom software?

It can be, when a packaged product does not handle your branches, your conflict rule or your card fallback the way your shops actually work. Offline behaviour and reconciliation are design decisions, so a business whose needs do not fit an off the shelf till often has exactly those parts built instead.

Tell us how your shops work today, how many branches share stock and what should happen when the line drops, and we will map how offline tills and reconciliation would behave for your setup, drawing on a branch POS case study where tills kept selling offline and reconciled on reconnect. Ask how offline tills would work for your branches.