Discover everything you need to know about SRC, or click-to-pay.

Secure remote commerce: What it means to merchants

Discover everything you need to know about SRC, or click-to-pay.

What is secure remote commerce?

Secure remote commerce (SRC), commonly referred to as ‘Click to Pay,’ is an open system where participants in the payments ecosystem facilitate a streamlined checkout process that reduces the need to enter personal and card information on multiple e-commerce sites and works across multiple devices and channels. To do this, the SRC specification defines a number of roles and functions to facilitate this secure and seamless experience by which consumers access their card and personal information.

You may have noticed the different websites you visit support a variety of different checkout experiences. Some use PayPal, Visa Checkout or Masterpass, but others use their own custom experiences. Often, this means you must re-enter many of the same details on many different websites.

One of the most frustrating issues for consumers when shopping online is the number of fields they must fill out to complete a purchase. In some cases, this can be as many as 58 unique fields. This includes entry of personal information, payment card details and billing and shipping addresses. It’s one of the biggest contributors to cart abandonment. The two top reasons for cart abandonment are 1) the site wanted the customer to create an account and 2) a checkout process that was too long or complicated. These two reasons alone contribute over 40% of overall cart abandonment.

To address this, EMVCo, an organization that works to promote standard payments infrastructure, has published the Secure Remote Commerce Specifications aimed at improving the checkout experience, which has been adopted by the global payment brands. The goal is to introduce a consistent user experience for consumers and remove the need to re-enter information on websites that support SRC thereby speeding up checkout time and reducing abandonment. This is especially beneficial in the guest checkout experience where a customer doesn’t want to create an account.

The SRC specifications enable the creation of what’s called virtual payment terminal. The idea is to create a similar experience to a physical terminal where the process is the same regardless of card used, but in the online commerce world. Per EMVCo, SRC provides “a foundation that will enable industry solutions for the processing of e-commerce transactions in a consistent, streamlined fashion across a variety of remote-checkout environments and consumer devices including smartphones, tablets, PCs and other connected devices1.”

How does secure remote commerce work?

To understand how this works, we will walk through a couple of typical online checkout journeys using secure remote commerce. In the first journey, the customer will be using SRC for the first time. As mentioned earlier, SRC can be especially beneficial in the guest checkout experience, so we will focus on that process. The journey begins as the customer finishes adding items to their cart and is now ready to checkout (figure 1).

pictures of cellphones with steps 1-3

In this example flow, the payment options are presented on the cart page of the merchant’s site2. While other payment options may also be present, we will only show the SRC option for simplicity.

Since this is the first time this customer will be using SRC, it’s likely the SRC icon itself will not be meaningful to the customer. The use of card brand logos in conjunction with the SRC icon may draw the user’s attention and provide confidence in clicking on the button, but additional messaging may be required to encourage consumer adoption of SRC.

Once the button is clicked, the customer is brought to the New User/Returning User page (figure 2). As a new user, the customer will enter their card details and click Continue.

The card details provided in this step are used to identify the SRC system to which the card is associated. The SRC system is the entity, typically the card brand, that orchestrates the overall SRC process and facilitates the secure storage of card data and access to the use of that card data. Once the SRC system is identified, the user is presented a page to enter the remainder of their billing and shipping information (figure 3).

Up to this point, the journey has been very typical of a guest checkout experience. However, after the customer enters their information, they are presented with fields to enter a personal ID (bottom of figure 3).

The SRC system will use this ID to associate, or bind, the user to the card and personal information previously entered. This may present a challenge for SRC adoption. Since the customer had intentionally chosen guest checkout, creating a personal ID may lead them to believe they are creating an account on the merchant’s site. This may lead them to return to the cart page and choose another payment option or abandon the cart all together, which ironically is something SRC is supposed to reduce.

Again, clear messaging will be needed so that consumers understand that their card credentials and personal information are being stored by a system backed by the card brand and not the merchant.

Assuming the customer is comfortable creating a personal ID, they will enter their email address (or other identifier defined by the SRC system) and continue to the next screen. Here, the user will confirm their information and be presented with an option to be “remembered” on the device they are using (figure 4). If the customer chooses to be remembered, device information will be bound to the user’s profile. This allows the SRC system to use device recognition for future checkouts and streamline the process as we will see shortly in the returning user journey.

pictures of cellphones with steps 4-6

The customer will then continue to the order review page (figure 5) and, if everything is correct, on to the confirmation page (figure 6). So, again, except for creating the personal ID, the first-time user journey is very similar to a typical guest checkout experience. It should be noted that it may be possible for users to enroll into SRC in other ways (such as through the card issuer’s website) that would eliminate the first-time user experience on a merchant’s website for that customer.

The Returning User Journey

In this journey, a user that previously enrolled in secure remote commerce and chose to have their device remembered will checkout as a guest on a merchant website they have not visited before. As with the first-time user experience, the returning user journey begins after the customer has added items to their cart and is ready to checkout (figure 7).

pictures of cellphones with steps 7-10

When the customer clicks the SRC button on the merchant’s cart page, information about the device will be sent to each of the SRC systems to determine if any recognize the customer’s device. If the device is recognized (bound to the customer’s SRC profile), the SRC systems will return the related card reference data (figure 8). The user then selects the card they want to use for the transaction and clicks to continue. The order review page will then display the relevant personal information the customer previously saved to the SRC system (figure 9). The user can then confirm to complete the order (figure 10).

Note that even though the user is performing a guest checkout, they did not have to enter any of their card or personal information into the merchant’s website. Additionally, because the SRC system recognized the device, the customer did not have to provide their personal ID from when they enrolled in SRC.

If the user had not chosen to have their device remembered, they would have been directed to the New User/Returning User screen (figure 2) where they would have selected the Returning User tab and then been prompted to enter their personal ID. The SRC System would then send them a one-time passcode to the email used for their personal ID. A screen to enter the passcode would be displayed and the customer would enter the passcode. Once the passcode was verified, the user’s list of cards (figure 8) would be displayed, and they would continue the journey from there. A significant benefit with this process is the customer does not create a static password for their personal ID that they then have to remember and manage.

Merchant considerations for secure remote commerce

As each of the major card brands is in the process of standing up their own SRC system, merchants will need to connect to multiple SRC systems to provide their customers with access to all of the cards they have chosen to enroll into SRC. Working with an SRC initiator that has already created the integrations to the various SRC systems can reduce the burden for merchants to participate in SRC. SRC initiators are participants in the SRC ecosystem that provide code to merchants to enable SRC on their websites and manage the application programming interfaces (APIs) to the SRC systems.

For merchants who support guest checkout, SRC can provide a secure, streamlined method for customers to access their card information, eliminate redundant entry of shipping and billing information and potentially keep PCI data out of their systems. While merchants who have tokenized card-on-file online shopping environments can potentially utilize SRC, the benefits may be less.

Merchants who support alternate payment methods will need to weigh how implementing SRC might impact the ease of use of those other methods, their customers’ perceptions of those impacts and determine if that potential disruption outweighs the benefits of SRC.

Getting started with secure remote commerce

Merchants interested in SRC should contact their acquirer or processor to understand what their plans are for supporting SRC. If a merchant is currently supporting an existing card brand digital wallet like Visa Checkout or Mastercard Masterpass, the card brands are in the process of converting those legacy solutions to SRC. Merchants should use their normal channels to contact the brands and understand how that process will impact them.