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 2.2.1, the current mainstream release, and the in-development 3.0. What makes it unusual for a point release is the driver. Most of 2.3 exists because of regulation: the EU’s AFIR rules for public charging, plus tax and reporting structures that the protocol’s European origins had left unmodelled. 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 new in 2.3, why the regulatory context matters, and how to think about adoption. Everything below maps to the official OCPI 2.3 changelog.
The headline changes
The short version:
- 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 carries the hub party ID, and hub clients are 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. Existing modules keep their 2.2.1 shape, and the new capability is opt-in, 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), the 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 created a different pull on the same spec. Adding North American tax support means a tariff and a CDR can express US and Canadian tax structures directly, instead of forcing a VAT-shaped field to carry a sales tax, a state tax, and a municipal surcharge in one number.
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 turned that gap into something worth standardizing.
The Payments module introduces:
- A Payment Terminal Provider (PTP) role for the party that operates the physical card terminals at charging sites, which may not be the CPO.
- A Terminal object representing a physical payment device and mapping it to the locations or EVSEs it serves.
- A Financial Advice Confirmation object carrying settled transaction details (total cost, plus 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. Be precise about the scope, though. OCPI still is not a banking rail: it does not move money, hold funds, 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 plugging 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. If you want the mechanics of how pricing data itself is modeled, the Tariffs module and CDRs module deep dives cover the underlying dimensions. What 2.3 contributes is making that pricing legible and regulation-ready at the moment of an ad-hoc, contract-free charge, when there is no account and no app to fall back on for the price display.
If you run no ad-hoc public charging and face no transparency mandate, these refinements are useful but low-urgency. For AFIR-scoped public infrastructure, they are the point of the release.
Parking, EVSE, and Location refinements
Several smaller additions make the location data richer for real deployments on both continents. Each one maps into the Locations module you already publish.
- A Parking object linked to EVSEs. It captures properties such as the vehicle type a space is intended for. That matters wherever a site mixes passenger cars with vans, trucks, or accessible bays, whether the site is a European motorway stop or a US truck-stop plaza.
- An EVSE field for accepted eMSP contracts. A charging point can now indicate which eMSPs’ contracts it accepts, which helps a roaming app show a driver where their subscription actually works. It complements, rather than replaces, the authorization path in the Tokens module.
- 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 is dramatic alone. What they replace is worth naming: before a field exists, the same information travels as a custom extension, a convention buried in a free-text description, or an out-of-band spreadsheet, and each of those has to be negotiated separately with every partner.
Extensibility and 3.0 alignment
Two forward-looking changes shape how 2.3 ages.
First, OCPI 2.3 explicitly makes the protocol extensible: modules, fields, and certain enum values can be added without breaking conformance. That is a structural shift, because it means new capability can arrive between major versions rather than only at them.
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 rather than a full 15118 integration. It lets a 2.3 implementation start expressing 15118-aware concepts using enum values that stay valid as the ecosystem moves toward 3.0. For 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, so a hub’s connected parties are represented the same way everything else is, instead of as a special case.
The role set itself (CPO, eMSP, NAP, NSP, SCSP, and the new payment-focused PTP) mostly predates this release. The 2.3 change is specifically about how hubs and their clients surface in the credentials flow. For the mechanics of the handshake, the Credentials and Versions walkthrough covers the token exchange in detail.
What OCPI 2.3 does NOT do
Being clear about what did not change matters, because a lot of expectations get projected onto a new version number.
- 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 an implementation can be fully 2.3-compliant without it. The end-to-end Plug and Charge flow (coming soon) sits in a different layer of the stack entirely.
- 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.
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/>current mainstream release] --> B[OCPI 2.3.0<br/>February 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:#2563eb2.3 is the regulation-and-payments release. 2.2.1 is the current mainstream release, so it is the version to assume in a new integration until a partner tells you otherwise, and 3.0 is the in-development major version where the architectural rework is scoped.
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.
- Check what your partner actually runs. Version strings are not tidy. 2.2 (March 2020) and 2.2.1 (June 2020) are distinct releases, and some implementations sit on 2.2; the 2.2 versus 2.2.1 differences explain why that matters before you assume a partner is on the newer one.
- Coordinate the rollout. 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 phased approach that worked for the 2.1.1 to 2.2 migration applies here too.
- Budget for dual-version support as a steady state, not a transition. A partner upgrades when a 2.3 feature maps to an obligation it carries, and that clock is theirs, not yours. Your 2.2.1 endpoint stays live until every partner has its own reason to move.
Who should move now and who can wait
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 model North American tax structures.
- 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 and 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.
One thing worth internalizing before you upgrade: the version you advertise on your Versions endpoint is a promise, not a badge. A partner that reads 2.3 there may start sending you Terminal objects and Financial Advice Confirmations, and a 404 or a silent drop on those is a billing problem, not a compatibility footnote. Announce the version after your implementation can answer for every module it implies, and read the official OCPI specification and changelog at the wire level before you commit to a date.