Latest-generation
strong authentication protocol

CentralPay integrates smooth, compliant identity verification protocols, with no impact on the payment experience

Talk to an expert
See our pricing

Secure

customer payments

Streamline

your journey

Reduce

compliance costs

A fully mastered
regulatory framework

service d'authentification forte : étape de validation d'identité sur l'interface bancaire

To protect banking information and reduce fraud, PSD2 has introduced customer identification requirements.

In accordance with the online payment security protocol, each transaction must be subject to a strong authentication (Strong Customer Authentication) to certify that it has been carried out by the cardholder.

The payer must provide at least 2 of the 3 authentication factors defined by the European Banking Authority:

Knowledge of information

Password, secret code, secret question...

Property in its possession

Mobile phone, connected device, token, badge...

Inherent attribute

Fingerprint, facial or voice recognition...

3D Secure 2.0 protocol

Streamline card transactions
by assessing risk

Strong authentication is decided by the issuing bank. This is based on a risk score, calculated by using additional data to put the payment into context.

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

If the cardholder’s payment conditions are considered to be normal, they will be able to benefit from frictionless authentication, with no redirection to the banking application. In the opposite case, strong authentication will be required.

Contextual analysis is made possible by the sharing of almost 150 data items from :

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.

Some examples of exemptions
to the 3DS 2.0 protocol

Under certain conditions, the payer’s bank may waive the requirement for systematic authentication

emoji paiement de -30€
Payments under 30 euros
emoji paiement récurrent
Recurring payments (subscription, in instalments, etc.)
emoji paiement par carte business
Business card payments
emoji marchands à faible risque
Low-risk merchants
emoji transactions hors Europe
Transactions outside Europe
emoji bénéficiaires de confiance
Trusted, white-listed beneficiaries
emoji transactions MOTO
Certaines transactions MOTO (Vente par correspondance/par téléphone)
Question boxes

Our strong authentication protocol

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.
3D Secure 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 2 (PSD2), the European Parliament 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.