Card testing fraud is a burst of small authorization attempts run against your checkout to find out which stolen card numbers still work. You prevent it with four controls: keep automated traffic off the payment endpoint, verify the card data on every transaction, cap how many attempts one identity can make, and alert on the patterns testing leaves behind. The steps below cover each control in order.
how to prevent card testing fraud
What card testing looks like from your side
Common signals include a sharp rise in declined authorizations, many attempts tied to one IP address or device fingerprint, small orders shipped to mismatched addresses, and a spike in new account creation right before a payment spike. Attacks often run late at night and target the cheapest item in your catalog, because the attacker only needs the authorization to succeed or fail.
Prerequisites
- Access to the fraud rules engine in your payment gateway or processor.
- Server-side logging on checkout, login, account creation, and password reset.
- A monitored alert channel and a named contact at your acquirer for escalation.
Steps to prevent card testing fraud
- Turn on CVV and AVS checks in your gateway and set both to reject on mismatch instead of warn.
- Require 3-D Secure or another step-up challenge for any transaction your rules score as risky.
- Set velocity limits per card number, per IP, per email, and per device across rolling one-hour and 24-hour windows.
- Place a bot challenge on checkout, login, and account creation so scripted requests cannot post card data at volume.
- Rate-limit the payment API at the edge, for example 10 requests per minute per IP, and return a 429 response when the limit trips.
- Block or challenge traffic from datacenter, VPN, and TOR exit ranges, plus any IP with an unusually high decline ratio.
- Set a minimum order value and lock the session after a fixed number of failed attempts on the same card.
- Create alerts for a decline rate above your baseline, more than a set count of zero-dollar or one-dollar authorizations per hour, and sudden concentration in a single card BIN.
- Review rule performance each week and adjust thresholds, since tight rules block real customers as well as attackers.
If an attack is already running
- Switch bot challenges to the strictest setting, or challenge every checkout session for a few hours.
- Raise the minimum order value and lower the failed-attempt cap.
- Block the offending IP ranges and BINs, then log the decision so you can lift it later.
- Contact your acquirer or processor risk team and file the details, including timestamps and request volume.
- Run a live test order to confirm legitimate customers can still complete checkout.
Card testing is cheap to run and expensive to absorb. Authorization fees, chargebacks, and processor penalties add up fast, so the goal is to make automated attempts slow, costly, and visible. Once your limits, challenges, and alerts are in place, keep watching the numbers so you can tighten a rule before the next wave starts.