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

> Per my understanding, it's the payment method author that is in charge of deciding which handlers ("payment apps") should be able to see data associated with a particular payment method. 

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

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' payments only ever go to 'bob pay.com'.   

> Why should we burden merchants with having to fetch this information and specify it in the request instead of having the browser do it for them?

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. 

> If we're ok with having the browser use an origin field to determine whether or not it should send data somewhere, what's the reason for not having the browser use other information, like which methods are supported/allowed by the destination?

Again, I'm not sure I am fully understanding, but - if merchant says "I support 'basic-card', but not Amex!" - then `wallet.com` and `bobpay.com` are both potential candidates. So, the browser needs to know if it should should any of those or none. 

The original requirements haven't changed: the problem is just being potentially solved differently.   

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

-- 
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-276278691