SRC Eagle Has Landed !
On June 7th the EMVCo has finally published its official version of Secure Remote Commerce (SRC) Specification (v1.0), announced over a year ago. Back in 2018 EMVCo has released an interim draft v0.9 for public and private feedback and comments. Therefore, the v1.0 can be seen as an incremental evolutionary upgrade from v0.9, based on the collected industry feedback. That means that the participant roles, underlying framework and proposed flows are pretty much the same in both versions, with v1.0 delivering clarifications, more details and final fine tuned updates. If you had read previous version of the SRC specification, you will definitely be very familiar with most of the concepts presented in this version.
The EMVCo SRC specification is generic attempt aimed at simplifying checkout process in e-commerce transactions when using payment cards. It has also provisions for improving security, as part of the flow, like:
Dynamic transaction cryptograms (for transaction replay prevention)
PAN tokenization (for payment credential protection)
3D-Secure 2.0 (user authentication)
At this point it is not clear HOW each of the payment schemes will exactly implement the EMVCo SRC framework vision, and industry will have to wait for those implementations to be officially released, with its own APIs / SDKs and SRC sandboxes for early on-boarding, experimentation and certification. At this time, we have promises by all major payment schemes that they are targeting second half of 2019 for general availability, so stay tuned.
It is also unclear whether SRC usage may get mandated by EMVCo members (payment schemes, issuers and acquirers) for all e-commerce transactions using payment cards. In our personal view, if the EMVCo membership is serious about eliminating e-commerce fraud with payment cards, mandatory SRC usage should be something to seriously consider for sure. However, since there might be several conflicting goals that SRC community is pursuing at the same time, this mandate may be unlikely to happen, meaning unfortunately that payment cards industry will miss (again) the opportunity for strong standardization (long overdue) on EMV-like transacting with payments cards across all the channels.
SRC framework distinguishes between several main participating roles:
SRC Initiator (SRCI) – initiates checkout flow to securely retrieve payment card credentials and shipping address data for the current e-commerce transaction. This function is most likely going to be provided by e-commerce PSPs / Acquirers to their e-commerce merchant clients
Digital Shopping Application (DSA) – merchant's own e-commerce shopping cart, e-commerce checkout web page, etc
SRC System – main core of the SRC framework implementation, which orchestrates the flows between all participating roles, most likely to be provided by major payment schemes
Digital Card Facilitator (DCF) - The entity that provides a consumer with secure storage for and access to one or more digital cards and billing/shipping addresses to facilitate the checkout experience. This function is most likely going to be provided by current providers of digital wallets like MasterPass, Visa Checkout, potentially PayPal, and others.
SRC Participating Issuer (SRCPI) – card issuer which enrols its Payment Cards with each of the SRC Systems and which authorizes the e-commerce transactions paid by using payment cards
SRC Programme – set of policies, procedures, rules for governing and oversight of the SRC operation and participants
The end to end SRC framework architecture is shown on the picture below. It shows how all of the roles (except SRC Programme, which is mainly governance, non-architectural role) are connected and what main domains comprise the SRC framework.
SRC introduces the set of the following environments / domains:
Acceptance Environment / Domain - responsible for standardized e-commerce payment triggering and initiation
Orchestration Environment / Domain - responsible for standardized orchestration of all checkout steps during a payment card based e-commerce transaction
Card Environment / Domain - responsible for storage, lifecycle management and provisioning of the e-commerce payment credentials and shipping address to the Acceptance Environment for the ongoing transaction
Note that the Payment Environment is outside the SRC scope ... it is staying as it is today, with its card payments authorization rails (with Acquirers, Payment Networks and Issuers) and 3D-Secure domains for secure payor authentication.
SRC System Processes
According to the EMVCo documentation, all compliant SRC Systems are going to be fully standardized in terms of governance processes and procedures. Only officially verified, on-boarded and certified players would be allowed to connect and participate. The following are main governance processes that are going to be enforced by SRC System:
On-boarding - this process establishes the relation between the SRC Participants and exchanges credentials for participation and enablement of events with the SRC System. On-boarding to the SRC System will be mandatory for Digital Card Facilitators, SRC Initiators and SRCPIs
Registration - this process enables the integration of SRC with merchant's Digital Payment Applications by establishing a unique reference identifier (SRC DPA Identifier) assigned for each Digital Payment Application participating in a specific SRC System
Enrolment - the process for creation of a Digital Card instance (config for Digital Card display, selection, and confirmation for Consumer interactions), assignment of SRC Digital Card Reference Identifier (identifies the underlying PAN) and establishment of Cardholder Assurance method (used for Customer Identification and Verification during Card Enrolment and/or e-commerce Checkout)
Binding - establishes the tight relationship between the Consumer Identifier, enrolled Payment Card, Device Identity and Digital Card Facilitator (DCF)
Beside pure governance processes, every compliant SRC System orchestrates standardized SRC Checkout Process, via following discrete steps
Identity Collection - step for collecting relevant data required to uniquely identify an SRC Profile that needs to be verified by the SRC System. SRC Profile is represented in SRC System as a collection of related data records about Digital Card(s), Consumer Identity(s), Consumer Device Identity(s) and their association to Digital Card Facilitator(s).
Recognition - step for identifying an SRC Profile based on collected data in Identity Collection
Assurance - step with rules for confirming successful outcome of the Identity Collection and Recognition steps
DCF Discovery - step is which the relationships previously established aspart of the SRC Profile creation, in Binding and Enrolment processes, are utilized to identify which DCF is to be used for the ongoing e-commerce transaction
Payment Credentials Collection - step in which the SRC System collects payment credentials (including unique per transaction cryptogram) and shipping address data from the SRC Profile.
Payload Delivery - step in which the final payload containing the transaction data, payment credentials, unique per transaction dynamic cryptogram and shipping address is delivered from the SRC System to the SRC Initiator. SRC Initiator then facilitates the submission of the final payload for authorization via the merchant's e-commerce PSP
SRC vs. W3C
Since World Wide Web Consortium (W3C) is also trying to standardize and streamline web payments with their own W3C Payment Request / Payment Handler framework, it is important to compare the two and understand how and where they differ. We will quickly compare them in several important categories.
SRC e-commerce framework is designed to be as generic as possible and to be customer agent (i.e. transacting device) agnostic. As such it shall be able to support e-commerce payments with payment cards initiated through browsers, merchant mobile apps, IoT devices, voice assistants, payment enabled cars, etc. On the other hand, W3C framework is by design limited to e-commerce transaction initiations through web browsers (desktop or mobile) only.
SRC is biased toward streamlined and secure utilization of payment cards as payment method, while W3C framework is payment method agnostic with possible support for: payments cards (tokenized or not), direct debit (pay from bank account), digital wallet, cryptocurrency, etc
SRC framework implementations are not yet available, and are expected to be provided by major payment schemes in second half of 2019, based on major payment networks' announcements. In comparison, W3C framework is already available today. Payments Request API is already implemented and supported by all major web browsers (Chrome, IE, Safari, Mozilla, etc). Browsers acts as a mediators between merchant's checkout page and compliant W3C Payment Handler applications (responsible for end user authentication and provisioning of the payment credentials back to the merchant via browser). W3C Payment Handlers apps can be implemented either as web browser plug-in, mobile app or standalone web application.
SRC framework is designed with provisions for handling Strong Customer Authentication (via its support for 3D-Secure 2.0) and payment card lifecycle (via tokenization). Like original EMV in chip-card transactions at POS, SRC uses dynamic data (i.e. random number combined with real transaction data, protected by unique per transaction cryptogram) in each transaction. The W3C does not address Strong Customer Authentication as part of their framework. However, W3C does not preclude using 3D-Secure as part of the Payment Handler implementation for end user authentication. W3C also has complementary but separate framework for Web Authentication that can be used.
Payment Credentials And Shipping Address Data Handling
SRC framework standardizes and prescribes that payment card data and customer shipping address shall be securely stored and managed by the DCF providers, while W3C framework is not prescribing how and where the payments credentials and customer shipping address are managed and stored (they can be stored inside a browser, or managed by the Payment Handler providers)
SRC e-commerce framework is designed to be tightly regulated and governed. As such it comes with a set of SRC Program policies, rules and regulations, provided by the SRC System provider. On the contrary W3C framework is browser based standard and doesn't have any formal governance (for now).
Are SRC and W3C Frameworks Mutually Exclusive?
Good news is that is looks that these two frameworks could easily and elegantly be combined going forward. For example, W3C Payment Handler app can act as SRC Initiator and SRC DCF in one component. However, the exact possibilities for combining them will be much clearer once payments schemes release their specific SRC System implementations
"One Button To Rule Them All"?
Since one of the motivations behind SRC is to simplify and streamline the checkout flow by reducing the number of checkout buttons, what will future of checkout look like after payment schemes fully rollout their SRC Systems?
Since payment schemes are free to implement SRC specification in their own ways, it is still unclear whether providers of SRC systems will even agree on a single SRC button or if each SRC System will offer their own specific SRC checkout button.
Will availability of SRC Systems eliminate PayPal and AmazonPay buttons from the checkout pages? For example, as part of the push for reduction of online payment card fraud levels, payment schemes and card issuers may decide to limit e-commerce transacting with payment cards, only through SRC and OEMPays (ApplePay, GooglePay and SamsungPay) channels, as those are designed to provide EMV-like security protection and governance.
If that mandate happens, PayPal and AmazonPay would likely play roles of compliant SRC Initiators and DCFs in case customer is paying using payment cards. However, their own individual buttons could still be needed and present for cases when user is paying outside of payment card rails, from the their PayPal or AmazonPay pre-funded digital wallet balance.
Therefore, most likely the Nascar-like clutter on checkout pages will continue to exist reflecting variety of payment methods and options.