Pour commencer, la DSP2 : La Directive sur les Services de Paiement 2, permet de sécuriser les paiements électroniques grâce à l’authentification forte du porteur pour les transactions électroniques. Elle s’applique aux 28 pays de l’Espace Économique Européen et concerne tous les marchands qui processent leurs paiements par carte via un acquéreur européen.
L’entrée en vigueur initiale et communiquée par l’EBA (European Banking Authority) était le 14 Septembre 2019.
En accord avec les autorités bancaires locales, la date d’entrée en vigueur de la DSP2 a été décalée de 12 à 18 mois en fonction des pays pour permettre à tous les acteurs de l'écosystème d’être prêts.
(Strong Customer Authentication pour les plus bilingues d’entre nous)
Destinée à renforcer la sécurité lors des paiements électroniques, l’Authentification forte a pour but de vérifier l’identité du porteur de carte. Pour cela, au moins deux éléments parmi les trois facteurs d'authentification suivant doivent être validés :
L’indépendance de ces éléments garanti en cas de compromission de l’un des facteurs, l’intégrité du second.
Veuillez comprendre Regulatory Technical Standards. Les RTS sont l’ensemble des normes techniques qui définissent les exigences constituant la DSP2.
Contrairement à la V1, cette évolution permettra aux marchands de proposer à leurs clients finaux des parcours d’achat plus fluides, sans redirection et comportant moins de points de friction.
Il offrira une protection renforcée contre les transactions frauduleuses grâce à une analyse de risque des transactions se basant sur plus de 150 données contextuelles collectées lors de l’achat.
Avec 3D Secure V2, l’authentification du client final s’effectuera directement au sein de la page de paiement, et sera entièrement compatible avec les environnements web mobiles/desktop, et achats in-app. La version 2 du protocole permettra de garder le client final sur la page de paiement, contrairement à la version antérieure qui obligeait une redirection vers une page mise à disposition par l’émetteur.
Le 3D Secure V2 s’appliquera à tous les paiements électroniques comme les paiements en ligne, les paiements mobiles, les paiements in-app, ou ceux effectués via des objets connectés.
Il s’agit du transfert de responsabilité vers la banque du porteur de carte (l’émetteur). En tant que marchand, si une transaction a bénéficié d’une authentification forte, mais qu’elle fait par la suite l’objet d’une contestation liée à de la fraude, vous n’en n'assumerez pas le coût (chargeback).
Les exemptions correspondent aux transactions pouvant faire l’objet d’une dérogation d'authentification forte tel que le prévoit la DSP2.
Un marchand peut demander l’application d’une exemption à l’émetteur (dans ce cas-là, pas de transfert de responsabilité appliqué si l’exemption est acceptée par ce dernier), mais les émetteurs peuvent également appliquer d’eux même une exemption (avec transfert de responsabilité)
Voici les cas d’exemptions permises par la DSP2 :
Transactions exemptées d’authentification forte
Les marchands peuvent bénéficier d’exemption d’authentification forte auprès des émetteurs pour les transactions telles que décrites ci-dessous :
Enfin, d’autres transactions ne sont tout simplement pas assujetties à la DSP2 :
Les transactions hors périmètre
Également appelées données transactionnelles, ces données sont collectées lors du processus d’achat conjointement par les marchands et par HiPay. Elles sont ensuite envoyées à l'émetteur. L'émetteur se base sur ces données pour effectuer une analyse de risque et décider du statut à accorder à la transaction.
Si la transaction est à faible risque et rentre dans le cadre d’exemptions prévues par la DSP2 alors l’authentification forte ne sera pas déclenchée, le parcours de paiement sans friction pour l’utilisateur final.
À l’inverse, si la transaction présente un risque, l’utilisateur final sera invité à s’authentifier fortement.
Dans ces deux cas, le transfert de responsabilité vers l’émetteur sera appliqué, sauf si le marchand est à l’origine de la demande d’exemption.
Les soft decline sont des refus d’autorisation pour cause de non-authentification de la transaction. En effet, avec la DSP2, toutes les transactions doivent passer par la case de l’authentification, et ne peuvent être envoyées directement en autorisation (sauf si la transaction ne rentre pas dans le périmètre de la DSP2).
En cas de non-respect de cette règle, les émetteurs déclineront la transaction sous la forme d’un nouveau code retour d’autorisation appelé “soft decline” (pour les différentier des hard decline).
Votre site n'est pas encore en conformité avec les nouvelles règles de la DSP2 ? Recevez les conseils d'un expert ici.