Payment Request API (call for wide review)

[sandandsnow]

The Web Payments Working Group made a call for wide review on 2 December 2020.

Spec: https://www.w3.org/TR/2020/CR-payment-request-20201203/

The document was published as a Candidate Recommendation Snapshot.

Reported changes since the last publication:
Changes since last publication

Substantive changes to the Payment Request API since the 9 July 2018 version are as follows. The complete list of changes, including all editorial changes, is viewable in the commit history. Key set of changes are viewable in the Changelog.

• Added support for notification when the user selects a payment handler, but before confirming payment. This allows merchant to update totals, validate acceptance, etc.
• Added support to notify site of billing address selection. This allows a merchant to update a total (e.g., for VAT in Europe). To enhance privacy, only some billing address data is returned to the merchant as long as the user has not confirmed payment.
• Added support for retry() and fine-grain error reporting to the user.
• Clearer definition of canMakePayment() and worked to align implementations. canMakePayment() does not reveal whether payment handler is primed to pay.
• Removed languageCode and regionCode from PaymentAddress.
• Removed currencySystem.
• "Payment request is showing" boolean now attached to top-level browsing context. Previously, only a single payment UI was allowed to be shown at a time across the whole browser. This now allows multiple browser tabs to show a payment UI at the same time (for those payment handlers able to support it).
• Integrated with Permissions Policy.
• Defined handling of multiple applicable modifiers.
• Removed support for merchant validation because of lack of multi-implementer support.
• Deprecated allowpaymentrequest attribute.
• Calling show() now consumes the user activation.

[sandandsnow]

Additional information provided by the WG regarding the review:

"PaymentRequest differs from other Web APIs because it is just an empty interface which depends on actual payment applications (implementations) which are unknown. As an example I use the PaymentRequest [*] for Android scheme which permit you to build native mode payments Apps that are callable from the Web. Google Pay and Apple Pay utilize the same scheme. Such Apps have access to all user-mode functions and data supported by the Operating System (and accepted by the user during installation).

What it means from a review point of view is that the API does not tell you the full story about privacy and nothing at all about security since the latter is not a part of the API.

The ability to thwart "fingerprinting" is probably the only measurable part of the API.

[*] https://cyberphone.github.io/doc/web/calling-apps-from-the-web.pdf"

[samuelweiler]

I think there is another thing we can evaluate: we can evaluate is whether the structure of the API allows for meaningful minimization in the sharing of information or whether, by its structure, it forces "oversharing". See w3c/payment-request#842 (comment)

Also, the person who provided the above appears to not be a member of the Web Payments WG, so I'm not sure if the statement above actually comes from the WG.

[sandandsnow]

Review discussed on PING call on 21 January 2020

Go to https://github.com/w3cping/tracking-issues/issues to track the progress of any issues raised as a result of the privacy review

[sandandsnow]

Closing issue as the review has been undertaken.

(Note: there may still be outstanding privacy considerations identified in the review that have not yet been resolved.)