W3C home > Mailing lists > Public > public-payments-wg@w3.org > July 2016

Re: [w3c/webpayments] [Payment Request] Should we allow a "polling" mechanism for websites to not invoke the API if there are no enabled methods (#159)

From: Adrian Hope-Bailie <notifications@github.com>
Date: Tue, 12 Jul 2016 04:52:19 -0700
To: w3c/webpayments <webpayments@noreply.github.com>
Cc: webpayments <public-payments-wg@w3.org>, Comment <comment@noreply.github.com>
Message-ID: <w3c/webpayments/issues/159/232023211@github.com>
The discussion in the payment apps breakout revolved around getting a similar function to that offered by ApplePay but also recognising the need to do this in a privacy preserving way.

In the abstract we need a way for a merchant website to say: "Here's my payment request, including all the supported methods, if I call show() right now will the user be prompted to install recommended payment apps to be able to process this payment or have they already got apps installed that can handle this request."

As you can see this fits hand-in-hand with the concept of the browser and merchant being able to recommend payment apps to the user. The desire here is to fail silently (from the perspective of the user) rather than show the user a UI suggesting they install recommended payment apps.

Obviously, if we don't have the idea of recommended payment apps at all then the API would fail silently (from the user perspective) anyway and the website can direct the user to their traditional payment page.

The privacy issue we haven't yet solved is merchants polling the API multiple times with different payment requests to determine what payment methods the user supports. We could conceivably only allow the website to call this once (specifically how this might be done I'm not sure yet)

---
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/159#issuecomment-232023211
Received on Tuesday, 12 July 2016 11:53:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 12 July 2016 11:53:02 UTC