I quite like this suggestion. The problem with `PaymentApp.register()` is that users are not very likely to install payment apps ahead of time. Even if the user goes to the web site of his bank, and this web site offers to install a payment app into his browser, he is most likely to think _"hmph, why would I need that? I have nothing that I plan to pay for online."_ Most people will probably not be interested in installing a payment app until the very moment they actually need to buy something. We've discussed having `merchant recommended apps`, but what this issue suggests is to ditch the installation part and only consider the list of apps supplied by the merchant (which will then need to contain enough information to actually launch the payment app). This will probably work very well for proprietary payment methods, which I would argue are probably the majority of payment methods. The only open payment methods I can think of right now would be basic card payments and probably most cryptocurrencies. If we go for this suggestion, many of the problems we are currently discussing will go away. For instance, there will be no need for a query function, which is functionality that many people are against, for privacy reasons. The open question here is: if we want to go this route, how do we deal with open payment methods? One approach might be to go for a combination, where we leave the `PaymentApp.register()` function (or something similar to it) intact, but make it optional for proprietary payment apps. --- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/w3c/webpayments-payment-apps-api/issues/8#issuecomment-235873397
Received on Thursday, 28 July 2016 11:52:54 UTC