Secure
customer paymentsStreamline
your journeyReduce
compliance costsA fully mastered
regulatory framework
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:
Password, secret code, secret question...
Mobile phone, connected device, token, badge...
Fingerprint, facial or voice recognition...
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 :
Telephone (for mobile payments)
- 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 browser (in the case of a browser payment)
- 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.
The merchant risk
- 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
Our strong authentication protocol
How does 3DSecure 2.0 differ from its previous version?
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.
Will payment always require strong authentication?
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.
How is the 3DSecure 2.0 protocol regulated?
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.