Re: State and fate of the PaymentHandler API

On 2017-08-05 07:44, Alex Russell wrote:
> 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. 

This posting was primarily about PaymentHandler API.  Current status:
https://github.com/madmath/payment-request-show/issues/13#issuecomment-317460376

I did indeed forgot to mention that the PaymentRequest API supports "basic cards" and on multiple platforms. Unfortunately "basic cards" is incompatible with the fairly commonly used outsourced "Secure Payment Pages".

Deciphering how the W3C payment effort matches the existing and anticipated payment landscape doesn't take hours to disentangle; it can easily take several weeks.

Anders

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

Received on Saturday, 5 August 2017 06:49:21 UTC