To prevent carding tests, block rapid low-value authorization attempts before they reach your processor. Layer strict velocity limits, mandatory AVS and CVV matching, bot detection, 3-D Secure, and daily authorization-rate monitoring. Carding tests are automated probes that validate stolen card numbers, and they are stopped by friction plus fast detection, not by a single setting.
What is a carding test?
A carding test is a small authorization attempt, often under a dollar, used to confirm whether a stolen card number is still active. Fraudsters fire thousands of these micro-charges in minutes and keep the cards that approve. Merchants absorb the damage as inflated decline rates, per-transaction fees, chargebacks, and possible placement in a card network monitoring program.
What are the warning signs of card testing on your checkout?
- A sudden spike in declined authorizations, especially on tiny order totals.
- Many different card numbers submitted from one IP address, device, or email domain.
- Sequential or near-sequential card numbers appearing in a short window.
- Orders with mismatched AVS and CVV responses, or prepaid and gift card BINs.
- Checkout sessions that complete in seconds with no browsing activity.
How do you prevent carding tests?
- Cap attempts per card, email, IP, and device per hour.
- Require AVS and CVV on every transaction and reject soft mismatches.
- Add a challenge that scripts cannot pass.
- Route risky traffic through 3-D Secure.
- Score each session with device fingerprinting and IP reputation.
- Set a minimum order value that makes testing unprofitable.
- Review authorization metrics every day.
1. Enforce strict velocity limits
Count authorizations per card number, per email address, per IP, and per device fingerprint within rolling windows. A limit of three to five attempts per hour per identifier catches most automated runs. When a limit trips, block the whole cluster rather than the single card.
2. Require AVS and CVV on every order
Card testing scripts rarely know the correct billing ZIP or security code. Make both fields mandatory and auto-void orders that fail either check. This one control removes a large share of successful test approvals.
3. Add friction that bots cannot solve
CAPTCHA or an invisible challenge on the payment step raises the cost of running a test batch. Combine it with blocking of known hosting providers, disposable email domains, and headless browser signatures. Friction should appear only when risk signals fire, so real customers keep a fast checkout.
4. Use 3-D Secure and network tokens
3-D Secure shifts liability for fraudulent charges to the issuing bank when authentication succeeds. Network tokenization replaces the stored card number with a token that cannot be tested elsewhere. Both reduce the value of a successful test to the attacker.
5. Score risk per device and per IP
Fraud engines correlate device fingerprints, IP reputation, and behavioral signals across sessions. Rising risk scores should trigger step-up verification or manual review. Fresh devices with no history and a mismatched geolocation are classic test markers.
6. Set a minimum order value
Attackers favor small amounts because they generate approvals with minimal exposure. A minimum cart total of a few dollars removes the cheap path. Pair it with a limit on the number of orders allowed per customer account per day.
7. Monitor authorization rates daily
Track approval, decline, and chargeback ratios by hour and by traffic source. A decline rate that jumps from a stable baseline is the earliest reliable signal of an active test. Alert thresholds should page someone who can change rules immediately.
What should you do after a carding attack?
Export the affected transaction window and block the shared IPs, devices, email patterns, and card BINs involved. Ask your processor or gateway to reverse the test authorizations and confirm whether fees can be waived. Then tighten velocity rules and document the incident for your acquirer, since repeated attacks can affect your processing terms.
Frequently asked questions
Does a CAPTCHA stop card testing?
It stops simple scripts, but determined operators use CAPTCHA-solving services. Treat it as one layer alongside velocity limits and AVS enforcement.
Do declined test attempts cost money?
Yes. Most processors charge authorization fees on declines, and a high decline ratio can raise your risk profile with the acquirer.
Can card testing target free trials and digital goods?
Yes. Any flow that validates a payment method qualifies, so apply the same limits to trial signups, account card-on-file updates, and stored-credential checkouts.