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

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

My only concern here is we're back to tying a Service Worker, 1:1, to a user choice. That feels wrong to me at an architectural level. It's an implicit binding between a background process and a UI element that is not really how SW's are intended to be used.

As @dlongley pointed out previously SWs are just a way of having a background process, a division of labour, for a web app. As @marcoscaceres has also pointed out, you could have multiple SWs per payment app (example one that knows how to handle card payments and one that can handle some other proprietary payment method). The developer intends these to be presented to the user as a single "app".

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.

In this flow the browser will fetch the SW script defined in the manifest and register the SW at which point the app can register its intention to be a payment app. (i.e. the app asks for the "handle payments" permission and registers event listeners for payment events).

I believe that the SW would necessarily have to be within the defined scope of the app as defined in the manifest or it will not be installed.

The thing presented to the user at payment time is the app in the form of its icon and label (as defined in the app manifest). 

If a user selects an app, all SWs within the scope of that app and which have registered listeners for one of the merchant supported methods receive the paymentRequest event. (i.e. it could be more than one).

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

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