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

@adrianhopebailie said:

> It seems that what many of us are calling "apps" only ever have to identified explicitly as "user choices".

I agree with this. All we need to do is specify:

1. How a developer can declare these choices so the browser can surface them in the UI, and
2. How the developer can write code to receive an event with the user's particular selection information.

I think origins and permissions are orthogonal to this particular problem. We already have a clear model for those: An origin requests permission to "handle payment" -- and, if granted, they may then specify whatever choices they want, whenever they want to.

We just need to pin down exactly what the API looks like for specifying choices and how the browser will communicate user selections back to the developer in a way that they expect. There is a secondary piece to the "how developers specify choices" which involves the ability to group choices so users can make more fine grained selections if the browser wants to expose this in their UI (but it likely isn't a requirement). @adrianhopebailie's [comment](https://github.com/w3c/webpayments-payment-apps-api/issues/98#issuecomment-280470427) shows an example of this.

I don't know that we even care what the identifiers are for the choices. Those could be left entirely up to the developer. All that needs to happen is the browser must effectively communicate them back to the developer once a user has made their selection. What is important is that the developer knows how to write the code to receive the selections.

It may be that a particular Service Worker `registration` will specify payment options and that same Service Worker will receive user selection events for those options (if the user chose them). That keeps it simple. What the Service Worker does after it receives those events is totally up to the developer, provided that their code, wherever it lives, ends up passing back a payment response via the appropriate API. It may be that for a particular choice, all the logic for specifying that choice, capturing a user selection event, and sending back a payment response will all happen in the same Service Worker. That doesn't mean a "Payment App *is* a Service Worker", it just means that the part of a Payment App that needs to talk to the browser (or use it as a mediator) appropriately reuses that component of the Web Platform.

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