Written by In the world of online payments (card not present), two issues that seem to be unavoidable are:
• Continuous rise of card-not-present fraud. Fraud rates for card not present are running at between four and ten times greater than card present depending on merchant sector
• High cart or basket abandonment rates. Average e-commerce abandonment rate is of the order of 65%, with 24% of customers at merchants using 3DS 1.0 abandoning the transaction after starting the checkout process.
As my colleague Andrew Whitcombe laid out in an earlier post, the quest for secure online payments (or at least as secure as their face-to-face cousins) is nothing new. We have seen initiatives such as the CVV2 and the Address Verification Service (AVS) implemented with mixed results. Other mechanisms such as 3D Secure (3DS) provide an added a layer of security, however they introduce added complexities to the checkout process which can lead to increased cart abandonment.
The good news is that regulatory authorities and relevant stakeholders are beginning to act. Various efforts within the payments industry such as tokenisation, 3DS 2.0 and Strong Customer Authentication (SCA) are directly or indirectly geared towards addressing the issues with card not present transactions.
Two initiatives of particular interest to us are the efforts of EMVCo and the World Wide Web Consortium (W3C); the Secure Remote Commerce (SRC) and the Payment Request API (PR API) respectively. They both aim to facilitate secure and interoperable online payments by providing an easier and more streamlined checkout experience. This will also go a long way in simplifying the integration processes between the players the payment ecosystem.
W3C is working on a set of specifications that define the interactions between different entities through an API – the Payment Request API (PR API). The PR API specification describes how an intermediary (typically a browser) facilitates payment between a merchant and a customer through one or more payment methods, that is managed by a Payment Handler within the customer’s device.
Similarly, EMVCo has published the Secure Remote Commerce Specification (SRC). According to EMVCo:
EMV SRC offers an approach to promote security and interoperability within the card payment experience in a remote payment environment.
At its core, SRC facilitates the checkout process using information made available via an SRC system. It allows a merchant to obtain customer payment information in a secure and consistent way, which can thereafter be used to authorise payments.
So wait! Aren’t W3C’s PR API and EMVCo’s SRC exactly the same thing? Well, they certainly share fundamental similarities, especially in their goals. However, they also have their differences as outlined below.
| EMVCo SRC | W3C Payment Request API |
| The customer’s payment information is stored within the SRC ecosystem i.e. typically off the customer’s payment device. | Payment Information is typically stored within the browser or payment handler on the customer’s device i.e. Device focused. |
| Very much “card” focused. | Can support a variety of payment methods, e.g. Basic Card, Tokenised Card, PISP Credit Transfer. |
At the moment it is early days for both initiatives; it is yet to become clear which will have the biggest impact on the digital commerce landscape. However, one interesting possibility is the idea that they could in fact work together. As ironic as it sounds, their collective strength may actually be in their subtle differences; W3C’s PR API being payment method-agnostic, puts it in a good position to support SRC as a relevant payment method within the W3C PR framework. Likewise, with SRC the “wallet” can be anywhere including a browser providing valuable additional flexibility. Hence, in spite of their similarities with regards to the problems they seek to address, it is their differences that presents an opportunity for the two approaches to work together towards achieving a common objective.
But we are not out of the woods yet! Some questions remain open; will SRC actually succeed, where wallets have failed before? What if you just use W3C’s PR API & 3DS 2.0? What happens when there are multiple wallets on the consumer’s device? Will larger merchants be willing to hand over any part of the consumer experience? So far, we only have the EMVCo framework, the full understanding will only come when the schemes publish their individual interpretations of the specification. In the meantime, we at Consult Hyperion are increasingly engaged in discussions with our clients who are trying to answer some of these questions, explore potential new revenue streams and understand the associated risk profiles.
In the next blog post, we’ll take a look at other payment initiatives such as tokenisation, 3DS and open banking APIs to try to understand if and how they all fit together. In the meantime, if you want to find out more and you’re attending The Payments Summit in Phoenix next week then please let us know, we’d love to meet you there.
