Re: State and fate of the PaymentHandler API

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:

https://samsunginter.net/docs/web-payments

Or see MSFTs support:

http://caniuse.com/#feat=payment-request

Regards


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

> 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
>
>
>
>
>