Refunds and reversals

The difference between a refund and a reversal can often be confused. This guide describes how they are relevant to Paymentology and our clients.

Refund: A refund occurs when a transaction is posted and the funds are already in the account.
Reversal: A reversal occurs when the transaction is part way through/has not yet completed, i.e. it is yet to post.

A payment refund or reversal can either be initiated by the cardholder, merchant, Issuer, Acquirer or Payment Scheme Network.

Refunds

A refund is a transaction type that returns funds to where they came from. For payment cards, a refund is typically performed when a purchased item is returned, and the funds (or some part thereof) are credited back to the cardholder.

There are a few interesting things to note about refunds:

While the merchant may associate the refund with an original transaction internally on their end, the refund received has no relation to the original transaction.
This means a refund can be done on any card, even if the original purchase was made via other means.

Due to this, refunds can be prone to fraud and should be monitored.

Monitoring refunds

You can make use of the following data exchange and alerting mechanisms to monitor refunds and assist in mitigating refund fraud:

Reports: You can source refund data from:
- Authorizations
- Presentments
FAST transaction interface: You can monitor refund transactions on your end in real-time.
PayRule: You can have rules configured that trigger alerts on refund transactions.

Sample refund messages

You can view sample reversal messages in Sample FAST messages and by navigating to a refund.

Reversals

A reversal can in theory be done on any kind of transaction i.e. an authorization, credit, debit, balance enquiry etc. The point of a reversal is to put things back to how they were before the event that is being reversed occurred.

Why would you want to do that?

The main reason is when you can't be sure of the result of the original transaction. In other words:

You sent a transaction of some type, and you never received confirmation the transaction was received.

The reason this is a problem is that it's possible the transaction never reached the destination and had no impact (so there's no financial impact), but it's also possible that the transaction did reach the destination, was processed correctly, and the response confirming this was lost in transit.

As the sender, if you don't receive a response, how do you know what happened?

In short, you don't. To avoid duplication, a reversal needs to be sent. This reversal asks the recipient to put things back to how they were before. This then allows you to then resend the transaction as if it's the first time you're sending it.

What happens at the destination side when you receive a reversal?

As mentioned, you need to put things back to how they were before. The reversal must include reference information with enough detail that you're able to determine if you received the original transaction. Then:

If you can find the original transaction (i.e. you did receive it), you need to undo/reverse it on the card/account.
If you can't find the original transaction (i.e. it seems you didn't receive it), then there's nothing to reverse on the card/account.

Problems can also happen when sending reversals. Similar to the original transaction, you could send a reversal and not receive a response/confirmation. Again, as the sender, you don't know if the reversal was received or not.

The recipient/destination side needs to be designed to accommodate this. In other words, if you receive a reversal repeat (you may not even know it's a repeat, because you may not have received the first reversal request), the same logic applies:

If you can find the original transaction (i.e. you did receive it), you need to undo/reverse it on the card/account.
If you can find the original transaction (i.e. you did receive it) and you already reversed it on the card/account, you do not need to do this again. The system must be able to receive the same reversal multiple times, processing it the first time as necessary, but doing nothing to the card/account for any subsequent times it's received.
If you can't find the original transaction (i.e. it seems you didn't receive it), then there's nothing to reverse on the card/account.

No matter what the situation is at the receiver, if you receive a reversal, you must send back a confirmation. You do not indicate to the sender whether you found the original transaction, all you do is send back a confirmation that you received the reversal. Reversals are therefore expected to be idempotent - that they can be applied multiple times without changing the result beyond the initial application.

🗒️
If you receive a reversal request, you must confirm receipt by responding.

Because the result of the reversal is irrelevant to the sender, and you're just confirming it was received, the standard practice on receipt of a reversal is to:

Send back a positive confirmation that the reversal was received.
Process it, reversing (or doing nothing) as necessary.

If you're sending a transaction and receive no response back, you send a reversal. If you do not receive a response to that reversal, you send another reversal. Standard practise dictates that you only keep trying to resend reversals for a limited number of times. The Retry Exhaust Mechanism, allows you to pre-define the number of retries the system has to make before stopping. If the pre-defined retry attempts are exhausted and still no response has been received, an alert is raised for manual intervention.

Sample reversal messages

You can view sample reversal messages in Sample FAST messages and by navigating to a reversal.