Re: [w3c/webpayments-payment-apps-api] Payment app identifier to manifest filename mapping (#48)

@tommythorsen thanks for putting this together!

With ["what we don't want"](https://github.com/tommythorsen/webpayments-demo/blob/gh-pages/proposals/Recommended%20Payment%20Apps.md#2-what-we-dont-want) - I'm not sure you'd ever show this. The page would be able to detect "no matching payment methods" and show links to supported methods.

The above would solve my issues with ["A much better experience"](https://github.com/tommythorsen/webpayments-demo/blob/gh-pages/proposals/Recommended%20Payment%20Apps.md#3-a-much-better-experience). Currently the browser is presenting a link of the merchant's choosing, along with a title & icon of the payment app's choosing. I'm really worried this will look like endorsement from the browser, and the title and icon is distracting from the security-sensitive part. I'm not sure "The merchant recommends…" is enough to overcome this.

["Installing the payment app"](https://github.com/tommythorsen/webpayments-demo/blob/gh-pages/proposals/Recommended%20Payment%20Apps.md#4-installing-the-payment-app) is problematic because (I assume) it'll involve a browser permission while you're showing two different origins on the screen.

I think we bypass a lot of the security complication if we allow the merchant to detect "no payment apps available", and they just show some links on a page, which are already well-understood by users in terms of who's offering the links, and who controls the content. Because it's a link, there'll be nothing new happening when the payment app requests permission.

-- 
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/48#issuecomment-276123833