CVV Test Cases: A QA Guide to Card Security Code Validation
CVV test cases check the card security code field: 3 or 4 digits, digits only, and correct handling of every gateway response code.
Card Testing Defense: Stop Card Attacks at Checkout
Card testing defense is the set of controls that stops attackers from pushing stolen card numbers through your checkout to learn which ones still authorize. The short answer: block the attempts at the edge with rate limits and bot challenges, make each attempt expensive with card verification value and address checks, and watch decline patterns so you can shut down an attack while it is running.
How Card Testing Works
An attacker loads a list of card numbers into a script and fires thousands of requests at your payment form. Each request uses a small amount, frequently under a dollar, and a new IP address. Approved cards go into a resale list. Declined cards get discarded. The operator never intends to receive the goods.
The cost lands on you. You pay authorization fees on traffic that never converts, your approval rate drops, and cardholders whose numbers were tested file disputes weeks later. Enough disputes and your processor adds monitoring fees or freezes the account.
Warning Signs
- A burst of authorization attempts from first-time visitors with no order history.
- Many declines in a short window sharing one device fingerprint, email domain, or card BIN.
- Orders for one low-priced item with billing and shipping details that do not match.
- Card numbers submitted in sequence, seconds apart, from rotating IPs.
- A jump in checkout traffic that never reaches a confirmation page.
Prerequisites
- Access to your payment gateway's fraud rules, velocity limits, and webhook logs.
- A staging environment where you can test rule changes against live traffic patterns.
- An alert channel that reaches a person who can act within minutes.
Defense Steps
- Enable rate limiting on the payment endpoint for each IP address, device fingerprint, and email address, then set the window to one minute or less.
- Require the card verification value and a full address verification match on every transaction, and auto-void orders that fail either check.
- Turn on 3-D Secure for card-not-present orders so the issuer runs its own authentication step.
- Add a bot challenge, such as a CAPTCHA or proof-of-work check, before the payment form accepts input.
- Block disposable email domains and known hosting, proxy, and VPN ranges at the form level.
- Cap repeated attempts per card BIN and per customer record, and return a generic decline message that reveals nothing about why the attempt failed.
- Write gateway rules that flag any account producing three or more declines in ten minutes.
- Log every declined attempt with IP, timestamp, user agent, and BIN, then review the log daily for clusters.
Monitor and Respond
Set an alert on your decline rate and on authorization volume per hour. When the rate crosses your threshold, tighten the velocity rules first, since that change takes effect without a deploy. Contact your gateway's fraud team if the attack continues, and keep a written record of the timeline for your processor. Refund the small authorizations you catch in time so the cardholders do not carry the dispute.