W3C home > Mailing lists > Public > public-payments-wg@w3.org > October 2020

Call for Consensus to publish Payment Request API as a Candidate Recommendation, and a new Note

From: Ian Jacobs <ij@w3.org>
Date: Thu, 15 Oct 2020 20:10:22 -0500
Message-Id: <57429B45-27F2-4C28-8578-A440C0AAAB5A@w3.org>
To: Web Payments Working Group <public-payments-wg@w3.org>
Dear Web Payments Working Group Participants,

This is a Call for Consensus to publish the following specification as a revised Candidate Recommendation:

  Payment Request API
  (GitHub commit 0d11184)

and to publish the following (new) Working Group Note describing a feature removed from Payment Request (see more below):

  The MerchantValidationEvent interface

  (Note: Respec errors will be resolved prior to formal publication.)

We would like to thank the editors for preparing these documents.

PLEASE RESPOND to the proposal by 26 October 2020 (17h00 UTC).

For the co-Chairs,
Ian Jacobs


Last year the Web Payments Working Group discussed (as described in
this blog post [1]) not advancing Payment Request API to Proposed
Recommendation until:

- we had gained more adoption and implementation experience, and
- we gained more experience regarding a proposal [2] for
  issue 842 [3] regarding shipping addresses and privacy.

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). 

Given the stability and interoperability of the implementations and
plans of browser vendors, we are proposing to finalize "version 1" of
Payment Request API as a W3C Recommendation, and then to continue to
work on the API, including privacy considerations and new features
(such as our discussions around Secure Payment Confirmation).

Payment Request API 1.0 is available through a number of payment
service provider libraries (e.g., Stripe and Braintree) and can be
used to make payments with Basic Card (in Chromium-based browsers),
Apple Pay, Google Pay, and Samsung Pay.

This latest draft of Payment Request API includes a small number of
substantive changes since the 12 December 2019 Candidate
Recommendation [4].  Per the W3C Process, we are returning to
Candidate Recommendation (CR) before advancing to Proposed
Recommendation. However, we do not expect to remain for very long at
CR; see our optimistic timeline for advancing to Recommendation [5].

Marcos Caceres is updating the Payment Request API test suite
accordingly. We plan to regenerate the implementation report [6] from
the updated test suite prior to any formal request to the Director to
advance the specification to Proposed Recommendation.

[1] https://www.w3.org/blog/wpwg/2019/10/28/the-evolution-of-payment-request-api/
[2] https://github.com/w3c/payment-request/pull/873
[3] https://github.com/w3c/payment-request/issues/842
[4] https://www.w3.org/TR/2019/CR-payment-request-20191212/
[5] https://github.com/w3c/payment-request/wiki/REC_2020_Plan
[6] https://w3c.github.io/test-results/payment-request/all.html

(Since 12 December 2019 Candidate Recommendation)

The following features are not supported interoperably and thus have
been removed from Payment Request 1.0:

* Merchant validation. Note: This was removed because it is only used
  in Apple Pay. It is now described in the informative Note mentioned above.
* 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 HTML's
  "allow" attribute, which is supported interoperably.

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:


That the Web Payments Working Group request that the W3C Director approve publication of Payment Request API as a Candidate Recommendation.

Please indicate one of the following in your response:

1. Support the proposal.

2. Request some changes, but support the proposal even if suggested changes are not taken into account.

3. Request some changes, and do not support the proposal unless the changes are taken into account.

4. Do not support the proposal (please provide rationale).

5. Support the consensus of the Web Payments Working Group.

6. Abstain.

We invite you to include rationale in your response.

If there is strong consensus by 26 October 2020 (17h00 UTC) for the proposal, it will carry.


* If you wish your LACK of support to publish to be conveyed to the
 Director and reviewed, please include the phrase "FORMAL OBJECTION"
 in your response and be sure to include substantive arguments or
 rationale. The W3C Director takes Formal Objections seriously, and
 therefore they typically require significant time and effort to

* We request that any Formal Objections be limited to changes made to
 Payment Request API since the 12 December 2019 Candidate Recommendation:

* Silence will be taken to mean there is no Formal Objection.

* If there are Formal Objections, the Chairs plan to contact the
 individual(s) who made them to see whether there are changes that
 would address the concern and increase consensus to publish.

For more information, see:

Transition Request Following a Working Group Decision to Publish

* In the case where this Call for Consensus results in a decision to
 publish, the Chairs will request approval from the W3C Director to
 publish Candidate Recommendations (including review of any Formal

* See the optimistic timeline to Recommendation:

Ian Jacobs <ij@w3.org>
Tel: +1 718 260 9447
Received on Friday, 16 October 2020 01:10:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 16 October 2020 01:10:27 UTC