Résumé
Plus connu sous ses dénominations commerciales Visa Secure, Mastercard Identity Check ou American Express SafeKey, le protocole 3D Secure vise à réduire la fraude et à renforcer la sécurité des paiements en ligne.
Le protocole 3D Secure 2 (3DS2) offre un « flux d'authentification simple » et améliore l'expérience d'achat par rapport à l'ancienne version, 3D Secure 1. Il s'agit du protocole le plus souvent utilisé pour assurer la conformité aux exigences de l'authentification forte du client en Europe et le principal mécanisme permettant aux entreprises de demander des exemptions à la SCA.
Nous prenons en charge le protocole 3D Secure 2 sur nos API de paiement, nos trousses SDK mobiles et Checkout.
Un bref historique de 3D Secure 1
Malgré le recours à des mesures de sécurité supplémentaires, telles que le système de vérification d'adresses (AVS) ou la vérification du code CVC, certains paiements par carte de crédit et de débit peuvent comporter un niveau de risque de fraude très élevé. (C'est d'ailleurs parce que ce risque existe que les clients ont la possibilité de contester les paiements frauduleux effectués avec leur carte.)
Pour faire face à ce problème, les réseaux de cartes ont déployé la première version du protocole 3D Secure en 2001. Si vous faites régulièrement des achats en ligne, le flux 3D Secure n'a probablement déjà plus de secrets pour vous : vous saisissez vos informations de carte pour confirmer un paiement avant d'être redirigé(e) vers une autre page dans laquelle votre banque vous demande votre code ou mot de passe pour autoriser l'achat. La page d'authentification étant comarquée avec le réseau de cartes, la clientèle est généralement plus familiarisée avec les appellations commerciales de 3D Secure, telles que Visa Secure, Mastercard Identity Check ou American Express SafeKey.
Les avantages du protocole 3D Secure sont évidents pour les entreprises : en demandant un complément d'information, elles peuvent créer une couche supplémentaire de protection contre la fraude et s'assurer d'accepter uniquement des paiements par carte de clients légitimes. Autre avantage, l'authentification d'un paiement avec 3D Secure transfère de la banque du marchand à la banque du client la responsabilité des contestations de paiement résultant de la fraude. Du fait de cette protection supplémentaire, 3D Secure est souvent utilisé pour authentifier les achats d'un montant important, comme les billets d'avion.
Malheureusement, l'utilisation du protocole 3D Secure 1 présente également des inconvénients : l'étape supplémentaire requise pour finaliser le paiement complexifie le flux de paiement et peut inciter les clients à abandonner leur achat. De plus, de nombreuses banques continuent d'obliger leurs titulaires de cartes à créer et mémoriser leurs propres mots de passe statiques pour effectuer l'authentification 3D Secure. Ces mots de passe peuvent facilement être oubliés, ce qui peut entraîner des taux d'abandon de panier plus élevés.
Les nouveautés introduites par le protocole 3D Secure 2
EMVCo, un organisme constitué des six principaux réseaux de cartes, a déployé une nouvelle version du protocole 3D Secure. 3D Secure 2 (également appelé EMV 3-D Secure, 3D Secure 2.0 ou 3DS2) a pour objectif de palier les manquements de 3D Secure 1 en introduisant une authentification moins perturbatrice et en offrant une meilleure expérience utilisateur.
Authentification fluide
3D Secure 2 permet aux entreprises et à leur prestataire de services de paiement d'envoyer à la banque du titulaire de la carte davantage de données sur chaque transaction. Il s'agit notamment de données propres au paiement, telles que l'adresse de livraison ainsi que de données contextuelles, telles que l'ID de l'appareil ou l'historique des transactions du client.
La banque du titulaire de la carte peut utiliser ces informations pour évaluer le niveau de risque de la transaction et sélectionner la réponse appropriée :
Si les données permettent à la banque de s'assurer que l'achat est bien effectué par le titulaire de la carte, la transaction poursuit un flux simple et l'authentification est finalisée sans aucune intervention supplémentaire du titulaire de la carte.
Si la banque a besoin de preuves supplémentaires, la transaction est envoyée vers un flux complexe dans lequel le client est invité à fournir des informations supplémentaires pour authentifier le paiement.
Si une certaine forme d'authentification basée sur le risque était déjà prise en charge avec 3D Secure 1, la possibilité de partager davantage de données avec 3D Secure 2 permet d'augmenter le nombre de transactions pouvant être authentifiées sans intervention du client.

Exemple de flux d'authentification d'un paiement utilisant 3D Secure 2 avec prise en charge de secours de 3D Secure 1
Même si une transaction suit le flux simple, l'entreprise bénéficiera du même transfert de responsabilité que pour les transactions qui sont soumises au flux complexe.
Meilleure expérience utilisateur
Contrairement à 3D Secure 1, 3D Secure 2 a été conçu après l'essor des téléphones intelligents et permet aux banques d'offrir plus facilement des expériences d'authentification innovantes grâce à leurs applications bancaires mobiles (parfois appelée « authentification hors bande »). Au lieu de saisir un mot de passe ou de recevoir un SMS, le titulaire de la carte peut authentifier un paiement au moyen de l'application bancaire simplement à l'aide de son empreinte digitale ou même de la reconnaissance faciale. Nous prévoyons que de nombreuses banques prendront en charge ces expériences d'authentification plus simples avec 3D Secure 2.
La deuxième amélioration apportée à l'expérience utilisateur est que 3D Secure 2 est conçu pour intégrer le flux complexe directement dans les flux de paiement Web et mobile, sans nécessiter de redirection de page complète. Si un client s'authentifie sur votre site ou page Web, l'invite 3D Secure apparaît dorénavant par défaut dans une fenêtre modale sur la page de paiement (flux de navigation).

Flux de navigation 3D Secure 2
Nos trousses SDK mobiles spécialement conçues pour 3D Secure 2 vous permettent de créer un flux d'authentification pouvant être aisément intégré à votre application afin d'éviter les redirections.

3D Secure 1 : flux d'authentification mobile avec redirection vers un navigateur

3D Secure 2 : flux d'authentification mobile amélioré dans l'application
3D Secure 2 et authentification forte du client
Avec l'entrée en vigueur de l'authentification forte du client (SCA), 3D Secure 2 joue un rôle d'autant plus important si votre entreprise est implantée en Europe. Dans la mesure où cette réglementation exige que les paiements européens soient davantage authentifiés, l'expérience utilisateur améliorée qu'offre 3D Secure 2 contribue à réduire l'effet négatif sur les taux de conversion.
Le protocole 3D Secure 2 permet également aux prestataires de services de paiement comme Stripe de demander des exemptions et de ne pas authentifier les paiements à faible risque. Les paiements soumis à la SCA doivent être traités à l'aide d'un flux complexe, tandis que les transactions pouvant être exemptées peuvent être traitées à l'aide d'un flux simple. Cependant, il est important de noter que si le prestataire de services de paiement demande une exemption pour un paiement soumis à la SCA et que ce dernier est traité à l'aide d'un flux simple, il ne pourra pas bénéficier du transfert de responsabilité.
Comment Stripe prend-il en charge 3D Secure 2?
Nos API de paiement et Checkout prennent en charge le flux 3D Secure 2, ce qui vous permet d'appliquer le protocole 3D Secure aux paiements à risque élevé de manière dynamique afin de protéger votre entreprise de la fraude. Nous appliquons 3D Secure 2 lorsque cette version du protocole est prise en charge par la banque du titulaire de la carte, et repassons à la version 3D Secure 1 lorsque la nouvelle version n'est pas prise en charge.
Nos trousses SDK iOS et Android permettent d'intégrer un flux d'authentification à votre application afin d'offrir une expérience d'authentification native et d'éviter de rediriger vos clients en dehors de votre application. Même si la banque du titulaire de la carte ne prend pas encore en charge la version 3D Secure 2, nos trousses SDK mobiles activeront automatiquement la version 3D Secure 1 dans une page Web intégrée à votre application.
Apprenez-en davantage sur nos API de paiement, nos trousses SDK mobiles ou Checkout pour démarrer avec 3D Secure 2.
Transactions effectuées par le marchand
|
Pour les transactions effectuées par le marchand, l’AFC ne doit être appliquée qu’au moment de la configuration du mandat, mais pas pour les transactions ultérieures. Un droit de remboursement inconditionnel de huit semaines, similaire aux prélèvements SEPA, est introduit pour les transactions effectuées par le marchand. |
---|---|
Ventes par correspondance/téléphone
|
Pour les transactions de vente par correspondance/téléphone, seule l’émission d’une transaction de paiement doit être non numérique pour que cette transaction soit exemptée de l’AFC. |
Liaison dynamique
|
Les éléments de l’AFC qui lient dynamiquement la transaction à un montant et à un bénéficiaire spécifiques doivent être utilisés pour les transactions de paiement électronique dans lesquelles un paiement est placé au moyen de l’appareil d’un payeur à l’aide d’une technologie de proximité (p. ex. la communication en champ proche ou CCP) et l’application de l’AFC nécessite l’utilisation d’Internet sur l’appareil du payeur. |
Services d’informations sur les comptes
|
Pour les fournisseurs de services de paiement fournissant des services d’informations sur les comptes dans le cadre d’un système bancaire ouvert, l’AFC n’est requise qu’à l’occasion du premier accès aux données. Toutefois, l’AFC est requise lorsque les clients accèdent à des données de compte agrégées sur le domaine du fournisseur de services d’informations de compte, au moins tous les 180 jours. |
Création de jetons
|
La création de jetons nécessite l’application de l’AFC lorsque le titulaire de la carte participe activement au processus de création de jetons (p. ex. lors de l’inscription ou du remplacement d’une carte dans un portefeuille ou une solution de carte enregistrée). |
Surveillance des transactions
|
L’Autorité bancaire européenne publiera des normes techniques de réglementation pour l’utilisation de la surveillance des transactions par les prestataires de services de paiement, y compris par le biais de caractéristiques environnementales et comportementales (p. ex. la localisation des clients ou les habitudes de dépenses). Cela sous-tend l’utilisation des exemptions de l’AFC pour les transactions qui présentent un faible niveau de risque (c’est-à-dire les exemptions pour l’analyse du risque de transaction). |
---|---|
Exemptions de l’AFC
|
L’ABE est également chargée d’élaborer d’autres normes techniques de réglementation sur les exigences et les exemptions de l’AFC, en tenant compte d’une approche fondée sur les risques et de l’utilisation de la technologie. |
Authentification à deux facteurs
|
Les nouvelles règles suggèrent que les facteurs utilisés pour l’authentification à deux facteurs dans le cadre de l’AFC n’ont pas besoin d’appartenir à des catégories différentes, tant que leur indépendance est entièrement préservée. Cela pourrait permettre aux clients de s’identifier à l’aide de deux mots de passe, ou d’une empreinte digitale et de Face ID. |
Accessibilité
|
Les PSP doivent offrir différentes façons de respecter l’AFC, par exemple par SMS, qui ne dépendent pas de la possession d’un appareil intelligent. |
Responsabilité des FST
|
La responsabilité est attribuée aux fournisseurs de services techniques (FST) et aux opérateurs de systèmes de paiement en cas de non-prise en charge de l’application de l’AFC. Il s’agit d’assurer une coopération accrue entre tous les acteurs impliqués dans l’application de l’AFC. |
---|---|
Externalisation
|
Les prestataires de services de paiement qui font appel à des FST pour la fourniture et la vérification des éléments de l’AFC doivent conclure des accords d’externalisation avec ces FST. L’ABE définira les exigences relatives à ces accords d’externalisation. |