Maintaining quality for a common services middleware application suite is a critical factor in successful integration of any bank’s systems and rolling out of new offerings. A key success factor for any payment transformation program is to start testing earlier, to deliver early and achieve cost savings.

Overview: System Integration Testing (SIT) & Payment Domain Architecture

Payment domain applications are built on highly complex architecture which leads to complicated problems when it comes to integrating them and dependencies between subsystems, processes and infrastructure. A payment processor is a highly scalable and high throughput application designed to support the processing needs of all different types of payment schemes. It assigns end to end workflows to process the customer payment transactions.

SIT is basically the integration testing of two or more system components. Specifically, system integration testing is the testing of software components that have been distributed across multiple platforms (e.g. client, web server, application server, and database server) to produce failures caused by system integration defects (i.e., defects involving distribution and back-office integration).

The term “System Integration Testing” (SIT) refers to the test phase that follows Integration testing, comprising of Integration Testing and End to End Testing.

System Integration Testing

 

Payments & Payment life Cycle

Let us try to understand what are actually payments and a payment lifecycle.

A payment system is a set of instruments, bank procedures and usually, interbank fund transfer systems that guarantee the circulation of money. It consists of multiple applications connected via standard protocol layer following HTTP and MQ transmission modes.

When we deposit a check in a bank, it becomes a check payment, when we do third party funds transfer it becomes an interbank payment, fund transfer within the same bank becomes a book to book payment or an electronic payment and so on. What happens with these payments which we make? How do we finally get the account status saying “Your account XXXX is credited with so much amount of money”? To get answers of all these, we need to know a payment life cycle.

When the payment is punched in via frontend by a user, it is received as a stream of data bytes at payment processor. This stream of data contains all user specific confidential details, which is used by the payment processor for executing business rules, enrichment, and payment transformation, perform business validations, scheduling, and perform bookkeeping and disbursement. When the payment reaches its release date, it is finally DISBURSED to Clearing for settlement. It is now that the actual credit happens to the beneficiary account and Clearing marks the payment as COMPLETED and we finally get that SMS which we are eagerly waiting for…..!

The Challenge to start early SIT

• Constrained access to live servers for testing
• While individual services could be tested with relative ease, simulating the impact of interacting with multiple back-end live systems to provide realistic responses was nearly impossible, as these systems supported live customer operations that were too critical to be exposed to testing
• Scheduling and test data conflicts between teams
• High labor cost and maintenance of custom-coding developers. Several developer teams manually building their own “stubs” or responder frameworks, with little success or reusability

The Solution

Service virtualization solution helps to create an end-to-end virtual environment for continuous testing across the payment processor HUB and its partners. There are now service virtualization tools that allow comprehensive integration testing to happen all the time. That means less hardware and time to configure complex heterogeneous systems, making it attainable to run integration tests on each and every build.

SIT Before and After Solution

Before and after the Solution, things probably look a bit like this:

Service Virtualization

 

• Before Service Virtualization, there were no dedicated group building responders and all the teams had their own hodgepodge framework of custom coded Java applications or other types of responders
• After the solution, test teams can align with the development team on the same milestone because setup is no longer a bottleneck

How Service Virtualization works for Payments Domain?

• Virtualizing HTTP and MQ at the protocol level and stubbing out calls that go back to a lot of different mainframe systems, extending the framework to talk to webMethods, middleware systems, mainframe calls
• Pretty much anything we can reach via an HTTP or MQ interface, we can now virtualize
• Service virtualization allowed test environments to be launched in an automated way alongside test management and application lifecycle activities including builds
• With its ability of capturing and automating test data, this data could be quickly managed within Service Virtualization, or exported and manipulated quickly in spreadsheets or other tools
• Use of “Pass-Through” feature for specific payment transactions to the real services or back-end systems as needed allows validation of real systems closer to the point of integration, and refreshing of the data within Virtual Service models on an as-needed basis

We see constant change in the testing world, with new methodologies being proposed all the time. This is good as it all is a part of moving from art to craft to science. There are many projects in the practice, in which early and continuous testing has proven to be a boon. This approach has been successful and for the payments domain with complex design and architecture described in this blog – by preventing problems instead of fixing them on a later stage.

References:

• http://www-01.ibm.com/software/rational/servicevirtualization/solutions/
• http://Servicevirtualization.com