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

I think we are all clear on the permission model so let's leave that to the side now.

What we're trying to establish is whether it is possible/desirable for a user to be presented with two "things" that it can choose between when the browser prompts him/her to make a choice between payment apps.

## Example

Assuming the two "apps" that @tommythorsen has created each install a service worker (https://people.opera.com/tommyt/blue/sw.js and https://people.opera.com/tommyt/red/sw.js are the script files).

Both SWs have registered event listeners for the `paymentRequest` event and also registered their ability to handle payments for the `basic-card` payment method.

So, from the perspective of the browser there are two apps (from the same origin but that's okay) with non-overlapping scopes that can both handle basic card payments.

When @tommythorsen visits a website that calls payment request and lists `basic-card` as a supported method, what is the desired/expected behavior? Does @tommythorsen get presented with 1 or 2 options?

Assuming he's presented with 2 options, how does the browser decide which event handler to invoke when he picks the blue app? 

Do we require that the two service workers that register the event listeners have non-overlapping scopes and scopes that fit within the scope of the manifest (from which the browser gets the icon and label to display), or must the URL of the service worker install scripts be under that same scope?

What happens if a third service worker is installed from that origin (https://people.opera.com/tommyt/sw.js) with an overlapping scope (https://people.opera.com/tommyt/) and also registers itself as a handler for basic card payments?

What if it has no manifest?

How does the browser figure out what options to present and, when the user has selected one, what event listener to invoke?

My understanding of navigation scope is that it is simply a way to tell the browser whether to apply the context changes defined in the manifest or not, based on the location the browser has navigated to. I would like to hear from @marcoscaceres but I don't think the intention of the navigation scope is to define app boundaries?

So, I don't think we can prevent anyone having a hundred SWs under the same origin, all listening for payment request events. 

But, we must define how the browser separates these from one another into logical "apps" for the sake of presenting a user with choices and also, how the browser determines which "app" to invoke when the user has made their choice.

If we want to use scope, then that's fine, but we need to put something in the spec that makes this easy to understand, implement and develop against so that the outcome is predictable.

-- 
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-277955035