PaymentRequestFAQ

Status: This FAQ is no longer maintained and may no longer be accurate. Please instead visit the FAQ on the Payment Request API developer portal.

This (now historical) FAQ was created to accompany the First Public Working Draft (on 21 April 2016) of several specifications related to the Payment Request API from the Web Payments Working Group. Questions? Please write to public-webpayments-wg@w3.org. See also the previous Web Payments Working Group Charter FAQ.

Questions about Payment Request API

What specifications did the Web Payments Working Group publish?

• Payment Request API: This specification describes a user agent API (aka browser API) to allow merchants (i.e., web sites selling physical or digital goods) to easily accept payments from different payment methods with minimal integration. User agents will facilitate the payment flow between merchant and user.
• Payment Method Identifiers: This document defines payment identifier strings and how they are created.
• Basic Card Payment: This specification describes the data formats used by the Payment Request API to support payment by payment cards such as credit or debit cards.

Who is participating in this work?

Please see the list of participating organizations.

What problems do the set of specifications address?

Making purchases on the web, particularly on mobile, can be a frustrating experience for people. Every web site has its own flow and its own validation rules, and most require us to manually type in the same set of information over and over again. Likewise, it is difficult and time consuming for developers to create good checkout flows that support various payment schemes.

What is the relationship of this work to requestAutocomplete?

The requestAutocomplete() method (aka rAC), a part of the autofill mechanism defined in the HTML specification, was designed to address use cases similar to the core part of the Payment Request API. However, along with the fact that rAC has not been adopted by implementers other than Chrome, rAC is limited in a number of ways compared to the Payment Request API:

• rAC is limited to credit card scenarios (and thus only works with form fields)
• rAC cannot collect a system-level payment mechanism from newer systems like Apple Pay
• rAC was not designed for integration with financial systems or third party software

The Payment Request API endeavors to address these limitations and offer additional functionality.

How will users experience the future standards?

The group's editors' drafts include an overview of the anticipated user experience.

What are the scenarios where people can use the API?

The API can be used in any scenario where someone (e.g., a merchant, an app developer, an individual) wishes to request payment from the user.

What payment methods does the API support?

The API is intended to support a large number of payment methods. The Working Group's flows task force is working to ensure that the API will work for widely deployed and emerging payment methods.

How do I make the API work with payment method X?

To use a payment method with this API, the following information will be required:

• One or more identifiers for that payment method; see the Payment Method Identifier specification.
• Descriptions of what data will be carried by the Payment Request API through the payment request and response.

The Working Group's Basic Card Payment specification illustrates how to write a specification for a payment method. The Working Group anticipates publishing such specifications for a variety of payment methods, but others may also publish their own payment method specifications.

For more information about payment methods in discussion by the Working Group, see the Working Group's flows task force wiki.

Questions about Publication

What does First Public Working Draft Mean?

The W3C Recommendation Track Process describes the steps and requirements to advance from First Public Working Draft to final Recommendation.

First Public Working Drafts are generally incomplete and do not yet represent Working Group consensus. W3C publishes them to encourage early review and feedback on the general direction of the work.

What are the open issues the Working Group will address?

Please see the Payment Request API issues list. Markers in the draft specifications also refer to these issues.

How can I provide feedback on the specifications?

You can raise issues in the group's GitHub issue tracker.

Alternatively, you can e-mail comments to public-payments-wg@w3.org, a mailing list with a public archive.

Questions about Schedule

When will we see implementations?

We expect early implementations before the end of 2016. Broader adoption will require additional time.

When will the specifications be finalized as W3C Recommendations?

The Working Group charter sets the expectation that the Recommendations will be published in November 2017.

General Questions about the Web Payments Working Group

Are these the only deliverables of the Web Payments Working Group?

No. The Working Group anticipates publishing additional specifications to complete this set around the Payment Request API. The Working Group expects to develop additional payment method specifications for a variety of payment methods (beyond basic card payments), as well as a test suite to promote interoperability.

In addition, per its charter, the Working Group anticipates working on an HTTP API for payments.

Who will benefit from these standards?

Customers will benefit from streamlined checkout across Web sites, and a consistent experience across devices (especially mobile).

The ultimate goal is to solve those problems for customers—and to help others solve those problems for customers.

So, in solving those problems for customers, there are also a number of direct and indirect benefits primarily to merchants, Web developers, and payment services providers. We also expect there to be secondary benefits for banks, mobile network operators, and other parties. For example:

• For merchants, standards for representing information about payment instruments accepted by the merchant and available to the customer will make it possible for merchants to more easily support large numbers of payment systems without jeopardizing the customer's payment experience. In turn, streamlined payment flow and improved customer experience should contribute to reducing cart abandonment rates.
• For developers, checkout flows are traditionally complex and require many hours of development time to correctly implement. A standard payment API will allow developers to integrate purchase flows into their web applications or sites more quickly, avoid building complex forms, and add payment methods to checkout more easily.
• Because it will be easier to bring new payment methods to the Web, all parties should benefit from easier adoption of more secure payment methods (e.g., tokenization).
• In the longer term, it should become more practical to use payment instruments that are complex to use but have very low (or zero fees) to make micro-payments for on-demand services.