Card testing detection rules are automated conditions that flag or block transactions matching known patterns of stolen-card probing. They combine velocity limits, BIN and geography checks, amount thresholds, device fingerprints, and authorization outcomes into a single risk score. The goal is to catch a carding attack in its first minutes, before the fraud turns into chargebacks and network fines.
card testing rules for merchants
What does a card testing attack look like?
A card tester holds a list of stolen card numbers and needs to learn which ones still work. The method is simple: run a small charge, often under $1, and read the authorization result. Approvals mark live cards, declines mark dead ones.
card testing rules for merchants
Early traffic looks clean on a per-card basis. Each card gets one or two attempts, so card-level counters stay flat. The pattern appears only when you group attempts by IP address, device, email domain, or time window.
card testing rules and regulations
Which signals feed detection rules?
Rules are only as good as the fields they read. Most fraud platforms pull from the authorization request, the checkout session, and the customer account.
- Velocity: attempts per IP, per device, per email, per card BIN, per shipping address, per time window.
- Geography: BIN country versus IP country versus billing country, plus the distance between them.
- Amount: order value, round numbers, repeated identical totals.
- Outcome: decline ratio, response codes such as do-not-honor, AVS and CVV match results.
- Device: fingerprint, user agent, headless browser markers, proxy and VPN flags.
- Behavior: time on page, form fill speed, mouse movement, paste events in card fields.
Core card testing detection rules to deploy
1. Velocity rules
Start with a hard cap on failed attempts from one IP address in a rolling window. A limit of 5 declines in 10 minutes catches most bots without touching normal shoppers.
Add a second layer at the payment method level. Ten different card numbers used from one session in an hour is a carding signature, not a family sharing a laptop.
2. BIN and geography rules
Block or review when the card's issuing country, the IP country, and the billing country do not match. A US-issued card used from a data center IP in another region is worth a challenge.
Track BIN-level bursts too. If one BIN prefix produces 40 declines in 15 minutes, the attacker is walking a range of numbers from a single bank.
3. Amount and outcome rules
Small-ticket probes cluster below the amount that triggers manual review. Set a rule that scores any order under $2 that arrives with a new email, a new device, and no account history.
Watch decline ratios per session. A session with 8 attempts and 8 declines earns a block even if each attempt looks harmless on its own.
4. Device and fingerprint rules
Card testers rotate IPs, so device fingerprint carries more weight. One fingerprint tied to 25 card numbers in a day is a strong signal.
Flag headless browsers, automation frameworks, and missing device APIs. Legitimate checkout traffic returns a stable set of client attributes.
5. Behavioral and timing rules
Humans take time to type a card number. Bots post the form in under two seconds. A rule on form fill duration catches scripted attempts without penalizing slow typists.
Check the clock as well. Attacks often run in the merchant's off-hours, when staffing is thin and review queues are empty.
How do you set thresholds without blocking real customers?
Start rules in monitor mode. Score the traffic, log what would have been blocked, and compare that list against your known-good orders.
Then move in stages: challenge first, block second. A 3-D Secure step kills most carding bots because they cannot pass authentication.
Review every rule against a baseline of false positives. A rule that blocks 5 real orders to stop 10 fake ones costs more than it saves.
Where do detection rules fail?
Rules miss distributed attacks that spread attempts across thousands of IPs and devices. Aggregation at the account level is the only way to see that shape.
Rules also decay. Attackers learn thresholds and stay just under them, so a limit that worked last quarter may sit idle today. Schedule a monthly review of hit rates and blocked-attack volume.
FAQ
What is the first card testing rule to turn on?
Block more than 5 failed authorization attempts from one IP in 10 minutes. It costs little, catches basic bots, and gives you a baseline for tuning.
Do these rules work on mobile checkouts?
Yes, with tweaks. Mobile traffic has shorter form times and shared IP ranges on carrier networks, so weight device fingerprint and account history higher than IP.
How many rules should a store run?
Between 15 and 40 active rules covers most small and mid-size merchants. More rules add overlap and make it hard to trace which condition blocked a good order.
Do card testing detection rules need machine learning?
No. Rules handle known patterns well and stay explainable. Machine learning helps with distributed attacks where no single threshold fires.
Key takeaways
- Card testing shows up in aggregate, not in single transactions.
- Velocity, geography, amount, device, and outcome signals form the base rule set.
- Run new rules in monitor mode and challenge before you block.
- Review thresholds every month, because attackers tune to your limits.