Solving the Twin Problems of Speed and Access in Payments

People want payment to be instantaneous and painless. While that may never be absolutely true, the industry is getting better. What’s driving these improvements are two interconnected trends: shrinking latency and the decline of the walled garden. Working together, the payments community has the ability to create a faster, better industry – and ultimately a better customer experience. 

 

Latency in payments has been in the news lately. The implementation of the long-delayed move from swipe to Chip and PIN cards, has led to multiple second processing delays at the checkouts, and sometimes hyperbolic reports of confusion and long lines at retailers nationwide. The exact source of these are manifold – and I think they obscure the industry’s progress on speed in other areas.

 

Let’s look more closely at the three causes of latency. The first is the underlying application. Traditionally payment companies have used monolithic mainframe applications in languages like COBOL. These workhorse systems were not designed for real-time programming, rather they are more optimized for batch processing. Changes made on top of the system usually only solve part of the problem – since they do not impact the application’s core. More modern languages like Java and Scala can scale easier, which is better for today’s dynamic market. 

 

Latency has also come from exposing applications to third parties. Given the batch processing nature of these legacy mainframe applications, data was traditionally exchanged using csv or other delimiter based batch files. Later, wrappers on top of this batch process were designed using XML files to make records more readable by humans, but then incurred the XML file processing performance cost. Next, these XML based extensions were wrapped further with a SOAP interface to facilitate web services. And lastly, the SOAP XML web service extension was wrapped again with a REST API interface. In this example, there are four layers on top of the core processing engine, which creates latency by not being close to the metal.

. 

The next form of latency comes from the internet itself. Sending data through the worldwide web can be unpredictable, depending on location and access. It takes time to create a connection and establish access. For now this is generally unavoidable, but the in the near-future we should see an increase in “persistent connection” based applications that allow for the exchange of information without reestablishing internet access each time. 

 

Payments processors traditionally stored integration documentation and testing facilities in a controlled environment, only giving it to certain people. This was the “walled garden” – a place where only a select few could interact with data and payments applications. Potential customers had to go through a contract process to buy an application, followed by documentation verification. You had to establish a commercial relationship before you start working with payment processing applications. 

 

APIs are changing this. With an API, it’s possible to have a login straight to a website and have instantaneous implementation information and prototyping facilities. It is possible for a prospective client to build a proof of concept without having a contract or paying money. A formal relationship can start only once it is clear that the product would be beneficial to both sides of the arrangement. Rather than walled garden, the world now looks like the “right to roam” on open access lands in the United Kingdom.  

 

The biggest advantage to all parties with this revised approach is price. In a software model, the price stakes were high because of the significant overhead involved. An API-approach levels the playing field, allowing nimble teams with great ideas a chance to compete. 

 

In many ways we are just beginning to see the potential of this open, faster world. An early example of how these twin trends can lead to a better product is in the area we refer to as “just in time” funding. This allows companies to disburse capital exactly at the point when it is needed, increasing security and available capital for the assets. But for it to work, it requires capital to move quickly. A process that typically took five or six seconds won’t work in this scenario. By building core processing systems from scratch using modern technologies from the start, a significant amount of computation and processing can be done in milliseconds. This is happening now – and it’s just the beginning.