Request for use cases: "canmakepayment" event

[rsolomakhin]

Hi,

As part of looking into improving the privacy properties of Payment Handlers, I'd like to collect the known use cases for the "canmakepayment" event. Here is what I have came up with so far:

1. Kill switch: A payment app wants to globally disable the use of Web Payment API. A service worker may use the “canmakepayment” event for this purpose, in case if there is a bug that causes the Web Payment API flow to be broken.
2. Single instance: A payment app wants to prevent showing two instances of the payment UI at the same time. Chrome rejects any PaymentRequest.show() calls that happen while another PaymentRequest.show() call is happening, but there is no way for web developers to know that the reject is going to happen ahead of time. A service worker may use the “canmakepayment” event to check an in-memory boolean variable that is set to “true” when this service worker is already handling an ongoing "paymentrequest" event. (This implementation would not catch another origin's Payment Handler UI being displayed, however.)
3. Instrument on file: A payment app wants to check whether the user is logged in and has a payment instrument on file.

I'm assuming that the same use cases hold for Android payment apps.

What other use cases are out there? I'd love to hear feedback.

Thank you,
Rouslan

[stephenmcgruer]

cc @ianbjacobs - perhaps something for the agenda for either the 18th or TPAC? (Perhaps as a broader discussion of PaymentHandlers in a more-privacy-preserving world, and what the future should look like?)

[ianbjacobs]

Hi @stephenmcgruer and @rsolomakhin, yes, let's start by putting this on the 18 August agenda. It would be great for you to re-introduce the topic then.