Re: [w3c/webpayments-payment-apps-api] Use PaymentRequest and PaymentResponse (#99)

@marcoscaceres,

> I'm not following, sorry :( What is the "payment method author"?

No problem. The entity that is in control of the payment method -- either of its specification or of the manifest that lives at the end of the URL that identifies it. So, for example, someone (the author) invents "Floyd Bucks" that various websites can use and publishes a URL with information about this payment method. When this URL is fetched, it returns a document that includes a restricted list of origins that may provide payment apps for it. Then, when a payment app tries to say that it supports this payment method in the browser, this URL will be fetched and checked to ensure that they are allowed to do so.

Note that, as I mentioned elsewhere, a "payment method", in this WG, is understood to refer to a set of rules and potentially a network for processing payments. It is not a "payment instrument" or "payment credential" like a credit card. These are merely examples of mechanisms for authenticating on a payment network. We are trying to enable the creation and interoperability of multiple payment methods on the Web. Anyone should be able to create a payment method, and if they so choose, restrict which origins may provide applications to implement that payment method.

> A payment app (evil.com) can only say: "I support 'BobPay', send those my way!". It can lie all it wants, but merchant.com can protect itself by always making sure that 'BobPay' requests only ever go to 'bobpay.com'.

See above. One idea that has been thrown about here by the WG is to have the payment method manifest specify which apps/origins may support it -- and payment mediators (e.g. browsers) would enforce this.

> Because, as I understand it, it is merchants, in coordination with payment processors, that need to include privacy-sensitive/proprietary/merchant-identifiying information in the .data field. Thus, the browser doesn't burden them: it provides them with a perfectly good solution for protecting this information.

The merchant doesn't care which app you use to process the payment. It cares which *payment method* you use. The apps that are permitted to use this payment method are decided by the payment method author -- which is an abstraction level away from the merchant. We are trying to enable the independent creation and management of payment methods -- so that merchants may use them at will with any end user that has any app that supports (and is permitted to use) that payment method. We don't want the merchant to have to concern themselves with which app you are using (or to unduly restrict you).

> Again, let's please start using code to reduce ambiguity.

That's fine, but I think there's a basic terminology issue. A credit card is not "payment method", it's a "payment credential" or "payment instrument". When writing code, we'd simply be reusing the same terms that are causing confusion.

-- 
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/99#issuecomment-276407056