PCI Watch

Tracking changes across the Payment Card Industry

EMV® Secure Remote Commerce Specifications

v1.3 Specifications
Secure Remote Commerce

EMV® Secure Remote Commerce Specification Version 1.3 December 2022

v1.3

Legal Notice

Page i / vii 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 NONINFRINGEMENT, 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.

v1.3

/ vii Revision Log – Version 1.3 The following changes have been made to the document since the publication of version 1.1. Note that there is no version 1.2 of the document.

  • Minor Editorial changes
  • Changes to account for the deprecation of the SRC Data Dictionary
  • Changes to reference the publication of SRC Use Cases
  • Removal of description of deprecation (now in SRC Version Management)
  • Addition of the following to Section 9.2 Payment Operations
  • Make Payment (push payment)
  • Addition of the following Sections: o 10.4 Authentication Facilitation o 10.5 Management Service o 10.6 Notification
  • Addition of the following services to Section 11.1.1 SRC API Operations
  • Authentication Facilitation Service
  • Management Service
  • Notification Service
  • Addition of the following methods to Section 11.2.1 SRC JavaScript SDK Methods o addBillingAddress() o authenticationMethodsLookup() o authenticate() v1.3 i Revision Log – Version 1.3. 1. 1. 1. 1. 1. 1. 1.7. 1.7. 1. 1. 1.9. 1.9. 3. 3. 3. 3. 3. 3. 4. 4. 5. v1.3 / vii 5. 5. 6. 6.1. 6.1. 6. 6.2. 6.2. 7. 7. 7. 7. 7. 8. 8.1. 8.1. 8. 8. 8.3. 8.3. 8.3. 9. 9.1.1 9.1.2 9.1.3 9.1. 9. 9.2. 9.2. 9.2. v1. 10. 10. 10. 10. 10. 10. 11. 11.1. 11. 11.2. A. A. A. A. A. B. B. B. B. v1.3 / vii Figures Figure 2. Figure 3. Figure 5. Figure 6. Figure 8. Figure 8. v1.3 / vii Tables Table 1. Table 1. Table 1. Table 1. Table 2. Table 6. Table 6. Table 6. Table 7. Table 7. Table 8. Table 8. Table 8. Table 9. Table 11. Table 11. Table 11. Table 11. Table 11. Table 11. Table 11. Table 11. Table 11. Table 11. Table 11. Table A. Table A. Table B. v1.3 / 64 1

Introduction

Secure Remote Commerce (SRC) is an evolution of remote commerce that provides for secure and interoperable card acceptance established through a common set of specifications (collectively known as the SRC Specifications). 1.1

Background

Internet-based commerce, known as remote commerce, became available in the 1990s and has continued to grow in popularity as a purchasing environment for Consumers. The remote commerce environment involves the purchase of goods or services through an interaction between a Consumer and a merchant on a Consumer Device. Remote commerce is serviced by a wide variety of stakeholders and is typically enabled through the Consumer entry of Primary Account Number (PAN) data into a merchant's shopping application or commerce provider’s website. The current environment has many different integration models and practices. The variety of implementations and the lack of common specifications for this environment results in fragmentation, complexity, and inconsistency for ecosystem stakeholders. EMVCo’s chip specifications have been very successful in driving down counterfeit fraud at the point of sale (POS), enabling cryptograms or other transaction unique data to be transmitted and verified in the transaction. This enables better risk management of the transaction which has led to increased Consumer confidence in card payments and provided the pre-conditions for significant long-term global growth of electronic payments using card accounts. This has been a major benefit to all stakeholders in the payment ecosystem. While security of payments in the physical terminal environment have improved with the introduction of EMV® specifications, there have been no such specifications for the remote commerce environment. As remote commerce becomes increasingly targeted and susceptible to compromise, it is important to establish common specifications that protect ecosystem stakeholders. The popularity of remote commerce as a purchasing environment continues to increase with innovation targeted to drive engagement and convenience enabled through new technology and new Consumer Devices. Although many merchant shopping applications have enabled a card-on-file methodology, the basic method of delivery of the Payment Card is largely insecure and unauthenticated. While account data storage standards such as Payment Card Industry Data Security Standards (PCI DSS) have been a staple in this environment, there is no common specification to address the functional interactions and transmission of data between the participants.

v1.3

/ 64 There is growing concern that the lack of uniformity in remote commerce creates opportunity for bad actors and hinders the progress made by the payment ecosystem to reduce paymentrelated fraud. An industry transition from a dependency on Consumer entry of PAN data can be accomplished by providing an SRC specification that meets the needs of all stakeholders involved.

1.2 Opportunity A secure and interoperable specification for transmission of Payment Data, rather than the Consumer entry of Payment Data, has the potential to increase transaction security while simplifying integration for merchants and commerce platforms. There is the opportunity to facilitate more secure methods of remote commerce through:

  • Minimising the number of times Consumers enter their Payment Data
  • Minimising the local storage of static Payment Data or Personal Identifiable Information
  • Supporting common verification of the Consumer to enable access to established Payment Data
  • Introducing Dynamic Data to protect the integrity of the Payment Data
  • Encryption of Payment Data
  • Providing transparency in the transaction data available between the participants to facilitate identity validation and Consumer Device identification to enable enhanced fraud management
  • Streamlining integrations between industry participants using a common set of API and SDK specifications 1.3

Scope

This document, the EMVCo Secure Remote Commerce Specification, (hereafter the “Specification”), along with the associated SRC specifications (hereafter the “SRC Specifications”, see Section 1.7.2 Published EMVCo Documents) describe the functional behaviour of SRC as well as the interactions and data exchanges among SRC Participants. In scope for SRC:

  • Preparation and assertion of Payment Data delivered to a merchant or commerce provider using a payment-enabled application for a remote commerce payment interaction v1.3 / 64
  • Common SRC API and SRC JavaScript SDK specifications (“EMV® Secure Remote Commerce Specification – API” and “EMV® Secure Remote Commerce Specification – JavaScript SDK”), which include data fields and services to provide consistency and reduce integration complexity by SRC System Participants for the enablement of a remote commerce payment interaction
  • Guidance on the interaction and connectivity infrastructure necessary for SRC System Participants to interface with SRC System
  • Presentation of visual elements (“EMV® Secure Remote Commerce Specification – User Interface Guidelines and Requirements”) that enable Customer selection and recognition of an SRC enabled experience provided by a payment-enabled application Out of scope for SRC:
  • Card-present transactions initiated by an EMV chip application and terminal interaction
  • Card-not-present transactions where no Consumer Device is utilised, except for those that are Merchant-Initiated Transactions
  • Product definitions and commercial products provided directly to Consumers
  • Changes required by participants or to messages within a Payment Networks authorisation, clearing and settlement processes
  • Payments initiated from anything other than a Payment Card
  • Payment processing interactions including, but not limited to, the submission of an authorisation, reversal, or capture transactions
  • Changes to transaction routing or processing choices by Payment System participants
  • Eligibility requirements for participation
  • Merchant experience guidance or mandates
  • Compliance or policy requirements defined by SRC product implementations or SRC Programmes The SRC Specifications:
  • Can be adopted to meet the unique payment ecosystem requirements of international, regional, national or local implementations
  • Do not include messages, formats and use case requirements based on implementation details
  • Are not designed to mandate, incentivise, or define commercial rules, requirements or policies for the implementation of SRC solutions by international, regional, national or local Payment Systems v1.3 / 64 1.4 Objectives The objectives of SRC include:
  • Streamlining integrations in remote commerce by:
  • Enabling simplified and efficient integration and interfaces between SRC System Participants
  • Creating guidelines for a recognisable trigger (Click to Pay) to initiate checkout
  • Providing common API and JavaScript SDK specifications that enable integration of industry participants to perform remote commerce
  • Creating common guidelines for card selection within checkout
  • Enabling consistency in the delivery of Payment Data to the merchant to facilitate post-checkout processing and payment authorisation
  • Interoperability in the remote commerce environment by:
  • Facilitating interoperable remote transactions
  • Enabling the use and integration of other EMV technologies such as Payment Tokenisation and EMV® 3-D Secure authentication by a variety of SRC Participants to improve the protection and use of Payment Data
  • Increasing security in remote commerce by:
  • Maintaining integrity of Payment Data using transactionally unique Dynamic Data
  • Decreasing vulnerability of shopping websites and mobile shopping applications by replacing PAN data with reference information that will enable the secure and consistent transmission of Payment Data and related checkout data
  • Introducing encryption during the exchange of Payment Data between SRC Participants
  • Enabling transparency in the data exchanged between the participants to facilitate improved Consumer Identity validation results and enhanced Consumer recognition
  • Supporting common Assurance to enable access to established Payment Data
  • Enabling federated recognition and authentication of Consumers using a unique Consumer Identity (or supporting common Consumer verification to enable access to established Payment Data)
  • Improving benefits to merchants by:
  • Reducing shopping cart abandonment by using a Consumer Identity to access Payment Data, decreasing the need for repetitive manual PAN entries v1.3 / 64
  • Increasing approval rates for remote commerce transactions by reducing fraud
  • Delivering a common digital representation of the Consumer account data to merchants 1.5 Constraints The SRC Specifications are designed to work within a number of constraints of the payment ecosystem, including roles of various entities, transaction flows, and associated payment use cases. These constraints include, but are not limited, to the following:
  • The SRC Specifications or any implementation of the SRC Specifications are not intended to replace or interfere with any international, regional, national or local laws and regulations; those governing requirements supersede any industry standards
  • An entity providing SRC payment authorisation capability must be cognisant of the payment processing environment in which that service is provided, and ensure that the introduction of SRC does not have an adverse effect on existing processes
  • The SRC Specifications do not prescribe any single implementation approach, but describe functions and protocols and the interactions between an SRC System and its SRC Participants 1.6 Audience This document is intended for the participants in an ecosystem where SRC is implemented. 1.7

References

The latest version of any reference, including all published amendments, shall apply unless a publication date is explicitly stated.

1.7.1 Normative References The standards in Table 1.1 may be associated with SRC. Reference ISO 3166 Table 1.1: Normative References Publication Name Country Codes — ISO 3166

v1.3

/ 64 Reference ISO 4217 ISO 8583 RFC 3447 RFC 5246 RFC 5322 RFC 7516 RFC 7518 RFC 7519 OpenID Secure Payment Confirmation Publication Name Currency Codes — ISO 4217 Financial transaction card originated messages — Interchange message specifications (1987, 1993, 2003 and other variants where appropriate) Public-Key Cryptography Standards Transport Layer Security (TLS) Protocol Internet Message Format JSON Web Encryption JSON Web Algorithms JSON Web Token OpenID Connect Core W3C specification Secure Payment Confirmation 1.7.2 Published EMVCo Documents The documents in Table 1.2 are related to or are associated with SRC and are located at www.emvco.com. Reference Table 1.2: EMVCo References Publication Name EMV 3-D Secure Specification EMV® 3-D Secure – Protocol and Core Functions Specification Merchant-Presented Mode EMV® QR Code Specification for Payment Systems (EMV QRCPS) – Merchant-Presented Mode Payment Tokenisation EMV® Payment Tokenisation Specification – Technical Technical Framework Framework

v1.3

/ 64 Reference Publication Name Payment Tokenisation EMV® Payment Tokenisation – A Guide to Use Cases A Guide to Use Cases SRC Reproduction Requirements EMV® Secure Remote Commerce (SRC): Click to Pay Icon Reproduction Requirements SRC UI Guidelines and Requirements EMV® Secure Remote Commerce Specification – User Interface Guidelines and Requirements SRC API EMV® Secure Remote Commerce Specification – API SRC JavaScript SDK EMV® Secure Remote Commerce Specification – JavaScript SDK SRC Version Management EMV® Secure Remote Commerce Version Management for SRC API and JavaScript SDK Specifications SRC Use Cases EMV® Secure Remote Commerce Use Cases Transaction Types EMV® Best Practices Document – Recommendations for EMV Processing for Industry-Specific Transaction Types Collectively, the term SRC Specifications refers to:

  • SRC Core Specification (this document)
  • SRC Reproduction Requirements
  • SRC UI Guidelines and Requirements
  • SRC API
  • SRC JavaScript SDK
  • SRC Version Management 1.8

Definitions

The definitions contained within this document apply only to the context of the SRC Specifications and are not representative of other uses outside of the scope of the SRC Specifications. Local market differences in terminology may exist, and these are not reflected in the SRC Specifications. The following terms as defined in Table 1.3 are used in the SRC Specifications.

v1.3

/ 64 Term Table 1.3: Definitions Definition Assurance An assertion of an authentic identity claim(s) provided by SRC Participants for Consumer, Device, Cardholder, Card and/or Relationship identity(s). Binding The process that establishes the relationships to an SRC Profile. Cardholder An individual that has been issued a financial account provisioned to a Payment Card by a Card Issuer, where a Payment Card is used as a PAN or a Payment Token for purchases. CardholderInitiated Transaction A transaction where the Cardholder directly interacts with the Digital Payment Application using a Digital Card. Card Art A visual representation of the Digital Card. Card Issuer A financial institution or its Third Party Service Provider that issues a Payment Card to Cardholders. Click to Pay Icon A visual representation that identifies that SRC is available to the Customer. Consumer An individual with an existing SRC Profile using the services provided within SRC. Consumer Device A Consumer-operated device such as a smartphone, laptop, personal computer, tablet, or voice-activated digital assistant or any application running on a device. Consumer Identity A unique value provided by the Consumer to associate the Consumer with a specific SRC Profile. Customer An individual making a purchase using a Digital Payment Application. Device Identity A combination of attributes enabling the identification of a Consumer Device. Digital Card A digital representation of a Payment Card.

v1.3

/ 64 Term Definition Digital Card Facilitator (DCF) The SRC System Participant which provides a Consumer with access to Digital Card related data and other optional services. Digital Card Feature A card benefit provided by the Card Issuer or SRC System and associated with a Digital Card. Digital Payment Application (DPA) A payment-enabled application that enables the initial interaction of a Customer with a merchant, marketplace or other service provider in order to use SRC to pay for goods or services through a Consumer Device. Dynamic Data A value unique to a transaction used to protect the integrity of the Payment Data. EMV 3-D Secure EMV 3-D Secure authentication is a three-domain model where the acquirer domain and issuer domain are connected by an interoperability domain for the purpose of authenticating a Cardholder or providing verification of their identity during a transaction. Refer to EMV 3-D Secure Protocol and Core Functions Specification. Enrolment The process of associating a PAN with an existing or new SRC Profile. Federated ID Token A digitally signed attestation that the Consumer Identity has been verified by an SRC System. First Party Token An opaque first party authorisation token issued and recognised by the same SRC System. Merchant-Initiated A transaction that relates to a previous Cardholder-Initiated Transaction Transaction but conducted without Cardholder participation. Onboarding The process that establishes credentials that enable an SRC System Participant to interact with an SRC System. Payment Card A payment credential created by a Card Issuer or their agent for a Cardholder to enable a financial transaction. A Payment Card contains Payment Data. Payment Data A PAN or Payment Token required to initiate a payment authorisation request.

v1.3

/ 64 Term Definition Payment Network An entity that operates an electronic system for payment transaction processing, including operating a network switch for purposes of completing payment authorisation, clearing, and settlement for one or more Payment System(s). Payment System An entity that maintains a consumer-facing brand and provides branding guidelines, inclusive of branding requirements for issuers and merchant acceptance environments, may distribute IINs/BINs, defines rules and guidelines for Payment System participants, and develops products and respective product requirements for Payment System participants that are derived from a variety of technologies. Payment Token A surrogate value for a PAN that is an ISO/IEC 7812-compliant numeric issued from a designated Token BIN or Token BIN Range that must pass basic validation rules of a PAN. Payment Tokenisation A specific form of tokenisation whereby Payment Tokens are requested, generated, issued, provisioned, and processed as a surrogate for PANs. Refer to EMV Payment Tokenisation Specification – Technical Framework. Primary Account Number (PAN) An ISO/IEC 7812-compliant account number that is generated within account ranges associated with a PAN BIN or PAN BIN Range by a Card Issuer. Registration The process by which a Digital Payment Application is identified by an SRC Initiator to an SRC System. SRC Candidate List A list of Digital Cards and related data that are eligible for a specific checkout. SRC Initiator The SRC System Participant which presents an SRC Candidate List and potentially facilitates the retrieval of Payment Data. SRC Participant An Onboarded or Registered entity that participates in SRC. SRC Participating A Card Issuer that has its Payment Cards enrolled in SRC Systems. Issuer (SRCPI) SRC Profile A collection of data within an SRC System comprising a primary Consumer Identity and optional data elements such as Payment Card(s), Digital Card(s), Consumer information, and Device Identity(s).

v1.3

/ 64 Term Definition SRC Programme Responsible for the policies and processes associated with the oversight of SRC Participants within an SRC System. SRC System A technical platform that manages an SRC Profile for each enrolled Consumer and facilitates the payment information exchange among all SRC System Participants. SRC System Participant An entity that is Onboarded to an SRC System. SRC Trigger The point of initialisation for checkout which may accompany a Click to Pay Icon.

1.9 Notational Conventions 1.9.1 Abbreviations The abbreviations listed in Table 1.4 are used in the SRC Specifications. Abbreviation 3DS ACS API AReq ARes AVS BIN CDCVM CSC Table 1.4: Abbreviations

Description

EMV 3-D Secure Access Control Server Application Programming Interface Authorisation Request Authorisation Response Address Verification Service Bank Identification Number Consumer Device Cardholder Verification Method Card Security Code

v1.3

/ 64 Abbreviation DCF DPA FIDO ID&V IIN IoT JSON JWE JWS KBA OTP PAN PCI DSS PII QR SCA SDK SPC SRC SRCI SRCPI T&Cs Description Digital Card Facilitator Digital Payment Application Fast Identity Online Identification and Verification Issuer Identification Number Internet of Things JavaScript Object Notation JSON Web Encryption JSON Web Signature Knowledge Based Authentication One Time Passcode Primary Account Number Payment Card Industry Data Security Standards Personally Identifiable Information Quick Response Strong Customer Authentication Software Development Kit Secure Payment Confirmation Secure Remote Commerce Secure Remote Commerce Initiator Secure Remote Commerce Participating Issuer Terms & Conditions

v1.3

/ 64 Abbreviation TLS TSP UI UTC Description Transport Layer Security Token Service Provider User Interface Coordinated Universal Time 1.9.2 Terminology and Conventions The following words are used in the SRC Specification and have a specific meaning: SHALL/MUST Defines a product or system capability which is mandatory. MAY Defines a product or system capability which is optional or a statement which is informative only and is out of scope for the Specification. SHOULD Defines a product or system capability which is recommended. The following conventions apply: Defined Terms, Operations, Methods and Data Elements The SRC Specifications use capitalisations, camel case and different fonts, with the following conventions, to refer to:

  • Defined terms (see Table 1.3) are capitalised with no other qualification (e.g. Digital Card Facilitator)
  • SRC API operations are capitalised and followed by the word “operation” (e.g. Checkout operation)
  • SRC JavaScript SDK methods are in camel case and followed by “() method” (e.g. enrollCard() method)
  • SRC API and SRC JavaScript SDK complex data objects are capitalised and in Courier New font (e.g. DigitalCardData)
  • SRC API and SRC JavaScript SDK data elements are in camel case and Courier New font (e.g. srcCorrelationId)
  • Booleans are in lower case and in Courier New font (e.g. true) v1.3 / 64 2 Overview Secure Remote Commerce (SRC) offers an approach to promote security and interoperability within the card payment experience in a remote payment environment. SRC facilitates the delivery of interoperable Payment Data to a merchant, during checkout, in order for the merchant to process a payment. The core tenets of SRC are:
  • Consumer Awareness: the Consumer is aware that an SRC experience is occurring when initiating checkout
  • Consumer Recognition: the ability for a Consumer to be recognised and authenticated using a unique Consumer Identity
  • Card Selection: presentation of an SRC Candidate List to a recognised Consumer in order to select a card
  • Consumer Review & Confirmation of Checkout: presentation of all related payment information to be edited and confirmed by the Consumer
  • Payload Delivery: providing Payment Data and transactionally unique Dynamic Data to authorised participants in order to facilitate payment authorisation A brief description of the entities involved in SRC is given in Table 2.1. v1.3 / 64 Entity SRC Programme SRC System SRC Initiator Digital Card Facilitator SRC Participating Issuer Digital Payment Application Table 2.1: SRC Entities Description Responsible for the policies and processes associated with the oversight of SRC Participants within an SRC System. A technical platform that manages an SRC Profile for each enrolled Consumer and facilitates the payment information exchange among all SRC System Participants. The SRC System Participant which presents an SRC Candidate List and potentially facilitates the retrieval of Payment Data. The SRC System Participant which provides a Consumer with access to Digital Card related data and other optional services. A Card Issuer that has its Payment Cards enrolled in SRC Systems. A payment-enabled application that enables the initial interaction of a Customer with a Merchant, marketplace or other service provider in order to use SRC to pay for goods or services through a Consumer Device. Enabling innovation requires flexibility in the user experience to support a variety of different use cases. At the same time, consistency across some elements help deliver streamlined user experiences across SRC Programmes which drive increased conversion and better repeat experiences. The SRC UI Guidelines and Requirements describe the common presentation elements of the user experience supported within SRC. These include:
  • SRC Trigger
  • Input for Consumer Identity
  • Consumer Assurance
  • SRC Candidate List
  • Payment method and Cardholder information confirmation The user experience for SRC is completed when the checkout process returns control to the Digital Payment Application. An example flow for a remembered Consumer is shown in Figure 2.1. v1.3 / 64 Figure 2.1: Example Consumer Flow SRC Initiator When a Consumer indicates an intent to complete a purchase, the following specific actions are enabled:
  • Initialisation: presentation of an SRC Trigger within the Digital Payment Application that indicates to the Customer that an SRC experience is available. The SRC Trigger (Checkout button or SRC Trigger button above) is the point of interaction that activates the SRC experience
  • Card selection: presentation by the SRC Initiator of the SRC Candidate List that enables the Consumer to select the Digital Card to be used for payment
  • Consumer review: presentation by the Digital Card Facilitator of confirmation information that includes:
  • Delivery Information: personal data (that may be changed by the Consumer) that accompanies a purchase
  • Acknowledgement: validation of the selected Digital Card and personal data
  • Merchant completion: return of the user experience to the Digital Payment Application that will indicate any next steps necessary to process payment. SRC Systems assess whether additional Assurance is needed to perform a specific action. This assessment is use case specific and determined by the policies of the SRC Programme. For example, additional Assurance could be attempted to authenticate the Consumer Identity. In addition, the SRC Use Cases document describes various use case examples under the categories of:
  • Enrolment v1.3 / 64
  • Checkout (SRC and Merchant)
  • Management Service
  • Recognition
  • Authentication Facilitation These use case examples provide guidance for SRC within existing payment ecosystems and the considerations associated with various usage scenarios. They are neither exhaustive nor representative of all possible usage scenarios supported by the SRC Specifications since the associated usage scenarios may require additional considerations not provided here. Each use case may use certain functions enabled by the SRC API or SRC JavaScript SDK in an SRC System specific way to enable the desired experience. v1.3 / 64 3 SRC Participants This Section provides details on the various SRC Participants, their roles and how they interact to enable SRC experiences. While the SRC Specifications provide flexibility for participation, they do not:
  • Prescribe which entities can act as which SRC System Participant
  • Define new actors or suggest modifications to existing relationships between payment ecosystem participants. Note that as shown in Figure 3.1, the SRC Specifications distinguish between:
  • SRC Participants, encompassing the SRC System, SRC Initiator, Digital Card Facilitator, Digital Payment Application and the SRC Participating Issuer
  • SRC System Participants, encompassing entities that interact directly with the SRC System (SRC Initiator, Digital Card Facilitator and the SRC Participating Issuer) Figure 3.1: SRC Participants v1.3 / 64 3.1 SRC Programme An SRC Programme is established by a business entity responsible for the policies, requirements and processes associated with the oversight of participating SRC Systems and all SRC Participants. Examples of policies, requirements, and processes that could be established by an SRC Programme include, but are not limited to, the following:
  • Onboarding and configuration for SRC System Participants
  • Registration and configuration for Digital Payment Applications
  • Enrolment of Consumers and Payment Cards into an SRC System
  • Visual guidance for SRC System Participants
  • Supported Assurance methods
  • Use and management of Payment Data
  • On-going operation and maintenance of participating SRC Systems
  • Lifecycle management of configuration data
  • Security policies for SRC Systems and SRC Participants
  • Performance requirements for SRC Systems and SRC Participants
  • Policies for usage of the SRC API and the SRC JavaScript SDK
  • Types of checkout supported
  • Criteria that define the relationship of Digital Cards to Digital Card Facilitators 3.2 SRC System An SRC System is a technical platform that is established by a business entity. It manages an SRC Profile for each enrolled Consumer and facilitates the payment information exchange among all SRC System Participants. An SRC System is responsible for implementing SRC Programme policies, requirements and processes. These responsibilities may include but are not limited to:
  • Onboarding, management and integration of SRC System Participants
  • Registration, management and integration of Digital Payment Applications
  • Orchestration of the checkout experience
  • Creation and management of SRC Profiles
  • Ensuring adequate controls of Personally Identifiable Information (PII) data v1.3 / 64
  • Federating ID Token management with other SRC Systems and/or other identity providers
  • Configurations related to the use of unique Dynamic Data in Payment Data
  • Delivering Payment Data in accordance with established Payment System and Payment Network transaction processing requirements
  • Implementing the functions defined in the SRC API and SRC JavaScript SDK in accordance with the requirements of the SRC Programme
  • Maintaining and distributing a JavaScript SDK
  • Hosting a recognition subdomain to enable Consumer recognition for browsers 3.3 SRC Initiator An SRC Initiator provides the following functionality:
  • Registration of Digital Payment Application(s)
  • The SRC Initiator manages Registration for its participating Digital Payment Applications
  • A Digital Payment Application can be Registered by multiple SRC Initiators.
  • Integration with SRC System(s)
  • An SRC Initiator may provide support for a specific technology (e.g. web, mobile application, IoT services)
  • An SRC Initiator may implement recognition subdomain functionality to allow Consumer recognition for browser-based use cases SRC Initiators also provide payment and/or non-payment functions. In some cases, an entity may provide all functions of an SRC Initiator. In other cases, functions may be split between entities:
  • Payment functions (Section 9 Payment Enablement)
  • Receives Payment Data from an SRC System
  • Entities that provide payment services on behalf of merchants can be SRC Initiators in their own right. Such entities indicate which merchant they are servicing by providing the appropriate Digital Payment Application configuration data to SRC Systems
  • Provides payment confirmation to the SRC System
  • Non-Payment functions (Section 10 Non-Payment Functions) v1.3 / 64
  • Initiation of checkout, presentation of SRC Candidate List (see Section 8.3.1 SRC Profile Retrieval) and completion of checkout
  • Provides checkout confirmation to the SRC System
  • Transmits and receives checkout data on behalf of a Digital Payment Application to SRC Systems indicating transaction details and service elections 3.4 Digital Card Facilitator The Digital Card Facilitator provides access to Consumer data such as billing address, shipping addresses and other data tied to a specific Consumer Identity, provided it is relevant to, and requested by, various SRC Participants. In Secure Remote Commerce, Digital Card Facilitators are responsible for providing the ability to Consumers to review and confirm the Digital Card and payment-related data associated with a specific checkout.

3.5 SRC Participating Issuer (SRCPI) An SRC Participating Issuer is configured in each SRC System to establish eligibility and enable Enrolment of its Cardholders and their related PANs. An SRC Participating Issuer may:

  • Identify its BIN and or BIN ranges eligible to participate in SRC so that eligibility can be determined by the SRC System
  • Provide Card Art and other data that is used to surface the Digital Card to the Consumer
  • Determine the default Digital Card Facilitator(s)
  • Provide Assurance method preferences to be used during an Enrolment or checkout
  • Provide Enrolment data to the SRC System to facilitate Cardholder participation in SRC The SRC Participating Issuer also manages other business processes related to Enrolment defined by the SRC Programme. v1.3 / 64 3.6 Digital Payment Application A Digital Payment Application enables the initial interaction of a Customer with a merchant. A Digital Payment Application can be any payment-enabled application such as a website, mobile application or IoT device. Participation of the Digital Payment Application is based on the following:
  • Relationship with SRC Initiator(s): Each Digital Payment Application integrates with one or more SRC Initiators. As part of integration, the SRC Initiator may register the Digital Payment Application for participation in each SRC System
  • Selection of Digital Payment Application(s): The merchant, or any other commerce provider, selects which of its Digital Payment Applications will participate in one or more SRC System(s) through one or more SRC Initiator(s)
  • SRC Trigger: The requirement to support a specific SRC Trigger is defined by the SRC Programme and the types of checkout supported as described in Section 8.2 SRC Trigger Merchants can elect to integrate with multiple front-end SRC Initiators (shopping carts, gateway providers etc.) and need to consider implications for their Digital Payment Application and SRC experience. A Digital Payment Application provides the following functionality:
  • Presenting an SRC Trigger and providing indication of which SRC Systems it supports to the Consumer
  • Invoking one or more SRC Initiators
  • Conveying data to SRC Initiators indicating transaction details and service elections, which may include but is not limited to Payment Tokenisation and EMV 3-D Secure payment authentication
  • Providing checkout confirmation information to the SRC Initiator v1.3 / 64 4 Onboarding and Registration SRC Participants are established within an SRC Programme through a series of set-up events orchestrated by the SRC System. Once established, the SRC System continues to manage SRC Participants’ data throughout their life cycle. The establishment and subsequent management of SRC Participants occur using the following set-up events provided by SRC Systems:
  • Onboarding of SRC System Participants
  • Registration of Digital Payment Applications For each of the above events, the SRC Systems stores configuration settings and, as allowed by the SRC API or SRC JavaScript SDK, configuration data can be overridden during checkout and payment. While these events are orchestrated by the SRC System, the data requirements, processes and methods associated with Onboarding and Registration are outside the scope of the SRC Specifications. For example, an SRC System may use batch processes, automated tools or portals to enable manual entry of data, or a combination of these to facilitate Onboarding or Registration.

4.1 Onboarding of SRC System Participants Onboarding establishes:

  • The relationship between the SRC System Participants and SRC Systems
  • Credentials that enable the interaction between the SRC System Participants and the SRC Systems Onboarding to SRC Systems is supported for the following SRC System Participants:
  • Digital Card Facilitator
  • SRC Initiator
  • SRC Participating Issuer The following may be performed by an SRC System during Onboarding:
  • Obtain business-related information from each SRC System Participant.
  • Generate unique reference identifiers for each SRC System Participant
  • Exchange keys with SRC System Participants to enable signing and verification (e.g. JWS) and application-level encryption (e.g. JWE) v1.3 / 64
  • Establish settings for features and services offered by the SRC System for checkout and payment
  • Management of transaction settings for Payment Tokenisation and payment authentication using EMV 3-D Secure
  • Manage configurations for each SRC System Participant such as:
  • Unique reference identifiers for every SRC Participant in the SRC System
  • Adding and managing relevant configuration details
  • Allowing access to SRC Profile data 4.2 Registration of Digital Payment Application Registration establishes the identity of the Digital Payment Applications within the SRC Systems through the Digital Payment Application’s related and previously Onboarded SRC Initiator(s). SRC Systems may require that the Digital Payment Application has been Registered before it initiates a checkout. For these SRC Systems, SRC Initiator(s) are required to provide the necessary Digital Payment Application data for each of the Digital Payment Application(s) they service. As a Digital Payment Application may have a relationship with multiple SRC Initiators, each SRC Initiator will perform a separate Registration. At a high level, Registration involves the establishment of a unique reference identifier and configuration settings for each Digital Payment Application within each SRC System. For SRC Systems that do not require the Digital Payment Application to be Registered prior to checkout, the necessary Digital Payment Application data is provided during checkout. For SRC Systems that require the Digital Payment Application to be Registered prior to checkout, the optional Management Service APIs are available in Section 10.5 Management Service. v1.3 / 64 5 SRC Profile and Digital Card This Section describes the SRC Profile and Digital Card.

5.1 SRC Profile Each SRC System creates and manages SRC Profiles

Each SRC Profile has a primary Consumer Identity, which the Consumer uses to access the SRC Profile, and optional data elements which can include:

  • Payment Card(s)
  • Digital Card(s)
  • Consumer information
  • Device Identity(s) While an SRC Profile is created during Enrolment, it may be added to and/or managed during subsequent SRC interactions. Figure 5.1 shows the relationships between the main data elements within the SRC Profile. Figure 5.1: SRC Profile Organisation Note: more details on data elements can be found in the SRC API. v1.3 / 64 The initial SRC Profile is created during Enrolment. The SRC System then manages the SRC Profile throughout its life. This includes:
  • Adding new data elements (e.g. Consumer adds a new Payment Card)
  • Updating content of existing data elements (e.g. Consumer changes a shipping address)
  • Deleting existing data elements (e.g. Consumer removes a device from the SRC Profile) Changes to the SRC Profile can occur due to any of the following:
  • Enrolment
  • Binding
  • Lifecycle mangement How the SRC Profile data is configured, or managed, by the SRC System is outside the scope of the SRC Specifications. When the SRC System provides an SRC Profile to an SRC System Participant, the results are dependent on the following:
  • Policies and requirements of the SRC Programme
  • Configured selections of the Digital Payment Applications, Consumers, and SRC Participating Issuers.
  • Capabilities and services available for the Digital Card Facilitators The above may also affect the level of data provided for a Digital Card as presented content can affect Customer usability, and the overall user experience.

5.2 Digital Card The Digital Card represents the underlying PAN (Payment Card or Payment Token) within SRC. It is used for:

  • All communication with the Consumer/Cardholder such as purchase receipts, order confirmation pages, emails, text messages, chat-bots, messenger platforms, etc.
  • Enabling the Consumer to make a selection from the SRC Candidate List Accompanying the Digital Card is a visual version of the Payment Card commonly referred to as Card Art. v1.3 / 64 An SRC System may also manage Digital Card Features. These enable the SRC System and/or the Card Issuer to present a card benefit to the Consumer at checkout. Some examples of card benefits may include, but are not limited to:
  • Complimentary memberships
  • Concierge services
  • Event ticket protection
  • Extended warranty How Digital Card Features are received and managed by the SRC System is out of scope of the SRC Specifications.

5.3 Data Obfuscation Within SRC, Consumer PII data such as name, address, email address or phone number should be obfuscated when presented. It is the responsibility of the SRC Participants to ensure that the communication and presentation of PII data related to the Digital Card or Consumer is obfuscated as required by local regulations, SRC Programme policies and Payment System policies. Obfuscation of information may be achieved by following the masking rules and best practices defined in Annex B Data Obfuscation. The masking rules and best practices ensure obfuscation of data is conducted in a consistent manner that enables the Consumer to recognise their information while limiting the potential for others to determine the PII data.

v1.3

/ 64 6 Card Services This Section describes:

  • Enrolment of a PAN in an SRC System
  • Management of enrolled PANs
  • Management of the SRC Profile 6.1 Enrolment Typically, an SRC Participating Issuer drives Enrolment by providing Cardholder PAN(s) and associated Consumer Identities to an SRC System. However, Digital Card Facilitators and SRC Initiators, based on SRC Programme participation policies, can also initiate Enrolment. The Cardholder must provide consent to participate in SRC by electing or confirming Enrolment of its PAN(s) in an SRC System. If an SRC Profile already exists for the Cardholder, then when a PAN is Enrolled, it will be associated with the existing SRC Profile, otherwise the SRC System will create a new SRC Profile. An SRC System may support proprietary batch processes for Enrolment, allowing simultaneous Enrolment of more than one PAN. Batch Enrolment details are not in scope of this Specification. The SRC API and SRC JavaScript SDK define operations/methods to facilitate Enrolment, which are shown in Table 6.1. Specification Table 6.1: Enrolment Operations/Methods API/SDK Operation/Method SRC API Card Enrolment SRC Java Script SDK enrollCard() checkout() v1.3 / 64 The functions associated with Enrolment are shown in Figure 6.1. Figure 6.1: Enrolment 6.1.1 SRC Profile Creation When creating an SRC Profile, the SRC System includes assigned values as well as information provided by the Consumer. As a minimum, each SRC Profile must have:
  • A Consumer Identity
  • A unique identifier for the SRC Profile Examples of additional information contained within an SRC Profile are given in Figure 5.1. The SRC System will also keep a record of when the SRC Profile was created. v1.3 / 64 6.1.2 Digital Card Creation The SRC System creates Digital Card instances of the Payment Card associated with the underlying PAN. When creating a Digital Card, the SRC System includes assigned values as well as Payment Card and Cardholder information such as:
  • An SRC System specific reference identifier for each Digital Card and Payment Card
  • Payment Data (a Payment Token may be requested for the PAN during Enrolment)
  • BIN and last four digits of Payment Data
  • Digital Card presentation information (Card Art)
  • Cardholder Assurance methods associated with the Digital Card The SRC System will also keep a record of when the Digital Card was created. Note: Payment Tokenisation – A Guide to Use Cases gives example use cases showing how SRC can combine with Payment Tokenisation to issue a Payment Token for the PAN during Enrolment.

6.2 Managing Digital Cards The SRC API and SRC JavaScript SDK provide a number of operations/methods to allow an SRC System to manage Digital Cards.

6.2.1 Delete Card Table 6.2 shows the operations/methods defined by SRC API and SRC JavaScript SDK to delete a Digital Card from an SRC Profile. Specification Table 6.2: Delete Card Operations/Methods API/SDK Operation/Method SRC API Delete Card SRC JavaScript SDK deleteCard() 6.2.2 Add Billing Address Table 6.3 shows the operation defined by SRC API to add a billing address to an SRC Profile.

v1.3

/ 64 Table 6.3: Add Billing Address Operations/Methods Specification API/SDK Operation/Method SRC API Add Billing Address SRC JavaScript SDK N/A

v1.3

/ 64 7 Identity Management This Section describes how the Consumer Identity and Device Identity are recognised and managed within SRC.

7.1 Identity Recognition Identity recognition occurs when a Consumer Identity or Device Identity is presented to an SRC System and is performed prior to enabling access to the SRC Profile. Functions such as Checkout and SRC Candidate List retrieval require successful recognition of the available identity(s) before enabling access to the associated SRC Profile:

  • Device Identity recognition: determines if the provided Device Identity is associated with, and has authorised access to, an existing SRC Profile. Device Identity recognition may be performed prior to Consumer Identity recognition
  • Consumer Identity recognition: determines if the provided Consumer Identity is associated with, and has authorised access to, an existing SRC Profile
  • Additional identity recognition information: if the Device Identity or Consumer Identity is not successfully recognised (i.e. it is not associated with an existing SRC Profile) this may lead to collection of additional information where appropriate Table 7.1 shows the operations/methods defined by the SRC API and SRC JavaScript SDK to facilitate identity recognition and validation. Table 7.1 Identity Recognition Operations/Methods Specification API/SDK Operation/Method SRC API Identity Lookup Initiate Identity Validation Complete Identity Validation Is Recognized SRC JavaScript SDK identityLookup() initiateIdentityValidation() completeIdentityValidation() isRecognized() © 2018-22 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.emv

Shown in part. Read the original for the full text.