You open your payment dashboard on a Monday morning and find 400 new $1 charges from overnight — all from different card numbers, most of them declined, a handful inexplicably successful. Nobody bought anything. Your checkout was just used as a card validator, and the cleanup bill is already growing.
That scenario is not a freak event anymore. Signifyd's 2026 State of Fraud report found card-testing attacks surged 175% year over year in the first four months of 2026, and card testing now sits among the five most common fraud types merchants face, hitting at least a third of them. If you sell anything online — physical goods, digital downloads, SaaS seats, or nonprofit donations — your payment form is a target. Here is how card testing works, what it actually costs you, and the layered controls that stop it.
What Card Testing Is (and Why Bots Love Your Payment Form)
Card testing, also called carding, card checking, or enumeration, is the process of validating stolen card numbers to find the ones that still work. Fraudsters buy breached card data in bulk, then run it through real merchant checkouts to see which cards authorize. The valid ones get used for bigger fraudulent purchases or resold at a premium; the duds get discarded. Industry estimates put bots behind roughly 80% of these attacks — this is automated, high-volume probing, not someone typing numbers by hand.
Attackers typically probe you in two ways:
- Small-amount payments. A $1 or $2 charge is small enough that most cardholders never notice it, so it rarely gets reported. A success means the card is live.
- Card setup and tokenization. Saving a card to an account or wallet triggers a $0 verification or a small authorization that usually never appears on a cardholder statement at all. This is the stealthier channel, and it is why account-creation and "save a card" endpoints get hammered just as hard as checkout pages.
Donation forms deserve a special mention. Nonprofits are disproportionately targeted because their forms are deliberately frictionless — no account required, tiny minimums, emotionally urgent copy — which is exactly what a testing script wants. If you run a nonprofit, everything in this guide applies to you twice over.
Why Your Checkout Got Picked
Card testers are rational about where they burn their bot time. They look for payment endpoints with three properties: no login required, low or no minimum amount, and an instant machine-readable response (approved or declined) they can feed back into their script. Guest checkout, digital-goods stores with instant delivery, free-trial-to-paid flows, and donation pages check every box.
None of this means you did something wrong. Fraud prevention teams at every major processor treat card testing as background radiation of online commerce — unavoidable, but manageable. The goal is not to make your checkout impenetrable; it is to make it expensive enough to probe that the bots move on to someone else's form.
What an Attack Actually Costs You
The damage goes well beyond the few dollars in fraudulent charges. Add up the full bill:
Authorization and processing fees. Depending on your pricing plan, you can pay a per-authorization fee on every attempt — including declines. A burst of 10,000 test attempts is real money even if every single one fails.
Dispute fees and chargebacks. The small payments that succeed eventually get noticed by cardholders and reported as fraud. Each fraudulent dispute typically costs you a $15 to $25 dispute fee on top of the refunded amount, plus the staff time to respond. LexisNexis puts the total downstream cost of fraud at $4.61 for every $1 of direct fraud loss for US merchants, once you count fees, lost merchandise, and operations.
A damaged decline-rate reputation. Issuers and card networks watch your decline ratio. A testing burst pins a huge pile of declines to your account, which makes your legitimate transactions look riskier — and that can raise your decline rate on real customers even after the attack stops. You keep paying for the attack in lost sales long after the bots leave.
Monitoring programs and fines. If testing-driven disputes push your dispute ratio over the card networks' thresholds, you can land in a dispute monitoring program with monthly fines that escalate the longer you stay in it. This is the tail risk that turns a nuisance attack into a five-figure problem.
Polluted business data. Successful test charges look like new customers in your analytics. Revenue dashboards, conversion rates, and growth trends all get skewed, which makes it harder to see how your real business is doing — and harder to reconcile your books, as we will cover below.
How to Tell You Are Being Tested
Catch it early and you can often shut it down before the dispute wave arrives. Watch for these red flags:
- A sudden spike in declined authorizations, especially for small amounts
- Many attempts from a small set of IP addresses, or one IP address cycling through many cards
- Rapid-fire submissions seconds apart, at odd hours, or from geographies you do not normally sell to
- Repetitive email patterns (random strings, plus-addressed variants of one inbox) or mismatched billing data across attempts
- A jump in $0 verifications or new saved-payment-method attachments with no corresponding purchases
- 3D Secure challenge failures clustering around the same time window
Most processors let you set up webhook alerts or dashboard views for decline-rate anomalies. If you do nothing else from this article, set up one alert for "decline rate doubled versus trailing average." That single notification is the difference between a two-hour incident and a two-week one.
The Controls That Stop Card Testing
No single control ends card testing; the defense is a stack of cheap frictions that together make your form unprofitable to probe. Implement them in roughly this order.
1. Require CVC and Address Verification — and Enforce the Result
Collect the card verification code (CVC) and billing ZIP on every transaction, then actually block transactions that fail those checks rather than merely flagging them. Stolen card dumps often lack the CVC, so a hard decline on CVC mismatch filters out a large share of testing traffic at zero cost to legitimate buyers, who have their card in hand. Never store CVC values — that is both a compliance violation and pointless, since you cannot reuse them anyway.
2. Add CAPTCHA to Payment and Card-Save Endpoints
Because testing is overwhelmingly bot-driven, a CAPTCHA on every endpoint that can validate a card — checkout, save-a-card, wallet top-up, donation submit — breaks most attack scripts outright. Start with an invisible, score-based CAPTCHA so real customers never see a puzzle; if an attack is underway, switch to a visible challenge temporarily. Two implementation details matter enormously: validate the CAPTCHA token on the server side, not just with client-side JavaScript (bots skip the browser), and make sure the check covers every card-validating request, not just the main checkout page.
3. Set Velocity Limits
Velocity rules cap how often the same entity can attempt payments in a time window. Sensible starting points for a small merchant:
- Max attempts per IP address per hour and per day
- Max distinct cards per email address, account, or device per day
- Max new customer accounts created from one IP address per day
- Max purchases of the same low-value SKU in a short window
The key word is "same entity across dimensions" — testers rotate cards but often reuse IPs, emails, or devices, so a rule on any one dimension catches them. Most fraud platforms, including the ones bundled with major processors, support these as configurable rules; tune thresholds against your real peak traffic (a product launch or Giving Tuesday surge should not trip your own defenses).
4. Raise the Cost of Each Attempt
Small structural changes make your form a worse target without hurting conversion much:
- Require login for checkout, or at least for saving a payment method. Forcing account creation with email verification slows scripts dramatically.
- Set a minimum charge amount that still converts. Moving a donation minimum from $1 to $5 barely dents real donors and makes each probe five times more expensive.
- Add a small delay or confirmation step before the final authorization. Humans do not notice a one-second pause; a script running thousands of attempts an hour feels it immediately.
5. Turn On 3D Secure for Risky Traffic
3D Secure 2 shifts liability for authenticated transactions to the issuer and cuts card-not-present fraud dramatically — industry data suggests reductions around 70% where it is applied. The conversion tradeoff is real, so the smart play is selective: challenge only transactions that trip your risk rules (new device, mismatched geography, velocity flags) and let trusted returning customers sail through frictionless.
6. Know What to Do Mid-Attack
If the alert from the previous section fires at 2 a.m., here is the playbook:
- Refund the successful fraudulent payments promptly. A refund costs you the processing fee; a dispute costs you the fee plus $15 to $25 plus ratio damage. Refunding is the cheaper exit every time.
- Tighten rules temporarily. Drop velocity thresholds, switch CAPTCHA to visible, enable 3D Secure broadly. You can relax them after the wave passes.
- Do not retry the fraudsters' cards. Aggressive dunning and smart-retry logic can re-fire saved cards from fraudulent accounts, effectively repeating the attack against yourself. Exclude recently created, never-fulfilled accounts from retry sequences.
- Block and report. Block the abusive IPs and device fingerprints, preserve logs, and file a report with your processor — early reporting helps if any resulting disputes need context.
Bookkeeping for the Aftermath (Do Not Skip This)
Fraud incidents create accounting messes that linger for months if you book them sloppily. When the dust settles:
- Track dispute fees in their own expense account, separate from processing fees. Lumping them together hides the true cost of the incident and makes it impossible to measure whether your new controls paid off.
- Reconcile gross to net carefully. Test authorizations, refunds, and chargebacks all hit your payout at different times. Reconcile your processor payout against your order records line by line for the affected period instead of trusting the dashboard totals.
- Record fraud losses explicitly. Unrecovered chargebacks are a real expense, not a revenue reversal to bury in a miscellaneous account. Booking them to a dedicated fraud-loss account keeps your margins honest and gives you clean numbers for insurance or tax purposes.
- Watch your reserve. Processors sometimes impose or raise a rolling reserve after a fraud spike. That is cash you cannot touch — forecast around it so a reserve hold does not surprise your operating account.
If your ledger already separates processing fees, refunds, and chargeback losses into distinct accounts, this cleanup takes an afternoon. If everything lands in one "Stripe fees" bucket, it takes a week. The boring chart-of-accounts work you do today is what makes the next incident survivable — and the Beancount documentation on structuring accounts is a good reference if your books need that cleanup.
Keep Your Checkout — and Your Books — Hostile to Fraud
Card testing is getting worse, not better: automated attacks keep rising, and every online seller is in the blast radius. The merchants who suffer most are not the ones who get probed — everyone gets probed — but the ones with no decline-rate alert, no velocity limits, and no plan for the 2 a.m. incident. Put the controls in this guide in place now, while traffic is normal, and the next burst becomes a notification instead of a crisis.
And when the fraudulent charges, refunds, and dispute fees hit your ledger, make sure they land in accounts that tell you the true story. Beancount.io provides plain-text accounting that gives you complete transparency and control over your financial data — no black boxes, no vendor lock-in. Get started for free and see why developers and finance professionals are switching to plain-text accounting.
