Ramping up for TPAC

W3C’s annual “big meeting” of groups takes place in the Bay Area this year. The Web Payments Working Group agenda is coming into view, and I think of it in four parts:

  • Payment Request API. How is implementation going? As we prepare to recharter the group, what topics should we include in scope for the next iteration of the API?
  • Payment Apps. We will see demos of Web-based payment apps used to make payments in Chrome (which has an experimental implementation of the Payment Handler API), and address some of the current issues with that specification.
  • Payment Methods. We will discuss new versions of payment method specifications for card tokenization, card encryption, credit transfer, and interledger payments.
  • Adoption. What are we hearing from merchants? Do we have any preliminary data of interest to support the hypothesis that the improved user experience can increase conversations and lower cart abandonment rates?

I anticipate between 500-600 people will attend TPAC this year, and at the current rate of registration, we are likely to have record number of attendees —around 60— at the Working Group’s meeting.

As always, I look forward to the most exciting W3C week of the year.

Payment Request API —Now Being Implemented in All Major Browsers— Advances on the Recommendation Track

In early September I learned with excitement that the status of Payment Request API implementation in Webkit went from “Under Consideration” to “In Development.” That means that the API is being implemented in Chrome, Edge, Firefox, and Webkit, as well as Samsung Internet Browser and Facebook. If you know about more implementations, please let me know.

The timing couldn’t be better. Today the Web Payments Working Group advanced both Payment Request API and Payment Method identifiers to Candidate Recommendation Status. This step in the W3C Recommendation Track means that the specification is stable and we will now focus on browser interoperability, primarily by developing a comprehensive test suite. If you would like to help us work on the test suite, please contact me.

For more information about the Candidate Recommendation announcement, see our media advisory and FAQ.

In parallel, the Working Group continues to work on:

  • Payment Handler API, which enables Web sites to be payment apps in the Payment Request API ecosystem. Google and Samsung have been working on experimental implementations on the browser side of the API, and Klarna and others working on payment apps. I expect that the Working Group will devote more attention to payment apps now that Payment Request API is a Candidate Recommendation.
  • Payment Method Manifest, which supports the secure deployment of third-party payment apps for proprietary payment methods.
  • Ongoing discussion of payment methods “beyond Basic Card,” including discussions of encrypted and tokenized cards, as well as credit transfers and interledger payments.

The Working Group’s charter expires 31 December, so we have begun to discuss what’s next. If you are interested in shaping the group’s agenda, now is a great time to get involved, especially as our next face-to-face meeting is around the corner: 6-7 November at TPAC 2017.

Congratulations to the Web Payments Working Group for reaching this milestone!

Update: Many thanks to everyone who responded to this post urging the Working Group to include support for cryptocurrencies. I have turned off comments for now, most of which speak to the same request.

Payment Handler API – First Public Working Draft Published

Today W3C published the First Public Working Draft of Payment Handler API. This diagram shows the relationship between Payment Request API and Payment Handler:

Relationship between Payment Request API and Payment Handler API

In a typical scenario, a merchant calls Payment Request API so that the browser (or other user agent) displays UI for the user to choose a way to pay via a “payment app.” Payment apps include browsers (which plan to offer the service of storing card credentials), native mobile apps and Web sites. Browsers will communicate with native mobile apps using operating-system specific mechanisms. But what about Web sites?

Payment Handler API is designed to enable Web apps to handle payment requests. The specification explains how Web apps register supported payment methods with the browser and provide information that the browser will display to the user to make a selection. The specification also defines what happens after user selection of such a Web app, including how the app is launched, what data it receives about the transaction, and what data it returns to the browser after the user has completed interaction with the payment app. That data is packaged and returned to the merchant Web site through Payment Request API.

Although we have had some early implementation experience at both ends of the API (browser and payment app), I expect that to accelerate now that we have reached this milestone.

For more information, see the Payment Request FAQ.

Preparing to Advance Payment Request and Payment Handler APIs

Photo of Web Payments Working Group at their March 2017 face-to-face meeting; photo by Adam Roach.

Fifty people from more than 25 organizations attended the 23-24 March face-to-face meeting in Chicago of the Web Payments Working Group. We wanted to know whether we are ready to advance our most mature work to the next stage of the W3C Process, and whether we are ready to take up new work that complements it.

The first day was a blast, which is uncommon praise for a day-long meeting. What made it exciting for me was the evidence of traction. The editors of the Payment Request API brought us up-to-speed on the main changes of the past several months. We then heard about implementation experience from Google and Facebook, and enjoyed demos from Facebook, Samsung, Worldpay, Alibaba, Microsoft, and Gemalto. The demos brought the specifications to life and reinforced a shared vision. The number and diversity were very motivating.

Most of first day focused on Payment Request API, which enables merchants to build streamlined checkout flows where people can easily return card information stored in the browser.

Some Payment Request API implementers have also begun to support payments by native mobile apps in addition to browser-stored credentials. We call these “third party payment apps” and the consensus is that this architecture should support integration of third party payment apps. So in the afternoon of the first day we turned our attention to the Payment Handler API draft. That specification defines capabilities that enable Web applications to be “third party payment apps” and handle payment requests. The task force working on that specification has made significant progress in the past few months thanks to growing contributions from Mozilla, Google, Opera, Shopify, Ripple, Worldpay, Klarna, Samsung, American Express, and others.

Views differ on how strongly coupled Payment Request API and Payment Handler should be. Those views were on display on Day 2, and we proceeded at a slower pace. I would summarize them this way:

  • Strong Decoupling. Payment request API can be implemented in browsers and other user agents without requiring third party payment apps. It is being implemented, and it should be allowed to progress through the W3C Process without dependencies on Payment Handler API.
  • Moderate Decoupling. Payment request API can be implemented in browsers and other user agents without requiring third party payment apps, but there is a clear expectation for third party payment apps to be part of the ecosystem. Therefore, we should get implementation experience for Payment Request API and also third party payment apps. Payment Request API should not be finalized in the W3C Process until we are confident the two play well together.
  • Moderate Coupling. We won’t know whether Payment Request API is stable until we have greater implementation experience with Payment Request API. Therefore, we should get more implementation experience for both specifications and the two should exit the “Candidate Recommendation” step of the W3C Process at the same time.

Although people in the group likely have more nuanced views than this, I think it helps frame our discussion. In the end, we opted for a moderate decoupling: Payment Request API can exit Candidate Recommendation once we’ve satisfied our implementation expectations —two implementations from two different vendors on both mobile and desktop— and will not depend on the status of Payment Handler API. However, the group will simultaneously gather third party payment app implementation experience during the Payment Request API Candidate Recommendation phase to strengthen our confidence. Discussion about requirements and expectations took up several hours but it was important that we hear from one another and come to agreement on our plan.

We did cover a number of other topics on the second day:

  • We discussed a draft Tokenized Card payment method specification. Although people did not rally around the draft we presented, they did voice significant interest in defining one or more tokenized card payment methods. I expect this activity to pick up momentum because it offers an opportunity to make Web payments more secure with little added friction.
  • We also discussed a Basic Credit Transfer payment method specification. People also indicated interest in this specification both because of its adoption in some places (e.g., we heard 30% of Internet payments in Belgium are done through credit transfers) and because it is a “push” payment method, which helps us validate the Payment Request API for more payment methods than cards. The group asked the task force working on this specification to find more implementers and validate the usefulness of the specification across a variety of credit transfer systems.
  • We also discussed a new proposal to give payment method owners the tools they need to securely authorize payment apps that implement those payment methods.

The Working Group is thus preparing to answer two questions over the next couple of weeks:

  • Should Payment Handler API advance to First Public Working Draft?
  • Should Payment Request API and its supporting spec Payment Method Identifiers advance to Candidate Recommendation?

For Payment Handler API, the road to First Public Working Draft is a bit easier. If all goes well, I would expect that to happen in April. We won’t have resolved all the issues by then, but we don’t have to: we will record them in the specification and those markers will help us guide reviewers.

For Payment Request API, we need to freeze the issues list and resolve at least some of those issues before the Chairs issue a call for consensus. If all goes well, I would expect we enter Candidate Recommendation by mid May.

Many thanks to Adam Roach for his photo of the group meeting. Minutes from 23 March and 24 March are available.

Congratulations to the Working Group for their significant progress and upcoming milestones!

Getting to CR!

The Web Payments Working Group meets 23-24 March in Chicago. On the agenda are these questions:

  • Given progress on Payment Request API (and associated specifications) as well as Payment Handler API, are we ready to advance Payment Request API to Candidate Recommendation (CR) and Payment Handler API to First Public Working Draft?
  • Do we wish to take up two new payment method specifications: Basic Credit Transfer Payment and Tokenized Card Payment?
  • What is the state of the Payment Method Manifest File proposal (for payment method owners)?
  • What are next steps for our test suite?
  • What progress have we made on merchant adoption strategy?

We’ll hear from the Editors of the various specifications, as well as from the implementers. We anticipate demos from Alibaba, Facebook, Gemalto, Microsoft, Ripple, and Worldpay.

I anticipate summarizing our meeting the week of 27 March.


Web Payments Traction in 2016 and Looking Ahead

“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!

Priorities for the weeks after TPAC 2016

Photo of Web Payments Working Group at their 20 Sep 2016 face-to-face meeting; photo by Adam Roach.

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.

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