All previews
Operations441 wordsnot yet seeded

Offline Authorization and Store-and-Forward Billing

Letting drivers charge without a backend means trusting them and trusting the charger's records. What has to be true for that energy to be billable afterwards.

Technically reviewed by Akhil Joy, CEO. Last reviewed 2026-09-01.

Offline operation is the difference between a network outage costing you some records and costing you every session at every affected site. It is also the mechanism by which energy is delivered with no confirmed way to charge for it.

Getting the balance right is a commercial decision with technical requirements, and most deployments inherit whatever the charger shipped with.

Three positions, chosen deliberately

Private, workplace and fleet sites usually suit cached authorisation. Public sites face the harder trade, and the right answer depends on how much unattributable energy the commercial model can absorb.

  • Refuse: no session without the backend. Billing is never at risk; a network outage is a total service outage.
  • Cached authorisation: the charger checks a stored list of permitted identifiers. Balances risk against availability.
  • Allow freely: anyone may charge. Maximum availability, some energy will be unattributable.

The cached list is only as good as its freshness

A stored authorisation list authorises drivers whose access has since been revoked and rejects ones recently added. How often it refreshes, and whether the charger was online to receive the update, determines how wrong it can be.

A stale list is worse than none, because it produces confident wrong answers rather than a known limitation.

What must be stored for a session to be billable

Storage is finite. What happens when it fills, whether the oldest records are discarded or new sessions refused, is a behaviour worth knowing before a long outage rather than after.

  • The identifier presented, so the session can be attributed.
  • Start and stop timestamps from a clock that was plausible.
  • Meter readings at start and stop, and interval readings if configured.
  • The tariff context, or enough information to determine it later.
  • A transaction identifier that will not collide with others.

Delivery on reconnect is where it fails

Stored transactions must arrive without being mistaken for current activity, with timestamps reflecting when the sessions happened. Platforms vary considerably in how they handle this: some accept backdated records cleanly, some reject anything outside a recent window, some accept them and bill at the current tariff.

The middle case loses revenue silently, and it is worth testing deliberately rather than discovering after an outage.

Clock accuracy becomes critical offline

While connected, a charger keeps its clock aligned to the platform. Offline it depends on its own timekeeping, and drift becomes error in the records it is storing.

For a short outage this is immaterial. For a long one, or on hardware without a reliable clock, timestamps may be wrong enough to affect time-of-use billing and dispute resolution.

Expect duplicates and detect them

A charger that does not receive an acknowledgement will resend. Duplicate delivery after an outage is normal, and a platform without duplicate detection will bill some drivers twice.

That costs more in trust than the recovered revenue is worth, which makes duplicate detection a requirement rather than a refinement.