Refunds
Saferpay generally offers a refund functionality from the start through the Saferpay Backoffice. However, if automated, or more integrated processes are needed, the JSON-API can be used to execute refunds from the merchants webshop, or ERP-system. This part of the guide covers the process of how to execute refunds through the Saferpay JSON-API, which can be performed in two ways.
Saferpay does not check the amount you are submitting, against the initial transaction, no matter, what method you chose!
It is in your hands to check, if you refund more, than initially payed by the customer.
Not all payment methods to support a refund functionality. Especially online banking payment methods do not provide refund functionality due to how the money is processed. You can find an overview of the supported features, inside the respective Payment Method chapter.
- a valid login access with a username and password for the Saferpay Backoffice.
- one active Saferpay ecommerce terminal
- Saferpay terminal number (TerminalId parameter) and Saferpay customer number (CustomerId parameter).
- valid acceptance agreement for credit cards or other payment methods
Referenced refunds are performed, by using the Refund request. This request accepts the CaptureId, of the transaction you want to refund!. It is usually -please refer to the respective Payment Method chapter- returned, after you have executed a Capture.
{
"ResponseHeader": {
"SpecVersion": "1.21",
"RequestId": "d66252aacafc19161333916ba87601e5"
},
"CaptureId": "W6ttz4AQMIM2tAhI2llEA0E5xCzb_c",
"Status": "CAPTURED",
"Date": "2021-07-09T11:48:02.462+02:00"
}
By passing this ID through to Saferpay, the refund will be linked to the original transaction inside the Saferpay Backoffice:
(click to enlarge)
By clicking on the transaction ID you'll be redirected to the original transaction:
(click to enlarge)
If necessary, you can prevent Saferpay from exceeding the originally captured amount. This can prevent multiple refunds and other mishaps, that can cause you to refund more money, than originally charged.
In order to do so, you have to set the Refund.RestrictRefundAmountToCapturedAmount to true.
However, please note the following restrictions:
- This only works for API SpecVersions 1.25+ !
- This only works, if you reference a CaptureId and not a TransactionId! Old API-Versions did use the TransactionId, which still works in newer versions, but not in conjunction with this feature!. If you migrate from an old version, you must move to the CaptureId, as described in the previos section!
- Only the amount of the capture is checked here and not the amount of the whole transaction! This can prove problematic, when using Partial Captures. Please see the following example:
Lets say, that you have a transaction over 100,- and use Partial Captures to capture 50,- , 20,- and 30,-. You can refund these individual parts and Saferpay will make sure, that the amount of these parts will not be exceeded, even if multiple refunds are executed. This means, that you have to refund each individual part, with this option enabled, in order to refund the whole transaction, as Saferpay will not allow you to refund 100,- on just one part (as it is possible without this option enabled). Likewise, if you want to refund 75,- , you first must refund the 50,- and then 25,- of the 30,- or the 20,- and the remaining 5,- from the 30,-. Of course, you can ignore this detail, if you execute a normal capture or just one Partial Capture over the whole transaction amount.
You can try it out, by first doing a complete (including the Capture!) transaction, by using the PaymentPage, or Transaction Interface. The refund-option will be displayed, after the Capture has been executed!
A different method is using an alias obtained through Secure Card Data, which can be obtained in multiple ways.
This request is different from the that of the referenced refunds. When using an alias, the Refund Direct request has to be used.
WE HIGHLY RECOMMEND, THAT YOU ALWAYS START WITH METHOD #1 AND ONLY USE AN ALIAS, IF THERE ARE NO OTHER OPTIONS!
Due to legal requirements, concerning money laundering - mandating a refund to always reference a previous transaction, which is only possible via method #1; referenced refund (hence the name) -, each non-referenced refund must be manually checked by your acquirer and even then, it is not guaranteed, that they will be approved!
While Refund Direct does offer the possibilities to submit the card number (PAN) directly, it is not allowed to do this without a full PCI-DSS certification. More on that topic can be found in the Data Security and PCI DSS chapter.
Due to the fact, that the original transaction ID is not submitted, like with referenced refunds, the refund will not be linked to the original transaction inside the Saferpay Backoffice!
You can try it out, by first doing a complete (including the Capture!) transaction, by using the PaymentPage, Transaction Interface, or the Secure Alias Store. The refund-option will be displayed, after the Capture has been executed!
Like normal transactions, refunds need to be captured/booked by executing the Capture request successfully, if the transaction STATUS is AUTHORIZED.
The actual transfer of money will not be executed if the refund hasn't been captured!
It’s by no means rare that customers want to cancel their orders or return goods. As a merchant, you will in such a situation either want to cancel or make a refund for the transaction in question.
Once that happened, the money flow has been initated and the transaction can no longer be cancelled. In this case you need to issue a refund, to transfer the money back to the card holders bank account! So a cancel actually stops the money transfer from happening, while a refund reverses the transfer, once it happened!
Please note, that there are exceptions. Some payment methods initiate the money flow with the capture, some with the Daily Closing.
Not all payment methods do support a refund, or even the cancel. An overview can be found in the respective Payment Method chapter.
Refunds are basically normal transactions where instead of debiting the cardholders account, you are crediting it. That means, that refunds go through the same authorization-steps like a normal (debit) authorization. Please keep in mind that a refund can also be rejected, though this is very rare.
The refund amount value can differ from the originally authorized (debited) amount. This also applies to referenced refunds. The refund will be regarded as a completely new transaction, with its own set of parameters, like the amount value. So, if you want to refund two transactions in one batch, you can do that by simply adding the amounts together. It is also possible to do multiple refunds on one transaction, even though the originally authorized amount has been exceeded! Please make sure to keep track of this process.
One way to do so (like with normal transactions) is to submit the parameter "OrderId" inside the "Refund" container. This ID will be forwarded by Saferpay and will show up inside the Saferpay Backoffice (as the Reference number) as well as in your reconciliation-files.
Last modified 10mo ago