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

@jakearchibald,

> What's the benefit of allowing this (given the massive complication it brings)?

Seems like a natural division of code. As a developer, you may want to implement payment method X in service worker script `/payment-methods/x.js` and payment method Y in service worker script `/payment-methods/y.js`. Wouldn't a developer be surprised if they couldn't do that -- or if by doing that it meant that they couldn't group those options under the banner of a single "Payment App" for display to the user?

I think the difficulty here may still be related to the terminology. I think we should stick to saying that what we register is a "payment option" -- and when the user selects that payment option, a `paymentrequest` event is emitted to the thing that did the registering. Ideally, the developer could group these payment options however they'd like to give the user a collective sense of using a single "Payment App". I would think that where the events go is just bound to who does the registering, not to the meta data that declares how to logically group the options for the end user.

So, from that perspective, I don't understand why we should force the developer to divide their code such that all options that will be grouped together must be handled via the same script. However, if this restriction is required in order to avoid "massive complication", then it's worth imposing it. I just don't know what "massive complication" you're referring to.

Thinking through it further now, I can see an unfortunate complication -- that only arises, I believe, from the fact that we don't plan on requiring browsers to surface more granular options. If we register these payment options from @adrianhopebailie's example above:

```
Origin: https://banka.com
      |- Option 1:  Bank A Business
                          |-  Option 1.1: Credit Transfer
                          |-  Option 1.2: Bank Cheque
                          |-  Option 1.3: Corp Card ****4567
      |- Option 2:  Bank A Personal 
                          |-  Option 1.1: Acard ****1234
                          |-  Option 1.2: Loyalty Points
```

One browser may surface these as simply:

```
- Bank A Business (banka.com)
- Bank A Personal (banka.com)
```

While another may show the full granularity of the options for user selection. Given this fact, it will be difficult for a developer to know which service worker script would receive the `paymentrequest` event when more granular options aren't made available to the user. :cry: That's a good reason to restrict payment option groups to a single service worker registration.

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