Reflecting on the W3C Web Payments WG
9 months since conception
I am spending a lot of time in airports and on aeroplanes these days and this affords me occasion to relax and reflect on what I have been doing and the work I am involved in. After a fairly hectic two weeks between Seattle, Boston and London, I am back at home in Cape Town (sitting in the airport waiting for my family to fly back from Durban) and able to consider, especially, the last two days, meeting face-to-face with the rest of the W3C Web Payments WG.
Sometimes it feels like we put a lot of energy into the WG and the output is slow and progress challenging and at those times I think it is valuable to take stock and appreciate what we have achieved in just 9 months.
Some genuine miracles can happen in 9 months, anyone with children will agree with that, and it would be a stretch to say we have achieved anything “miraculous” but we have made progress and I am positive about the impact this is going to make over the coming years. (Some may argue that having a working group at W3C with the majority of browser vendors engaged is, at a minimum, a minor miracle but let’s stay focused on what we are doing and not who is involved).
It’s been clear to me over the last nine months that for Nick (my co-chair and also a first time W3C WG chair) and me, there is a lot to learn about the W3C and how things get done, about the role of the staff, the power balances within the consortium and the “real” value of a W3C standard.
Payments is a vertical that the W3C has not taken on directly before and the result has been a swathe of new members from that industry who have joined the consortium with a variety of agendas and, in general, naivete about both W3C process and how things get done (which are not always the same thing).
For many in the payments industry, standards setting is a rigorous process of bureaucracy, consensus building and regulatory oversight as stakeholders juggle a variety of interests and, most importantly, produce a standard that is enforceable by regulators, governments or similar legislative or industry bodies.
To put a finer point on it, a lot of the W3C Payments activity participants are still getting their heads around the fact that we’re producing “recommendations” not “specifications” and that implementations of these standards is entirely voluntary and unenforceable.
This fact filters into everything we do and how we do it. We publish unfinished work early, riddled with unanswered questions (explicitly marked as such), as a signal to the industry of our direction, and a request for comments from the Web community. We design features into the platform that we expect to change because we want to try them out first and gather data. We architect solutions from the bottom up, often designing interfaces that make sense in the browser without considering how they might be implemented in other contexts or how the messages we pass in and out of these APIs might be used elsewhere.
To be clear, when I say “we” I am aggregating the output of the group and not the will of it’s participants. There are a great number of us who wish we could start top down with a solid architecture and then implement that as browser and HTTP APIs that share a common data model. We tried that in the beginning with little success.
The fact that the output of the group doesn’t exactly match the will of all participants is, to my mind, a combination of the motivations of W3C as an organisation as manifested by it’s staff, the consensus process we use to make progress, and the complex power-balance among W3C members. This is something that weighs on me heavily as a chair in my reflections. I wonder if there is more I could do to change this mismatch between inputs to and outputs from the group. But that is a conversation for another day.
In many respects one could look at the W3C’s standards process as an agile methodology for developing standards, in contrast to the waterfall methodology of institutions like ISO where the standard is developed out of sight of anyone but the standards developers and then thrust upon the world, often as a legally enforceable specification.
Personally, I prefer the W3C process but I have observed how the members of a highly competitive and regulated industry like payments have found it challenging. They boil with frustration as the technology companies in the group largely ignore their input and concerns about minor technicalities like existing industry terminology, message formats and flows and instead prioritize end user use cases. This is the agile way. Gather use cases, prioritize them, develop for the important ones and iterate.
In many respects the Web Payments WG at W3C feels to me like a microcosm of the greater fintech disruption happening across the financial industry. The pace of technical innovation on the Web is leaving those familiar with slow considered progress ruffled and uncertain.
The tech companies are more than happy to “move fast and break things” (to quote the CEO of one of the WG member companies) but I am happy to say that in the context of this WG they are not being completely deaf to everything the rest of group has said.
I think everyone in the group has felt some frustration over the course of the last 9 months. The tech companies wonder why we spend so much time discussing topics they consider irrelevant (or at best unimportant) like payment methods with very little user adoption. The payments companies are keen for the group to have a global perspective and be more cognizant of the complexities of the regulatory environment and also the existing standards that exist in this space.
From the perspective of the tech companies I’m sure they feel we could have made much faster progress if we just let them get on with developing something so they can get it to market and test it.
The reality is, we have published a number of draft specifications and we are already seeing these implemented. There are features of the Payment Request API that not everyone likes, and with my architect hat on (as opposed to chair hat), I know there are things I would change, but the recommendation is published and being implemented, and I believe it has the potential to revolutionize payments on the Web (some thoughts on that another time, this is getting long winded). Short term it will solve a great number of use cases that have mass appeal and it has the potential to reduce dropped checkouts and online payments fraud dramatically.
But, I am most excited about the long term potential of this API when combined with the Payment Apps API and the development of an ecosystem of secure payment apps. This should allow users to ditch card numbers once and for all and for new, more secure, more open payment methods to thrive online.
The Payment Apps API was adopted by the group yesterday as an editor’s draft. All that’s left now is for the browser vendors that have committed support for this third-party app ecosystem to participate actively in the design of the API and implement it as it matures.
Finally, I would be amiss if I didn’t mention the HTTP API recommendation that is moving rapidly toward publication. It’s hard to truly grasp the value of this API now, but when I consider it alongside the work I am involved in with Interledger, and the data I see predicting how autonomous payments from machine to machine will explode in an IoT world, it’s quite possible that standardizing autonomous Web payments this early may be one of the smartest things we could ever do.
After all, HTTP response code 402 has been “undefined” for decades, perhaps the time is right to give it some meaning?
There is a lot for this group to still tackle and a long tail of use cases we must deal with, but on balance I am confident that we’ll get there, and that despite the frustrations and disillusionment that some may feel we are on track.