What card testing mitigation means

Card testing is a fraud pattern in which an attacker submits a large number of card numbers against a payment form or API endpoint to learn which numbers still authorize. The numbers that succeed get kept, resold, or used for larger purchases. Mitigation is the work of spotting that pattern and cutting it off before the authorizations turn into chargebacks and processor penalties.

The dollar amount is not the main signal. The stronger signals are the ratio of attempts to completed orders, the speed of the attempts, and the small set of attributes that repeat across them, such as one IP range, one device fingerprint, or one card BIN block.

Before you change anything

  • Read access to gateway logs and web server logs covering at least 30 days.
  • Permission to edit payment form fields and server-side validation rules.
  • A named contact at your acquirer or gateway for fraud escalation.
  • Agreed thresholds your team will accept as grounds for a block.

How to mitigate card testing, step by step

  1. Export 30 days of authorization attempts and group them by IP address, device fingerprint, card BIN, and email domain.
  2. Rank each group by attempt count and by decline rate.
  3. Flag groups with more than 10 attempts in an hour, or a decline rate above 80 percent, as suspected testing.
  4. Cross-check the flagged groups against completed orders in the same period. Groups with almost no completed orders are the strongest candidates.
  5. Block the confirmed IP addresses and device fingerprints at the edge, before the request reaches your payment endpoint.
  6. Add a rate limit per IP address and per card BIN across the checkout path.
  7. Turn on a CAPTCHA or a proof-of-work challenge for sessions that cross the attempt threshold.
  8. Require CVV and postal code verification on every authorization, and reject mismatches.
  9. Enable 3D Secure or an equivalent step-up authentication for suspicious sessions.
  10. Restrict the number of card attempts allowed per customer account and per email address.
  11. Log every blocked attempt with a timestamp, IP, and rule that fired, so you can tune the rules later.
  12. Notify your acquirer and gateway fraud desk with the pattern you found.

Controls that hold up over time

  • Velocity limits on attempts, not just on successful charges.
  • Device fingerprinting that survives cookie clearing.
  • BIN and country rules matched to where your real customers live.
  • Address verification service checks with clear fail actions.
  • Alerting on attempt spikes, so a human reviews the pattern within the same business day.

After the burst stops

  1. Refund or void any charge that came from a flagged group.
  2. Review the blocked list monthly and remove entries that no longer match.
  3. Re-run the grouping report to confirm the attempt volume returned to baseline.
  4. Document the incident, the rules you added, and the false-positive rate those rules caused.

Metrics to watch

  • Authorization attempts per hour, split by new and returning customers.
  • Decline rate by BIN and by IP range.
  • Ratio of attempts to completed orders.
  • Blocked-attempt count and false-positive count per rule.
  • Chargeback rate on card-not-present transactions.

Track these numbers weekly. A drop in attempts paired with a steady order count is the sign that the mitigation is working without costing you real sales.