Refunds and reversals

If there is a need to reduce the amount that was charged from a customer before the purchase transaction is confirmed, the primary means to do so is to send a confirm operation with either a failure (which will return the entire transaction amount) or a reduced captured_amount (which will reduce the total_amount of the transaction). Since confirming a transaction happens after a transaction is marked as successful on the client, this should handle all the cases where transaction fails or is modified before it is complete.

Returning funds to the customer after the transaction has been confirmed is done by creating a refund transaction. A refund should be created for the amount that the merchant wishes to return to the customer. A refund should always refer to the original purchase transaction whenever this is feasible.

The server keeps track of how much of the original purchase transaction has been refunded. If the total of the refund amounts exceeds the original purchase transaction amount, the refund transaction will fail.

Refunds can be created either as “customer present” or “customer not present”. “Customer not present” refunds will never require interaction with the terminal and can be created as part of back-office processes. “Customer present” refunds may require the presentation of the payment instrument to the terminal during the processing of the refund. This needs to be the same payment instrument that was used for the original purchase transaction.

“Customer present” refunds may also be created without referring to the original purchase transaction. In this case, the refund will always require a payment instrument to be presented and the money will be returned to that payment instrument. Most schemes require that refunds are always done to the same account that was used for the original purchase, so when using non-referred refunds this is the responsibility of the client.