Home-network sessions often work. Roaming is where things get flaky. Same driver, same app, different result on the next highway stop.
This post walks through the authorization path, the error classes drivers actually see, and what we do about it on the eMSP side — plus what operators can fix so every app on the network looks better.
The authorization path (simplified)
- Driver starts in the eMSP app.
- eMSP sends auth to a roaming hub (or a direct OCPI peer).
- Hub reaches the CPO.
- CPO tells the charger to allow energy.
- Status and CDR flow back for billing.
Any hop can fail: wrong token, hub downtime, unknown location ID, slow path to the station. From the driver’s seat it is usually one of a few screens: rejected, timeout, or start failed.
Common error classes
| What the driver sees | Typical cause |
|---|---|
| Authorization rejected | Token not allowed on that network |
| Timeout | Hub or CPO too slow |
| Start failed | EVSE offline after auth succeeded |
| Price unknown | Tariff not published for that EVSE |
We map these to human copy in the app whenever we can. “Error 503” is not a product. See also Charger won’t start .
What we do about it
- Validate tokens and contract eligibility before the driver relies on a weak path when we can.
- Prefer direct integrations for high-volume CPOs where hubs add latency without benefit.
- Show the real failure class in the app, not a generic failure.
- Auto-suggest nearby stations that use a healthier path when a start fails.
None of this replaces CPO uptime. It reduces the number of times a healthy station looks broken because of the path in front of it.
For operators
If your OCPI locations and EVSEs are stale, or your auth endpoint is slow under load, every eMSP’s drivers will blame their app. Roaming quality is shared infrastructure: accurate IDs, fast auth, and honest status help the whole market.
What’s next
Drivers who need the full start checklist should read Charger won’t start . Operators connecting hardware should read OCPP for operators .