Card testing fraud explained: the signals that flag a testing session

Card testing has gotten big enough that the card networks now police it by the hundred thousand. Under monitoring rules Visa put in place in 2025, a merchant that sees more than 300,000 card-enumeration attempts in a single month is flagged as excessive. Enumeration is the polite word for card testing: running stolen card numbers through a checkout to see which ones are still alive. The attack looks like noise, a flurry of tiny charges that mostly decline, which is exactly why it slips past a tired fraud rule. The useful question is not how to block each charge, but how to recognize that the whole burst is one actor.

Key takeaways

• Card testing is a fraudster validating stolen cards by pushing a stream of small charges through your checkout, keeping the ones that approve for a bigger purchase later.
• Your payment processor sees the charges and the declines. What it does not see is that the cards rotate while the device and connection behind them stay the same.
• The reliable tell is linkage, not the individual charge: many different cards, many declines, one session. Reading the device and network ties the run back to one actor.
• This is a supporting signal. The decline-velocity rule, the charge decision, and any CAPTCHA stay where they belong, in your processor and your code.
• Treat the session read as a risk input weighed into a score that you act on by your own rules.

What is card testing fraud?

Card testing fraud, sometimes called carding, is the step where a fraudster checks whether stolen card numbers still work before spending real money on them. They buy a batch of card data, then run each one through a checkout or a donation form as a small charge, often under a dollar, to see which cards approve. The approved cards go in a "live" pile for a larger purchase or resale; the declined ones are thrown away. A related variant, a BIN attack, starts from one valid card's bank identification number and guesses the remaining digits, generating fresh candidate cards to test rather than buying a list.

The reason it targets smaller shops is the same reason it is easy to miss. A single test charge is tiny, so it does not trip the alarms tuned for a big fraudulent order, and a store without much fraud scrutiny is a convenient place to validate cards quietly. The damage is not the test charges themselves; it is the pile of processing and authorization fees, the chargebacks when real cardholders dispute the charges, and the risk that an acquiring bank flags the account as high-risk once the pattern shows up.

What your payment processor already catches, and where it stops

The first line against card testing is your payment stack, and it is a good one. A processor watches the rate and pattern of authorizations, so a sudden burst of small charges with a high decline rate is something tools like a gateway's built-in fraud rules are built to throttle. A CAPTCHA on the checkout slows the automated scripts that drive the volume, and a rate limit caps how many attempts come from one source. The charge decision, the decline-velocity rule, and the bot-script throttle belong in your processor and your checkout code, and they stay there.

What that layer reads well is the transaction. What it reads less well is the actor. A processor sees fifty declines and can throttle them, but it does not natively know whether those fifty cards came from fifty people or from one machine cycling a list. When the attacker rotates cards faster than any single card trips a rule, and spreads attempts to stay under the velocity threshold, the per-charge view runs out of signal. That is the gap a session-level read fills.

The cards rotate, the session does not

Here is the part the per-charge view misses. The card numbers in a testing run are disposable by design, a fresh one every attempt, so anything that reasons about the card alone sees a stream of unrelated strangers. What does not change nearly as fast is the machine and the connection driving the attempts. The same device, often behind the same VPN or proxy, submits one card after another, and that session is the thread that ties the burst together.

Reading the device and the network behind the checkout is what turns fifty unrelated declines into one recognizable actor. The card-network guidance says as much without naming the fix: a classic card-testing tell is dozens of different cards processed under one profile or one device. A stable device identifier makes that link directly, surviving the cleared cookies and rotated IPs the run leans on, and the connection often carries anonymity signals, a VPN, an anonymous proxy, or an anti-detect browser, that mark the session as built to hide. This is the same one-actor-many-identities pattern that sits under multi-accounting prevention; here the many identities are cards instead of accounts.

The signals that flag a testing session

No single charge is a verdict; the read is how strongly the session looks like one actor working a list. The tells that do the work:

Signal at checkout	What it suggests	Strength
Many different cards from one device	one actor cycling a stolen list, not many shoppers	High
A burst of small charges with a high decline rate	the footprint of testing, not normal buying	High
An anonymized connection: VPN, proxy, or anti-detect browser	the session is built to hide where it comes from	Medium-High
A device new to your store going straight to repeated checkout attempts	no browsing, no history, just card submissions	Medium-High
The same device returning after a block under a fresh IP	an actor working around a per-IP rule	Medium

The strongest single read is the device, because it is the thing the attacker cannot swap as cheaply as a card or an IP. A real customer reaches checkout once with one card; a testing run arrives on a device that has done nothing but submit cards, often behind a connection meant to mask it. A defender weighs these into a risk score rather than acting on any one row, so a legitimate shopper who simply retyped a declined card is not mistaken for an attack.

How to spot a card-testing session

1. Read the device and connection on each checkout attempt, not just the card.
2. Link the attempts to one session so a run of different cards from one device reads as a single actor.
3. Check the connection for anonymity signals like a VPN, proxy, or anti-detect browser.
4. Weigh the signals into a risk score, including the burst of declines and the lack of any normal browsing.
5. Hand the score to your processor and your rules, which decide whether to add friction, hold, or decline, by your own logic.

Where the device signal fits with your payment stack

The honest scope is narrow on purpose. The charge, the CAPTCHA, the endpoint rate limit, and the approve-or-decline decision belong to your processor, your gateway, and your checkout code, and they should. A device-and-network signal layer reads a different thing: it scores the session on its own and recognizes when the same device and connection sit behind a run of card attempts, so the action is yours to take.

What the signal layer adds is the read those tools lack on their own: an independent answer to whether this checkout session traces back to a device working through a list, masked behind an anonymized connection. The two halves chain together. Your processor decides the charge and throttles the velocity; the device-and-network read tells you which sessions are one actor in disguise, so the action your code takes is aimed at the testing run rather than at every customer who mistypes a card.

Which businesses card testing hits hardest

Card testing follows low-friction payment forms where a small charge slips through unnoticed:

• Donations and nonprofits. Open-amount, no-goods donation forms are the classic testing ground, since a fraudster can validate cards for pennies with nothing to ship and no order to flag.
• E-commerce and digital goods. High checkout volume hides testing traffic, and instant-fulfillment digital products let a validated card be cashed out immediately.
• Subscriptions and SaaS. A cheap first charge or a trial-to-paid step is an easy, repeatable place to test a card.
• Ticketing and events. Fast, high-volume on-sale windows give testers cover to run cards in bulk before anyone notices.

Wherever cards rotate through a form, the session and device behind them stay consistent, which is what the device layer reads regardless of vertical.

Preventing card testing fraud with ShieldLabs

ShieldLabs helps you prevent card testing by reading the device and network behind each checkout. You add one JavaScript snippet to your checkout, and on each visit it returns a risk score from 0 to 100 with the named signals behind it: whether the device is one your checkout has already seen, whether the connection carries anonymity signals like a VPN, proxy, or anti-detect browser, and whether the session behaves like a run of attempts rather than a real purchase. ShieldLabs never reads the card numbers; it recognizes the returning device and issues a stable DeviceID that holds while the cards rotate. You join that DeviceID to your own payment records to count how many cards one device has tried, and across attempts the pre-built patterns surface when many "different" checkouts trace back to one device, so a testing burst reads as one actor in the dashboard instead of a pile of separate declines.

The card number changes on every attempt; when we ran the device read against a burst of checkout tries, the device identifier and the connection behind them stayed put, which is what turns fifty unrelated declines into one recognizable actor. That burst is the same behavior the card networks moved to police in 2025, when a monitoring threshold began flagging any merchant that sees more than three hundred thousand enumeration attempts in a month.

ShieldLabs scores the device and network behind the checkout on a risk score from 0 to 100 and names the anonymity signals that fired. You read the risk score and named anonymity signals through the API and webhooks and decide, by your own rules, whether to add a step, hold the session, or pass it to your processor as higher risk, so the charge decision stays in your stack. The same identity layer carries into payment fraud prevention and the broader ecommerce account and offer abuse picture.

Sources

1. Visa: 2025 Global eCommerce Payments and Fraud Report
2. OWASP: Automated Threats to Web Applications: Carding (OAT-001)
3. Wikipedia: Carding (fraud)
4. Federal Reserve Bank of Kansas City: Card-not-present fraud rates in the United States