For several years, the Web Payments Working Group has discussed a range of ideas for layering security improvements on the user experience of Payment Request API. These have included:
- Encrypt response data to help reduce PCI DSS assessment burden.
- Digitally sign request data to reduce the risk of tampering.
- Tokenize payment credentials to make them less susceptible to unauthorized use (and reduce the use of “basic card” payments).
- Reduce some forms of fraud by strengthening authentication on the Web. Our colleagues in the Web Authentication Working Group are leading the charge to do better than passwords.
As we have made progress in the Working Group, more people have begun to ask me “How do these proposals relate to EMV® 3D Secure (3DS) 2.x?” Until recently I answered that I do not know. But this month the Web Payments Working Group launched the 3DS task force and my answer has changed to “It seems there are some opportunities here and we’re working on it!”
The EMVCo FAQ summarizes 3DS this way:
“EMV® Three-Domain Secure (3DS) is a messaging protocol developed by EMVCo to enable consumers to authenticate themselves with their card issuer when making card-not-present (CNP) e-commerce purchases.”
My rudimentary understanding is that 3DS is an authentication framework. If that’s accurate, then I would reformulate the above question as: How can emerging Web standards (for payment and authentication) be used to fulfill the flows and requirements of the 3DS framework?” The task force aims to answer that question.
Why do some in the Working Group think this is useful activity? Here are some perceived benefits:
- Merchants should benefit from reduced fraud, higher transaction approval rates, and lower software development costs. In addition, in some parts of the world (e.g., India), it may be mandated that merchants adopt 3DS flows for card payments. We also think that card issuers and card networks will appreciate the fraud reduction and approval rate benefits.
- Users should benefit from reduced fraud and improved user experience. The 3DS flow involves communication with a server (the “Access Control Server”) to determine whether strong (multi-factor) authentication is required for a given transaction. I am told that this authentication “step-up” should only be required in about 5% of transactions. Of course, “not being asked to authenticate” nearly all the time is a good user experience. In the 5% of cases where step-up is required, the thought is that doing that authentication in the same context as
the selection of payment credentials would offer a superior user experience compared to completing one part of a transaction and then being prompted a second time, with a potentially different user interface. Incidentally, this idea of authenticating in the payment handler (before Payment Request completes) has also come up in our discussions of PSD2 authentication requirements in Europe.
There is further hope that moving 3DS server interactions to the user side (via the browser or third party payment handler) could help scale 3DS adoption. It has been observed that there are many more merchants than browser or payment handler providers, so that fewer parties would need to manage the 3DS server interactions, facilitating deployment.
The task force has only met twice, but I’m already encouraged by the initial attendance by American Express, Capital One, Discover, Google, Lyra Networks, Mastercard, Merchant Advisory Group, Mozilla, NACS, Shopfiy, Stripe, Visa, and Worldline. Colleagues from EMVCo are participating in the calls, which is fantastic.
I expect to have a much crisper picture of how 3DS and Payment Request relate by the time of the Working Group’s next face-to-face meeting (likely in April 2018). As I said, we’re working on it!
