Re: [w3c/webpayments-payment-apps-api] Multiple payment apps per origin (#98)

@marcoscaceres,

In your mock up, if a user selected "master card" to pay, would only the service worker that registered it receive the payment request event?

Now, regarding "multiple payment apps per origin", I think what @chackett and @adamroach are looking for is another level of classification that can be surfaced on the UI. In other words, I believe they would like to be able to create different groupings, each with their own icon/title, of N of what you are calling payment methods.

Side note: I think what you're calling payment methods are really what have been understood by the group to be payment instruments. These are instances of payment credentials that can be used by a particular payment method. In other words, "visa-debit-legacy-v2" is a payment method identifier which uniquely identifies a payment method, which is set of rules (and a network) for processing payment. A payment instrument like "the visa card with number `4111 1111 1111 1111`" may be used by such a payment method to perform payment. The terminology in this space -- as previously noted -- can be confusing and significant conflation occurs between popular understanding and various industry terms of art. So you should be aware that even the language you are using to talk about how a payment app exposes "which payment methods it supports" may take on a somewhat different meaning from others in this group. We must all make a best effort to understand these nuances.

Anyway, getting back to what I think may be desired here: Could the same origin, after getting permission (just once) to handle/manage payment for the user, register two different "groups" of payment options? I'm intentionally not using methods/instruments or mentioning service workers, because it doesn't matter for this particular point.

Each group could be surfaced on the UI using a title and icon, e.g. one for "Merchant X" and one for "Merchant Y" where both of these merchants have signed up to use a white label service provided by the origin. Similarly, another origin could surface two different groups "MyBank for Business" and "MyBank Personal". The origin would be the same for both of these cases but, from the end user's perspective, there would be multiple "apps". The assumption here is that the end user's only concept of "an app" is an icon they click on to do things -- and that icon is merely a "grouping" indicator. Each of these groups may have N "payment methods/payment instruments".

Under this scenario, there would be no user consent required to "install" these groups. Any service worker on the origin could add or remove them at will. They could, of course, ask the user (on their own) at the origin if they want to add/remove these groups (and may use the language "app" on their site). I believe this would give @adamroach and @chackett what they are looking for and it would fit into the architecture you've described. The only possible hiccup may be with how origin/manifest icon meta data is used (or not used) here.

Sorry for rambling on. **TL; DR**: Would it meet the use cases and fit the existing browser architecture to allow origins to create their own "groups" (terminology pending) of payment methods/instruments that could be surfaced using titles and icons on the UI? Control over the addition/removal of these groups would not require user permission. Note: getting user consent for permission to handle payment and any site's division of its own code into N many service workers is totally orthogonal to this.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments-payment-apps-api/issues/98#issuecomment-275717308