Gain exclusive insights into the evolving world of payments that are reshaping the banking sector and enhancing customer experiences.

Thought Leadership

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:

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!

The picture below shows a high-level overview of SRC participants based on the EMVCo. specification:



Rivero Blog - EMVCo SRC Participants - who does what.webp


EVMCo. defines the followings 6 roles in the SRC ecosystem:

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?

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:

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:

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:

Customer journey issuer SRC.webp



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:

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.

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:

payment request and src rivero.jpg

Payment Request API vs. Secure Remote Commerce

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 ;-)

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.

A few months have passed since the EMVCo.

Dispute management is essential

7 Things Every Issuer And Bank Should Know About The Secure Remote Commerce (SRC)

Simplifying payment operations for banks — scheme compliance, dispute management, fraud recovery and industry trends.