Integration testing in banking verifies that connected systems exchange, process and retain transaction data according to their interface and business rules. It checks boundaries such as a digital channel and core banking system, or a payment service and payment hub, including successful processing, error handling and recovery. The aim is to find defects caused by interactions between components before release.

What integration testing in banking covers

A bank transaction can pass through several services, each with its own data model, processing rules and availability. Integration tests check that those components work together across their interfaces. The interfaces may use application programming interfaces (APIs), message queues, files or database connections.

For a payment flow, tests might cover a mobile or web channel, payment initiation service, fraud and sanctions checks, payment hub, core banking system, general ledger and an external network connection. The exact scope depends on the architecture and the interfaces under test. Checks can include:

  • Required fields, formats, identifiers and value mappings at each boundary.
  • Business rules applied as data moves between services, such as currency or account validation.
  • Transaction status and event handling, including delayed or out-of-order messages where the design permits them.
  • Posting, balance and reconciliation outcomes in line with the bank's specified rules.
  • Error responses, timeouts, retries, duplicate prevention and recovery after a partial failure.

Integration testing differs from end-to-end testing in banking by focusing on interactions between selected components or services. An end-to-end test follows a customer or business process across a broader set of systems, potentially from initiation through settlement and reporting. The two scopes can share scenarios, while their test boundaries and evidence differ.

Conditions for reliable integration tests

Tests need stable interface contracts and defined expected behaviour for each transaction state. Before execution, confirm the relevant service versions, configuration, routing rules and test endpoints. Environment drift, such as a changed schema or payment route in one test environment, can cause misleading failures or hide defects.

Use controlled test data with known account states, limits and permissions. Test records should be isolated from other runs, and any created transactions should have a defined cleanup or reversal approach. For external dependencies, use an approved non-production endpoint or a controlled simulator where appropriate. A simulator can exercise expected responses, while testing against a provider's test service can reveal integration issues specific to that service. Neither removes the need to verify the bank's own processing and reconciliation.

Assertions should cover the full message or transaction outcome, not just an HTTP success response or a user-interface confirmation. A request can be accepted while later processing fails. Correlate logs and events using transaction identifiers, and check that the final state, postings and downstream records agree with the expected business rules.

Practical example: an outbound payment

Suppose a test submits a £125 payment from a customer account through a digital channel. The test checks that the payment service passes the correct amount, currency, beneficiary and customer reference to the payment hub. It then checks the expected account posting and payment status against the product rules, and verifies that the hub sends the expected instruction to a test network endpoint.

The endpoint returns an accepted response, after which the test checks the resulting status and any required ledger or reconciliation records. The test also repeats the submission with the same idempotency key, if the interface supports one. It should confirm that the retry follows the specified duplicate-handling behaviour and does not create an unintended second payment. A separate failure-path test can make the endpoint time out and verify the documented retry, pending-status or repair process.

The expected result must reflect the bank's own payment lifecycle. An accepted instruction does not necessarily mean that the payment has settled. Tests should therefore assert each relevant state separately and retain evidence linking the request, response, postings and final outcome.

Frequently asked questions

Should banking integration tests use production payment networks?

Routine integration tests should use approved non-production endpoints or controlled simulators. Any production transaction testing requires explicit operational approval, safeguards against unintended customer impact and a defined reconciliation process.

How should teams test an unavailable banking dependency?

Use a controlled stub or test service to reproduce the dependency's timeout or error response, then verify the bank's specified retry, status, alerting and recovery behaviour. Confirm the outcome with transaction records and logs.

What test data is suitable for banking integration tests?

Use controlled synthetic data or appropriately protected test data with known account states, permissions and balances. Keep records isolated between runs, and prevent test transactions from reaching real customer accounts or production payment routes.