Most payment systems assume the network is always there. At a stadium gate on match day, or a festival bar three fields from the nearest cell tower, it simply isn't. Connectivity browns out exactly when transaction volume peaks — and a terminal that stops taking payments the moment it loses signal is worse than no terminal at all.
The network is an optimization, not a dependency
We design terminals to clear a tap locally first and reconcile with the backend later. Each device carries a tamper-resistant secure element holding a signed balance, a monotonic counter, and a set of risk limits issued the last time it was online. A tap is authorized against that local state in well under a hundred milliseconds, with no round trip. The backend is treated as an eventual destination for the record, not a gatekeeper for the sale.
Offline authorization only works if the rules are conservative. Each card or wristband carries a per-transaction cap, a cumulative offline ceiling, and a velocity limit; exceed any of them and the terminal forces an online check or declines. These thresholds are set per event from the expected spend profile, so the worst-case exposure of a fully disconnected venue is bounded and known before the gates open.
Store, forward, and reconcile
Every authorized tap is written to an append-only queue on the device, each entry idempotent and signed. When connectivity returns — Wi-Fi, cellular, or a staff device walking the floor as a courier — the queue drains to the settlement service, which deduplicates on each entry's stable identifier. Because writes are idempotent, replaying the same batch twice changes nothing, which means we can retry aggressively without any risk of double-charging.
Treat the network as an optimization, not a dependency. The sale already happened; syncing it is just bookkeeping.— Protocore · Payments engineering
The hardest problems are the unglamorous ones: a terminal losing power mid-write, a wristband used at two bars inside the same offline window, a clock that drifts over a long shift. We handle them with atomic journaled writes that survive a brown-out, conflict resolution that favors the venue's recorded ledger, and counters that are signed rather than trusted. None of it is exotic. It is the same discipline distributed systems have used for decades, applied to a device that happens to fit in one hand.
On a recent cashless deployment we cleared €2.4M across roughly 80,000 attendees over three days, with stretches where whole zones ran offline for minutes at a time and not a single attendee noticed. That is the goal: the resilience should be invisible. The person tapping to buy a drink should never learn that the network was the most fragile thing in the building.
Have a system to build?
Tell us the problem. We'll come back with an architecture and a plan.
Start a project