Definition
OCPI (Open Charge Point Interface) is an electric vehicle charging industry standard protocol maintained by the EV Roaming Foundation, used for data exchange and interoperability between Charge Point Operators (CPO) and e-Mobility Service Providers (eMSP). OCPI defines RESTful API specifications for modules such as charging stations, charging points, sessions, CDRs (Charge Detail Records), authorization, and pricing, allowing users of different operators to charge at each other's networks and achieve unified settlement. In line with the interoperability concept, OCPI is the fundamental protocol for building cross-border charging networks.
Technical Features and Architecture
OCPI technical features include: Modular design — Version 2.2 covers modules such as CDRs, Locations, Sessions, Tokens, Commands, etc.; Role separation — CPO manages charging points and real-time status, eMSP manages users and authorization; Two-way communication — Supports real-time status push and command issuance; Version evolution — Continuous iteration to support new payment methods, metering and charging management requirements. In a typical architecture, the charging platform functions as the CPO-side OCPI Server, interfacing with the eMSP's OCPI Client; charging stations report sessions and CDRs to the platform through data feedback .
In cross-border scenarios, OCPI needs to coordinate with multiple currencies, languages, time zones, and the compliance requirements of local charging operation platforms .
Application in IoT and cross-border scenarios
The application of OCPI in IoT and cross-border scenarios includes:Cross-border charging roaming—— Users can use a charging card or app from one country to charge in another country Charging Station Through OCPI for authorization, billing, and settlement;Aggregation platform—— Charging aggregators connect with multiple CPOs, displaying available chargers and prices uniformly through OCPI;Fleet and logistics—— When electric logistics vehicles and buses operate across borders, they access local charging networks via OCPI;Energy and power grid——with Demand Side Management, combined with orderly charging, achieves load regulation. SimtoLink provides IoT devices such as EV charging stations One SIM for Multiple Countries Connection ensures the stable transmission of OCPI data in cross-border scenarios.
How Sessions and Bills Are Split in OCPI Roaming
The Open Charge Point Interface splits cross-border charging into items that can be checked on their own. Locations and tariffs tell an e-mobility provider where a driver can charge and at what price. A token answers whether that user is authorized at this moment. Commands start or stop a session remotely. The session describes the process while it is running. Only the closed charge-detail record is the voucher that settlement uses afterward. The charger's IoT connection delivers energy, status, and the reason for ending to the operator platform. The interface itself does not replace the local protocol between the charger and that platform. Roaming has succeeded when the token is accepted on the visited network, the session can open and close, and both sides can match the detail record by the same identifier.
A roaming record that can be settled must at least tie together the token identifier, the session identifier, and the detail-record identifier. Start time, end time, energy, total cost, and currency should come from the same closed session. If real-time authorization fails, do not first create a detail record with no session in order to fill the books. If a charger on the visited network is briefly offline, the session may stay local, but the upload should keep the start and end times from the charger's own clock, not the time the platform received the message. Both sides should interpret the status words for that session according to the agreed version, so one side is not still in progress while the other has already written completed.
Version and Role to Fix Before Roaming Opens
Roaming is ready to open when both sides have written down the protocol version, whether each party is the operator or the e-mobility provider, the endpoint addresses, how credentials rotate, and which business entity is acting. Different versions change module fields and enumerations. A lower-version client cannot read objects that exist only in a higher version. If the roles are reversed, location data is pulled from the wrong side and commands are sent to a side that does not control the chargers. Currency, tax, and the parts of the energy price must be complete in the tariff module. Do not leave the unit price in an offline spreadsheet and pass only a total through the interface. If the visited country has its own invoice or data-retention rules, the business agreement should say which party issues the local document. The interface only keeps the record traceable.
Time Zone, Currency, and Token Expiry
A common mistake is to treat time as a string with no time zone. In cross-border reconciliation the start and end then differ by hours, and the energy interval no longer lines up. Another is to keep accepting a token after its cache has expired, or to reject every token when a cache refresh fails, so the whole site cannot start. A detail record pushed before the session has ended cannot be recognized later, when more energy is appended, as the same item. A start command sent again after a timeout may open a second session on the charger while the cost is still booked to the first token. If the currency code and the minor currency unit disagree, an integer amount is scaled up or down. Use the detail record from the closed session as the settlement basis, give the authorization cache an explicit expiry, and deduplicate repeated commands with the same command identifier.
Interface logs should also keep the version number, the module the request belongs to, and the status code returned by the other side. A successful call without those fields cannot show, during cross-border reconciliation, whether the failure was in the token, the command, or the detail record. A broken charger connection and an interface rejection must be recorded separately. The first waits for the device to report the session later. The second is corrected from the status code and sent again. Do not fold the two failures into one retry.
A resend of the same session must carry the original session identifier, and the receiver updates the record that is not yet closed. A detail record that has already entered settlement accepts only a correction message, not a second independent bill.