Card testing defense is the set of checkout controls that stops attackers from pushing thousands of low-value transactions through a payment page to discover which stolen card numbers are still live. The minimum effective stack is per-card and per-IP velocity limits, a CAPTCHA or bot score on the payment step, required CVV and address verification, 3-D Secure step-up on risky orders, and a fraud model that flags patterns rather than single orders.
What is card testing?
Card testing, also called card enumeration or a BIN attack, is the practice of running small authorization attempts against a merchant to sort working stolen card numbers from dead ones. Attackers favor merchants with weak friction: guest checkout, no CVV requirement, instant digital delivery, and no velocity rules.
Each attempt costs the attacker a few cents. Each success produces a validated card that resells for far more, which is why the attack scales fast once a vulnerable endpoint is found.
How do you spot card testing in progress?
Watch for a spike in declined authorizations from many different card numbers arriving through the same IP range or device fingerprint. Real customers do not fail 40 different cards in one hour.
- A jump in failed CVV or AVS mismatches with no matching rise in completed orders.
- Order values clustered at or just under a fixed low threshold, such as $0.50 or $1.00.
- Disposable email domains, sequential email patterns, and trial signups that never convert.
- Traffic from data-center ASNs, VPN exits, or regions where you do not ship.
- Many cards sharing one shipping address, or many addresses sharing one card BIN.
Which defenses stop card testing fastest?
Rate limits on the payment endpoint are the highest-value control because they cap the attacker's throughput, and throughput is the whole economics of the attack. Layer them per IP, per card fingerprint, per device, and per account, then return a generic failure so the attacker learns nothing from the response.
- Require CVV and AVS on every transaction, and decline on mismatch rather than sending it to manual review.
- Apply 3-D Secure step-up to new customers, mismatched geography, and orders below your testing threshold.
- Add a CAPTCHA or invisible bot challenge before the authorization call, not after it.
- Block disposable email domains and known proxy ranges at the edge.
- Set a decline threshold per card fingerprint and auto-block the identifier after repeated failures.
What should the rule set actually cover?
Write rules against identifiers, not just orders, because a card tester changes order details far more often than they change infrastructure. A rule that blocks three declines on one device fingerprint catches more attacks than a rule that blocks three declines on one email address.
Review the rule set monthly. Attackers probe for the exact threshold you set, so static limits degrade into a known allowance.
How do you respond during a live attack?
Raise friction first and preserve evidence second. Tighten velocity limits, force 3-D Secure on the affected BIN ranges, and throttle the source ASNs while you capture logs for the acquirer.
Contact your payment processor the same day. Repeated authorization attempts count against your approval ratios, and card network fraud programs can place a merchant under monitoring when the volume stays high.
Does 3-D Secure stop card testing?
3-D Secure stops most of it because a tester rarely holds the cardholder's second factor, and the issuer absorbs liability on authenticated transactions. It is not free friction, so apply it by risk score rather than to every order.
Are small transactions safe to approve?
No. A $1.00 authorization is the standard probe, and approving those quietly builds a validated card list that gets used against you later at higher values. Treat repeated low-value approvals as a leading indicator, not a rounding error.