Card testing prevention: the short answer

Card testing prevention is the set of checkout controls that stop attackers from pushing stolen card numbers through your payment form to learn which ones still work. The core moves are: require CVV and address verification on every authorization, cap how many payment attempts one IP, device, or email can make in a short window, place a human challenge in front of the payment endpoint, and send risky orders to 3D Secure. Detection matters as much as blocking, because a card testing attack shows up as bursts of small failed authorizations, not as a single large fraudulent order.

Merchants lose twice in these attacks. You pay interchange and gateway fees on every attempt, and a high decline rate can push your account into a chargeback or fraud monitoring program. The fix is configuration plus monitoring, and most of it can be done in an afternoon.

Prerequisites

  • Admin access to your payment gateway and fraud rule engine
  • Ability to change checkout code or API rate limits
  • At least 30 days of order, decline, and gateway log history
  • A named contact at your acquirer for emergency BIN blocking

Step-by-step prevention setup

  1. Turn on CVV verification and address verification (AVS) for every card-not-present transaction. These two checks alone remove a large share of test traffic, since bulk card lists rarely include matching ZIP and CVV data.
  2. Set your rules to decline on a CVV mismatch and on a full AVS mismatch. Do not make these checks optional for low-value orders, because testers deliberately use small amounts.
  3. Apply velocity limits at several layers: per IP address, per card BIN, per email domain, and per device fingerprint. A practical starting point is three declines per hour and ten per day for any single identifier.
  4. Rate limit the authorization endpoint itself. A real customer submits one payment every few seconds at most, so a cap of five requests per minute per session blocks scripted traffic without touching normal buyers.
  5. Add a bot challenge in front of checkout. A CAPTCHA or invisible challenge on the payment step raises the cost of automation and pushes most scripted attacks to easier targets.
  6. Require 3D Secure for orders that trip any risk rule. The extra authentication step shifts liability for fraud chargebacks to the issuer when the transaction is fully authenticated.
  7. Block high-risk BIN ranges and countries that never produce legitimate sales for your store. Review the block list each month so you do not cut off real customers.
  8. Watch for micro-authorizations. A cluster of $0.00 to $2.00 attempts across many cards in a short period is the clearest sign of an active test run.
  9. Set alert thresholds on decline rate, not just decline count. A jump from 8 percent to 40 percent in one hour should page someone.
  10. Log the IP, device fingerprint, user agent, email, and full gateway response code for every attempt. You cannot block a pattern you never recorded.
  11. Test your own rules with a live card and a deliberately wrong CVV. Confirm the decline lands in your alerting pipeline.
  12. Review the rule set each week for the first month, then monthly. Attackers rotate infrastructure, so a fixed configuration drifts out of date.

Signals that an attack is in progress

  • Many authorizations from one IP or a small set of IPs in a short window
  • A high ratio of declines to approvals on new customer accounts
  • Sequential or near-sequential card numbers in your transaction log
  • Disposable email domains or mismatched billing and shipping countries
  • Order values clustered at the minimum your gateway accepts

What to do during an active attack

  1. Block the offending IP range at the edge, not in your application code, so the traffic never reaches checkout.
  2. Raise the bot challenge to a full interactive test on the payment page.
  3. Turn on 3D Secure for all transactions until the traffic stops.
  4. Notify your acquirer and gateway support with timestamps and sample transaction IDs.
  5. After the traffic drops, roll controls back one at a time and watch the conversion rate.

Common mistakes

  • Relying on a single control. Rate limits without AVS catch the same traffic twice.
  • Blocking by country alone. It removes real revenue and misses domestic test traffic.
  • Ignoring the test phase. Attackers probe first, then run the full fraud wave days later.
  • Leaving the same controls on forever. Review the rule set against your own decline data.