Skip to main content

Testing integrated payment systems

Banking systems are usually quite complex. There is a big difference in testing a single application and a fully integrated banking system.

Even when creating a simple SEPA payment, if we trace the flow from the user initiating it to the payment message leaving the bank's systems and reaching the SEPA payment system, many steps are taken.

For example a simple payment flow could look like this:

  1. The customer inputs the payment information in the internet bank; 
  2. The internet bank queries the main banking system to check if the customer still has enough funds for the payment;
  3. The internet bank makes a query to another system to check if the receiver bank accepts SEPA payments;
  4. If it does the payment message is be screened for fraud in another system;
  5. If no fraud is detected it travels to the main bank system;
  6. Then depending on the bank it could travel to another system that is used to send the payment to the global SEPA payment system (in case the core banking system is not used for that);
  7. Then the payment could again be screened for money laundering in another system;
  8. Then if no money laundering is detected then the payment file could be transferred to another server where it would be finally retrieved by an external system (for example Latvia Central bank EKS) to be sent to the SEPA payment system.

This is just an example and the flow might be different for each bank - having more or less systems involved - but in this example we already have 7 separate systems (Internet Bank, Main bank system, System for checking SEPA reachability, Fraud check system, SEPA payment sending system, Money Laundering System, SEPA file server) that are used to process just one simple payment.

In addition between each of these systems there can be multiple types of message sending integration solutions. And technically each of these systems and the message integrations can fail (especially in testing environments).

Due to this it is very important for the QA to understand the full message flow when testing it. When something fails it is important to understand at least approximately where it failed. 

Often as QAs in the testing environment you will have direct access to a lot of these systems but more than likely you will not have access to all of them and to the integration queues that are between each of these systems.

Even if the failure is related to some bug in the code - to create a bug ticket you will need to describe the issue and to understand which system the bug is in. Often each system has a different person responsible for it and some of them might even have an external Jira system where the bug needs to be created.

If the QA does not describe which system the bug is in and exactly what it is, a lot of the other employees' time can be wasted.

So to properly understand and describe the issues the QA needs to know or at least know how to find out who is responsible for each system and integration.

For example, often bugs are related to content of XML messages that are sent between systems and this content can not be visible in any user interface.

In this case the QA would need to understand what integration is used between the systems and contact the integration admin/developer who is responsible for it and request for the message content from the logs.

Then after analyzing the message and finding the issue a proper bug can be created.