W3C’s Web Payments Interest Group is gaining momentum in its pursuit of the integration of payments into the Open Web Platform. As part of building understanding security, and the role of the Web, I am organizing a series of interviews on Web payments. In this first interview with Tom Poole and Drew Jacobs of Capital One, and Siva Narendra of Tyfone, we open with the broad question of what the Web needs to facilitate eCommerce.
Ian Jacobs (IJ): Let’s jump right in. The Web is 25 and people have been engaging in commerce from the start. But smart phones, cryptocurrencies, and stories of stolen passwords and other sensitive information have created a lot of new activity around payments. What does the Web need so that we achieve the full potential of ecommerce?
Drew Jacobs (DJ): The Web is clearly one of the most prominent channels for payments today. But there are gaps and pain points across the value chain, from the consumer to the merchant to the financial institution. The reality today is that the process for online purchases today can be convoluted, often requiring a lengthy checkout process where you provide a lot of information without a lot of security. Over the years solutions have emerged such as Amazon¹s One Click to reduce friction at checkout. Other capabilities in market today attempt to solve the challenge of convenience and security, but no clear winners have emerged. We see a lot of opportunities in the payments ecosystem for improving the lives of customers, and giving them new tools for payments.
DJ: For example, online credit card transactions today leverage static data and are therefore vulnerable. We are seeing a move toward tokenization.
Editor’s note on tokenization: In eCommerce today, consumers typically provide sensitive information such as credit card numbers directly to merchants. Many in industry see tokenization as a promising secure alternative. As an example of tokenization: when I want to pay for something with a credit card issued by my bank, the bank can send me an electronic token that I give to the merchant. To the merchant the token is a meaningless sequence of numbers, but it can be “redeemed” at my bank as part of settling payment. This indirection through a secure token benefits the consumer, who keeps control of sensitive information, and also merchants, whose liability is reduced in the case of attacks on their IT system.
DJ: But tokenization should not be a separate process from other forms of payments, we need a cohesive solution across channels. I want to add that there are also many new opportunities to provide customers with richer experiences by leveraging data available to merchants or to banks.
Siva Narendra (SN): I agree with Drew that we need to improve security. Today, ecommerce is a relatively small proportion of the world’s overall commerce; I believe around 7%. But there is a fraud rate of about .9% for ecommerce while it is .09% for other forms of transactions. So the fraud rate for ecommerce is 10 times what it is for non-ecommerce. There are a number of reasons for this, including the fact that passwords are not very effective. Tokenization, as Drew mentioned, is an important path for the future. But securely authenticating the right user is being provisioned the right token is necessary, otherwise criminals can steal tokens, too. When you have a secure element on your phone that can be used for authentication, for example, your fraud footprint decreases significantly. Tools provided by the Fido Alliance are useful, but they do not yet take into account tokenization standards already in use. I also agree with Drew that leveraging data can be powerful, but I think consumer privacy protection is going to be a big issue, and there may be pushback if users start to receive a lot of annoying alerts.
DJ: Our data can enrich the experience or make it more efficient, but I agree with Siva about the importance of privacy.
IJ: It sounds like security should be our first focus.
DJ: Yes, we need to secure both authentication of the user and then the transaction itself. But we also need to simplify payments. Today there are many disjointed ways to pay: PayPal, Credit Cards, wallets from Apple, Google, etc. There’s already a proliferation of checkout bugs for payment instruments on Web sites. Introducing more is not the answer.
Tom Poole (TP): The more checkout bugs, the less likely any particular one will be noticed. There are three different levels where payments could be improved. The first involves adding support for secure storage of information, such as via a browser plug-in. An open standard would enable multiple providers of such plugins (and of course, browsers might provide their own solutions). The next level up is the “white label container” like Softcard that could provide consistency for payment scheme providers, but still allow for innovation. The third layer would be to build on something like Apple Pay, but that would mean very little differentiation and a single vendor would drive the normalization of payments. But I don’t think many people want to invest in that sort of centralized solution. Rather, I think they will want to differentiate by building better or smoother experiences. W3C should focus on core service and leave a lot of room and levers for innovation.
IJ: Ok, so within the first two levels, where should W3C focus?
TP: Identify what is the narrowest service that must be delivered. One will involve delivery of payments credentials. As Drew and Siva have mentioned, tokenization will play an important role, and the browser (or plugin) would securely store credentials. Over time, we could see direct fill of information in the background, which could further increase security by reducing attacks like keylogging. Ultimately it would be create to standardize the interactions with merchant checkouts, so that sites have a common, secure approach that works across browsers, speeding up transactions, and enabling financial institutions opportunities to add value.
IJ: What are the most important bits of infrastructure that you think we should be leveraging for the Web? What should we be connecting to?
SN and DJ simultaneously: Tokenization!
SN: There is no better security than hardware in someone’s hands. Browsers should allow integration of the security modules available through these portable devices. These security models might be running in the cloud, as software on a device, or in a secure element in hardware. For example, browsers might provide access to secure element via a password (and the risk and reward will be different according to application).
DJ: I agree we should be connecting to existing infrastructure, especially around tokenization, and that there should not be a single solution for all applications. Different needs will drive different solutions.
SN: In my view, anything other than tokenization to secure the transaction is probably not going to be acceptable to the financial industry. We also want to see convergence between ecommerce and in-store purchases.
IJ: What will that require?
SN: Building on top of existing tokenization standards will also facilitate convergence. There are questions about liability between physical and ecommerce transactions, but there are well-understood rules of engagement between banks.
DJ: The key point for us is that W3C has a unique opportunity to provide underlying infrastructure standards that leverage existing work around tokenization. That is the biggest pain point for us today: tokenization doesn’t exist easily online, and we need greater security online. We think browsers can play a role in bringing this together. We also see opportunities around improved authentication and identification of the real user.
IJ: What will be the biggest benefits to banks if we can do this?
IJ: Thank you all for your time!