Inside the page
OCPI is a protocol. Roam OCPI is the product Plugsurfing built on top of it. Senior Product Manager Sofia Stadler explains what that means in practice.
OCPI is a protocol the EV charging industry already uses. Roam OCPI is the product Plugsurfing built on top of it. The difference between those two things is where most of the interesting work lives.
We sat down with Sofia Stadler, Senior Product Manager at Plugsurfing, to walk us through how that product layer actually works: what comes in from charge point operators, how it is checked, and what happens when it doesn't line up.
This is the third interview in our Roam OCPI series. Matias Heiskala covered what customers get commercially. Aaron Rubenstein covered the operations work behind the network. This one goes one layer deeper into the product itself.
OCPI and Roam OCPI are not the same thing
OCPI is an industry standard protocol developed by the EV Roaming Foundation. It defines how systems exchange data such as locations, tariffs, tokens, session commands and charge detail records. Plugsurfing did not invent OCPI, and we are far from the only company using it.
Roam OCPI is how Plugsurfing shares its managed roaming network through that protocol. Plugsurfing has more than one hundred of direct OCPI-connections and also converts non-OCPI HUB connections to the OCPI standard, so EMP partners only need to work with the OCPI protocol and with one single connection. In the OCPI relationship, the partner connects on the EMP side, and Plugsurfing connects on the CPO side.
"Through one connection, you get our entire network of over 800 CPOs and a million chargers. We manage all the connections, the relationships with the CPOs, the invoice reconciliation, the CDR verification. The partner gets one invoice per country instead of hundreds."
That list is the difference between a connection and a product. The protocol makes communication possible. The product is what lets that communication scale in two directions at once: across the roaming network behind one CPO-side connection, and across the partners using Roam OCPI to reach it.
Who Roam OCPI is built for
Roam OCPI is built for partners who already operate their own EMP layer. Their own app, their own backend, their own users, their own payment setup, their own end-user pricing. What they need from Plugsurfing is the managed roaming network behind it.
"A typical Roam OCPI customer already has their own network and wants to extend it. They know how to take care of their users and the user journey. Roaming just isn't their main thing, and it doesn't have to be."
That maturity is what separates Roam OCPI from our other products. For a deeper look at the commercial model and the merchant-of-record setup, Matias covered it in the previous interview.
Why CDRs and tariffs are the hard part
The CDR (charging detail record) is both a technical record and a commercial trigger. It tells the partner what happened in the session, and it gives them the data they need to charge their own end customer.
Receiving a CDR is rarely the difficult part. Verifying whether it was calculated correctly against the tariff data available at the time of the session is. Sofia broke the typical issues into three groups.
Tariff structure interpretation
Some CPOs have complex tariff structures, and the order and nesting of tariff elements can change how the final price should be read. Two systems can look at the same tariff object and arrive at different totals if they apply the rules differently.
"We sometimes interpret a CPO's tariff structure differently than their CPMS does. Tariffs can be complex, and some CPOs have very layered structures. Reading them correctly according to OCPI is something we've spent a lot of time getting right."
Wrong order of arrival
Let's look at this through an example: a CPO sends a new tariff at midday. The connector-to-tariff mapping arrives at 5pm. Sessions happen between noon and 5pm. The CPO then invoices those sessions using the new tariff, but at the time of the session there was no way to know which connectors should use it.
Illogical session data
Timestamps in the future. A start time after the stop time. Energy or duration values that are not physically possible. These often come from chargers that went offline mid-session and the meter values get distorted.
When Plugsurfing rejects a CDR because the data is unreliable, it is not forwarded to the Roam OCPI partner as a usable session record. Instead, it moves into operational follow-up, particularly if the rejected session later appears on a CPO invoice. Aaron covered that work in the previous interview.
How is it evolving?
We launched Roam OCPI in the spring of 2025, and we've been busy making it even better for our customers. Four product improvements have landed since the start of 2026: three in the first half of the year, and one more over the summer.
Authorization control
Previously, Plugsurfing shared all tokens on what is called "allowed offline" behavior, where the CPO has the right to accept a session if communication fails between the systems. Partners can now choose "whitelist never" instead, which requires real-time authorization on every session and removes that fallback. Plugsurfing also improved the surrounding authorization settings, including timeout configuration and explicit allow-or-deny behavior when authorization fails.
Live session updates
Roam OCPI now supports ongoing kWh updates during a session. Partners can display real-time consumed energy in their end-user app, and use it for incremental card pre-authorization (extending the reservation as the session passes set kWh thresholds).
Networks with extra requirements
Tesla is the most concrete example: idling fees, congestion fees, and additional session statuses that let the partner app notify the user when those conditions apply. None of those map cleanly onto standard OCPI fields, so they are added as optional fields available on Roam OCPI. Only customers receiving the specific network will receive sessions with the non-standard OCPI fields.
Partners need to sign a specific amendment to receive Tesla once it is available. This work will scale to other networks with similar extra requirements.
Routing headers for parallel pull jobs
Roam OCPI now supports up to five parallel jobs when partners are pulling for location updates. This enables processing, so that the partners can ensure that their network is always up-to-date.
What makes it scale
OCPI is the main protocol the industry uses, but it's not the only one, and complete European coverage isn't reached through OCPI connections alone. What turns Roam OCPI into a product is the scale and the work that happens around it: converting more than one hundred OCPI connections plus non-OCPI connections into one single Roam OCPI connection, validating CDRs, catching tariff interpretation problems, and managing invoices and CPO relations.
That work is the same for every Roam OCPI customer. The protocol gets you the language. The product is everything that happens once the language is in place.
Want to talk about how Roam OCPI fits your setup?
