You are receiving this email as it has come to our attention that your transaction flow for reversals and refunds is incorrect (as per the Payments Association of South Africa/PASA requirements) in some instances and therefore leading to avoidable failures.
Please see the below information with regards to always using the correct transaction flow when processing reversals and refunds (more detailed PASA explanations are at the end of this mailer).
Reversals (RV):
Reversals are only to be used/processed when you would like to reverse a Pre-Authorisation (PA) transaction:
a Pre-Authorisation (PA) of a transaction places the funds in a suspense status/reserves the funds from the customers account
a Reversal (RV) must be used for PA transactions for funds that have not yet been settled
The transaction flow for this would be a PA and then a RV
Please note that a Reversal can only be processed on on the same day as the original successful PA transaction
Refunds (RF):
Refunds (RF) are only to be processed for successful Debit (DB) and Capture (CP) transactions
For a debit transaction, a Refund (RF) needs to be used as the funds are either on their way to the merchant or have already been settled.
If a Reversal (RV) is done on a Debit DB, this reversal will most likely fail as there is a potential for schemes issuing penalties
Quote from PASA with regards to Reversals (RV):
A reversal transaction takes place when the cardholder requests the merchant from whom he purchased the goods or services to reverse or cancel the original credit card purchase transaction.
This would generally occur immediately after the original purchase, or preferably on the same day – at least before the transactions on the terminal or store server have been “banked” with the acquiring bank.
In such a case the purchase transaction is effectively cancelled or aborted before its completion.
The transaction flow for this would be a PA and then a RV.
Quote from PASA with regards to Refunds (RF):
A refund transaction occurs when the cardholder approaches the merchant from whom the goods or services were purchased and, for whatever reason (return of goods, non-delivery of goods, incorrect goods or services, etc.), wishes the merchant to refund or rebate the full original amount. If the merchant agrees, the result is a “credit” transaction from the acquiring bank to the issuing bank, which then reimburses the cardholder the full amount.
In the event that a cardholder and merchant are unable to agree on a reversal or refund transaction, the cardholder has the right to declare a dispute and request his issuing bank to perform a charge-back transaction on his behalf.
The transaction flow for this would be on a DB, a RF would then be done.
Reversal Scenarios:
PA (Pre-Authorisation transaction) >> RV (Reversal)
RG (Registration) >> CF (Confirmation) >> PA >> RV on PA (must Reverse the successful PA)
Refund Scenarios:
DB (Debit) >> RF (Refund)
RG >> CF (Confirmation) >> DB >> RF
RG >> CF (Confirmation) >> PA >> CP (Capture of funds on PA - CP is a debit off the customers account) >> RF (must refund the successful CP)
Thank You for using Peach Payments as a Payment Gateway and please do not hesitate to reach out to us if you have any questions.
Peach Payments Support
Contact us at support@peachpayments.com