Interfaces
Integration Guide
3-D Secure
3-D Secure – 3DS for short – is supported by Visa (Visa Secure), Mastercard (Mastercard ID check), American Express (SafeKey), Diners Club (ProtectBuy) and others. Via liability shift, merchants who offer the 3-D Secure process benefit from fewer payment defaults and from increased security with respect to credit card acceptance. It does not matter whether the card holder (CH) participates in this process or not.
The 3-D Secure procedure can only be used for payments on the Internet. If participating in the process, CHs must identify themselves to their card-issuing banks (issuer) while making payments. Payments that merchants conclude via 3-D Secure are to be specially flagged. Only when the corresponding criteria have been sent with the authorisation to the credit card company does the liability shift apply. This step is done automatically via the Transaction Interface and the Payment Page, meaning that no additional integration costs arise. The authentication of the CH proceeds via a web form provided by the issuer or by the service provider contracted by the issuer. The 3-D Secure authentication of the CH is done via an Internet browser.
A transaction with the 3-D Secure process proceeds as follows:
- 1.The merchant sends the credit card details together with the relevant payment data to Saferpay.
- 2.Saferpay checks whether the CH uses the 3DS process or not. If yes, she or he will be required to authenticate her or himself to her or his bank. If not, the payment can be carried out without authentication.
- 3.The 3DS request will be forwarded to the card-issuing bank via the CH’s Internet browser.
- 4.The Issuing bank, or its 3DS provider will then perform a so called scoring. This scoring will determine the fraud risk, which will lead to one of two outcomes:
- 5.Frictionless: The fraud risk is low and 3-D Secure will proceed without user interaction. The bank will be the liable entity. This also applies to all orders smaller, or equal to 30 Euro, or equivalent, though with a maximum of 5 concurrent transactions (Globally, not merchant/shop-based!).
- 6.Challenged: The fraud risk is high, or the issuer wants to force 3D Secure (E.g. after 5 concurrent transactions, as described above!), thus the cardholder needs to authenticate him/herself, by using a password, an SMS-TAN, an App, or even the fingerprint-sensor on his phone. If 3-D Secure was successful, the bank will still be the liable entity.
- 7.The result of this authentication is sent back to Saferpay.
- 8.Saferpay checks the result and ensures that no manipulation has occurred.
- 9.Saferpay links the 3DS data to the token used by the JSON API and uses this data automatically when authorising the card.
- 10.When receiving the authorisation answer, the merchant also receives information about the outcome of the 3-D Secure process.
What is Liability Shift and why is it important for me as a merchant?
The best way to understand what Liability Shift means, is through a small example:
Let's say a merchant is offering certain goods and gets an order for 1000 EUR. The merchant finalizes the order and the money gets charged from the card holder's bank account. After he received his money, the merchant ships the goods to the given destination.
After three weeks the merchant gets the information, that this transaction is a fraud-case and that the actual cardholder initiated a chargeback. Here is what happens, either with, or without 3-D Secure/Liability Shift:
Without 3-D Secure/Liability Shift:
The Money gets transfered back, from the merchants bank account, to the original card holder. The merchant, in this case, is liable for the damage that has been caused and even though the goods already have been shipped (probably to a criminal subject), he has to pay the full amount back to the card holder. So he carries the whole risk and the cost in a fraud-case!
Attention: A high amount of chargebacks can also cause penalties from the brands (E.g. VISA and Mastercard) directly! So it can be, that they will force you -the merchant- into using 3-D Secure, if the fraud-rate is too high!
With 3-D Secure/LiabilityShift:
Like the name suggests, the liability gets shifted! Shifted from the merchant, to the bank. So in case of fraud, the chargeback gets completely carried by the issuer. The card holder will get his money back, BUT, unlike before, the merchant can keep the charged money. The risk and the cost is carried by the issuer in this case, negating the costs on the merchant side.
3-D Secure on API-Level
The Saferpay JSON-API does return all necessary information inside the Liability-Container, when using Transaction Authorize or PaymentPage Assert. The important parameters are Authenticated and especially LiabilityShift. Furthermore LiableEntity will provide information about who will be liable in case of fraud, while Version will tell you the used 3D Secure protocol (Subversions are not conveyed!) and, in case of protocol-version 2, AuthenticationType will tell you whether the card holder went through a Frictionless or Challenged flow.
Caution: Liability shift can only be granted through 3D Secure!
Saferpay will return LiabilityShift: false, if the used payment method does not support 3D Secure at all! Please also check the used payment method, when making decisions, based on the LiabilityShift!
Information, about whether, or not a payment method does support 3DS, can be found in the respective Payment Methods chapter!
Attention: Only the Transaction interface and Payment Page processes do support 3-D Secure! Please keep that in mind, when implementing Saferpay!
Tip: If you want to always do a Challanged Flow, you can set Authentication.ThreeDsChallenge to FORCE. Saferpay will then always do a Challenged Flow!
Info: With 3DSv2 the XID value format changes (see respective request specification and below), while the VerificationValue is no longer returned!
1
"Liability": {
2
"LiabilityShift": true,
3
"LiableEntity": "THREEDS",
4
"ThreeDs": {
5
"Authenticated": true,
6
"LiabilityShift": true,
7
"Xid": "4ca1a5e4-f9fc-4081-873f-f02e30547c81",
8
"Version": "2",
9
"AuthenticationType": "FRICTIONLESS"
10
},
11
"InPsd2Scope": "NO"
12
}
Copied!
Recommended behaviors
It then depends on the merchant, how to proceed further. However Saferpay does recommend the following behaviors:
Attention: These are only recommendations! Your credit card contract can dictate otherwise. Please contact your acquirer/card processor for further information!
Tip: Only want to accept transactions with LiabilityShift? Check out the Condition-flag, that can be set within the Payment Page Initialize and Transaction Authorize requests, to control whether an authorization should be performed, or not, in the first place. Important Note: Issuers may reject the LiabilityShift with the authorization itself. The Condition-parameter does not cover such cases. Please still process the parameters accordingly!
Authenticated
LiabilityShift (Overall/3DS)
Liable Entity
Recommended behavior
Info
true
true/true
THREEDS
Everything is okay. Continue transaction
A full 3-D Secure authentication has been performed by the card holder. This is the best case scenario.
false
true/true
THREEDS
Continue transaction
In some cases, it can be, that the card holders bank grants the Liability Shift. For instance, some banks only require one 3-D Secure every 24 hours and the others will be approved, in order to speed up the payment process. The Liability Shift is still granted, however high risk businesses (Jewelery, Electronics, ect.) may want to stick to the highest level of security. It is your (The merchant) decision, if you want to accept these transactions, or if you want a full authentication.
true
false/true
MERCHANT
Abort transaction
In this case, the cardholder authenticated him-/herself successfully, but his/her bank still rejects the Liability Shift during authorization for internal reasons (Note that we -Saferpay- only get a rejection. The real reason is only known to the cardholder's bank). You are allowed to continue, but please note, that you (The merchant) will be liable in case of fraud (See above in this chapter). We recommend to not continue.
false
false/false
MERCHANT
Abort transaction
Similar to the previous case, but this time, the cardholder did not authenticate him-/herself successfully, which causes the LiabilityShift to be completely rejected. You are allowed to continue, but please note, that you (The merchant) will be liable in case of fraud (See above in this chapter). We highly recommend to not continue.
Attention: If you intend on doing a dummy authorization, using 3-D Secure as a card holder verification measure, we do not recommend an amount < 1,-! Small amounts often get rejected by issuing banks, thus causing issues, with amount 0 not being possible at all. However, if you just want to register and validate cards, without charging them, you may want to take a look at the Online Strong Card Check, you can perform with a standalone card registration!
Optional Parameters
If you want to keep the amount of Challenged transactions as low and thus your conversion-rate as high as possible, please make sure to submit a BillingAddress and DeliveryAddress within the PaymentPage Initialize or Transaction Initialize requests. This information will then be used for the scoring, as mentioned earlier, to increase the possibility of a frictionless transaction and thus a smooth experience for your customers!
Likewise, if you want to force a Challanged flow, for instance, if you have a high-risk business and are in need of a high level of protection, you can set the parameter Authentication.ThreeDsChallenge to FORCE.
Important: All other values, like the AVOID and the Exemption parameter underly the PSD2 rules! DO NOT submit these on your own accord, without having read and understood the PSD2 Chapter. Violating these rules may result in heavy consequences for you and your business! Authentication.ThreeDsChallenge = FORCE is the only value you may use, without considering these rules!
Last modified 1mo ago