- 1 Introduction
- 2 Status Summary
- 3 Development
- 4 Quality Assurance
- 5 Project Members
- 6 Discussion
- 7 References
The Payment Request API makes online purchases easier without having to fill in all of the personal and payment information over and over again. Together with the form autofill feature, it saves user's time and effort when making online purchases by storing their personal and payment information in Firefox to be used when a merchant requests payment. The Payment Request UI provides consistency across merchant sites.
The overall objective is to increase user engagement, satisfaction, and retention for frequent online shoppers. We believe this can be achieved by enabling users to complete forms and “check out” in e-commerce flows as quickly and securely as possible.
The W3C PaymentRequest API is currently in draft stage and has momentum. The API is extensible to any payment source without requiring the browser to be Payment Card Industry (PCI) compliant.
Development Update - Milestones 1 - 3 Delivery
Below is a weekly engineering development update.
May 21 Update
- Status: Green - In Development.
- Team is currently working on Iteration #4 which runs from May 14 - May 25.
- A cumulative completion of 20 bugs is required by the conclusion of Iteration #4 to remain on schedule.
- Team has, to date, a cumulative completion of 26 bugs for Iteration #4.
- Team has completed 74% of the entire Milestone 1 - 3 Backlog.
- The forecast completion of the entire Milestone 1 - 3 Backlog is on August 17.
- View Project Tracking Dashboard for current schedule progress and backlog.
Work Currently In Development
|1408234||P1||PaymentRequestService doesn't clear requests from closed documents||ASSIGNED||EdenChuang(ChenYu Chuang)|
|1420853||P1||Ensure only fields valid for the given country are saved||ASSIGNED||Scott Wu [:scottwu]|
|1429260||P1||Handle request changes with updateWith - verify that state stays consistent||ASSIGNED||Sam Foster [:sfoster]|
|1435892||P1||Implement the basic first-time-use wizard state logic and footer buttons||ASSIGNED||:prathiksha|
|1461477||P1||Duplicate implementations of the Luhn algorithm exist in the tree||ASSIGNED||Jared Wein [:jaws] (please needinfo? me)|
|1462461||P1||Show the back button in the basic card page during on-boarding||ASSIGNED||:prathiksha|
|1462779||P1||Show the billing address page on on-boarding when requestShipping is false and there are no saved addresses||ASSIGNED||:prathiksha|
|1463608||P1||Required `name` property is missing on temporary PR addresses||ASSIGNED||Sam Foster [:sfoster]|
8 Total; 8 Open (100%); 0 Resolved (0%); 0 Verified (0%);
Work Available in Backlog
12 Total; 12 Open (100%); 0 Resolved (0%); 0 Verified (0%);
72 Total; 0 Open (0%); 71 Resolved (98.61%); 1 Verified (1.39%);
Tentative plan for 2018’H2
- Frontend: Basic card UI implementation. Known dependencies include:
- 1. (Completed) UX design reiteration V1.7: Jacqueline. (see also: Web Payment - Basic Card (MVP) design doc.
- 2. Front-end Resources: 3 Engineers
- 3. (Confirmed) Reviewer’s availability: MattN
- 4. (Confirmed) No other feature dependency (e.g., Any Lockbox dependency?)
- 5. (Confirmed) Compliance for Basic card UI (or that’s only for Payment Handler?)? e.g., PA-DSS by PA-QSA
- Platform: Ensure Payment Request APIs “ready to enable” (disable until FE ready) in Q3
- API Compat. test coverage / compliance
- Basic card spec. implementation
- (Q3 and more) Marcos keeps working on W3C spec of both the Payment Handler/Request
- (Q3 and more) Bridging UI and the Request API (subject to FE’s actual progress), including 2 parts:
- Connecting UI: ongoing and will complete in Q3;
- IntegrationL requires FE completion to start (e.g., fix bugs during UI integration and verification on merchant website like WooCommerce).
Achievement in 2017'H1
- (Done) Payment Request API development.
- (Done) User research of Payment Request (Basic Card) UX.
- (Done) Payment Request Handler API Proposal. It's been merged into the renamed Payment "Handler" API (was the Payment "App" API) spec.
- Bugzilla Component: Firefox :: WebPayments UI (file a bug)
- Front-end Work Breakdown
- Privacy & Security Considerations
- Developer Documentation
- End-to-end test with valid user data and merchant update/change events, no Fx validation, generic merchant error string, only already stored cards/addresses
- add/edit screens, only basic validation (e.g. non-empty) and address-field-specific merchant-provided errors
- FTU, data validation & error recovery, "update" badge, telemetry, ready to enable on fx63 Nightly-only / Partner / End-to-end User Testing (not riding the trains)
- Tab modal widget (maybe do in parallel), UI feature complete, ready for release users, Visual Polish, cc logos
- Ride the trains
See Firefox/Features/Web_Payments/DOM for more info.
- Bugzilla Component: DOM: Web Payments
- Intent to Implement
- Platform implementation Architecture
- TBD. The pure API development in H1 doesn't require QA involvement (UI level verification). We will have unit/autotest instead.
- Product: Cindy Hsiang
- User Experience: Jacqueline Savory (UX), Erin Pang (VisD)
- User Research: Sharon Bautista
- Front-End Engineering: Justin Dolske, Matthew Noorenberghe (Tech Lead), Jared Wein, Samuel Foster
- Platform Engineering: Marcos Caceres, Peter Saint-Andre
- Program Management: Jean Gong
- Product: Jeff Griffiths
- User Experience: Jacqueline Savory (UX)
- Engineering: Justin Dolske, Matthew Noorenberghe (Tech Lead), Marcos Caceres (Architect), Jared Wein, Samuel Foster
- Program Management: Jean Gong
- Product: Joe Cheng
- User Experience: Juwei Huang (UX), Fang Shih (Visual)
- Engineering: Marcos Caceres (Architect), Ben Tian (TDC Tech Lead), Alphan Chen, Eden Chuang, Matthew Noorenberghe (Front-end oversight)
- Program Management: Wesly Huang
- IRC: #payments
- Weekly Meeting Notes
- Web Payments Mailing list: email@example.com
- Auto Fill Public Mailing list: firstname.lastname@example.org