How EMV® Secure Remote Commerce intends to streamline online payment experience

In 2018, EMVCo decided to tackle the lack of guest checkout interoperability and particularly the necessity for consumer to input systematically their payment details online. It was the birth of Secure Remote Commerce (SRC) Specification, later branded as “Click-to-pay”, aimed at improving the checkout experience by reducing the need to re-enter information when making purchases.

Click-to-pay objective is to offer consumers a consistent experience across different websites by storing their identity and payment details to reduce the hassle of time spent filling in forms.

This approach is similar to existing buy-buttons and digital wallets available in the payment industry, starting with Paypal, one of the first to historically propose a digital payment means relying on a user account, with a reassuring payment journey whatever the e-merchant.

This new payment framework has been successfully tested and deployed across USA and a few other countries worldwide (Canada, Australia, Hong Kong, Singapore, etc.).

Consumer Journey

A customer, who has already signed up for SRC, will be able to click on the recognizable SRC icon to access the service. Similar to a cloud-based wallet, the Click-to-pay system will then determine whether the user’s device is recognized, before returning their payment cards to choose from. After selecting their preferred payment card, the user’s details will be securely transferred to the merchant (shipping address, contact details and payment credentials).

Figure 1: Consumer flow (source EMV® Secure Remote Commerce (SRC) specification v1.1)

Figure 2: EMVCo Click to Pay icon

Technical requirements for merchants

In order to support Click to Pay, merchants need to have an integration with an SRC Initiator (SRCI) component, which supports the merchants in all SRC activities, starting from registration to SRC to getting the payment details required for authorization. SRCI uses two channels for communicating with the SRC System:

SRCI Frontend Plugin

This plugin runs in the context of the merchant’s e-commerce frontend (web shop) and consists of several aspects required to support Click to Pay.

The SRCI-UI is responsible for the user experience and provides a set of visual components which can be embedded on the hosting site. It enables the direct interaction with the consumer during the SRC processes, such as assurance, card retrieval and card selection.

The SRCI-Logic is responsible for handling the events originating from the SRCI-UI and feeding back the visuals with the appropriate data. It communicates with the SRC Common Software component in order to facilitate the SRC features such as device recognition, consumer authentication, card registration and card selection flows.

The SRCI-API is the integration point with the merchant frontend/app. It provides functionalities such as initialization of the SRCI-Frontend, creation of the UI components and configuration of the SRC properties. Merchant e-commerce frontend solutions can use the SRCI-API as single point of interaction with the SRCI-Frontend.

SRC Common Software knows how to talk with the APIs exposed by the SRC System Software. It combines the results gathered from the underlying components and passes them to the upper layers through the SRCI-Logic.

SCRI Server

• This is the backend part that handles the payment credentials for an SRC transaction previously initiated by the SRCI-Frontend.
• The SRCI-Server has a direct connection with the backend of the corresponding SRC Systems (managed by card schemes) and communicates with their secured API’s.
• The SRCI-Server notifies the SRC System about the transaction result.
• The SRCI-Server supports the merchants in registering the Digital Payment Applications (DPAs) to the SRC systems.
• The SRCI-Server is merchant agnostic and thus can be deployed by PSPs to serve multiple merchants.

Technical requirements for issuers

In order to support Click to Pay, issuers need to enable the so-called Push provisioning. This generic capability enables cardholders to “push” a token from the issuer experience into the corresponding SRC Systems. Issuers must be enrolled in the Schemes Tokenization Systems (e.g. MDES from Mastercard, VTS from VISA) to activate payment cards to receive token requests from the SRC Systems. In addition, issuers must perform strong cardholder authentication prior to initiating push provisioning and not request additional cardholder authentication during push provisioning itself.

Roles and responsibilities

For Click to Pay there the following three roles can described:

Digital shopping application:

• The Click to Pay SDK enables an easy and seamless integration of Click to Pay into any Digital Shopping Applications
• The Click to Pay Server is integrated with various payment scheme SRC systems
• The Click to Pay Server manages the payload between merchant checkout, SRC system and Payment Service Provider
• The Click to Pay Server provides a unified a seamless backend integration layer for PSPs and Payment Gateways

Scheme:

• The SRC System performs the tokenization of the PAN (card number) entered by the cardholder, stores the digital cards and other (meta) data, such as consumer profile data (address, phone number), registration and configuration data and orchestrates the interactions of the other SRC participants in the purchase process.
• The DCF component (Digital Card Facilitator) finds the corresponding card art, card descriptor, and address and then renders the UX of confirming the chosen digital card.

Bank / card issuer:

• Easy and seamless integration into Wallet Apps or via App SDK or Web SDK
• Support for pre-enrollment of new generated cards (issuer backend integration)
• States the type of authentication method to be used for the assurance requirements
• Enables Click to Pay to find the card art,
  card meta data and cardholder’s data

Integrated with various payment scheme SRC systems

Banks & Click to Pay?

Banks, willing to enable Click-to-pay to their cardholders will need to interface to their card schemes Token Service Platform (the same way as in Apple Pay service for example, requiring the digitization and tokenization of a payment card). The issuer has the ability to initiate the digital card enrolment (stored in the Click-to-pay wallet), proposing a “push provisioning” journey from the banking mobile application.

SRC will expectedly provide more security and convenience to cardholders, and avoiding abandonment. Click-to-pay is compatible with EMV® 3-D Secure, bringing additional security to the online payment process.

As of now, co-badging has not been taken into account yet in the SRC specification, which could raise questions from banks that are issuing co-badge cards.

Benefits for merchants?

Proposing Click-to-pay for a merchant will probably be a tradeoff between the benefit of leveraging a user profile already enrolled in click-to-pay system and the potential threat of losing consumer’s data (shipping address, contact details). The Click-to-pay icon integration by an e-commerce website in its already overloaded payment checkout page will presumably be a matter of concern, as e-retailers are always looking for the smoothest experience and SRC hasn’t proved to be entirely frictionless, in spite of what card schemes claim.

SRC, in spite of strong push marketing from stakeholders, will only be a commercial success if consumers find it relevant, the same way as contactless gained significant traction during the pandemic. In the battle of payment method, SRC has already some identified enemies: payment initiation, instant payment outside of traditional card rails.