In recent years the Web Platform has gained many of the capabilities that had been exclusively the preserve of native applications. But one area in which the Web has continued to lag is in the area of payments.
Enter the Payment Request API a way for browsers to manage the user’s experience of paying for things on the Web, and making this faster and more consistent for users and merchants alike.
In this session, Eiji Kitamura from Google Web Developer Relations team shows us what the payments API is for and how to use it to make the experience of paying for things on the Web much more pleasant.
Better Payments for the Web with the Payments API
Eiji Kitamura, Developer Advocate Google
Eiji is going to talk about progress on the web payments API.
The most common payment method in most countries is to use a credit card. But there are pitfalls like people entering the wrong code, or they just give up on the purchase – which is not what an online retailer wants!
In-app payments have much lower friction, but requires an existing relationship and prior setup. It makes individual purchases very easy for the user.
So why not do something similar for the open web? That’s what the payment API is trying to do.
It’s also looking at the challenges of closed ecosystems, where developers have to deal with each separate API for multiple payment providers.
Comparison demo – native payment flow in an app, where the user never leaves their app context; vs existing web experience where users are sent out to third party sites, then back to the actual merchant.
Using web payments the UX is much closer to the mobile-native purchase – the user stays in the same context and the payment is modal. It also works across platforms, so the same system can be used across desktop and mobile.
Key roles in this:
- Merchants – who sell things
- Payment handlers – who handle the transaction
Code demo showing how the Payment Request API captures purchase requests, launches a payment app and awaits a payment credential for a successful payment. This allows the merchant site to complete the purchase.
On the Payment Handler API side, listeners are set up to receive payment request events; then launch the payment interface.
Secure Payment Confirmation – while there are mostly two players, the merchant and the payment handler, but there may also be a a bank or issuer involved as well. That adds a requirement for stronger verification that the customer is the legitimate card holder.
While more secure, it adds a lot of friction – and this can lead to abandoned purchases. So WebAuthn aims to reduce this friction, using FIDO standard biometric sensors (like a fingerprint reader) on the user’s device to reduce the need for slow verification.
If you are interested in this feature, please join the discussion at https://github.com/rsolomakhin/secure-payment-confirmation/
Digital Goods API – this brings the idea of marketplace purchases to the web. It pairs well with Trust Web Activities (TWAs) that expose web content on Android apps. While a specific marketplace will reduce user friction, you will still have to abide by the vendor’s rules.
If you are interested in more, go to https://web.dev/payments