A card testing alert is an automated warning from your payment gateway, fraud provider, or card network that your checkout is receiving a burst of small authorizations typical of someone validating stolen card numbers. The alert arrives by email, webhook, or dashboard notice, and it means the probe is already in progress. Treat it as urgent work, not as a report to file.

Why the alert fires

Card testers run low-dollar charges, often between $0.10 and $2.00, against a long list of numbers. Declines tell them a card is dead. Approvals tell them the card is live and worth reselling or using for a larger purchase. Fraud systems spot the signature: many attempts in a short window, a narrow range of card numbers, repeated addresses, or a spike in decline codes such as insufficient funds. When your processor sees that shape, it sends the alert.

Prerequisites

• Access to your gateway or processor dashboard with transaction search
• Login rights for your firewall, CDN, or bot management console
• A support contact or account manager at your acquirer
• Permission to change checkout and fraud rules

How to respond

1. Open your gateway dashboard and pull the last 72 hours of authorizations.
2. Filter for approvals under $5.00 and note how many came from the same IP address or subnet.
3. Sort by card BIN and look for a cluster of numbers from one issuer range.
4. Compare timestamps and flag any window where attempts ran faster than a human could type.
5. Block the offending IP addresses, subnets, and autonomous system numbers at your firewall or CDN.
6. Turn on a bot challenge or CAPTCHA for the payment form if it is not already active.
7. Set a velocity rule that caps attempts per IP, per card, and per email address within an hour.
8. Require the card security code and a full address match on every order until the traffic drops.
9. Void or refund the approved test charges so the real cardholders are not billed.
10. Email your acquirer with the transaction IDs, the time window, and the rules you changed.
11. File a complaint with the FBI Internet Crime Complaint Center if the volume is large or tied to a known group.
12. Watch decline rates daily for the next 30 days, since testers often return with new infrastructure.

What not to do

• Do not raise your decline threshold to reduce noise. That lets more test charges through.
• Do not cancel the whole alert queue without reading it. Real customer declines get mixed in.
• Do not assume one block ends the attack. Attackers rotate proxies within hours.
• Do not skip the acquirer notice. Unreported testing can lead to fines or a terminated merchant account.

After the alert clears

Keep the logs. Card networks can ask for evidence months later, and your processor will want the timeline if chargebacks follow. Review the rules you added after two weeks and loosen only the ones that block legitimate buyers. Most merchants who respond inside the first day stop the attack before it turns into a fraud loss.