7 Things Every Issuer And Bank Should Know About The Secure Remote Commerce (SRC)
A few months have passed since the EMVCo. Secure Remote Commerce specification was published and yet if you search the topic on the internet, it is hard to find an article that simply explains the key takeaways for banks or issuers. First of all, not everyone has the time or interests to read a technical specification. Second, even if you do have interest and time, the EMVCo. specifications only describes a framework for SRC and therefore, it is too generic to draw any conclusion on roles and responsibilities in the SRC ecosystem. Therefore, everyone is waiting for the payment schemes to publish their specifications and shed light on this topic.
While waiting for the schemes to get a clear direction is an option, we were too impatient to wait and decided to do our own research to find answers to questions we had or got from people asking. In this article, we would like to share with you our understanding of SRC specification and our reflections on 7 top questions that every issuer or bank might ask about SRC.
Disclaimer: The views and opinions expressed in this article are solely ours and do not necessarily express the views or opinions of any official body, such as EMVCo. or the payment schemes.
1) What is SRC exactly and why should I care?
Secure Remote Commerce is all about online shopping, so-called online-payments, eCommerce, mCommerce, digital commerce, Web-based payment, etc. According to the specification, the framework is focused on card payments and is aimed at:
Addressing the fragmentation and complexity of existing online payment implementations (for example, think about Paypal, Masterpass, Visa Checkout, Twint, or other domestic checkout solutions)
Increase security of online payment, by leveraging existing tokenization technology (aka, replacing the payment card data with tokens) and 3-D Secure 2.0 (aka, cardholder authentication).
Looking at these two main aims, it is clear why issuers should care about SRC and why they should know about the impacts for them. Are you curious now? Just continue reading!
2) ‘Who’ does ‘What’
The picture below shows a high-level overview of SRC participants based on the EMVCo. specification:
EVMCo. defines the followings 6 roles in the SRC ecosystem:
SRC Initiator (SRC I): Supports Checkout and/or the secure retrieval of Payment Data from the SRC System on behalf of a payment embedded application, provided by a merchant or its service provider.
Digital Shopping Application (DSA): A payment embedded application (on the merchant side) facilitating consumer experience for SRC.
SRC System: Orchestrate of all activities between participants and manage technical aspects of SRC programme.
Digital Card Facilitator (DCF): The entity that provides a consumer with access to one or more digital cards and billing/shipping addresses to facilitate the checkout experience.
SRC Participating Issuer (SRC PI): A Card Issuer which enrols its Payment Cards with SRC Systems.
SRC Programme: Responsible for the policies and processes associated with the oversight of SRC participants within an SRC System.
As you can see, most of the roles in the SRC ecosystem are rather straightforward. For instance, SRC I and DSA can be covered by PSPs and merchants. The SRC System role can be fulfilled by the payment schemes (e.g, Mastercard and Visa) and SRC PI will be fulfilled by issuers. The only role that remains rather open, is the role of DCF. While payment schemes wallets, such as masterpass and Visa Checkout, could fulfil this role, the question is if the role is open to other participants and if so, what are the other potential participants for such a role?
3) What should an Issuer do?
The most important role issuers have is to enable cardholders for SRC payments by enrolling their Payment Cards into SRC system. The enrollment process requires that issuers define the following parameters on the SRC system:
Eligible BIN (Bank Identification Number) Ranges for SRC
Card Arts: to be displayed to cardholders during the checkout
Preferences regarding the order of Verification Methods done by DCF: This means that issuers decide what level and type of assurance is needed to be performed to provide cardholders access to cards. Examples of such verification methods are OTP, Authentication App, Knowledge-Based Questions, etc. Most likely, this verification method will be influenced by regulatories or requirements such as PSD2 Strong Customer Authentication.
Cardholder Consent /Authentication to complete a (non-) payment transaction. We assume that this part is related to 3-D Secure technology and the issuer’s channel and preferences for performing a 3-D Secure authentication.
Default DCF to support enrolment: Issuers can define a default DCF to onboard cardholders.
Contact Information for cardholders, in case of questions or issues during SRC
If the issuer participates in Tokenization and if so, identifying Token Service Providers for the BIN Range: As mentioned earlier, SRC is built upon tokenization technology to replace the card data stored at merchants or DCF with tokens to reduce the risk of data breaches.
Eligible Transaction Types supported by the Issuer
It looks like that issuers have to define almost the same parameters as when they enable tokenization for their BIN Ranges. This indicates that the path to SRC would be rather straightforward for issuers, who:
Are connected to tokenization systems such as MDES (Mastercard), VTS (Visa) and American Express Token Service (American Express)
Have a cardholder authentication channel in place (e.g., 3-D Secure 2.0).
The list of parameters to be defined by issuers also shows that issuers have full control over if and how their cards can be used in SRC transactions.
4) How might the customer journey look like?
There is not yet a definite view on how the customer journey would look like, and there will be different flows, depending on if the customer is registered for SRC and if a merchant remembers the customer. However, the EMVCo. specification has defined some UI guidelines for customer recognition. In the picture below, you can see an example user experience for a customer that has been registered by the issuer for SRC:
As mentioned, this is an example of UX and some steps could be performed differently or skipped altogether. For example, based on the transaction risk parameters, an issuer may decide to authorize the payment without additional cardholder authentication (the last step).
Another important point is that the list of registered cards and the shipping address are provided by DCFs. Our speculation is that wallets such as masterpass can be an example of a DCF that provides the cards available in the masterpass wallet for the identified cardholder.
6) Where do 3-D Secure 2.0 and Tokenization fit in?
EMVCo. specification only explains that these two technologies can be used as part of the SRC program. However, the how and where is not specified and needs to be clarified by the specific SRC programs from the different payment schemes.
Our understanding of this question, based on the EMVCo. specification is as follows:
Tokenization
When a cardholder is registered for SRC, the SRC system creates a profile that contains information about the contact information, cards and devices related to the cardholder.
One of the information stored in the cardholder profile is ‘PAN Reference Information’ for each registered PAN (Primary Account Number). Once a PAN is registered in the SRC system, the SRC system creates and shares a Reference Number with related DCFs and merchants (DSA & SRC I) to be used for future communication with the SRC system. This is to ensure that the PAN is not stored by any party and instead the ‘Reference Number’ is used in communication between the systems. This is where the existing tokenization systems (e.g. MDES, VTS) can be used to create tokens or so-called PAN Reference Numbers. Based on this, we assume that the schemes’ SRC system is a part or very close to their existing tokenization systems.
3-D Secure
As you have seen in the customer experience flow, there will be parts where cardholder has to verify his identity to access his profile and/or authenticate to complete an SRC transaction. This is where we think the existing the 3-D Secure technology will play a role.
4) How is SRC different from W3C Web Payments?
If you have been following web payment developments, you must have heard about W3C Web Payments group. The purpose of the Web Payments Group is to make online payments simpler and more secure. As a part of this goal, they have defined a set of standards, among which are Payment Request API and Payment Handler API. Discussing the details of each of these standards are beyond the scope of this article. But for those you who are familiar with Payment Request API, one might say ‘wait a second!’. Payment Request API is also aimed to address the fragmentation of checkout solution and improve the user experience. So how is SRC different from the Payment Request API? Fair question! We have tried to describe the differences in the table below:
Now you might be probably asking yourself, aren’t these two standards somehow complementary? And the answer is ‘yes’! Indeed, the SRC and Web Payment Standards can work well together. However, it’s very much up to the payment schemes how they are going to use the Payment Request API or other standards from W3C Web Payments when defining their requirements and implementation mandates for SRC. You can read a more detailed analysis on this topic here.
7) In the end, will it be ‘ONE’ checkout button?
The EMVCo. specification does not mandate any specific implementation about the checkout button, neither any mandates regarding the cardholder identifier. Therefore, it is up to the SRC systems and SRC Programs (aka, payment schemes) to decide if there will be a common button or if each SRC Program will have their own specific checkout button. If we think of solving the fragmentation and enhancing the customer experience, we would assume that ‘One Checkout’ button would be a better choice for customer experience, but we are not the one who decide ;-)
Final Words
Whether or not the SRC framework can solve the fragmentation issue or not, depends on how the program will be specified by the schemes and who could participate as the DCF in this ecosystem. Nevertheless, we are hopeful that SRC program paves the path for ‘token on file’ so that merchants can manage payment data in a more secure and streamlined way.
An important question to be answered is, if and how the SRC programs will include the Payment Request API in their implementations. So far, public information from W3C Web Payments group shows that only little analysis has been done on whether and how the SRC framework and Web Payment standards can work together. We hope that in the next step of refining the SRC specification and defining schemes’ specific implementation mandates, EMVCo., payment schemes and W3C get together to create complementary solutions that at the end improve the customer experience.
References:
Related articles:
Explore the risks and consequences of breaking card scheme compliance rules
Discover strategies to win over your cardholders, especially during fraud and dispute chargebacks
What issuers need to know about Visa's latest Compelling Evidence 3.0
See firsthand how our SaaS products have fueled success for our clients
Rivero in the news: our latest press releases