How to test interrupted customer journeys in banking

Banking interrupted customer journey testing checks whether a customer can safely continue, recover or restart a banking task after an interruption such as an app closure, session expiry, network loss or channel change. It verifies that the customer sees an accurate status and that account, payment and audit data remain consistent with the journey’s defined recovery rules.

What to include in banking interrupted customer journey testing

Start by identifying the interruption points in each journey and the expected outcome at each point. A payment journey, for example, may include payee selection, payment details, review, authentication, submission and confirmation. An interruption before submission may allow the customer to resume editing. A lost response after submission needs different handling because the payment may already have been accepted.

Cover interruptions that affect different parts of the system:

• Customer interface: close or background the mobile app, refresh a browser, or navigate away.
• Session and authentication: allow a session to expire, or require the customer to authenticate again after returning.
• Connectivity: disconnect during a request, delay a response, or restore the network after a timeout.
• Channel: begin on mobile and continue on web, branch-assisted service or another supported channel.
• Dependencies: make an identity, payment or core banking service slow or unavailable.

The journey specification should say which details may be saved, how long they remain available, when authentication is required again, and which actions can be repeated. Policies vary by product and risk. Tests should verify the documented behaviour, including cases where the customer must restart or contact the bank.

Set up reliable recovery tests

Prepare controlled test accounts, known balances and test beneficiaries. Record the initial state before each run, and reset or reconcile it afterwards. Use an isolated test environment and simulated or approved payment rails so an interrupted test cannot create an unintended real payment.

Coordinate the customer interface with the relevant services. A screen that shows a draft does not prove that the backend saved it. Where access is available, check service responses, transaction records, audit events and ledger effects. Use a correlation identifier or another agreed test reference to trace one journey across services and channels.

Define expected results for each interruption point before execution. Include what the customer sees, the backend transaction status, whether a retry is allowed and the final account effect. For automated tests, prefer stable selectors and explicit state checks over fixed delays. A fixed pause can hide timing defects or make a test flaky when a dependency responds at a different speed.

Worked example: transfer response lost

Create a test customer with a known balance and an eligible beneficiary. Enter a transfer, review the details and submit it. Configure the test service to accept the request while delaying or dropping the response before the mobile app receives confirmation.

On reconnection, verify that the app presents a status consistent with the backend. If the transfer was accepted, the customer should be able to find that transfer and its status. Repeating the submit action must not create a second transfer. Check the transaction record and relevant account effects for duplicates, and confirm that the audit trail links the request and its later status. If the service did not accept the request, verify that the customer can retry according to the journey rules.

This scenario tests a lost response, which differs from a request that never reached the service. Test both conditions: the interface can show a timeout in either case, while the resulting transaction state differs. Safe retry behaviour depends on the service’s duplicate-prevention and transaction handling rules, so assert those outcomes directly.

Verify session recovery and channel changes

For a session-expiry case, pause the journey until the configured expiry condition is met, then return and authenticate again. Check that the customer is not shown stale or unauthorised data, that protected actions require the required authentication, and that saved information follows the stated retention rules. Also test expiry while the customer is reviewing or submitting a transaction, since each point can have a different result.

For cross-channel recovery, begin a supported journey on one channel and continue on another. Confirm that the second channel shows the correct saved details and current status, including changes made in the first channel. Check for stale balances, conflicting edits and duplicate submissions. A channel change should follow the product’s defined rules for authentication and unfinished work.

Diagnose failures with state, not screenshots alone

A passing screen check can miss a duplicate payment or an incorrect backend status. Compare the expected state with customer-visible status, service records and account effects. Classify failures by cause, such as lost persistence, stale session state, inconsistent channel data, unsafe retry or misleading status. Re-run with the same initial data and interruption point to distinguish a product defect from environment drift or a test setup problem.

Link recovery cases to the relevant journey requirements and rerun them after changes to session management, payment processing, authentication or channel integration. This makes interrupted paths part of regression coverage alongside the uninterrupted customer journey.