How the platform works

Road runs EV charging. On the operator side it runs charging stations, the CPO role, a charging station management system. On the driver side it issues the cards and tokens people charge with, and bills for them, the eMSP role. Most customers run both, against the same accounts, and the two sides share one model that the rest of these docs build on.

The data model

Everything on the platform belongs to a Provider, the tenant. Under a Provider sit Accounts, and the Account is the unit that owns the working parts: users, charging infrastructure, cards and sessions. Billing settles on top of the Account.

• Provider is the top of the tree, the tenant a customer is set up as, and every other object is owned somewhere beneath it. A Provider can nest sub-providers for a group that sits over several underlying entities, and it may be a Private Label running the platform under its own brand, a single operator running only its own charging, or an eMSP. CPOs usually join a Provider as Accounts. Providers, accounts and users covers the variations.

• Account is where ownership and money sit. It owns the locations and the cards, carries the socket fees for its sites and the cost of the sessions its users run, and is the entity Road bills and reimburses.

• Users and administration. Users are the logins within an Account. There is no separate directory of administrators: a Provider administrator is simply a User whose roles are assigned at the Provider level rather than only within one Account. Roles decide what a user may do and at what scope, but the Account still owns whatever they create or spend.

• Location is a physical site, and it carries the policy for the stations on it: whether and how the site is reimbursed for the energy it delivers, and whether it is published to the roaming network so other networks' drivers can find and use it.

• EVSE Controllers and Connectors. An EVSE Controller is a charging station at a Location, speaking OCPP and identified by an evseId such as NL*EFL*EV*1234567; its Connectors are the individual plugs. Two kinds of money attach to a connector: its tariff sets what a charge costs the driver (a tariff profile applies one tariff across many stations), and its billing plan is the operator's monthly subscription for running that connector on Road.

• Charge Cards and Tokens are the eMSP side. A Charge Card, tag or app carries a Token, the credential a driver presents to charge. A token carries its own billing plan, which sets how the driver is charged for the energy they use.

• Authorising a charge. When a driver presents a token at a station, whether it may charge there is an authorisation check: the station and backend look the token up, usually over roaming against its home network, and allow or decline. A station can also carry an Access Group for local rules, such as letting a set of people charge for free there.

• Records of a charge. The operator side writes a CPO session, then sends it out over roaming as a CDR (Charge Detail Record, the standard billing record). If the token's eMSP is also on Road, that CDR comes back and becomes an MSP session for the driver's side. Road trades CDRs off the platform too: the eMSP side takes them in from other operators, and the CPO side sends them out to other eMSPs. The shape to remember:

  CPO session → CDR (over roaming) → MSP session

  A CPO session and an MSP session are two records of the same charge, linked by the CDR between them. Corrections are made with credit sessions, not edits.

From a tap to an invoice

A single charge runs like this:

1. A driver presents a Token at a Connector.
2. The station and backend authorise it: they check whether the token is allowed to charge there, usually over roaming against its home network, and allow or decline.
3. On approval the charge runs and is metered through to the end.
4. The operator side writes a CPO session and sends a CDR over roaming. If the token's eMSP is on Road, that CDR returns as an MSP session.
5. Billing settles it from those records. On the CPO side the issued CDR feeds a credit invoice that reimburses the station owner for the energy delivered, at the EVSE's tariff. On the eMSP side the received CDR is billed to the card's owner for usage, alongside their card subscription.

The same shape holds whether the charge happened on the customer's own network or, through roaming, on someone else's. Only who reimburses whom changes.

Two sides of one model

Every charge touches both roles: the CPO operates the station it happens on, and the eMSP serves the driver who runs it. Each keeps its own record of that charge.

The CDR is the link between them. Plenty of customers run both sides against the same Accounts, and the same cpo/msp split shows up across the model, on locations, billing plans and invoices as well as sessions.

Beyond the core

A lot of functionality hangs off the core model, and the later sections take each in turn: dynamic and scheduled pricing, billing plan management, EVSE hardware configuration and operational control (remote start and stop, reboots, availability), smart charging and load management, access control, payment terminals at the station, roaming connections, and campaigns and promotions.

Where to go next

• Account management for the tenancy model, sign-in and provisioning.
• Charging station operation for stations, connectivity and sessions.
• E-mobility services for cards, tokens and access.
• The API reference for every endpoint behind the model.

This section is the platform's own model. The roaming hub and ChargeNow are separate products with their own sections, and where the model touches roaming (tokens and CDRs) we note it and point onward rather than diving in here.