Today W3C announced the report of the Web Payments Working Group Patent Advisory Group (PAG). After analysis of the disclosed patents, the PAG recommended that the Working Group continue its work.
“We are long overdue for a payments user interface for the web.”
—Tim Berners-Lee, New York Times, 25 September 2016
The new payments user interface for the Web gained significant traction in 2016. Browser vendors have been implementing the Payment Request API and supporting specifications to make it easier to pay on e-commerce sites. In the past two months we've seen a spike in detailed comments on the specification from Web technology gurus and a flurry of improvements to achieve interoperability, including alignment with other technologies of the Open Web platform. Our progress is such that we anticipate inviting wider review of the Payment Request API specification in January, as a prerequisite for advancing to Candidate Recommendation. We are simultaneously developing a test suite and preparing for conversations about how to encourage merchant adoption.
A significant focus of the Working Group to date has been to make card payments easier within the browser. We have also made progress on topics relevant to other payment apps and other payment methods, including:
- Third-party payment apps. Payment Request API provides a standard way to initiate payment requests from Web pages and applications. User agents implementing that API prompt the user to select a way to handle the payment request, after which the user agent returns a payment response to the originating site. But Payment Request API does not include support for third-party payment apps: software that runs outside the browser that enables users to pay. Browser vendors are already working on mechanisms to enable integration of native mobile payment apps into the ecosystem. In addition, a task force of the Web Payments Working Group has made significant progress on a Payment App API for Web-based payment apps. Implementers are already experimenting with the early draft of the specification and providing feedback. I anticipate that the Working Group will consider taking this on as a formal work item by early February 2017.
- Push payments. Push payment methods —where the payer initiates payment processing, unlike payee-initiated methods such as credit cards— raise interesting questions about handling failure modes such as network outages. To facilitate reconciliation between merchants and payment services, we have introduced a “paymentRequestID” into the Payment Request API.
- canMakePayments(). To create a seamless checkout experience, merchants would like to maximize the chances that a particular user experience will lead to success. Users do not want to follow a path to payment that ends in frustration. We are working on a feature that enables merchants to query whether a user is “ready to pay” with a particular payment method, which will enable the merchant to fine-tune the checkout experience. We are still investigating the balance between merchant goals with user privacy goals.
- Payment method manifest files. The group’s expectation is that when someone publishes a new payment method and identifies it with a URL, that there also be machine readable information discoverable from that URL. We have begun work on a Payment Method Manifest Specification to describe what information browsers can use to improve security around payment apps that support a payment method.
- Payment methods beyond basic card. For most of 2016 we focused on using Payment Request API with traditional card payments, where raw card information is returned via an API instead of a Web form. We kept on the back burner two other payment method specifications that could make it easier to bring more payment methods to the Web: credit transfers and tokenized card payments. I anticipate both of those to progress in early 2017. Along the way we are also taking notes on payment method good practices.
- Out of browser payments. Although our focus in 2016 has been on in-browser payments, we have laid the groundwork for discussions in 2017 about out-of-browser payments such as automated payments from other types of software or Internet of Things use cases. We published early drafts of Web Payments HTTP API 1.0 and Web Payments HTTP Messages 1.0 in 2016 and I expect we will return to them once Payment Request API has advanced and stabilized.
We saw a promising increase in participation in the Working Group in 2016, as well as growing awareness within the industry about the work at events such as Money 20/20 2016 and The Point 2016 and to the NACHA Payments Innovation Alliance. We have also begun to engage more actively with a number of other bodies, including EMVCo, PCI Security Standards Council, ISO 20022 RMG, Payments NZ, ITU-T, Smart Card Alliance, US Payments Forum, Global Platform, and others.
The Working Group will hold its next face-to-face meeting in March 2017. I encourage organizations that wish to join the Working Group to do so in time to participate in that meeting.
I look forward to 2017 as a big year for streamlining Web payments. Thank you to the Working Group for all of their good work to date!
The Web Payments Working Group held a productive face-to-face meeting in Lisbon in September; see 19 Sep and 20 Sep minutes. At the end of the meeting we articulated some priorities for the next few weeks:
- Close issues related to payment request API and payment method identifiers. Flesh out the test suite.
- Get review of the payment apps specification with an eye toward advancing the specification to First Public Working Draft.
- Develop a proposal about how to use payment request API with push payment methods.
- Publish a First Public Working Draft of an overview document describing the group’s deliverables.
Our expectation is to review where we are at the end of October and determine whether we are in a good position to advance payment request API and supporting specifications to Candidate Recommendation.
Many thanks to Adam Roach for his photo of the group meeting.
TPAC, W3C’s annual big meeting of groups, takes place in Lisbon next week. The Web Payments Working Group will be among the 500-600 participants expected this year. The Working Group has been busy since our London meeting in July, so our agenda is a full one and includes:
- Discussion of issues necessary to advance the payment request API suite to Candidate Recommendation.
- Payment apps, and whether to advance the Editor’s draft to First Public Working Draft
- Implementer experience and demos from Google, Samsung, and more. We’ll also hear about progress on a test suite.
- Lots of discussion of payment methods including updates to basic card, SEPA credit transfer, cash on delivery, invoice, 360 Pay (from Qihoo 360), and a draft tokenized payment method specification from Facebook. We have a very early draft of a payment method good practices document that we should be able to expand based on the growing set of payment methods in discussion. We will also be looking at push payment methods generally, to determine how push payments could be made easier through the payment request API.
- Next steps for the recently published First Public Working Drafts of Web Payments HTTP API 1.0 and Web Payments HTTP Messages 1.0
A few days after the Brexit vote, I traveled to London for a face-to-face meeting of the Web Payments Working Group. I was unsure what chaos I would find. Friends suggested I might find great deals due to currency devaluation. I found neither chaos nor deals, mostly because I was in meetings nearly the entire trip. But the shock of the outcome was palpable, mostly as uncomfortable humor.
On the other hand, I felt the mood in our meeting was largely optimistic. In particular:
- New people from a growing set of organizations signed up to do work. I took this “diversification” as a good sign of traction and investment.
- We also heard more about implementations, another good sign of traction (and source of insight about the work). One takeaway is that some of the browser makers have indicated their expectation that the payment request API would be available in browsers for the Q4 2016 holiday (shopping) season.
Here were a few other key topics we covered during the meetings:
- The payment request API provides a core functionality that involves matching merchant-accepted payment methods with user-provided credentials, but it does not itself include support for third party payment apps. Those are apps that we expect banks, retailers, mobile operators, card networks, and others to provide so that users can store credentials and make payments alongside value-added services. To add third-party payment apps to the ecosystem, the Working Group agreed to work on Payment Apps API, which is still very drafty. We have many open questions about registration, selection, display, and launch of these apps, as well as how to ensure the best possible user experience so that merchants will have confidence that apps will help increase conversions.
- Several participants reported on their security review of three WG specifications; this prompted a call for further security review, and several people volunteered to ask their organizations to commit to those reviews.
- One of the ways that we have sought to validate the usefulness of this approach for “real world payment systems” has been to document the information flows of those systems and the inputs and outputs we would expect from a payment app that supports them. In addition to the “Basic Card” payment method specification we published in April, we discussed SEPA Credit Transfer, Alipay, and Samsung Pay at the face-to-face meeting. One design goal is to make it possible for anybody to publish a payment method description to tell people how to use that payment method with the payment request API. We realized the need to provide some good practice suggestions for people who want to create payment method documentation.
- We also began to look at and take up specifications for payments outside the browser (e.g., in an Internet of Things context). (We had previously resolved that this work, in scope for the Working Group, would have a lower priority than the browser APIs.)
While I felt good about our progress, we definitely have more work to do, to close issues around payment request API, to develop a test framework, to build a shared understanding about how third-party payment apps will work, and to figure out how to bootstrap the ecosystem. In particular, we need to ensure that the user experience is as simple as possible, and that merchants have sufficient motivation and confidence to adopt the API.
The group meets next in Lisbon in September, during W3C’s annual TPAC meeting. At that meeting I hope that we will have the pieces in place to advance payment request API to Candidate Recommendation, that will see some advanced demos, and that we’ll have a solid payment app specification that the entire group can support.
For additional personal insights from co-Chair Adrian Hope-Bailie, see his post Reflecting on the W3C Web Payments WG.
Photo Copyright Adam Roach
Today we announced the July 7-8 Face-to-Face meeting of the Web Payments Working Group, in London, hosted by Visa Europe. We’ll be building the agenda over the next few weeks.
The following FTF meeting of the group will be the week of 9 September in Lisbon at TPAC 2016.
The mission of the Web Payments Working Group is to make payments easier and more secure on the Web. Today the Web Payments Working Group published first drafts of specifications in pursuit of this mission:
- Payment Request API: This specification describes a web 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 (e.g. browsers) will facilitate the payment flow between merchant and user.
- Payment Method Identifiers: This document defines payment method identifier strings so that components in the payment ecosystem can determine which parties support which payment methods.
- 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.
We have also published a FAQ today, and will update it as we receive questions from the community.
Although the Web Payments Working Group has begun to discuss payment application registration, we have not yet adopted a specification for this important piece of the Payment Request API suite (though there is an early proposal).
Together, these specifications will help streamline checkout in Web sites and applications. The Working Group is revising a description of how the pieces fit together and I anticipate an updated “overview” soon.
Important: These are early, incomplete drafts! We recognize that people not previously involved with W3C may be accustomed to specifications being more “mature” when they are first made public. In the W3C Process, “First Public Working Draft” does not mean that the specifications are publicly available for the first time; Editors’ Drafts are always public. Rather, it is a call for early review by the Working Group to the broader community.
In addition to hearing general feedback such as “yes, this seems like a useful overall direction” the group has a number of specific issues where we would like input, covering topics including:
- Extensibility and versioning
- Security and Privacy
- How much functionality to include in the API
Issues are sprinkled throughout the documents and are being managed in the group’s issues lists (one general, and one specific to these documents). As you read the documents, we invite your comments on the issues, or you may wish to raise new issues. Please see the status section of each specification for information about how to provide feedback.
After First Public Working Draft, the Editors will incorporate Working Group resolutions into the evolving Editors’ Drafts.
In parallel, we are also studying in detail how the API will be used to addressed common payment methods. The Working Group is documenting “real-world” payment flows for payment methods such as credit cards, credit cards with 3DS, tokenized cards, SEPA credit transfers, Bitcoin, Alipay, and others. For each flow, the group expects to show how the Payment Request API fits into these payment flows. We also expect this detailed investigation to inform developer guidance on how to use the API in different scenarios and how to plan corresponding payment apps. We also expect the flows will inform our test suite development.
We welcome assistance from the community to help us document common payment flows, both those we have started to analyze and any others you feel we should address. Please see the flows home page if you wish to help.
The Working Group is currently focused on advancing the Payment Request API suite, but is also chartered to facilitate payments outside of the browser (e.g., via an HTTP API). We expect to turn our attention to that work shortly.
Today’s publications represent an important milestone for the Working Group, but we have a lot more to do to develop, test, and deploy the new API. We welcome your feedback and your help in our effort to make Web payments easier and more secure.
The Web Payments Working Group held its second face-to-face meeting at Google last week. For several months, the Working Group has been reviewing two proposals: one from the Web Payments Community Group and one from the Web Incubator Community Group. The primary goal of the meeting was to determine how turn two proposals into a single path to First Public Working Draft (FPWD). After several hours of demos, code reviews, and discussion on the first day of the meeting, we resolved to base the FPWD on the Payment Request API proposal from the Web Incubator Community Group, authored by participants from Microsoft and Google.
The decision was not easy. Both proposals have merits and supporters. Fortunately, through face-to-face time and GitHub discussions in the weeks leading up to the meeting, the differences between the proposals grew smaller and smaller. We have not resolved all of the issues, so we plan to include clear issue markers in the FPWD, currently scheduled for early April. We will invite feedback from merchants, payment service providers, developers, and other stakeholders to help us resolve these issues.
How the API Could Work
The focus of this API is to streamline checkout and help reduce shopping cart abandonment. Checkout experiences differ from site to site, require sharing the same information over and over again, frequently require many (often confusing) steps, and can be cumbersome on mobile devices. This API should make it easier and faster to pay, on desktop as well as mobile, through a harmonized experience across sites. Below I say a bit more about other deliverables from the group to improve Web payments.
Here is my current synthesis of how the standards could work. I say could because there is not yet consensus on all these points. Though preliminary and incomplete, this description should give a sense of our direction and the origin of some issues.
- At the end of shopping on a merchant site, the user pushes the “buy” button.
- The merchant site calls the payment API with purchase amount, currency, accepted payment methods (e.g., Visa, Paypal, Bitcoin), and any custom data for those payment methods.
- The browser determines the intersection of merchant-accepted payment methods and user-registered payment methods (more on that in a moment). The merchant can (optionally) use the API to capture shipping information through the same user experience.
- The user selects a payment app to pay, and carries out any app-supported activities as needed, such as authentication.
- Assuming the payment is authorized, the payment app returns payment method-specific data through the browser to the merchant site.
- Depending on the payment method, this data will either enable the merchant to be paid, or signal that the merchant has already been paid.
Hot Concepts and Topics
It’s worth calling out a few concepts that are in discussion and some related issues:
- Users will pay with “payment app” software. Banks, merchants, mobile operators, and anyone else who wants to will make these available. Browsers are also likely to act as basic payment apps, storing some information on behalf of the user, as they already do today with passwords. We expect payment apps will increase security and privacy by giving users more control over what they share over the network. Payment apps will distinguish themselves through the features and services they provide beyond the standard API, such as strong user authentication, loyalty program integration, back-channel communications with the merchant for fraud analytics, and so on. Payment apps should be able to run on desktops, mobile devices, televisions and so on, but there are likely to be challenges in achieving that level of interoperability.
- Each payment app will support one or more payment methods. We are designing the API to support the broadest possible array of payment methods. When a merchant accepts a given payment method, the assumption is that the merchant will know how to process the data returned by the payment app for that payment method. We are likely to seek to increase interoperability by standardizing some payment method response data. For example, There is an early draft of a basic card specification that describes what information merchants should expect to receive for a credit card payment.
- Each payment method will also have an associated identifier that will be used, for example, to compute the merchant/user intersection. The group has not yet resolved the syntax of payment method identifiers and other related issues.
- Users will register payment apps with browsers. Through registration, browsers will know which payment methods are available on the user side. We have only just begun to discuss some of the challenges associated with registration. The API will not involve sharing the user’s list of registered payment methods with the merchant.
- For a given payment method within a payment app, a user may have multiple payment instruments (e.g., a personal credit card and a business credit card, or multiple Bitcoin accounts).
Over the next couple of months the Working Group will establish the limits of version 1 of the API. This means that some payment functionality will need to be handled by the merchant site or a payment app, at least for the short term. The group plans to keep version 1 “minimalist,” but we still have to determine just how small it will be. We want to include enough so that merchants (and their payment service providers) have sufficient incentives to adopt the API. For example, we have resolved that version 1 will support the capture of shipping information. But we are also discussing whether to include a flag to indicate a recurring payment, a flag to enable payment initiation even when the final amount is not yet known (e.g., a taxi service or hotel reservation), and whether to enable capture of some billing information to enable VAT or other tax computations on the merchant side. We plan to seek input on these issues.
We also have technical choices ahead of us, such as how to manage communications among the various parties (e.g., using events, promises, or call-backs), and how the API will support extensibility and versioning.
We enjoyed solid participation by Web Payments Working Group participants last week, including Apple, Bloomberg, BPCE, Canton Consulting, China Mobile, Deutsche Telekom, Digital Bazaar, Federal Reserve Bank of Minneapolis, Google, IBM, INRIA, ISO 20022 Registration Authority, Knowbility, Lyra Network, Microsoft, Mozilla, NACS, NIC.br, Opera, PayGate, Ripple, Visa Europe, and Worldpay. A number of guests also attended in person or by phone with additional perspectives: Capital One, DDS, Facebook, Gemalto, Intel, Netflix, Samsung, Square, and Visa.
Though we have strong representation from parts of the industry, but need greater diversity (including participation from more parts of the planet) to produce a useful API. We also need more participation because we have a lot of work to do. We need to advance the browser API specifications in order to meet our goal of early implementations before the end of 2016. Beyond the browser API and its companion specifications, we are starting to discuss developer guides on how to write Web apps (that use the API) or payment apps that support different payment methods. We will also develop a test suite for the API to promote broad interoperability. Lastly, we are chartered to develop an API for payment requests outside the browser (e.g., via HTTP or some other mechanism) for use cases such as Internet of Things payments. We will begin to focus on that work by the middle of 2016. Please contact me if you’d like to help the Web Payments Working Group make Web payments easier and more secure.
We invite you to join the new Web Payments Working Group, launched 21 October 2015. From the press release:
[The standards from this group] will support a wide array of existing and future payment methods, including debit, credit, mobile payment systems, escrow, and bitcoin and other distributed ledger technologies. Standardized APIs (Application Programming Interfaces) will establish a foundation for simplified checkout and payment experience, greater transaction security, automated secure payments, and more payment options for merchants and users alike. These APIs will allow users to register payment instruments (such as credit cards or payment services) and select the right payment type through the browser, making payments faster, more secure, and easier, particularly on mobile devices.
Here’s how to get involved and help improve payments on the Web!
How to Participate
The technical discussion for the Web Payments WG will center around the mailing list, firstname.lastname@example.org (archive), including minutes from weekly teleconferences and face-to-face meetings. The public may join the open technical discussions on the mailing list, though all input on the list should remain focused on the group’s agenda. Teleconferences and face-to-face meetings, as well as group decisions, are reserved for Working Group participants.
If you wish to join the Web Payments Working Group, there are 2 paths: joining as a W3C Member, or becoming an Invited Expert.
W3C Members fund the work of the group, and typically provide active resources and direct implementation experience. If you’re affiliated with a W3C Member organization:
- (If you don’t have any W3C Member account) Use the W3C Member account request form and get a W3C account,
- (If your organization has not yet joined the group) Ask your AC Representative (Member-only) to join the group using the join form,
- And then ask your AC Representative (Member-only) to nominate you using the nomination form.
When you have joined the group, you will also be automatically subscribed to the group’s Member-only mailing list. See the Instructions for joining the Web Payments Working Group for the details of the participation procedure.
Invited Experts are often important to a Working Group, when they fill gaps in expertise, and when they commit to a level of participation beyond the average Working Group participant, such as acting as a test lead, a specification editor, a reliable scribe, or a chair. If W3C Membership is not an option, and you have the expertise and commitment to participate, please contact the staff contact, Doug Schepers.