How to test refunds during neobank account closure

Neobank account closure refund testing verifies that refunds and remaining funds are handled correctly while an account moves through closure. It checks the account’s state, ledger entries, payment-rail responses, customer access and reconciliation against the neobank’s documented rules. The expected outcome depends on the product, processor and payment method, so define those rules before building tests.

Define what counts as a refund

Separate a refund of a completed payment from the payout of the account’s closing balance. A merchant card refund usually follows the original card transaction through the card processor. A closing balance payout is a separate transfer initiated by the neobank. They can arrive at different times and follow different accounting and operational paths.

Document the expected handling for each payment type and account state. For example, a card refund might be credited to an account that is still open, held for later processing, routed through an approved internal process, or returned if the account cannot accept it. The correct result depends on the neobank’s arrangements and policies. Avoid treating one route as universal.

Map the closure workflow, including states such as requested, pending, closed and rejected. Record the rules for outgoing payments, pending card transactions, fees, holds, overdrafts and refunds received after closure. Confirm whether closure is blocked while particular items remain unresolved, and what happens when an incoming refund arrives after the customer’s access has ended.

Build tests around the lifecycle

Use test cases that cover both the account state and the refund’s state. Include an account with a zero balance, a positive balance awaiting payout, and a balance affected by an outstanding hold or fee. Exercise refunds before closure, during a pending closure and after closure. Check partial and full refunds, duplicate notifications, delayed settlement, rejection and retry behaviour where these apply.

Verify the customer-facing result alongside the financial records. Check that a closed account cannot be used to make new payments or withdrawals, while any permitted refund handling follows the documented process. Confirm that the app displays an accurate status and does not imply that funds are available when they are pending, held or being returned.

At the ledger level, assert the debit and credit entries, currency, amount, transaction reference and posting status. Check that a refund does not exceed the refundable amount unless the product explicitly supports an adjustment. Reconcile the processor or payment-provider record with the internal ledger and account balance. A user-interface status alone does not prove that funds were posted or returned correctly.

Test retries and repeated events for duplicate financial effects. If a processor sends the same refund notification more than once, the account should receive only the treatment defined by the product, with a traceable outcome for each event. Check that a timeout followed by a retry does not create duplicate credits or leave a refund in an ambiguous state.

Worked example

Assume the documented rule says that a card refund received after closure cannot credit the customer’s closed account and must enter an operations queue for handling. The account has a £12.00 balance, which is paid out when closure is completed. A merchant then sends a £42.80 refund for an earlier card purchase.

Assert that the original £12.00 payout is recorded once and that the account remains closed. When the refund event arrives, verify that no new customer-available balance appears. Check that the £42.80 is recorded in the configured processing state, linked to the original purchase and visible in the operations queue. Replay the same event and confirm that it does not create a second financial entry. Finally, reconcile the account, ledger and processor records. If the actual product rule specifies a different route, change the expected result while retaining the same reconciliation checks.

Verify dependencies and test evidence

Run the scenario across the systems that own the relevant decisions: mobile or web channel, account service, ledger, card processor and reconciliation process. Use controlled test data with known transaction references and account states. Where a provider cannot reproduce delayed or rejected events, use a controlled test double and separately verify the provider integration contract.

Keep evidence for each transition, including event timestamps, account state, ledger entries, processor status and customer-visible messages. Check for environment drift, such as different closure rules or processor configuration in a test environment. Link each expected result to the applicable product rule so that changes to refund handling can be traced into regression tests. These checks complement broader bank account closure testing and cross-system testing in banking.