Add canMakePayment() method

[domenic]

This closes #310, and closes #316 (which it is roughly based on), and closes #367 by intentionally allowing user agent leeway in restricting repeated calls to canMakePayment().

---

The main difference from #316 is in allowing user agents maximum flexibility in protecting against fingerprinting, instead of trying to prescribe an algorithm for doing so. It also contains a number of fixes to the algorithm.

[adrianba]

I think this is fine to merge but we should add a note to the spec explaining that "supports" in the canMakePayment case may be different from "supports" in the show() case, because some implementations may only return true if there are payment credientials stored.

[burdges]

I'd do think "returns true" should be considered a valid algorithm for browsers that seek to provide maximum security, although the InvalidStateError makes sense, so it's not literally "always true" I guess.

[rsolomakhin]

@domenic: Excellent patch! Thank you for sending this in.

@adrianba: +1 to distinguish "supports" of .canMakePayment() and .show().

@burdges: I don't quite follow about maximum security. Can you elaborate?

[domenic]

Thanks @rsolomakhin! @adrianba and @rsolomakhin, for clarifying "supports", probably that is best done on top of #382, which itself clarifies "supports" for show(). I can work on something, although I'm building up quite the dependency list of unmerged PRs :)

[burdges]

There is an unacceptable risk to the user's privacy here @rsolomakhin so a browser that wishes to protect the user's privacy must prevent .canMakePayment() from returning any information.

There are two heavy handed ways browsers could do this, either disable the payments API all together, or disable all payment methods except one the Browser vender chooses, ala the Brave project's in-browser payments.

Instead, we should provide a less heavy handed route whereby a browser can effectively disable .canMakePayment() in some way so that many merchants still work. There are several options :

• .canMakePayment() invokes .show() immediately.
• .canMakePayment() always returns false, so merchants who call it cannot use the payment API.
• .canMakePayment() always returns true, possibly resulting in customers seeing the wrong invocation.
• .canMakePayment() throws an exception indicating that it detected an attack on the user by the page. This would happen if the page called .canMakePayment() too many times, but a more secure browser could simply do it anytime .canMakePayment() gets called. Ideally, the browser should warn the user that the page did something nefarious.

[domenic]

@burdges I think several of your suggestions are already implemented by https://w3c.github.io/browser-payment-api/#canmakepayment-method :

• step 3 allows returning a rejected promise with QuotaExceededError (your 4)
• step 6.1, modulo some above-mentioned ambiguity in the definition of "supports", allows always returning false or true (your 2 and 3)

I don't think your 1 is a good idea, as asking if you can make a payment should not show a payment; that defeats the purpose of the API.

[burdges]

I missed this conversation over "supports", sounds good.