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.
Refunds via API, are a feature sub-set of the Transaction Interface.
Saferpay does not check the amount you are submitting, against the initial transaction, per default.
If you want to prevent the API from refunding more, than originally authorized, see this chapter. Also note, that this can only be done with referenced refunds.
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.
Requirements
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
Secure Card Data Module (if refunds are performed using Aliases. Method 2)
We highly recommend, that you always start with Method 1: Referenced refunds and only use Method 2: Refunds using an alias, if there really are no other options!
Due to legal requirements, each non-referenced refund must be manually checked and approved by your acquirer, even if they appear successful.
This increases the rejection-risk and also the amount of manual labor, that later has to be done by the merchant, due to the successful refund being reverted.
Method 1: Referenced refunds
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.
Capture response
By passing this ID through to Saferpay, the refund will be linked to the original transaction inside the Saferpay Backoffice:
By clicking on the transaction ID you'll be redirected to the original transaction:
Preventing refunds from exceeding the originally captured amount
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 previous 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:
Let's 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.
Try it out
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!
Method 2: Refunds using an alias
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.
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!
Original Credit Transfer
Sometimes, there are cases, where a credit transfer needs to be executed without the availability of a previously made transaction and thus a reference. In these cases, the referenced refunds method is not applicable, which is where Original Credit Transfer transactions (OCTs) come in.
OCTs are used in cases, where the merchant wants to perform a payout against the card holder. One example for this may be the payout of a lottery win.
However, due to the nature of this kind of transfer, these transactions are highly regulated under money laundering laws and require certain care to be successful.
This chapter will guide you through the necessary steps needed, in order to perform OCTs.
Requirements
Aside the basic refund requirements, OCTs require the following things to be in place:
An OCT contract with your acquirer, allowing you to execute OCTs. Without the official allowance, you may not execute these refunds, causing the payout to your client to be blocked, even if the refund was successful. Please contact your account manager or our sales for more information.
API SpecVersion 1.24+
OCTs also require a set of datapoints to be submitted with the refund direct request, in order to be approved. See next chapter.
Technical integration
OCTs are executed via the Refund Direct request, using a card alias, or submitting the PANs directly (Please consider PCI, when doing so!). Additionally, you also must set the OriginalCreditTransfer.Recipientcontainer, for example:
That ensures, that these refunds can be approved automatically and will not be blocked.
Try it out!
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!
Capture
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!
Likewise, if a transaction has been captured, you cannot execute a cancel anymore.
Difference, between Cancel and Refund
At first glance, a cancel and a refund may be very similar and while they come into action in similar situations, they do different things and apply in slightly different circumstances. It is important to know these differences, so you apply both of them in the right situation.
A cancel prevents a customer from being charged, a refund is for situations, where the customer already has been charged.
However, you must know, that a cancel can only be issued as long as the money-flow hasn't been initiated, which usually happens with the capture.
Once the capture has been executed successfully, the money has been deducted from the cardholder and the transaction can no longer be cancelled. In this case you need to issue a refund, to transfer the money back to the cardholders bank account.
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.
Additional information
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 as 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. It is also possible to do multiple refunds on one transaction, even though the originally authorized amount has been exceeded, per default. Please make sure to keep track of this process, or prevent that behavior on Saferpay side.
Similar to normal transactions, it is possible 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. This will help you, keeping track of your refunds.
Last updated
