3D Secure
Learn about 3D Secure
Three Domain Secure (3D Secure) is a regulatory requirement specified by EMVCo to ensure safe and secure online card transactions. 3D stands for the three domains that are the browser, the issuing bank, and the card network. It is a mandatory requirement that from 1.01.2021 merchants process all card transactions as 3D Secure.
Who is impacted?
3D Secure must be applied if:
- You are conducting business in European Economic Area (EEA)
- Your customers are in the EEA
- You are accepting card payments (credit or debit)
What is Strong Customer Authentication (SCA)?
Processing all card transactions as 3D Secure is a requirement from the Second Payments Services Directives (PSD2) for all transactions in the European Economic Area (EEA). This enables Strong Customer Authentication (SCA) to reduce fraud when paying online. You must have additional authentication checks when a customer is paying with cards on your website.
This could include any two of the following verification methods.
Something the customer knows | Something that the customer owns | Something that the customer is |
---|---|---|
Exclusive knowledge, such as the password or CVV. | A device or instrument that is registered with the consumer, such a mobile device. | Biometrics to identify the customer, such as face ID or fingerprint. |
Why do you need to be 3DS compliant?
Some of the reasons for being 3DS compliant are:
Regulatory requirements
It is mandatory to process card transactions as 3D Secure from 1st January 2021. It is possible that the payments are declined if the transaction is processed without applying 3D Secure.
Fraud prevention
Fraudulent transactions can be minimized to a great extent by verifying and authenticating the cardholder’s identity.
Higher conversion rates
It is now easier for the issuing banks to verify and authenticate the transactions. They are now able to avoid false declines. This generates more confidence for customers who are shopping on your portal.
Liability shift
If you are using 3DS-secured transaction workflow, it is possible that the liability in case of fraud and misrepresentation is with the issuer because they must authenticate the identity of the customer. The chargeback liability now shifts to the issuer. During full authentication where merchant, issuer, and card is registered as 3D Secure, the liability shifts to the issuer. If you, as a merchant, are not registered as 3D Secure, the liability shifts to you in case of a fraudulent transaction.
Decreased rejected transactions
The 3DS transactions are verified by the issuer and the card network, and hence the rejection rate of transactions is lower. The 3DS2 is also more user-friendly. The issuers are more confident of approval because of valid authentication.
Out of scope for SCA
There are certain cases in which card transactions are not subject to SCA and therefore the 3DS.
Recurring payment
If a customer signs up to a subscription or recurring billing for exactly the same amount with the same online seller, they will only need to authenticate the first time they pay. This is a great exemption for sellers like Netflix, but it won’t cover repeat payments if the amounts differ (for example, a weekly online grocery shop) or if the value changes (for example, if Netflix increases their prices).
Transaction Risk Analysis (TRA)
Some low risk transactions can be exempted from the Strong Customer Authentication (SCA) flow by the application of this exemption. To do this, we need to assess if your business qualifies for the exemption, verify the risk level of the transaction, and check the fraud levels to determine if an exemption is possible and what the current maximum basket amount can be. Please contact us to enable the standard option to apply TRAs. After it is enabled, you can control whether you want to request TRA in each transaction using the API flag if you want to keep the liability shift with the issuer for some cases.
Secure Corporate Payments (SCP)
Secure corporate payments can be exempted from the Strong Customer Authentication (SCA) flow if the transaction occurs in a B2B environment that is not accessible for the end clients. One example for such case would be a corporate travel agent keeping their clients’ corporate cards for business travel. Please contact us to enable the standard option to apply SCP. After it is enabled, you can control whether you want to request SCP in each transaction if the criteria for it qualifies as described previously.
Low Value Exemptions/Low Value (LVP)
Low-value exemptions allow payment providers to bypass Strong Customer Authentication (SCA) for transactions equal to or less than €30. This exemption can be applied up to five consecutive times or until the total reaches €150. If these limits are exceeded, a soft decline occurs, and the customer must complete the usual 3DS authentication process.
Payment providers must be aware that the cardholder’s bank determines the cumulative limits. The bank may require SCA after every fifth transaction or when the total value of transactions exceeds €150.
This exemption is primarily beneficial for transactions below €30 and may not be suitable for sellers with an average order value exceeding this amount.
Low-value payments under €30
This exemption allows payment providers to avoid applying strong customer authentication for online payments under €30 up to a certain cumulative limit. The customer’s bank has the choice to either request strong customer authentication on every sixth payment under €30 or request strong customer authentication if the combined value of several payments goes above €100.
Although it may look attractive on the surface, this exemption is tricky for online sellers and payment providers. The cardholder’s bank decides which cumulative limit to use, so it’s hard to know whether the bank will choose to limit the number of transactions or total value.
For example, a customer could make five payments of €10 and be challenged on the sixth, or make up to 10 payments of €10 before they need to authenticate.
This exemption also doesn’t help online sellers with an average order value above €30.
No exemption
If you have already exemptions configured on your account for your credit card transactions, you can send in the exemption type of the configured one in case more than one are configured to control the type of exemption. If you don’t send any flag the default exemption type is executed automatically. To avoid sending a transactions as exemption no_exemption
needs to be sent as a parameter. The logic only applies if exemptions are configured on your account.
One leg out
Payments where the card is issued outside of Europe or where the country you are acquiring from is outside of Europe.
Mail Order Telephone Order (MOTO)
Mail Order and Telephone Orders (MOTO) are excluded from 3D Secure Strong Customer Authentication (SCA) in all cases. MOTO transactions are not considered “electronic” payments and therefore do not fall within the scope of the PSD2 regulation.
3DS workflow
Below, you can see a diagram showing the workflow for a 3D Secure transaction.
- Create card resource based on the information that the customer enters in their browser. The cardholder’s email is used for identifying the customer for 3D Secure. The generated resource ID is used for charge or authorization.
- The Unzer API creates a
Charge
orAuthorization
transaction based on the payment workflow - Once the payment transaction is sent for
Authorization
orCharge
, the customer is redirected to the 3D Secure verification page provided by their bank using a redirect URL. The bank performs the verification and validation and redirects the customer to the shop after the payment. - The Unzer API sends the payment completed message to your shop. This is now displayed in the browser of your customer.