CVV test fraud is a card testing pattern. Someone runs a string of small authorization attempts against stolen card numbers to learn which ones have a matching CVV and an open account, then uses the confirmed cards for larger purchases. For a merchant, the warning sign is not one bad order. It is a burst of low-dollar attempts, a sharp rise in declines, and a few approvals buried in the middle.

What the pattern looks like in your data

  • Many attempts from one IP range or device fingerprint inside a short window
  • Order values clustered at the lowest amount your checkout will accept
  • A high decline-to-approval ratio on cards that share a bank identification number
  • Billing country, IP country, and shipping destination that do not match
  • Guest checkouts or new accounts with no purchase history

Prerequisites

  • Read access to gateway and authorization logs for at least 90 days
  • Permission to edit velocity rules or fraud filters in your payment stack
  • A written escalation path for blocking sources and voiding orders

How to detect CVV test fraud

  1. Export authorization logs for the past 24 hours with card token, IP, device ID, amount, and response code.
  2. Group the rows by card token, then by IP, then by device ID.
  3. Count attempts per group inside 10-minute windows.
  4. Compare each count against your 90-day baseline for the same hour and weekday.
  5. Filter for amounts at or below your minimum order value.
  6. Highlight groups where the same card appears more than five times.
  7. Flag groups where the same device ID places more than ten attempts.
  8. Pull every approved order inside a flagged group and hold it before fulfillment.
  9. Send the flagged group to your risk queue with a timestamp and a source list.

How to stop it

  1. Require the CVV field on every card-not-present transaction.
  2. Set a velocity limit of one attempt per card per hour.
  3. Set a velocity limit of five attempts per IP per hour.
  4. Require address verification for first-time buyers.
  5. Route flagged groups to 3D Secure step-up authentication.
  6. Block the IP range and device fingerprint tied to the burst.
  7. Void or refund approvals that sit inside a confirmed cluster.
  8. Report the cluster to your acquirer with the log export attached.
  9. Review the same rules after seven days and tighten the thresholds that fired late.

What does not stop it on its own

Address verification catches a mismatched ZIP code but lets a matching one through. A CAPTCHA slows a script for a few minutes. Manual review fails when the queue is long and the amounts are small. Card testing works because the cost per attempt is low and the review threshold is usually set by dollar value, so single controls leave a gap.

Questions merchants ask

Does a CVV mismatch always mean fraud?

No. A typo, a new card, or a stored credential produces the same response. The signal is volume: many mismatches from one source inside a short window.

Why do small charges matter?

They are cheap to run and they test the full authorization path. An approved low-value charge tells the attacker the card, the CVV, and the billing data all match.

How fast should a response be?

Within the same business day. A confirmed cluster will usually repeat against your gateway until the source is blocked.