Reversals and Refunds
After a transaction is initiated or completed it may be necessary to undo the actions requested in the original message. It is important to understand the difference between a reversal and a refund in the context of Electrum’s APIs.
Reversals
A reversal is a system-generated advice that entirely reverses a request before the overall transaction is completed. This usually includes any fees that may have been incurred during the original request, i.e., the consumer receives back any transaction fees they had paid. Reversals are initiated automatically in response to a system error, such as a timeout, and sent upstream via a store-and-forward (SAF) queue as shown in the diagram below.
Reversals are important from a reconciliation perspective. In the diagram above, the authorisation is successful from the service provider’s point of view (they approved the request and sent a response) but unsuccessful from the originating system’s point of view (they did not receive a successful response). The reversal message system helps to ensure that all entities are in agreement.
Refunds
A refund is a request to undo a previously completed and successful operation. For example, a consumer may change their mind about a purchase and request their money back. This refund forms a completely new and separate transaction with its own authorisation and confirmation legs.
A refund request may or may not be accepted or allowed. For example, in the case of a direct airtime top-up a refund may not be possible as the consumer has already received the airtime on their mobile phone. If allowed, a refund also may or may not allow the return of the original transaction fees to the consumer.
Differences Between Reversals and Refunds
The table below summarises the main differences between reversals and refunds.
| Feature | Reversal | Refund |
|---|---|---|
| How it originates | Automatically generated by system in response to transaction error, e.g., timeout. | Initiated by a consumer wishing to undo a financially impacting transaction, e.g., a purchase. |
| When it occurs | During the transaction, if errors occur during the authorisation leg. | After the original purchase/redemption/order/creation transaction is completed. | A distinct new transaction must be initiated. |
| Dependency | Whether originating system and service provider support reversals. | Whether refund transactions are allowed for that service and accepted by the service provider. |
| Fees incurred during authorisation phase | Usually returned to consumer. | Often not returned; depends on financial agreements between the parties. |
| Impact on reconciliation | Very important for facilitating reconciliation – reduces exceptions by allowing all parties to reflect the same state of the transaction. |
|
Timeout Error Handling
Originating systems and service providers have varying levels of support for handling timeout scenarios.
Electrum may use reversals (as shown above), transaction retries, or transaction lookups as a means to handle timeouts.
Retries
The originating system retries the original request. There is usually a pre-determined maximum number of times that a transaction can be retried in an attempt to get a successful response.
Lookups
A transaction lookup is a separate operation used to determine the status of the original transaction request. If the originating system receives a successful lookup response, it means that the original request was successful. If the originating system receives an error message – for example, if the original request ID was not found – then it indicates that the authorisation was unsuccessful. The consumer can choose to reattempt the transaction or not.
The Benefit of Reversals for Handling Timeouts
Retries and lookups require that the originating system receives a response from upstream before the transaction can proceed. If there is a delay, then the entire process is held up. If further timeouts occur the originating system will still not know the status of the transaction and will not know how to proceed. Lack of agreement on transaction final states also leads to reconciliation exceptions.
The reversal message system solves these problems. If a transaction request is not returning a successful outcome, the originating system can issue a reversal message – which will be place in a SAF queue – and thus will not have to wait for a response. The nature of the SAF queue guarantees that a reversal will arrive at its destination upstream and that all parties will agree on the outcome of the transaction. The originating system can therefore decide immediately on whether to reattempt or abort the transaction.
Electrum strongly recommends that our customers and service providers implement reversals as part of their standard dual message flows, to facilitate error handling and reduce reconciliation exceptions.