A fraud detection card test is a small, low-value authorization attempt used to find out whether a card number is active and able to approve. Attackers run thousands of these tests because most will fail, and the ones that succeed reveal which card numbers are still usable. For merchants and issuers, the point of fraud detection is to recognize that testing pattern early, before it turns into a wave of chargebacks. This guide covers detection and prevention from the merchant side, not instructions for running card tests.
How card testing shows up in your data
Card testing rarely looks like one dramatic event. It looks like a burst of activity that does not match how real customers behave.
- Many small orders, often near a minimum amount, placed in a short window
- A high share of declines mixed with a few approvals
- Multiple card numbers coming from the same device, IP address, or email domain
- Billing data that is formatted correctly but does not match the card
- Attempts spread across many BIN ranges to probe different issuers
- Traffic concentrated in minutes rather than spread through the day
Signals worth tracking
Velocity checks are the foundation. Count attempts per IP, device fingerprint, email, phone number, shipping address, and card BIN, then set thresholds that trigger review. Pair velocity with the authorization response itself: repeated CVV mismatches, AVS failures, and do-not-honor codes from the same source are strong fraud detection signals. Device and network data add context, since card testing traffic often originates from datacenter IPs, proxies, and headless browsers instead of normal consumer connections.
Why card testing hurts even when it fails
Failed authorizations are not free. They add gateway and processor fees on many plans, raise your decline ratio, and can push you into card network monitoring programs that carry their own penalties. Successful tests convert into fraudulent orders, which lead to chargebacks, lost inventory, and higher processing costs. The longer a testing campaign runs unnoticed, the more expensive the cleanup gets.
What to do when you detect it
- Set velocity limits per IP, device, email, and BIN, and throttle rather than only block
- Require CVV and full AVS verification on low-value orders from new customers
- Add a challenge step such as a CAPTCHA on checkout and account endpoints during spikes
- Block or slow traffic from known proxy, VPN, and datacenter ranges
- Route suspicious orders through 3D Secure so the issuer authenticates the cardholder
- Review decline-to-approval ratios daily and alert on sudden shifts
- Log every attempt with device and network data so patterns are visible after the fact
Fast detection matters more than perfect detection. A velocity rule that slows a testing campaign within minutes protects far more revenue than a manual review queue that catches it a week later.