Initiate a refund transaction in the same way as a sale transaction, specifying the transactionType as REFUND instead of GOODS_SERVICES.
For all refund types, the system performs an additional check to make sure funds are available in the merchant account. Take care when interpreting the FINAL_RESULT_APPROVED tender state. The system received the request and accepted it for processing, but has not completed the refund.
The system does not process refunds online in real-time, as many acquirer/issuers process these in offline batches when the final result may not be known. Basic checks can be performed when submitting a refund, but the issuer is not guaranteed to accept the refund.
Configure notifications to report the result of a transaction as soon as the issuer responds. By processing these notifications, you can reconcile refunds and take action if a refund failed, by repeating the refund request or by reimbursing the shopper in another way.
If an internet connection is not available, the terminal queues and submits the refund when the internet is restored.
Dynamic Currency Conversion
Refund DCC transactions in the currency paid by the shopper, regardless of exchange rate changes during the time since the original transaction. This is required by scheme regulations.
For example, a Dutch merchant (currency EUR) sells an item of EUR 10.00 to a US citizen, who selected DCC and paid USD 12.00, exchange rate being 1.2000; After some time, the refund is granted, but the exchange rate is now 1.3000. The refund needs to be done for $12.00, which amounts to EUR 9.23. In this case, there is a loss to the merchant of EUR 0.77. This could also result in a profit for the merchant, if the exchange rate is lower.
Security
Refunds are restricted by permissions that can be set for the merchant in the Adyen payments platform and on the PED and are disabled by default.
Build specific security measures around this functionality to make sure that no fraudulent actions can be initiated by using these facilities.