Card Testing Monitoring: Detect Card Testing Attacks

The top pick for card testing monitoring is real-time authorization monitoring that layers per-card, per-device, and per-BIN velocity limits on top of response-code pattern analysis, backed by a written alert path. It wins on three criteria: it catches an attack while volume is still small, it produces evidence a risk team can act on the same day, and it does not require a checkout rewrite. The sections below cover what to watch, how the main approaches compare, and what to do in the first hour of an attack.

What card testing looks like in your authorization data

Card testing is an attacker pushing large numbers of card numbers through a payment form to learn which ones still authorize. The attacker profits from the small share that works; the merchant absorbs the authorization fees, the chargebacks, and any scheme penalties that follow. The pattern is visible in data most merchants already store.

• Many small authorizations, often under a few dollars, inside a short window.
• A decline rate far above your own baseline, especially declines for invalid or expired accounts.
• Card numbers arriving in clustered or ascending BIN ranges.
• One device fingerprint or IP address tied to dozens of different card numbers.
• Concentrations of CVV and AVS mismatches, which point to numbers circulating without matching cardholder data.
• Retries on the same card after a decline, or a burst of failed 3-D Secure challenges.
• Traffic shifted to your off-hours, or to a price point your normal customers ignore.

Criterion 1: Velocity measured on more than one dimension

Velocity limits are the cheapest control to deploy and the first thing an attacker probes. A limit on card number alone is not enough, because the attacker rotates cards. Set limits per dimension and on combinations of them.

• Attempts per card number per hour and per day.
• Attempts per device fingerprint and per IP address, counting failures as well as approvals.
• Attempts per BIN or BIN range, which catches enumeration walking through an issuer's number space.
• Distinct card numbers per email address, per customer account, and per shipping address.
• Authorization attempts per session, which catches scripted form submission.

Count declined attempts, not only approved ones. The failed attempts are the attack; approvals are just the payout.

Criterion 2: Response-code pattern analysis

Single declines mean little. Ratios and their movement over time mean a lot. Track these against a rolling baseline of your own traffic rather than an industry figure.

• CVV mismatch and AVS mismatch responses as a share of total attempts, sampled hourly.
• Declines in categories that mean invalid account or invalid format, separated from insufficient funds.
• Clusters of issuer do-not-honor and pick-up-card responses.
• Failed or abandoned 3-D Secure authentications rising while approvals stay flat.
• Average ticket size falling while attempt volume climbs.

Criterion 3: Device, session, and network signals

Authorization data tells you what happened; device data tells you who did it. Collect a stable device identifier, the session identifier, and the network origin on every attempt, then join them to the authorization record.

• Card count per device and per session, with a hard ceiling.
• Account age and email domain age on the customer record.
• Datacenter and proxy ranges appearing where residential traffic normally comes from.
• Form fill timing that is too uniform or too fast to be human.

Criterion 4: An alert path someone owns

Monitoring only pays off when the alert reaches a person with authority to act before the attacker finishes. Write the path down before you need it.

1. Set thresholds from your own baselines and route them to a named on-call owner, not a shared inbox.
2. Prepare containment actions in advance: blocklist the device or network range, tighten velocity limits to a hard block, require 3-D Secure for the affected segment.
3. Preserve the evidence: authorization requests, response codes, device identifiers, timestamps, and the rule version that fired.
4. Review after each event to see which rule fired first and which one fired too late.

Monitoring approaches compared

Rule-based velocity and pattern rules

Deterministic rules you configure on your own traffic. Transparent and fast to deploy.

• Pro: You can explain every block to a customer, an acquirer, or a chargeback analyst.
• Pro: Cheap to run and easy to tune when false positives appear.
• Con: An attacker who learns your thresholds can sit just under them.
• Con: Rules need maintenance as your product and traffic mix change.

Use it when: you process a few thousand transactions a month, have no dedicated fraud team, and need coverage this week.

Machine-learned risk scoring

A model scores each attempt from device, behavioral, and authorization features, and you set a review or block band.

• Pro: Catches pattern shifts that fixed rules miss.
• Pro: Scales across many payment methods without a rule for each one.
• Con: Opaque unless you invest in reason codes and review tooling.
• Con: Needs labeled historical data, which a new merchant does not have.

Use it when: you already block obvious attacks with rules and want to catch the slower, blended attacks that hide inside normal traffic.

Processor-side and network-level monitoring

Your payment processor or acquirer watches authorization traffic across its whole portfolio and can flag or block at the network edge.

• Pro: Sees cross-merchant patterns you cannot see from one checkout.
• Pro: Blocks before the request reaches your systems, which protects your fees.
• Con: Limited visibility into your own rules and thresholds.
• Con: Alerts arrive after the fact unless you enable blocking.

Use it when: you run a high-volume or high-risk merchant account and want a second layer behind your own monitoring.

Which setup fits your business

• Small merchant on a hosted checkout: turn on the processor's built-in fraud rules, add a per-card and per-IP attempt cap, and monitor decline ratios weekly.
• Mid-market with a risk analyst: run rules in real time, add device signals, and put a scoring layer on top for review queues.
• High-risk or digital goods: require 3-D Secure on new customers, keep velocity limits tight at the BIN level, and alert in minutes rather than hours.
• Marketplace or platform: monitor at the seller level as well as the buyer level, since one compromised seller account can drive a testing wave.

Baseline metrics to keep on a dashboard

• Authorization approval rate, split by new and returning customers.
• Attempts per card, per device, and per BIN, measured hourly.
• CVV and AVS mismatch rate.
• Share of attempts blocked by rule, and the false-positive rate behind it.
• Time from first anomaly to first containment action.