State and fate of the PaymentHandler API

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 03:49:59 UTC