Accueil | Payment institution | Security | 3DSecure 2.0

Limit your financial risk with 3DSecure 2.0

Our services integrate all 3DSecure 2.0 processes for full PSD2 compliance, while enhancing your payment experience.

écran de téléphone qui montre la vérification 3D Secure 2.0 à réaliser par le porteur de carte

Strong authentication

Mandatory validation of cardholder identity

Since 2019, the Payment Services Directive No. 2 (PSD2) has introduced several requirements aimed at limiting the risk of fraud and protecting banking information, especially through strong customer identification.
In the second version of the online payment security protocol, 3DSecure 2.0, each transaction is subject to Strong Customer Authentication (SCA) to certify that it has been carried out by the cardholder.
To do this, the payer must enter at least 2 of the 3 authentication factors defined by the European Banking Authority (Regulatory Technical Standards – RTS):

Knowledge of information (password, secret question, secret code, identification number, diagram, etc.)

Property in possession (cell phone, connected device, token, card, badge, etc.)

Inherent attribute that characterizes the payer (fingerprint, facial, voice or iris recognition...)

Risk assessment to streamline customer card transactions

Strong authentication is decided by the issuing bank. In certain cases, the latter grants merchants an exemption from 3DSecure 2.0, allowing them to bypass systematic strong authentication.
In this configuration, the bank relies on a risk score, calculated by using additional data to put the payment into context. Contextual analysis is achieved by sharing nearly 150 data items from

From the phone,in the case of mobile payment

From the browser, in the case of payment executed from a computer

The merchant risk

This operation takes place in the background and does not disrupt the payment process.

The 12 types of data collected on mobile platforms include :

The type of platform used with the cardholder's IP address
Device name and model, screen resolution
Operating system and OS version
Time zone and device position

The data captured from the customer's browser is, in some cases, similar to the information discussed in the mobile section. They are divided into 9 categories:

Accept Headers: indicate the content types (MIME) that the browser is able to understand.
IP address: the IP address of the computer on which the browser is running.
Java Enabled: indicates whether the browser is Java-enabled
Language: indicates the language used by the cardholder's browser.
Screen Colour Depth: indicates the depth of the color palette used to display images on screen.
Screen Height: indicates the total height of the holder's screen in pixels
Screen Width: indicates the total width of the cardholder's screen in pixels.
Time Zone: indicates the time difference between UTC and the cardholder's local time.
User-Agent: indicates the exact content of the HTTP User-agent header.

To enrich the transaction with contextual data and minimize the risk, the bank can collect and use additional cardholder information.

The "customer account": the customer data held by the merchant as part of a registered account (age of the account, dates of any changes made to the account, delivery address and frequency of transactions, including successful and abandoned transactions, etc.).
Purchases: the customer's purchasing habits, whether the products or services purchased have been ordered before (new item order indicator), where the order is shipped (shipping indicator) and whether the order is purchased in advance (pre-purchase order indicator).
Authentication of past transactions: possible friction during transactions (request for additional authentication, date and time of previous attempts).

Authentication of the cardholder's merchant account: customer login on the merchant account, transaction medium (browser or mobile application). Optional information may include issuer credentials and third-party authentication (Google, Apple). If the existing information is not available to the cardholder, the data is set as Guest.

Exemptions

Other 3DSecure 2.0 protocol exemptions

For payments under €30
For low-risk merchants
For recurring payments (subscriptions)
For trusted beneficiaries, whitelisted merchants
For business card payments
For MOTO transactions
For transactions outside Europe

Frequently asked questions

All about 3DSecure 2.0 with CentralPay

Considered as an evolution of the 3DSecure protocol, version 2.0 offers new advantages:

Data oriented: It uses a more intelligent approach, by collecting more data on the transaction to assess the level of risk and determine whether authentication is required.
Enhanced user experience: To reduce friction and avoid damaging the user experience, 3DSecure 2.0 incorporates strong authentication more seamlessly into the payment process.
Enhanced security: With more advanced authentication and analysis methods, 3DSecure 2.0 enables more accurate identification of fraudulent transactions, while reducing false positives.
Multi-device: Unlike its first version, 3DSecure 2.0 is now supported on a wide variety of devices, offering smoother authentication on all media, including smartphones and tablets.

The new version of the 3DSecure protocol requires issuing banks to perform strong authentication for every payment.

In practice, these are based on the analysis of some factors, in order to calculate the transaction's risk score. If payment conditions are considered normal and risk-free, cardholders can benefit from frictionless authentication, without redirection to their bank's application.

3DSecure 2.0 meets the authentication requirements defined by the Regulatory Technical Standards (RTS) published by the European Banking Authority (EBA) and approved in 2018.

In 2019, as part of the Payment Services Directive No. 2 (PSD2), the European Parliament has made Strong Customer Authentication (SCA) mandatory in order to limit the risk of fraud.

No. The protocol is designed to add an extra layer of security to online payments, protecting both e-merchants and consumers by reducing the risk of credit card fraud.

Limit your financial risk with 3DSecure 2.0

Mandatory validation of cardholder identity

Risk assessment to streamline customer card transactions

Other 3DSecure 2.0 protocol exemptions

Frequently asked questions

How does 3DSecure 2.0 differ from its previous version?

Will payment always require strong authentication?

How is the 3DSecure 2.0 protocol regulated?

Can I disable 3DSecure 2.0 authentication for payments?

Ready to get started with CentralPay?