Secure Remote Commerce (SRC) officially launched in the US last week,
supported by a limited set of merchants, with more to launch by year-end and into early 2020. We’ve been tracking SRC for some time now as it moved through the specification development process within EMVCo. It has emerged at launch as a customer-facing brand called “Click-to-Pay,” unless you’re using an Amex card, where it’s also called “Online Checkout” in confirmation emails received after registering a card.
So now we know SRC has launched as Click-to-Pay, but what is it? As the card brands have positioned it, Click-to-Pay is intended to solve the challenges that come with guest checkout (i.e. the first time a customer shops with a merchant, or when a customer prefers not to let the merchant store their payment details). SRC itself is a specification that acts behind the scenes to provide a secure and interoperable card acceptance environment
and covers both web-based and native app-based transactions. EMVCo has suggested that by having a simpler integration for merchants to access a consolidated brand wallet through a single buy button, it can enable a smoother process for consumers to access their payment cards and shipping details without having to manually fill out payment details for these types of transactions. This is not the first attempt by the brands to solve this problem (e.g. Visa Checkout, Masterpass, and Amex Express Checkout), but previous attempts struggled with adoption by both consumers and merchants. This new iteration under SRC has all the brands working together under EMVCo to coordinate efforts, so if implemented correctly, and if it does simplify the process for merchants and consumers, the momentum of this joint effort might help enable broad adoption.
Naturally, as all intrepid payment consultants are inclined to do, we went out and tested SRC with the launch merchants to see how it’s working and what we could learn for our clients. We bought some chocolate, movie tickets and also donated to the Movember charity. Based on these payments we found a few peculiarities to note so far:
• The checkout experience across the three launch merchants varies quite a bit, which can be expected for different types of goods or services (i.e. donations vs. goods that need to ship). However, even the experience after returning to the merchant checkout from the SRC checkout varied. Sometimes there was a “Payment Review” screen before confirming payment, and others the payment was submitted immediately after clicking a button to “Confirm” payment on the SRC screens.
• The flows for desktop web and mobile web varied slightly as well when returning to the merchant checkout. Interestingly, there were more steps to complete on a mobile browser after returning from the SRC checkout.
• On subsequent payment attempts after initial registration, more cards appeared without needing to register each one. It’s not entirely clear how these were loaded or where they came from, though we believe it could be due to past use of Visa Checkout, or registration of cards within Apple Pay using the same email address. Even though these cards appeared, they still needed to be authenticated (with a card security code or a one-time passcode) before use.
• While a registered SRC profile contains the customer’s shipping address, the merchant checkout flow forced manual entry of shipping information since payment method selection comes after entering shipping details. As solutions mature, this flow may shift to bring Click-to-Pay earlier in the flow.
• There is a trusted device process, but it doesn’t appear to be recognized by subsequent attempts as even after using Click-to-Pay as a “Returning User”, we were forced to enter a one-time passcode sent via email.
Some of these variations can be expected in early iterations of SRC, and some of them are by design. Jess Turner, executive vice president of digital payments and labs of North America at Mastercard told PYMNTS.com,
“…the way a merchant deploys SRC will depend on their chosen verticals, consumer bases, and how large or small the merchant may be.” This flexibility, in the long run, should actually provide merchants with more choice about how they implement SRC, and which features are most important to them. At this time, the only thing that SRC seems to save for a customer is entering their card details. As adoption expands, we expect to see the checkout experience optimized and simplified for everyone involved.
Speaking of merchants, what’s in it for them? If a consumer is going to enroll any payment cards into a wallet, historically, merchants have preferred this be in a merchant wallet under their control, rather than a scheme wallet. However with SRC there is no merchant card on file “honey pot” to be breached, so for many merchants this is an appealing security feature that reduces their risk of becoming the next credit card data breach in the news like Home Depot, Target, TJX, Marriott, British Airways, Macy’s, Lord & Taylor or Saks Fifth Avenue. For consumers who do not regularly shop with certain merchants, SRC could help reduce the checkout friction while also simultaneously securing the cardholder’s payment details.
There are a variety of ongoing developments attempting to make the experience of guest checkout more convenient and more secure for both consumers and merchants. These include different approaches like storing payment details in your device’s browser (W3C Payments Request API in Safari, Chrome, Firefox, etc.) or leveraging digital wallets like Apple Pay, Google Pay or Samsung Pay for in-app payments. While the technologies available today are still early to the market and need time to mature, they each are striving to enable universal acceptance, increased security, and a common checkout experience, but do we need all these solutions? Are we going to just confuse consumers? Which solutions will gain traction and survive? Which solution works best for different merchant types? The answer to these questions may well depend on the consumer experience a merchant wants to provide on their website.
At Consult Hyperion, we are continually working with our clients to make payments simple and secure. Based on what we can see so far, SRC should make paying online more secure for everyone while reducing integration and enrollment roadblocks for the merchant and consumer respectively, however the current implemenatations are somewhat clunky and need to be more streamlined to succeed. The real test will be the adoption rate and the brands’ responsiveness to feedback from participants in the ecosystem to ensure a beneficial approach for everyone involved. If you’d like to learn more please contact us for a copy of our latest digital commerce material at email@example.com.