A CVV attack, also called card testing or carding, is a fraud pattern where someone pushes a high volume of authorization attempts through a checkout to learn which stolen card numbers are still live. The top defense is a layered setup: require CVV and AVS on every authorization, cap how many attempts any single card, IP, device, or email can generate, and route risky sessions through 3-D Secure. That combination wins because it attacks the economics of enumeration. Each try gets more expensive, more visible, and less likely to return a useful answer. The criteria here are how directly a control blocks testing, how fast it can be switched on with a standard payment processor, and how many legitimate customers it risks declining.

How card testing looks in your transaction data

Card testing rarely hides well once you know the shape of it. You see bursts of attempts in short windows, often dozens of authorizations from a handful of IP addresses. Decline rates climb while average order value stays flat and low. Many different card numbers share one billing address, one email pattern, or one device fingerprint. You may see repeated CVV mismatch responses on the same card across several attempts. Chargebacks usually arrive weeks later, after the attacker has already moved on to another merchant.

Defense 1: CVV and AVS enforcement on every authorization

Requiring the card verification value and running address verification is the baseline control. It forces the attacker to hold more than a card number. A dump that includes only a PAN and expiry fails at the first attempt, which removes a large share of cheap, recycled data from your checkout.

Pros

  • Blocks attempts that rely on card numbers alone
  • Available as a toggle in nearly every gateway and processor
  • Produces mismatch reason codes you can act on immediately

Cons

  • Typing errors and moved households create false declines
  • AVS coverage is weaker outside the United States
  • PCI DSS forbids storing the CVV after authorization, so you cannot re-verify later

Use this as your default posture. Treat a CVV mismatch combined with an AVS mismatch as a hard stop on that session, not just that order.

Defense 2: Velocity limits and rate limiting

Enumeration needs volume. Limits on attempts per card, per IP, per device, and per email address remove that volume. A simple rule set, such as five declines in ten minutes triggering a temporary block, stops most automated runs.

Pros

  • Cheap to build and independent of your processor
  • Slows both scripted and manual testing
  • Protects endpoints beyond checkout, including account login and card-on-file updates

Cons

  • Needs tuning to avoid blocking offices, libraries, and shared networks
  • Attackers rotate through proxy pools to spread attempts
  • Poorly tuned rules can decline loyal customers

Start with generous thresholds during business hours for your main markets, then tighten based on what your own decline data shows.

Defense 3: 3-D Secure and risk-based authentication

Step-up authentication moves the decision to the issuer. When a transaction is challenged, the attacker needs the cardholder's device and credentials, not just the card data. Liability for fraud chargebacks often shifts to the issuer when authentication succeeds, which changes who absorbs the loss.

Pros

  • Breaks automated testing at the point of payment
  • Can be applied selectively to risky sessions only
  • Provides a strong signal for future risk scoring

Cons

  • Adds friction and reduces conversion when applied broadly
  • Issuer support and exemption rules vary by market
  • Requires integration work beyond a basic gateway setup

Apply it to new customers, mismatched AVS results, and traffic from regions where you see little legitimate volume.

Defense 4: Monitoring, blocklists, and processor fraud tools

Rules catch known patterns. Monitoring catches the rest. Watch authorization-to-sale ratios, decline clusters, and card numbers that appear across unrelated accounts. Most processors offer built-in fraud scoring that flags testing behavior without custom development.

Pros

  • Surfaces patterns that static rules miss
  • Vendor models are trained on data from many merchants
  • Alerts let you react while the attack is still running

Cons

  • False positives require a review queue and staff time
  • Model reasoning is often opaque
  • Tooling costs scale with transaction volume

Defense 5: Tokenization and staying inside PCI scope

Tokenization replaces stored card numbers with a reference value, so a breach of your systems yields nothing usable. It does not stop a live-card attack by itself, but it limits the damage if testing traffic is a probe for a larger intrusion. Keeping sensitive authentication data out of your environment is also a PCI DSS requirement, not an option.

Pros

  • Removes stored card data from your systems
  • Simplifies PCI DSS compliance work
  • Supports recurring billing without holding the PAN

Cons

  • Requires integration and migration effort
  • Adds a dependency on your token provider
  • No direct effect on checkout-time testing

Which combination fits your situation

A small merchant on a hosted checkout should enable CVV and AVS, add basic velocity rules, and turn on CAPTCHA at the payment step. That covers most automated runs with minimal build cost.

A high-volume merchant with custom checkout code should layer 3-D Secure on risky sessions, use processor fraud scoring, and staff a review queue for flagged orders. The extra friction is justified by the volume of attempts you attract.

Subscriptions and card-on-file businesses need the same controls plus tight limits on how often a stored card or account can be modified, since account takeover often precedes a testing run. Track declines per card and per customer, and alert when either number moves.