Card Testing Monitoring Process: Merchant Guide

The top pick for a card testing monitoring process is a gateway-native authorization monitor, paired with a small velocity ruleset and one named person who reviews the alerts each morning. It wins on the criteria that decide whether monitoring catches a live attack: detection latency in minutes rather than days, a false-positive load your support team can absorb, coverage of every checkout channel you run, and an evidence trail you can hand to an acquirer when disputes arrive.

What card testing looks like in authorization data

Card testing is an automated attempt to find out which stolen card numbers are still live. A script submits many card numbers against your checkout, often for small amounts or zero-value verification, and keeps the ones that approve. The attack rarely hides well once you know where to look, because it has to touch your authorization stream to work. Common traces include a jump in decline codes such as do-not-honor and insufficient-funds, many different issuers hit from one IP or hosting provider range, cardholder name fields filled with random strings, and dozens of attempts inside a few minutes from a single session.

Option 1: Gateway-native velocity and decline monitoring

Your payment gateway already stores every authorization request, so this approach turns on existing data instead of buying new data.

• Pros: no new vendor or contract, rules sit next to the blocking controls, setup takes days not quarters, and the logs are already in scope for your payment security review.
• Cons: the gateway sees only your traffic, so a slow attack spread across weeks is easy to miss, rule sets drift out of date, and raw count alerts generate noise on high-volume days.

Use this when you process under roughly a few thousand transactions a day, run one gateway, and need coverage now rather than a procurement cycle.

Option 2: Dedicated fraud platform with card testing models

Fraud vendors score each attempt against signals pooled from many merchants, which is the main advantage over rules you write yourself.

• Pros: network-level visibility into BIN ranges and device fingerprints under attack elsewhere, model scoring that adapts without manual tuning, and card testing alerts delivered as a finished queue.
• Cons: per-transaction cost, integration work on the checkout and order flow, less direct control over why a request was blocked, and the economics only work at meaningful volume.

Use this when you run multiple gateways or storefronts, sell digital goods with instant delivery, or have already absorbed one attack that cost more in fees and chargebacks than the vendor would have.

Option 3: In-house monitoring on your own event data

You stream authorization events into your own warehouse and write the detection logic there.

• Pros: full control over signals, the ability to join payment data with account age, session behavior, and fulfillment outcomes, no per-transaction fee, and one view across every processor.
• Cons: you own tuning and on-call, the pipeline needs real engineering time, and you get no threat intelligence from outside your own traffic.

Use this when you have a data team, several processors, and a fraud analyst who wants custom rules that no vendor dashboard exposes.

The monitoring process, step by step

1. Record a baseline for approvals, declines, and decline-code mix by hour and by channel, so an alert can be measured against normal rather than a guessed number.
2. Log every authorization attempt with timestamp, amount, response code, BIN, country, IP, device identifier, account age, and checkout session, and keep the retention your processor and acquirer require.
3. Alert on ratios, not raw counts: share of declines per session, attempts per card, attempts per IP, and distinct BINs per minute all survive traffic spikes better than fixed counts.
4. Triage on a fixed clock. Someone opens the alert, confirms whether the pattern is a script or a marketing spike, and records the decision.
5. Respond with the lightest control that works: rate limits, a challenge on the checkout, blocking the source range, or routing the traffic to a stricter review queue.
6. Verify the fix. Confirm declines return to baseline and that legitimate customers are still approving at their usual rate.
7. Write a short post-incident note covering first signal, time to detection, time to block, and what rule would have caught it earlier.

Signals worth alerting on

Treat these as candidates and calibrate each one against your own baseline before setting a threshold.

• Authorization attempts per session or per IP rising well above your normal peak.
• Decline rate for a single BIN range climbing while approvals stay flat.
• Many card numbers tried against one account, or one card tried across many accounts.
• Order values clustered at the smallest amount your checkout accepts.
• Card country, IP country, and billing country disagreeing at a rate above your usual mix.
• Traffic from hosting providers and datacenter ranges where your customers normally do not appear.

Choosing for your situation

Small single-gateway merchants should start with option 1 and add one in-house report on BIN concentration. Multi-channel merchants with instant delivery should put option 2 in front of the checkout and keep a light ruleset behind it. Teams with a data platform and several processors get the best result from option 3, provided someone owns the alert queue by name and not by team. In all three cases the process matters more than the tool: a monitored threshold with a named reviewer beats an unread dashboard.