REC_2020_Plan

Documenting here steps (initiated in 2020 and completed in 2021) to advance Payment Request API 1.0 to Recommendation. Questions? Ian Jacobs.

Context

• Payment Request API has been implemented in two browser engines (Chromium, Webkit) for several years.
• See the implementation report and tests with fewer than 2 implementations.
• To further align the specification with implementations, see milestones for what issues we expect to resolve before progressing on the Recommendation Track.
• Because we anticipate removing a small number of features that are not implemented interoperably, per the W3C Process we expect to return to Candidate Recommendation prior to advancing to Proposed Recommendation.

Timeline

• Prior to 15 October 2020:
  • Complete milestones
  • Create interop report
  • Give heads-up to i18n groups based on their i18n issue tracking
• 15 October - 26 October: Call for Consensus to the Web Payments Working Group; see CfC email. At the same time:
  • Notify horizontal groups per guide on horizontal review. We want to allow six weeks for these groups to consider the small number of changes that we have made since the most recent substantive CR publication (PR API 12 Dec 2019). We are taking into account that TPAC is happening and groups are busy.
  • Notify public. See blog post by Ian.
• 19-22 October: WPWG meeting
  • Our agenda includes time to address some issues.
• 26-30 October: Publishing moratorium
• 27 October: Decision sent to WPWG.
• 09 November: Transition request.
  • PR API transition request
  • MerchantValidationEvent interface transition request
• 20 November: Director's Decision, assuming time was required to schedule and hold a meeting with the Director.
  • PR API approval
  • MerchantValidationEvent approval
• 30 November: Publication Request
  • Due to dependencies between the specifications, indicate to the Webmaster that PR API needs to be published first.
• 3 December: Announce Candidate Recommendation (and message to AC)
  • This triggers a 60-day exclusion period. During this time we can also start the Proposed Rec AC review.
• 8 December: Publish MerchantValidationEvent Note
• 23 December - 1 January: Publishing moratorium
• 14 January 2021: Deadline for comments

In Q2 2021 we adapted our timeline based on (1) a desire to address a previous privacy issue and (2) I18N review.

• 2 June: Call for Consensus in the WPWG to republish A CR snapshot AND ALSO (because we are only removing things) to advance to PR without another Call for Consensus (until 18 June)
• 22 June: Transition request to republish a CR snapshot.
  • This triggers a 60-day exclusion period. During this time we can also start the Proposed Rec AC review.
• 28 June: Director Approval. Request Webmaster re-publication as a CR.
• 29 June: Re-publication of the CR.
  • Note: The CR triggers a 60-day exclusion opportunity (even though we only removed features). Thus, there is a 6-week gap until requesting to advance to PR.
  • Note: During this time we will update the implementation report and less than 2.
  • Note: Turn on auto-publishing.
• 4 September: End of 60-day exclusion opportunity
• 7 September: Transition request to PR
• 13-17 September: Publishing Moratorium
• 29 September: Publication request for 30 September
• 30 September: Publication of PR and Start of AC Review
• 18-29 October: Publishing Moratorium
• 28 October: End of Advisory Committee Review
• 1 November: Transition Request to Recommendation for PR API and PMI
• 9 November: Publication of Recommendations

Note: Dates in part determined with help from the milestone calculator.

Implementation Notes

• Implementation report

Less than Two View

Notes on less than 2 view

• Does not affect interop
  • Regarding 4 allowpayment request tests: Payment Request API 1.0 deprecated allowpaymentrequest on iframes in favor of allow="payment". Payment Request in Webkit can only be used with ApplePay, but not within an iframe, so lack of support today does not affect interoperability in practice. We anticipate that should this change, feature policy would be the preferred direction.
• Bugs to be fixed
  • Regarding 1 idlharness test: The "PaymentRequest interface object length" test is checking the number of non-optional constructor arguments. To support the Digital Goods API (see issue 912), Chrome made the details parameter of the PaymentRequest constructor optional, reducing the number of non-optional arguments from 2 to 1. The fix is likely to depend on discussion of the Digital Goods API's future. This does not affect interoperability.
  • Regarding 1 payment request constructor test (duplicate PMI): This is a bug in Webkit. (Update: Apparently this was fixed!)
  • Regarding 6 show / consume tests: Chrome is known not to comply, but there are some users who depend on this behavior. The expectation is that user activation delegation will provide the desired functionality. Once available, Chrome plans to change code to bring it into compliance with Payment Request.