An attacker holding thousands of stolen card numbers has one problem: most are already cancelled, and there is no way to tell which from the number alone. So they find a checkout that will accept a small payment without much friction, and let it answer the question for them.
How it works
- The attacker acquires numbers
From a breach, a marketplace, or by generating candidates from a known issuer prefix that pass the Luhn check.
- They find a permissive checkout
Something that accepts small amounts, has no rate limiting, and returns a clear success or failure quickly.
- They run the list
Automated, often thousands of attempts, usually overnight or across a weekend.
- They keep the ones that work
The live cards are used or sold. Your business never sees the actual fraud.
What it costs you
| Cost | Why |
|---|---|
| Authorization fees | Many processors charge per attempt, approved or not |
| A damaged approval rate | Issuers see a flood of declines from your merchant ID |
| Genuine customers declined | That degraded reputation applies to real traffic too |
| Chargebacks later | Any card that did succeed becomes a dispute |
| Network monitoring | A dispute ratio above roughly 0.9% brings real consequences |
The third row is the one merchants underestimate. A card testing attack is not just a bad night — the damage to how issuers score your traffic persists after the attack has stopped.
Where attacks find a way in
- Donation forms, where the amount is chosen by the payer and small values are normal.
- Card-on-file endpoints that validate a card before charging it.
- Free trials taking a card, especially with a zero-dollar or one-dollar verification.
- Any public checkout with no rate limiting and a fast, clear response.
What actually stops it
- Rate limit on every axis — IP, device fingerprint, email, and card number. Most attacks are volume plays and die at the first real limit.
- Add an invisible CAPTCHA on payment endpoints. It costs legitimate users nothing and breaks naive automation.
- Do not expose trivially small or zero-dollar charges on a public endpoint.
- Alert on decline-rate spikes. Detecting it in an hour rather than a weekend is most of the mitigation.
- Use [3D Secure](/resources/what-is-3d-secure) selectively, triggered by risk signals rather than applied to everyone.
None of this is exotic. Card testing is an economic activity — the attacker is looking for the cheapest place to run a list, and modest friction is usually enough to make your site not worth the trouble.
Sources
- Card network guidance on enumeration and card testing attack patterns.
- Visa Dispute Monitoring Program thresholds, which apply regardless of how a merchant's dispute ratio rose.
GOOD QUESTIONS
Frequently asked
What is a card testing attack?+
An attacker with a list of stolen or generated card numbers runs small transactions through a merchant's checkout to find out which cards are still live. The valid ones are then used or sold elsewhere. Your site is the testing ground, not the target.
What is a BIN attack?+
A variant where the attacker takes a known issuer identification number — the first six or eight digits — and generates candidate card numbers that pass the Luhn check, then tests them in bulk to find real accounts.
Does card testing cost me money if every payment declines?+
Yes. Many processors charge per authorization attempt regardless of outcome, and a flood of declines damages your approval rate with issuers, which then affects your genuine customers. Any card that does succeed usually becomes a chargeback later.
How do I stop card testing?+
Rate limit by IP, device and card, add an invisible CAPTCHA on payment endpoints, avoid publicly reachable zero-dollar or trivially small charges, and alert on any sudden spike in declines. Speed matters more than sophistication — most attacks are automated and move on when a site becomes expensive.