What role do developers play in open payment?

Earlier this year, I attended TransportationCamp East 2011, an ‘unconference’ on transportation and technology. In one of the sessions, on open payment, the most common question from developers was a simple one: how can I get involved? Many developers were disappointed to hear that there was no good answer; that while these systems are intended to be open, little work has been done to define specific interfaces.

Now that WMATA has released the Step 2 RFP for its New Electronic Payments Program, we have a clear view of what WMATA expects from the system. As much as WMATA has pushed the use of an open architecture for the NEPP, open data does not feature heavily in the specification. There’s an entire section in the Technical Specifications devoted to APIs—but it deals with the APIs that will be used for the various components of the NEPP to interact with each other as well as with other WMATA systems. Evidence from transit systems around the world shows that there’s a great deal of interest in developing apps which interact with their data. Rather than being bolted on after-the-fact, public APIs should be part of the NEPP from the ground up, and the system should be designed to embrace the efforts of outside developers.

What might these public APIs include?
Continue reading What role do developers play in open payment?

What can you do in 300 ms?

300 milliseconds—about as long as the blink of an eye. It’s also the amount of time WMATA provides, in the specifications for their New Electronic Payments Program, for bus fareboxes and rail faregates to process a transaction and respond. But how feasible is that? What needs to be done in those 300 milliseconds, and can it be done?
Continue reading What can you do in 300 ms?