Card testing defense in one paragraph
Card testing is a fraud attack that runs small charges on many card numbers to find which ones authorize. Defense has three parts: limit how fast one source can submit payments, verify the cardholder with CVV, AVS, and 3-D Secure, and watch authorization data for spikes in declines and micro-amount charges. Merchants that do all three cut attack volume before it turns into chargebacks.
How the attack works
An attacker buys a list of card numbers. Lists come from breaches, skimming, and fraud markets. A list holds numbers that may be live, dead, or expired. The attacker needs to sort them.
The usual method is a script. The script sends thousands of authorization requests to a checkout page in minutes. Amounts stay small, from $0.01 to $1.00. Most requests fail. The ones that return an approval code mark a live card. Live cards get used for larger purchases or sold again.
Targets include donation forms, guest checkouts, and any storefront that does not require account creation. Attackers prefer endpoints with no CAPTCHA and no rate limit.
Signals to monitor
- Authorization attempt volume per hour, per IP, per device, and per card BIN.
- Share of transactions under $1.00.
- Decline rate. A jump from 5% to 40% in one hour points to enumeration.
- Decline codes. Repeated code 82 or N7 means CVV mismatch. Repeated code 05 means do not honor.
- New accounts or guest checkouts that make several payment attempts in a row.
- Requests with mismatched billing data or missing fields.
Controls that work
Rate limits and throttling
Cap authorization attempts per IP, per card, per device fingerprint, and per email. Give each limit a short window, such as 5 attempts per 10 minutes. Return a generic error so the attacker cannot tell which field failed.
Verification checks
Require CVV and AVS on every card-not-present sale. Decline on CVV mismatch. Add 3-D Secure for high-risk orders. These checks raise the cost of testing because the attacker must hold data that a stolen number alone does not provide.
Bot controls
Add a CAPTCHA or a device check to the payment step. Block known proxy and hosting IP ranges. Reject requests with missing headers or automated user agents.
Blocklists and rules
Maintain lists of IPs, BINs, emails, and device IDs tied to past attacks. Update them from your own dispute data. Share attack data with your acquirer and with fraud-prevention vendors.
Response plan
- Turn on stricter rules for the affected endpoint.
- Block the source IPs and BINs. Do not cancel legitimate orders from the same BIN range without a manual check.
- Alert your acquirer and payment processor. They see the same BINs across merchants.
- Refund or void test charges. Do not ship goods from orders that fail verification.
- Review the attack window for chargebacks. Dispute windows in the US run up to 120 days from the transaction date, so the cost can arrive months later.
What does not work
Blocking a single IP does little. Attackers rotate through proxy pools with thousands of addresses. Declining every small transaction blocks honest customers who buy low-priced items. Waiting for chargebacks to identify an attack costs money and can cost processing privileges. Issuers and card networks track fraud ratios, and a high ratio can lead to fines or account termination.
Numbers to track
Track authorization rate, decline rate by code, average ticket size, and the count of attempts per card. A healthy store sees a stable authorization rate. A store under attack sees a fast rise in attempts with a fall in approvals. Set alerts on those two metrics and review them each day.