SB n° 320 Update to SRC Specifications - API v1.5

EMV® Specification Bulletin No. 320 First Edition January 2026 Secure Remote Commerce Specification – API This Specification Bulletin updates EMV® Secure Remote Commerce Specification – API, version 1.5 to improve descriptions in the original specification in support of the Electric Vehicle Open Payments Use Case. There is no change to the underlying functionality. Applicability This Specification Bulletin applies to: • EMV® Secure Remote Commerce Specification – API, version 1.5 Related Documents • EMV® Secure Remote Commerce – Electric Vehicle Open Payments Use Case, version 1.0 Effective Date • The date of publication Description Ahead of the publication of the EMV® Secure Remote Commerce – Electric Vehicle Open Payments Use Case, version 1.0 (EVOP Use Case v1.0), EMVCo published EMV® Secure Remote Commerce Specification – API, version 1.5 (API v1.5), which included new data elements to support the EVOP Use Case v1.0. This bulletin updates API v1.5 to make a minor editorial change and to improve descriptions in API v1.5 that discuss how the APIs and data elements are used to support the EVOP Use Case v1.0. There is no change to the underlying functionality of the API v1.5. In the changes that follow, struck through text is to be deleted and replaced by new text which is highlighted in red. Specification Changes 2.1.26 DeviceIdentity The data element type for identityProvider in Table 2.26 was originally presented in camel case in error. The data element identityType and its associated type has been renamed identityAssuranceType. The correct capitalisation and renamed data element are presented in the updated table below. © 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. Page 1 Data Element Table 2.26: DeviceIdentity R/C/O Constraints Description identityProvider Type: deviceIdentityProvider DeviceIdentityProvider O See Entity or organisation that deviceIdentityProvi collected and verified the der deviceIdentity DeviceIdentityProvi der identityAssuranceType Type: deviceIdentityType DeviceIdentityAssuranceType R See Assurance type of deviceIdentityType deviceIdentity DeviceIdentityAssu transmitted or collected ranceType identityValue Type: String R Max Length = 255 Device identity value that corresponds to the deviceIdentityType 2.3 Enumerations The enumeration DeviceIdentityType has been renamed DeviceIdentityAssuranceType. This is presented in the table below. Table 2.64: Enumerations Name Valid Values DeviceIdentityAssuranceTy • ASSURANCE_REQUIRED pe • ASSURANCE_NOT_REQUIRED 5.4.2 Add Consumer Identities Delete the existing introductory paragraphs: The Add Consumer Identities operation binds a Device Identity (an application instance) or Consumer Identity to an SRC Profile. In the case that the SRC Profile cannot be located, the SRC System may create a new SRC Profile (based on Consumer details provided in the request) if a previously enrolled unbound Digital Card exists. The Add Consumer Identifiers operation supports Consumer Identities such as e-mail address, phone number, device identity and/or application instance information to support a range of use cases. When the type of a provided Consumer Identity is considered to be a primary identity for an SRC Profile (e.g. an email address or phone number), then, if the SRC System detects that © 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. Page 2 an SRC Profile already exists with the same primary identity, the SRC System should respond to the request by advising that an SRC Profile with that identity already exists. Whether or not a provided Consumer Identity is used to replace an existing identity on an existing SRC Profile is an SRC System implementation decision. Replace with the following introductory paragraphs. These have been updated to both clarify the existing use case (first bullet) and to describe support for the EVOP Use Case v1.0 (second bullet). The Add Consumer Identities operation binds: • One or more identities to an SRC Profile; or • A Digital Card to an identity In the case that the SRC Profile cannot be located (e.g. the Digital Card was created during a guest checkout and was not bound to an SRC Profile), the SRC System may create a new SRC Profile (based on Consumer details provided in the request) if a previously enrolled unbound Digital Card exists. The Add Consumer Identities operation supports identities such as e-mail address, phone number, device identity and/or application instance information to support a range of use cases. When the type of a provided identity is considered to be a primary identity for an SRC Profile (e.g. an email address or phone number), then, if the SRC System detects that an SRC Profile already exists with the same primary identity, the SRC System should respond to the request by advising that an SRC Profile with that identity already exists. Whether or not a provided identity is used to replace an existing identity on an existing SRC Profile is an SRC System implementation decision. Update the conditionality for the srcDigitalCardId data element in Table 5.4.6 by deleting the existing conditionality and replacing it with the text in red. This clarifies both the existing use case (first bullet) and describes support for the EVOP Use Case v1.0 (second bullet). © 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. Page 3 Table 5.4.6: Add Consumer Identities Definition – Request Body Data Element R/C/O Notes srcDigitalCardId Type: String C Must be provided if the request is to establish a new SRC Profile and bind the identifier(s) to a previously enrolled, unbound card Must be provided if the request is to: • Establish a new SRC Profile using the identity(s) provided, and bind a previously enrolled, unbound Digital Card (srcDigitalCardID)to the new SRC Profile; or • Bind a Digital Card (srcDigitalCardID)to an identity 5.4.3 Unbind App Instance Delete the existing introductory paragraph: The Unbind App Instance operation unbinds a Device Identity (an application instance) from an SRC Profile. Replace with the following introductory paragraph. This has been updated to both clarify the existing use case (first bullet) and to describe support for the EVOP Use Case v1.0 (second bullet). The Unbind App Instance operation unbinds: • An application instance from an SRC Profile; or • A Digital Card from a Device Identity 5.5.2 Checkout Update the combined conditionality for the srcDigitalCardId and deviceIdentity data elements in Table 5.5.7 by deleting the existing conditionality and replacing with the text in red. This clarifies the intent of the conditionality. © 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. Page 4 Table 5.5.7: Checkout Definition – Request Body Data Element R/C/O Notes srcDigitalCardId Type: String RC Changed from Required to Conditional Either srcDigitalCardId or deviceIdentity must be provided deviceIdentity Type: DeviceIdentity C At least one of srcDigitalCardId or deviceIdentity must be provided A.3.1 Assurance Data Update the description of Assurance Data and its nested data elements to improve clarity. Delete the struck-through text below and replace with the text in red, which has been moved to the end of the section to improve readability. For the EV Open Payments use case, assuranceData is a required data element in the request bodies of the following APIs: • Add Consumer Identities • Checkout Within assuranceData, verificationData has specific values depending on the level of authentication (see below). Furthermore, the additionalData data element is used to provide: • Contract certificate (Add Consumer Identities API) • idToken (Checkout API) • Proof of Authentication (for two-factor authentication) Single-Factor Authentication For the Add Consumer Identities API, the verificationData values are: • verificationType = DEVICE • verificationEntity = 04 DCF • verificationEvent = 01 Bind • verificationMethod = 02 Public Key Infrastructure • verificationResult = 01 Verified For the Checkout API, the verificationData values are: • verificationType = DEVICE • verificationEntity = 04 DCF © 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. Page 5 • verificationEvent = 02 Checkout • verificationMethod = 02 Public Key Infrastructure • verificationResult = 01 Verified Two-Factor Authentication For the Add Consumer Identities API, the verificationData values are: • verificationType = CARDHOLDER • verificationEntity = 04 DCF • verificationEvent = 02 Add Card/Card Enrolment • verificationMethod = 06 Proprietary Method of Authentication • verificationResult= 01 Verified For the Checkout API, the verificationData values are: • verificationType = CARDHOLDER • verificationEntity = 04 DCF • verificationEvent = 01 Payment Transaction • verificationMethod = 06 Proprietary Method of Authentication • verificationResult= 01 Verified Within verificationData, additionalData is a required data element and is used to provide: • Contract certificate (Add Consumer Identities API) • idToken (Checkout 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. Page 6 Legal Notice The EMV® Specifications are provided “AS IS” without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in these Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT, AS TO THESE SPECIFICATIONS. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to determine whether any implementation of the EMV® Specifications 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 the EMV® Specifications should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, the Specifications 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 these Specifications 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 the EMV® Specifications © 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. Page 7