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

@ianbjacobs 

> Your comment above: "In this architecture a payment method is the protocol that is used between payment app and payee to exchange payment data. "

> Does not seem to align with the architecture document, which defines payment method as: "A way of paying. A system and set of rules for payments."

That definition needs an update to more closely reflect how "payment method" is being used in the API proposals.

Again, this is not something that directly translates to the physical world metaphor because the discovery of payment methods that are supported and filtering of payment apps based on this is entirely automated (and has no user interaction). The proposals are already talking about identifying the payment methods using a URI, not a very user-friendly label.

For illustration, I wouldn't consider "Visa" a payment method. I'd consider something like "Legacy Visa Credit", "Tokenised Visa Credit", "Encrypted Visa Credit v2" as payment methods that could all potentially be used with the same visa credit card (as payment instrument). In fact, a payment app could support all three or just one.

The payment method that the payment app uses defines what it expects the format of the request to be, how it processes the payment and what the format of the response will be. These will be different for the same payment instrument depending on how it's used (e.g. plain text, tokenized, encrypted, etc.).

> I have understood payment method to be the things you say for X in the phrase "At this shop we accept X ". 

Yes, but in our architecture this statement is made via a machine-readable payment request. It's not surfaced to the user at all.

> That would include things like "Visa" and "PayPal" and "Samsung Pay". I believe users, merchants, and payment system providers care a lot about visibility of those brands.

That is true but the opportunity for branding would be in the app. In the same way as VISA doesn't issue cards but rather force their issuers to put their brand on cards, I'd expect brands that care about this to force apps that want to claim support for their payment methods to have some branding requirements too.

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