Connectivity failure is not an exceptional condition for a charging network. It is a routine one, and the interesting question is not whether it happens but what the charger does about it.
A charger that refuses to charge when offline protects billing integrity and frustrates drivers. A charger that charges freely and forgets protects the driver experience and loses revenue. Most operators want something between the two and never specify which.
Three positions on offline behaviour
There is no correct answer. There is only the answer your commercial model can absorb, and it should be a decision recorded in the configuration rather than whatever the charger shipped with.
- Refuse: no session starts without the backend. Billing is never at risk, and a network outage becomes a total service outage.
- Allow with local authorisation: the charger checks a cached list of permitted identifiers and starts if it matches. Balances risk against availability.
- Allow freely: anyone may charge. Maximises availability and accepts that some energy will be unattributable.
The cached authorisation list
Chargers can hold a local list of identifiers that remain valid while offline. Its usefulness depends entirely on how current it is, which depends on how often the platform refreshes it and whether the charger was online to receive the update.
A stale list is worse than no list, because it authorises drivers whose access has been revoked and rejects ones recently added, both of which produce support calls that are difficult to explain.
What the charger must record
A session that occurs offline still needs to be billable afterwards. That requires the charger to store the transaction locally with everything the platform would have received: identifiers, timestamps, meter readings at start and stop, and any interval readings taken during the session.
Storage is finite. A long outage on a busy charger can exhaust it, and what happens then, whether the oldest records are discarded or new sessions refused, is a behaviour worth knowing before it matters.
Reconnection is where it goes wrong
On reconnect, the charger must deliver its stored transactions without the platform mistaking them for current activity. Timestamps must reflect when the sessions actually happened rather than when they were reported, and the platform must accept records that are hours or days old.
Platforms differ considerably in how gracefully they handle this. Some accept backdated transactions cleanly. Some reject anything outside a recent window. Some accept them but bill them at the current tariff rather than the one in force at the time.
Clock accuracy becomes critical
While online, a charger can keep its clock aligned to the platform. While offline, it depends on its own timekeeping, and any drift becomes error in the transaction records it is storing.
For a short outage this is immaterial. For a long one, or on hardware without a reliable real-time clock, the stored timestamps may be wrong enough to affect time-of-use tariffs and dispute resolution.
The reconciliation obligation sits with the platform
Once records arrive, someone has to merge them into the billing view, apply the correct tariff for the period they cover, and detect duplicates where a charger delivered the same transaction twice after an uncertain acknowledgement.
Duplicate delivery is common and expected. A platform without duplicate detection will bill some drivers twice, which costs more in reputation than the energy was worth.
What to specify
These six answers determine whether an outage costs you sessions, revenue, or driver trust. Most deployments discover their answers after the first significant outage rather than before.
- The offline authorisation position, chosen deliberately rather than inherited.
- How often the local authorisation list refreshes.
- How many transactions the charger can store, and what happens when full.
- Whether the platform accepts backdated transactions, and how far back.
- Which tariff applies to a session billed after the fact.
- How duplicates are detected and resolved.