@dlongley, This came up on the apps TF call today. I agree that we need more clarity on how this would be supported but I don't think we should call these "apps". Many of these option could technically be supported by a single web app. I like your other comment that payment apps are effectively web apps that use some specific platform features that we are defining. Personally I still like the idea of sticking with origin boundaries (and then using sub-domains if required) and providing options per origin (where each option has a label and icon). @adamroach had some other ideas but I don't want to speak for him so will leave it with him to comment. Consensus was that a payment app is identified by its origin (just like any other app on the Web platform), but that as a separate issue we need to ensure our "option" semantics support all the use cases we expect payment app developers to have. Step 1 is gathering those use cases. -- 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-276457994
Received on Tuesday, 31 January 2017 19:02:09 UTC