Paying when there is no network at all

Networks fail at the worst possible moments: market day, the hour before closing, the afternoon everyone is paid.

When the signal goes, digital payment stops and everyone returns to cash — which is exactly when a trader is carrying the most of it.

The obvious fix and its obvious hole

Let the two phones agree between themselves and synchronise later.

This works beautifully until somebody realises they can make the same offline promise to four different merchants in four different parts of the market, and be gone before any of the phones find a signal.

Offline payment is easy. Offline payment that is not a double-spend machine is the actual problem.

A signed, counted promise

The payer’s phone produces a promise carrying the amount, a nonce and a per-device counter, signed by the device’s enrolled key.

The merchant’s phone verifies that signature with no network at all. It cannot fabricate a promise, because it does not hold the payer’s key.

The nonce means a replayed promise is recognised. The counter means a gap is visible: if a device synchronises promises 41, 42 and 44, somebody is holding 43 and the system knows to look for it.

The honest part

You cannot make offline spending risk-free. Anybody claiming otherwise is selling something.

What you can do is bound the exposure and tell the truth about it:

• Limits cap how much can be promised offline before synchronising.
• Expiry means an unsynchronised promise does not sit forever as an open claim.
• Counter gaps are listed per device, so a phone that has stopped synchronising is visible rather than assumed healthy.
• And both sides see the words pending confirmation rather than a green tick.

That last one matters most. A merchant who knows a payment is a promise can decide whether to hand over the goods based on the size and the customer. A merchant shown a tick that means nothing has been lied to.

Which is still better than cash

Cash on market day means carrying notes through a crowd and keeping them overnight. A signed promise from an enrolled device, pending confirmation, bounded by a limit, is a smaller risk than a full cash box — and considerably smaller than a screenshot on a stranger’s phone.

When the signal returns

Promises synchronise and settle. Both sides see the payment move from pending to settled, and the merchant sees the money.

The sale happened when the customer was standing there. The settlement happened when the network allowed it. Those are two different events, and the product does not pretend they are one.

What you can check

These are facts about the running platform, not adjectives. Each one is visible in the product, in the API reference or in the ledger.

• A promise is signed by the payer’s enrolled device key, so it cannot be fabricated by the merchant’s phone.
• Each promise carries a nonce and a per-device counter; a replayed promise is recognised and a missing counter value shows as a gap.
• The pending state is shown to both sides in plain words rather than being presented as a completed payment.
• Promises have an expiry, so an unsynchronised promise does not sit indefinitely as an open claim.
• Counter gaps are listed per device, so a device that has stopped synchronising is visible rather than assumed healthy.

What it costs

No additional charge. The payment is priced as an ordinary payment when it settles.

Is it switched on?

Whether this is available depends on the authorisations in place and on what the administrator of a given deployment has switched on. That changes, and an article does not — so the live answer lives on the feature page, which reads it from the platform itself: Offline payments on the features page.

Read next

• BitriQR payments — One code on the wall. Every payer it can reach.
• USSD and SMS — No smartphone. No data. Same account.
• BitriPay Lite — Works on the connection you actually have.