The top pick for CVV attack detection at most merchants is a tiered rule engine that scores every authorization attempt in real time and routes borderline cases to a human review queue. I ranked the layers below on four criteria: how many enumeration signals each one covers, the false-positive load it adds to manual review, decision latency at checkout, and whether it reuses data your gateway already collects. No single layer catches a card testing run on its own. The stack does.
Layer 1: Velocity and attempt-rate monitoring
Card testing has a shape that normal buying does not. It produces many authorization attempts against one card, one IP, one device, or one billing email inside a short window. Count attempts per card number, per BIN, per IP, per device fingerprint, and per email, then set thresholds on each counter.
- Pros: low build cost, catches scripted testing within a single session, works with logs you already keep.
- Cons: noisy on shared IP ranges, carrier NAT, and corporate proxies; thresholds need tuning per market and per season.
Use this layer first if you have no fraud tooling and process fewer than a few thousand orders a day. It is the cheapest signal with the fastest payoff.
Layer 2: BIN and card-number enumeration signatures
An enumeration run walks a BIN range or a guessed sequence. Watch for near-sequential PANs, repeated first six digits arriving from one source, and a decline-to-approval ratio that sits far above your baseline for a given BIN. Attackers burn through dead numbers to find live ones, so the decline rate on the source is the tell, not the decline rate on the order.
- Pros: strong precision on scripted runs, easy to express as a rule, low compute cost.
- Cons: misses low-and-slow runs that spread attempts across days; needs a baseline per BIN before it means anything.
Choose this layer if your catalog attracts resellers or digital goods, where a live card is worth testing at volume.
Layer 3: CVV and AVS mismatch clustering
A lone CVV mismatch is ordinary. A cluster of mismatches sharing one device, IP, or shipping address is someone guessing. Score mismatch rate per source rather than per order, and compare it against the mismatch rate of your approved population. A source running several times that baseline deserves a block, not a review.
- Pros: maps to the CVV attack model directly, cheap to compute from authorization responses.
- Cons: weak on issuers that do not return detailed response codes; can penalize customers with recently reissued cards.
Best for merchants that already store full authorization responses and can join them to session data.
Layer 4: Device, IP, and behavioral fingerprints
Testing scripts leave traces in the browser and network layer: headless user agents, missing or frozen canvas and WebGL values, datacenter ASNs, timezone and billing country that disagree, paste events in the card field, and checkout completion times that no human can match.
- Pros: survives card rotation, which velocity rules alone do not; useful for linking accounts.
- Cons: privacy review required in some states; fingerprint spoofing erodes accuracy over time.
Deploy this layer when attackers rotate cards and IPs faster than your counters can react.
Layer 5: Model-based scoring
A supervised model blends the signals above into one risk score per attempt. It handles interactions that hand-written rules miss, such as a clean IP paired with a mismatched AVS and a new device.
- Pros: catches novel patterns; ranks review queues by expected loss.
- Cons: needs labeled chargeback data, retraining, and monitoring for drift; opaque scores are hard to defend in a dispute.
Add this once you have at least a few months of labeled fraud outcomes. Below that volume, rules beat models.
Response steps when a CVV attack is confirmed
- Block the source at the edge: IP, device ID, and email domain, with an expiry so you can lift it.
- Raise the challenge level for the affected BIN range, not the whole store.
- Void authorizations that have not settled and stop fulfillment on unshipped orders.
- Notify your acquirer and the card brands with timestamps, attempt counts, and source identifiers.
- Preserve logs for the dispute window before you rotate or delete anything.
Metrics that show detection is working
Track blocked attempt volume, decline rate by source, false-positive rate on manual review, and time from first suspicious attempt to block. A drop in blocked attempts alongside a stable decline rate usually means the attack stopped or moved, not that your rules got better. Review thresholds each quarter against fresh chargeback data.