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

@adrianhopebailie 
> You are talking about the options and I am talking about apps. The choices presented to a user exist at two levels. The user is presented with a bunch of "apps" and under each app is a bunch of "options". The most common use of options will be to present different instruments that the app has stored.

While the exact presentation should be left up to the implementor of the mediator to decide on, I do agree that providing the mediator with the means to display "app" elements with underlying "option" elements is a good thing.

The challenge then is how do we decide which Service Workers belong to which Web App? Is there any existing method/algorithm we can use for this? Comparing scopes could work, but there are a fair amount of corner cases that can make problems for us. For instance, a Web App can be [unbounded](https://www.w3.org/TR/appmanifest/#dfn-unbounded). How do we handle this case? A service worker that is registered by a page that belongs to the Web App, can probably also set a scope that is wider than the scope of the Web App. Does the service worker belong in this case, or not?

@marcoscaceres 
> I honestly don't think we need [Payment Options].

Keeping things simple for V1 of the spec *is* a good thing. I could probably be convinced to agree to leave the options for a future version. Especially if doing so would simplify things significantly. Unfortunately, omitting Payment Options does not let us sidestep the problem I describe above. We'd still need to figure out which Service Workers belong to which Web App.

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