The Testing Challenge: Future Proofing

Synopsis

Payment systems providers are in stiff competition with each other to quickly provide innovative products for their customers. So, new systems with different communications interfaces are being added to their processing systems architecture at a high rate. The testing tools that payment systems providers use are usually created to test a single message format on single processing system. As a result, new and additional testing tools and testing processes are required to support the new products, resulting in additional licensing and maintenance cost, as well as training and the maintenance of expertise by the testing staff.

The testing challenge

The classic 4-party payments model created the following system architecture. System testing focused on using a “simulator” to mimic the behavior of one or more systems in the 4-party model. The following is an example where a simulator is used to test an issuer’s processing system:

A single simulator is sufficient to stand-in for the merchant and acquirer systems as well as the processing network handling communications between the Acquirer and the Issuer. The same situation exists when testing the acquirer and/or merchant systems.

However, with advent of ISO 20022, mobile payments applications and a variety of different systems supporting value-added products, the testing architecture for the classic 4-party model shown above is no longer sufficient. The following architecture shows some of the level of complexity in modern payment system architecture although, if anything, it is simpler than the reality of most systems.

 

 

Single message format simulators are unable to cope with this complexity, which features messages in two different ISO formats, a terminal-dependent language, a mobile payment application interface, a reward system protocol and two different fraud scoring system interfaces. Functional testing of all of the components in this network requires seven (7) different simulators.

The problem is compounded in systems integration testing. To isolate a single system, either a string of simulators would need to be configured and supported to test the system under test or the actual test systems for the systems not under test would have to be configured and maintained. In either case, multiple points of failure are introduced, requiring extended debugging if something goes wrong. In the best case, they require setup and observation, even though they are not the system under test.

 

The challenge going forward

This illustration shows a typical, if possibly over-simplified, view of the current internal architecture of a payment system. It is clear that the array of systems involved in such an architecture will increase going into the future. New products often require new processing systems to support them. Existing systems will be improved, sometimes to the extent of changing their messaging interfaces or communications methodologies. In a typical situation, this means adding a new simulator or replacing an existing simulator with another that is designed for the new requirements. In the best case, this means additional costs. In the worst case, this limits the ability to innovate when new capabilities cannot be effectively and efficiently tested.

 

The approach to a solution

The solution to this problem is to stop focusing on simulating a specific environment but instead to create an enterprise-wide testing platform that is agnostic in terms of the messaging protocol and method of communications with the systems it is simulating or testing. This may seem obvious but, on the other hand, overly ambitious. But using 21^st century programming architecture techniques it is achievable and, in fact, has been achieved. What does such a platform look like?

First, it is modular. Each piece is built separately but designed to interact with all of the appropriate modules on demand. In this way, the tool can be configured and reconfigured to meet different and changing testing needs. In modern software, this consists of multiple modules within an API framework, such as RESTful.

Second, everything that can be treated as data is treated as data. This maximizes the platform’s flexibility by allowing all levels of function be modifiable “on the fly” without resorting to modifying the software code. Combined with modularization, the right functions can be driven by easily modifiable parameters and data to obtain whatever testing functions are required.

Finally, the solution platform allows multiple different parameterized, modularized functions at the same time. In the sample above, the platform can, at the same time, speak ISO8583 over TCP/IP, drive one Risk Scoring protocol using MQ and another using http while talking ISO 20020 over whatever communication interface is required. And internally, it can simulate any and all of the systems shown in the example in combined tests that allow any system under test to be isolated in a systems integration test environment without requiring other simulators or systems to be active.

 

The t3:Switch™ Solution

These capabilities are built into t3:Switch™ by Iliad Solutions. T3:Switch currently supplies and supports a choice of over 75 protocols. More are being added by Iliad and customers can create their own if needed. Three (3) primary communications methods (TCP/IP, MQ and HTTP) are available and others and others can be added. The main access to t3:switch functions are via a “simulator-like” Web Browser but all functionality is directly accessible via a RESTful API, which allows automation via CI/CD methodologies as well as integration to test and customer management systems. While traditional “exe” type installation is supported on Windows and Linux systems, Docker-based containers make installation easy over a wide array and mix of implementation strategies.

In short, t3:Switch provides a totally state of the art for current needs and the flexibility of meeting the future needs for enterprise-wide payment systems testing.

 

Iliad Solutions

We have over 25 years’ experience working on payment innovation and developing test tools to help. In this time, we have been at the forefront of building, implementing and supporting major payment solutions. Our experience has led us to develop the most comprehensive and resilient test solutions available in the world today. Iliad’s test platform enables you to simulate a real world transaction across legacy systems, multi-step transactions, APIs, web services and tokenisation.

Iliad’s t3: Switch Platform:

– automates payment testing, which significantly reduces project costs.

– can be used 24/7 by hundreds of testers globally and simultaneously for prototyping, testing, accreditation and certification purposes.

– tests the business flow as opposed to simulating individual parts of the transaction.

– decreases risk through end-to-end testing in new deployments, which helps to protect your brand from high profile failures.

People using Iliad save time and money, and increase the confidence in their core systems.

Our global customer base trusts us to take the risk out of payment testing.