zevOS

01Operations

Why charging sessions fail — a taxonomy

Failed sessions are the clearest signal of network health and the least examined. Eight failure classes, how to tell them apart in the data, and which ones are actually your fault.

ENzevOS Engineering · Platform engineering
17 June 2026 · 3 min read

Every network has a failed-session rate. Few operators know theirs, because failure is not a single event — it hides in sessions that never started, sessions that started and delivered nothing, and sessions that delivered energy but never got paid for. Each of those has a different cause and a different owner.

The eight classes

1. Authorisation refused

The driver presented a tag or started from the app and was refused. Legitimate reasons — expired tag, insufficient balance, station not permitted for that group — should be distinguished from platform faults. The authorisation log should carry the reason, not just the rejection.

2. Payment failed before start

Usually the driver’s bank, sometimes the gateway. This is the largest category on public networks and mostly not your fault — but the abandonment rate after a failed payment attempt is entirely a function of how quickly you let them retry with a different method.

3. Cable or connector not seated

The session reaches Preparing and stops. The charger is fine, the driver did not push the gun home or the vehicle refused the lock. High rates on a specific unit usually mean a worn latch.

4. Vehicle refused the handshake

Common with certain vehicle and charger combinations, particularly on older CCS implementations. The signature is a session that starts, delivers zero energy, and ends within a minute — repeatedly, with the same vehicle model, across different chargers.

5. Charger fault mid-session

The genuine hardware failure. Energy was delivered and then the session terminated abnormally. These need refunds handled automatically and a fault attached.

6. Connectivity loss mid-session

The charger kept charging but the platform lost sight of it. If the charger buffers and replays the transaction on reconnect, this is a reporting delay rather than a failure. If it does not, you have a session with no stop record and a billing problem.

7. Meter values missing

Energy was delivered but not reported, so the session closes at zero or at an implausible figure. The most expensive class, because you either refund a genuine session or bill a driver for a number you cannot defend.

8. Payment capture failed after the session

Energy was delivered, the driver left, and the capture failed on a pre-authorisation that had expired or been released. Recoverable only through follow-up, so the real fix is authorisation sizing and capture timing.

Telling them apart in the data

SignatureLikely class
No StartTransaction, Authorize rejectedAuthorisation refused
No StartTransaction, no AuthorizePayment failed before start
Preparing → Available, no transactionCable not seated
Transaction < 60s, energy = 0Vehicle handshake
Energy > 0, StatusNotification FaultedCharger fault
StartTransaction present, StopTransaction late or absentConnectivity loss
Transaction long, energy = 0 or implausibleMeter values missing
Session complete, payment status failedCapture failed

Which ones are yours

Classes 1, 5, 6, 7 and 8 are the operator’s to fix. Class 3 is partly yours — hardware wear. Classes 2 and 4 belong to the driver’s bank and the vehicle respectively, but they still shape your reputation, so they belong in the report even if not in the remediation plan.

A network that measures this typically finds a failed-session rate between 4% and 12% and can move the operator-owned half of it substantially within a quarter. A network that does not measure it usually believes the rate is around 1%, because that is how many drivers bother to complain.

sessionsdiagnosticsdata

Get the next one by email

One email a month. Operations notes, unit economics and policy changes that affect your tariff.