Most store owners think of payment fraud as someone buying goods with a stolen card. Card testing is different and in some ways more annoying: the attacker does not want your products at all. They have a list of stolen card numbers and need to know which ones work. Your checkout, or your donation form, or your free-trial sign-up, is a convenient place to try them, a few at a time, at speed.
Small stores are favoured precisely because they are less guarded. This guide explains how card testing works, how to recognise it in your payment data, what it costs and how to build layered defences that stop most of it without blocking real customers. It complements order fraud rules for small stores and chargeback prevention. Payment providers differ in the tools they offer, so check your provider’s current documentation.
How the attack works
- The attacker obtains lists of stolen card numbers, often incomplete or unverified.
- A script, often a bot, submits them through a checkout or payment form, usually at low value.
- Each response tells the attacker whether the card is valid, perhaps through the type of decline or by approval.
- Valid cards are used elsewhere for larger purchases, or sold on.
- The store is left with a flood of declines, a few successful micro-charges that later turn into disputes and a strained relationship with its payment provider.
Attackers choose payment forms that are easy to automate and that return clear signals: checkouts without CAPTCHA, donation pages, gift-card purchases, cheap digital products and forms that accept guest orders. Blocking one route often moves the attack to another, which is why layered defence matters.
Signs you are being tested
| Sign | What you might see | Note |
|---|---|---|
| Burst of declines | Dozens or hundreds of failed payments in minutes | Often at night or weekends |
| Tiny amounts | Orders of the lowest price or just a gift card | Attackers prefer low-value probes |
| Odd emails | Random strings, sequential names, disposable domains | Pattern repeats across attempts |
| Same IP or small range | Many attempts from one source or hosting provider | Proxies can disguise this |
| Mismatched details | Billing and shipping very different; unusual addresses | Not always present |
| Spike in checkout traffic | Without more visitors or ad spend | Check analytics for direct hits to checkout |
| Unusual error codes | Many “security code incorrect” or “do not honor” results | Your provider’s dashboard categorises them |
| Provider warnings | Email about high decline rates | A late sign: act on earlier ones |
What it costs you
- Processing fees. Providers often charge a fee for failed attempts as well as for successes, depending on your plan.
- Disputes. A few tests succeed. The real cardholders later dispute them, and each dispute can carry a fee. A high dispute rate can lead to monitoring programmes or account restrictions; see Stripe dispute evidence.
- Account review. Payment providers watch for abnormal patterns and may pause payouts or ask questions.
- Inventory and fulfilment. If small successful orders get fulfilled, you lose goods.
- Time. Cleaning up and answering questions takes hours.
- Customer impact. Overreacting with blanket restrictions can block real shoppers.
A layered defence
Think of defence as several thin barriers, each cheap, together costly enough that the attacker moves elsewhere.
| Layer | What it does | Trade-off |
|---|---|---|
| Bot protection / CAPTCHA | Challenges suspicious traffic at checkout or on forms | Adds friction if over-used; apply to risky sessions |
| Rate limits | Caps attempts per IP, per session and per card or email | Needs tuning to avoid blocking shared networks |
| Payment-provider rules | Rules based on risk scores, countries, CVC and postcode checks | Some tools are paid or need configuration |
| Security code and address checks | Require CVC and, where relevant, postcode matches | Some real cards fail on address |
| 3D Secure / strong authentication | Cardholder verifies with their bank | Can reduce conversion; use risk-based triggering |
| Minimum order values or limits on gift cards | Removes the cheap probe route | May affect low-value sales |
| Account or email requirements | Require sign-in or verified email for risky products | Adds friction to checkout |
| Blocklists | Block known bad IPs, emails and domains | Maintenance; attackers rotate |
| Monitoring and auto-pause | Detects bursts and switches on stricter rules | Needs a way to restore normal rules |
Use risk-based controls where possible: strict rules only for suspicious sessions, not everyone. Your payment provider’s fraud tools generally work this way. Stripe, Shopify Payments and others publish guidance specific to card testing, and it is worth reading before you design your own rules.
Protect the routes attackers love
- Donation and tip forms. Add CAPTCHA and minimum amounts.
- Gift cards. Limit quantity and require sign-in or review of first purchases.
- Free trials and sign-ups with a card. Verify the email and add bot protection.
- Add-to-cart endpoints and APIs. Rate limit them, since bots often skip the page and call them directly.
- Guest checkout. Keep it, but watch it, since it is the easiest route.
- Custom payment pages and old checkout versions that you no longer use. Remove them.
Detect it automatically
Manual checking of the payments dashboard is how many stores find out hours late. Automate the detection with a few simple rules that run frequently.
- Count failed payments per five minutes and alert above a threshold set from your normal rate.
- Count distinct emails or cards per IP address over an hour.
- Watch the ratio of declined to successful payments.
- Alert on bursts of orders at your lowest price point.
- On a trigger, enable stricter rules automatically: CAPTCHA on all checkouts, tighter rate limits and 3D Secure for all.
- Notify the owner and keep the stricter mode on until a person reviews and switches it off.
The key design decision is the automatic protective mode with human release. It stops the bleeding at 3 a.m. without leaving the store locked down forever. Our fraud screening and fraud prevention services build these detection and response rules, and monitoring store automations shows how to make alerts reliable.
What to do during an attack
- Turn on stricter protection at your provider and checkout (CAPTCHA, 3D Secure, rate limits).
- Pause fulfilment of suspicious low-value orders until reviewed.
- Block obvious sources such as repeated IPs and email patterns.
- Contact your payment provider, describe the pattern and ask for guidance; they see the wider picture.
- Refund successful test charges where appropriate, to reduce disputes, following your provider’s advice.
- Review after the event and strengthen the route that was used.
Working with your payment provider
Your payment provider sees patterns across thousands of merchants, and it is usually keen to help you stop card testing, because attacks cost it money too. Learn which fraud tools your plan includes, such as risk scores, rules on card country and security code checks, and turn on the ones that fit. Ask support what thresholds trigger a review of your account, and what they want to see in a response. Keep a short incident record: when the attack started, what you changed and what the effect was. If the provider contacts you about a high decline or dispute rate, respond quickly with specifics. Providers tend to be more forgiving of merchants who show that they noticed and acted than of those who stay silent.
A worked example
A store that averages 40 failed payments a day sees 1,800 failed attempts in two hours overnight. The provider charges a fee on each failed attempt under its plan, say 10 cents, so the burst costs about $180. Of the attempts, 25 succeed at $5 each, and 18 later become disputes at a fee of $15 each, or $270 in dispute fees plus the $125 of refunded or lost charges. The total is roughly $575 for one night, plus the risk of the account being reviewed. A rule that triggers CAPTCHA and tighter rate limits when failed payments exceed 100 in 10 minutes would have fired within minutes and limited the attempt count to a few hundred. The figures are illustrative and depend on your provider’s fees.
Mistakes to avoid
- Waiting for the provider to warn you. Their threshold is later than yours should be.
- Blocking whole countries without checking your customers.
- Relying on one control. Attackers adapt.
- No way to restore normal rules, leaving permanent friction.
- Ignoring forgotten routes, like an old payment page.
- Not telling your provider, who can often help.
Sources and further reading
Figures and rules in this guide come from the primary pages below. Platform limits and prices change, so open the page before you build on a number.
- Stripe: card testing, how card testing works and how to prevent it
- Shopify Help Center: fraud and chargebacks, identifying and handling fraudulent orders
- FTC: consumer data on card fraud, general information on payment fraud trends