How to test ATM partial dispense reversals

ATM partial dispense reversal testing checks that a withdrawal is financially corrected when the cash dispenser delivers less cash than requested. The test compares the physical dispense outcome with the ATM's recorded result, the reversal or adjustment sent to the host, and the final customer account and settlement records. The expected financial treatment must come from the bank's transaction rules and ATM network contract, since implementations can differ.

Define the expected transaction outcome

Before testing, establish how the system represents the withdrawal request, the cash actually dispensed, and any cash presented to or retracted from the customer. Confirm which component reports the dispense result and which system decides whether to send a full reversal, a partial reversal, or another adjustment. Do not assume that every ATM reverses the undispensed portion in the same way.

Record the expected outcomes for at least these states:

• The dispenser delivers fewer notes than requested and confirms the amount delivered.
• Cash is presented, but some or all of it is retracted after the customer does not take it.
• The dispenser reports an error or uncertain outcome, such as a sensor fault, and the ATM cannot confirm how much cash reached the customer.

The transaction rules should specify the expected customer debit, reversal amount, transaction status and reconciliation treatment for each state. If the hardware cannot determine the amount delivered reliably, the defined recovery or investigation process is part of the expected result.

Prepare a controlled test

Use a certified test ATM, dispenser simulator or other approved test environment with test cards and accounts. Configure known cassette denominations and note counts so the requested amount can be mapped to a specific physical dispense. Use a host simulator or test host that records messages and responses. Keep the environment isolated from live customer accounts and production settlement.

Capture the ATM electronic journal, dispenser events and counters, host request and response messages, reversal records, and account or ledger entries. Align their timestamps or transaction references so the same withdrawal can be followed across systems. This is cross-system evidence: a successful screen message alone does not prove the financial correction occurred.

Run the scenario and verify each layer

For each case, submit a withdrawal, trigger a controlled dispenser outcome, and allow the normal ATM and host processing to complete. Check the following against the agreed transaction contract:

• The ATM records the requested amount and the dispenser's confirmed physical outcome accurately.
• The host receives the correct reversal or adjustment, with the original transaction reference and required amount and status fields.
• The customer account ends with the correct net debit after the original posting and any correction have been applied.
• The ATM journal, host records and cash counters provide a consistent explanation of the outcome.
• Retried or delayed messages do not create duplicate financial corrections.

Include a timeout or communication interruption after the dispense event. On recovery, verify that the ATM can resolve the transaction using its recorded state and transaction identifiers. Check both immediate results and the later reconciliation view, since a transaction can appear corrected at the host while remaining mismatched in cash records.

Worked example

Assume a test withdrawal requests £100 using £20 notes. The dispenser confirms that three notes were delivered, so the recorded physical dispense is £60. The expected outcome depends on the bank's rules: the test specification might require the customer to be debited £60 after a £40 partial reversal, while another approved flow may represent the correction differently. Assert the configured outcome rather than hard-coding a universal rule.

The test passes only when the dispenser evidence supports the £60 delivery, the host correction matches the specified treatment, and the account's final net debit is correct. If the host shows a £40 correction but the ATM journal records £80 dispensed, the case fails even if the account balance appears plausible. The conflicting evidence indicates a dispense reporting or transaction mapping defect that requires investigation.

Common failure modes

A reversal can be missing, use the wrong amount, reference the wrong withdrawal, or be applied more than once after a retry. A stale ATM state can also lead to a reversal being sent after the host has already completed a different recovery path. Physical cash records may disagree with host processing when note-present, note-taken or retraction events are interpreted incorrectly.

Treat these as transaction reversal testing across the ATM, dispenser, network and account-processing boundary. Keep assertions tied to the approved business rules and protocol contract, and retain enough evidence to distinguish a dispenser fault from a messaging, posting or reconciliation defect.