What card testing looks like in authorization logs

Card testing is a run of authorization attempts against stolen card numbers. The attacker needs one answer: which numbers are live. The attempts leave a pattern in the data. Small tickets. Many cards. One device. Short windows.

card testing monitoring best practices

Monitoring means watching for that pattern before chargebacks arrive. Chargebacks lag 30 to 90 days after the test run. Authorization data arrives in seconds.

related article

Metrics to track

  • Authorization rate split by BIN and by card brand. A drop of 15 points on one BIN range in a day is a signal.
  • Decline code mix. Spikes in do_not_honor and insufficient_funds from one source point to enumeration.
  • Share of approved transactions under $2. Normal for some merchants. Abnormal when it jumps.
  • Distinct card numbers per device ID per hour.
  • Distinct BINs per IP address per day.
  • AVS mismatch rate and CVV mismatch rate, tracked as separate series.
  • Cardholder name mismatch rate on approved orders.
  • Orders per email domain and per shipping address cluster.

Set thresholds against a baseline

Fixed thresholds fail. Set a baseline per channel, per payment method, and per hour of day. Use 28 days of history. Alert at three times the baseline, not at a round number.

Card Testing and Monitoring Systems: A Comprehensive Guide

Example rules that work in practice:

related article

  1. Decline rate above 3x baseline for 15 minutes.
  2. More than 10 distinct cards on one device in 60 minutes.
  3. More than 25 authorization attempts from one IP in 10 minutes.
  4. More than 5 BINs from one IP in 24 hours.
  5. Approval rate under 20 percent on a new traffic segment.

Monitor, then decide

Monitoring output feeds rules, manual review queues, and blocklists. Keep the three separate. A monitor that blocks by default will cost revenue on false positives.

Log every alert with the rule ID, the entity blocked or flagged, and the outcome. Review outcomes after 30 days. Rules with a false positive rate above 10 percent need tuning or removal.

Review cadence

  1. Daily: decline code mix, sub-$2 approval share, alerts from overnight.
  2. Weekly: velocity by device and IP, new traffic segments, rule hit counts.
  3. Monthly: chargeback data mapped back to alert history. Did the monitor catch the run?
  4. Quarterly: baseline refresh and rule retirement.

Data retention

Keep raw authorization records for 13 months. Each record needs: timestamp, card BIN and last four, amount, response code, AVS result, CVV result, device ID, IP address, user agent, and merchant account ID. Without device and IP fields you cannot link attempts into a run.

Common failures

  • Watching chargebacks only. The feedback loop is too slow.
  • Aggregating by merchant account and losing the per-device detail.
  • Blocking IP addresses. Attackers rotate through proxies; the device and BIN data survive.
  • No baseline, so every alert is a guess.
  • Storing CVV results without the raw response code, which removes the link to the issuer.

Where to start

Pull 90 days of authorization logs. Build the five series listed above. Set one alert on card-per-device velocity. That single rule catches most small-scale test runs.