Overview

• Feature Set
• Implementations
• Implementation Report
• New Feature Request
• Schedule

Feature Set

• Payment Request 1.0 feature set has been stable since April 2019 Candidate Recommendation
• Strong support at 5 September teleconference to freeze 1.0 feature set ... except possibly for one privacy enhancement

Implementations in Browsers

• Chromium-based: Chrome, Edge, Samsung Internet
• Webkit-based: Safari (for Apple Pay only)
• Mozilla continues to edit the spec; awaiting update re: support for Payment Request
• See Can I Use? table

Also supported in various PSP SDKs, including Stripe, Braintree, WePay, Bluesnap, Paysafe, BS Payone

Implementation Report

• To advance to Proposed Rec need 2 implementations of each feature
• Full implementation report
• Tests with fewer than 2 implementations (between Chromium and Webkit):
  • One Chrome issue relates to feature policy rather than PR API
  • Ignore tests for 1.1 features
  • Allowpaymentrequest-timing is a feature policy bug in Chrome
  • Ignore obsolete tests (where nobody shown to pass)
• One implementation update away for current feature set

New Feature Request

• We have a proposal to address a Formal Objection
• PR API would support incremental and piecemeal request for shipping address information.
• We have also heard a request to extend this to billing address. Do so would likely involve changes to Payment Handler API and Basic Card (see issue 72).
• If we choose to include this feature in Payment Request 1.0, it would likely mean 8 months to Rec (based on Chrome team estimate).

Schedule

• Dependencies:
  • Webkit update related to issue 813
  • Decision to include additional feature, followed by specification and implementation
• Rec without new feature: mid-November 2019
• Rec complete with new feature: July 2020

What opportunities might we miss by waiting until mid-2020?