Five questions you need to ask to avoid payment system failures and delayed launches

If you’re on the Board of Directors in an organisation which handles payments, I suspect you will have broken out into a cold sweat at the thought of a systems failure. Alternatively, you may have been in a meeting where a project has overrun (again) or needs more money to achieve completion. These are all unwanted events. The result is huge reduction in customer satisfaction plus an adverse effect on your profits and share price. If you’re an executive, it’s the last thing you need. You want to be focused on growth and leading your organisation rather than micromanaging avoidable problems.

The experience of your teams, their access to the latest testing methodology and technology will have a large bearing on your success in a rapidly changing environment. You need to be able to devise, plan and execute faster than ever before. To do that you need to be confident that controls are in place strong enough to identify a problem and successfully mitigate risk.

But as an executive removed from the detail, how do you know if your teams have control of the process? Do they have everything they need to move quickly and launch with minimal risk? Here are some questions you should be asking your technology teams to find out if they have everything they need to develop new initiatives and test accurately.

 

Are you testing payment innovation in silos?

In the past, test teams developed standalone solutions, focused on a single element of a payment environment. The people responsible test a specific leg of a transaction. This sounds ok in principle, but it prevents them from understanding more deeply how data will flow through all the different systems involved in a payment.

Testing in this way limits the learning and provides only part of the answer. For example, if an ATM test fails due to a VISA response, the separation of the two environments prevents proper analysis. This means that the test delivers inconsistent and questionable results. Get the number of your PR manager and decide how to handle the inevitable crisis.

But to avoid having to make this call, ask your teams if they still test in this way. If they do, tell them to stop immediately and look for a more reliable and modern approach.

 

Can you simulate an end-to-end transaction?

It is likely that your teams will answer ‘no’ if they are still testing in a piecemeal fashion, and this should be a concern. Virtualisation offers significant benefits when it comes to emulating a transaction. Creating multiple virtual images of the system under test enables entire testing streams to be run in parallel. Not only is this a more reliable approach, it is also much more efficient. Each engineer, or group of engineers, has access to their own virtual system without affecting testing being done by others. Virtualisation enables the simulation of a real world environment, without the impossible costs of operating multiple mirror images set through the whole process.

So virtualisation removes resource constraints, as anyone can run a test at any time they choose. It avoids test teams sitting around while someone in a different silo completes a test on an earlier stage in the process. It also consolidates skills, as testers have access to all parts of the system. Imagine if your tester who specialises in ATMs calls in sick and no-one else is confident enough to test and interpret the results?

Find out if your teams are using virtualisation in their test strategy.

 

Are your tests developed to prove that your technology works, or to see if it will fail?

Too many organisations focus on proving that software works, and yet the focus should be on trying to break it. It’s easy to be satisfied that everything is working if you are testing in the wrong way. Your confidence will survive only until Twitter goes into meltdown because your customers can’t get access to their money.

Challenge your teams to prove they are trying to break your technology, not simply presenting a signed document saying that it worked against a very limited test plan.

 

If you are using virtualisation in your payment testing, how flexible is the platform?

Virtualisation isn’t new in testing technology. Being able to virtualise an environment is, in most cases, sufficient to produce greater efficiencies and reduce risk. In the payments space though, if you lack support for the relevant industry standards, message flows and cryptography, standard generic platforms can only hope to scratch the surface of what is possible.

If you were planning to invest in the Far Eastern stock market you would not ask your local bank manager for advice, you’d speak to someone with a deep knowledge of investing in Asia.  In the same way, don’t ask a generalist about testing. Speak to experts, as it will save you huge amounts of time and money.

 

How confident are you that you can launch new payment technology without a delay?

Put simply, banks and payment providers need to change to new systems but find migration and development of new technology difficult. The world of payments is full of aging systems that are no longer up to the job.  They are expensive to maintain, slow, and increasingly hard to adapt to new technologies. Ask yourself these questions:

• Do your projects go over budget?
• Have projects been abandoned after it was decided that they were too complicated?
• Has the scope of the project been reduced or compromised at any point?
• Do you find yourself running two systems together, the old and the new?

There are a number of reasons why migration to a new platform becomes hazardous and subject to delay. Generally speaking though, it is because there is a lack of confidence in the ability to test accurately how the new platform will perform.

These simple questions will prompt deeper conversations about how you manage the development and launch of new payment technology. From the answers provided, you’ll be able to assess the level of confidence you have in the process or whether further work is required to reduce risk and improve efficiency.