[octalmage]

I used the Payment Request API in a project and it was great. Chrome currently has it implemented for Android, you call a JavaScript function, a prompt appears asking the user if they'd like to pay, they enter the security code and hit pay.

All this feature actually does it give you the users credit card, phone number, and billing/shipping addresses. You still have to give that information to someone like Stripe.

They're focusing on mobile since that is where the checkout experience is the most painful. https://ride.lyft.com has it implemented if you want to check it out.

[objclxt]

> All this feature actually does it give you the users credit card, phone number, and billing/shipping addresses. You still have to give that information to someone like Stripe.

I used to sit on the working group for Payment Request - the primary intention of Payment Request is to get rid of checkout forms and parallel implementations of the same logic. Right now most for most implementations that means credit card entry, but the standard is designed to support any type of payment.

So if I'm running an eCommerce site and want to support PayPal, Apple Pay, and Android Pay I shouldn't need to implement three discrete SDKs and APIs - I can instead implement Payment Request (although you'll still need to process the payment information output by each of those payment mechanisms separately. Ultimately for many merchants the implementation of Payment Request will be abstracted away by their payment processor, such as Stripe).

However, there is a parallel standard to Payment Request, called Payment Handler, which is designed to allow third party payment providers to write service-worker-esque plugins to browsers to take payment directly. They're intended to work together, but it's possible for a browser to implement just Payment Request to replace autofill if they so choose.

There's also a lot of other work going on at the W3C around payment, but Payment Request and Payment Handler have the most support from browser vendors and are as such the most actively developed.

[mcintyre1994]

Do you know if this is being used in iOS Safari for Touch ID in the browser too? Or is that something non-standard?

[MBCook]

Apple Pay on the web exists and it's fantastic. As Tarek points out it is custom and doesn't use this standard.

Apple has not implemented the starndard yet, the WebKit Status page lists it as "Under Consideration".

I hope they end up implementing it for the sites hat won't do Apple Pay natively.

[traek]

That's the non-standard Apple Pay JavaScript API [1].

[1] https://developer.apple.com/documentation/applepayjs

[baybal2]

Well, they are trying to undercut Chinese with web payments, one part why mobile payments took off so well in China is because Tencent and Alibaba took out browser makers out of the equation.

If you open a website that requests your Visa or MasterCard CC data in any Tencent product, it will be blocked unless "their special hack proof API" is used. And yes, they blocked apple pay too

[objclxt]

> Well, they are trying to undercut Chinese with web payments

Alibaba are very active participants on the Payment Request Working Group. I'm not sure they can undercut themselves. You will find several very large Chinese companies taking part: https://www.w3.org/2004/01/pp-impl/83744/status

[baybal2]

On my memory, they were very very anxious about anything with capacity to subplant zhifubao. Paypal famously had a one click payment plugin for China, and it got banned by Alibaba nearly instantaneously.

Paypal later banned Alibaba from using Paypal outside of China