3-D Secure
PS3-D Secure – 3DS for short – is supported by Visa (Visa Secure), Mastercard (Mastercard ID check), American Express (SafeKey), Diners Club (ProtectBuy) and others and is intended as an anti-fraud measure.
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.
Worldline does not recommend to circumvent 3D Secure, as it is an anti-fraud measure!
We generally recommend to do 3D Secure wherever possible!
3D Secure is only available through the Payment Page, Integration Interface flows, or via the Standalone Secure Card Data registration, using the "ONLINE_STRONG" check function.
Transactions can be done via other means and flows, but those do not support 3D Secure!
Please make sure, that you use the above flows, if you want (or in case of PSD2 HAVE TO) use 3D Secure.
A transaction with the 3-D Secure process proceeds as follows:
The merchant sends the credit card details together with the relevant payment data to Saferpay.
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.
The 3DS request will be forwarded to the card-issuing bank via the CH’s Internet browser.
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:
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!).
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.
The result of this authentication is sent back to Saferpay.
Saferpay checks the result and ensures that no manipulation has occurred.
Saferpay links the 3DS data to the token used by the JSON API and uses this data automatically when authorising the card.
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?
LiabilityShift does not protect you against all cases of fraud and thereby chargebacks. It is merely one tool you have to your disposal.
Especially for high-risk business and business, that deal with huge amounts and extremely valuable goods (Electronics, Jewelery etc.), or for a first, or guest order of a card holder in your shop, we recommend forcing a 3DS-Challenge, so the card holder definitely has to confirm theis payment, through a full authentication.
You can set the parameter Authentication.ThreeDsChallenge to FORCE. Saferpay will then always do a Challenged Flow, granting a higher level of protection for your business.
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/liability shift:
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.
Transactions without liability shift
There are certain kinds of transactions, that do not have liability shift and it is important to know beforehand, in order to avoid unwanted chargebacks and fraud issues.
Here is a list of transactions, that generally do not offer liability shift:
Mail Phone Order Transaction: Mail Phone Order does not support 3D Secure in general and thusly does not know liability shift by design.
Recurring/MIT transactions: Merchant Initiated Transactions, like recurring transactions, installments, subscriptions, or just re-authorizations, without card holder presence, are exempt from liabilityshift. This also applies to processes, where 3D-Secure has been performed during the first capture of the card details. It is highly recommended to perform 3D Secure at this point and liability shift can be granted for this one time, but it is not extended onto the subsequent payments.
In general, liability shift through 3D Secure is only granted for the transaction/process, where 3D Secure is performed. For any new transaction, 3D Secure has to be performed again, if you want liability shift.
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 AuthenticationType and especially LiabilityShift. Furthermore LiableEntity will provide information about who will be liable in case of fraud.
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!
Info: With 3DSv2 the XID value format changes (see respective request specification and below), while the VerificationValue is no longer returned!
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!
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!
Forcing a 3DS Challenge
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.
While this setting does cover 99% of all transactions, Worldline has been made aware of certain banks behaving in a non-compliant manner.
Thusly, it can happen, that some transactions will be processed as frictionless, even though a challenge has been requested.
Please always check the AuthenticationType and make sure, that it is set to STRONG_CUSTOMER_AUTHENTICATION.
This behavior is currently out of the control of Worldline Saferpay and has been reported.
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!
Compliance and conversion-rate
Since 2024, the Schemes make it mandatory to submit certain parameters during a transaction, in order for 3DS to work and the authorization to be accepted. This also helps to minimize the risk of a 3D Secure challenge, reducing the number of redirects needed and thusly the friction for your customers during checkout, making the experience smoother and increasing the conversion-rate.
Saferpay already collects certain data-points automatically, like:
Card Holder Name: This field is displayed by default on all Saferpay forms.
Browser-Data: Saferpay does collect this data upon redirect to Saferpay. However, you can also pass it to Saferpay beforehand.
IP-Address: Saferpay does capture the IP automatically, upon redirect, though you can submit it beforehand, using the Address containers.
The following data-points are NOT captured automatically and need to be captured and submitted by you:
Card Holder E-Mail: The E-Mail must be submitted, by using the address-containers, as described below.
Capturing the address
While for the most part optional, the more data you submit, the higher the chance of avoiding a 3DS Challenge. So if you want to minimize the friction for your customers, Saferpay recommends, that you submit their whole address, using the Payer.BillingAddress and DeliveryAddress containers, within the respective Initialize requests. If you only have one of the two, or if they are the same, simply submit the same address with both.
Capturing browser-data
In order for the 3DS fraud-scoring to work, Saferpay has to submit certain data-points towards the 3DS provider, like the customer addresses (see above) and also certain browser information.
This data is then only used for the scoring process, to evaluate, if a frictionless-flow is applicable, or if the risk is too high, so a 3D Secure challenge has to be performed.
Payment Page
The Saferpay Payment Page does collect the necessary data upon redirect. No additional steps are needed.
Transaction Interface
The Transaction Interface, due to its more integrated nature, can do it in two ways:
Like the Payment Page, the necessary data is collected automatically upon redirect to the RedirectUrl.
The merchant can alternatively submit the necessary data with the Transaction Initialize, within the Payer-container:
This data will then be forwarded to the 3DS-provider, which could lead to the redirect towards the RedirectUrl not being necessary. The parameter RedirectRequired inside the Transaction Initialize response would then be set to false and no RedirectUrl will be returned. This can be used to streamline the user-experience on your site, through negating the need for a redirect, in case of a frictionless flow.
Last updated