Card testing monitoring is the practice of watching authorization attempts across your payment stack so you can spot bursts of small-value, high-decline traffic while the attack is still running. The goal is simple: see the pattern in minutes, not in next month's chargeback report.

What card testing looks like in your logs

An attacker buys a list of stolen card numbers, then runs them through a merchant's checkout to learn which ones still authorize. A small charge confirms a live card, so the attacker can sell or reuse it. Your gateway sees the result as a run of tiny orders, most of them declined, often from a narrow set of IP addresses or device fingerprints.

Prerequisites

  • Access to authorization logs in your payment gateway or processor portal
  • Permission to edit fraud rules or velocity limits in that portal
  • A monitored alert destination such as a chat channel or an on-call pager
  • Access to your WAF or CDN for IP blocking

How to set up card testing monitoring

  1. Turn on full authorization logging in your gateway, capturing the response code, amount, card BIN, IP address, device fingerprint, and timestamp for each attempt.
  2. Export 30 days of historical authorizations and record your normal volume of failed attempts for each hour of the day.
  3. Set an alert that fires when failed authorizations for any single BIN pass three times that hour's baseline.
  4. Create a second alert for one IP address that crosses 10 failed attempts inside a 10 minute window.
  5. Group traffic by device fingerprint and flag any fingerprint that touches more than five distinct card numbers in one hour.
  6. Add velocity limits for the same card number, the same customer email, and the same shipping address.
  7. Route both alerts to a channel with a person watching it, so a spike gets a human response.
  8. Trigger a CAPTCHA or a 3D Secure challenge for any session that trips a rule.
  9. Block the source IP range at your WAF when traffic continues after the challenge.
  10. Log the outcome of every block and challenge, then review the week's alerts each Monday and tune thresholds to cut false positives.
  11. Write an incident runbook naming who calls the processor, who refunds affected customers, and who reports the attack to the card networks.

Signals worth alerting on

  • Authorizations between $0.00 and $2.00 that arrive in clusters
  • A decline ratio above 70 percent on a single BIN
  • Sequential or near-sequential card numbers from one IP
  • New accounts with billing and shipping data that do not match
  • Order spikes during hours your real customers sleep

What to do when an alert fires

Confirm the pattern in the logs, then rate-limit the source and force a challenge on the sessions in question. Refund any captured test charges and void the authorizations you can still void. Report the event to your processor with the BIN ranges and IP addresses involved, since network-level fraud teams track these attacks across merchants. After the traffic stops, keep the alert rules in place and revisit your baselines, because card testing campaigns rotate infrastructure and return.