Le card testing consiste à utiliser votre checkout pour savoir quelles cartes volées fonctionnent encore. Quelqu'un achète une liste de numéros de carte, puis les essaie en masse, avec de petits paiements ou en enregistrant une carte, et garde celles que votre prestataire de paiement accepte. Stripe cite d'autres noms : carding, account testing, énumération et card checking ; l'OWASP l'appelle carding, « de multiples tentatives d'autorisation de paiement pour vérifier la validité de données de cartes de paiement volées en masse ». Il se fait par script, car une liste ne vaut la peine d'être testée qu'en volume.
Ce que le card testing vous coûte
- Des litiges. Certains paiements de test réussissent, les titulaires les voient et signalent une fraude, et chacun peut devenir un litige avec ses frais.
- Les paiements de vos vrais clients. Des milliers de refus liés à votre entreprise font voir à l'émetteur chacun de vos paiements comme plus risqué, et Stripe prévient que des paiements légitimes peuvent alors être refusés plus souvent, même après la fin des tests.
- Des frais et de la charge. Des frais d'autorisation sur certaines tarifications, et une vague de requêtes auxquelles vos serveurs et votre prestataire doivent répondre.
- L'attention des réseaux de cartes. Visa compte : depuis juin 2025, son programme de surveillance des acquéreurs signale un marchand dont les autorisations d'énumération atteignent 20 % de toutes ses autorisations, avec au moins 300 000 d'entre elles en un mois.
- Vos chiffres. Les petits paiements du testeur ressemblent à de nouveaux clients dans vos données.
Comment il se voit dans vos paiements
Stripe cite les symptômes habituels :
- un pic de paiements échoués ou bloqués ;
- un pic de requêtes refusées, beaucoup avec un refus générique ;
- plus de petits paiements, souvent avec des noms et des adresses e-mail absurdes.
Surveillez aussi l'enregistrement de cartes, pas seulement le paiement. Stripe note que les testeurs le préfèrent, parce qu'une carte enregistrée sur un compte n'apparaît généralement pas sur le relevé du titulaire, si bien que personne ne la signale.
Pourquoi un seul contrôle ne suffit pas
Les testeurs changent de cartes, d'adresses et de sessions, si bien qu'un filtre sur un seul signal, comme l'adresse IP, ne suffit généralement pas à lui seul, selon Stripe. Son conseil est un ensemble de contrôles sur les routes qui enregistrent une carte ou encaissent un paiement : un CAPTCHA vérifié côté serveur, une connexion avant le paiement, des rate limits, et une combinaison de ceux-ci. Chacun ajoute une étape, et cette étape tombe sur vos acheteurs autant que sur le script.
Interroger avant de débiter
Un script de test envoie en général ses requêtes directement à votre route de paiement et ne charge jamais votre page de checkout. Bot Protection juge la requête avant que votre serveur n'appelle le prestataire de paiement, et sur cette route vous pouvez exiger la preuve que la page a vraiment été visitée : une action qui exige le tag. Placez-la sur le POST qui débite la carte, celui qui enregistre une carte et celui qui utilise une carte cadeau. Puis agissez selon la classe :
bot_high: refusez avec le même message qu'une carte refusée, ou avec une réponse leurre, pour que le script n'apprenne rien sur ses cartes.bot: demandez d'abord votre propre vérification, comme 3-D Secure, ou faites passer l'acheteur par la page de défi.unknown,human,human_high: le paiement normal.
Commencez en mode surveillance : personne n'est arrêté, et chaque réponse dit ce qu'aurait fait le mode blocage, ce qui vous montre combien de requêtes de votre checkout viennent de scripts avant de l'activer. La configuration complète, route par route et langage par langage, est dans protéger un checkout.
Après le paiement
Remboursez les petits paiements passés avant que leurs titulaires ne les contestent, comme Stripe le conseille. Puis renvoyez le résultat du paiement en feedback : un chargeback ou une fraude confirmée pèse sur les décisions suivantes concernant le même navigateur, et un bon client les relève.
Rester fail-open
La vérification se trouve dans votre checkout, elle ne doit donc jamais l'arrêter. Utilisez un timeout court et laissez passer l'acheteur à la moindre erreur : quelques paiements de test pendant une panne coûtent moins cher qu'un checkout qui ne répond pas. Plus de détails dans pourquoi une vérification anti-bots doit être fail-open.
Sources
Vérifié le 28 octobre 2026.