Card testing : ce qui arrive vraiment à votre caisse avant le premier litige
Un pic de refus qui n'est pas encore une contestation
Un matin, votre tableau de paiement affiche quelque chose d'étrange : des dizaines de nouvelles inscriptions dans la dernière heure, chacune ajoutant une carte et tentant un petit débit, la plupart refusés. Personne n'a appelé pour se plaindre. Aucun litige n'est arrivé. Si vous vérifiez la semaine suivante, il n'y en aura peut-être encore aucun. Il est tentant de lire cela comme rien du tout, un problème de bots pour votre boîte de support plutôt qu'un problème de paiement pour votre compte marchand. Cette lecture est fausse, et le temps qu'elle produise un litige que vous puissiez désigner, le dommage qui compte le plus a généralement déjà eu lieu ailleurs.
Ce que vous regardez, c'est du card testing : quelqu'un fait passer un lot de numéros de carte volés ou devinés par votre caisse, ou par votre formulaire « ajouter une carte », pour découvrir lesquels fonctionnent encore. Votre site n'est pas la cible. C'est l'outil. L'escroc ne veut rien de ce que vous vendez ; il veut que votre formulaire de paiement lui dise, gratuitement, lequel des numéros d'une liste qu'il a achetée est une carte vivante et lequel est du plastique mort.
Cela compte particulièrement pour un opérateur d'annuaire d'annonces pour adultes, car les conseils écrits pour les marchands en ligne supposent généralement un détaillant classique avec un processeur classique. Votre compte passe presque certainement par une passerelle à haut risque, avec ses propres conditions de réserve et sa propre tolérance, plus étroite, précisément pour le type de pic de refus qu'une attaque de testing produit. Le mécanisme est le même partout ; ce qu'il vous coûte ne l'est pas.
Ce texte porte sur ce mécanisme : comment le testing fonctionne, ce qu'il coûte réellement avant qu'un seul litige existe, pourquoi un compte à haut risque absorbe la même attaque plus mal qu'un compte standard, et quoi changer sur votre caisse cette semaine plutôt qu'après la prochaine attaque.
Rien de tout cela n'exige que vous deveniez analyste antifraude. Cela exige de savoir ce qu'est vraiment le pic dans votre tableau, pour arrêter de le traiter comme du bruit de fond.
Ce qu'est vraiment le card testing, et pourquoi une caisse comme la vôtre est pratique
Un escroc qui achète ou récupère un lot de numéros de carte a un problème avant même d'avoir une opportunité : la plupart de ces numéros sont déjà morts, annulés, ou signalés. Les tester un par un avec un vrai achat serait lent et brûlerait vite des marchands légitimes, car un achat refusé est le genre de chose qu'un titulaire remarque et qu'une banque signale. L'escroc cherche donc un moyen moins coûteux et plus discret de poser la même question : cette carte est-elle encore vivante.
Le moyen discret consiste à attacher une carte à un compte, ou à exécuter une vérification d'autorisation, plutôt qu'à finaliser un achat. La documentation officielle de Stripe indique que les escrocs préfèrent cette voie parce que les vérifications concernées n'apparaissent généralement pas sur le relevé du titulaire, si bien que le vrai titulaire n'a aucune raison évidente de le remarquer et de le signaler. Quand cette voie n'est pas disponible, un petit achat, un dollar ou deux, est la solution de repli, choisie car elle reste assez petite pour passer inaperçue sur un relevé plein de vraies dépenses.
Dans tous les cas, la requête doit bien atterrir quelque part, et un script ne se préoccupe pas de ce que vend cet endroit. Il se préoccupe de savoir si le formulaire est facile à atteindre et si quelque chose se dresse entre un numéro de carte soumis et une réponse. Un parcours d'inscription qui laisse un visiteur créer un compte et attacher une carte sans mur de connexion, sans CAPTCHA, ni limite au nombre de tentatives qu'un visiteur peut faire, est exactement ce genre de formulaire, quelle que soit l'activité derrière.
Le guide de J.P. Morgan destiné aux marchands sur ces attaques rend explicite le schéma de ciblage : les escrocs recherchent des marchands mal équipés pour détecter ou se défendre contre l'attaque, les utilisant souvent comme ce que le guide appelle une mule, une cible intermédiaire utilisée uniquement pour découvrir si un compte est encore actif. Un opérateur d'annonces petit ou moyen avec une caisse minimale, souvent sur une passerelle à haut risque moins chère qui n'inclut pas le CAPTCHA ni les défenses d'apprentissage automatique qu'une plateforme comme Stripe offre par défaut, correspond à cette description plus qu'un grand détaillant, non pas en raison de ce que traite le site mais de ce qu'il peut se permettre de construire.
Le résultat est une forme de fraude qui n'a rien à voir avec vos annonces, votre modération, ou l'honnêteté de vos annonceurs, et tout à voir avec le degré d'exposition de votre parcours de saisie de carte à un script qui n'a nulle part ailleurs de plus productif où aller.
Ce que cela vous coûte avant que quiconque conteste quoi que ce soit
L'instinct d'attendre un litige avant de traiter cela comme un problème est compréhensible, et c'est le mauvais instinct. Le guide de J.P. Morgan le dit clairement : ne comptez pas sur le processus de litige pour détecter une attaque de card testing, car la fenêtre entre une transaction et un litige est assez longue pour qu'un site puisse être frappé plusieurs fois avant que quiconque ne réalise qu'il y a un problème. Le temps que le premier litige arrive, l'attaque qui l'a causé peut déjà être terminée, et une seconde peut déjà être en cours.
Le coût qui arrive en premier n'est pas un litige, c'est des frais. Chaque demande d'autorisation que votre passerelle envoie aux réseaux de cartes en votre nom, approuvée ou refusée, est une transaction que votre acquéreur traite et facture généralement. Un script de testing qui lance des centaines de tentatives en une heure ne vous coûte pas en ventes perdues ; il vous coûte en trafic d'autorisation que vous payez quel que soit le résultat, en plus de tous frais fixes ou en pourcentage que votre processeur facture déjà pour être un compte à haut risque.
Le deuxième coût est réputationnel dans un sens très littéral et mécanique : Stripe décrit un pic de refus comme quelque chose qui peut, à lui seul, nuire à la façon dont les émetteurs de cartes et les réseaux lisent votre activité, rendant chacune de vos transactions plus risquée même après la fin de l'attaque, ce qui peut signifier que les cartes de clients légitimes commencent elles aussi à être refusées. Les indications de Checkout.com disent la même chose du côté de l'acquéreur : un taux de refus élevé signale un risque à ceux qui décident de surveiller votre compte de plus près, indépendamment du fait que ces refus deviennent jamais un litige.
Le troisième coût est celui qui finit par se montrer réellement comme un litige. Une partie d'une attaque de testing réussit, car certains des numéros sont des cartes vivantes attachées à de vraies personnes. Ces petits débits réussis sont exactement ceux qu'un titulaire finit par remarquer sur un relevé et signale comme fraude, se transformant en les litiges que vous attendiez comme premier signal. Pour voir comment ces litiges comptent contre votre compte une fois arrivés, voyez ce qui décide vraiment le ratio de litiges d'un annuaire d'annonces : l'attaque de testing est souvent le premier acte silencieux d'un problème que vous ne rencontrez que plus tard sous cette forme.
Pourquoi un compte à haut risque absorbe plus mal la même attaque
Les programmes au niveau des réseaux qui surveillent les ratios de litiges et de fraude ne sont pas la première ligne de défense sur laquelle s'appuie votre processeur. En dessous se trouve le seuil interne de votre propre acquéreur, plus étroit, celui qu'il se fixe lui-même précisément parce qu'il répond devant le réseau si tout son portefeuille de marchands s'approche trop de la ligne. Le temps qu'un compte franchisse officiellement un seuil publié par un réseau de cartes, l'acquéreur a généralement déjà agi sur son propre chiffre, plus bas et privé, souvent par une augmentation de réserve ou un contrôle manuel plutôt qu'un avis formel nommant le programme.
Pour un compte marchand à haut risque, ce seuil privé et anticipé est déjà celui sous lequel vous vivez chaque jour ; c'est pourquoi le compte porte une tarification à haut risque et des conditions de réserve qu'un compte marchand classique n'a pas. Un week-end de refus liés au card testing n'a pas besoin de toucher un chiffre jamais publié par un réseau de cartes pour produire une réponse : il doit seulement déplacer le chiffre que votre propre acquéreur surveille déjà plus étroitement qu'il ne surveille un compte classique, ce qui constitue par définition une barre plus basse à franchir.
La réserve elle-même aggrave le problème plutôt que de simplement le refléter. Un processeur qui réagit à un pic de refus en retenant une part plus importante des revenus, ou en la retenant plus longtemps, retire du fonds de roulement à une activité qui paie déjà plus qu'un marchand classique pour traiter le même volume. C'est de l'argent que vous ne pouvez pas dépenser dans les outils antifraude qui auraient arrêté la prochaine attaque, ce qui est exactement le piège dans lequel tombe le plus facilement un opérateur à haut risque, maigre et à court de liquidités.
Rien de tout cela ne signifie que votre compte est fragile en raison de ce que vous vendez. Cela signifie que l'acquéreur surveillait déjà vos chiffres de plus près avant même que la première transaction de test ne touche votre caisse, et qu'une attaque de testing est l'un des moyens les plus rapides de déplacer un chiffre qu'il surveille.
Ce qu'il faut vérifier et changer cette semaine
Commencez par découvrir si vous le remarqueriez même. Extrayez votre taux de refus du dernier mois et cherchez un schéma que J.P. Morgan signale directement : un groupe de nouveaux comptes, créés dans une fenêtre courte, chacun ajoutant une carte ou tentant un débit de faible valeur refusé, souvent depuis une plage restreinte d'adresses IP ou d'appareils. Si votre tableau ne rend pas ce schéma visible d'un coup d'œil, c'est déjà le constat : vous dépendez actuellement d'un litige, des semaines plus tard, pour vous dire quelque chose que votre journal de refus sait déjà aujourd'hui.
Remboursez immédiatement, n'attendez pas. Si l'une des transactions de test a réussi, la rembourser dès que vous repérez le schéma, plutôt que d'attendre de voir si le titulaire le remarque, est la chose la moins chère que vous puissiez faire, et c'est aussi la première étape de la liste de contrôle officielle de Stripe contre le card testing. Un remboursement que vous initiez compte très différemment d'un litige déposé par le titulaire : le débit ne devient jamais un litige, donc il ne finit jamais par peser sur la façon dont les litiges se résolvent réellement sur votre ratio.
Activez les contrôles qui existent déjà. La vérification d'adresse et la correspondance du CVV sont des fonctions standard sur pratiquement toutes les passerelles, et elles sont souvent laissées sur un réglage permissif parce que les durcir peut refuser quelques clients légitimes en même temps que les bots. Pour une activité qui absorbe déjà une tarification à haut risque, ce compromis vaut généralement la peine d'être fait délibérément plutôt que laissé à un réglage par défaut que personne n'a vraiment choisi.
Placez de la friction spécifiquement sur la création de compte et la saisie de carte, pas seulement sur la caisse. La vraie cible d'un script de testing est votre parcours d'inscription et d'ajout de carte, pas votre page d'achat, donc un CAPTCHA et une limite stricte au nombre de comptes ou de cartes qu'une adresse IP peut créer par jour doivent y être placés en premier. Demandez directement à votre passerelle quels outils de vélocité et de limitation de fréquence votre forfait spécifique inclut, car les fournisseurs à haut risque varient énormément sur ce point, et les moins chers vendent souvent le compte sans les défenses qu'une passerelle classique inclut par défaut.
Enfin, arrêtez de dire aux clients refusés pourquoi ils ont été refusés. Exposer un motif précis, un mauvais CVV, une adresse qui ne correspond pas, donne à un script de testing exactement la pièce manquante d'un relevé de carte volée dont il a besoin pour affiner la prochaine tentative. Un message de refus générique ne coûte rien à un vrai client, qui peut appeler le support de toute façon, et il coûte à l'escroc la seule information qui rend sa prochaine tentative plus précise que la dernière.
