OCPI 2.3.0 is the current released version of the Open Charge Point Interface, published by the EVRoaming Foundation in February 2025. It sits between the widely deployed 2.2.1 and the in-development 3.0, and — unlike some point releases — it is driven mostly by regulation: the EU’s AFIR rules for public charging and the need to serve markets, like North America, that the protocol had historically underserved. If you are new to the protocol, start with what OCPI is and the full OCPI version history before reading on.
This article walks through what is actually new in 2.3, why the regulatory context matters, and how operators should think about adoption. Everything below maps to the official OCPI 2.3 changelog; where the ecosystem is still settling, that is called out rather than glossed over.
The headline changes
A short list before we go deep:
- A new Payments module for direct, contract-free payment at the charger, built around a Payment Terminal Provider (PTP) role.
- Extensibility built in — OCPI 2.3 makes it possible to add modules, fields, and certain enum values without breaking existing implementations.
- A new Parking object linked to EVSEs, indicating the intended vehicle type and related properties.
- A new EVSE field indicating which eMSPs’ contracts are accepted at that charging point.
- Support for North American taxes, broadening the protocol beyond its European tax assumptions.
- Accessibility information for people with disabilities.
- A support telephone number field on the Location object.
- Credentials refinements — a new field to give the hub party ID, and hub clients now reported as normal credentials roles.
- Selected enum values pulled forward from the OCPI 3.0 draft, including values that signal ISO 15118 compatibility.
This is a targeted, largely additive release. Most 2.2.1 code keeps working; the new capability is opt-in and clustered around payment, pricing transparency, and regulatory reporting.
Why AFIR drove this release
To understand 2.3, you have to understand what regulators started requiring of public charging.
The EU’s AFIR (Alternative Fuels Infrastructure Regulation) sets obligations for publicly accessible charge points: drivers must be able to pay ad hoc, without a subscription or a specific app, and prices must be transparent at the point of charging. It also formalizes National Access Points (NAPs) — per-country data registries that aggregate charging infrastructure information.
OCPI 2.3 is, in large part, the protocol catching up to those obligations. The AFIR compliance picture (coming soon) is the connective tissue behind the Payments module, the pricing-transparency work, and the emphasis on NAP data exchange. If you operate public charging in Europe, this is not optional background — it is the reason the release exists.
North America has different but parallel pressures. The addition of North American tax support in 2.3 reflects a deliberate effort to make OCPI serve US and Canadian operators as first-class citizens rather than as an afterthought layered onto European assumptions.
The Payments module (the biggest addition)
The most significant new thing in OCPI 2.3 is a whole new module: Payments.
Historically, OCPI stayed out of payment. It told a CPO what to bill (via Tariffs and CDRs) but not how money moved; settlement happened out-of-band between roaming partners, and ad-hoc payment at the charger was handled by each operator’s own terminal integration. AFIR’s ad-hoc payment mandate made that gap a problem worth standardizing.
The Payments module introduces:
- A Payment Terminal Provider (PTP) role — a party that operates the physical card payment terminals at charging sites, which may be distinct from the CPO.
- A Terminal object — represents a physical payment device and maps it to the locations or EVSEs it serves.
- A Financial Advice Confirmation object — carries the settled transaction details (for example, total cost and electronic-funds-transfer data tied to an authorization reference) back to the CPO so it can produce correct invoices.
In practice, this lets a terminal operator and a CPO coordinate a direct, contract-free charge: the terminal reserves a pre-authorization amount, a session starts against an authorization reference, and the confirmed financial detail flows back so billing and receipts line up. It is worth being precise about scope — OCPI still is not a banking rail. It does not move money or replace card networks; it standardizes the data exchange around a payment that a terminal provider processes.
Pricing transparency, Tariffs, and CDRs
AFIR’s transparency requirement means a driver walking up to a public charger should be able to see what they will pay before they plug in, and get a clear breakdown afterward. OCPI 2.3 tightens the pricing path to support this.
The Tariffs and CDR shapes carry the pricing-transparency and tax detail that AFIR expects at the socket and on the receipt, and the North American tax support means the same records can express US and Canadian tax structures rather than only European VAT. If you want the mechanics of how pricing data itself is modeled, the Tariffs module and CDRs module deep dives cover the underlying dimensions; 2.3’s contribution is making that pricing legible and regulation-ready at the point of an ad-hoc, contract-free charge.
For operators without ad-hoc public charging or strict transparency mandates, these refinements are useful but low-urgency. For anyone running public AFIR-scoped infrastructure, they are the point of the release.
Parking, EVSE, and Location refinements
Several smaller additions make the location data richer and more useful for real deployments across both European and North American sites.
- A Parking object linked to EVSEs. It captures properties such as the vehicle type a space is intended for — relevant for sites that mix passenger cars with vans, trucks, or accessible spaces, whether that is a European motorway stop or a US truck-stop charging plaza.
- An EVSE field for accepted eMSP contracts. A charging point can now indicate which eMSPs’ contracts it accepts, which helps roaming apps show drivers where their subscription actually works.
- Accessibility information. OCPI 2.3 adds structured information for people with disabilities, so apps can surface accessible bays and facilities.
- A support telephone number on Location. A driver stuck at a broken charger now has a standardized place to find a number to call.
None of these are dramatic on their own, but together they close gaps that operators had been filling with non-standard extensions.
Extensibility and 3.0 alignment
Two forward-looking changes are worth noting because they shape how 2.3 ages.
First, OCPI 2.3 explicitly makes the protocol extensible: it becomes possible to add modules, fields, and certain enum values without breaking conformance. That is a structural shift — it means future capability can arrive incrementally rather than only at major version boundaries.
Second, 2.3 pulls forward selected enum values from the OCPI 3.0 draft, including values that signal ISO 15118 compatibility. This is a bridge, not a full 15118 integration: it lets 2.3 implementations start expressing 15118-aware concepts using enum values that will remain valid as the ecosystem moves toward 3.0. If you want the bigger picture on where the protocol is heading, see the OCPI 3.0 preview.
Credentials and roles
The Credentials handshake — how two OCPI parties register and exchange tokens — got a small but useful refinement in 2.3.
- A new field to provide the hub party ID, making hub relationships explicit in the credentials exchange.
- Hub clients are now reported as normal credentials roles, which simplifies how a hub’s connected parties are represented rather than treating them as a special case.
If you have questions about which roles exist in OCPI at all, the role set (CPO, eMSP, NAP, NSP, SCSP, and the new payment-focused PTP) predates most of this release; the 2.3 change here is specifically about how hubs and their clients surface in the credentials flow. For the mechanics of the handshake itself, the Credentials and Versions walkthrough covers the token exchange in detail.
What OCPI 2.3 does NOT do
It is as important to be clear about what did not change, because a lot of expectations get projected onto a new version.
- It is not a payments rail. The Payments module standardizes data exchange around a terminal-processed payment; it does not move money, hold funds, or replace card networks.
- It does not make ISO 15118 Plug & Charge mandatory. PnC remains optional. 2.3 adds enum values that signal 15118 compatibility, but a CPO can be fully 2.3-compliant without supporting Plug & Charge.
- It is not a customer-management or CRM API. How an eMSP manages its users is still out of scope.
- It is not the 3.0 architectural refresh. 2.3 borrows some 3.0 enum values but remains a 2.x release layered onto 2.2.1, not the larger redesign that 3.0 is expected to be.
Where OCPI 2.3 fits
Here is a compact view of how 2.3 sits between the version people run today and the one being drafted.
flowchart LR
A[OCPI 2.2.1<br/>widely deployed] --> B[OCPI 2.3.0<br/>Feb 2025<br/>Payments, AFIR pricing,<br/>NA taxes, extensibility]
B --> C[OCPI 3.0<br/>in development<br/>larger refresh]
style B fill:#dbeafe,stroke:#2563ebThe practical takeaway: 2.3 is the regulation-and-payments release. 2.2.1 remains the interoperability baseline most partners speak, and 3.0 is where the deeper structural change is expected.
Migration considerations
If you are weighing 2.2.1 to 2.3:
- It is mostly additive. Because 2.3 layers onto 2.2.1 and adds extensibility, existing modules keep working and new capability is opt-in. You are adding surface area, not rebuilding.
- Scope your driver by regulation. The clearest reasons to move are external: AFIR ad-hoc payment and price transparency in Europe, or North American tax handling. If neither applies, the urgency drops sharply.
- Coordinate with partners. As with any version bump, announce 2.3 on your Versions endpoint only when your implementation is solid, and roll out to one trusted partner first. The disciplined, phased approach that worked for the 2.1.1 to 2.2 migration applies here too.
- Plan for long dual-version support. Many partners will run 2.2.1 for years. Do not rush to deprecate it.
Who should move now — and who can wait
A few honest scenarios.
Move now if:
- You operate publicly accessible charging in the EU and must meet AFIR ad-hoc payment and price-transparency obligations.
- You need to report into a National Access Point and want the structured NAP-oriented data exchange.
- You are a North American operator or platform that needs proper tax handling in your tariffs and CDRs.
- You are a payment terminal provider or a CPO integrating one, and you want the standardized Payments module rather than a bespoke terminal integration.
Wait if:
- None of the 2.3-specific features map to a regulatory or commercial need you have today.
- Your key roaming partners are still solidly on 2.2.1 — moving ahead of them means maintaining both versions without realizing the benefit.
For a broader framing of where OCPI sits against the other protocols in the stack, the comparison of OCPI vs OCPP vs ISO 15118 is a useful companion.
Key takeaways
- OCPI 2.3.0 shipped in February 2025 and is the current released version, driven mainly by EU AFIR and by the need to serve North American markets properly.
- The marquee addition is the Payments module (PTP role, Terminal and Financial Advice Confirmation objects) enabling standardized direct, contract-free payment at the charger.
- Supporting changes include AFIR-ready pricing transparency, North American tax support, a Parking object, an EVSE contracts field, accessibility info, a Location support phone number, credentials/hub refinements, and built-in extensibility.
- It is largely additive over 2.2.1, does not make Plug & Charge mandatory, and is not the 3.0 refresh — though it borrows some 3.0 enum values, including ones that signal 15118 compatibility.
- Let regulation and payment needs, not novelty, decide your timing. For anything at the wire-level, read the official OCPI specification and changelog directly.