- From: Tommy Thorsen <notifications@github.com>
- Date: Wed, 01 Mar 2017 00:05:32 -0800
- To: w3c/webpayments-payment-apps-api <webpayments-payment-apps-api@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webpayments-payment-apps-api/issues/105/283272163@github.com>
@ianbjacobs > In the summary [1] I wrote 'There is some support in the task force for renaming the specification to more closely reflect the features it adds to the Web platform (e.g., "Payment Handler API").' > > What do you think of that name (courtesy I believe of @jakearchibald)? I think the name "payment handler" is a lot more generic and carries a lot less information and meaning to prospective developers than "payment app" does. However, if we decide to not focus on apps anymore, in favor of origins, wallets and options, "Payment Handler API" is an appropriate name. @adrianhopebailie > I like the idea that any Service Worker that registers options, automatically groups them under their origin. The origin is not an identifier it is a "default wallet". Say we do it this way -- where do we get name and icons for the origin entry? I think this is the main weakness of focusing on origins over apps. In the apps case, my first example is super simple, since it picks out name and icons from a web page, using existing algorithms (and presumably, existing implementation). If we want to pick this information out of an origin, we will need to require payment app implementors to do something that isn't currently standard practice. We can require `HTTP GET /` to return an html page, or certain [link headers](https://www.w3.org/wiki/LinkHeader), but I don't feel too good about making this kind of requirements. -- 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-283272163
Received on Wednesday, 1 March 2017 08:06:17 UTC