Card testing is a fraud pattern. An attacker runs a script that submits many payment attempts, often for small amounts, to learn which card numbers are live. The merchant sees a burst of attempts, a high decline rate, a few approvals, and disputes weeks later. Mitigation has three parts: rate limits, verification, and monitoring. No single control stops a run. The stack does.

Card Testing Mitigation v10: A Comprehensive Guide

Signals of a card testing run

• Many authorization attempts from one IP range or device fingerprint in a short window.
• Order values at the minimum, often $0.00 to $1.00.
• Card numbers that run in sequence or share one BIN.
• Email addresses with random strings, or one email used with many cards.
• Decline codes that repeat, such as do-not-honor and stolen card.
• Instant-delivery goods, gift cards, or digital items in the basket.
• Attempt volume that peaks between 01:00 and 05:00 in the merchant's time zone.

Controls that cut attempt volume

1. Rate limits. Cap attempts per IP, device, email, and BIN. Block the source after a set number of failures in a set window.
2. CAPTCHA or a proof-of-work check on the payment page. This adds cost to a scripted run.
3. Require CVV and AVS on every card-not-present order. A mismatch declines the attempt.
4. 3-D Secure. Authentication blocks many tested numbers and shifts liability on approved orders.
5. Blocklists for IPs, ASNs, device IDs, and emails seen in earlier runs. Keep the lists current.
6. A minimum order value plus a small fee on low-value orders.
7. Generic decline messages. Do not name the field that failed.
8. Velocity rules tuned per BIN, not one global rule.

Steps during an active attack

1. Switch the affected BINs to the strictest velocity rule.
2. Require 3-D Secure on all card-not-present traffic.
3. Block the source ASNs and hosting providers found in the logs.
4. Call the acquirer and the gateway. Ask about issuer alerts and rule changes on their side.
5. Log IP, device, user agent, timestamp, amount, and response code for each attempt.
6. Keep the strict rules for two weeks after the burst ends. Attackers return.

Cost and network programs

Each declined authorization can carry a fee. Check the processor contract for the per-attempt rate. Disputes add fees and count against the account. Visa runs the Acquirer Monitoring Program. Mastercard runs the Excessive Fraud Merchant program. Both set thresholds on fraud ratios. Acquirers pass the penalties to merchants, and accounts above the threshold face fines or closure.

card testing mitigation v6

Metrics to track

• Authorization attempt count, by hour and by BIN.
• Authorization rate and decline code mix.
• Dispute count and dispute rate.
• Fraud-to-sales ratio against the network threshold.
• Share of orders that pass 3-D Secure.

Unknowns: no public figure states the share of card testing runs that use residential proxies compared with data center IPs. Treat proxy traffic as a risk input, not proof.

read more