What goes wrong between roaming partners?
At the next stop, the provider's app shows a charger as available. On arrival it is taken, and a second one is out of order.
The driver charges at the third, and wonders why the app did not know.
The questionWhere can the exchange between two companies go wrong?
None of these is specific to one company; they come from data travelling between independent systems.
Keeping frictions small
- Frequent updates: status and tariffs pushed as they change, not once a day.
- Fallbacks: such as ALLOWED_OFFLINE, so a card works when the provider is briefly unreachable.
- Clean corrections: instead of silent changes.
- Shared versions: both partners on a current version, such as 2.3.0.
Failed sessions seen from the driver's side are the subject of EV charging fundamentals, stop 06.
Check your understanding
3 questions. Answer all of them to complete this stop. Each answer explains itself.
Why can an app show a charger as available that is already taken?
Charger, operator backend, OCPI, provider app: every step takes a little time.
A new card is refused at a partner's charger. What is a likely cause?
Without real-time authorisation, the operator only knows tokens that have been shared with it.
Partner A runs OCPI 2.2.1, partner B 2.3.0. What can they use together?
Partners negotiate a common version and use what it supports.
- Whitelist type OCPI's rule per token for cached or real-time authorisation: ALWAYS, ALLOWED, ALLOWED_OFFLINE or NEVER. Stop 04 Glossary
- Credit CDR A record that cancels a CDR already sent; OCPI does not allow CDRs to be deleted, so corrections run through credit CDRs. Stop 06 Glossary
- EVRoaming Foundation: OCPI 2.3.0, Tokens module: whitelist types and real-time authorisation. https://github.com/ocpi/ocpi/blob/2.3.0/release/core/mod_tokens.asciidoc. Checked 09 Oct 2026.
- EVRoaming Foundation: OCPI 2.3.0, CDRs module: credit CDRs, push and pull model. https://github.com/ocpi/ocpi/blob/2.3.0/release/core/mod_cdrs.asciidoc. Checked 09 Oct 2026.