Re: [webpayments] [Architecture] Payment App is a term used in EMV to describe the applet stored in SC (#31)

> User's don't care about payment methods and it's arguable whether they care about payment instruments. The purpose of the payment app is to abstract these away. 

I disagree that users don't care about payment methods and I definitely think they care about payment instruments. Certainly in existing payment systems they do.

Before we decide to add another abstraction layer, can you list the benefits of doing so?

>From my point of view, it seems like this abstraction has a lot of drawbacks. For example, it potentially makes it more difficult to bootstrap a wallet/browser that doesn't have "Payment Apps" stored in it yet. It makes it more difficult for people to store their instruments/funding sources in a cloud-based service and then use any device they want to make a payment, as the declarative information in the instruments can recommend to the browser/payment mediator default "Payment Apps/Payment Agents" to install and they could be auto-installed and invoked. There are a number of other issues (eg: non-compliance with [Rule of Least Power](http://www.w3.org/2001/tag/doc/leastPower.html), more difficult to implement automatic updates) that would also be worth considering when looking at such an abstraction. But before we get further into drawbacks, I would like to know what the benefits are.

Knowing the benefits seems like a better starting place.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/31#issuecomment-163275336