Re: [w3c/webpayments-payment-apps-api] What is a Payment App? (#105)

@adrianhopebailie 
> I am still not convinced that the use case for wallets is strong enough to justify all the complexity it brings with it. Your first code example is so clean and easy to understand and doesn't require any new data models to carry icons, just a label and set of supported methods.

I agree, and this was [my reaction too](https://github.com/w3c/webpayments-payment-apps-api/pull/104#issuecomment-281330695), to the pull request that introduced them. Like you, I won't oppose it too strongly, but I would prefer simplicity over having this -- in my opinion unnecessary -- feature. I say unnecessary, because you can achieve the same result by using two apps and no wallets.

@adrianhopebailie 
> None of your examples demonstrate what would happen if two Service Workers were registered from the same origin with no wallets. Would they be grouped together? I assume so.

No, not according to my proposal. For the case in your example, it would absolutely make more sense to group them together, since they are indeed registered from the same page/app. However, if they were registered from different pages within the same origin, things get a bit iffy. I think you should be allowed to have multiple apps within one origin, so I'm not sure I agree with grouping them all together inside an item representing the origin.

I would personally prefer the following solution:

We introduce an `appId` property on the `PaymentAppManager`. This property defaults to the url of the context that registers the Payment App, but can be set to any string. If multiple service workers within one origin have the same `appId`, they will be considered the same app, and sub-options will be grouped together in a single item.

-- 
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/105#issuecomment-283031724