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

@adrianhopebailie 
> My only concern here is we're back to tying a Service Worker, 1:1, to a user choice.

I'm not sure what this refers to. Neither the existing `setManifest()` specification text, nor the proposal in https://github.com/w3c/webpayments-payment-apps-api/issues/95 ties Payment Option 1:1 to a Service Worker. Each Service Worker can register 0, 1 or many Payment Options.

> I like the idea of the "user choice" being analogous to the "app icon on a user's home screen". i.e. My browser finds an app manifest and "installs" that app (assuming I give the app all the permissions it requires). This is no different to the app manifest flow today.

That does actually sound pretty nice, but then we are not doing Payment Options anymore. You're now describing a single entry per Payment App. Nothing wrong with that approach, although there might be advantages to having multiple Payment Options per Payment App too.

Implementation-wise, this does probably require us to keep track of all Service Workers that belong to a Payment App. "Belong to" meaning either registered through the App Manifest, or from a page that [is associated with the App Manifest](https://www.w3.org/TR/appmanifest/#associating-a-resource-with-a-manifest). Not sure how easy this is. It might be feasible.

> It is up to the app developer to co-ordinate this if they use multiple SWs (as it would be today if you had mutiple SW(s) listening for fetch events). The first SW that calls respondWith on the event wins and that is the response passed back to the website.
> 
> This only leaves SWs that attempt to register handlers independent of the app manifest install flow (which is completely possible). We need to define a way for them to make themselves available for user selection or decide that we always ignore them...

This does not sound that great, though. Our current specification, where Payment Options are registered by the individual Service Worker, and Payment Request events are passed directly to the correct Service Worker feels much more precise and elegant. It solves the last problem you describe, too, by allowing any Service Worker to register and handle payments, regardless of whether has a relation to a Web App Manifest.

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