CVV attack IOCs are the traces a card-testing run leaves on your systems: a burst of small declined orders, many card numbers tried from one IP or device, billing data that does not match the card, and sessions that skip straight to the payment step. Fraud teams watch these signals to stop a card verification attack before it turns into chargebacks and processor fines.

A CVV attack takes nothing from your site. The attacker already holds a list of stolen card numbers with CVVs and wants to learn which ones still work. Your checkout is the test bench.

How does a card verification attack run against a checkout?

The mechanics are simple and repeatable. A script does the work in seconds.

  1. The attacker loads a stolen card list into a script or a bot farm.
  2. The script submits an authorization request per card, often at a low amount.
  3. The response code tells the attacker if the card is live. Approvals and soft declines such as insufficient funds mark a working card. Hard declines such as stolen or closed mark a dead one.
  4. Working cards get sold or cashed out. Dead ones get dropped from the list.

Every step is a real request against your acquirer, so the attack shows in your data whether or not an order ships.

Which IOCs show up first?

Look at three layers. The transaction table lights up first, but network and behavior logs confirm the pattern.

Transaction and authorization indicators

  • Decline rate on one BIN or card range that jumps outside your normal band.
  • Many authorizations at $0 to $1, or repeated $1 auth and void pairs.
  • The same card number submitted with several different CVVs or expiry dates.
  • One customer ID or email tied to dozens of card numbers in an hour.
  • Approvals followed by instant cancellation, or orders that never pass the shipping step.

Network and device indicators

  • A single IP or a small subnet block hitting the payment endpoint.
  • Traffic from datacenter ASNs, proxy pools, or VPN ranges your normal buyers do not use.
  • Headless browser fingerprints, empty referrers, no mouse movement, instant form fills.
  • A fresh device ID for every order, or one device ID spread over many cards.
  • Requests to the payment API with no session on the product pages.

Account and behavior indicators

  • New accounts with disposable email domains and no order history.
  • Checkout sessions that last a few seconds from landing page to payment submit.
  • One shipping address with a rotating set of card numbers and names.
  • Failed card attempts across many accounts from the same browser build.

How do you separate an attack from normal decline noise?

Compare the current hour against the same hour last week and against your daily mean. A single spike can be a bad gateway. A spike in card churn plus card attempts per IP is a test run.

Ratios beat raw counts. Track declines per session, distinct cards per IP per hour, and CVV mismatch rate per BIN. Set alert thresholds from your own baseline, not from a vendor default.

What should you do when the IOCs fire?

  1. Throttle the payment endpoint and add a challenge at the card step.
  2. Turn on 3-D Secure or a CAPTCHA for the flagged traffic segment.
  3. Block the IP, ASN, and device set tied to the burst.
  4. Call your acquirer and describe what you see. Early notice protects your fraud ratio.
  5. Preserve logs: request timestamps, response codes, IPs, device IDs, session traces.
  6. Review every approval inside the attack window for fraud before you ship.

Which fields do you need to log to catch the next run?

Store the fields that let you rebuild a session. Without them the IOCs are gone by the time you look.

  • Full response code and the raw acquirer message per attempt.
  • Card BIN and last four, never the full PAN.
  • IP, ASN, user agent, device fingerprint, and session ID.
  • Time from first page view to payment submit.
  • Account age, email domain, and shipping address hash.

How do you harden checkout against card testing?

Prevention costs less than cleanup. Small friction at the payment step stops scripts without hurting real buyers.

  • Force 3-D Secure on high-risk segments: new accounts, datacenter IPs, unusual geos.
  • Require an account or email verification before the payment page.
  • Rate limit per IP, per device, and per card BIN, not just per session.
  • Add a CAPTCHA to the card step when velocity passes your threshold.
  • Reject mismatched billing country and card BIN country for new buyers.

FAQ

Is a CVV attack the same as card testing?

Yes in practice. Card testing is the wider term. A CVV attack is the version that checks the security code along with the card number, and both show up as bursts of small authorizations.

Can a CVV attack succeed without approved transactions?

Yes. Attackers read decline codes too, and a do-not-honor or insufficient-funds response still confirms the card is live. Your decline data is the asset they mine.

How long does a card testing burst last?

Some run for minutes. Others spread thin over days to stay under velocity rules. Low and slow is the harder pattern, so watch weekly ratios alongside hourly spikes.

Do you need a fraud vendor to catch this?

No. Most CVV attack IOCs sit in logs you already collect. Rules on decline ratio, card churn per IP, and session speed catch the common runs before a vendor contract earns its cost.