A card testing alert is a notification that someone is running many small authorization attempts against your checkout to find out which card numbers are still live. It fires when a burst of low-value, rapid, scripted transactions looks more like an automated probe than real customers. Treat it as an active attack, not a routine decline spike.
Card Testing Alert V10: What You Need to Know
Why card testing triggers an alert
Attackers rarely have a confirmed working card number. They have lists, and they need your payment page to tell them which entries in the list get an approval instead of a decline. Because stolen cards get blocked quickly once they are used, the validating happens fast and cheap: tiny amounts, many attempts, short intervals.
Risk engines and processors watch for that pattern and raise a card testing alert when the shape of the traffic matches it. Typical markers include:
- A steep jump in authorization volume in minutes, not days
- Average ticket size far below your normal order value
- Decline rates climbing sharply while approvals cluster on a few BINs
- Hundreds of different card numbers from a small pool of IP addresses or devices
- Sequential or near-sequential card numbers and matching expiry patterns
- Checkout completions that skips real shipping or contact details
What to do in the first hour
- Stop the traffic. Turn on your fraud rule for velocity per IP, device, email, and BIN, and tighten the threshold for low-value orders.
- Require more friction. Enable CAPTCHA or 3-D Secure for suspicious segments so automated scripts cannot complete an authorization loop.
- Notify your provider. Call or ticket your payment processor and acquiring bank. They can block the offending BIN ranges and IPs upstream, faster than you can on your own.
- Preserve evidence. Export logs with timestamps, IPs, device fingerprints, user agents, and authorization responses before your retention window rolls over.
- Review card verification settings. Confirm whether address verification and CVV checks are set to reject mismatches instead of allowing them through.
What the alert does not tell you
An alert is a signal, not a verdict. A legitimate promotion, a broken test environment, or a misconfigured integration can also produce a wave of small declines. Before you block traffic, check whether the attempts come from your own staging keys, a retry loop in your checkout, or a marketing campaign that went live at the same moment. False positives hurt real buyers, so scope any block to the narrowest segment that explains the pattern.
Card Testing Alert V7: A Comprehensive Guide
Prevention that lowers repeat risk
- Set a hard floor on order value and require manual review under it
- Rate limit authorization attempts by IP, card fingerprint, and email address
- Reject mismatched CVV and postal code responses rather than queuing them
- Monitor decline-to-approval ratios daily, not monthly
- Keep an alert threshold that pages someone, with a runbook attached
- Log every authorization attempt with the response code for later tracing
Card testing is cheap for the attacker and expensive for you: chargeback fees, scheme fines, and a processor that starts asking questions. A card testing alert exists to give you the minutes you need to cut the loop before the list is fully validated.