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