Ramping up for TPAC in Lisbon

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

Brexit No Damper on Web Payments Participation and Progress

Attendees of the Web Payments Working Group meeting in London in July, 2016

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

First Public Working Drafts of Payment Request API

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.

Approaching First Public Working Draft of Web Payments API

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.

On Participation

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.

Join the Web Payments Working Group

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, public-payments-wg@w3.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:

  1. (If you don’t have any W3C Member account) Use the W3C Member account request form and get a W3C account,
  2. (If your organization has not yet joined the group) Ask your AC Representative (Member-only) to join the group using the join form,
  3. 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.

If you do not work for a W3C Member organization, please first consider whether your employer can join W3C and get the benefits of Membership.

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.