What is a card validation attack?
A card validation attack is an automated attempt to find live payment cards by pushing many small authorization requests through a checkout and recording which ones approve. The trade also calls it card checking, card testing, or a BIN attack. The "v9" tag in card validation attack v9 points to a version number on a card-checking script or service, so it describes a tool release rather than a separate attack type.
The goal is information, not goods. A working card number has resale value, and a script that sorts dead numbers from live ones turns a messy list into a product. That is why the charge amounts stay tiny and the order volume gets huge.
How the attack runs
Most campaigns follow the same broad pattern. Attackers load a list of card numbers into a script that acts like a shopper, then fire authorization requests at one or more merchants and watch the responses.
Card Validation Attack v7 Buying Guide
- Collect card numbers from breaches, phishing pages, or criminal markets.
- Send small requests, often under a dollar, through a live checkout page.
- Log the response codes. Approvals mark a card as live, declines mark it as dead or blocked.
- Retry flagged cards later with new details to slip past simple filters.
- Resell or use confirmed cards before issuers close them.
None of this needs a physical card or the cardholder's consent. The script only needs a payment endpoint that answers fast.
Why attackers favor real checkouts
A merchant's own checkout gives the cleanest signal, because a live gateway response tells the attacker whether the card works right now. Some scripts also probe tokenization and card updater services to stretch the life of a card number. That is why validation traffic lands on ordinary stores rather than on card network test systems.
What a card validation attack looks like from the merchant side
The first sign is often a spike in authorization attempts with almost no matching sales. Fraud teams watch for that gap, because real shoppers approve at a far higher rate than scripts do.
- A burst of small orders from one IP address or a small set of them.
- Many cards sharing one BIN, one email pattern, or one device fingerprint.
- High decline rates mixed with a few approvals inside a short window.
- Orders with mismatched billing country, IP country, and shipping address.
- Traffic to the payment step that far exceeds traffic to product pages.
Some campaigns spread attempts across hundreds of IP addresses to hide the shape of the attack. In those cases the card numbers themselves and the timing give the pattern away.
Why it matters to merchants
Card validation attacks cost money in several places at once. Every attempt carries an authorization fee, and card networks bill merchants for excessive declines and chargebacks. A flood of $0.50 probes can burn through a small store's margin in a single night.
Then there is the account risk. Acquirers and processors monitor card testing activity, and an account that keeps feeding it can be frozen or closed. Recovery takes weeks and often a new processor relationship.
How to stop card validation attacks
- Rate limit the checkout and the payment endpoint by IP, device, and card BIN.
- Add a CAPTCHA or a proof-of-work challenge before payment for suspicious sessions.
- Require CVV and AVS checks, and reject orders that fail both.
- Turn on 3D Secure, which adds a step scripts cannot fake and shifts liability.
- Run a fraud scoring service that flags enumeration patterns, not just single orders.
- Block or challenge datacenter IPs, disposable email domains, and headless browsers.
- Review decline rates each day and set alerts for sudden spikes.
Rules worth writing into your fraud stack
Keep a rule that rejects more than N payment attempts per card, per device, or per IP within an hour. Add a second rule for low-value orders from customers with no purchase history. Keep error messages vague: never tell a script whether a card failed because it is dead or because it was blocked.
If your card was tested
Cardholders learn about this through a small pending charge or a fraud alert, not through a purchase they made. Report it to the issuer and ask for a new number, since a card flagged as live gets used again.
Freeze the card in your banking app while you wait for the replacement. Check the account for other small charges, because testers often run several before they stop.
FAQ
Is a card validation attack the same as carding?
Related, not identical. Validation confirms which numbers are live. Carding is the follow-on step where those numbers buy goods or get cashed out.
Does CVV verification stop card validation attacks?
It raises the cost but does not end them. Some scripts hold full card data that includes the CVV, and some merchants expose endpoints that skip the check.
How fast can a card validation attack run?
Thousands of attempts per minute against an unprotected endpoint. Well-defended stores see the same volume broken into slow, spread-out probes instead.
Key takeaways
- A card validation attack confirms live card numbers through small authorization requests.
- The v9 label marks a script or service version, not a new class of fraud.
- Rate limits, CAPTCHA, 3D Secure, and enumeration-aware scoring cut the volume fast.
- Merchants pay through fees, chargebacks, and processor risk even when no goods ship.