Offline Selling Solves the Wrong Half of Load-Shedding
Everyone sells offline capture as the answer to a power cut, and it is a real answer to the wrong half. Your till can record a sale in the dark. What it cannot do is get a card approved — and in this region the card is not the minority tender.
The schedule was published this morning, so everybody in the shop has known since breakfast that the power goes at six. At two minutes past six there is a queue, the emergency lights are on, the tablet at the counter has eighty per cent battery and about four hours in it, and the first customer in the line is holding out a card. Everything you bought to survive this moment is working exactly as advertised. You still cannot take the money.
This is the part that gets skipped. A scheduled supply interruption is discussed as a data-availability problem, which it is, and which the industry has largely solved. It is also a payments problem, which is harder, less discussed, and in this region considerably more expensive.
The half that is genuinely solved
Offline-capable capture is real and it works. Sales are held on the device and synchronised when the connection returns, the stock movements travel with the sales that caused them, and shift sessions still reconcile against float and counted cash. The mechanics, the device-registration model and the honest limits are set out in selling when the connection drops, and the warehouse side — receiving, counts and issues continuing on a charged phone — in inventory and distribution in South Africa. None of that needs repeating here.
Take that as given, then, and notice what it buys you: your record survives the outage. It does not follow that your trade does.
The half that is not: what a till actually knows about a payment
What a tender record here contains, exactly
A sale carries one or more payment rows, so split tender works. Each row holds a method, an amount and a time. The method is one of three values — cash, mobile money or card — and the row carries no authorisation code, no terminal reference and no card identifier of any kind. Which means a card tender at this till is not a record that a payment happened. It is a record that somebody believes a separate machine, on a separate network, approved one. In normal trading that belief is well founded and the distinction is academic. During an outage it is the whole problem.
Two things follow from that, and they pull in opposite directions. The till will happily let a cashier record a card tender it cannot verify, which is why the sale can be captured at all. And nothing in the record will later tell you which card tenders were real, which is why the reconciliation afterwards is done by total rather than line by line.
| Tender | What it needs to work | What survives a power cut | What you are exposed to |
|---|---|---|---|
| Cash | A drawer and a float. | Everything, as long as somebody can make change. | Holding more cash than usual, in a dark shop, on a day everyone knew about in advance. |
| Card | The terminal, its network, and the acquirer — none of which are yours. | Nothing, unless the terminal has its own power and its own connection. | Refusing the majority of your normal trade, or accepting it on trust and discovering the gap at settlement. |
| Mobile money | The customer's handset, their signal, and the provider. | Often more than a card does, because the dependency is on the customer's network rather than on yours. | Confirmation you cannot see. A screenshot is not a receipt from your acquirer. |
| Account or credit sale | A credit check somebody has to be able to perform. | The capture. Not the check. | Extending credit blind, to whoever asks during the two hours you cannot look. |
Offline capture protects the record of a sale. A sale you cannot get paid for does not need its record protecting.
The tower fails after you do, not with you
There is a second-order effect worth planning for, because it makes an outage feel like two different outages. Your own equipment goes first and comes back first: the lights, the router, the card terminal. The mobile network usually survives the beginning of an interruption, because the cell site has batteries — and those batteries are sized for short, occasional cuts rather than long or repeated ones, and in some places they have been stolen.
So the practical sequence in a long or a back-to-back outage is: fixed line and terminal down immediately, mobile data still up, mobile data degrading part-way through, everything back a few minutes after the power. A plan that assumes connectivity is binary will be wrong in the middle, which is exactly when the queue is longest. If you are relying on a mobile connection to keep card acceptance alive, know how long that has actually lasted in your area, from observation rather than from the specification.
A scheduled outage is a different management problem from an unscheduled one
This is the genuine advantage of the regional situation and almost nobody uses it. You know when it is happening. That converts the whole thing from resilience engineering into shift planning, and it makes the failures that do occur much harder to excuse.
-
Decide the tender policy in advance and put it on the wall
Cash only during the window, or card on trust up to a stated limit, or no trading. All three are defensible and the worst outcome is a cashier deciding it alone at the counter, differently each time. Whatever you choose, the limit should be a number, and the number should be written down where the customer can also read it.
-
Move the trade you can move, rather than surviving it
A published schedule means the deliveries, the cash-ups, the price changes and the stock counts can all be placed outside the window instead of colliding with it. This is worth more than any equipment you will buy, and it costs nothing.
-
Power the terminal and the router before you power the till
The tablet already has a battery. The card machine and the network equipment are the components that turn an interruption into lost revenue, and they are also the cheapest things in the shop to keep alive. Most sites get this order backwards.
-
Cap the credit and the change
A cash-only window means an unusual amount of cash in the drawer and an unusual amount of change going out. Both are predictable from the schedule, and both are a security decision that belongs to a manager rather than to the person holding the drawer.
-
Rehearse the reconnection, not just the outage
Most of what goes wrong goes wrong on the way back: sales that did not sync, a terminal that reconnected to a different session, a shift that got closed twice. Take a counter offline deliberately during a quiet hour, trade on it, bring it back and reconcile it.
What you check afterwards, and in what order
The reconciliation after a planned outage is not the same as the ordinary end-of-day, because two specific things can be wrong and neither of them shows up as an error.
- Pending operations, first. Anything captured offline and not yet synced is not in any report. Somebody looks at the device list and confirms it is empty before the day is called closed.
- Card tender total against the acquirer's settlement. Not line by line, because the till holds no authorisation reference to match on — by total, for the window. A difference here is the real cost of whatever trust policy you ran, and it is the number worth knowing before you set the policy again.
- Negative stock at the counters that were offline together. Two disconnected tills can both sell the last unit; both sales are valid and both sync. Nothing resolves that automatically and nothing flags it as an outage consequence, so look for it while you still remember why it happened.
- Shift sessions closed cleanly, with float, drops, expected and counted cash — see till and shift reconciliation for the ordinary version of this.
- Cold chain, separately. That is a stock write-off question rather than a counter question, and it is covered from the warehouse side in the South African distribution guide.
What we do and do not do
What AWRA OpsHub does today
- Offline-capable capture at the counter, with sales and their stock movements held on the device and synchronised on reconnection.
- Registered devices with pending operations visible, so what has not yet reached the server can be seen rather than assumed.
- Split tender across a sale, with each payment recorded as its own row.
- Shift sessions that still reconcile against float, drops, expected and counted cash after an offline period.
- A recorded sale is a recorded sale. Nothing about the offline path produces a lesser document once it syncs.
What it does not do
- No offline payment authorisation, of any kind. Card and mobile money need their own networks and their own providers. Offline capture records that a tender was taken; it does not and cannot approve one.
- Three tender types, fixed. Cash, mobile money and card, set in the schema rather than configurable — and the mobile money option is a specific East African brand. Instant EFT, a QR wallet or a voucher has to be recorded as one of those three, which is workable and means your tender analysis is coarser than your actual tender mix.
- No authorisation reference on a tender. No approval code, terminal id or card identifier is stored, so a card tender cannot be matched to an acquirer settlement line. Reconciliation against the acquirer is by total.
- No conflict resolution for the same unit sold twice offline. Two disconnected counters can both sell the last one; both sales sync and the stock position goes negative for a person to resolve.
- We do not supply tills, tablets, routers, terminals or UPS, and the equipment that actually determines whether you can trade in the dark is all on that list.
The second and third points together are the ones to weigh. If reconciling card takings line by line against your acquirer matters to you — and in a card-majority market it reasonably might — that reconciliation happens in your banking or acquiring tooling, not here, and you should confirm that before it becomes a month-end surprise rather than a design choice.
What is not built for South Africa today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in South Africa. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If SARS-shaped return output, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
SARS output and e-invoicing
VAT201-shaped return output from live records, a maintained rate history rather than a single preset, and e-invoicing against any prescribed interface — with retries, a failure queue and a reconciliation report.
Banks, EFT and card acquirers
Bank statement feeds, EFT and debit-order files, and card acquirer settlement reports pulled into the Payments Register so receipts match invoices without anyone re-keying a statement.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
EMP201 and EMP501 schedules, UIF declarations and COIDA returns produced in the layout your filing body expects, generated from live payroll records instead of rebuilt each month.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
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. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedThree questions worth asking a POS vendor in this region
Past the word "offline", which every vendor will say
When the power is off, what can I actually accept as payment?
What you are listening for
Cash, and an honest account of what happens to card.
How to read the answer
Any answer that implies card works offline is either about a stored-and-forwarded terminal that the acquirer has specifically enabled, or it is wrong. Ask which, and ask who carries the risk on a declined stored transaction.
What does the system store against a card tender?
What you are listening for
A method and an amount, or a method, amount and reference.
How to read the answer
If there is no reference, reconciliation against your acquirer is by daily total — perfectly workable, and worth knowing before you promise your auditor something else. If there is one, ask whether it is captured automatically from an integrated terminal or typed by a cashier, because a typed reference during a dark shift is not a control.
If two counters are offline and both sell the last unit, what happens?
What you are listening for
Both sales sync and the stock goes negative.
How to read the answer
This is the correct answer and an honest vendor gives it. A vendor who claims their system prevents it is describing a distributed lock they do not have; a vendor who has not considered it has not run a multi-till site through a real outage.
The short list, before the next scheduled window
Decide these once; they hold for every outage after
- The tender policy for the window is written, has a dated limit on it, and the counter staff have read it.
- The router and the card terminal have backup power, and someone has timed how long it actually lasts rather than trusting the label.
- Somebody has observed how long mobile data survives an outage at this specific site.
- Deliveries, cash-ups and counts are scheduled outside the published window as a standing rule, not case by case.
- The post-outage check has an owner: pending operations, card total against settlement, negative stock at the offline counters.
- One rehearsed outage has been run at this site — offline, trade, reconnect, reconcile — and what broke was written down.
The short version
Offline capture is the answer to a network problem, and a scheduled power cut is only partly a network problem. Your record survives it; your card acceptance does not, and in a market where the card is the majority tender that is where the money goes. Treat the published schedule as the gift it is: decide the tender policy in advance and put a number on it, put backup power on the terminal and the router before the till, move everything movable out of the window, and reconcile the card total against your acquirer afterwards rather than assuming. The equipment that determines whether you trade in the dark costs less than the software, and almost nobody buys it in the right order.
Frequently asked questions
Can we take card payments during load-shedding?
Only if the terminal has its own power and its own working connection, and that is a question for your acquirer rather than for your POS vendor. The point-of-sale software records that a card tender was taken; it does not authorise it, and no software can — authorisation belongs to the terminal, the network and the acquirer. If you intend to accept cards through an outage, the conversation to have is with your bank about a battery-backed, independently connected terminal and about who carries the risk on a transaction that is stored and later declined.
Should we just go cash-only during the window?
It is the simplest policy and often the right one, and it is not free: it means more cash in the drawer and more change going out, in a dark shop, at a time published in advance. Treat that as the security decision it is, cap it, and give the decision to a manager rather than to the person holding the drawer. The alternative — accepting cards on trust up to a stated limit — is also defensible, but only if the limit is a written number and somebody reconciles the total against the acquirer afterwards to find out what it cost.
Will sales made during an outage be missing from our reports?
Until they sync, yes — which is why the first task after the power returns is to confirm the device list shows no pending operations. Captured sales are held on the device and travel with their stock movements on reconnection, so the position corrects itself rather than needing manual repair. What does not correct itself is two disconnected counters both selling the last unit: both sales are valid, both sync, and the stock goes negative for somebody to resolve.
How do we reconcile card takings after an outage?
By total for the window, against your acquirer's settlement, because the tender record holds a method and an amount and no authorisation reference to match on line by line. That is workable and it is worth knowing in advance rather than at month-end. If line-level matching against your acquirer matters to your audit, it happens in your banking or acquiring tooling and you should confirm how before you need it.
Is this only a South African problem?
No. Scheduled supply interruption is a planning input across much of the region, and in Zambia and Zimbabwe the schedules are driven by hydrology rather than by generation capacity, which makes them seasonal and in some years longer. What differs is the tender mix: the further the market is from card majority, the more of your trade survives the window on cash. The planning is identical; the size of the loss is not.
