A card testing alert is a warning that someone is running small charges through your checkout to find out which stolen card numbers still work. It can come from your payment processor, your fraud tool, or your own monitoring. The alert means live attacks are hitting your payment page right now and you have hours, not days, to stop them.
Card testers work in batches. They buy lists of card numbers, push a $0.50 to $3 charge through each one, and keep the ones that approve. Valid numbers get sold or used for larger purchases. Invalid numbers get discarded.
What triggers a card testing alert?
Payment processors and fraud platforms watch for patterns that look nothing like normal shopping. Any of these can fire an alert:
- A sudden jump in authorization attempts, often hundreds within an hour.
- A decline rate above 30 to 40 percent on traffic that normally approves.
- Dozens of different card numbers hitting checkout from one IP address or device.
- Card numbers that run in sequence, a pattern called a BIN attack.
- Small-ticket charges with no matching product page visits.
- Billing addresses and cardholder names that change with every attempt.
What does a card testing attack look like in your data?
The giveaway is volume plus repetition. Real customers buy things. Testers hammer the payment step and leave.
Signals to check in your transaction log
- Many attempts in a short window from one IP, subnet, or ASN.
- One email address or email domain used across many cards.
- Sessions that go straight to checkout without viewing a product.
- Failed CVV and AVS checks on most attempts.
- Orders for the cheapest item in your catalog, repeated.
- Traffic at hours when your normal customers sleep.
If you see three or more of these together, treat it as an active attack.
Why do testers target small merchants?
Small shops run few fraud rules, so approvals come easy. Test charges cost less than a dollar, which keeps them under the thresholds that large processors set. A three-person team also has nobody watching the dashboard at 2 a.m.
How do you respond to a card testing alert?
- Confirm the pattern. Pull the last 24 hours of authorizations and sort by amount, IP, and card BIN. If the same source repeats, you have your answer.
- Block the source. Add the IP range, ASN, and device fingerprint to your block list. Some processors let you block at the gateway level.
- Tighten your rules. Require a CVV and AVS match on every order, and set velocity limits per IP, card, and email.
- Add 3-D Secure. It shifts liability to the issuer on approved transactions and stops most automated testing scripts.
- Void and refund the test charges. Do not ship anything. Cancel the orders and refund the amounts so the real cardholders see the money back.
- Call your processor. Report the attack and ask about fee waivers. Processors handle these events all day and often adjust fees when a merchant reports first.
- Save the evidence. Export the log. You may need it for chargeback rebuttals in the next 60 to 120 days.
How do you stop the next attack?
Checkout controls that work
- CAPTCHA or a bot-detection script on the payment form.
- Rate limits on the checkout endpoint, such as 10 attempts per IP per hour.
- CVV and AVS required, with no manual overrides for staff.
- 3-D Secure on orders above a set value or from new devices.
- Blocks on disposable email domains and known proxy services.
- A minimum order amount that makes bulk testing expensive.
Monitoring that catches attacks early
Set alerts on authorization volume and decline rate, not only on completed orders. Testing shows up in declines first, so a decline-rate alert gives you a head start. Review small-ticket transactions each morning and keep a direct contact at your processor and acquirer so you can reach a human when an attack starts.
What happens if you ignore a card testing alert?
Test charges that settle turn into chargebacks when the real cardholders dispute them. A high chargeback ratio puts your account into a card network monitoring program, which adds monthly fees and a required remediation plan.
Repeated failures lead to fines, reserve requirements, and account termination. Terminated merchants land on industry blacklists that make it hard to open a new processing account. The cost of a two-hour block-list update is small next to those outcomes.
Frequently asked questions
Does a card testing alert mean my site was hacked?
No. Testers use card numbers stolen from other breaches, so your site did not have to leak anything. An alert does mean someone found a checkout they can automate, so patch your platform and review your payment settings.
How long does a card testing attack last?
Most attacks run in bursts of minutes to a few hours. Some run for days at low volume to stay under alert thresholds. If an attack stops, watch your logs for a week before you relax your rules.
Is a card testing alert the same as a fraud alert?
They overlap but differ. A fraud alert flags one suspicious order. A card testing alert flags a pattern across many cards that share a source. The second one points to an automated attack on your gateway.
Should I report a card testing alert to anyone besides my processor?
Report the attack to your processor and acquirer first. In the US, payment fraud also goes to the FTC, and cases with money lost go to the FBI's IC3. Card networks collect data from issuers and acquirers, so your processor is the main channel.
Key takeaways
- A card testing alert means someone is checking stolen card numbers on your checkout.
- Decline spikes and repeated IPs show up before chargebacks do.
- Block the source, require CVV and AVS, add 3-D Secure, and void the test charges.
- Report to your processor fast to improve your odds on fee waivers.
- Set decline-rate alerts so the next attack is caught in minutes, not days.