Card testing defense means making it expensive and slow for someone to guess which stolen card numbers still work, and impossible for a successful guess to turn into a shipped order. Three levers do most of the work: rate limiting per IP and per card fingerprint, strict velocity rules across accounts and devices, and requiring full card verification data (CVV plus address checks) on every authorization. Add fast alerting so you see a probe in minutes instead of finding it in a chargeback report three weeks later.
What a carding probe looks like in your logs
The signature is a burst of small authorizations, often between $0.50 and $3, from many card numbers hitting one checkout page. You see a decline ratio far above normal, a cluster of BINs from the same issuing region, and email addresses that follow a pattern. Order counts rise while your average order value drops off a cliff.
I look for three things first: a spike in declined authorizations on the same endpoint, a single device fingerprint tied to many distinct cards, and session behavior with no browsing before checkout. Bots that test cards rarely read product pages, add to cart, or linger. They land, they submit, they leave.
Controls that hold up under load
- Rate limits per IP, per card fingerprint, and per email. Cap authorization attempts per minute and per hour. Real customers almost never retry a decline more than a few times.
- Velocity rules across dimensions. Block when one card number appears on three or more accounts, or one device tries more than five distinct cards in a day.
- Mandatory CVV and AVS. Skipping either check hands attackers a free validation channel. Decline on CVV mismatch rather than flagging it for review.
- 3-D Secure or an equivalent step-up challenge. A challenge on the first transaction from a new device kills most automated probes outright.
- Minimum order values with manual review. If your margins allow it, send anything under a dollar to review instead of authorizing it automatically.
- Bot detection on the checkout path. Rate limits stop naive scripts. Fingerprinting and behavioral signals catch the ones that rotate IPs.
Tuning so you do not block good buyers
Aggressive rules will catch card testers and also catch legitimate customers on shared networks, corporate VPNs, and mobile carriers that recycle IPs constantly. Test every new rule in log-only mode for a week. Compare what it would have blocked against your known-good order history. If the false positive rate crosses roughly one percent, tighten the threshold or add a second condition before the rule fires.
Keep a separate, stricter rule set for card-not-present channels with high average ticket sizes. A rule that is safe on a $20 digital purchase is not safe on a $2,000 order, and the reverse is also true.
After you spot an attack
- Block the source ranges and device fingerprints you confirmed, not the whole hosting provider.
- Force re-authorization or cancel any orders that slipped through during the window.
- Pull the affected card numbers and report them to your acquirer. Issuers can flag the BINs and stop the next wave.
- Document the attack volume and your response. Acquirers and processors weigh that record when they review your fraud ratios.
Expect the probes to shift rather than stop. Attackers rotate infrastructure and change ticket sizes after a block. Weekly review of decline patterns and velocity hit rates keeps your thresholds current, and it is the cheapest early warning you have.