Content 3DSV2
| Sommaire | ||||
|---|---|---|---|---|
|
| Développer | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
|
What is DSP2 ?
The new Payment Services Directive (DSP2) initiated by the European Commission has been applied since 01/13/2018.
Objective: Strengthen the security of online payments
The European Banking Authority (EBA) has developed implementing measures called Regulatory Technical Standards (RTS) which will come on 09/14/2019.
DSP2 will make SCA (Strong Customer Authentication) or two-factor authentication mandatory for online transactions.
What is SCA strong authentication ?
To strengthen the protection of buyers during remote payments, the PSD2 makes mandatory SCA (Strong Customer Authentication) authentication, also known as “two-factor authentication”.
Strong buyer authentication requires verification of at least two of the following 3 factors:
- Knowledge: what the buyer knows (PIN, password);
- Possession: what the buyer has (card, mobile, token);
- Inherence: what the buyer is (fingerprint, facial recognition, iris).
which are independent of each other in the sense that the compromise of one does not lead to the compromise of the other.
| Extrait | ||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||
Catégorisation des facteurs d’authentification forte (SCA)
|
Although not recognized as a strong authentication method by the European banking authority, the SMS-OTP will still be used until new methods (biometrics for example) take over.
This method, adopted massively by buyers, has helped to significantly lower the fraud rates for e-commerce card payments. It is currently the most common among banks (86%).
What are the impacts for your activity ?
PSD2 applies to banks and not to merchants, which means that issuing banks that accept non-compliant transactions run the risk of being outlawed.
All transactions are not subject to RTS (see out-of-scope cases and exemptions).
- In the case of an out of scope transaction, strong authentication is not required.
- If a transaction falls within the scope of an exemption, strong authentication is optional and the choice to strongly authenticate is in the hands of the buyer's bank.
- If a transaction does not fall within the scope of an exemption, strong authentication is mandatory.
Strong authentication impacts the user journey and the acceptance rate, in particular on mobile, so it should only be triggered for risky transactions.
The objectives for the merchant are therefore:
- compliance in order to avoid refused transactions;
- maintaining an optimal user experience;
- reducing fraud.
We provide you with the tools to achieve these goals.
3DS V2
The rules describing SCA are technically neutral and do not impose any particular method.
The 3DS V2 protocol provides a mechanism which enables strong authentication to be carried out in accordance with the DSP2.
The main advantage of 3DS is to shift the responsibility for possible fraud from the merchant to the card issuer, which reduces chargebacks.
However, many merchants do not use the 3DS solution due to loss of conversion rates and service costs.
As a reminder, the main disadvantage of the 3D-Secure 1.0 version :
- payment process can be complicated or confusing for a cardholder, resulting in lower conversion (abandoned carts issue);
- 3-D Secure 1.0 does not adapt well to mobile devices;
- lack of seamless integration with modern payment tools such as wallets;
- limited set of possible authentication methods, some of which are obsolete and dangerous (date of birth);
- very limited ability of frictionless clearance based on score.
Major developments in the new 3-D Secure 2.0 specification.
Functionality | Profit |
|---|
Risk-Based Authentication (RBA) |
Permet une authentification passive sans challenge du porteur de la carte (mode frictionless) pour une majorité de transactions.
Gestion du risque orientée données
Utilisation de plusieurs données incluant les caractéristiques du device, les informations du compte du porteur et de sa localisation, afin de fournir une évaluation du risque suffisamment fine permettant ainsi de réduire le recours à une authentification forte du porteur.
Support natif des dispositifs mobiles
Conçu pour supporter les workflows e-commerce natifs et web fournissant ainsi une expérience fluide sur l’application mobile commerçant quel que soit le device (achat In-App).
Intégration souple dans le parcours client du marchand
Permet au marchand d’embarquer l’authentification dans le tunnel d’achat, maintenant ainsi une expérience utilisateur cohérente.
Support de la biométrie et d’autres méthodes
Réduit les frictions au niveau de l’expérience utilisateur.
Flags dans les messages afin de supporter les dérogations liées à la DSP2
Permet aux marchands et aux acquéreurs de préciser aux émetteurs quand ils souhaitent appliquer une exemption et prendre la responsabilité de la transaction.
La plus grande différence avec 3DS 1.0 réside dans le flux « frictionless » qui permet à l'émetteur d'approuver une transaction sans interaction du titulaire de la carte sur la base d'une authentification basée sur les risques effectuée dans l'ACS.
Allows passive authentication without challenge for the cardholder (frictionless mode) for a majority of transactions. | |
Data-driven risk management | Use of several data including the characteristics of the device, the information of cardholder's account and its location, in order to provide a sufficiently detailed risk assessment thus making it possible to reduce the use of strong authentication of cardholder. |
Native mobile device support | Designed to support native e-commerce and web workflows, thus providing a fluid experience on the mobile merchant application regardless of the device (In-App purchase). |
Flexible integration into the merchant's customer journey | Allows the merchant to embed authentication in the payment process, thus maintaining a consistent user experience. |
Support for biometrics and other methods | Reduces friction in the user experience. |
Flags in messages to support derogations related to DSP2 | Allows merchants and acquirers to tell issuers when they want to apply an exemption and take responsibility for the transaction. |
The biggest difference with 3DS 1.0 is the “frictionless” flow which allows the issuer to approve a transaction without cardholder interaction based on risk-based authentication performed in the ACS.
Thanks to these developments, buyers' banks will have access to more information allowing them to refine decision support scoring for triggering strong authentication (or not Grâce à ces évolutions, les banques des acheteurs auront accès à un plus grand nombre d’informations leur permettant d’affiner le scoring d’aide à la décision pour le déclenchement d’une authentification forte (ou non / frictionless).
3DS 2.0
permet de résoudre plusieurs problèmes techniques desolves several technical issues of 3DS v1.0.
Comme une optimisation des parcours acheteurs, rendant le processus de paiement plus aisé pour les achats sur navigateur et inapp, l'introduction d'un flux d'authentification sans friction et une sécurité renforcée.L'authentification 3DS V1 restera possible jusqu'à la fin 2020. A partir de 2021, toutes les authentifications 3DS devront utiliser laSuch as optimizing buyer journeys, making the payment process smoother for browser and inapp purchases, the introduction of a frictionless authentication flow and enhanced security.
3DS V1 authentication will remain possible until the end of 2020. From 2021, all 3DS authentications must use version 2.
How to comply with DSP2 ?
La méthode d'authentification 3DSecure répondra aux exigences des RTS - SCA à partir du 14/09/2019.
Il faut cependant distinguer les cas suivants:
- Cas 1 : 3DS systématique
Un marchand réalisant actuellement une authentification 3DS V1 de manière systématique sera en conformité avec la DSP2.
- Cas 2 : 3DS sélectif
Un marchand réalisant actuellement une authentification 3DS V1 de manière sélective s'expose à un refus de la banque de l'acheteur pour les transactions non 3DS.
- Cas 3 : pas d'authentification réalisée
Un marchand ne réalisant actuellement aucune authentification s'expose à un refus de la banque de l'acheteur pour toutes ses transactions.
Nous vous recommandons dans tous les cas d'envisager dès à présent une migration vers le protocole 3DS V2 afin d'être prêt à bénéficier de ses avantages et notamment du frictionless.
Afin d'intégrer le protocole 3DS V2, veuillez consulter l'article suivant 3DSv2 - Comment intégrerThe 3DSecure authentication method will meet the requirements of RTS - SCA from 09/14/2019.
We must however distinguish the following cases:
- Case 1: systematic 3DS
A merchant currently performing a 3DS V1 authentication systematically will be in compliance with the DSP2. - Case 2: selective 3DS
A merchant currently performing 3DS V1 authentication selectively is subject to refusal by the buyer's bank for non-3DS transactions. - Case 3: no authentication performed
A merchant who does not currently perform any authentication is liable to a refusal by the buyer's bank for all his transactions.
In any case, we recommend that you consider migrating to the 3DS V2 protocol now in order to be ready to benefit from its advantages and in particular frictionless.
In order to integrate the 3DS V2 protocol, please consult the following article 3DSv2 :
Associated pages
| Contenu par étiquette | ||||||||
|---|---|---|---|---|---|---|---|---|
|