What is card authorisation reversal testing?

Card authorisation reversal testing checks that a payment system can cancel all or part of an approved card authorisation and handle the resulting state correctly. It verifies that the reversal refers to the original authorisation, is transmitted and processed as expected, and does not leave an unintended card hold or create a duplicate financial effect. The issuer controls when a released hold becomes visible to the cardholder.

How card authorisation reversals work

An authorisation request asks the issuer to approve a card payment and reserve funds or credit. If the merchant or payment service later cancels the payment, it can send a reversal through the relevant acquiring and card-processing route. The reversal identifies the original authorisation and requests cancellation of all or part of the approved amount.

A reversal can be needed when a customer abandons a purchase, a terminal or application times out after an approval, or a business rule prevents the payment from continuing. In a timeout case, the system may not know whether the approval reached the issuer. It must resolve the uncertain outcome before deciding whether a reversal is appropriate.

The reversal lifecycle can involve several systems and asynchronous responses. A successful API response from one component does not necessarily prove that the issuer has released the hold. Test expectations should follow the system's defined status model and account for issuer processing and display delays.

What the tests should verify

Start with an approved authorisation and retain its identifiers, amount, currency and status. Verify that the reversal references the correct original transaction and that the amount and currency follow the configured rules. Check the response and subsequent status updates across the payment service, processor or simulator, and any customer-facing transaction view in scope.

Include failure and timing conditions. For example, test a reversal request after a timeout, a processor rejection, a delayed response, and a retry after the caller has not received the first response. Confirm that retries do not create duplicate reversals or leave the original transaction in a misleading state. Check that unrelated authorisations on the same card remain unchanged.

The expected result depends on transaction state and the processor's rules. A reversal for an uncaptured authorisation should not be treated as a refund for a settled purchase. Once a payment has been captured or cleared, the applicable cancellation or refund process may differ. Testing should check these state boundaries rather than assume every reversal follows one universal flow.

Practical example

A checkout service receives approval for £40, then the order service cancels the order before capture. A test can send a full reversal referencing that approval and assert that:

• the reversal request contains the original authorisation reference, currency and amount;
• the processor or test double accepts it and returns the expected status;
• the payment record moves to the configured reversed state, with no capture created;
• retrying the same request does not create a second reversal; and
• the card balance or available-funds result is checked according to the test environment's issuer simulation, rather than assumed from the API response alone.

A related partial-reversal case can cancel only the unused portion of an authorisation, where the product and processor support that flow. The remaining authorised amount and later capture must agree with the defined rules.

Reversal testing and related payment tests

Card authorisation reversal testing focuses on cancelling an authorisation and managing its state across connected services. It complements Card authorisation testing, which checks approval and decline behaviour, and Payment idempotency testing, which checks how repeated requests are handled. Reversal tests often need both: a correct reversal request must also remain safe when delivery or acknowledgement is repeated.