A card test is a small authorization run against a card number to see whether the account is live. Fraud detection catches these attempts by watching volume, amount patterns, and the gap between who owns the card and who is typing it in. Waiting for chargebacks is too slow. Most card testing is over before the first dispute ever lands.
What a card test looks like on the merchant side
You rarely see one attempt. You see a burst. Dozens of low-value orders hit the same checkout in a few minutes, often from a handful of IP addresses or a single residential proxy pool. Amounts cluster around $1 to $5, sometimes $0.00 with a card validation endpoint. Email addresses look generated. Shipping details are thin or missing. The same device fingerprint shows up across cards that belong to different banks.
The pattern matters more than any single transaction. A lone $2 charge is noise. Four hundred of them in an hour is an attack in progress.
Signals detection systems actually weigh
- Velocity. Attempts per card, per IP, per device, per BIN, per email domain, measured in windows of minutes rather than days.
- Decline clustering. A high ratio of declines on one BIN means someone is walking a list of numbers and keeping the ones that authorize.
- Amount uniformity. Real customers buy different things. Testers buy the same $1 item 60 times.
- CVV and AVS outcomes. A correct card number with a wrong security code is the classic signature of a leaked database that never included the printed code.
- Geography mismatch. Card issued in Ohio, IP in Vietnam, billing address in a freight forwarder's zip code.
- Session behavior. Paste instead of type, no browsing, no cart edits, instant submit.
Issuer checks and merchant checks are not the same job
The issuer validates the card: does this account exist, is it open, does the CVV2 match, does the address match. The merchant's fraud engine validates the behavior: does this order make sense for this store, this hour, this customer history. Card testing beats weak issuer checks and gets stopped by strong merchant-side rules. That is why the same stolen list can fail at one checkout and glide through another.
3-D Secure shifts part of the burden back to the issuer. A script that can guess a 16-digit number cannot easily complete a challenge tied to the cardholder's phone, so authentication steps break the economics of running thousands of tests.
Why the tiny amounts are the whole point
Testers do not want the product. They want confirmation. A $1 authorization that returns an approval tells them the number is worth selling or worth using for a larger purchase later. That is why blocking the large fraudulent charge is not enough. If you approve the test, you have already told the attacker which numbers are good, and the real damage happens on someone else's site or weeks down the line.
What to do when a spike shows up
- Rate limit by card, IP, device, and email at the authorization endpoint, not just at checkout.
- Require CVV and AVS to match on low-value first-time orders from new devices.
- Add a challenge or block when decline rates on a BIN cross a threshold in a short window.
- Suppress the response detail. Do not echo back why a card failed in a way a script can parse.
- Review the last 24 hours for approved micro-charges and refund or void them before fulfillment.
Bottom line
Fraud detection of card testing is a speed problem. The window between the first probe and the thousandth attempt is minutes, and the systems that win are the ones scoring velocity and consistency in real time instead of reconciling after the fact. Watch the small charges. They are the loudest signal you get.