Re: [w3ctag/spec-reviews] Web Payments Working Group Specifications (#152)

Thanks, Travis!

> In PaymentRequest(methodData, details, options) constructor MUST act as follows Step 5 throws if total.amount.value is negative. Can't the merchant push a negative (return) transaction? (Same with 10.2.2.1.3).

Nope, no negatives. We don't support refunds, which is effectively what a negative payment is. Things get all kinds of complicated in refund-land, so we thought best to avoid it for now.

> currencySystem - I read the current spec as the user agent doesn't validate this in any way, but passes along this string to a payment app as part of the payment app matching process. At what point would a bogus value fail?

Good question. I suppose never. Note that we'll be marking currency systems as "at risk" for CR.

>  I'm not sure I follow--show is the API to trigger the UI--before that paymentMethods dictionary is provided in the PaymentRequest constructor, and the canMakePayment is accessible independently of show--so how is this actually mitigated?

So there are two ways to determine if a user has an available payment method. The first is to just call .show(). If that doesn't throw, a UI is shown, and that means the user has an available way to pay. This makes it a poor "attack" vector since you can't keep iterating through forms of payment if the UI is shown.

Before calling .show(), however, you can call canMakePayment to determine if a form of payment is available *before* calling .show(). This gives merchants more flexibility on the UI side. For this, we say in the spec: "Optionally, at the user agent's discretion, return a promise rejected with a "QuotaExceededError" DOMException." The idea here is that user agents can, themselves, figure out the best way to address the risk of fingerprinting exposed by canMakePayments.

I'll file bugs for some of the other issues.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/152#issuecomment-291319821