Advancing the Web Payments HTTP API and Core Messages

Summary: This blog post strongly recommends that the Web Payments HTTP API and Core Messages work be allowed to proceed at W3C.

For the past six years, the W3C has had a Web Payments initiative in one form or another. First came the Web Payments Community Group (2010), then the Web Payments Interest Group (2014), and now the Web Payments Working Group (2015). The title of each of those groups share two very important words: “Web” and “Payments”.

“Payments” are a big and complex landscape and there have been international standards in this space for a very long time. These standards are used over a variety of channels, protocols, and networks. ISO-8583 (credit cards), ISO-20022 (inter-bank messages), ISO-13616 (international bank account numbers), the list is long and it has taken decades to get this work to where it is today. We should take these messaging standards into account while doing our work.

The “Web” is a big and complex landscape as well. The Web has its own set of standards; HTML, HTTP, URL, the list is equally long with many years of effort to get this work to where it is today. Like payments, there are also many sorts of devices on the Web that access the network in many different ways. People are most familiar with the Web browser as a way to access the Web, but tend to be unaware that many other systems such as banks, business-to-business commerce systems, phones, televisions, and now increasingly appliances, cars, and home utility meters also use the Web to provide basic functionality. The protocol that these systems use is often HTTP (outside of the Web browser) and those systems also need to initiate payments.

It seems as if the Web Payments Working Group is poised to delay the Core Messaging and HTTP API. This is important work that the group is chartered to deliver. The remainder of this blog post elaborates on why delaying this work is not in the best interest of the Web.

Why a Web Payments HTTP API is Important

At least 33% of all payments[1][2], like subscriptions and automatic bill payment, are non-interactive. The Web Payments Working Group has chosen to deprioritize those use cases for the past 10 months. The Web Payments Working Group charter expires in 14 months. We’re almost halfway down the road with no First Public Working Draft of an HTTP API or Web Payments Core Messages, and given the current rate of progress and way we’re operating (working on specifications in a serial manner instead of in parallel), there is a real danger that the charter will expire before we get the HTTP API out there.

The Case Against the Web Payments HTTP API and Core Messages

Some in the group have warned against publication of the Web Payments HTTP API and Core Messages specification on the following grounds:

  1. The Web Payments HTTP API and Core Messages are a low priority.
  2. There is a lack of clear support.
  3. There is low interest from implementers in the group.
  4. The use cases are not yet well understood.
  5. It’s too soon to conclude that payment messages will share common parts between the Browser API and the HTTP API.

While some of the arguments seem reasonable on the surface, deconstructing them shows that only one side of the story is being told. Let’s analyze each argument to see where we end up.

The Web Payments HTTP API and Core Messages are a low priority.

The group decided that the Web Payments HTTP API and Core Messages specs were a relatively lower priority than the Browser API and the Payment Apps API until June 2016. There was consensus around this in the group and our company agreed with that consensus. What we did not agree to is that the HTTP API and Core Messages are a low priority in the sense that it’s work that we really don’t need to do. One of the deliverables in the charter of the Working Group is a Web Payments Messages Recommendation. The Charter also specifies that “request messages are passed to a server-side wallet, for example via HTTP, JavaScript, or some other approach”. Our company was involved in the writing of the charter of this group and we certainly intended the language of the charter to include HTTP, which it does.

So, while these specs may be lower priority, it’s work that we are chartered to do. This work was one of the reasons that our company joined the Web Payments Working Group. Delaying this work is making a number of us very concerned about what the end result is going to look like. The fact that there is no guiding architecture or design document for the group makes the situation even worse. The group is waiting for an architecture to emerge and that is troubling because we only have around 8 months left to figure this out and then 6 months to get implementations and testing sorted. One way to combat the uncertainty is to do work in parallel as it will help us uncover issues sooner than at the end, when it will be too late.

There is a lack of clear support.

In the list of concerns, it was noted that:

“Activity on the issue lists and the repositories for these deliverables has been limited to two organizations… This suggests that the Working Group as a whole is not engaged in this work.”

Previous iterations of the HTTP API and Core Messages specifications have been in development for more than 5 years with far more than two organizations collaborating on the documents. It is true that there has been a lack of engagement in the Web Payments Working Group, primarily because the work was deprioritized. That being said, there are only ever so many people that actively work on a given specification. We need to let people who are willing and able to work on these specifications to proceed in parallel with the other documents that the group is working on.

There is low interest from implementers in the group.

We were asked to not engage the group, which we didn’t, and still ended up with two implementations and another commitment to implement. Note that this is before First Public Working Draft. Commitments to implement are typically not requested until entering Candidate Recommendation, so that there is now a request for implementation commitments before a First Public Working Draft is strange and not a requirement per the W3C Process.

If the group is going to require implementations as a prerequisite for First Public Working Group publication, then these new requirements should apply equally to all specifications developed by the group. I personally think this requirement is onerous and sets a bad precedent as it raises the bar for starting work in the group so high that it’ll result in a number of good initiatives being halted before they have a chance to get a foothold in the group. For example, I expect that the SEPA Credit Transfer and crypto-currency payment methods will languish in the group as a result of this requirement.

The use cases are not yet well understood.

It has also been asserted that the basic use cases for the Web Payments HTTP API are not well understood. We have had a use cases document for quite a while now, which makes this assertion shaky. To restate what has been said before in the group, the generalized use case for the HTTP API is simple:

A piece of software (that is not a web browser) operating on behalf of a payer attempts to access a service on a website that requires payment. The payee software provides a payment request to the payer software. The payment request is processed and access is granted to the service.

Any system that may need to process payments in an automated fashion could leverage the HTTP API to do so. Remember, at least 33% of all payments are automated and perhaps many more could be automated if there were an international standard for doing so.

There are more use cases that would benefit from an HTTP API that were identified years ago and placed into the Web Payments Use Cases document: Point of Sale, Mobile, Freemium, Pre-auth, Trialware, In-Vehicle, Subscription, Invoices, Store Credit, Automatic Selection, Payer-initiated, and Electronic Receipts. Additional use cases from the W3C Automotive Working Group related to paying for parking, tolls, and gasoline have been proposed as well.

The use cases have been understood for quite some time.

It’s too soon to conclude that payment messages will share common parts between the Browser API and the HTTP API.

The work has already been done to determine if there are common parts and those that have done the work have discovered around 80% overlap between the Browser API messages and the HTTP API messages. Even if this were not the case, I had suggested that we could deal with the concerns in at least two ways:

  1. The first was to mark this concern as an issue in the specification before publication.
  2. The second was to relabel the “Core Messages” as “HTTP Core Messages” and change the label back if the group was able to reconcile the messages between the Browser API and the HTTP API.

These options were not surfaced to the group in the call for consensus, which is frustrating.

The long term effects of pushing off discussion of core messages, however, are more concerning. If we cannot find common messages, then the road we’re headed down is one where a developer will have to use different Web Payments messages if payment is initiated via the browser vs. non-browser software. In addition, this further confuses our relationship to ISO-20022 and ISO-8583 and will make Web developers lives far complex than necessary. We’re advocating for two ways of doing something when we should be striving for convergence.

The group is chartered to deliver a Web Payments Messages Recommendation; I suggest we do that. We are more than 40% of the way through our chartered timeline and we haven’t even started having this discussion yet. We need to get this document sorted as soon as possible.

The Problem With Our Priorities

The problem with our priorities is that we have placed the Browser API front-and-center in the group. The group did this for two reasons:

  1. A subset of the group wanted to improve the “checkout experience” and iterate quickly instead of focusing on initiating payments, which was more basic and easier to accomplish.
  2. A subset of the group was very concerned that the browser vendors would lose interest if their work was not done first.

I understand and sympathize with both of these realities, but as a result, the majority of other organizations in the group are now non-browser second-class citizens. This is not a new dynamic at W3C; it happens regularly, and as one of the smaller W3C member companies, it is thoroughly frustrating.

It would be more accurate to have named ourselves the Browser Payments Working Group because that is primarily what we’ve been working on since its inception and if we don’t correct course, that is all we will have time to do. This focus on the browser checkout experience and pushing things out quickly without much thought to the architecture of what we’re building does result in “product” getting out there faster. It is also short-sighted, results in technical debt, and makes it harder to reconcile things like the HTTP API and Core Messages after the Browser API is “fully baked”. We are supportive of browser specifications, but we are not supportive of only browser specifications.

This approach is causing the design of the Web Payments ecosystem to be influenced by the way things are done in browsers to a degree that is deeply concerning. Those of us in the group that are concerned with this direction have been asked to not “distract” the group by raising concerns related to the HTTP API and Core Messages specifications. “Payments” and the “Web” are much bigger than just browsers, it’s time that the group started acting accordingly.

Parallel and Non-Blocking is a Better Approach

The Web Payments Working Group has been working on specifications in a serial fashion since the inception of the group. The charter expires in 14 months and we typically need around 6 months to get implementations and testing done. That means we really only have 8 months left to wrap up the specs. We’re not going to get there by working on specs in a serial fashion.

We need to start working on these issues in parallel. We should stop blocking people that are motivated to work on specifications that are needed in order for the work to be successful. Other groups work in this fashion. For example, the Web Apps Sec group has over 13 specs that they’re working on, many of them in parallel. The same is true for the Web Apps working group, which has roughly 32 specs that it’s working on, often in parallel. These are extremes, but so is only focusing on one specification at a time in a Working Group.

We should start working in parallel. Let’s publish the HTTP API and HTTP Core Messages specifications as First Public Working Drafts and get on with it.

Leave a Comment

Let us know your thoughts on this post but remember to play nicely folks!