3D Secure 2.0
Principes du 3DS 2.0
Bien qu’il renforce la sécurité par une meilleure couverture des risques d’impayés, le protocole 3D Secure V1 est souvent décrié pour son manque d’ergonomie. Il est en effet responsable d’une perte de conversions des clients fidèles et reste contraignant pour s’authentifier sur un smartphone où il faut jongler entre la réception du SMS et la validation du code sur le même écran. Le 3D Secure 2.0 se présente comme un correctif majeur avec une promesse de renforcement de la sécurité sur toutes les transactions tout en rendant le parcours client plus simple et sans friction.
Pour les banques, plus besoin de demander systématiquement une authentification à chaque transaction. Celle-ci se base maintenant sur l’analyse des risques encourus par l’exploitation de données complémentaires, en replaçant le paiement dans son contexte.
Les risques de paiements frauduleux sont ainsi mieux évalués grâce au partage par les commerçants de près de 150 données complémentaires qui sont envoyées lors du paiement vers la banque du consommateur. Cette nouvelle approche permet ainsi de se soustraire à une authentification forte et systématique. Celle-ci n’étant réalisée que sur décision de la banque émettrice et que pour les transactions les plus risquées.
En complément et afin d’être conforme avec la Directive des Services de Paiements 2 (DSP2), un paiement soumis à une authentification forte (Strong Customer Authentication – SCA*) devra rapprocher au minimum de 2 informations suivantes :
- la connaissance d’une information par l’utilisateur
(ex. : mot de passe, une question secrète, un code secret, un numéro d’identification, un schéma…) - une chose en sa possession
(ex. : téléphone portable, appareil connecté, token, carte à puce, badge) - une information qui lui est propre et qui le caractérise
(ex. : une empreinte digitale, la reconnaissance faciale, la reconnaissance vocale, la reconnaissance d’iris…)
Les modes d’authentifications seront soumis à des changements progressifs qui s’accompagneront dans le temps pour ne pas détériorer les habitudes des consommateurs.
Fonctionnement du 3DS 2.0
Lors d’un paiement en ligne, que ce soit via un navigateur ou un smartphone, la banque du porteur de carte va procéder à une évaluation du risque est se basant sur l’analyse contextuelle des près de 150 données en provenance:
- du téléphone dans le cas d’un paiement mobile
- du navigateur (browser)
- du risque marchand
Cette opération se passe en tache de fond et ne perturbe pas le processus de paiement. Les données doivent néanmoins être envoyées lors de la transaction.
A titre d’information, voici les données échangées :
1. Pour les paiements sur smartphone
À titre d’exemple, parmi les 12 éléments communs à toutes les plateformes mobiles on retrouve :
- le type de plateforme utilisée avec l’adresse IP du porteur
- le nom et le modèle du périphérique, la résolution de l’écran
- le système d’exploitation ainsi que la version d’OS est également inclus
- le fuseau horaire et la position de l’appareil
2. Pour les paiements depuis un navigateur
Les données capturées depuis le navigateur du client sont, dans certains cas, similaire aux informations évoquées ci-dessus et provenant d’un smartphone.
Elles sont réparties en 9 catégories :
- Accept Headers (en-têtes) : indiquent les types de contenu (MIME) que le navigateur est capable de comprendre.
- Adresse IP : l’adresse IP du PC sur lequel le navigateur est en cours d’exécution.
- Java Enabled : indique si le navigateur est activé Java
- Language : indique la langue utilisée par le navigateur du détenteur de la carte.
- Screen Colour Depth : indique la profondeur de la palette de couleurs utilisée pour l’affichage des images à l’écran.
- Screen Height : indique la hauteur totale de l’écran du détenteur en pixels
- Screen Width : indique la largeur totale de l’écran du détenteur de carte en pixels.
- Time Zone : indique la différence de temps entre l’UTC et l’heure locale du détenteur de la carte.
- User-Agent : indique le contenu exact de l’en-tête HTTP User-agent.
3. Pour l’analyse du risque marchand
Afin d’améliorer l’exactitude de l’authentification basée sur les risques, la banque a la possibilité de collecter et d’utiliser des informations supplémentaires sur les titulaires de carte. Ces données additionnelles ne sont pas obligatoires, mais fortement recommandées.
- Le “compte client” :
Concerne les données du client détenues par le commerçant dans le cadre d’un compte enregistré. Cela comprend des informations basiques telles que l’âge du compte, les dates de toute modification apportée au compte, l’adresse de livraison et la fréquence des transactions, y compris les transactions réussies et abandonnées. - Les achats :
Se rapportent aux habitudes d’achat du client, si les produits ou les services achetés ont été commandés auparavant (indicateur de nouvelle commande d’articles), lieu où la commande est expédiée (indicateur d’expédition) et si la commande est achetée en amont (indicateur de commande pré-achat). - L’authentification des transactions passées :
Concerne les éventuelles frictions durant les transactions ou si le détenteur de carte a été confronté à une demande d’authentification supplémentaire. Les informations supplémentaires peuvent inclure la date et l’heure des tentatives d’authentification précédentes. - L’authentification du compte marchand du titulaire de carte :
Cette catégorie fait référence au login client sur le compte marchand et si l’opération s’est déroulée sur un navigateur ou une application mobile. L’information optionnelle pourrait inclure des justificatifs concernant l’émetteur et l’authentification de tiers, (Google par exemple). Si l’information existante n’est pas disponible sur le détenteur de la carte, les données sont paramétrées en Guest (invité).
L’objectif est donc d’enrichir la transaction avec le maximum de données contextuelles afin d’apporter toutes les garanties à l’émetteur et éviter une demande d’authentification forte.
Calendrier de déploiement prévisionnel
1. Europe
- Septembre 2019 : entrée en vigueur de la directive concernant l’authentification forte des clients.
- Rappel des dates de SCA selon les pays
2. France
En France, l’authentification renforcée se fait selon les paliers suivants :
- 1er octobre 2020 : transactions de plus de 2 000 euros
- 5 janvier 2021 : transactions de plus de 1 000 euros
- 15 février 2021 : transactions de plus de 500 euros
- 15 mars 2021 : transactions de plus de 250 euros
- 15 avril 2021 : transactions de plus de 100 euros
- 15 mai 2021 : transactions de plus de 30 euros
2. Canada, LAC (Latin America and the Caribbean) & US
- Déploiement : aout 2019
3. CEMEA (Central Europe, Middle East and Africa)
- Déploiement : avril 2020
- D’ici à fin 2020, le protocole 3D Secure 2.0 sera donc implémenté à échelle globale.
Transfert de responsabilité
- Les règles 3D Secure 2.0 :
La transaction est entièrement authentifiée avec 3D Secure 2.0. - Responsabilité juridique :
L’émetteur est responsable de la fraude.
- Les règles 3D Secure 2.0 :
Le Marchand est en conformité avec 3D Secure 2.0, l’émetteur ne satisfait pas les mesures de 3D Secure 2.0.
Une tentative d’authentification de 3D Secure 2.0 a été initiée. - Responsabilité juridique :
L’émetteur est responsable de la fraude.
- Les règles 3D Secure 2.0 :
Le Marchand est entièrement conforme à 3D Secure 2.0. L’émetteur est également en conformité avec 3D Secure 2.0.
La transaction n’est pas authentifiée en raison de contestation. - Responsabilité juridique :
Le Marchant est responsable de la fraude.
- Les règles 3D Secure 2.0 :
Le Marchand satisfait aux règles de 3D Secure 1.0 mais pas à celles de 3D Secure 2.0.
Une transaction est rétrogradée au niveau de 3D Secure 1.0, ce qui entraîne une authentification complète du détenteur de la carte. - Responsabilité juridique :
L’émetteur est responsable de la fraude. Notez cependant que 3D Secure 1.0 pourrait ne pas être compatible avec DSP2 (Authentification forte du client), ce qui pourrait entraîner un léger recul lors de l’autorisation.
- Les conditions de DSP2 :
Authentification forte non appliquée.
Pas d’exemption appliquée. - Responsabilité juridique (Visa, MasterCard) :
Refus donc pas d’autorisation.
- Les conditions de DSP2 :
Authentification forte appliquée – 3D Secure 2.0 réalisé.
Pas d’exemptions. - Responsabilité juridique (Visa, MasterCard) :
L’émetteur est responsable.
- Les conditions de DSP2 :
Authentification forte appliquée – L’émetteur ne prend pas en charge 3DS 2.0.
Pas d’exemptions.
Tentatives AAV/CAVV sont renvoyées à l’acquéreur. - Responsabilité juridique (Visa, MasterCard) :
L’émetteur est responsable.
- Les conditions de DSP2 :
Le marchand a demandé une exemption d’autorisation forte via la procédure d’authentification – Exemption acceptée par l’émetteur.
Pas de friction. - Responsabilité juridique (Visa, MasterCard) :
Le marchand est responsable.
- Les conditions de DSP2 :
Le marchand a demandé une exemption d’autorisation forte via une la procédure d’autorisation.
Sans friction. - Responsabilité juridique (Visa, MasterCard) :
Le marchand est responsable.
- Les conditions de DSP2 :
Authentification forte appliquée par l’acquéreur – L’émetteur examine l’authentification et choisit d’appliquer une exemption.
Sans friction. - Responsabilité juridique (Visa, MasterCard) :
L’émetteur est responsable.
- Les conditions de DSP2 :
Refus par l’émetteur de l’exemption de l’authentification forte. - Responsabilité juridique (Visa, MasterCard) :
L’émetteur est responsable.
Exemptions possibles
Des exemptions d’authentifications fortes sont néanmoins prévues. On peut citer entre autres les cas d’exemption suivants :
1. Pour les paiements inférieurs à 30 euros
Si un paiement est inférieur à 30 euros, une exemption est appliquée car il est considéré comme une transaction de faible valeur.
Cependant au-delà de 5 transactions exemptées cumulées ou si la somme des transactions dépasse 100 euros, l’authentification forte du client peut de nouveau être requise.
2. Pour les marchands à faibles risques
CentralPay est autorisé à effectuer, en tant que fournisseur de moyen de paiement, une analyse des risques en temps réel. Elle permet de procéder, si nécessaire, à une authentification forte du client lors d’une transaction.
L’analyse du taux de fraude effectuée par CentralPay tient compte de comportement, des dépenses, de l’historique des scénarii d’achat, de la localisation du client et de l’entreprise.
L’exemption à faible risque s’applique si les seuils des taux de fraude pour les montants indiqués ne sont pas dépassés.
Taux de fraude et montants :
- Taux de fraude de 0,13% pour les transactions d’un montant allant jusqu’à 100 euros
- Taux de fraude de 0,06% pour les transactions d’un montant allant jusqu’à 250 euros
- Taux de fraude de 0,01% pour les transactions d’un montant allant jusqu’à 500 euros
3. Pour les paiements récurrents (les abonnements)
En cas de paiements récurrents l’exonération s’applique dans les cas suivants :
- 1ère transaction fortement authentifiée.
- Transactions suivantes sans authentification si elles sont de même montant et depuis le même commerçant.
- Les transactions initiées par le marchand : résultent d’un accord explicite (un mandat) établi entre ce dernier et le client concernant la fréquence des transactions. Il est à noter que cela couvre les cas d’utilisation de transactions récurrentes. Dans ce cas l’authentification forte n’est requise que lors de la définition du mandat.
4. Pour les bénéficiaires de confiance, les marchands inscrits sur liste blanche
Le client peut inscrire sur liste blanche (whitelister) des commerçants en qui il a confiance. Les commerçants, ainsi authentifiés comme “bénéficiaires de confiance”, sont ajoutés à une liste qui est mise à jour par la banque du client. Il est à noter que l’authentification forte du client est nécessaire lors la première transaction mais pas pour les suivantes et également lors de la création, confirmation et modification de la liste blanche. En prenant comme référence la dernière authentification forte du client, l’inscription sur liste blanche, qui s’applique aux paiements par carte et aux virements bancaires, permet une plus grande flexibilité concernant les montants, le nombre de transactions et la période des paiements.
5. Pour les paiements par carte d’affaires
Cette exemption couvre les transactions effectuées par des numéros de cartes virtuelles ou des cartes d’entreprise servant à gérer les frais de déplacements des employés auprès d’agents de voyage en ligne.
Seule la banque du détenteur de carte est autorisée par la réglementation en vigueur à demander cette exemption, car ni l’entreprise ni le fournisseur de moyen de paiement ne sont pas en mesure d’identifier l’appartenance de la carte.
6. Pour les transactions MOTO
Les transactions Mail Orders & Telephone Orders (MOTO) ne rentrent pas dans la catégorie des paiements électroniques. Elles sont donc exemptées d’une procédure d’authentification forte du client.
7. Pour les transactions hors Europe
La transaction est exemptée si l’émetteur ou l’acquéreur d’une transaction n’est pas localisé en Europe. Une fois les directives de la DSP2 mises en application, les transactions provenant d’acheteurs non-Européens seront vraisemblablement acceptées.
Implications pour les commerçants
CentralPay a intégré l’ensemble des processus dans ses traitements afin de vous permettre de tirer profit de cette nouvelle version du 3DS : plus de sécurité, expérience de paiement améliorée.
Nos services sont ainsi 100% compatibles avec la DSP2 et le 3D Secure 2.0.
