How to test card refund processing

Card refund processing testing checks that a refund request for a settled card payment is authorised by the application, sent to the payment processor, reflected in transaction records and reported accurately to the customer. It covers full and partial refunds, duplicate requests, rejected or delayed responses, and reconciliation. The expected result depends on the processor contract and the system's refund rules.

Define the refund rules and starting state

Before execution, establish which transactions are refundable, whether refunds can be partial, whether multiple partial refunds are allowed, and how fees, currency conversion and refund limits are handled. These rules vary by product and processor. Use the agreed requirements and API contract as the oracle for expected results.

Create a known card payment in the test environment and confirm its state. Refund eligibility commonly depends on the payment having reached a specified stage, such as capture or settlement. A request against an authorised but uncaptured payment may follow a cancellation or authorisation-reversal path instead. Keep that flow separate from a refund test.

Record the original payment identifier, amount, currency and current refund total. Use controlled test data and avoid storing sensitive card data in test logs. Where the workflow spans a customer application, payment service and processor, test the hand-offs as part of end-to-end testing in banking.

Test the API request and transaction state

For a successful full refund, verify that the service accepts a valid request, associates it with the correct original payment and returns a response that matches the API contract. Check the refund amount and currency, processor reference, status and timestamps where these fields are provided. Avoid assuming a particular HTTP status or field name across providers.

For a partial refund, check that the requested amount is within the refundable balance and that the remaining amount is calculated correctly. Test currency precision using valid minor-unit amounts for the supported currency. Also check boundary cases: zero, a negative amount, an amount above the remaining refundable balance, and a currency that differs from the original transaction.

Verify the transaction lifecycle rather than checking only the initial response. A processor may accept a request before the refund reaches a final state. Confirm that asynchronous notifications or status queries update the refund record correctly, and that repeated or out-of-order events do not overwrite a final outcome with a stale status.

Exercise retries and failure paths

Submit the same request again after a simulated timeout. If the API supports an idempotency key, verify that retrying with the same key does not create a second refund. Check the documented behaviour for a reused key with a different request body. Test what the customer and support tools show when the processor rejects a request, is unavailable, or returns an ambiguous result.

A timeout can leave the outcome unknown to the caller even when the processor has received the request. The application should follow its defined recovery process, such as checking the processor's status before resubmitting. Assert that retries do not exceed the original payment's refundable amount and that failures leave a traceable record for investigation.

Reconcile the financial result

Check that the refund is linked to the original payment and represented correctly in the relevant transaction records. Verify that the refund amount is not counted as a new sale, that any fee treatment follows the configured rules, and that the customer-facing balance or transaction history reflects the refund status accurately.

Compare application records with processor reports or test events. Reconciliation should identify missing, duplicated or mismatched refunds, including differences in amount, currency or reference. A passing API response alone does not prove that downstream records are consistent.

Worked example

Assume a settled payment of GBP 60.00 is eligible for partial refunds. Submit a refund request for GBP 20.00 and verify its processor reference and accepted state. After the processor reports completion, confirm that the original payment remains linked, the cumulative refunded amount is GBP 20.00, and the remaining refundable amount is GBP 40.00. Retry the same request with the same idempotency key and verify that no second refund is created. Then attempt a refund above the remaining amount and check that the service rejects it according to the documented rule, with no additional processor or ledger entry.

Capture request and response evidence, event identifiers and relevant transaction records with sensitive values masked. This makes failures easier to diagnose across the application and processor boundary, while preserving a clear audit trail for banking audit trail testing.