When the Line Drops
An offline till is not one feature. It is four, they fail independently, and most systems that claim offline mode have built one or two of them. Here is the honest map of which are here — which is none — and what that means before you buy anything.
The position, stated first
This till requires a connection. There is no offline sale mode, no queued transaction, no offline tender authorisation and no reconciliation of tills that were disconnected. If your shop loses connectivity regularly and cannot stop trading when it does, this is a fit question rather than a feature request, and it should be settled before a trial.
Ask a vendor whether their till works offline and you will usually get a yes. The word covers at least four different capabilities that fail independently, and the yes is nearly always about the first one.
The four things "offline" means
Four independent capabilities, and whether they are here
| Capability | Present | Partial | Absent |
|---|---|---|---|
| Ring up a cash sale with no connection | No | No | Yes |
| Authorise a card or wallet with no connection | No | No | Yes |
| Reconcile two tills that were both disconnected | No | No | Yes |
| Meet a fiscal transmission duty during an outage | No | No | Yes |
Built and maintained Configurable by you, not maintained by us Not built
Four rows, four absences. This is one of the clearest and least qualified answers anywhere on this blog, which is why it is stated as a table rather than argued for.
Why each one is a separate problem
The first is a client problem: the till needs somewhere to hold a sale until it can be sent. That is the one most systems build, and it is genuinely useful on its own for a cash shop.
The second is not solvable by the till at all. A card or wallet payment is an authorisation from somebody else's system, and no amount of local storage produces one. A shop that goes offline can take cash and cannot take cards, whatever the software does.
The third is the one nobody thinks about until it happens, and it is the reason offline mode is hard rather than fiddly.
Two disconnected tills both sell the last unit. Both sales are valid. Both customers walked out with something. The reconciliation is not a merge conflict — it is a shortage, and software cannot resolve it.
In this product, stock is allocated server-side at the moment of sale, through the same allocation service the rest of the system uses. That is precisely what cannot happen when the till cannot reach the server, and it is the mechanical reason offline selling is a build rather than a setting.
The fourth is jurisdictional. Where a country requires each sale to be transmitted to a tax authority as it happens, an outage stops being an inconvenience and becomes a compliance question with a legally defined answer that varies by market. This product transmits in exactly one country and nowhere else, so for everywhere else the honest statement is that there is nothing to fail.
What to do if connectivity is genuinely variable
Outages are rare and short
Accept it
A few minutes of manual receipts a month, keyed in afterwards. Most shops in most places are here, and building for the exception is expensive.
Outages are frequent and you take mostly cash
The build is worth scoping
Offline cash selling with a queue is the one capability that pays for itself, and it is separable from the other three.
Outages are frequent and you take mostly cards
Software will not save you
The authorisation is not yours to give. Fix the connection, or take a terminal that has its own.
You run several tills in one shop
Ask about the third row first
Multi-till offline is where every implementation gets hard, and where a vendor's yes most often turns out to mean single-till.
The question to ask any vendor claiming offline mode
Two tills, both offline, both sell the last unit of the same item. When they reconnect, what happens? There is no good answer to this, only honest ones — and the shape of the answer tells you exactly how much of offline mode has actually been built.
Four questions about offline operation
Which of the four capabilities do you have?
A good answer sounds like
They recognise there are four.
What it actually means
A vendor who has not separated them has probably built the first and will discover the third with you, in production.
Can I take a card payment while offline?
A good answer sounds like
No — that is the acquirer's job.
What it actually means
A yes here is either a separate terminal or a misunderstanding. Both are worth uncovering early.
How is stock allocated during an offline sale?
A good answer sounds like
Optimistically, and reconciled after.
What it actually means
This is the honest answer and it means oversells are possible. A claim that they are impossible is a claim not to have thought about it.
What happens to a fiscal transmission during an outage?
A good answer sounds like
A market-specific answer.
What it actually means
Ours transmits in one country only, so for everywhere else the question does not arise — which is a limitation, stated as one.
Two of the four, and we would say plainly why not the others
Offline is a real project rather than a switch. These are the two halves worth building; the other two are not ours to solve.
Offline cash selling with a queue
Sales held on the device and submitted when the connection returns, with the receipt printed locally and the sale marked as pending until accepted. Genuinely valuable for a cash-dominant shop, and separable from everything else on this page.
A reconciliation view for oversold stock
Not conflict resolution — there is no such thing when both customers have left with goods — but a clear, immediate list of what went negative while tills were disconnected, so a person decides rather than a merge rule. This is the honest version of the third capability and it is the one most vendors skip.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Card authorisation offline is not buildable by us at any price, and we would rather say that than quote for it.
Talk to us about offline tradingWhat AWRA OpsHub does today
- Nothing. The till requires a connection to complete a sale, and this row is not hedged.
- Server-side stock allocation at the moment of sale, which is correct behaviour online and is the reason offline is a build.
- Fiscal transmission in exactly one market, which is stated plainly wherever it is relevant.
What it does not do
- Offline sale capture of any kind, cash included.
- A queue of pending transactions on the device.
- Offline card or mobile-money authorisation.
- Any reconciliation of tills that traded while disconnected.
- Any fiscal transmission outside the single market where it exists.
- Local receipt printing independent of the server.
Not ours, by choice
- This is one of the least qualified answers on this blog. If offline trading is a requirement, this product does not meet it today and no configuration changes that.
- The card-authorisation row is not a gap we could close. It belongs to the payment provider, and any vendor claiming otherwise is describing a separate terminal.
- Nothing here is Pakistani, and no fiscal claim is made about that market — this product transmits to one tax authority, in one country, and Pakistan is not it. Pakistan is here as a market where connectivity is genuinely variable and cash remains dominant.
Settle this before the trial
Offline is the one requirement that cannot be discovered late. If your shop must keep trading through an outage, ask the two-tills question of everyone you are considering, including us.
Talk about connectivity requirementsFrequently asked questions
Does a slow connection break the till?
Slow is different from absent, and a slow connection degrades the experience rather than stopping the sale. What is not possible is completing a sale with no connection at all.
Could I run a local server in the shop?
That is a deployment conversation rather than a product one, and for a single site with reliable local networking it can be a real answer. It moves the failure point rather than removing it, and it should be designed rather than improvised.
Why not just cache sales in the browser?
Because of the third capability. Capturing the sale is straightforward; deciding what happened when two tills allocated the same last unit is not, and shipping the capture without that reconciliation produces negative stock nobody can explain.
