A card testing attack is a fraud technique in which criminals send a large number of low-value payment attempts through a checkout page to learn which stolen card numbers are still active. The attacker does not want the product. The attacker wants the authorization response, because that response reveals whether a card number will work. Once a number is confirmed, it gets used for larger purchases or sold again on a carding market.
For merchants, a card testing attack is expensive even when no order ships. Each attempt can add authorization fees, chargeback risk, processor scrutiny, and a damaged fraud ratio that affects future processing terms.
How a card testing attack works
- The attacker buys or trades a bulk list of card numbers, often with expiration dates and partial cardholder data attached.
- A script or bot submits those numbers to a live payment form, sometimes thousands of times in a few hours.
- Proxies, rotating IP addresses, random email addresses, and spoofed device data are used so each attempt looks like a separate shopper.
- The attacker logs which responses come back approved or return a decline code that signals a live card.
- Verified cards are sold onward or used later for high-value purchases before the cardholder notices.
Small amounts are chosen on purpose. A charge under a dollar rarely triggers a cardholder alert, and many issuers approve it with no friction. Attackers also favor merchants that do not require the card verification value or a billing address match, since those checks remove the easiest validation path.
Why small merchants get hit hardest
Large retailers run velocity checks, device fingerprinting, and machine learning scoring on every order. Smaller stores often run none of that, and their checkout pages are public, simple, and easy to automate against. Attackers scan for shops with no CAPTCHA, no 3D Secure, and no rate limit on the payment endpoint, then point the bot at whichever one responds fastest.
Warning signs of a card testing attack
- A sharp rise in declined transactions inside a short window, often overnight
- Many orders placed with different card numbers but the same shipping or contact details
- Dozens of attempts from one IP range, one country, or one device fingerprint
- A high share of orders for the cheapest item in the catalog
- Failed attempts clustered within seconds of each other
- Cardholders contacting you about charges they do not recognize
- A sudden drop in authorization rate from your processor
How to prevent a card testing attack
- Turn on bot detection or a challenge on the payment step, not just the login page.
- Require CVV and address verification for every transaction, including digital goods.
- Enable 3D Secure where your processor supports it, which shifts liability and adds a step bots cannot pass.
- Set velocity limits by IP address, card BIN, email domain, and device.
- Rate limit the payment endpoint and block requests that skip your checkout flow.
- Reject disposable email domains and mismatched billing details.
- Watch authorization logs for patterns and add rules as new ones appear.
What to do after an attack
- Contact your payment processor or acquirer and report the activity with timestamps.
- Collect the IP addresses, user agents, and attempt counts involved.
- Add the offending ranges to a block list and tighten your velocity rules.
- Review your chargeback policy and respond to disputes with evidence.
- Keep monitoring for a second wave, since attackers often return to a page that worked once.
One point worth stating clearly: most card testing attacks do not mean your own systems were breached. The card numbers came from somewhere else, and your checkout page was simply the tool used to check them. That distinction matters when you decide whether customer notification or a formal breach review is required.
Card testing, carding, and account enumeration
These terms overlap but are not identical. Carding is the broad practice of trading and using stolen payment data. Account enumeration tests username and password pairs against login pages. A card testing attack targets the payment authorization step specifically. All three rely on automation and volume, and all three are strongest against sites that treat a single failed attempt as harmless.