The strongest CVV attack mitigation is a layered control set: verify the CVV on every card-not-present order, throttle attempts by card, IP, device and BIN, and step up to 3D Secure when risk signals fire. The layers below are judged on four criteria: how well each one stops automated card testing, how much friction it adds at checkout, what it costs to run, and how fast a normal merchant team can turn it on. No single control covers every attack pattern, and the merchants who get hit hardest are usually the ones running only a gateway default.

CVV verification on every card-not-present transaction

Requiring the CVV2 value is the cheapest real gate against attacks that use card numbers scraped from a breach. Attackers who hold a number without the printed code fail verification, and the failed attempts show up as a clean, blockable signal.

  • Pros: fast to enable on most gateways; works with any processor; rejects number-only data sets; failure responses can feed your blocklist automatically.
  • Cons: does not shift chargeback liability the way authentication does; attackers who hold full card data including the code still pass; recurring and stored-credential transactions run without a fresh CVV.

Use case: every merchant that accepts card-not-present orders should treat this as the baseline. If you sell digital goods or ship immediately, enable it before anything else.

Velocity limits tied to card, IP, device and BIN

Card testing relies on volume. Attackers push hundreds of low-value attempts through a merchant in minutes, then move on. Velocity rules catch the pattern even when each individual order looks normal.

  • Pros: stops enumeration attacks that pass CVV checks; cheap to configure; catches BIN attacks where sequential numbers share an issuer range; no customer-facing friction until a threshold trips.
  • Cons: thresholds need tuning or you will decline legitimate repeat buyers; shared IP ranges such as corporate networks or mobile carriers can produce false positives; determined attackers rotate proxies and devices.

Use case: high-volume ecommerce and marketplaces. Start with a per-card and per-IP limit over a rolling window, review the decline log weekly, and loosen any rule that blocks repeat customers.

3D Secure and step-up authentication

3D Secure challenges the cardholder through the issuer. In many regions it moves fraud chargeback liability to the issuer when authentication succeeds, which makes it valuable well beyond the fraud it blocks directly.

  • Pros: strong authentication signal; liability shift in supported markets; frictionless flow passes low-risk orders without a challenge.
  • Cons: added step reduces completion for some checkout flows; coverage varies by issuer and region; implementation is heavier than a gateway toggle.

Use case: merchants with high average order value, cross-border volume, or a chargeback ratio that threatens their processing account. Apply it as a step-up on risky orders rather than to everyone.

Address verification, IP reputation and device signals

AVS compares the billing address and postal code against issuer records. IP and device intelligence flags proxies, datacenter ranges, emulators and known fraud tooling.

  • Pros: no customer input beyond the address; catches mismatched data and disposable infrastructure; strong when combined with velocity rules.
  • Cons: AVS support is limited outside the US, UK and Canada; false declines on gift orders and moves; device fingerprinting draws privacy scrutiny in some jurisdictions.

Use case: US and UK merchants shipping physical goods, and any store seeing repeated attempts from the same device fingerprint across different cards.

Not storing CVV after authorization

PCI DSS treats the CVV as sensitive authentication data. It must not be retained after the authorization decision, and storing it turns a breach into a much larger incident.

  • Pros: required for compliance; limits exposure if systems are compromised; simplifies scope for audits.
  • Cons: no reuse for later disputes or manual review; requires tokenization or a vault to handle repeat purchases correctly.

Use case: all merchants. If your order review queue shows the CVV value, that is a finding to fix before anything else on this list.

Monitoring, alerting and review queues

Mitigation fails quietly when nobody watches the results. Track authorization rates, decline reason codes, and the ratio of failed to successful attempts on the same card or IP.

  1. Alert when failed authorizations spike above your hourly baseline.
  2. Alert when one device or IP produces more than a handful of distinct card numbers.
  3. Send small-value orders from new accounts to manual review.
  4. Feed confirmed fraud back into your blocklist the same day.

Use case: any merchant with an in-house fraud or support team. Smaller shops can rely on processor-side radar tools, but the alert thresholds still need an owner.

Choosing a stack by business type

Digital goods sellers should run CVV verification plus tight velocity limits, since delivery is instant and unrecoverable. Physical goods merchants can lean more on AVS and device signals because shipping gives a window to cancel. Subscription businesses need tokenization and issuer authentication instead of repeated CVV checks, which are not available after the first payment. In every case, add one layer at a time and measure decline rates before adding the next, so you can tell which control is doing the work.