How to test CHAPS payments

CHAPS payment testing verifies that a high-value sterling payment is authorised, validated, transmitted, settled and recorded correctly across the bank's payment systems. CHAPS, the Clearing House Automated Payment System, settles payments individually through the Bank of England's real-time gross settlement (RTGS) service. Tests should distinguish a payment accepted for processing from one confirmed as settled, and should use a controlled test environment rather than live payment traffic.

Define the CHAPS payment flow

Map the payment journey before writing test cases. A typical flow starts in an online banking channel, corporate file or internal payment application. It then passes through payment validation, approval controls, sanctions or fraud screening where applicable, a payment hub or gateway, the CHAPS interface and the bank's ledger and reconciliation processes.

Confirm the message format and implementation rules used by the bank. CHAPS uses ISO 20022 messaging; the applicable message types, required fields and validation rules depend on the payment flow and interface. Use the bank's current specifications as the test oracle. Do not assume that a message schema alone captures all business rules.

Agree the expected status transitions with system owners. For example, a payment may be created, approved, submitted, rejected or settled. Record which system is authoritative for each status, and how that status reaches the customer or originating application. A technical acknowledgement or successful message transmission does not by itself prove settlement.

Prepare data and test conditions

Use test accounts and payment data provisioned for the environment. Confirm that the environment routes to a simulator or other approved test endpoint and cannot send a real payment. Test data should cover valid and invalid account details, permitted payment limits, approval mandates and screening outcomes. Keep sensitive production data out of test environments unless its use is explicitly authorised and controlled.

Model business calendars, operating windows and cut-off behaviour from the relevant bank configuration. These can depend on the service, participant and operating arrangements, so avoid hard-coding a universal cut-off time. Include tests around calendar boundaries and scheduled maintenance where the system supports them. Check that environment configuration and reference data match the intended scenario, since drift can make results misleading.

Test the main payment outcomes

Start with a valid payment. Assert that the system applies the correct currency and amount, preserves required party and remittance data through each transformation, enforces approval rules, and sends the expected instruction. Verify the resulting status across connected systems, the debit to the payer's account, the corresponding ledger entries and the reconciliation record. Check that notifications reflect the actual payment state.

Then test rejection and exception paths. Examples include missing or malformed mandatory fields, an account that cannot be used for the payment, an amount outside a configured limit, insufficient available funds, a failed approval, or a screening hold. Confirm that the payment is not incorrectly submitted or debited, that the rejection reason is recorded and displayed appropriately, and that any repair or release action follows the required controls.

Exercise duplicate and uncertain-outcome cases. If a timeout occurs after submission, the originating system may not know whether the downstream system received the instruction. Verify that retries use the agreed reference or idempotency controls and cannot create an unintended second payment. Reconcile the result before retrying, and check that duplicate detection does not block a legitimate payment with a distinct reference.

Also test operational failures such as a downstream service outage, delayed status notification or interrupted batch. Verify queue handling, alerting, restart behaviour and reconciliation after recovery. A payment should not disappear from the workflow or be reported as settled solely because one component recovered successfully.

Worked example

Submit a valid GBP payment in the test environment with an approved mandate and a unique payment reference. Check that the channel displays it as submitted only after the payment service accepts it. Have the CHAPS simulator return a settlement outcome, then verify that the payment hub updates the status, the payer's account and ledger reflect one debit, and the reconciliation output contains the same reference and amount.

Repeat with a simulator rejection. The expected result is a recorded rejection, no settled status and no completed debit. Finally, simulate a timeout after submission and retry using the same reference. Confirm that the workflow checks the original outcome or applies its duplicate controls before any resubmission. Capture message identifiers, timestamps, status history and ledger evidence for each run.

Verify results across systems

Use assertions at service boundaries as well as end-to-end checks. Compare the payment instruction before and after translation, inspect API or message responses, and match the payment reference and amount across the channel, payment hub, ledger and reconciliation output. Verify both positive and negative outcomes, including that rejected or held payments do not produce settlement accounting.

Keep test evidence linked to the requirement and test data used. If an outcome differs, first establish whether the cause is application behaviour, simulator behaviour, configuration or environment drift. This separation helps teams diagnose failures without treating a test endpoint's response as proof of live CHAPS behaviour.