EMVCo Electric Vehicle Open Payments Use Case

EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case Version 1.0 March 2026 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Legal Notice Page i / vii This document is subject to change by EMVCo at any time. This document does not create any binding obligations upon EMVCo or any third party regarding the subject matter of this document, which obligations will exist, if at all, only to the extent set forth in separate written agreements executed by EMVCo or such third parties. In the absence of such a written agreement, no product provider, test laboratory or any other third party should rely on this document, and EMVCo shall not be liable for any such reliance. No product provider, test laboratory or other third party may refer to a product, service or facility as EMVCo approved, in form or in substance, nor otherwise state or imply that EMVCo (or any agent of EMVCo) has in whole or part approved a product provider, test laboratory or other third party or its products, services, or facilities, except to the extent and subject to the terms, conditions and restrictions expressly set forth in a written agreement with EMVCo, or in an approval letter, compliance certificate or similar document issued by EMVCo. All other references to EMVCo approval are strictly prohibited by EMVCo. Under no circumstances should EMVCo approvals, when granted, be construed to imply any endorsement or warranty regarding the security, functionality, quality, or performance of any particular product or service, and no party shall state or imply anything to the contrary. EMVCo specifically disclaims any and all representations and warranties with respect to products that have received evaluations or approvals, and to the evaluation process generally, including, without limitation, any implied warranties of merchantability, fitness for purpose or noninfringement. All warranties, rights and remedies relating to products and services that have undergone evaluation by EMVCo are provided solely by the parties selling or otherwise providing such products or services, and not by EMVCo, and EMVCo will have no liability whatsoever in connection with such products and services. This document is provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in this document. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT, AS TO THIS DOCUMENT. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to this document. EMVCo undertakes no responsibility to determine whether any implementation of this document may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of this document should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, this document may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement this document is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party's infringement of any intellectual property rights in connection with this document. © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page ii / vii Revision Log – Version 1.0 This is the first published version of this document. © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page iii / vii Contents Legal Notice...................................................................................................................i Revision Log – Version 1.0 ........................................................................................ ii Contents...................................................................................................................... iii Tables .......................................................................................................................... vi Figures ....................................................................................................................... vii 1 Introduction ........................................................................................................... 1 1.1 Scope ............................................................................................................ 1 1.2 Constraints .................................................................................................... 1 1.3 Audience ....................................................................................................... 2 1.4 References.................................................................................................... 2 1.4.1 Normative References ....................................................................... 2 1.4.2 Published EMVCo Documents .......................................................... 3 1.5 Definitions ..................................................................................................... 3 1.6 Notational Conventions................................................................................. 4 1.6.1 Abbreviations ..................................................................................... 4 1.6.2 Terminology and Conventions........................................................... 5 2 Overview ................................................................................................................ 6 2.1 EV Open Payments Entities ......................................................................... 7 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.1.7 MO PKI Service Provider................................................................... 7 EV Open Payments (EVOP) eMSP................................................... 7 Electric Vehicle (EV) .......................................................................... 8 Charging Station (CS)........................................................................ 8 Charging Station Operator (CSO) and Charging Station Management System (CSMS) ................................................................................ 8 SRC System ...................................................................................... 9 Authorisation Entities ......................................................................... 9 2.2 Using SRC to Enable EV Open Payments................................................... 9 2.2.1 Onboarding Plug and Charge Ecosystem Entities............................ 9 2.2.2 SRC System Functions ..................................................................... 9 3 EV Open Payments Use Case ........................................................................... 11 3.1 Enrolment and Binding ............................................................................... 11 3.1.1 3.1.2 3.1.3 Preconditions ................................................................................... 11 Assumptions .................................................................................... 12 Sequence Diagrams ........................................................................ 12 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page iv / vii 3.1.4 Card Enrolment API......................................................................... 14 3.1.5 Add Consumer Identities API .......................................................... 14 3.2 EVOP eMSP Contract Certificate LCM ...................................................... 14 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 Preconditions ................................................................................... 15 Assumptions .................................................................................... 15 Sequence Diagrams ........................................................................ 15 Add Consumer Identities API .......................................................... 18 Unbind App Instance API ................................................................ 18 Delete Card API ............................................................................... 18 3.3 Checkout ..................................................................................................... 19 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.3.6 Preconditions ................................................................................... 19 Assumptions .................................................................................... 19 Sequence Diagrams ........................................................................ 19 Checkout API ................................................................................... 22 Confirmation API.............................................................................. 22 Payment Notification........................................................................ 22 Annex A SRC API Data Elements......................................................................... 23 A.1 Device Identity ............................................................................................ 23 Annex B CS to CSMS Communication................................................................ 24 B.1 CS to CSMS Overview ............................................................................... 24 B.2 DataTransferRequest message.................................................................. 27 B.3 DataTransferResponse message............................................................... 27 Annex C EVOP eMSP Contract Certificate Leaf................................................. 28 C.1 EV Open Payments Extensions ................................................................. 28 C.2 Organization Unit Data Elements ............................................................... 30 C.2.1 Separators ....................................................................................... 31 C.2.2 Validation Rules ............................................................................... 31 C.2.3 Examples ......................................................................................... 32 Annex D Multi-Factor Authentication .................................................................. 33 D.1 Single-Factor Authentication ...................................................................... 33 D.1.1 Add Consumer Identities API .......................................................... 33 D.1.2 Checkout API ................................................................................... 33 D.2 Multi-Factor Authentication......................................................................... 34 D.2.1 Add Consumer Identities API .......................................................... 34 D.2.2 Checkout API ................................................................................... 34 D.3 Enrolment with Multi-Factor Authentication................................................ 35 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page v / vii Annex E ISO 15118 Public Key Infrastructure.................................................... 38 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page vi / vii Tables Table 1.1: Normative References................................................................................. 2 Table 1.2: EMVCo References..................................................................................... 3 Table 1.3: Definitions .................................................................................................... 3 Table 1.4: Abbreviations ............................................................................................... 4 Table B.1: DataTransferRequest (OCPP) .................................................................. 27 Table B.2: DataTransferResponse (OCPP) ............................................................... 27 Table C.1: Organization Unit Data Elements ............................................................. 30 Table C.2: Validation Rules ........................................................................................ 32 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page vii / vii Figures Figure 2.1: Plug and Charge Ecosystem Entities Relationship with SRC ................... 6 Figure 3.1: Example Enrolment and Binding Flow..................................................... 13 Figure 3.2: Example LCM Flow .................................................................................. 16 Figure 3.3: Example Checkout Flow .......................................................................... 20 Figure B.1: Example Checkout Flow .......................................................................... 25 Figure D.1: Enrolment with Multi-Factor Authentication ............................................ 36 Figure E.1: ISO 15118 Public Key Infrastructure ....................................................... 38 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 1 / 39 1 Introduction This document, EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case (hereafter “EV Open Payments Use Case”), describes the use case for a Consumer using an open payments solution to pay for EV charging enabled by the EMV SRC specifications (see Section 1.4.2 Published EMVCo Documents) and the ISO 15118 Vehicle to Grid specification with the Plug and Charge option. This allows Consumers to make payments at merchants without requiring a pre-existing relationship between the two parties. 1.1 Scope The EV Open Payments Use Case uses an ISO 15118 contract certificate which is extended to carry the payment-related data required by the SRC System. This is known as an EV Open Payments (EVOP) eMSP contract certificate (see Annex C EVOP eMSP Contract Certificate Leaf). The EV Open Payments Use Case explains how the following SRC functions can be carried out within the context of using an open payments solution to pay for EV charging in an EV Plug and Charge experience: • Enrolment and Binding, which results in an enrolled Payment Card and includes the creation of anISO 15118 EVOP eMSP contract certificate, which is bound to an instance of the enrolled Payment Card • Lifecycle Management, including the renewal of an EVOP eMSP contract certificate, the unbinding of an EVOP eMSP contract certificate from an instance of an enrolled Payment Card and the deletion of an instance of an enrolled Payment Card • Checkout, including the transmission of the EVOP eMSP contract certificate from the EV to the Charging Station Operator (CSO) using the Plug and Charge protocol defined in ISO 15118 Note: For the EV Open Payments Use Case, the term “binding” is used to express the relationship between an enrolled Payment Card and an EV using an EVOP eMSP contract certificate Note: The scope of this document only covers payment for EV charging. This does not preclude incremental amounts for other services supplied at the same time (e.g. parking) 1.2 Constraints The EV Open Payments Use Case is designed to work within the constraints described in the SRC Core Specification. The EV Open Payments Use Case or any implementation of the EV © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 2 / 39 Open Payments Use Case is not intended to replace or interfere with any international, regional, national or local laws and regulations; those governing requirements supersede any industry standards. 1.3 Audience This document is intended for use by SRC Systems, SRC System Participants and industry participants in the EV charging ecosystem, including but not limited to CSOs, eMSPs, Original Equipment Manufacturers (OEMs) and their service providers. 1.4 References The latest version of any reference, including all published amendments, shall apply unless a publication date is explicitly stated. 1.4.1 Normative References The standards in Table 1.1 may be associated with the EV Open Payments Use Case. Reference ISO 4217 ISO 15118 OCPI OCPP Table 1.1: Normative References Publication Name Currency Codes — ISO 4217 (located at https://www.iso.org/store.html) ISO 15118-2 Road vehicles — Vehicle-to-Grid Communication Interface — Part 2: Network and application protocol requirements ISO 15118-20 Road vehicles — Vehicle-to-Grid Communication Interface — Part 20: 2nd generation network layer and application layer requirements (both located at https://www.iso.org/store.html) Open Charge Point Interface (located at https://evroaming.org/ocpi/) Open Charge Point Protocol (located at https://openchargealliance.org/protocols/open-charge-pointprotocol/) © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 3 / 39 1.4.2 Published EMVCo Documents The documents in Table 1.2 are related to or are associated with SRC and the EV Open Payments Use Case. They are located at www.emvco.com. Reference SRC Core Specification SRC API SRC Use Cases Table 1.2: EMVCo References Publication Name EMV® Secure Remote Commerce Specification EMV® Secure Remote Commerce Specification – API EMV® Secure Remote Commerce Use Cases 1.5 Definitions For the definition of the SRC specific terms used in the EV Open Payments Use Case, refer to the SRC Core Specification, Section 1.8. The following terms are used in solely in the EV Open Payments Use Case and are defined in Table 1.3. Term Table 1.3: Definitions Definition Charging Station The physical system where one or more EVs can be charged. Charging Station Management System Manages Charging Stations and has the information for authorising Consumers for using its Charging Stations. Charging Station Operator Entity that manages the Charging Station Management System. Consumer The Consumer is defined in the SRC Core Specification. In the content of this use case, the Consumer is typically the person who enrols a Payment Card in the SRC System. eMobility Service Provider Entity with which the Consumer has a contract for all services related to the EV energy transfer. © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 4 / 39 Term Definition EV Open Payments A card-based open payments solution for EV charging, enabled by SRC and the Plug and Charge protocol defined in ISO 15118. EV_ID Identifier for an electric vehicle. Can either be the EVCCID or PCID. Mobility Operator Entity that provides e-mobility services, such as contract certificate creation, to Consumers who want to use plug and charge for their electric vehicle. 1.6 Notational Conventions 1.6.1 Abbreviations For the definition of the SRC-specific abbreviations used in the EV Open Payments Use Case, refer to the SRC Core Specification, Section 1.9.1. The abbreviations listed in Table 1.4 are used solely in the EV Open Payments Use Case. Abbreviation CA CDR CS CSMS CSO EMAID eMSP EV EVCCID EVOP Table 1.4: Abbreviations Description Certificate Authority Charge Details Record Charging Station Charging Station Management System Charging Station Operator Electronic Mobility Account Identifier eMobility Service Provider Electric Vehicle Electric Vehicle Communication Controller ID. EV Open Payments © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 5 / 39 Abbreviation MO OEM PCID PKI PSP V2G Description Mobility Operator Original Equipment Manufacturer Provisioning Certificate ID Public Key Infrastructure Payment Service Provider Vehicle to Grid 1.6.2 Terminology and Conventions For the definition of the terminology and conventions used in the EV Open Payments Use Case, refer to the SRC Core Specification, Section 1.9.2. In particular, the following conventions are used with reference to the SRC API: • SRC API operations are capitalised and followed by the word “operation” (e.g. Checkout operation) or “response” (e.g. Checkout response) • SRC API complex data objects are capitalised and in Courier New font (e.g. DeviceIdentity) • SRC API data elements are in camel case and Courier New font (e.g. srcDigitalCardId) • SRC API enumeration values are in capitals (e.g. ASSURANCE_REQUIRED) © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 6 / 39 2 Overview This section introduces the principal entities in the Plug and Charge, SRC and payments ecosystems and the relationships between them, as illustrated in Figure 2.1. Please note that this is not a flow diagram. The relationships are described in detail in Section 3, which also gives flow diagrams for each use case. Figure 2.1: Plug and Charge Ecosystem Entities Relationship with SRC The different colours of the arrows / text in Figure 2.1 represent the different functions of each relationship. The text in parenthesis () in the bullets below give the equivalent SRC functions: • Blue: Root CA management • Green: Payment Card (Enrolment) and contract certificate management (Binding) • Grey: ISO 15118 Plug and Charge • Purple: Charging and payment authorisation (Checkout) The remainder of the section is structured as follows: • Section 2.1 EV Open Payments Entities describes the roles and responsibilities of the main entities within the Plug and Charge ecosystem © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 7 / 39 • Section 2.2 Using SRC to Enable EV Open Payments describes the additional functions an SRC System undertakes in order to enable open payments 2.1 EV Open Payments Entities This section describes the EV Open Payments entities for Plug and Charge under ISO 15118. 2.1.1 MO PKI Service Provider The Mobility Operator (MO) Public Key Infrastructure (PKI) Service Provider manages the Public Key Infrastructure (PKI) that secures certificate-based authentication between electric vehicles (EVs) and the charging ecosystem under ISO 15118 (see Annex E ISO 15118 Public Key Infrastructure). In EV Open Payments, the MO PKI Service Provider operates the SRC MO Root CA on behalf of the SRC System. The SRC MO Root CA is used by the SRC System to issue EVOP eMSP contract certificates or to allow eMSPs to generate their own EVOP eMSP contract certificates under the SRC MO Root. Each EVOP eMSP contract certificate is used to bind a specific EV to a Consumer’s Payment Card. Core responsibilities include: • Issuing and managing EVOP eMSP contract certificates • Supporting certificate lifecycle operations (renewal, revocation, replacement) • Serving as a trusted anchor to ensure interoperability across OEMs, CSOs, and eMSPs • Supporting SRC Systems by either generating EVOP eMSP contract certificates under the SRC MO Root CA or signing the EVOP eMSP Sub-CA2 to delegate EVOP eMSP contract certificate generation to the EVOP eMSPs using their own PKI Service Provider Through these functions, the MO PKI Service Provider enables secure, interoperable, and seamless EV Open Payment Plug and Charge experiences. Note: SRC MO root CA must comply with the relevant trusted PKI Systems requirements depending on the market (e.g. SAE EV PKI Certificate Trust List (CTL) in US, or European Certificate Trust List (CTL) in EU). 2.1.2 EV Open Payments (EVOP) eMSP The EVOP eMSP is an eMSP which is enabled to support EV Open Payments. Its application (e.g. on the EV’s console or the Consumer’s mobile phone) manages both the EVOP eMSP © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 8 / 39 contract certificates and the Consumer’s payment credentials bound to those EVOP eMSP contract certificates. The EVOP eMSP relies on the MO PKI Service Provider or an on-behalf entity to generate EVOP eMSP contract certificates and to provision them securely to the Consumer’s EV as per ISO 15118. EVOP eMSP contract certification provisioning to the EV is implementation-specific and it is the responsibility of the EVOP eMSP and the EV OEM to facilitate this functionality. The EVOP eMSP differs from the ISO 15118-defined eMSP in the following respects: • Charging Session Authorisation • Acting as source of funds • Tariff and pricing • Clearing and settlement • Roaming agreements Beyond payments, the EVOP eMSP may also offer value-added services such as locating nearby charging stations, displaying transaction history, and providing digital receipts for charging sessions. 2.1.3 Electric Vehicle (EV) In order to support EV Open Payments, the EV is provisioned with an EVOP eMSP contract certificate. This is passed to the Charging Station (CS) during the ISO 15118 Plug and Charge data exchange. 2.1.4 Charging Station (CS) The CS provides electric power and communication interfaces to the EV for charging purposes under Plug and Charge. To support EV Open Payments, the CS is provisioned with the SRC MO root certificates when it onboards with the SRC System. The CS receives the EVOP eMSP contract certificate from the EV during the ISO 15118 Plug and Charge data exchange, which it validates using its preloaded SRC MO root certificate. The CS extracts the relevant payment-related data from the EVOP eMSP contract certificate and passes it to the Charging Station Operator (CSO). 2.1.5 Charging Station Operator (CSO) and Charging Station Management System (CSMS) The CSO manages its CS through the CSMS. The CSMS is a backend system connected with the CS. It initiates the charging process and handles tasks such as maintenance, billing and the overall function of the CS within a charging network. © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 9 / 39 To support EV Open Payments, the CSO needs to trust the SRC MO root certificate. In contrast to an ISO 15118-defined eMSP, the CSO does not need to have a contractual relationship (e.g. billing or roaming) with the EVOP eMSP in order to receive payment. The CSO uses the payment-related data received from the CS to obtain payment data from the SRC System. The payment data is used for payment authorisation to pay for a specific charging session. The CSO interactions with the SRC System and the payment authorisation entities can be direct or via a Payment Service Provider (PSP). 2.1.6 SRC System The SRC System facilitates the trust between the CSO and the EVOP eMSP to enable EV Open Payments. To support EV Open Payments, the SRC System binds the Payment Card to an individual EV via the EVOP eMSP contact certificate. During checkout, the SRC System validates the binding of the Payment Card to the EV before providing the payload to the CSO. For further details, see section 2.2 Using SRC to Enable EV Open Payments. 2.1.7 Authorisation Entities The authorisation entities (e.g. acquiring bank, payment network, issuing bank) use the payment data from the CSO to process a standard card-based open payments transaction. 2.2 Using SRC to Enable EV Open Payments This section describes how SRC enables EV Open Payments within the context of an ISO 15118 Plug and Charge experience. 2.2.1 Onboarding Plug and Charge Ecosystem Entities Both the EVOP eMSP and the CSO are onboarded as SRC System Participants in accordance with the SRC Core Specification, Section 4, for each SRC System that they support. 2.2.2 SRC System Functions To enable EV Open Payments, the SRC System performs the following functions in conjunction with the Plug and Charge ecosystem entities. The SRC System: © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 10 / 39 • Acts as the root Certificate Authority (CA) for the EVOP eMSP contract certificates (see Annex E ISO 15118 Public Key Infrastructure). During onboarding: o The EVOP eMSP is enabled to act as a sub-CA2 in order to create EVOP eMSP contract certificates o The CSO is provided with the respective SRC MO root certificates • Supports requests from the EVOP eMSP to: o Add a Payment Card using the Card Enrolment API. The SRC System returns the Digital Card Identifier (srcDigitalCardId) for the enrolled card, which is included in the EVOP eMSP contract certificate o Bind an EVOP eMSP contract certificate for the EV to a given instance of the enrolled Payment Card (represented by the srcDigitalCardID) using the Add Consumer Identities API o Renew an EVOP eMSP contract certificate using the Add Consumer Identities API o Unbind an EVOP eMSP contract certificate using the Unbind App Instance API o Delete an instance of an enrolled Payment Card which is not bound to any EVOP eMSP contract certificates using the Delete Card API • Validates the signed data from the EV provided by the CSO using the Checkout API • Receives the Charge Details Record (CDR) provided by the CSO using the Confirmation API • Provides the CDR to the EVOP eMSP using the Notification API © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 11 / 39 3 EV Open Payments Use Case This section presents the following use case examples, each describing a specific function of the overall EV Open Payments use case: • Enrolment and Binding (Section 3.1) • EVOP eMSP Contract Certificate LCM (Section 3.2) • Checkout (Section 3.3) Note: In these use case examples, it is assumed that the Consumer is the driver of the EV and is also the person paying for the EV charging. However, this is not always the case (e.g. fleet, rental vehicles, etc). Note: Each example follows the structure of the use cases described in the SRC Use Cases document, with additional subsections for each SRC API that is used. These additional subsections describe any specific data that are needed to support the use case, including the data elements used to carry these data. 3.1 Enrolment and Binding In this example of the Enrolment and Binding function, the Consumer uses an EVOP eMSP to enrol a Payment Card with an SRC System and bind it to the EV. This results in the creation of an eMSP EVOP contract certificate bound to the Payment Card, which is then provisioned to the EV. The following APIs are used: • Card Enrolment • Add Consumer Identities Note: Communication between the front end of the EVOP eMSP and the EVOP eMSP server is proprietary to the EVOP eMSP. 3.1.1 Preconditions The following preconditions apply to this example: • The EVOP eMSP has onboarded to the SRC System • The MO PKI Service Provider acts as the MO root CA on behalf of the SRC System • The EVOP eMSP server is able to provide EVOP eMSP contract certificates to the EV © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 12 / 39 3.1.2 Assumptions The following assumptions apply to this example: • The Consumer has been successfully authenticated, allowing access to the EVOP eMSP • The Payment Card has not previously been enrolled in the SRC System 3.1.3 Sequence Diagrams Figure 3.1 shows an example flow where the Consumer uses the EVOP eMSP to enrol a Payment Card into an SRC System, which is then bound to the EV for use with EV Open Payments. The numbered steps are explained following the figure. © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 13 / 39 Figure 3.1: Example Enrolment and Binding Flow 01. The Consumer provides the Payment Card details to the EVOP eMSP application 02. The EVOP eMSP application provides the details to the EVOP eMSP server 03. The EVOP eMSP server calls the Card Enrolment operation to enrol the Payment Card with the SRC System 04. The SRC System returns the srcDigitalCardId (which represents the Payment Card) in the Card Enrolment response following successful enrolment 05. The EVOP eMSP server creates a key pair and signs the EVOP eMSP contract certificate, which includes the srcDigitalCardId and other data elements (see Annex C EVOP eMSP Contract Certificate Leaf for details) © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 14 / 39 06. The EVOP eMSP server calls the Add Consumer Identities operation to request the binding of the EVOP eMSP contract certificate to the Payment Card, providing the SRC System with the srcDigitalCardId, EVOP eMSP contract certificate and the EV_ID (see section 3.1.5 Add Consumer Identities API for more details) 07. The SRC System verifies the signed EVOP eMSP contract certificate and extracts the EV contract public key 08. The SRC System binds the EV_ID, EVOP eMSP contract certificate and the EV contract public key to the Payment Card represented by srcDigitalCardId 09. The SRC System notifies the EVOP eMSP server that the binding has been successful in the Add Consumer Identities response 10. The EVOP eMSP server sends the EVOP eMSP contract certificate and associated private key to the EV using EV proprietary provisioning flow as described in ISO 15118 3.1.4 Card Enrolment API No EV Open Payments use case specific data is required by the Card Enrolment API. 3.1.5 Add Consumer Identities API The following data elements in the request body of the Add Consumer Identities API carry data specific to the EV Open Payments use case: • assuranceData o Used to pass the EVOP eMSP contract certificate, which is carried in the additionalData data element within assuranceData. Refer to Annex D Multi-Factor Authentication for the specific VerificationData parameters used for single- and multi-factor authentication. • deviceIdentity o Used to pass the EV_ID. Refer to Annex A.1 Device Identity for example usage. 3.2 EVOP eMSP Contract Certificate LCM In this example of the Lifecycle Management (LCM) functions of an EVOP eMSP contract certificate, the Consumer performs one of the following LCM events: • Renewing the EVOP eMSP contract certificate • Unbinding the EVOP eMSP contract certificate, but retaining the enrolled Payment Card within the SRC System • Deleting the enrolled Payment Card from the SRC System © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 15 / 39 The EVOP eMSP provides the user interface for the Consumer to add, update and delete Payment Cards and related EVOP eMSP contract certificates. The EVOP eMSP is responsible for managing the lifecycle of each EVOP eMSP contract certificate, reflecting any LCM events according to each SRC System implementation. The following APIs are used: • Add Consumer Identities • Unbind App Instance • Delete Card Note: Communication between the front end of the EVOP eMSP and the EVOP eMSP server is proprietary to the Plug and Charge wallet. 3.2.1 Preconditions The following preconditions apply to this example: • The EVOP eMSP has onboarded to the SRC System • The MO PKI Service Provider acts as the MO root CA on behalf of the SRC System • The Consumer has selected an EVOP eMSP contract certificate which is bound to the EV and a previously enrolled Payment Card (see Section 3.1 Enrolment and Binding) 3.2.2 Assumptions The following assumptions apply to this example: • The Consumer may have bound the instance of the Payment Card to multiple EVOP eMSP contract certificates managed by the same EVOP eMSP • It is the responsibility of the EVOP eMSP to manage EVOP eMSP contract certificates, including their updating or removal from the EV, and for notifying the Consumer of the outcome of any LCM event 3.2.3 Sequence Diagrams Figure 3.2 shows an example flow where the Consumer performs one of the following LCM events for a specific EVOP eMSP contract certificate: • Renewal (Option 1) • Unbinding (Option 2) • Deletion (Option 3) The numbered steps are explained following the figure, with the first two steps and the last step common to all options. © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Figure 3.2: Example LCM Flow Page 16 / 39 01. The Consumer uses the EVOP eMSP application to request an LCM event for the selected EVOP eMSP contract certificate 02. The EVOP eMSP application provides the details of the EVOP eMSP contract certificate and EV_ID to the EVOP eMSP server © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 17 / 39 Option 1: Renewal of EVOP eMSP contract certificate 03. The MO PKI Service Provider generates a new EVOP eMSP contract certificate on behalf of the EVOP eMSP. The EVOP eMSP server calls the Add Consumer Identities operation to request the renewal of the EVOP eMSP contract certificate, providing the SRC System with the srcDigitalCardId, the new EVOP eMSP contract certificate and the EV_ID (see section 3.2.4 Add Consumer Identities API for more details) 04. The SRC System unbinds the existing EVOP eMSP contract certificate from the Payment Card (represented by the unique combination of the srcDigitalCardId and the EV_ID) and then binds the Payment Card to the new EVOP eMSP contract certificate 05. The SRC System notifies the EVOP eMSP server of the outcome of the updating and binding in the Add Consumer Identities response. It is responsibility of the EVOP eMSP to ensure that the EVOP eMSP contract certificate is updated in the EV Option 2: Unbinding of EVOP eMSP contract certificate from Payment Card 03. The EVOP eMSP server calls the Unbind App Instance operation to request the unbinding of the EVOP eMSP contract certificate from the Payment Card, providing the SRC System with the EVOP eMSP contract certificate (see section 3.2.5 Unbind App Instance API or more details) 04. The SRC System unbinds the existing EVOP eMSP contract certificate from the Payment Card 05. The SRC System notifies the EVOP eMSP server of the outcome of the unbinding in the Unbind App Instance response. The unbound EVOP eMSP contract certificate cannot be used for EV Open Payments. It is responsibility of the EVOP eMSP to ensure that the unbound EVOP eMSP contract certificate is removed from the EV Option 3: Deletion of instance of Payment Card 03. The EVOP eMSP server calls the Delete Card operation to request the deletion of the instance of the Payment Card, providing the SRC System with the srcDigitalCardId 04. The SRC System deletes the instance of the Payment Card (represented by the srcDigitalCardId). Any EVOP eMSP contract certificates bound to the instance of Payment Card will become unbound 05. The SRC System notifies the EVOP eMSP server of the outcome of the deletion in the Delete Card response. It is responsibility of the EVOP eMSP to ensure that any unbound EVOP eMSP contract certificates are removed from the respective EV(s) © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 18 / 39 Outcome for all Options 06. The EVOP eMSP server communicates the outcome of the relevant request to the EV and ensures that any relevant updates are made to the associated EVOP eMSP contract certificate stored in the EV 07. The EVOP eMSP server informs the EVOP eMSP application of the outcome of the relevant request 08. The EVOP eMSP application informs the Consumer of the outcome of the relevant request 3.2.4 Add Consumer Identities API The following data elements in the request body of the Add Consumer Identities API carry data specific to this use case: • assuranceData o Used to pass the EVOP eMSP contract certificate, which is carried in the additionalData data element within assuranceData. Refer to Annex D Multi-Factor Authentication for the specific VerificationData parameters used for single- and multi-factor authentication. • deviceIdentity o Used to pass the EV_ID. Refer to Annex A.1 Device Identity for example usage. 3.2.5 Unbind App Instance API The following data elements in the response body of the Unbind App Instance API carry data specific to this use case: • signedObject o Used by the SRC System to pass the EVOP eMSP contract certificate in X509.v3 format. See the SRC API, Section 2.2.2, for details of the signedObject data element. See Annex C EVOP eMSP Contract Certificate Leaf for the detailed format of the EVOP eMSP contract certificate. 3.2.6 Delete Card API No EV Open Payments use case specific data is required by the Delete Card API. © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 19 / 39 3.3 Checkout In this example flow of the checkout function, SRC is used to enable an open payment for a Plug and Charge experience. The following APIs are used: • Checkout • Confirmation • Payment Notification Note: Communication between the front end of the EVOP eMSP and the EVOP eMSP server is proprietary to the Plug and Charge wallet. Note: Communication between the CS and the CSMS is proprietary; for an example, see Annex B CS to CSMS Communication. 3.3.1 Preconditions The following preconditions apply to this use case example: • The CSO has been onboarded with the SRC System • The MO PKI Service Provider acts as the MO root CA on behalf of the SRC System • The CSO has distributed the SRC MO root CA certificate to all Charging Stations • The Consumer has selected an EVOP eMSP contract certificate which is bound to the EV and a previously enrolled Payment Card (see Section 3.1 Enrolment and Binding) • The EV has completed Consumer authentication, which may be passive (biometrics) or active (Consumer entry of pin, password etc) either on the EV console or via a dedicated app (e.g. authenticator app on the Consumer’s mobile device) 3.3.2 Assumptions There are no additional assumptions for this example flow. 3.3.3 Sequence Diagrams Figure 3.3 shows an example flow where the Consumer inserts the charging cable from the Charging Station (CS) into the EV, which automatically triggers the start of ISO 15118 Plug and Charge communication. The numbered steps are explained following the figure. © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 20 / 39 Figure 3.3: Example Checkout Flow 01. The Consumer plugs the charging cable into the EV, resulting in an ISO 15118 message exchange between the EV and the CS. During this exchange, the CS validates the EVOP © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 21 / 39 eMSP contract certificate using the SRC MO root CA as per ISO 15118. The EV signs the ISO 15118 AuthorizationReq data using the private key associated with the EVOP eMSP contract certificate and sends it to the CS. See Annex B CS to CSMS Communication for more details on the message exchange 02. The CS populates the deviceSpecificData using data received from the EV and sends it to the CSMS. This includes the signed AuthorizationReq data from Step [01] 03. The CSMS: o Generates an idToken by including the deviceSpecificData in signed_data private claims o Creates the assuranceData, which includes the idToken 04. The CSMS calls the Checkout operation to provide the following to the SRC System server: o assuranceData o deviceIdentity 05. The SRC System validates: o idToken o Contents of deviceSpecificData, including the validation of the signedAuthorizationReqData(GetChallenge) data from the EV using the EV contract public key o EVOP eMSP contract certificate details o Timestamp using defined business rules o Binding of the EVOP eMSP contract certificate 06. The SRC System generates a payload and returns it to the CSMS in the Checkout response following successful validation in Step [05] 07. Optionally, the CSMS may perform a pre-authorisation (pre-auth) 08. The CSMS responds to the CS to initiate charging 09. The CS charges the EV 10. The CS informs the CSMS that charging is complete and provides the final amount for the transaction 11. The CSMS completes the final authorisation or captures on the pre-authorisation if one was performed in Step [07] 12. The CSMS calls the Confirmation operation to send the Charge Details Record (as specified by OCPI) to the SRC System once payment has been successfully processed © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 22 / 39 13. The SRC System provides the CSMS with a Confirmation response 14. The SRC System calls the Payment Notification operation to send confirmation notification data to the EVOP eMSP server Note: Since the Cardholder authentication indicator (i.e. whether there was single- or multifactor authentication) is available within the EVOP eMSP contract certificate, this can be used by the CSMS during risk-based decisioning. 3.3.4 Checkout API The following data elements in the request body of the Checkout API carries data specific to this use case: • assuranceData o Includes the idToken which is provided in additionalData o The idToken includes deviceSpecificData which is provided in the signed_data private claim. The amr (Authentication Method Reference) claim uses the value “swk” o The deviceSpecificData is used to pass the signedAuthorizationReqData(GetChallenge) data, the EVOP eMSP contract certificate and other data elements as defined in the SRC API, Section 2.2.2 o Refer to Annex D Multi-Factor Authentication for the specific verificationData parameters used for single- and multi-factor authentication • deviceIdentity o Used to pass the EV_ID. Refer to Annex A.1 Device Identity for example usage. 3.3.5 Confirmation API The following data element in the request body of the Confirmation API carries data specific to this use case: • customData o Contains the Charge Details Record data object (as specified by OCPI) 3.3.6 Payment Notification The following data element in the request body of the Payment Notification API carries data specific to this use case: • customData o Contains the Charge Details Record data object (as specified by OCPI) © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 23 / 39 Annex A SRC API Data Elements This Annex contains usage examples for various SRC API data elements. A.1 Device Identity The Add Consumer Identities and Checkout APIs use the deviceIdentity data element to identify the EV for the different use cases. For example, an OEM-provided EVOP eMSP would use the following parameters: • identityProvider = ORIGINAL_EQUIPMENT_MANUFACTURER • identityAssuranceType = ASSURANCE_REQUIRED • identityValue = EV_ID Note: The identityValue is the EV_ID, which can be either the EVCCID or PCID, (whichever was made available to the Plug and Charge wallet) to uniquely identify the EV. © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 24 / 39 Annex B CS to CSMS Communication This Annex describes the communication between the CS and the CSO CSMS. It gives an illustration of how device specific data could be send to the CSMS using OCPP. Note: Flows and data structures in this Annex are illustrative only Note: Data objects in this Annex are related OCPP data objects schema and follow OCPP data objects and messages definitions in OCPP 2.01 and OCPP 1.6 Note: Flows and data structures in this Annex are related to ISO 15118-2. However, ISO 15118-20 flows should provide the CS with the same data elements that are required by the SRC System to build the deviceSpecificData data object. B.1 CS to CSMS Overview Figure B.1 gives an example checkout flow, explicitly showing the communication between the EV and the Charging Station. This is an expanded version of the example checkout flow shown in Figure 3.3 for the Checkout function (Section 3.3). Generally, the numbered Steps [0x] are the same as for Figure 3.3. However, Steps [1.1] – [1.10] and Step [08] are specific to ISO 15118-2, while Steps [02] and [07] are specific to OCPP. These steps are explained following Figure B.1. For more information on these steps, refer to the relevant protocol. © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 25 / 39 Figure B.1: Example Checkout Flow © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 26 / 39 1.1 The EV sends a ServiceDiscoveryReq to the CS 1.2 The CS returns the list of accepted payment methods in the ServiceDiscoveryRes 1.3 The EV selects the payment method and informs the CS using the PaymentServiceSelectionReq 1.4 The CS responds with a PaymentServiceSelectionRes 1.5 The EV sends a PaymentDetailsReq to the CS, including the contractCertificateChain (EVOP eMSP contract certificate) corresponding to the selected payment method and the EMAID 1.6 The CS verifies the EVOP eMSP contract certificate using the SRC MO root CA certificate public key 1.7 The CS responds to the EV with a PaymentDetailsRes, including the GenChallenge 1.8 The EV signs the AuthorizationReq(GenChallenge) as specified in ISO 15118-2 using the private key associated with the EVOP eMSP contract certificate 1.9 The EV sends a AuthorizationReq to the CS, including the signed AuthorizationReq(GenChallenge) 1.10The CS verifies the signed AuthorizationReq(GenChallenge) as specified in ISO 15118-2 using the EVOP eMSP contract certificate provided in the PaymentDetailsReq (Step [1.5]). If the verification fails, the flow moves to Step [08], with an error code returned in the AuthorizationRes and no charging takes place 02 The CS sends the DataTransferRequest (see B.2 DataTransferRequest message) to the CSMS 03-07 The CSMS calls the Checkout operation, while the SRC System returns a payload in the Checkout response. For more detail, see Figure 3.3 and Steps [03] – [06] in Section 3.3.3 Sequence Diagrams. 08 The CSMS responds to the CS with a DataTransferResponse (see B.3 DataTransferResponse message) following successful receipt of the payload 09 The CS responds to the EV with an AuthorizationRes, giving the appropriate outcome of the AuthorizationReq from Step [1.9]. Assuming successful verification in Step [1.10], the CS can start charging. © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 27 / 39 10-14 Once charging is complete, the CSMS completes the authorisation steps and the Charge Details Record is delivered to the EVOP eMSP server. For more detail, see Figure 3.3 and Steps [10] – [14] in Section 3.3.3 Sequence Diagrams. B.2 DataTransferRequest message Table B.1 contains the field definition of the DataTransferRequest sent by the CS to the CSMS. Table B.1: DataTransferRequest (OCPP) Field Name Field Type data anytype vendorId String[0…255] Description Contains the deviceSpecificData This field is filled with “NULL” since it is not used B.3 DataTransferResponse message Table B.2 contains the field definition of the DataTransferReponse sent by the CSMS to the CS. Table B.2: DataTransferResponse (OCPP) Field Name Field Type data anytype vendorId String[0…255] Description Contains the status string “Authorised” or “Failed” This field is filled with “NULL” since it is not used © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 28 / 39 Annex C EVOP eMSP Contract Certificate Leaf This Annex describes the Contract Certificate Leaf as defined in ISO 15118-2 / ISO 15118-20 along with the extensions for the EV Open Payments use case, resulting in an EVOP eMSP contract certificate which is generated by the EVOP eMSP. C.1 EV Open Payments Extensions The contents in Subject field as shaded below are specific to the EV Open Payments use case and are populated as follows: • Organization field contains the URI of the SRC System which is the issuer of the MO root certificate. Additional SRC System URIs may be present in certain use cases, e.g. co-badged cards • Organization Unit field is a concatenation of the values of the MFA, EV_ID_type and EVID_value data elements along with conditional and optional data elements as defined in Table C.1 (see Annex C.2 Organization Unit Data Elements) • Common Name field contains a network specific prefix and the last 4 of the FPAN (with hashed srcDigitalCardId value in between to ensure uniqueness) • Domain component field optionally contains the value of srcDigitalCardId All other fields in the certificate are as defined in ISO 15118-2. When ISO 15118-20 is used, the same fields specific to this use case are to be used. Note: ISO 15118-2 and ISO 15118-20 define two different versions of the application layer protocol. ISO 15118-20 is an evolution of ISO 15118-2 but is not backward compatible; the two versions contain different messages, message sequences and data structures. Both versions support the open payments solution to pay for EV charging enabled by the EMV SRC specifications. Mobility Operator Leaf Certificate: Name: Typ: tbsCertificate Version SerialNumber Contract Cert Leaf 2 (X.509v3) The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e. the issuer name and serial number identify a unique certificate).CAs MUST force the serialNumber to be a non-negative integer. Given the uniqueness requirements above, serial numbers can be expected to contain long integers. Certificate users MUST be able to handle serialNumber values up to 20 octets. Conforming CAs MUST NOT use serialNumber values longer than 20 octets. Example :10:e6:fc:62:b7:41:8a:d5:00:5e:45:b6 Signature ecdsa-with-SHA256 (ISO 15118-2) © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 29 / 39 Issuer Country Organization Organization Unit Common Name Validity Subject Organization Organization Unit Common Name Domain Component SubjectPublicKeyInfo Public Key Cryptographic Algorithm Parameters Extensions AuthorityKeyIdentifier SubjectKeyIdentifier KeyUsage digitalSignature ecdsa-with-SHA512(ISO 15118-20) Optional content Required content Optional content Required content 4 weeks to 2 years (ISO 15118-2) Up to eMSP (ISO 15118-20) The certificate validity period is the time interval during which the CA warrants that it will maintain information about the status of the certificate. The field is represented as a SEQUENCE of two dates: the date on which the certificate validity period begins (notBefore) and the date on which the certificate validity period ends (notAfter) Both notBefore and notAfter are to be encoded as GeneralizedTime expressed in Greenwich Mean Time (Zulu) with format YYYYMMDDHHMMSSZ A concatenation of Subject identifier for the Issuer of srcDigitalCardIds bound to the Contract Certificate. Identifiers MUST BE in the form of case sensitive URI using the https scheme that contains scheme and full qualified domain name of the host only. Sample value of URI A multi-factor authentication indicator, followed by the EV_ID_type, EVID _value. Conditionally: CURRENCY and AMOUNT must be provided when the value of MFA is “01” or “02”. Optionally: Custom_data (a 6-character string) may be provided. The conditional and optional elements are delineated by a separator. All data elements are defined in Table C.1 (see Annex C.2 Organization Unit Data Elements) EMAID Note: Last five characters of the instance component of EMAID must contain the FPAN last 4 digits followed by the check digit character srcDigitalCardId (Conditional: must be included if only one SRC System URI is provided) EV contract public key id-ecPublicKey ECParameters (namedCurve secp256r1) (ISO 15118-2) (named Curve secp521r1)(ISO 15118-20) Optional-not critical content Optional-not critical content The key usage extension defines the purpose (e.g., encipherment, signature, certificate signing) of the key contained in the certificate. KeyUsage ::= BIT STRING { digitalSignature (0), nonRepudiation (1), -- recent editions of X.509 have -- renamed this bit to contentCommitment keyEncipherment (2), dataEncipherment (3), keyAgreement (4), keyCertSign (5), cRLSign (6), encipherOnly (7), decipherOnly (8) } 1 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 30 / 39 Cryptographic Algorithm nonRepudiation (contentCommitment) keyEncipherment dataEncipherment keyAgreement BasicConstraints CA CRLDistributionPoints Authority Information Access (OCSP) Signature Value 1 1 0 1 c false Optional-not critical content Optional-not critical content ecdsa-with-SHA256 (ISO 15118-2) ecdsa-with-SHA512 (ISO 15118-20) Octet-String C.2 Organization Unit Data Elements The data elements for the Organization Unit in Annex C.1 EV Open Payments Extensions are defined in Table C.1. Table C.1: Organization Unit Data Elements Data Element MFA Type: String (Numeric) EV_ID_type Type: String EVID_value Type: String R/C/O Length Description R Exactly 2 characters Multi-Factor Authentication indicator: Values are: • 00: single-factor authentication without amount • 01: single-factor authentication with amount • 02: multi-factor authentication with amount • 03: multi-factor authentication without amount R Exactly 2 characters Identifier type for EV (e.g., OEM, EMSP, VIN type ID). Values are: • 00: EVCCID • 01: PCID R Max Length = Unique identifier of the Electric Vehicle 30 characters © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 31 / 39 Data Element CURRENCY Type: String R/C/O Length C Exactly 3 characters AMOUNT Type: String (Numeric) C Exactly 12 characters Custom_data Type: String O Exactly 6 characters Description ISO 4217 three-digit numeric currency code Conditionality: Required if MFA = 01 or 02 Amount expressed in minor units with no decimal point as defined in ISO 4217 Conditionality: Required if MFA = 01 or 02 Custom data string for future use or proprietary flags Proprietary indicators for specific usage. Two-character use case indicator assigned by EMVCo: • 01: Fleet • 02-99: EMVCo future use Four-character use case specific data: Defined by use case provider C.2.1 Separators The separator “:” is used only to delineate conditional/optional fields. • If CURRENCY/AMOUNT are omitted (MFA = 00), no separator is included ahead of the CURRENCY data element • If Custom_data is omitted, no separator is included ahead of the Custom_data data element C.2.2 Validation Rules The validation rules for the conditional and optional data elements are shown in Table C.2. © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 32 / 39 Condition MFA = 00 or 03 MFA = 01 or 02 Custom_data provided Table C.2: Validation Rules Required Fields MFA, EV_ID_type, EV_ID_value MFA, EV_ID_type, EV_ID_value, Separator, CURRENCY, AMOUNT Separator, Custom_data C.2.3 Examples Example organizational units are given below. Example 1 – Single-Factor, No Amount Required 0001HUBPROVCERTBOXQA1:019800 • MFA = 00 → No currency or amount • Only EV_ID_type and EV_ID_value data elements required Example 2 – Multi-Factor, Amount Required 0201HUBPROVCERTBOXQA1:840000000005000:019800 • MFA = 02 → Amount required • 840 = USD • 00000005000 = 50.00 USD • 019800 = Custom_data Notes • AMOUNT is always sent in fixed-length, zero-padded minor units • Custom_data is optional and system-defined (6 characters) © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 33 / 39 Annex D Multi-Factor Authentication All transactions under this contract model will have at least single-factor possession authentication as a result of the signed GenChallenge sent by the EV to the CS, as defined in ISO 15118 for Plug and Charge (see Figure B.1 for more details). This binds the EV to the srcDigitalCardID based on the successful verification of the signed GenChallenge. D.1 Single-Factor Authentication In regions where multi-factor authentication is not required, the following sections describe how the Add Consumer Identities and Checkout APIs are used. D.1.1 Add Consumer Identities API The Plug and Charge wallet is expected to: • Pass the EVOP eMSP contract certificate in additionalData • Include the following verificationData within AssuranceData: o Verification Type = DEVICE o Verification Entity = 04 DCF o Verification Event = 01 Bind o Verification Method = 02 Public Key Infrastructure o Verification Result = 01 Verified D.1.2 Checkout API When the EVOP eMSP contract certificate indicates single-factor authentication, the CSO is expected to: • Pass the idToken in additionalData • Include the following verificationData within AssuranceData: o Verification Type = DEVICE o Verification Entity = 04 DCF o Verification Event = 02 Checkout o Verification Method = 02 Public Key Infrastructure o Verification Result = 01 Verified © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Secure Remote Commerce Electric Vehicle Open Payments Use Case v1.0 Page 34 / 39 D.2 Multi-Factor Authentication In regions where multi-factor authentication is required, implementation will depend on requirements by the region and the OEM preference (see Section 1.2 Constraints). For instance, the EVOP eMSP may have to implement an additional element other than possession for authentication. This could be either inherence (e.g. behavioural biometrics, touch ID, etc.) or knowledge (e.g. PIN, ID number, etc.). In other markets, the OEM could implement another possession element such as companion device, key fob, etc. The EVOP eMSP is expected to implement multi-factor authentication based on the EV capabilities in such markets. When the EVOP eMSP application decides to use multi-factor authentication for a given EV, it uses the multi-factor authentication indicator in the EVOP eMSP contract certificate during enrolment and binding (see Annex C EVOP eMSP Contract Certificate Leaf) to communicate this to the SRC System. When the multi-factor authentication indicator is set in an EVOP eMSP contract certificate, the EV is only allowed to use this EVOP eMSP contract certificate after first successfully completing active or passive Cardholder authentication. The following sections describe how the Add Consumer Identities and Checkout APIs are used for multi-factor authentication. D.2.1 Add Consumer Identities API The EVOP eMSP is expected to: • Pass the EVOP eMSP contract certificate (which includes the multi-factor authentication indicator) in additionalData • Include the following verificationData within AssuranceData : o Verification Type = CARDHOLDER o Verification Entity = 04 DCF o Verification Event = 02 Add Card/Card Enrolment o Verification Method = 06 Proprietary Method of Authentication o Verification Result = 01 Verified D.2.2 Checkout API When the EVOP eMSP contract certificate indicates multi-factor authentication, the CSO is expected to: • Pass the idToken in additionalData © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.c