What makes us think that the payment request API will get more adoption than requestAutocomplete?
This is always a hard question to answer, but a couple of thoughts: 1.) We have multi-browser support early in the process, which sends a strong signal to merchants that might consider implementing.

This could have also been solved by other browser vendors implementing requestAutocomplete. The API was very simple and I suspect Mozilla and Google would have considered changes if it meant other vendors would be onboard. Perhaps the payment request API was created because there wasn't widespread knowledge of the rAc API (perhaps because it was just part of the HTML spec).

2.) PaymentRequest allows us to bring better, faster, and more secure forms of payment to the web platform (e.g. things like Apple Pay).

The requestAutocomplete API was very simple (one method) so it could have easily been extended/modified to return tokens instead of plaintext credit card numbers.

3.) The landscape has changed. Mobile payments have become quite popular over the last couple of years, and we've also seen a resurgence of mobile web sites and a focus on creating great mobile experiences. PaymentRequest is about making sure we also have modern payments on the web as well.

This doesn't seem new to me as requestAutocomplete was often positioned as an API to help the checkout flow on mobile (there were studies about drop-off rates on mobile checkouts cited in Chrome dev videos and at I/O). IIRC, it was also implemented for Chrome on Android first and Chrome only supported rAc if payment fields were present instead of implementing the API in general. In other words, mobile was the primary motivator for rAc too and payments was the priority for Google's implementation.

I wrote up a bit more on this in my rationale doc.

I disagree with the three points since the spec wasn't set in stone and therefore starting from scratch wasn't required.

Why is requestAutocomplete adoption low? Were there implementer concerns? Author concerns?
No one else implemented it. Why spend the development resources to update your checkout flow for one browser?

requestAutocomplete was made to easily work on top of existing sites without changes to the server-side (receiving the request) or markup (of the requesting page) so the investment was very small to adopt it and the value would be higher checkout conversion rates (especially on mobile). We (Mozilla) did start implementing it but it just wasn't a high priority. I don't know why other vendors didn't implement it. Did they even know about it or consider it or was it forgotten about?

Why wasn't the payment request API built on top of rAc since it's mostly a subset with some extra/different returned data which could have been part of the rAc return value?
I actually disagree with the premise of this question. That might be true for basic card payments, but it is not true for all other forms of payment out there (tokenized, closed loop systems, direct bank transfer, etc).

I don't see how new arguments or Promise resolution values for the requestAutocomplete method couldn't have support non-credit card payment methods in a non-breaking way.

Consider removing requestAutocomplete #1207

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions