Isn’t is delightful when your browser autofills a dauntingly long web form? Imagine if it could do that for payments. Well, it soon might. The W3C is working on what it calls a single ‘buy button for the web’. MEF Minute Features Editor Tim Green delved deeper…
Do you trust your browser?
I’d wager you do. You probably store various passwords and log-ins inside it. You certainly fill it with bookmarks that reveal your most personal interests.
So what about your payment credentials? Why not stick them in there too?
Imagine what difference this would make to your payment experience on the web.
Here’s the deal at the moment. You want to buy something, so the merchant asks you to fill out a series of long card and shipping details. This is very boring. And it also raises this question: do you trust this retailer to look after your data?And this leads to the following payment experience equation: boring x distrustful = cart abandonment.
Now, imagine you can store your payment details inside your mobile browser. You arrive at a new and unfamiliar merchant site. You click a ‘buy now’ button. The site pings your browser and instantly knows what payment options you have.
It then displays only those. If you’re not an Visa customer, you won’t see Visa. So you select the one you want. The system then auto-fills all the data fields. You are done in one click.
You’ll have probably guessed by now that this is not hypothesis. The World Wide Web Consortium (W3C) is trying to make it happen.
In October 2014, it launched the Web Payments Interest Group to create a universal checkout for the web. Its members include all the major browser firms plus Apple, Microsoft, Facebook, Mastercard, American Express, Alibaba, Tencent and more.
Two and a half years later, they’re clearly still working on it.
Google is testing it inside its Chrome browser. And sites like Washington Post have trialled it.
Ian Jacobs, head of payments at W3C (pictured), is confident that the process will succeed. Not just because of how much easier it makes life for users. But also because of the big difference it could make to merchants.
He says: “There’s less code to write. The merchant doesn’t have to implement a large number of payment products. It just adds the APIs for what’s stored in the native browser interface.
“So the system only displays what the merchant accepts and what the user has. This also means the merchants don’t store any data – and that reduces their PCI compliance.”
But what about security? Well, self-evidently the system returns control of data back to the user, which is a great start.
Clearly, this is in line with the growing interest in the ‘personal data economy’ ethos, which the MEF has done so much to elucidate (download the white paper here).
W3C is also working on a process for tokenising the payment credentials inside the browser, so that when payment data flows it cannot be intercepted by a ‘man in the middle’ attack. It is also looking into biometric two factor authentication.
Ultimately, what’s most compelling about the W3C’s project is that it is not a wallet. It’s one process for all the wallets. So with minimal effort a merchant can accept any or all of Mastercard, Amex, PayPal, Google Pay, Apple Pay, Samsung Pay, Dwolla, ACH/bank transfer, Visa and so on.
Of course, the issue is clouded by the whole apps v browser debate. But with web apps becoming more sophisticated (Google has developed web pages that look and feel like native apps), there is surely scope for browser-based payments to flourish on mobile.
Great article! Fantastic idea! 🙂
Do you expect the merchant when using w3c’s web payments to enter into contracts with all those payment options? I think there is still a need for a payment service provider in between that is handeling the contracts for the payment options and taking care of the cashflows.