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

@adrianhopebailie 
> 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?

2 options, assuming both service workers have registered a single option each.

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

Each of the two options presented to the user, is connected to a specific service worker instance, by means of an ID (in our [current implementation](https://github.com/tommythorsen/webpayments-demo/blob/gh-pages/clients/README.md) in Chromium, this is not the scope url, but a unique numeric identifier).

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

Our current implementation does not care about the scopes of the web apps nor the scopes of the service workers when it comes to directing events to the right listener. Each option presented to the user is linked directly to a specific service worker instance. Even if we move from being service-worker-centric to being web-app-centric, I don't think this implementation detail needs to change.

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

That's fine. It will be presented as a third payment option in the UI, and an eventual payment request event will be routed to it without any problem.

> What if it has no manifest?

This depends. As per the current specification, the web app manifest doesn't really matter, but it could be that we want to rely on it a bit more, now that we've changed our definition of "Payment App".

> How does the browser figure out what options to present

This is easy. We go through all the registered service workers, and check which ones can handle the merchant's supported payment methods, and do optional extra filtering. I don't think we need to confuse things any more by dragging origins and scopes into this equation.

> ... and, when the user has selected one, what event listener to invoke?

Again, as an implementer, I don't see that there is any problem with knowing exactly which option belongs to which service worker instance. Once the user has selected an option, we can pass the event to the correct service worker.

Even though we have moved from focusing on service workers to focusing on web apps, the service workers are still the ones that register the payment options and the payment request event listener. I don't see any reason to change this. Do you?

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