Progressing "PaymentRequest" to TR

The Payment WG is in the process making the PaymentRequest API a TR.

That's fine.  What's maybe somewhat less obvious is that PaymentRequest in itself has no value since it is just an interface that depends on concrete implementations, aka "payment handlers".

For the latter the WG started with browser-based (built in) "basic-cards".  This has subsequently been deprecated and is not a part of any standard.

After that the ServiceWorker-based PaymentHandler project was launched with the goal making it possible to write payment handlers using "pure" Web technology.  Although this mission has been running for several years, there have been no reports on any major (or even minor) uptake of this technology.

In fact, it appears that the to date only "substantial" use of PaymentRequest is through the proprietary OS/App-level interfaces to iOS and Android provided by Apple/Safari and Google/Chrome respectively.

Recently a new effort called Secure Payment Confirmation (SPC) using FIDO2/WebAuthn was launched.  Unlike PaymentHandler, it is based on browser-based (built-in) support for parts of a payment authorization including the UI.  However, this is also pretty much the antithesis of the open Web.

The only reasonable conclusion from all of this is that supporting advanced payment systems through "pure" Web technology is not going anywhere.  To put things in a slightly simpler wording: it appears to be infeasible building something along the lines of Apple Pay using PaymentHandler.  Apple have more or less set the standard for mobile payment systems in the western hemisphere.

The anticipated charter update ought to take the above in consideration.

Sincerely,
Anders Rundgren

Received on Sunday, 15 November 2020 07:05:25 UTC