CR Snapshot Update Request for Payment Request API

[ianbjacobs]

Document URLs

https://w3c.github.io/payment-request/
(GitHub commit 0d11184)

Link to group's decision to request transition

https://lists.w3.org/Archives/Public/public-payments-wg/2020Oct/0012.html

Link to previous Candidate Recommendation transition or update request

https://lists.w3.org/Archives/Member/chairs/2019AprJun/0035.html

Substantive changes

The following features are not supported interoperably and thus have been removed from Payment Request 1.0. They had not been identified as "at risk":

• Merchant validation. Note: This was removed because it is only used in Apple Pay. It is now described in a new informative Note; we will send a separate transition request for this.
• hasEnrolledInstrument. Note: This feature is shipping in Chromium-based browsers and for now has been moved to the living Editors' draft of Payment Request. That is: as of now it remains part of the API post version 1.0.
• allowpaymentrequest. Note: This was simply deprecated in favor of the HTML "allow" attribute, which is supported interoperably. We had mentioned moving in that direction in our March 2019 transition request [5].

Other changes:

• Remove recommendation to localize sheet based on body element
• Give AddressInit members defaults
• Disallow duplicate Payment Method Identifiers when creating request

For the full commit history, see:
https://github.com/w3c/payment-request/commits/gh-pages

[5] https://lists.w3.org/Archives/Member/chairs/2019JanMar/0154.html

Any changes in requirements?

None. However, some minor changes to dependencies:

• "Fetch" moved from an informative to a normative reference.
• The "Feature Policy" reference has been changed to "Permissions Policy"

Wide Review of substantive changes

• Because changes largely involved removing unsupported features, we did not solicit additional wide review since the previous Candidate Recommendation publication.

• We did alert horizontal review groups of our Call for Consensus to return to Candidate Recommendation.

Issues status

• Issues raised and closed for Payment Request API since December 2019:
  https://github.com/w3c/payment-request/issues?q=is%3Aissue+is%3Aclosed+created%3A%3E2019-12-12

Formal Objections

We received no new Formal Objections through the October 2020 Call for Consensus [0] to the Web Payments Working Group.

Regarding the previous objection from Sam Weiler (addressed during the previous transition request) Ralph wrote:

"[T]he Working Group should continue to work with the community
during CR on issues #842 [2] and #72 [3] to identify means for
payment methods to specify those address fields required for the
transaction, confirm whether the specified PaymentMethodData data
attribute is sufficient for carrying that information in the
basic-card payment method, and recommend good privacy practice for
consideration in other payment methods."

Following the April 2019 publication, Working Group participants, in discussion with Sam Weiler, developed a proposal to allow incremental request of billing and shipping information [4]. However, as we wrote in the Call for Consensus:

"One year later, implementations in Chromium-based browsers and
 Webkit have remained essentially unchanged. There are no
 implementer plans in the near term to address issue 842. Browser
 vendors believe that there are sufficient privacy mitigations in
 place in the current API to allow it to ship as part of the Web
 platform (as it has been for a number of years). "

At this time we are proposing to return this specific to Candidate Recommendation (en route to Recommendation), without changes to address Sam Weiler's objection. We expect to revisit the topic as part of "post 1.0" discussions.

[0] https://lists.w3.org/Archives/Public/public-payments-wg/2020Oct/0006.html
[1] https://lists.w3.org/Archives/Member/chairs/2019AprJun/0003.html
[2] w3c/payment-request#842
[3] w3c/payment-method-basic-card#72
[4] w3c/payment-request#873

Any changes in implementation information?

• Implementation report (showing Chromium and Webkit support):
  https://w3c.github.io/test-results/payment-request/all.html

• Less than two view:
  https://w3c.github.io/test-results/payment-request/less-than-2.html

• We are in the process of adjusting the test suite and regenerating
  the implementation report. We expect a "clean" implementation report
  by the time we request to advance to Proposed Recommendation.

Deadline for further comments

14 January 2021

Any changes in patent disclosures?

No.

See Requirements for updating a Candidate Recommendation Snapshot for further information.

[swickr]

hasEnrolledInstrument is not mentioned in "Changes since last publication"; I recommend you add it. The Transition Request says Basic Card is normative now, but the reference is still listed as Informative. It appears that Permissions Policy should be normative and referenced from Section 15 else that section 15 is ambiguous. The updateWith() method depends normatively on DOM; why was DOM dropped from Normative References? 3.1 needs a reference for "payment method identifier"; this was also dropped from the Normative References.

[ianbjacobs]

Hi @swickr,

You wrote:

"hasEnrolledInstrument is not mentioned in "Changes since last publication"; I recommend you add it. "

Under substantive changes I had written:

"hasEnrolledInstrument. Note: This feature is shipping in Chromium-based browsers and for now has been moved to the living Editors' draft of Payment Request. That is: as of now it remains part of the API post version 1.0."

Were you thinking I should say something else?

You wrote:

"The Transition Request says Basic Card is normative now, but the reference is still listed as Informative"

That's my error then. Apparently there's no change here and I was wrong. I will fix the transition request.

I will chat with the editors about the other references and get back to you.

Thanks!

[ianbjacobs]

Hi @swickr,

• hasEnrolledInstrument only appeared in the Editor's Draft (not a formally published TR document)
• Basic Card is not normative (my transition request has been fixed)
• The editor's draft has been updated so that there is a normative reference in section 15 to permissions policy; see edit:
  w3c/payment-request@2799b44
• The DOM spec is there as a normative reference (but as "dom" lower case):
  https://w3c.github.io/payment-request/#normative-references
• [payment-method-id] is a normative reference. There's a reference 3.1 (step 4.3.3).

Please let me know if there are any remaining issues. Thank you!
Ian

[swickr]

Transition approved.

Thanks for the clarifications.

[plehegar]

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