Authorization velocity rules are the top pick for card testing detection, because a scripted attack leaves a dense trail of near-identical authorization attempts that a plain counter can catch before the first chargeback lands. Each rule family below was judged on four criteria: how early it fires during an attack, how much data it needs before you can switch it on, how much analyst tuning it demands, and how often it turns away a paying customer. Everything here runs on data you already get in the authorization response or in your own checkout logs, so no new vendor is mandatory.
What card testing looks like in your authorization log
Card testing is a validation step. Someone holding a list of card numbers runs small authorizations to learn which accounts are still live, then uses the survivors or resells them. The fingerprint in your logs is a burst of attempts that share a device, an IP range, or a narrow band of BINs, with a decline rate far above your baseline. Ticket sizes cluster at the smallest amount your gateway accepts. Attempts often land between midnight and 5 a.m. local time, and the same email or account may appear with several different card numbers inside a few minutes.
Track three numbers on a dashboard: authorization attempts per card fingerprint per hour, declines per IP per hour, and the share of approvals under your typical minimum ticket. A simultaneous rise in all three is the signature of a test run.
Velocity rules: the first line of defense
Velocity rules count events over a sliding window and act when the count crosses a limit. Run separate counters for card fingerprint, IP address, device ID, email, billing ZIP, and BIN. A limit of three attempts per card fingerprint per hour and ten per IP per hour catches most scripted runs while leaving normal shoppers untouched.
Pros
- Fires within seconds of the first probe, often before a single approval.
- Cheap to build and easy to explain to support staff and issuers.
- Works on authorization data alone, with no third-party service required.
Cons
- Attackers rotate IPs and cards to stay under any single counter, so you need several keys at once.
- Subscription retries, bulk B2B buyers, and shared corporate NAT can trip IP limits.
- Thresholds drift as your traffic grows and need a quarterly review.
Use velocity rules first if you run any self-hosted checkout. They give the best protection per hour of engineering effort, and they are the only rule type that can stop an attack that is still in progress.
CVC and AVS mismatch escalation
Issuers return CVC and address verification results with the authorization. Treat a failed CVC as a strong signal and a failed AVS as a weaker one, then escalate to a block or a manual review when both fail on the same order.
Pros
- Network-supplied, so there is nothing to build or maintain.
- Strong correlation with fraud on card-not-present orders.
- Useful as a scoring input rather than a hard block, which limits collateral damage.
Cons
- AVS coverage and reliability vary outside the US, Canada, and the UK, where many issuers return partial or unsupported responses.
- Stored-credential and merchant-initiated transactions return no CVC, so they need a separate rule path.
- Address typos and apartment-number formats create genuine false declines.
Use CVC and AVS escalation for physical goods with a shipping address, where a mismatch is meaningful. Note that retaining CVC data after authorization is prohibited under PCI DSS, so the check has to happen inside the authorization request itself.
BIN and issuer-country checks
Compare the card BIN country against the IP country, the billing country, and the shipping country. A US-issued card presented from a hosting-provider IP in another region while shipping domestically is a recurring pattern in test runs.
Pros
- No extra data collection, since BIN and IP arrive with every order.
- Catches geographically impossible orders that pass velocity checks.
- Easy to weight instead of blocking outright.
Cons
- Travelers, expatriates, and VPN users generate legitimate mismatches.
- Prepaid and gift-card BINs are common in honest low-value purchases.
- BIN databases carry licensing costs and go stale without updates.
Best suited to digital goods and high-value catalogs. Score the mismatch and add a challenge step (a second factor or a manual review queue) rather than a flat decline.
Device fingerprint, IP reputation, and proxy detection
Fingerprinting links many attempts to one browser or device even when the attacker changes card numbers and emails. Pair it with IP reputation lists that flag datacenter ranges, open proxies, and known abuse sources.
Pros
- Ties a whole test run together, which velocity counters on a single key cannot do.
- Survives card and email rotation, the most common evasion move.
- Improves every other rule by giving you a stable grouping key.
Cons
- Raises privacy and consent questions that vary by state and country.
- Commercial fingerprinting and reputation services carry monthly costs.
- Mobile carriers and IPv6 rotation produce noise that needs filtering.
Use fingerprinting once you have subscription signups, free trials, or any offer a tester can redeem for value. It pays off fastest for merchants already seeing repeat attacks from rotating IPs.
Micro-amount aggregation and minimum-ticket review
Per-transaction rules miss the tester who spreads fifty tiny charges across fifty cards. Aggregate approvals under a dollar (or your chosen floor) by IP, device, and email, and review the group when the count crosses a limit.
Pros
- Catches the low-value probe pattern that single-order rules ignore by design.
- Can trigger an automatic void or refund before settlement.
- Complements velocity without duplicating it.
Cons
- Adds a time lag, since the group has to build before the rule fires.
- Requires a hold, void, or refund workflow that your operations team must own.
- Harms honest sellers of one-dollar digital items if the floor is set too high.
Recommended for donation pages, trial signups, and any catalog where sub-dollar tickets are unusual for real customers.
Tuning thresholds without drowning in false positives
Run every new rule in shadow mode for two weeks. Log what it would have blocked and compare that list against chargebacks and manual reviews. Keep the rules with a high hit rate and loosen the rest. Set different thresholds per payment method and per sales channel, since card traffic and wallet traffic behave differently. Review declines with your support team each week, because a rule that blocks good customers quietly is worse than the fraud it prevents. Record a decline reason code on every block so you can measure precision later.
Which rule set to start with
Small merchants should enable authorization velocity plus CVC and AVS escalation, which together cover the common scripted attack at near-zero cost. Mid-market merchants should add device fingerprinting and BIN-country scoring to close the rotation gap. High-volume merchants selling digital goods should layer micro-amount aggregation and per-channel thresholds on top, then review rule precision monthly against chargeback data. Start with one rule family, watch the shadow-mode results, and add the next only when the previous one is tuned.