What is card testing?
Card testing is a technique in which attackers run small, automated transactions to check whether stolen card numbers are still active before using the validated numbers for larger-scale fraud. Because the goal is validation, not profit, attackers usually target many cards from the same issuer range in quick succession, often hitting several merchants at once.
The transactions themselves rarely look like fraud. A one-dollar charge, a free-trial signup, a small donation — each one designed to pass through checkout without a second look. Multiply that by hundreds or thousands of attempts across a stolen card batch, and a pattern that's invisible at the transaction level becomes obvious at the card-range level.
How card testing works
Every card number starts with a bank identification number, or BIN: the first six to eight digits, which identify the issuing bank and card type. Stolen card data is usually sold or leaked in batches tied to a single issuer or a specific breach, so the numbers in a batch typically share a BIN or a narrow range of BINs.
Attackers exploit that structure directly. Rather than testing one card at a time, they cycle through possible account numbers within a compromised range, often automating the process so that thousands of attempts run within a short window. Some of those combinations belong to real, active accounts. The rest fail. Either way, the attacker learns something, and the merchant absorbs the cost of processing the attempt.
The behavioral signals that reveal it
A single test transaction looks like an ordinary decline. A card range being tested looks like nothing else.
Velocity spikes
A sudden jump in authorization attempts from related card numbers, concentrated in a short window well outside a merchant's normal transaction rhythm. A merchant that typically processes a few hundred transactions an hour, suddenly seeing several thousand attempts in the same window, many sharing the same first six digits, is a textbook example.
On its own, a spike isn't proof of an attack: a flash sale or a viral product moment can produce a similar jump in legitimate volume. What separates the two is what comes with the spike. Real demand tends to show a healthy approval rate and ordinary purchase patterns, while a card-testing spike appears alongside the decline-rate and concentration signals shown below.
Decline-rate anomalies
Card testing produces far more declines than approvals, since most guessed or partially known numbers won't work. A healthy merchant typically declines a small share of transactions for ordinary reasons: insufficient funds, expired cards, mismatched billing details. A spike in declines with no matching spike in legitimate sales is a signal on its own, especially when the decline rate on the suspicious batch runs far above the merchant's normal baseline, since the attacker is testing volume rather than trying to pass any specific transaction.
Merchant concentration
The same card range showing up across multiple merchants at once, rather than isolated activity at a single storefront, points to a coordinated attack rather than a single bad actor testing cards at random. This is the hardest signal for any single merchant to see on their own, since it requires comparing activity across businesses that have no relationship with each other and no reason to share transaction data. A merchant, seeing an unusual card range in isolation, has no way to know whether five other merchants saw the same range in the same hour. That comparison becomes possible only once the pattern is tracked at a level above any individual merchant's transaction log.
Geographic dispersion
Attempts spread across locations and IP ranges that are inconsistent with a single cardholder's normal behavior, often automated to a degree well beyond what a person manually entering card numbers could produce. A cardholder might occasionally travel or use a VPN, so geographic variation alone isn't unusual.
What stands out is the combination: the same card range tested from many disparate locations within minutes, a pace no single traveling cardholder could produce. Paired with the other three signals, geographic dispersion helps confirm the activity is automated and coordinated, rather than a handful of unrelated transactions that happen to look similar.
Individually, none of these signals proves fraud. Together, at the card-range level, they're hard to explain any other way.
The term family: card testing, enumeration, BIN attacks, and more
Card testing is used as an umbrella term, and several related terms are used almost interchangeably with it. They're related, but not identical, and the differences matter for anyone trying to search for or diagnose a specific attack pattern.
What is a BIN attack?
A BIN attack is a form of card testing that targets a specific bank identification number, the first six to eight digits of a card number, by systematically testing many possible account numbers within that range to find ones that are valid.
What is enumeration fraud?
Enumeration fraud is the automated, high-volume version of card testing, in which software cycles through large batches of card numbers, expiration dates, and security codes within a card range to identify live combinations, often spreading attempts across many merchants simultaneously.
What's the difference between card testing and enumeration?
Card testing is the umbrella term for validating stolen card numbers before committing fraud, while enumeration refers to the automated, systematic method attackers commonly use to do so at scale. In practice, most modern card testing activity is enumeration-driven; the manual, one-off version has mostly given way to software doing the guessing.
What is a penny testing attack?
A penny-testing attack is a card-testing variant that uses very small transaction amounts, often between $0.01 and $1.00, to confirm a card is active without drawing the cardholder's attention or triggering standard fraud alerts. The name refers to the transaction size, not a different underlying mechanic.
Card testing vs. card cracking
Card testing confirms whether a stolen card number is valid. Card cracking, classified by OWASP as an automated threat OAT-010, is a related but distinct technique: instead of testing a full stolen number, it guesses the remaining unknown details, like an expiration date or security code, of a card number that's already partially known.
Why is card testing hard to catch?
Two habits keep card testing running longer than it should.
Chargebacks arrive too late
Most fraud programs still learn about card testing from chargeback data, and that data typically doesn't surface for 30 to 90 days after the transaction. A merchant can be under active attack for weeks before the first sign reaches a fraud team's dashboard. By the time the chargebacks land, the attacker has already moved on to the next batch of numbers.
Manual review doesn't scale
Analysts who catch card testing early usually do it by hand: pulling transaction data into a spreadsheet, grouping by BIN, and looking for clusters that don't fit normal patterns. It works, but only for the volume one person can review, and only if that person already knows what to look for. As attack volume grows, more of it slips through simply because nobody was looking at the right slice of data at the right time.
Why it matters now
Two shifts have changed the stakes on getting card testing detection right: how fast attacks move now, and how card networks account for them before a chargeback ever appears.
AI has changed the speed and scale
Attacks that used to take a botnet weeks to run now complete in hours, using the same underlying tactic at a faster, cheaper, and larger scale. Static, rule-based detection was built for a slower version of this threat, and a rule tuned to catch last month's attack pattern often has nothing to say about a pattern that didn't exist last month.
VAMP counts enumeration before a chargeback ever posts
Visa's Acquirer Monitoring Program (VAMP) folds fraud and dispute data into a single compliance ratio, and enumeration activity counts against that ratio the moment it happens, whether or not a chargeback is ever filed. That shift means a portfolio can accumulate real compliance exposure from card-testing activity well before a single related chargeback posts. Learn more about VAMP in our comprehensive whitepaper: What Should Merchants and Acquirers Do About Visa’s new VAMP?
Frequently asked questions
How does card testing affect merchants?
Merchants absorb the immediate cost of authorization fees on fraudulent test transactions, then face downstream effects including chargebacks, elevated decline rates, and, under Visa's VAMP program, compliance-ratio impact that can occur before a single chargeback is ever filed.
Why is card testing hard to detect?
Individual test transactions are typically small and designed to resemble normal shopper behavior, so they rarely trigger transaction-level fraud rules. The pattern usually becomes visible only when transactions are analyzed together across a range of cards and merchants, rather than one at a time.
How much does card testing fraud cost businesses?
Costs vary by merchant size and industry, but typically include authorization fees for fraudulent test transactions, chargeback and dispute management costs, and compliance exposure under programs like Visa's VAMP. Card testing affected 33% of merchants globally over the past 12 months, according to the 2026 Visa/MRC Global eCommerce Payments & Fraud Report, making it one of the five most common types of fraud merchants face today.
Key takeaways
Card testing, enumeration, and BIN attacks describe overlapping parts of the same problem: attackers validating stolen card data before the real fraud starts, using automated techniques that keep getting faster. Catching it means watching the card range, not just the transaction, since that's the level where the pattern actually shows up.
AI-accelerated attack speed and VAMP's compliance exposure are the two forces raising the stakes on this right now. Closing that gap in real time, at the card-range level, is what FraudNet’s card testing detection is built to do, and [Guide: Enumeration Attack Detection] walks through how. To see how FraudNet can help detect card testing for your business, book a meeting with one of our solutions consultants.
%20(640%20x%201229%20px).png)
You might be interested in…
Get Started Today
Experience how FraudNet can help you reduce fraud, stay compliant, and protect your business and bottom line
