Card testing detection is the practice of catching the small authorization attempts criminals run to check whether stolen card numbers still work. A working program combines velocity rules, decline analysis, device and network signals, and a risk score, then blocks the pattern at the checkout. Merchants who skip this work find out weeks later, through chargebacks and a damaged approval rate.
How Card Testing Attacks Work
Card testing runs in two stages. A criminal buys a batch of stolen card data, then pushes each number through an open checkout to see which ones authorize. Numbers that pass get sold or used for bigger purchases, and numbers that fail get discarded.
Test orders stay small on purpose. A $1 donation or a digital gift card limits the loss if the card is dead and stays under most manual review triggers. Once a batch is confirmed, the attacker often returns to the same merchant for high-value goods.
The cost lands on the merchant either way. Every attempt burns an authorization request, and a burst of failures drags down your approval rate with the processor. Some acquirers add monitoring fees or hold funds when the pattern repeats.
Signals That Point to Card Testing
No single order proves an attack. The pattern shows up when you look across orders, devices, and card ranges at the same time.
Velocity and BIN patterns
- Dozens of attempts from one IP, device, or account inside a short window.
- Many card numbers from the same BIN range hitting one checkout.
- One card number spread across several accounts or email addresses.
- Attempt counts that spike at night, when your fraud desk is thin.
Decline and response codes
- A jump in card-not-present declines on a checkout that approves most orders.
- Repeated "do not honor," "insufficient funds," or "pick up card" responses.
- Success that arrives after several failures from the same device fingerprint.
Device and network signals
- Traffic from data centers, proxies, or commercial VPN ranges.
- Billing country that does not match the IP country or the card's issuing bank.
- Missing browser fingerprints, scripted form fills, and no page views before checkout.
- One device running many cards, or one card running on many devices.
Order and basket signals
- New accounts buying digital goods, gift cards, or trial subscriptions.
- Sequential order numbers created seconds apart from one session.
- Disposable email domains and phone numbers tied to a string of accounts.
How to Build a Detection Stack
Start with cheap rules that stop volume, then add scoring for the attempts that slip through. Rules catch the obvious bursts. Models catch the slow, blended attacks that look like normal traffic.
- Cap velocity. Set limits per IP, device, card BIN, email domain, and account per hour. Reset the counters on a rolling window.
- Block known bad ranges. Deny data center IPs, open proxy lists, and disposable email domains at the edge.
- Require CVV and AVS. Both checks raise the cost of bulk testing because the attacker loses cards that fail the match.
- Add a challenge at the point of risk. A CAPTCHA or 3D Secure step on suspicious attempts breaks scripted tools while most real buyers pass without friction.
- Score every order. Feed device, network, card, and behavior data into a risk score, then act on thresholds instead of gut feel.
- Watch authorization logs live. Alert on decline-rate spikes by BIN and by checkout, with a threshold tuned to your normal traffic.
What to Do When an Attack Is Live
- Throttle the offending IP range and device fingerprints for a set period.
- Force 3D Secure or manual review on the affected checkout, not the whole store.
- Raise the minimum order value for new accounts until the burst dies down.
- Pull every successful order from the same fingerprints, then void or refund the ones that fail review.
- Notify your payment processor and give them the BIN ranges and timestamps.
- Write down what tripped first so the next detection rule fires sooner.
Tuning Out False Positives
Shared IP addresses cause most false alarms. Offices, schools, mobile carriers, and public Wi-Fi all put many real buyers behind one address, so treat network signals as one input rather than a verdict.
Gift card buyers and travelers also look odd on paper. Track your false positive rate by segment and loosen thresholds where the loss from blocked sales runs higher than the loss from fraud. Review the number monthly, since attack patterns shift.
Metrics Worth Tracking
- Authorization rate and decline rate by reason code.
- Chargeback rate and fraud-to-sales ratio.
- False positive rate and the revenue lost to blocked orders.
- Time from first attack signal to first blocked attempt.
Time to detect matters most. A program that blocks a burst in ten minutes saves far more than one that catches it the next morning.
Frequently Asked Questions
What is card testing in simple terms?
It is a criminal running stolen card numbers through a checkout to sort the live ones from the dead ones. The test orders are small, and the goal is a verified list, not the merchandise.
How do I know if my store is being card tested?
Look for a sudden rise in declined transactions, many small orders from one IP or device, and several card numbers sharing a BIN range. A drop in your approval rate with no change in traffic is another common sign.
Can card testing be stopped completely?
No. Attackers rotate IPs, devices, and card ranges, so detection is an ongoing tuning job. The realistic goal is to cut the volume, raise the attacker's cost, and keep chargebacks under the processor's threshold.
Does card testing hurt my payment processing?
It can. High decline rates and fraud ratios push you into monitoring programs, and some acquirers charge fees or delay settlement. Repeated attacks can also end in account termination.