CVV Attack Signature Detection: How Merchants Spot Card Testing

What is CVV attack signature detection?

CVV attack signature detection is the practice of matching live payment traffic against known patterns of card testing so a merchant can block an enumeration run before it turns into chargebacks. A signature is a set of measurable traits: request velocity, BIN spread, authorization decline rate, CVV and AVS mismatch rates, device fingerprints, and timing. Detection works by scoring those traits against a baseline of normal traffic for that merchant.

cvv intrusion indicator

The CVV is the 3 or 4 digit verification code printed on a card. Attackers do not guess it in the dark. They push small purchases through a gateway and read the authorization response to learn which card details work. That feedback loop is what makes the traffic stand out in logs, and it is what signature detection keys on.

cvv intrusion indicator

What does a card testing attack look like in payment logs?

Card testing versus standard card fraud

Standard fraud uses one stolen card for a purchase someone wants. Card testing uses thousands of card numbers for tiny purchases nobody wants. The goal is information, so order value stays low and request volume stays high.

read more

Signals that appear in authorization data

• Velocity spikes. Hundreds of authorization requests per minute from one IP, subnet, or device ID.
• BIN concentration. Many cards from a small set of BINs, often issued in one country.
• Uniform amounts. Repeat charges of $0.01 to $5.00, or the same amount across many cards.
• Skewed decline rate. Declines above 90% with a small number of approvals mixed in.
• Geography clashes. Card issuing country, IP country, and billing address country disagree.
• CVV and AVS mismatch clusters. A run of no-match results on the CVV2 check or the street and postal check.
• Shared device data. Identical user agents, screen sizes, or TLS fingerprints across unrelated cards.
• Odd timing. Requests that ignore business hours, or bursts that start and stop inside seconds.

How do you build a CVV attack signature?

1. Baseline normal traffic. Record average and peak authorization volume per hour, per merchant, per country. You need a reference point before any threshold means something.
2. Pull the raw fields. Collect BIN, amount, response code, AVS result, CVV result, IP, device ID, and timestamp in one place.
3. Find clusters. Group traffic by device ID, IP range, BIN, and amount. Attacks show up as dense clusters, not as scattered noise.
4. Define the rule. Combine two or three traits that almost never appear together in honest traffic, such as high decline rate plus shared device ID plus small amounts.
5. Backtest. Run the rule against the last 90 days of data and count how many real orders it would have flagged.
6. Ship, then tune. Start in monitor mode, read the false positive list, then move to blocking.

Should you use rules, models, or both?

Rules catch known signatures with logic you can explain to a risk team or an acquirer. Models catch the shifts attackers make after a rule goes live. Most payment risk stacks run both, with rules handling fast blocks and models scoring the borderline traffic.

Neither approach replaces the other. A pure rule set goes stale as soon as attackers rotate IP pools. A pure model can miss a crude, high-volume burst that a simple velocity cap would have stopped.

What thresholds make sense at the start?

There is no universal number, because normal volume differs by merchant. These are common starting points worth testing against your own data:

• More than 5 authorization attempts on one card number within an hour.
• More than 10 distinct card numbers from one device ID in a day.
• More than 20 declines from one IP address within an hour.
• More than 3 cards per IP per minute during a single checkout session.

Set the first version low enough to catch attacks and high enough to avoid blocking repeat customers. Then watch flag volume for a week before you turn on hard blocks.

What is the response plan once a signature fires?

1. Rate limit the IP, device, or session instead of blocking a whole country.
2. Force step-up authentication, such as 3-D Secure, on the flagged session.
3. Route the order to manual review when the amount is high or the account history is thin.
4. Block the card range if the same BIN shows a sustained attack.
5. Log the full request payload for later analysis and for acquirer disputes.
6. Tell your gateway and acquirer. They see the same campaign across other merchants.

How do you measure whether detection works?

Track four numbers: detection rate on known attacks, false positive rate, time from the first suspicious request to the block, and chargeback rate on card-not-present orders. A rule that catches everything but flags one in five honest orders costs more than it saves.

Review the numbers each month. Attackers change tools, and a signature that worked in March may be noise by June.

Why do detection programs fail?

• Transaction data sits in separate systems, so no one sees the full pattern.
• Only gateway logs get reviewed, and device or IP data is missing.
• Thresholds are set once and never revisited.
• Blocks are applied to whole countries, which kills legitimate sales.
• No one owns the alert queue, so flags sit unread.

Frequently asked questions

Can I store CVV values to check them later?

No. PCI DSS prohibits storing sensitive authentication data, including the CVV2, after authorization. Detection has to run on the authorization response and the surrounding metadata, not on the code itself.

Is card testing the same as account takeover?

No. Card testing validates card data. Account takeover uses a real customer login to place orders. The two overlap when an attacker tests cards inside a hijacked account.

How fast does a card testing run finish?

Large runs can push thousands of requests in minutes. That short window is why velocity based detection beats weekly report reviews.