Mambu integration testing checks that Mambu, a core banking platform, exchanges the right data with connected systems and that the resulting banking process behaves as specified. It covers the configured interfaces, data mappings, processing rules and failure handling across a boundary such as a payment service, customer onboarding platform or general ledger. The exact tests depend on the institution's Mambu configuration and the interface contracts in use.
What Mambu integration testing covers
A test should follow data across the systems involved in a business process. For example, account onboarding may pass customer details from a digital channel to an identity verification service and then create a customer or account in Mambu. Payment processing may send an instruction to Mambu, pass it to a payment provider and return a status to the originating channel.
Test each relevant interface type, such as an application programming interface (API), event or file exchange, against its agreed contract. Check required fields, formats, identifiers, validation rules and error responses. Verify that values retain their meaning across mappings, including currency, dates, account status and transaction references.
The business outcome matters as much as the message. Confirm that the intended record or transaction appears in the expected systems, with the correct status and amount. Where the process includes a ledger or reconciliation service, check that its resulting data agrees with the source transaction.
How to plan and run the tests
Start with a system map and interface specifications. Record which system initiates each interaction, what data it sends, how a response or status is returned, and whether processing is synchronous or asynchronous. Confirm the expected behaviour with the product and operations teams, especially for rejected, pending, reversed or timed-out transactions.
Prepare controlled test data for each path. Include valid records and cases that exercise mandatory fields, boundary values, duplicate references and invalid states. Use synthetic or approved masked customer data, and confirm that test records can be identified and cleaned up safely. Data relationships matter: a test payment may require an existing account, configured product and eligible status.
Run tests in an environment where Mambu and its connected services have compatible configuration and versions. Environment drift, missing credentials, incorrect callback addresses, unavailable dependencies or different product settings can produce failures that resemble defects. Record environment and configuration details with the test results.
For each test, capture the request or event, response, correlation identifier, relevant system records and final business state. Avoid logging sensitive customer data in test evidence. When a failure occurs, use timestamps and correlation identifiers to locate the transaction across service logs and distinguish a rejected request from a delayed or duplicated update.
Example: payment status update
Suppose a channel submits a payment instruction that is processed through Mambu and a connected payment service. A useful integration test is:
- Create an eligible test account and submit an instruction with a unique reference and known amount.
- Verify that the receiving interface accepts or rejects the instruction according to the agreed contract.
- Follow the instruction through both systems and confirm the expected transaction amount, reference and status.
- Deliver the same instruction again if the interface contract defines duplicate handling. Confirm the specified outcome, such as safe rejection or idempotent processing.
- Simulate a timeout or unavailable dependency, then verify the expected retry, pending state or failure response and check that recovery does not create an unintended second transaction.
The expected result must come from the approved business rules and interface contract. A successful HTTP response alone does not prove that the banking process completed correctly.
Common failure modes and trade-offs
A test can pass at the interface level while data mapping, downstream processing or status propagation is wrong. Conversely, a delayed event can make an asynchronous process appear to have failed. Set an appropriate wait or polling condition based on the documented processing behaviour, and retain evidence of intermediate states.
Service stubs can make tests repeatable when a third party is unavailable, but they cannot prove that the real integration works. Use them for focused and frequent checks, then run tests against an authorised integrated environment to verify connectivity, authentication, contracts and end-to-end outcomes. Keep the scope clear: integration testing checks connected components, while broader end-to-end testing in banking validates a complete customer or operational journey.
Frequently asked questions
Can Mambu integration testing run in a CI pipeline?
Yes. A CI pipeline can run repeatable contract and integration checks when it has access to a suitable environment, controlled test data and required credentials. Keep tests dependent on unavailable third parties separate or use service stubs, and report which dependencies were simulated.
How should teams test a Mambu interface change?
Compare the changed interface contract and configuration with the previous approved version, then run affected mapping, validation, error-handling and downstream workflow tests. Include consumers that depend on the changed fields or statuses, and retain regression evidence for unaffected critical flows.
What evidence should a Mambu integration test retain?
Retain the test case and expected result, environment and configuration details, request or event metadata, correlation identifiers, timestamps, relevant responses and evidence of the final business state. Mask or exclude sensitive customer information from logs and reports.