If you follow online payments or have an interest in e-commerce (or even if you don't), it's about to get really interesting: the web just got an open, standards-based payments API, after three years of work to ensure it's a fair solution, to fix the mess that is online payments.
Bear with me, we're going to jump into the deep end and look at a bunch of work that's coming together in a big way, but can be confusing from the outside.
Called the Payment Handler API, the new standard allows the website to securely hand off a payment to a digital wallet, which can be completed natively by the web browser. Combined with the also new Payment Request API released a few months earlier, this is a huge step forward: we can now make digital payments in a predictable interface, securely, and trust that it's properly implemented thanks to the requirements in the standard.
Google, among others, is already planning big things for this API. Last year it rebranded Android Pay to Google Pay in anticipation of an eventual cross-platform payments product, and it now (optionally) synchronizes cards added to the mobile wallet across Chrome seamlessly.
To get a feeling for why the Payments Handler API is such a big deal we can already experiment with it. Stripe has a new intelligent button as a part of its Elements product that detects payment API support and triggers the correct service, be it Apple Pay or Google Pay, seamlessly.
If you're in a supported version Chrome (68 and above, available in the developer channel) and you click the payment button, you'll see a new interface like the below.
There are so many things to this dialog that get me excited about the future of the online commerce here.
First, I'm able to pay in just a few seconds without typing in my card yet again, because the API is able to handle all of the banal details of card, address and so on. Second, this dialogue is presented by the browser and means that regardless of the website I'm on, so I can be sure that it's implementing a level of security high enough to even trigger it.
Third, the dialog also works natively on mobile devices, across mobile platforms, and can be implemented by any browser:
What's fascinating beyond this, however, is that the payments API isn't limited to only support credit cards: it's able to be extended to support cryptocurrencies, bank transfers and any obscure local payment methods that countries may have.
Those writing the API were rightly concerned that the biggest issue with such a project is actually getting people to use it, because one of the core issues with the standards-based web is it often feels something like this:
I don't think this is the end result here at all, and the team's post about how the standard was developed is evidence of that, along with how many platform providers are poised to provide support for payments:
Creating a new global payment method seems all but impossible. First, there is acceptance. Visa is accepted by tens of millions of merchants worldwide. Any new payment instrument would have to first convince a significant number of merchants to support it. And that’s the easy part. What’s much more difficult is to change consumer habits such that people actually use this new option.
By supporting a wide array of networks for payment, there's an opportunity here to disrupt the traditional credit card networks and provide methods of payment most convenient for the end user, while making the experience of paying for things more secure and consistent.
It also presents a big opportunity for Google to make an end run around Apple Pay. Chrome is used on more than 60 percent of active web browsers, so with the launch of native web payments via this API it's able to reach a few billion users on day one. Apple Pay, however, requires the user is paying with Safari and an iOS or MacOS device.
Google quite literally has an opportunity to run circles around the credit card networks (Visa, Mastercard), Apple, and others, and win big in the payments space where nobody has stood a chance over the last decade.
Instead of needing to convince people to use Google Pay on mobile, it'll have a billion cards on file, synchronized across devices for even in-person payments at retail. All it has to do is educate the user that they're now magically able to pay with their phone, too. I assume the next logical step is a Google-branded card, too.
We'll see how that plays out in a few months, but these payment buttons are already close to appearing across the web. Shopify, for example, has already said it plans to "kill the checkout" with the API and will implement it soon. Others will follow, and I suspect we'll see this as a dominant payment choice within a year or so.
To me, what's most astounding about all of this work that's flying under the radar is that we only just figured out a consistent way to do payments, but it's more than welcome.
The only curveball here that will matter, of course, is whether or not any one uses these new APIs... but the reality is that Chrome's reach is almost certainly to make sure of that. If you're looking for a quick, secure way to make payments on your website, it's likely going to become a no-brainer to use these modern payment APIs rather than build your own.
All that's left as an open question is who the winners and losers will be: the credit card companies? Payment networks? We've got an opportunity to change the payments landscape forever, and I'm optimistic these new APIs are going to do that.
A version of this post was sent to re:Charged subscribers a week ago. If you want to get insights like this sooner and support ad-free publishing, I'd love if you became a member!
