W3C home > Mailing lists > Public > www-tag@w3.org > August 2017

Re: State and fate of the PaymentHandler API

From: Alex Russell <slightlyoff@google.com>
Date: Sat, 05 Aug 2017 05:44:23 +0000
Message-ID: <CANr5HFXDLzW40AsDsEJ8zveKuRBahnBZt=0gZOzdZcMq_dtQjA@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>, "www-tag@w3.org" <www-tag@w3.org>
I can't tell if this is intentional trolling or not, but the littany of
factually inaccurate and misleading statements in this message will take
hours to disentangle. I do not have those hours. Perhaps you might consult
Samsung's documentation in the interim:


Or see MSFTs support:



On Fri, 4 Aug 2017 at 20:53, Anders Rundgren <anders.rundgren.net@gmail.com>

> For those who visited Google I/O 2017, you may have gotten the impression
> that Web payments is a deal done.
> However, this is not the case, what the Chrome team have actually created
> is a proprietary solution for invoking native Android payment applications
> through the PaymentRequest API.
> For creating truly Web based payment applications you must rather use the
> PaymentHandler API which is based on an extended ServiceWorker interface.
> At the time of writing PaymentHandler only exists in an experimental
> version running on Android using the "Canary" browser.
> Although that's a bit limiting, there are other factors to consider as
> well:
> A payment application based on PaymentHandler depends on (AFAICT) a rather
> unusual bootstrapping process requiring the user to surf to his/her payment
> provider to get "Initialized" with PaymentHandler code.  This departs from
> existing Web based payment solutions like PayPal and will likely hamper
> adoption.
> But the real stumbling block is that practically all new payment solutions
> are based on native "Apps" for the simple reason that they want to target a
> wider range of payment scenarios, exactly as Google and Apple already do.
> Another and quite popular way of performing Web payments is using a mobile
> device as a "Payment Terminal" to a Web application running on a PC. This
> scheme doesn't appear to fit any of the currently defined payment
> interfaces.  The Web NFC CG even dismissed this use case.  Since the
> payment industry can't wait, QR based solutions have become the norm and
> recently QR payments became an EMVCo standard.
> Anders
Received on Saturday, 5 August 2017 05:44:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:16 UTC