The short answer
Card testing rules are the automated conditions a payment stack checks before it approves an order. They exist because attackers take lists of stolen card numbers and run them through real checkouts in small batches, watching which ones authorize. The rules that stop this combine velocity caps, small-amount thresholds, address and CVV verification, BIN and issuer-country filters, and device or IP reputation signals. No single rule catches everything. The set works because each rule closes a gap the others leave open.
Card Testing Rules Guide: What You Need to Know
How card testing shows up on a live store
The signature is almost never one large order. It is a cluster of tiny ones arriving together. I look for a run of declines inside a short window, one card per order, billing and shipping details that do not match, and email addresses that look generated. Attackers often target digital goods and instant-delivery items because there is no shipping step to slow them down.
Synonym Card Verification Guidelines: A Comprehensive Guide
Other markers worth watching:
synonym card verification guidelines
- Many attempts from one IP, subnet, or hosting provider range
- Orders spaced a few seconds apart, too fast for a human to type
- Free trials or low-cost subscriptions created in bulk
- A single customer email tied to dozens of different card numbers
- Order values clustered at the lowest possible price point
Rule categories that do the real work
Velocity rules
Cap the number of payment attempts per card, per email, per IP, and per device in a rolling window. Attackers need volume, so tight attempt limits hurt them more than they hurt shoppers. Ten attempts per card per hour is a common starting point.
Card Testing Rules Guide: Ensuring Validity and Security
Amount and basket rules
Flag orders below a floor your normal customers rarely cross. If your average order sits at forty dollars and you suddenly see thirty orders at ninety-nine cents, that is a test run, not a sale.
Verification rules
Require CVV on every transaction and treat an AVS mismatch as a hard decline rather than a review. Step up to 3D Secure when the risk score climbs, since authentication shifts liability and kills most automated attempts outright.
BIN and geography rules
Block or review cards issued in countries you do not ship to. Watch for prepaid and gift card BIN ranges, which are cheap to buy and easy to burn.
Device, IP, and behavioral rules
Score the device fingerprint, check whether the IP belongs to a data center or proxy, and measure time on page. A checkout completed two seconds after landing is not a normal buyer.
Setting thresholds without turning away real customers
Start strict, then loosen. Review every decline your rules produce for the first week and check how many belonged to paying customers. Tighten whichever rule generated the false positives and keep the ones that fired on obvious attacks. Rules should route suspicious traffic to a challenge, not always to a block. A CAPTCHA or a 3DS prompt costs you a sliver of conversion and costs an attacker the entire attempt.
When an attack is already running
- Raise the velocity cap temporarily and block the IPs and BIN ranges involved.
- Turn on 3D Secure for all transactions until the traffic dies down.
- Contact your processor so they know the traffic is fraudulent, not organic.
- Check whether any test charges actually settled and refund or void them.
- Keep the evidence, since chargebacks will follow the approvals.
Metrics worth tracking
- Authorization rate by hour, so a sudden dip stands out
- Decline reasons grouped by code, not as one number
- Average order value over rolling windows
- New customer share versus repeat buyers
- Chargeback ratio, which is the number your acquirer watches
Card testing is a volume game, and so is defending against it. The merchant who notices a shift in the numbers on the same day it happens usually eats a handful of chargebacks. The one who notices a month later eats a monitoring program.