> For the complete documentation index, see [llms.txt](https://docs.enapi.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.enapi.com/advanced-features/plug-and-charge-iso-15118.md). # Plug & Charge (ISO 15118) ENAPI fully supports Plug & Charge (PnC) based roaming over OCPI, implemented according to the best practices of the EV Roaming Foundation white paper [*ISO 15118 Plug and Charge Authentication Support in OCPI*](https://evroaming.org/wp-content/uploads/2025/04/EVRF-Whitepaper-ISO15118-Plug-and-Charge-Authentication-Support-In-OCPI.pdf). You can roam using PnC through the ENAPI Transaction Broker on any supported OCPI version. ### How Plug & Charge works over OCPI PKI and certificate provisioning happen independently of the roaming protocol. OCPI is agnostic to the underlying PnC PKI service, so certificate handling stays out of scope of the roaming connection. At the charge point, the vehicle presents its contract certificate, the CPO validates it, and extracts the **EMAID** (the e-Mobility Account Identifier embedded in the certificate). The EMAID is the only identifier needed to authorize the session: roaming data is exchanged only after the EV-to-EVSE communication is established and the certificate has been validated. Two OCPI modules carry PnC: * **Tokens** — represents and authorizes the PnC contract via its EMAID. Because PnC requires online authorization, ENAPI routes a real-time authorization request to the MSP for each session rather than relying on a pushed token whitelist. * **Locations** — advertises whether a connector supports PnC, so drivers can make an informed decision before navigating to a charge point. ### Version support PnC works across all OCPI versions ENAPI supports. The mechanics differ by version: * **OCPI 3.0 / 2.3.0 (native support)** — `EMAID` is a dedicated `TokenType`. The Token `uid` and `contract_id` are set to the EMAID, and the recommended `authorization_policy` is `ASK_DEFAULT_DENY` to force online authorization. On the Locations side, the connector `capabilities` field carries `ISO_15118_2_PLUG_AND_CHARGE` and/or `ISO_15118_20_PLUG_AND_CHARGE`, set by the CPO when the hardware, EVSE configuration (including PnC PKI leaf certificates), and backend onboarding all support PnC. * **OCPI 2.2.1 and below** — these versions predate dedicated PnC support. Following the EVRF recommendation, the Token `type` is set to `OTHER` with `uid` = EMAID (which matches `contract_id`/`auth_id`), and `whitelist = NEVER` to enforce online authorization. Connector PnC capability is back-ported using the `capabilities` field as defined from 2.3.0 onwards. If you need to move a PnC-enabled connection between versions, [contact us](mailto:support@enapi.com) — the upgrade path is straightforward. ### EMAID normalization **This is where ENAPI removes a recurring source of failed Plug & Charge authorizations.** The EMAID is defined in ISO 15118-1 with optional separators and an optional check digit, so the same contract can be represented in several valid but non-identical ways: ``` DE-ABC-C12345678-X (with separators and check digit) DEABCC12345678X (canonical: no separators, with check digit) DEABCC12345678 (no check digit) deabcc12345678x (lower case) ``` In practice, parties implement these representations inconsistently. One side may emit EMAIDs with hyphens while the other expects them without; case handling and the check digit vary further. When roaming PnC over OCPI **outside of ENAPI**, this regularly causes authorization requests to fail or route to the wrong party, because a literal string comparison of two valid EMAIDs for the same contract does not match. ENAPI solves this at the platform layer. We **normalize EMAIDs on both inbound and outbound traffic and convert them into the format each receiving partner expects**, so authorization requests match and route reliably regardless of separator, check-digit, or case differences between counterparties. This is applied uniformly across the platform: * Normalization is internal: the data your platform sends and receives is preserved, and you continue to work in your own representation. In line with the EVRF recommendation, we encourage partners to transmit EMAIDs **with the check digit and without separators** — a 14-character alphanumeric string. ENAPI does not require it: if your representation differs, we normalize it for you, giving every partner full interoperability across the roaming ecosystem. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.enapi.com/advanced-features/plug-and-charge-iso-15118.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.