CVV Test Scenario Guide: Safe Card Verification Testing
A CVV test scenario checks how your checkout handles card verification values. Run them in a sandbox with test cards, never with live card data.
Card Validation Attack: Detection Guide for Merchants
Answer
A card validation attack is a burst of payment authorization requests sent to one merchant. Each request carries a different card number. The sender reads the response and sorts live cards from dead ones. The practice also goes by card testing, card enumeration, and carding attack. The attacker wants a list of working card numbers, not the goods in the cart.
What the traffic looks like
Attempts arrive from many IP addresses, often residential proxies or a botnet. Cart values sit near the minimum, from $0.01 to $5. Billing details are random. One email domain can appear across dozens of orders. Requests hit the payment endpoint with no session on the site: no product page views, no cart edits, no time on the checkout form.
A single campaign can send thousands of requests in an hour. Attackers stop when the decline rate rises or the merchant blocks the source.
Signals in the logs
- Authorization count jumps while order count stays flat.
- Decline rate moves from a 5 to 10 percent band to 40 percent or higher.
- CVV response code N (no match) repeats across unrelated card numbers.
- AVS response codes are absent or mismatched on most attempts.
- Many card BINs and issuing banks appear under one merchant account in a short window.
- Device fingerprints, email addresses, and IP addresses change on most attempts.
- Approved orders ship to a small set of addresses.
Detection methods
Velocity rules are the first layer. Count authorization attempts per IP address, per card BIN, per email, per device ID, and per shipping address. Set thresholds against a baseline of normal traffic, not a fixed number.
Decline codes carry data. Issuer responses such as "do not honor", "invalid card number", and "pick up card" cluster during an attack. Feed those codes into a rule that raises the risk score for the source.
Machine learning models score each authorization on device, network, and behavioral inputs. Models catch attacks that stay under fixed velocity thresholds. They need labeled fraud data and retraining to hold accuracy.
Controls that cut the volume
- Rate limit the payment endpoint at the edge, before the gateway call.
- Add a challenge such as CAPTCHA or a device check to the first transaction from a new client.
- Require 3-D Secure for card-not-present orders. The issuer authenticates the cardholder. Liability shifts to the issuer when authentication succeeds.
- Block IP ranges and device IDs tied to prior attacks. Rotate the list as sources change.
- Alert on authorization volume, not on settled dollar volume. A card testing run costs fees before it produces one chargeback.
- Send gateway decline responses to the fraud system in real time.
Cost and reporting gaps
Each declined authorization carries an interchange or gateway fee, so a run of 10,000 attempts produces a bill with no revenue. Chargebacks follow when approved cards are used for goods.
Public loss figures differ by source and year. Many attacks go unreported. Merchants count the cost in fees and staff time rather than in one line item. No single number covers the total.