APIs and How Their Potential for Innovation Could Be Stifled

Read the latest article from Anthony Walton who was talking to Payment Eye about the opportunity with APIs and how to control the dynamic payments ecosystem….

In this guest post, Anthony Walton, CEO of Iliad Solutions explores the development of APIs and how their potential for innovation could be stifled by cultural and technological problems.

APIs are one of the most talked about topics in the industry. They present a new way of working which can speed up development and increase the amount of features and applications available to new product development teams, as well as exposing services to partners, and even in some cases competitors. I believe that APIs are going to be among the key trends which split the payments community between the true innovators and those too cumbersome to grow, who will increasingly lag behind and become extinct.

There are two big challenges that face those planning for the future with APIs. Will companies have the right mindset and culture to grow? If they do, will they have the right technology to launch applications and innovate more effectively than the competition?

 

Cultural challenges

APIs are not new. They have been used for many years to create defined integration points between applications. They have been at the heart of mobile payments, geolocation applications and financial management tools for years. However, the idea of working in an open ecosystem, where organisations can access technology which is ordinarily guarded behind a financial institution’s gated walls, is enough to leave risk managers reaching for the tranquilizers.

But this must occur to increase the rate of innovation.

The big development will be to make the defined integration points widely available. Internal teams can experiment with this, or braver companies can use developers from outside their own organisation. If the systems are open to anyone, then developers can get their heads together to dream up new and so far unimaginable uses for the technology.

Those calm enough, and with sufficient vision to see the benefits, could be on the verge of a technological step change. Others will close this liberated approach down, fearful of what could happen, and the available opportunities will quickly reduce. Even so, those prepared to jump in at the deep end will still encounter a huge problem.

 

Technology

APIs are superb, and allow you to add features you do not need to develop yourself. However this makes it difficult to develop a robust test, and if you don’t control the “test system” then you are going to hit your first problem.

It may be expensive to connect to the system, or the system owner may only make it available during certain hours. In addition, the system under test might only return behaviour that is out of your control. What do I mean by this? For example, you may wish to test dropping a communication channel half way through a test. Increasingly, people do their banking on the train to and from work and tunnels tend to be signal proof! Or, you may look to identify test cases for a stolen credit card when the API insists the card is OK.

This can throw up problems as the full end-to-end transaction might react differently in a situation you have not been able to assess. The result is that you will be going to market with a system that is only partially tested. Hope is not a test strategy and, in essence, that’s the approach you will be taking if you don’t test accurately. And the expense of getting it wrong, and experiencing an outage on a new product, is huge. Equally, the need to quickly, and cohesively regression test your platform after changes becomes even more of an imperative if you’re exposing your organisation’s assets to third parties.

 

The solution

The approach to testing has changed radically over the last few years but the vast majority of organisations remain stuck in a process which causes them delays, and results in launches with systems riddled with problems. The way around this is by using ‘virtualisation’, allowing you to replicate an end-to-end test of all the points in the transaction.

Virtualisation not only lets you test in isolation from the API provider, but allows you to orchestrate calls to multiple APIs entirely under your own control. You can more easily perform negative tests that the API may not easily allow, make the connection available to all members of your test team 24/7 and allowing access at zero cost. In short, it liberates you from many of the constraints, but more importantly it reduces cost and risk.

Through the use of virtualisation, you can take back control of API testing, modify the API in order to prototype, and massively scale the tests for stress and performance analysis. With virtual models and 24 hour availability you can schedule complex regression tests that run automatically regardless of how insignificant a change is made. And this is anywhere in the transaction lifecycle. When switch/migrations occur between APIs or an API release, virtualisation allows multiple “versions” to be tested in any combination, which removes the usual risks for the migration.

 

The industry is at a crossroads

With over 25 years of payment testing, we have been at the forefront of building, implementing and supporting payment innovation, and I think that now is one of the most exciting times in the industry. I’m hopeful that if decision makers can get over the anxiety of opening the doors, then we’ll have the right environment to innovate more quickly than ever before.