CVV Attack Mitigation Techniques: Stop Card Testing

CVV attack mitigation, in short

A CVV attack is a card testing scheme: someone submits large volumes of card numbers with guessed card verification values, looking for combinations that authorize. The defense is layered. Enforce strict per-card and per-IP attempt limits, force a challenge after the first failed authorization, decline on address verification mismatches, and watch your authorization log for bursts of small-value attempts. No single control stops card testing. Velocity caps plus issuer decline rules plus merchant-side monitoring push the success rate close to zero and cut the interchange fees you pay on each declined attempt.

What the attack looks like in your data

• Hundreds of authorizations from one IP range inside a few minutes.
• Many card numbers, few or no repeat customers.
• Low-dollar amounts, often under five dollars, used to test whether a card works.
• A spike in declines with error codes tied to invalid verification values.
• Traffic from proxies, VPN endpoints, or data-center IP blocks instead of residential ones.

Prerequisites

• Access to your gateway's raw authorization log, including response codes and timestamps.
• Permission to change rules in your payment gateway or fraud tool.
• A named owner for fraud alerts, so someone acts when a rule fires.
• Written escalation steps for your acquiring bank and processor.

Mitigation steps

1. Pull the last 24 hours of authorization records and sort by IP address.
2. Count attempts per IP address and per card number.
3. Set a hard cap of three to five attempts per card number per hour in your gateway rules.
4. Set a second cap on attempts per IP address per hour, then tune it down as you see normal traffic levels.
5. Turn on a challenge — CAPTCHA, device fingerprint, or 3-D Secure — for any session that fails one authorization.
6. Enable address verification and require a match on the street number and postal code.
7. Require the CVV check to return a full match before you capture funds.
8. Block requests from hosting providers and known proxy ranges if your customer base is local.
9. Add the offending IP ranges and card BINs to your blocklist.
10. Route all flagged orders to manual review instead of auto-approving or auto-voiding them.
11. Ask your processor to apply issuer-level decline rules on the BINs you see abused.
12. Log every rule change with a date and an owner so you can roll back a bad threshold.

Issuer and processor controls

Merchant controls only cover your own checkout. Issuers can decline repeated verification failures at the network level, and processors can flag BIN ranges with abnormal authorization patterns. Ask your acquiring bank what decline rules already exist on your account and what thresholds trigger them. Store nothing you are not allowed to store: PCI DSS treats the verification value as sensitive authentication data, so it cannot be retained after authorization. Tokenization keeps repeat buyers working without keeping that value on your systems.

Signals to monitor

• Authorization volume per minute, compared to the same hour last week.
• Ratio of declines to approvals by BIN.
• Average order value, tracked daily.
• Number of distinct cards used from one device fingerprint.
• Chargeback rate by payment method and country.

Common mistakes

• Setting a per-IP limit only. Attackers rotate IP addresses constantly.
• Waiting for chargebacks before acting. Card testing costs you fees long before a chargeback lands.
• Blocking an entire country instead of the specific ranges causing the problem.
• Leaving manual review queues unstaffed overnight and on weekends.
• Failing to notify your acquirer, which delays network-level blocking.