Designing for the tower that falls over at five o'clock

In a lot of the country, connectivity is not binary. It is fine at 10:00, unusable at 17:00 when the tower is congested, and gone entirely at stage 4. A payment app that treats the network as either up or down will be down for the busiest hour of the shop's day.

What can safely happen offline

Not everything. A wallet-to-wallet payment cannot be authorised offline, because the balance it draws on lives on the server and nobody can verify it from a handset. A card tap is different: the card itself carries the cryptographic material to authorise a small amount, which is why offline card acceptance is a real, certified thing, bounded by a floor limit.

• Card taps below R500 per transaction and R2 000 per terminal per day continue offline and clear on reconnect.
• The top twenty airtime, data and electricity products sell from a voucher cache held on the device.
• Everything else queues — up to 500 operations — and replays in order, each with an idempotency key so a retry can never double-charge.

The idempotency key is the whole safety net

Once you accept that a device will retry, you have to accept that the server will see the same instruction twice. Every financial write in the platform carries a key generated at the moment the shopkeeper pressed the button, and the server returns the original result for a repeated key rather than performing the work again. Without that, an offline queue is a machine for double-charging customers.

And when the problem is power, not signal

Software cannot fix a dead router. The Comms Box carries the shop's till network for about eight hours on battery across two carriers, and reports its own state back to us every minute — so a shop about to go dark shows up on our board before the shopkeeper picks up the phone.