W3C Payments API and Consumer Authentication

Written by: Srinath Sitaraman

July 6, 2017 - A more consumer-friendly checkout experience

The statistics on e-commerce cart abandonment are staggering – about $4.6 Trillion in merchandise is left abandoned in the cart every year and 7 out of 10 web shoppers abandon their shopping carts never to return. Industry analysts estimate that 63% of people that abandon their electronic cart can be converted to buyers with the right tools. A primary driver for the high e-commerce abandon rate is fatigue caused by the cumbersome checkout process, lack of adequate payment options, long page-loading times etc. The Worldwide Web Consortium (W3C), the group that brought us some great web standards, has come together again to help address this situation by standardizing payments on the web (especially the mobile web), effectively by introducing an interoperability layer – the web browser itself.

By abstracting the payments functionality to the browser with the W3C Payments API, the merchant can provide a more consumer-friendly checkout experience and offer an increased variety of payment options. All this without having to go through a painful integration process with a payment provider.

 


In this article, I wanted to focus on one aspect of the W3C API – which the W3C consortium has chosen to exclude; and that is, the authentication of the consumer during checkout.

Historically, enabling secure forms of cardholder authentication for web transactions has proven to be a challenge. 3DS 2.0 offers considerable promise in helping issuers authenticate cardholders in a card-not-present (CNP) environment, significantly improving from its ‘baby-boomer parent’ 3DS 1.0. Built with the mobile platform in mind, the specification enables the use of new and enhanced authentication capabilities and the ability for the Issuer to exercise finer control over the use of 3DS. While the W3C payment API standards do not address 3DS (or security / authentication for that matter), it must be noted that the W3C Payment Request API is not mutually exclusive with 3D Secure. For instance, once the web browser has passed the payment credentials to the merchant checkout page, the Merchant and the Issuer can still do the 3DS ‘dance’, if they both support it. The browser does not interfere with this process whatsoever.

With the introduction of the W3C Payment Handler API (which is still in draft form at the time of this writing), the browser can further delegate the payments credential storage to a mobile payment app. This is a great opportunity for mobile payment apps to find their way into web payments, and opens a number of possibilities for the Issuer to authenticate the cardholder. Many banks already use the mobile phone functionality; eg. Fingerprint reader and camera along with protocols like FIDO, to authenticate their customers accessing their mobile bank app. It is but a logical extension that with a W3C API enabled mobile payment app developed (or trusted) by the Issuer, the Issuer can authenticate the cardholder – even before the payment credentials are passed to the merchant checkout page. An Issuer or an Issuer “trusted” 3rd party provider (TPP - e.g. Apple Pay, Android Pay) can seamlessly authenticate the consumer with minimal enrollment or interoperability concerns.

The concept is further explained below within the context of using a credit/debit card for payment during checkout, but can be extended to other forms of payment too.


For the sake of simplicity, it is assumed that the merchant checkout page supports the W3C Payment Request API as well as indicates support for the Issuer or 3rd Party provider (TPP) mobile payment app, and the consumer has registered their mobile payment app with the browser.

  1. The Merchant checkout page invokes the Payment Request API on the Web Browser and consumer selects the Issuer mobile payments app for the transaction
  2. The web browser invokes the Issuer mobile payment app requesting payment credentials
  3. The consumer authenticates him/her-self to the Issuer mobile payment app (through fingerprint, selfie, passcode, OTP etc…)
  4. The Issuer (or TPP) mobile payment app informs the Issuer Access Control Server (ACS)that the consumer is authenticated and retrieves a token
  5. The Issuer mobile payment app passes the payment credentials (including the token) to the merchant checkout page via the web browser
  6. The Authorization request flows from the Merchant to the Issuer, via the traditional rails
  7. The Issuer Authorization Host queries the Issuer’s ACS to confirm token authentication
  8. The Authorization response flows back to the merchant (via the traditional rails)

The benefit of W3C Payments API is that this process works even with merchants that do not support 3DS, and helps to improve and increase authentication for web checkout. Also, since the consumer is pre-authenticated during a transaction, he/she does not have to go through a separate 3DS enrollment process. Finally, this implementation will have the same effect as a full 3DS authentication flow, albeit with much fewer network hops – and thus potentially a faster response time for the consumer. This infographic provides a nice overview of why every 1-second delay in response/page-load time can affect the top-and-bottom line for the merchants.

The W3C Payments API promises to lay the foundations for a payments revolution on the web and as a result, savvy Issuers will have a significant role in the electronic checkout process and the ability to authenticate their cardholders with existing technology and assets. In the end this should mean more complete transactions, a better customer experience and improved earnings for both issuers and merchants.

Disclaimer

These are the personal opinions of UL’s employees and its guests and should not be misunderstood as representing the opinion of UL's clients, suppliers or other relations.