Card Testing Attacks: Prevent Authorization Abuse and Follow-On Chargebacks

Card testing is a payment fraud tactic where attackers submit small or zero-dollar authorization attempts against stolen or synthetic card data to find out which numbers are still live before using them for larger fraud.

The tactic persists because the supply of compromised card data keeps refreshing. Recorded Future's 2025 Annual Payment Fraud Intelligence Report counted 142 million stolen card records listed for sale on dark web marketplaces last year, a 19% decline in raw volume from 2024 but a shift toward higher-quality data: 82% of stolen card-not-present records now come bundled with matching contact details, up from 73% a year earlier. The Identity Theft Resource Center's 2025 Annual Data Breach Report documented 3,322 US data breaches affecting 278,827,933 victims, the lowest victim count since 2014 even as the number of breach events kept climbing.

For merchants, the impact is direct: a Merchant Risk Council survey found 33% of merchants experienced card testing attacks, which drive processing fees, chargeback fraud exposure, and operational strain long after the initial probe.

Most guides on this topic stop at detection. This one goes further, into what happens after a test transaction succeeds: how it turns into a real dispute, who ends up liable depending on how the transaction was authenticated, and what evidence actually holds up when the resulting chargeback lands.

Qu'est-ce que la fraude par test de carte ?

Card testing fraud, also called carding or card cracking, is a systematic payment fraud technique cybercriminals use to confirm whether stolen, generated, or partially known card details are still active, authorized for use, and carry available spending power.

Rather than immediately making large purchases, which carry a higher risk of instant detection and blocking, attackers initiate a series of low-value or even zero-dollar authorization requests. Successful authorizations signal that the card is live and ready for exploitation. Failed attempts help narrow down invalid or canceled cards, refining the usable dataset for resale or additional fraud.

Comment fonctionnent les attaques par test de carte

Fondamentalement, le « card testing » exploite le contexte « carte non présente » (CNP) des paiements en ligne, des applications mobiles, des formulaires de dons et des services d’abonnement. C’est précisément ce recoupement avec la fraude « carte non présente » qui explique pourquoi les outils de vérification en présentiel, tels que les lecteurs de puces ou les signatures, n’offrent aucune protection dans ce contexte. Comme ces transactions ne nécessitent pas la carte physique, les fraudeurs peuvent automatiser le processus à grande échelle à l’aide de bots, de scripts ou de plateformes spécialisées de « card testing as a service ». Une seule campagne peut générer des milliers de tentatives par minute sur plusieurs sites marchands.

Voici le processus type de test des cartes, en quatre étapes :

Étape 1 : Acquisition : les fraudeurs se procurent les données des cartes par divers moyens, notamment des fuites de données à grande échelle, le phishing et l'ingénierie sociale, les logiciels malveillants et les programmes de vol d'informations, le skimming ou les attaques visant à prendre le contrôle des comptes.

Étape 2 : Validation : des outils automatisés effectuent des micro-transactions ou des tests d'autorisation uniquement afin de vérifier des éléments clés tels que :

1. Vérifier si la combinaison du numéro de carte, de la date d'expiration et du code CVV est acceptée.
2. Si les contrôles du système de vérification d'adresse (AVS) sont satisfaisants (ou peuvent être contournés).
3. Crédit disponible ou limites de dépenses.

Étape 3 : Monétisation : les cartes dont la validité a été confirmée sont soit utilisées pour effectuer des achats frauduleux d'un montant élevé sur le même site ou sur d'autres sites, soit converties en cartes-cadeaux ou en moyens de paiement prépayés, soit revendues avec une majoration sur des places de marché clandestines.

Step 4: Escalation: In many cases, testing serves as the gateway to broader attacks, such as making a spree of high-value purchases through compromised accounts or combining with other fraud vectors. As automated purchasing tools become more common at checkout, the same low-friction flows that make card testing profitable are also raising new AI agent chargeback liability questions about who answers for a dispute when an autonomous agent, not a human, completed the transaction.

La fraude par carte bancaire passe souvent inaperçue. Les petits prélèvements échappent souvent à l'attention des titulaires de carte (qui peuvent les considérer comme des frais mineurs ou des abonnements), et de nombreuses règles de détection de la fraude existantes sont conçues pour signaler les dépenses inhabituellement élevées ou les comportements de dépenses suspects, plutôt que les micro-tentatives à cadence rapide.

Signes avant-coureurs d'activités de piratage de cartes bancaires

Les signaux de test de cartes ci-dessous sont regroupés en fonction de ce qu'ils révèlent. C'est ainsi qu'ils se manifestent dans la pratique, et c'est ainsi que les outils de surveillance doivent être configurés pour les détecter.

Signaux de fraude à la carte au niveau des transactions

• Des pics soudains dans les micro-transactions. Une forte augmentation des autorisations comprises entre 0,50 $ et 5 $, ou des demandes d'autorisation sans prélèvement d'un montant de zéro dollar se succédant à un rythme rapide. Les clients légitimes effectuent rarement des micro-achats répétés dans un laps de temps très court.
• Abnormal decline rates. An unusual surge in declines, particularly codes tied to invalid card numbers, expired credentials, AVS failures, or CVV mismatches, is a primary indicator. Attackers test large batches of compromised data, much of which is already canceled or partially known, producing a high decline-to-approval ratio by design.
• Un volume d'autorisations qui dépasse les ventes réelles. Un écart croissant entre les demandes d'autorisation et les achats effectués, en particulier pendant les heures creuses ou les périodes où il n'y a pas de trafic ni d'activité de campagne correspondante.

Signaux d'identité et de source

• Plusieurs cartes provenant d'une même source. Utilisation de différents numéros de carte à partir d'une même adresse IP, d'une même empreinte d'appareil ou d'une même signature de navigateur. Un client légitime n'utilise pas successivement plusieurs cartes sur un même appareil, ce qui en fait l'un des indicateurs les plus évidents d'un test par lots.
• Suspicious or inconsistent customer data. Generic or disposable email addresses, billing information that doesn't align with the card issuer's records, and mismatched billing and shipping addresses. Watch especially for repeated attempts sharing the same Bank Identification Number (BIN) range, a strong sign that cards came from the same breach or dataset.
• Anomalies géographiques. Les transactions provenant de régions situées en dehors de votre clientèle habituelle, ou d'adresses IP associées à des VPN ou à des proxys. Tout volume provenant de ces sources et ne correspondant à aucun segment de clientèle identifiable doit faire l'objet d'un examen immédiat.

Signaux comportementaux

• Vitesse de transaction excessive. Des dizaines de tentatives par minute provenant d'une seule adresse IP, d'un seul e-mail ou d'un seul appareil, bien au-delà de tout seuil pouvant s'expliquer par un comportement utilisateur normal. Les pics de vitesse sont particulièrement significatifs au niveau des micro-transactions, où les règles de détection de fraude de base, conçues pour les achats importants, ne se déclenchent souvent pas.
• Des tentatives répétées avec de légères variations. Les fraudeurs réessaient systématiquement en apportant de légères modifications, en testant différentes valeurs de code CVV, dates d'expiration ou champs d'adresse, tout en conservant le même numéro de carte. Les séries de tentatives quasi identiques constituent un indicateur fiable de l'utilisation d'outils de test automatisés.
• Anomalies dans les schémas comportementaux. Les outils d'analyse comportementale peuvent détecter des schémas d'interaction non humains, tels qu'une vitesse de frappe anormalement constante, l'absence de mouvements de souris ou le remplissage de formulaires à une vitesse supérieure à celle dont un être humain serait capable. Ces signaux viennent compléter les données transactionnelles et font de plus en plus partie intégrante des solutions modernes de lutte contre la fraude.

How These Signals Connect

Une vague de tentatives de fraude de faible montant provenant d'une seule adresse IP, entraînant un taux de refus élevé, des échecs répétés du système AVS et l'utilisation de plages de BIN communes, est rarement le fruit du hasard. Chacun de ces indices, pris isolément, pourrait justifier un examen plus approfondi. Ensemble, ils constituent un indicateur quasi certain d'une campagne active de test de cartes.

Early detection depends on tools that analyze linked patterns, not just individual transactions, across IP, device, email, and behavioral data in real-time. Most modern fraud platforms flag these combinations automatically, which lets merchants act before a testing probe escalates into high-value fraud or chargebacks.

From Test Transaction to Chargeback: How Card Testing Becomes a Dispute

Most of the attention in card testing goes to the probe itself, but not every test attempt gets caught before it converts into a real order. When a validated stolen card is used to complete an actual purchase, the merchant is no longer dealing with a fraud signal. They're dealing with a live transaction that the true cardholder never authorized.

When that cardholder reviews their statement and doesn't recognize the charge, they file a dispute, almost always coded as an unauthorized transaction or fraud claim rather than a service complaint. That puts the merchant into the standard chargeback process, on the same clock and evidence requirements as any other fraud-driven case. Understanding what a chargeback actually is and which reason code gets assigned determines what happens next, and how much room the merchant has to respond.

Fulfillment timing matters here. If a test-derived order ships before the underlying fraud is caught, whether it's physical goods, gift cards, or a digital subscription, the merchant absorbs the cost of the goods on top of the eventual chargeback and any associated fees. That's the real cost of card testing: it rarely shows up in the decline itself. It shows up two or three steps downstream, once a test attempt slips through.

Liability by Channel and Authentication State

Whether the merchant or the issuer ultimately absorbs the loss on a card-testing-driven purchase depends heavily on the channel and how the transaction was authenticated, not simply on whether the underlying card turned out to be stolen.

The overwhelming majority of card testing today happens in card-not-present environments, which means EMV chip protections never enter the picture. Liability instead runs through whatever authentication was applied at checkout, most commonly 3D Secure. For the full mechanics of how that determination gets made, see Chargeflow's guide to the EMV liability shift. The short version for card testing specifically: if 3D Secure was triggered and completed successfully, liability for a resulting fraud dispute typically shifts to the issuer. If it wasn't triggered, was skipped, or failed, the merchant stays on the hook regardless of how convincingly the card had been "validated" through prior testing.

A merchant's payment service provider applies these liability rules at the point of checkout, but the PSP doesn't make the liability determination in a dispute. That decision sits with the issuer, based on how the transaction was authenticated, not on whether the payment was approved.

How to Prevent Card Testing Fraud

Les contrôles de base tels que l'AVS, la validation du code de sécurité (CVV), le 3DS et les limites de vitesse sont indispensables. Ce qui fait toute la différence aujourd'hui, c'est la manière dont vous exploitez les signaux de détection des cartes avant que l'attaque ne se concrétise, ainsi que la manière dont vous augmentez délibérément le coût des tentatives de piratage sans pour autant nuire aux taux d'acceptation des clients légitimes.

Voici quelques recommandations :

Considérer l'activité de test des cartes comme une source d'informations préliminaires

Les tests de cartes constituent une phase de reconnaissance. Une série d'échecs de micro-autorisations provenant de plages de BIN liées et d'empreintes numériques d'appareils communes annonce ce qui va suivre. Les mêmes acteurs, munis de cartes validées, reviennent pour effectuer des achats plus importants en l'espace de quelques heures ou de quelques jours. Intégrez directement ces signaux dans votre moteur de gestion des risques sous forme de règles de suppression temporaires afin de resserrer les seuils applicables à la plage de BIN, au groupe d'adresses IP ou à la cohorte d'appareils des testeurs avant que l'attaque suivante ne se concrétise.

This requires decline data that's queryable in near real time, not batched into a morning report. For teams where streaming full transaction records is cost-prohibitive, a metadata-only sidecar stream tracking IP, BIN, and timestamp achieves the same detection capability at a fraction of the infrastructure cost. Pairing that suppression logic with a chargeback alert service closes the loop faster than waiting for the dispute itself to show up days later.

Les flux CTI (Customer Type Indicator) qui suivent les campagnes de test de cartes peuvent fournir des indicateurs plusieurs heures avant l'arrivée d'une vague. Mais leur utilité dépend entièrement de la rapidité avec laquelle votre équipe est capable de transformer un indicateur en règle active. Une intégration nécessitant la création d'un ticket et un cycle de déploiement n'est d'aucune utilité.

Limitez les informations que les pirates peuvent tirer de vos réponses

Chaque message d'échec constitue un retour d'information. Les messages génériques, impossibles à distinguer d'un code CVV invalide, d'une carte périmée ou d'un échec AVS, obligent les pirates à multiplier les tentatives pour évaluer la qualité de leurs propres données. Cette friction s'amplifie à grande échelle.

Envisagez de combiner cette mesure avec une latence aléatoire pour les sessions suspectes. Les scripts de test sont optimisés pour la rapidité. Un délai de deux ou quatre secondes sur les sessions signalées perturbe le débit sans affecter les utilisateurs légitimes. Privilégiez les défis progressifs déclenchés spécifiquement par des signaux de vitesse ou de corrélation, plutôt que les CAPTCHA généralisés, qui nuisent à la conversion sans distinction.

Commencez par fermer les zones à haut risque

Guest checkout, donation forms, and save-card flows are disproportionately targeted because they require no account context and produce clean authorization signals. These endpoints require their own rule sets as part of a broader ecommerce fraud prevention program: stricter velocity caps, enforced session validation, and a regular audit of whether your response patterns unintentionally reveal the difference between successful and failed authorizations. Many do.

Gérer explicitement le problème des faux positifs

Les mesures de défense agressives bloquent des transactions légitimes. Une règle bloquant une plage de BIN en cours de test bloquera également les titulaires de cartes légitimes de cet émetteur. Une suppression limitée dans le temps avec expiration automatique permet de gérer le volet « règles ». Cependant, votre équipe du service client doit également disposer de l’autorité nécessaire pour ajouter en temps réel un utilisateur vérifié à la liste blanche, sans passer par le même moteur de règles qui l’a signalé. Si cette fonctionnalité n’existe pas, chaque attaque majeure se transforme en problème de fidélisation de la clientèle.

La biométrie comportementale permet de réduire au minimum le problème des faux positifs en distinguant les sessions humaines des sessions automatisées sans s'appuyer sur des données de carte ou d'identité. Elle n'élimine toutefois pas complètement les faux positifs, c'est pourquoi la procédure d'escalade reste essentielle. Suivez le taux de faux positifs comme un indicateur de premier plan, au même titre que les taux de refus.

Mesurez ce qui compte vraiment

Quatre indicateurs permettent de déterminer si les mesures de protection sont efficaces :

• Ratio « autorisation/vente ». Une hausse de ce ratio indique que le volume des tests augmente par rapport aux achats réels, quel que soit le nombre d'autorisations bloquées.
• Authorization fees. Payment gateways typically charge $0.02 to $0.10 per authorization attempt regardless of whether it's approved or declined. A 50,000-attempt campaign, even one fully blocked, can still generate $1,000 to $5,000 in fees before any fraud completes. Suppressing sessions before they reach the gateway is a finance argument as much as a fraud one.
• Impact de la conversion sur les segments à faible risque. Si les taux de fraude baissent parallèlement à la conversion légitime, le bilan n'est pas positif au final.
• Délai entre le premier signal et la mise en place de la règle. Si ce délai est mesuré en heures, vous ne réagissez qu'à l'attaque de la veille.

Une lacune organisationnelle qu'il convient de souligner

La gestion des tests de cartes relève à la fois de la lutte contre la fraude, de l'ingénierie et des opérations de paiement, et, en général, aucun de ces services n’en assume l’entière responsabilité. Les programmes qui réagissent le plus rapidement sont ceux qui désignent un responsable unique et disposent d’un guide d’intervention pré-approuvé pour les schémas d’attaque courants. Ce guide n’a pas besoin d’être sophistiqué. Il doit simplement exister et pouvoir être mis en œuvre en situation de crise, sans nécessiter de consensus entre les équipes pendant une campagne en cours.

Refund, Block, or Fight: Deciding How to Respond to a Suspected Test Purchase

Once a card-testing-driven order slips through, there are three practical response paths, and picking the wrong one is expensive in a different way each time.

The representment path only works with the right paperwork already in hand, which is why the evidence you keep matters as much as the decision you make. Chargeflow's guide to chargeback representment covers the mechanics of building and submitting that evidence package.

Evidence Checklist for Card-Testing-Related Disputes

• AVS and CVV match or mismatch results at the time of authorization
• Device fingerprint, IP address, and geolocation captured at checkout
• Velocity data showing how many other cards were attempted from the same device or IP in the surrounding window
• Any 3D Secure authentication result tied to the transaction
• Fulfillment status (shipped, delivered, or digital delivery confirmation) as of the dispute filing date
• Prior account history, if the order came through a registered account rather than guest checkout

None of this is useful after the fact if it isn't captured at the moment of the transaction. Build the logging first. The representment case gets built from what's already on file, not from what you can reconstruct weeks later.

Outils de détection et de prévention des fraudes à la carte bancaire

Le cadre présenté ci-dessus (interrogation des signaux en temps réel, suppression des pré-autorisations, gestion des faux positifs et clarification des responsabilités) décrit à quoi ressemble concrètement un système de défense abouti. La question la plus délicate est de déterminer ce qu’il convient de développer en interne et dans quels domaines les outils externes permettent d’étendre efficacement vos capacités.

La plupart des équipes rencontrent des difficultés parce que leurs systèmes ne parviennent pas à relier les signaux assez rapidement, à agir sans perte de temps due à la coordination, ou à éliminer clairement les faux positifs. Tout outil digne d'intérêt doit être évalué à l'aune de ces trois contraintes.

One approach that aligns with this model is Chargeflow Prevent. It's useful to be precise about where it fits, and where it doesn't:

1) Éliminer les goulots d'étranglement dans la coordination des processus d'intervention

Dans de nombreuses entreprises, la réponse aux tests de cartes implique une série d'étapes : le service de lutte contre la fraude identifie un schéma suspect, l'équipe technique met en place une règle, et le service des opérations en surveille l'impact. C'est ce délai, souvent de plusieurs heures, qui fait le succès des campagnes de test.

Un point de décision qui exécute en temps réel des actions telles que l'annulation, la vérification ou l'approbation élimine cette dépendance. Au lieu d'être transmises d'une équipe à l'autre, les règles sont appliquées immédiatement au niveau de la transaction. Cela se traduit concrètement par une réduction du temps de réponse, seul élément susceptible de perturber de manière fiable les tests en cours.

2) Mise en relation des signaux d'identité entre les commerçants

La plupart des solutions internes traitent les signaux tels que l'adresse IP, l'empreinte digitale de l'appareil, l'adresse e-mail et les données de carte comme des données indépendantes évaluées transaction par transaction. Cela fonctionne pour les cas de fraude isolés, mais pas pour les acteurs coordonnés qui réutilisent la même infrastructure chez plusieurs commerçants.

Les systèmes au niveau du réseau tentent de résoudre ce problème en intégrant ces signaux dans un graphe d'identité partagé. Dans ce modèle, un appareil ou un comportement associé à une fraude ailleurs peut être identifié avant même que la transaction ne soit finalisée, même si la carte elle-même est nouvelle dans votre système.

Ce qui importe ici, ce n'est pas la taille du réseau, mais la transférabilité des signaux de risque. Il s'agit de savoir dans quelle mesure les comportements observés dans un environnement permettent de prédire de manière fiable des abus dans un autre, et à quelle vitesse ces informations sont mises à profit.

3) Résoudre le problème des faux positifs sans intervention manuelle

Il est facile de bloquer de manière abusive. En revanche, il est difficile de récupérer les clients légitimes.

Most teams stop at detection and leave resolution to customer support, which results in manual reviews, ticket queues, and delayed overrides. That doesn't scale during an active attack.

Un modèle plus efficace prévoit une étape de vérification structurée au moment où un problème survient. Lorsqu'une transaction est signalée, l'acheteur confirme qu'il est bien le titulaire de la carte via un processus simple lié au profil du titulaire. S'il est bien conçu, ce système :

• Préserve la conversion pour les utilisateurs légitimes
• Génère des pistes d'audit vérifiables en cas de litige
• Élimine la nécessité de modifier manuellement les règles

Outre la réduction des faux positifs, l'enjeu principal consiste à mettre en place un processus de résolution qui fonctionne à la même vitesse que le moteur de règles.

Cas dans lesquels cette approche ne s'applique pas

Card testing often begins upstream, at the probe stage. Bots submit authorization attempts before any purchase is completed. This is where authorization fees accumulate and where attackers learn from gateway responses.

Controls at this touchpoint, such as rate limiting, session-level blocking, response obfuscation, and latency injection, must be implemented at the gateway or edge. No post-authorization system can prevent those requests from reaching your processor.

Cela permet une séparation claire des responsabilités :

• Pré-autorisation : bloquer et limiter les tentatives de test avant qu'elles n'atteignent la passerelle
• Après l'autorisation : évaluer, relier et traiter les transactions qui ont passé les contrôles initiaux

Chargeflow Prevent operates in the second approach. It is effective there, but it does not replace the need to harden the first interface.

Comment évaluer dans la pratique

Une évaluation pertinente des outils de prévention des fraudes par carte ne repose pas sur le nombre de transactions bloquées. Elle se résume à deux questions :

• Le système met-il en évidence des acteurs récurrents ou des comportements interdépendants qui font défaut dans votre infrastructure actuelle ?
• Est-il possible de réduire les faux positifs sur les commandes légitimes sans alourdir la charge de travail liée à la vérification manuelle ?

Si la réponse à ces deux questions est « oui », cet outil comble une véritable lacune. Sinon, ce n'est qu'un tableau de bord de plus.

Card Testing Is an Economics Problem That Doesn't End at the Decline

Card testing is an operation problem with a simple economic logic: attackers probe until the cost of probing exceeds the return. Most merchants make this math too easy for fraudsters. Why? Open endpoints, specific decline feedback, slow response cycles, and no shared intelligence mean the cost of testing is effectively zero, right up until a validated card converts into an order and, weeks later, a dispute.

The programs that manage this well do two things well. They're faster and more deliberate. They treat the first signal as the incident, not the chargeback that follows weeks later, and they've resolved the organizational ambiguity before an attack forces the question. They've also accepted that the false positive problem is as real as the fraud problem, and built for both.

Card testing will continue to evolve. Infostealer-sourced data, AI-assisted enumeration, and testing-as-a-service platforms lower the barrier for attackers faster than most internal controls are updated. The defensive advantage is the speed at which your system learns and responds, end to end from the first probe through to the evidence you'd need if a resulting purchase gets disputed.

Foire aux questions

What is card testing fraud?

Card testing fraud is when attackers run small or zero-dollar authorization attempts against stolen or synthetic card data to find out which card numbers are still active before using them for larger purchases or reselling the validated data.

How can I tell if my store is being hit by a card testing attack?

Watch for spikes in micro-transactions between $0.50 and $5, an abnormal surge in declines (especially AVS or CVV failures), and multiple different card numbers being attempted from the same IP address or device in a short window.

Can a card testing attack turn into a chargeback?

Yes. If a validated stolen card is used to complete an actual purchase before the fraud is caught, the real cardholder will typically dispute the charge once they notice it, putting the merchant into a standard fraud-related chargeback case.

Is card testing the same thing as carding?

Yes, carding, card cracking, and card testing all refer to the same technique: using small authorization attempts to confirm which stolen or generated card numbers are still usable.

Who is liable if a card-testing-driven purchase gets disputed?

It depends on how the transaction was authenticated, not on the fact that the underlying card was stolen. If 3D Secure was successfully completed at checkout, liability for the resulting fraud dispute generally shifts to the issuer; if it was skipped or failed, the merchant is typically the one who has to respond to and fight the dispute.

Ready to close the gap between a card testing signal and a filed dispute? See how Chargeflow automates chargeback response and recovery.