Re: The elusive PaymentRequest API

Although the topic seems to be of no interest, I continue a bit :)

The purpose of an API is to create a standard way of interacting with a specific resource or activity.  This was also the motivation behind PaymentRequest.

However, you don't have to look further than Google Pay for Android to see that the only data that qualify as standard are the items "amount" and "currency", while Processing, UI and Return Data is entirely application specific.

Outside of the core payment [authorization] process, PaymentRequest also supports a fairly complex shipping data handler.  But the two established methods 1) Logging in as a registered customer and 2) Autocomplete, already do that without being mixed with payments.  Creating an API for saving one click seems like overkill.

PaymentHandler doesn't support the quite common Desktop/Web + Mobile Wallet scenario and it is not in workings either.  The "refactored" PaymentRequest method I'm proposing would enable a universal Web/BLE scheme along the lines used by WebAuthn.

Hopefully the modal window extension to ServiceWorker will spur the discussion that didn't happen when the PaymentRequest API was conceived.

Thanx,
Anders

On 2020-01-11 08:37, Anders Rundgren wrote:
> The PaymentRequest API has been in the workings for 5 years but has not yet reached REC state.
> 
> There never was a need for a specific payment API on the Web, you rather need new Web primitives [*].  Now this topic has come back, but this time from the WG itself: https://github.com/adrianhopebailie/modal-window/blob/master/explainer.md
>           "However, the presented UI component could be useful for other use cases
>             (e.g. authentication, sharing, access to third-party services) and an innovative use
>             of the payment APIs (creation of a fake payment context) to demonstrate this is
>             shown in this demo"
> 
> Unfortunately the pretty severe architectural issues doesn't end there.
> 
> Recently it was found out that one of the most touted features (enumerating matching payments methods in the browser chrome), has become a hurdle and should be skipped [*].
> 
> Regarding the latest mission by the Payment WG, you may take a peek at: https://lists.w3.org/Archives/Public/public-payments-wg/2020Jan/0009.html
> 
> Another troubled area is the Web(only) based https://www.w3.org/TR/payment-handler/  Why is that?  The payment industry appears to have to 99% based their developments on native mobile apps.  I have written a short paper why this is likely to remain a fact: https://github.com/cyberphone/doc/blob/gh-pages/payments/paymenthandler.md#the-w3c-paymenthandler
> 
> Thanx,
> Anders
> 
> *] Claimed by yours truly from the very beginning
>

Received on Tuesday, 24 March 2020 09:26:18 UTC