What a card validation attack is
A card validation attack is a burst of payment requests sent to a merchant to test if stolen card numbers work. The attacker wants a yes or no answer. An approved small charge marks the card as live. A decline marks it as dead. Stolen card data gets sold in bulk, and buyers need to know which numbers still work. Testing is how they sort the list.
Why merchants get the traffic
Attackers pick merchants with weak checks: no CVV requirement, no address verification, no velocity limit, no 3-D Secure. Donation pages, gift card sales, and low-price digital goods are common targets. Each test costs the merchant an authorization fee. A run of 10,000 tests can cost thousands in fees and chargebacks before anyone notices.
Signs of a card validation attack
- Order volume jumps in a short window, often at night.
- Many orders from one IP range or one device fingerprint.
- Card numbers in sequence, or many cards on one customer record.
- Order totals cluster at the same low amount.
- The decline rate climbs while the approval rate stays flat.
- Email addresses with random strings or disposable domains.
- Billing addresses that do not match the card.
Detection
Watch authorization logs, not just settled orders. Declines are the first signal. Most attacks show a high ratio of declines to approvals. Fraud teams track requests per IP, per card BIN, per email, and per device in rolling windows of minutes. A rule that fires on 3 or more attempts per card per hour catches most scripts.
Card networks offer account status inquiry services. These let a merchant check if an account is open without booking a full authorization. Merchants that use them see fewer test charges settle.
Prevention
- Require CVV and AVS on every transaction.
- Apply 3-D Secure to high-risk orders and first-time buyers.
- Set velocity limits per IP, per card, per email, and per device.
- Add a CAPTCHA or bot check at checkout when request rates spike.
- Block disposable email domains and known proxy ranges.
- Score each authorization with a fraud vendor.
- Review small card-not-present orders before capture.
Response steps
- Log the request data: IP, user agent, card BIN, amount, timestamp.
- Block the source ranges and device fingerprints.
- Void or refund test charges that settled.
- Contact the acquirer and the card network fraud desk.
- File a complaint with the Federal Trade Commission.
What not to do
Do not test cards back. Do not keep the card data. Storage of full card numbers after authorization has no business need and raises PCI scope. PCI DSS bans storage of the card verification value after authorization.