Payment process simulation in the cloud: Paving the way for scalable end-to-end testing

As ISO 20022 XML is replacing the plethora of older message formats, it is easily overseen that, even under application of the new standards, the handling of financial transactions between payment service providers and payment service users is far from unified.

While ISO 20022 XML defines a baseline for the communication between systems, the various flavors of the format (from plain XML and the CGI-MP recommendations to national or bank-specific definitions) make the development, deployment and maintenance of payment systems remain a challenging task. The inconsistency between implementations slows down development projects and increases their costs. Since an all-embracing, complete standardization remains a distant goal due to specific use cases and the legacy of old standards, the best approach are tools that help to manage the diversity on behalf of the developer.

In regard to both documentation and testing, it is much faster for the developing side to communicate with one interface than to reinvent the wheel for every new application. Ideally, the possibility to simulate even complex scenarios, for different payment providers, frees up a good part of developer time and significantly speeds up the work.

Testing all possible responses is crucial

Regarding XML-based financial transactions, software developers find themselves in an environment where no implementation is like the other. While there is little variation in how transactions are initiated, response messages often differ significantly. Transactions beyond the euro area are even more challenging. Work is further complicated by the fact that every bank’s documentation comes in a different format. Not or falsely computed r-messages (reverse, refuse, reveal…) may have severe consequences, from false bookings to failed transactions. In a production environment, every failed transaction unnecessarily binds human resources for troubleshooting.

In order to benefit from high rates of straight-through-reconciliation (STR) by means of automated processes, thorough testing is critical. The aim is to discover all non-standard responses in advance. However, the manual simulation of error situations for testing purposes is a time-consuming and expensive task.

Before using the banks’ production testing environments, testing the message formats and reconciliation of a new software is largely a manual process. Developers send message files to the bank by e-mail and wait for somebody to reply with the according response message received from a local test system. The amount of manual testing required does not only slow down the development process, but postponing the testing due to the laborious workflow often leads to the identification of problems late in the process, causing additional expenses and delays.

Even the alternative of testing directly against a production system hardly provides more flexibility. Apart from contractual challenges, opening accounts and moving real money for testing purposes is not very efficient; the targeted triggering of error situations to receive r-messages requires substantial planning.

Manual testing to be replaced with a smart platform solution

Obviously, the manual simulation of error conditions and the exchange of message files by e-mail are nowhere close to an efficient solution. It would be important to replace the manual testing workflow by automatizing the verification and handling of transaction messages.

Integrated end-to-end testing covers the entire event, from first initiation to the reception of the bank-specific response message. A centralized testing platform providing process simulation for any scenario without long setup times enables constant and repeated testing with little to no additional effort. Problems can be identified far earlier in the process and retesting a modified piece of software can be done in an instant, even using scripted batches. Malformed messages or issues from incomplete reconciliation can be eliminated early, reducing the task list for production testing against a live system to the verification of connectivity and communication flow.

Reduce development time and costs

In order to optimize the development of XML-based transaction systems and their maintenance, the identification of process bottlenecks is important. In an environment interacting with various banks, achieving interoperability of the software solution is a major factor. But even in smaller contexts with just one or two payment providers, complexity of documentation and specific error message implementations create an overhead as time is required for interpretation and manual testing.

Using a specialized end-to-end simulation service instead of manually testing against the system of a bank can significantly decrease development times and provide a solid base for future integrations of other payment providers or new processes.