Tests 3D Secure : 3DS1 vs 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.
3DS1 vs 3DS2 en un paragraphe
3DS1 est le flux d'origine par redirection dans le navigateur : le client quitte votre page, s'authentifie sur la page de l'émetteur, puis revient avec un résultat. 3DS2 remplace la redirection par un SDK ou l'empreinte de l'appareil : l'émetteur reçoit des données supplémentaires sur l'appareil et la transaction et peut approuver sans friction (aucune interaction de l'utilisateur) ou déclencher un challenge (une modale dans la page, ou une redirection en repli sur les navigateurs qui ne prennent pas en charge le SDK). La plupart des passerelles de paiement prennent encore en charge 3DS1 pour les intégrations anciennes ; un vrai plan de test couvre donc les deux.
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 :
- Succès sans friction — l'authentification réussit sans interaction de l'utilisateur. C'est le résultat 3DS2 le plus courant.
- 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.
- Non enrôlée / non prise en charge — la carte ne participe pas. Selon la configuration de votre passerelle de paiement, vous poursuivez la transaction ou vous la faites échouer.
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 :
| Numéro de carte | Ce que cela déclenche |
|---|---|
| 4000 0025 0000 3155 | Exige une authentification 3D Secure |
| 4000 0027 6000 3184 | 3DS requis pour que le paiement aboutisse |
| 4000 0000 0000 3055 | Prend en charge 3D Secure 2 |
| 4000 0000 0000 3220 | 3DS2 — le flux de challenge doit être complété |
Ces cartes sont conçues pour un usage en sandbox uniquement. Pour d'autres fournisseurs, Adyen documente 4917 6100 0000 0000 pour les scénarios 3DS1, ainsi que les cartes de succès génériques (4242…, 4111 1111 1111 1111) dans sa sandbox. 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 quand il est disponible, et testez séparément le repli par redirection.
- 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 est liée à l'intention de paiement ; modifier le panier entre l'authentification et la capture l'invalide.
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 :
- Utilisez les cartes du fournisseur pour les flux de succès authentifié, d'échec et sans friction.
- 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.
- Utilisez le générateur avancé quand vous avez besoin de toutes les combinaisons d'un motif précis.
- 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.