Defend Against Card Testing: 10 Merchant Steps

Card testing is an attack where someone runs a list of stolen card numbers through your checkout to find out which ones still work. Each attempt looks like a normal small order, so the volume, not the size, is the tell. Defend by making every attempt cost the attacker something: rate limit by IP and card fingerprint, put a challenge in front of checkout, enforce CVV and AVS on every card-not-present transaction, and alert on sudden jumps in declines or authorization attempts.

Why testers pick small merchants

Large retailers have fraud scoring and dedicated risk teams. Small stores often approve anything that clears the processor, which makes them a cheap place to validate a stolen list. The damage shows up later as chargebacks, processor fines, and a lower approval rate on real customers.

Prerequisites

• Access to gateway logs with IP, device, and card fingerprint fields
• Ability to edit checkout settings or deploy a rules engine
• A named contact at your acquirer or payment processor for incident reports

Defense steps

1. Turn on per-IP rate limits for checkout and card update pages, with a hard cap per minute and per hour.
2. Add a CAPTCHA or invisible challenge to checkout, account creation, and saved card update forms.
3. Require CVV and full AVS matching on every card-not-present order, and auto-void mismatches instead of reviewing them.
4. Set a minimum order value that covers your fees, and remove any free or one-dollar trial path that testers can abuse.
5. Build velocity rules on card fingerprint, email, device ID, and shipping address, not just IP.
6. Turn on 3-D Secure or step-up authentication for orders that trip a velocity rule.
7. Block disposable email domains and traffic from known proxy and hosting networks at the edge.
8. Restrict or challenge high-risk countries and data-center ASNs where your real customer base does not need them.
9. Alert on authorization rate and decline rate changes over a rolling hour, and route alerts to a phone, not an inbox.
10. Log every attempt with headers and card fingerprint, then share confirmed testing patterns with your processor.

Signals that you are under test

• Many orders in a short window with near-identical totals
• Sequential card numbers or the same BIN repeating across attempts
• High decline counts from a single IP block or ASN
• Email addresses with random strings and no order history
• Customers who never open a confirmation email

After an attack

1. Void or refund the fraudulent charges before capture where your gateway allows it.
2. Block the offending BINs, IP ranges, and email domains in your rules engine.
3. File an incident report with your acquirer and ask about chargeback thresholds.
4. Review the rules that failed and tighten the threshold that let traffic through.

Card testing rarely stops after one pass. Keep the rate limits and challenges on permanently, review blocked traffic monthly, and treat a sudden approval rate drop as an incident until you prove otherwise.