A card testing alert is a notification from your payment processor, gateway, or fraud vendor that an unusual number of authorization attempts hit your account in a short window, usually for small amounts. The pattern means someone is validating stolen card numbers against your checkout. The fastest useful response is to slow the traffic inside the first hour, then choose one control to keep in place: gateway velocity rules, a 3-D Secure step-up, or a bot challenge at the payment form.

What the alert usually looks like

Alerts arrive in different formats, but the underlying signal set is consistent. Look for several of these together before you treat it as confirmed card testing rather than a bad marketing spike.

• A run of authorizations in the $0.00 to $1.00 range, often dozens or hundreds in minutes.
• Many different card numbers sharing one IP address, one device fingerprint, or one email.
• Card numbers that look sequential or share a narrow range of bank identification numbers.
• A decline rate far above your normal baseline, since most tested numbers are already dead.
• Traffic concentrated in your lowest-volume hours, when a bot stands out less.

Option 1: Gateway velocity and rule-based alerts

Most processors let you set thresholds on attempts per card, per IP, per email, and per time window. When a threshold trips, the gateway blocks or flags the traffic and notifies you.

• Pros: fast to configure, no checkout changes, catches the bulk of scripted attacks.
• Pros: rules keep working while you sleep, which matters because card testing often runs overnight.
• Cons: aggressive thresholds can decline real customers on shared networks, such as offices and mobile carriers.
• Cons: rules react to volume, so a slow, low-rate test can stay under the line.

Best fit for stores that already have steady order volume and want a first layer in place today without touching front-end code.

Option 2: 3-D Secure step-up on suspicious traffic

Instead of challenging every buyer, you challenge only sessions that match test-like behavior. The issuer then decides whether to approve.

• Pros: shifts liability for fraudulent charges in many cases and stops most automated scripts cold.
• Pros: leaves your normal checkout flow untouched for trusted traffic.
• Cons: adds friction, and some legitimate buyers abandon at the challenge screen.
• Cons: needs a fraud tool or gateway that supports conditional triggering, which not every stack offers.

Best fit for merchants with high average order values where one fraudulent charge costs more than a handful of abandoned carts.

Option 3: Bot mitigation at the payment form

CAPTCHA, device fingerprinting, and rate limits on your own endpoints stop scripts before they reach the processor.

• Pros: reduces attack traffic at the source, so you pay less in authorization fees.
• Pros: protects related endpoints such as account login and gift card balance checks.
• Cons: sophisticated attackers rotate residential proxies and solve challenges at scale.
• Cons: poorly tuned challenges hurt accessibility and mobile conversion.

Best fit for sites seeing repeated waves, where the same script returns days after each block.

Option 4: Manual review and blocklists

You pull the flagged orders, confirm the pattern by hand, and add the offending IPs, emails, device IDs, and card fingerprints to a blocklist.

• Pros: catches context that automated rules miss, such as a single abuser behind many identities.
• Pros: produces evidence you can hand to your processor or acquirer if disputes follow.
• Cons: does not scale during a large attack and can lag behind the traffic by hours.
• Cons: blocklists age fast as attackers rotate infrastructure.

Best fit as a companion to one of the automated controls above, not as your only defense.

First-hour checklist

1. Confirm the pattern in your gateway logs: amount range, decline rate, shared identifiers.
2. Turn on the strictest velocity rule you can tolerate without breaking normal checkout.
3. Add a challenge or step-up for sessions that match the pattern.
4. Block the top offending addresses and identifiers from the last hour.
5. Notify your processor's fraud team so the activity is on record.
6. Refund or void any orders that were approved during the burst.

How to tell the attack stopped

Watch authorization attempts per hour, decline rate, and the count of distinct cards per IP. All three should fall toward your normal range within a day. If attempts drop but your dispute rate rises weeks later, the attacker succeeded before you responded, and you should expect chargebacks on the approved transactions. Keep the alert thresholds in place after the traffic stops, since card testing campaigns commonly return to the same merchant.