Card testing rules are the checks and thresholds a payment stack runs on a checkout to catch a stolen card before the fraudster moves on. They combine velocity limits, BIN and geography filters, CVV and AVS responses, and device signals, then block or step up the order when enough of those signals fire at once. A tuned rule set stops the small authorization probes that come before a large fraud run while leaving real customers alone.
What does card testing look like in a payment log?
Card testing is a fraudster running stolen card numbers through a live checkout to learn which ones still work. The order itself is not the goal. The goal is the authorization response: approved cards get kept, declined cards get thrown away.
On a merchant dashboard it shows up as a burst of low-value orders, often between $0.50 and $5, across many different card numbers in a short window.
- Many orders from one IP address, device fingerprint, or email domain.
- Card numbers that run in sequence or share a BIN.
- Billing address, shipping address, and IP country that do not match.
- Disposable email domains and auto-generated customer names.
- A decline rate far above your normal baseline.
- Orders placed during the overnight hours of the card issuer's time zone.
One attack can push hundreds of authorization attempts through in minutes. Each attempt costs an authorization fee even when it fails, and the approved ones come back later as chargebacks.
Why card testing costs more than the stolen goods
The direct loss is the smallest part of the bill. Authorization attempts, chargeback fees, refunds, and shipping losses stack on top of each other, and the pattern itself damages the account.
- Per-attempt fees: every authorization, approved or not, is billable.
- Chargebacks: each one carries a fee plus the sale amount.
- Network programs: high fraud and dispute ratios trigger monitoring.
- Processor risk: acquirers can raise reserves, add fees, or end the relationship.
The core rule categories
1. Velocity rules
Velocity rules count events over a window: attempts per card, per IP, per device, per email, per shipping address. A common set allows a few attempts per card per hour and a larger number per IP per day. Velocity carries the most weight of any rule family because card testing is a volume crime.
2. Amount and pattern rules
Attackers start with small amounts to keep the risk low. A rule that flags any order under a few dollars from a new customer, or several sub-$5 orders from the same device, catches the probe phase. Watch for repeated round numbers and for the same amount appearing across many cards.
3. BIN, geography, and issuer rules
The first six to eight digits of a card identify the issuer, the card brand, and the card type. A BIN rule can require that the card's issuing country match the billing country, or block BINs with a fraud history on your account. Card testing operations often use BINs from one region and IPs from another.
4. CVV, AVS, and 3DS rules
CVV and AVS checks compare what the buyer typed against what the issuer holds. A full mismatch on both is a strong signal. 3D Secure shifts liability and forces an authentication step that bulk testing tools cannot pass, which makes it the most reliable brake on card testing.
5. Device, IP, and identity rules
Device fingerprinting, IP reputation, and proxy detection separate a real shopper from a script. Rules here look for known datacenter IP ranges, VPN exits, browser automation flags, and one device tied to many cards.
6. Behavioral and session rules
Real shoppers browse. Bots go straight to checkout. Rules that measure time on site, mouse movement, form fill speed, and page depth catch traffic that ignores the store and only wants the payment form.
How do you set thresholds without blocking real customers?
Start in monitor mode. Log what each rule would have caught for two to four weeks, then compare the flagged orders against your chargeback record. Set thresholds so the rule catches the attack pattern with a false-positive rate you can live with.
- Baseline normal traffic: orders per hour, average order value, decline rate.
- Turn on rules in alert mode and review the hits by hand.
- Set the block threshold above the highest legitimate volume you see.
- Layer rules into a score instead of blocking on one signal.
- Review weekly, since attackers rotate IPs and BINs.
Single-signal blocks cause the most false declines. A shared IP address is common in offices, dorms, and mobile networks, so pair that signal with a card mismatch before you block.
What network programs punish card testing?
Both major card brands run monitoring programs that flag merchants with fraud and dispute rates above a set threshold. Visa's Acquirer Monitoring Program and Mastercard's excessive fraud and chargeback programs can lead to fines and, in serious cases, loss of card acceptance. Card testing inflates both ratios at once, so the risk goes past the sale you lose.
FAQ
Are card testing rules the same as general fraud rules?
Mostly, with a different emphasis. General fraud rules look for a bad order. Card testing rules look for a bad pattern across many orders, so velocity and device rules carry more weight.
Does blocking by IP stop card testing?
No. Attackers rotate through proxy pools and mobile IPs, so an IP block list goes stale in days. Use IP reputation as one input in a score, not as a standalone block.
Does 3D Secure stop card testing?
It removes most of it. Bulk testing tools rarely pass an authentication challenge, so a step-up at checkout sends testers to easier targets. Expect some friction and a small drop in conversion.
How fast should a card testing rule respond?
At authorization time. Rules that run after the order is placed stop the shipment but not the attempt, and the attempt is what builds the fee and chargeback trail.
What data can I keep to build these rules?
Full card numbers cannot be stored after authorization unless you meet PCI DSS requirements, so most rule engines key off tokens, BIN, last four digits, device IDs, and hashed email. Keep the retention window short and documented.