@dlongley asked: > Would it meet the use cases and fit the existing browser architecture to allow origins to create their own "groups" (terminology pending) of payment methods/instruments that could be surfaced using titles and icons on the UI? Yes, and this already exists in the spec as "options". The intention is for a single payment app to register multiple options each of which handles requests for a specific combination of payment methods. @dlongley said: > The argument here is that there is no 1:1 relationship between a Payment App and a Service Worker. A Service Worker is simply a division of labor mechanism for an origin. When we have said, in the past, that a "Payment App is just a Service Worker", that was a mistake. Yes, I think that's at the heart of the issue. And also: > What we should not do is talk about them as registering themselves. We should separate how we talk about the code an origin is running from what is effectively our "grouping" of an end user experience that a particular origin provides. That's what a Payment App really is, IMO. Agreed. I still think we should be writing a "Payment Apps Specification" but that this should define the various features that we are introducing for web apps to use that would qualify them as payment apps. -- 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-276377189
Received on Tuesday, 31 January 2017 14:28:50 UTC