Card testing detection is the practice of finding automated attempts to validate stolen card numbers against a payment form. Detection combines velocity rules, issuer decline patterns, and device signals, then sends suspicious sessions to a review queue or a block list. The goal is to stop the attack before it damages your approval rate and processor relationship.

Signals that reveal card testing

  • Many small authorization attempts from one IP address or device fingerprint within a short window.
  • A high share of declines with response codes tied to invalid card numbers or do-not-honor responses.
  • Card numbers entered in sequence or with random BINs from the same session.
  • New accounts that attempt a payment within minutes of signup.
  • Billing address, IP geolocation, and device locale that do not match.
  • Form fill times under three seconds, which indicates a script rather than a person.

Steps to build detection

  1. Log every authorization attempt with these fields: timestamp, IP address, device fingerprint, card BIN, amount, response code, and email age.
  2. Set a baseline count of authorization attempts per IP, per device, and per BIN over a rolling 10-minute window.
  3. Write a velocity rule that fires when one source exceeds five attempts in 10 minutes.
  4. Add a decline rule that fires when the decline rate for a single BIN passes 30 percent in one hour.
  5. Add a low-value rule that flags every authorization under $1.00 that returns a decline.
  6. Score each session from 0 to 100 using the rule hits, with more weight on velocity and low-value declines.
  7. Route scores above 70 to manual review and block scores above 90 for 24 hours.
  8. Store the score and the rule that fired for each blocked request so you can audit the decision later.

Response workflow

  1. Review blocked sessions within one hour and confirm the attack pattern.
  2. Block the IP range and device fingerprints tied to the attack.
  3. Require a challenge on the payment form for sessions that carry a score above 50.
  4. Send the decline data and the affected time window to your payment processor.
  5. Notify the fraud team and document the incident in your ticketing system.

Tuning the rules

Review false positives each week against a labeled set of known good orders. Raise a threshold when a rule blocks more than two good orders per 1,000. Lower a threshold when a rule misses attacks that your review queue catches. Keep a test set of past attack traffic and replay it after every rule change. Track the count of blocked attempts, the count of confirmed fraud attempts, and the share of good orders caught in review. Retire rules that produce no confirmed fraud over 30 days.