Tests 3D Secure : comment fonctionne 3DS2 et cartes de test pour chaque flux

3D Secure (3DS) est la couche d'authentification qui transfère la responsabilité de la fraude des marchands vers les émetteurs. C'est aussi la partie des tests de checkout qui casse le plus souvent, car elle implique des redirections, des iframes, des SDK mobiles et des résultats asynchrones. Ce guide couvre ce qu'il faut tester, quelles cartes de test déclenchent quel flux et les bugs qui passent systématiquement entre les mailles.

De 3DS1 à 3DS2 en un paragraphe

3DS1 était le flux d'origine par redirection dans le navigateur : le client quittait votre page, s'authentifiait sur la page de l'émetteur, puis revenait avec un résultat. Visa, Mastercard et American Express ont retiré 3DS1 (3-D Secure 1.0.2) en octobre 2022, et les dernières prolongations régionales ont pris fin en 2023 : les plans de test actuels n'ont donc besoin que d'EMV 3DS (3DS2). 3DS2 transmet à l'émetteur beaucoup plus de données sur l'appareil et la transaction, ce qui lui permet d'approuver sans friction (aucune interaction de l'utilisateur) ou de déclencher un challenge. Il comporte deux canaux : un flux navigateur, qui collecte les données de l'appareil via une iframe cachée 3DS Method et affiche le challenge dans une iframe (ou une redirection hébergée par le fournisseur), et un flux applicatif qui utilise le SDK 3DS dans les applications mobiles natives.

Les trois issues à gérer

Chaque transaction 3DS se termine de l'une des trois façons suivantes, et les trois exigent des états d'interface explicites :

1. Succès sans friction — l'authentification réussit sans interaction de l'utilisateur. C'est le résultat 3DS2 le plus courant.
2. Challenge — il est demandé au client de s'authentifier (OTP, validation dans l'app). Gérez le succès comme l'échec ou l'annulation.
3. Non enrôlée / non prise en charge — la carte ou l'émetteur ne participe pas. Soit aucune authentification n'a lieu, soit le réseau répond au nom de l'émetteur par une tentative (attempt). Selon la configuration de votre passerelle de paiement, vous poursuivez la transaction ou vous la faites échouer.

Sous le capot, chaque résultat correspond à une valeur transStatus : Y (authentifié), A (tentative ; transfère généralement quand même la responsabilité à l'émetteur), N (non authentifié), R (rejeté ; ne pas autoriser), U (indisponible, une défaillance technique sans transfert de responsabilité). C et D indiquent qu'un challenge ou une authentification découplée est encore en cours.

Ce sont les chemins d'échec qui cassent les checkouts : un challenge annulé n'est pas un refus, et les utilisateurs qui ferment la modale doivent pouvoir réessayer sans reconstruire tout le panier.

Cartes de test Stripe pour les flux 3DS

Stripe documente des numéros de test dédiés au comportement d'authentification :

Ces cartes sont conçues pour un usage en sandbox uniquement. Pour d'autres fournisseurs, Adyen documente 4917 6100 0000 0000 (Visa enrôlée en 3DS2 ; expiration 03/2030, CVC 737) pour les flux de challenge, et 4111 1111 1111 1111 parmi ses cartes de test Visa générales. Vérifiez toujours la documentation à jour du fournisseur : le comportement des cartes de test change sans préavis.

Une liste plus complète figure dans notre référence des numéros de carte de test.

Checklist de configuration de la sandbox

• Activez 3DS dans le tableau de bord de la passerelle de paiement, pas seulement dans l'appel API. Beaucoup de passerelles ont un interrupteur par compte qui désactive silencieusement l'authentification en mode test.
• Utilisez le SDK 3DS2 dans les applications natives, et testez séparément le flux navigateur (iframe et toute redirection utilisée par votre fournisseur).
• Ajoutez les URL de retour à la liste blanche pour chaque environnement, y compris les tunnels de développement local.
• Testez sur de vrais appareils mobiles, pas seulement en réduisant la fenêtre sur desktop. Les navigateurs intégrés aux applications (Instagram, TikTok, applications bancaires) se comportent différemment de Safari et Chrome.
• Gardez la fenêtre de challenge responsive. Un challenge affiché dans une iframe à hauteur fixe est un tueur de conversion classique.

Bugs qui passent entre les mailles

• Panier perdu lors de la redirection. Persistez la commande avant de lancer l'authentification, pas après.
• Bouton retour non géré. Les navigateurs restaurent la page depuis le bfcache ; votre JS doit réinterroger l'état du paiement au lieu de supposer un chargement neuf.
• Double soumission. Les utilisateurs cliquent deux fois sur « Payer » pendant que le challenge est ouvert. Utilisez des clés d'idempotence sur la demande d'autorisation.
• Succès supposé après le challenge. Le résultat de l'authentification est un signal distinct ; l'autorisation peut encore être refusée ensuite.
• Webhooks asynchrones ignorés. Certains flux 3DS2 se terminent de façon asynchrone. Si vous n'écoutez que la redirection, vous manquerez des résultats.
• Montant ou devise erronés. L'authentification couvre le montant et la devise que vous avez envoyés ; si le panier change, authentifiez à nouveau (sur Stripe, modifier le montant d'un PaymentIntent impose de le confirmer à nouveau).

Comment tester sans vraies cartes

Vous n'avez pas besoin d'une vraie carte pour tester 3DS. Les cartes de test du fournisseur et des données générées couvrent toute la matrice :

1. Utilisez les cartes du fournisseur pour les flux de succès authentifié, d'échec et sans friction.
2. Utilisez notre générateur de cartes pour produire de gros volumes de numéros structurellement valides pour les tests de charge, de fuzzing et d'interface.
3. Utilisez le générateur avancé quand vous avez besoin de toutes les combinaisons d'un motif précis.
4. Validez n'importe quel numéro de test avec le validateur de Luhn.

Résumé

Tester 3DS consiste surtout à couvrir les chemins difficiles : challenges annulés, authentification en échec, résultats asynchrones et navigateurs mobiles. Les cartes de test des fournisseurs déclenchent chaque flux de manière délibérée et un jeu de données généré comble les lacunes. Traitez l'authentification comme une machine à états distincte de l'autorisation et vous éviterez la majorité des incidents en production.