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.

What Is Card Testing Fraud?

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.

Hoe kaarttestaanvallen werken

At its core, card testing exploits the card-not-present (CNP) environment of online checkouts, mobile apps, donation forms, and subscription services. This overlap with card not present fraud is exactly why in-person verification tools like chip readers or signatures offer no protection here. Because these transactions don't require the physical card, fraudsters can automate the process at scale using bots, scripts, or specialized card-testing-as-a-service platforms. A single campaign can involve thousands of attempts per minute across multiple merchant sites.

Here's the typical card testing workflow in four steps:

Stap 1: Verwerving: Oplichters komen aan kaartgegevens via verschillende kanalen, waaronder grootschalige datalekken, phishing en social engineering, malware en infostealers, skimming of aanvallen waarbij accounts worden overgenomen.

Stap 2: Validatie: Geautomatiseerde tools voeren microtransacties of autorisatietests uit om belangrijke elementen te testen, zoals:

1. Whether the card number, expiration date, and CVV combination is accepted.
2. Als de controles van het Address Verification System (AVS) succesvol zijn (of kunnen worden omzeild).
3. Beschikbare krediet- of bestedingslimieten.

Step 3: Monetization: Confirmed "live" cards are either used for higher-value fraudulent purchases on the same or other sites, converted into gift cards/prepaid instruments, or sold at a premium on underground marketplaces.

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.

Carding is deliberately low-profile. Small charges often go unnoticed by cardholders (who may dismiss them as minor fees or subscriptions), and many legacy fraud rules are tuned to flag unusually large or suspicious spending patterns rather than high-velocity micro-attempts.

Waarschuwingssignalen van activiteiten op het gebied van kaarttesten

Card testing signals below are grouped by what they reveal. That's how they present in practice, and how monitoring tools should be configured to catch them.

Signalen van kaartfraude op transactieniveau

• Plotselinge pieken in microtransacties. Een sterke stijging van autorisaties tussen $0,50 en $5, of verzoeken voor autorisaties van nul dollar die snel achter elkaar verschijnen. Legitieme klanten doen zelden herhaaldelijk microaankopen binnen een kort tijdsbestek.
• 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.
• Het aantal goedkeuringen dat de daadwerkelijke verkopen overstijgt. Een groeiende kloof tussen goedkeuringsverzoeken en daadwerkelijk afgeronde aankopen, met name tijdens daluren of in periodes waarin er geen bijbehorend verkeer of campagneactiviteit is.

Identiteits- en bronsignalen

• Meerdere kaarten van één en dezelfde uitgiftebron. Er worden verschillende kaartnummers geprobeerd vanaf hetzelfde IP-adres, dezelfde apparaatvingerafdruk of dezelfde browsersignatuur. Een echte klant wisselt niet voortdurend tussen talrijke kaarten op één enkel apparaat, waardoor dit een van de duidelijkste aanwijzingen is voor het in bulk testen van kaarten.
• 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.
• Geografische afwijkingen. Transacties die afkomstig zijn uit regio’s buiten uw gebruikelijke klantenbestand, of van IP-adressen die verband houden met VPN’s of proxyservers. Verkeer uit deze bronnen dat niet overeenkomt met een herkenbaar klantsegment, moet onmiddellijk worden onderzocht.

Gedragssignalen

• Buitensporige transactiesnelheid. Tientallen pogingen per minuut vanaf één enkel IP-adres, e-mailadres of apparaat, wat ver boven elke drempelwaarde ligt die door normaal gebruikersgedrag kan worden verklaard. Pieken in de transactiesnelheid zijn met name van belang op het niveau van microtransacties, waar standaardfrauderegels die zijn afgestemd op grote aankopen vaak niet in werking treden.
• Herhaalde pogingen met kleine variaties. Oplichters proberen het systematisch opnieuw met kleine wijzigingen, waarbij ze CVV-waarden, vervaldata of adresvelden doorlopen terwijl ze het kernnummer van de kaart ongewijzigd laten. Clusters van vrijwel identieke pogingen zijn een betrouwbare aanwijzing voor geautomatiseerde testtools.
• Afwijkingen in gedragspatronen. Tools voor gedragsanalyse kunnen onmenselijke interactiepatronen signaleren, zoals onnatuurlijk constante typsnelheden, het ontbreken van muisbewegingen of het invullen van formulieren dat sneller gebeurt dan een mens zou kunnen. Deze signalen vormen een aanvulling op transactiegegevens en worden steeds vaker standaard onderdeel van moderne fraudebestrijdingsoplossingen.

Hoe deze signalen met elkaar in verband staan

A wave of low-dollar attempts from a single IP address, producing high declines with repeated AVS failures and shared BIN ranges, is rarely a coincidence. Each signal alone might warrant a second look. Together, they constitute a near-certain indicator of an active card testing campaign.

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.

Hoe fraude door het testen van betaalkaarten te voorkomen

De basismaatregelen zoals AVS, CVV-controle, 3DS en transactiesnelheidslimieten zijn een absolute must. Hoe je signalen uit kaarttests benut voordat de aanval volledig is uitgewerkt, en hoe doelbewust je de kosten van testaanvallen verhoogt zonder dat dit ten koste gaat van de goedkeuringspercentages voor legitieme klanten, maakt tegenwoordig het verschil.

Hier volgen enkele aanbevelingen:

Beschouw het testen van Treat-kaarten als inlichtingenwerk in een vroeg stadium

Card testing is reconnaissance. A cluster of micro-authorization failures from linked BIN ranges and shared device fingerprints signals what's coming. The same actors, with validated cards, are returning for larger purchases within hours or days. Feed those signals directly into your risk engine as temporary suppression rules to tighten thresholds for testers' BIN range, IP cluster, or device cohort before the follow-on attack lands.

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.

Customer Type Indicator (CTI) feeds that track card testing campaigns can provide indicators hours before a wave floods in. But their value depends entirely on how quickly your team can translate an indicator into a live rule. An integration that requires a ticket and a deployment cycle isn't useful.

Beperk wat aanvallers uit uw reacties kunnen afleiden

Every decline response is feedback. Generic messaging that is indistinguishable from an invalid CVV, expired card, or AVS failure forces attackers to run more attempts to diagnose their own data quality. That friction compounds at scale.

Overweeg om dit te combineren met willekeurige vertragingen bij verdachte sessies. Testscripts zijn geoptimaliseerd voor snelheid. Een vertraging van twee of vier seconden bij gemarkeerde sessies remt de doorvoer af zonder legitieme gebruikers te hinderen. Gebruik specifiek op snelheid of koppelingssignalen gebaseerde, steeds moeilijker wordende verificatievragen, en geen algemene CAPTCHA’s, die de conversie zonder onderscheid verminderen.

Sluit eerst het gebied met een hoog risico af

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.

Het probleem van valse positieven expliciet aanpakken

Aggressive defenses suppress legitimate transactions. A rule blocking a BIN range under active testing will also block legitimate cardholders from that issuer. Time-boxed suppression with automated expiry can handle the rule side. However, your customer service team also needs the authority to whitelist a verified user in real time, without routing through the same rule engine that flagged them. If that capability doesn't exist, every major attack becomes a customer retention problem.

Behavioral biometrics can minimise the false positive problem by distinguishing human sessions from automated ones without relying on card or identity data. They don't eliminate false positives, which is why the escalation path matters regardless. Track false positive rate as a first-class metric alongside decline rates.

Meet wat er echt toe doet

Vier indicatoren laten zien of de verdedigingsmaatregelen effectief zijn:

• Authorization-to-sale ratio. A climbing ratio means testing volume is growing relative to genuine purchases, regardless of how much you're blocking.
• 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.
• Conversion impact on low-risk segments. If fraud rates drop at the same time as legitimate conversion, the defense isn't net positive.
• Time from the first signal to the live rule. If this is measured in hours, you're always responding to yesterday's attack.

De organisatorische kloof die de aandacht verdient

Card testing response spans fraud, engineering, and payment operations, and typically none of them fully owns it. The programs that respond fastest have a single owner and a pre-approved playbook for common attack patterns. It doesn't need to be sophisticated. It needs to exist and be executable under pressure, without requiring cross-team consensus during an active campaign.

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.

Hulpmiddelen voor het opsporen en voorkomen van kaartfraude

The framework above (real-time signal querying, pre-authorization suppression, false positive management, and clear ownership) describes what a mature defense looks like in practice. The harder question is what to build internally versus where external tooling meaningfully extends your capabilities.

Most teams struggle because their systems can't link signals fast enough, act without coordination overhead, or resolve false positives cleanly. Any tool worth evaluating should be measured against those three constraints.

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) Het wegnemen van coördinatieknelpunten in responsworkflows

In many organizations, responding to card testing requires a chain of actions: fraud flags a pattern, engineering implements a rule, and operations monitors the impact. That delay, often measured in hours, is where testing campaigns succeed.

A decisioning point that executes actions like cancel, verify, or approve in real time removes that dependency. Instead of escalating between teams, rules are applied immediately at the transaction level. The practical impact is compressed response time, which is the only thing that reliably disrupts active testing.

2) Identiteitssignalen tussen verschillende verkopers koppelen

De meeste interne systemen behandelen signalen zoals IP-adressen, apparaat-fingerprints, e-mailadressen en kaartgegevens als afzonderlijke inputgegevens die per transactie worden beoordeeld. Dat werkt wel bij geïsoleerde gevallen van fraude, maar niet bij gecoördineerde actoren die hun infrastructuur bij meerdere handelaren hergebruiken.

Network-level systems attempt to solve this by linking these signals into a shared identity graph. In this model, a device or behavioral pattern associated with abuse elsewhere can be recognized before a transaction completes, even if the card itself is new to your system.

The value here isn't the size of the network, but the transferability of risk signals. It's how reliably behavior observed in one environment predicts abuse in another, and how quickly that intelligence is applied.

3) Het oplossen van het vals-positieve compromis zonder handmatige tussenkomst

Blocking aggressively is easy. Recovering legitimate customers isn't.

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.

A better model introduces a structured verification step at the point of friction. When a transaction is flagged, the buyer confirms ownership through a lightweight flow tied to the cardholder context. If designed correctly, this:

• Zorgt ervoor dat legitieme gebruikers hun conversie behouden
• Genereert verifieerbare audittrajecten voor geschillen
• Maakt handmatige aanpassingen van regels overbodig

The important distinction, besides lowering false positives, is creating a resolution path that operates at the same speed as the rule engine.

Wanneer deze aanpak niet van toepassing is

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.

Maatregelen op dit contactpunt, zoals tariefbeperking, blokkering op sessieniveau, versluiering van reacties en het inbrengen van vertraging, moeten op de gateway of aan de rand worden geïmplementeerd. Geen enkel systeem dat na de autorisatie in werking treedt, kan voorkomen dat deze verzoeken uw verwerker bereiken.

Dit zorgt voor een duidelijke scheiding van verantwoordelijkheden:

• Pre-autorisatie: testpogingen onderdrukken en afwijzen voordat ze de gateway bereiken
• Na goedkeuring: transacties die de eerste controles hebben doorstaan, beoordelen, koppelen en hierop actie ondernemen

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

Hoe dit in de praktijk te beoordelen

A meaningful evaluation of card testing prevention tools isn't based on how many transactions are blocked. It comes down to two questions:

• Komt er in het systeem een patroon voor van terugkerende actoren of onderling gekoppeld gedrag dat in uw huidige stack ontbreekt?
• Is het mogelijk om het aantal valse positieven bij legitieme bestellingen te verminderen zonder dat dit extra werk voor handmatige controle met zich meebrengt?

If the answer to both is yes, the tool is filling a real gap. If not, it's another dashboard.

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.

Veelgestelde vragen

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.