The first sign is rarely dramatic. It's a trickle of payment notifications on a quiet evening — $1 here, $0.87 there, a dozen charges from names you've never seen, for a product that costs $49. By morning there are two hundred of them, most declined, some not. Nothing about your business has changed. What's changed is that somewhere, someone with a spreadsheet of stolen card numbers has decided your checkout page makes a good laboratory.
This is card testing, and it's one of the few kinds of fraud where the immediate damage is not the point. The tiny charges are a means to an end. The real cost arrives on a delay — as chargebacks, weeks later, long after the bots have moved on. Understanding both waves of the attack is the difference between a bad afternoon and a bad quarter.
What card testing actually is
When card numbers are stolen — in a data breach, through a phishing kit, from a skimmer on a gas pump — they're sold in bulk. But a list of stolen numbers has a problem: nobody knows which ones still work. Cards get cancelled, reissued, and frozen all the time. A dead number is worthless. A number confirmed live can be resold at a premium or used for real purchases.
So before the profitable fraud, there's a validation step. The fraudster needs to run each number through a real payment system and see what comes back. Approved means live; declined means dead. Your checkout — or your donation form, or your $5 digital download — is the machine that sorts one pile from the other.
The amounts are small on purpose. A $1 charge is less likely to trip the issuing bank's fraud model and less likely to be noticed by the cardholder scanning a statement. Some attacks never complete a charge at all: they run authorizations only — the temporary hold that checks whether a card is valid without capturing money — because an authorization answers the fraudster's question just as well as a payment does.
A common variant is the BIN attack. The first six to eight digits of a card number — the bank identification number — identify the issuing bank. An attacker takes one known-good card, generates thousands of candidate numbers within the same BIN, and tests them all. That's why card-testing traffic often looks eerily uniform: same bank, same card type, numbers that differ by only a few digits, fired at your form seconds apart.
Why the attack picked you
It didn't, in any personal sense. Bots crawl the web for payment forms the way vulnerability scanners crawl for open ports, and what they're looking for is the absence of friction. A checkout that accepts a card with no account, no CAPTCHA, no 3D Secure challenge, and returns a clean approved-or-declined signal is ideal. Donation forms are famously popular targets because they accept arbitrary small amounts by design. So are free-trial signups and pay-what-you-want checkouts.
Being targeted says nothing about your product and everything about your form. That's oddly good news, because it means the fix is mostly mechanical.
The second act: chargebacks on a delay
Here's the part that catches merchants off guard. Suppose fifty test charges succeeded before you noticed. You saw them, shook your head, and moved on. The event feels over.
It isn't. Each of those fifty charges now sits on a real person's card statement. Over the following weeks, those cardholders — or their banks' automated fraud models — will find the charge and dispute it. Because the cardholder genuinely never authorized the payment, these arrive as true fraud disputes; on Visa cards, that's reason code 10.4, fraud in a card-absent environment. Stripe charges its $15 dispute fee on every one, regardless of the charge amount and regardless of the outcome. Fifty one-dollar charges can quietly become hundreds of dollars in fees, plus a spike in the number that matters most: your dispute rate.
And a dispute rate is a ratio. A card-testing attack inflates the numerator — disputes — without adding any legitimate volume to the denominator. A small merchant can be pushed toward a card network's monitoring program by an attack they didn't cause and never profited from. The bots cost you three ways: fees now, chargebacks later, and standing with the networks all along.
The first hour: contain, then refund
If you're mid-attack, the order of operations matters.
First, stop the bleeding. In Stripe, Radar rules can block the traffic's signature: velocity limits on charges from a single IP or email address, blocking payments where the CVC check fails, requiring 3D Secure on higher-risk attempts. Adding a CAPTCHA to the payment form cuts off the simplest bots entirely. If the attack is aggressive, temporarily pausing the payment surface is cheaper than absorbing another thousand attempts while you think.
Second — and this is the counterintuitive one — refund the fraudulent charges that succeeded. Proactively, before the cardholders notice them. A refunded charge generally never becomes a chargeback, because by the time the cardholder looks, the money is already back and there's nothing to dispute. Refunding costs you the processing fee; a chargeback costs you the amount, the $15 fee, and a permanent tick on your dispute rate. The window matters, though: once a dispute has actually been filed, refunding no longer helps — the dispute proceeds anyway. The time to refund is early, and briefly.
Third, tell Stripe. When you refund, mark the charges as fraudulent rather than issuing a plain refund. That feeds Radar's machine-learning model, helps protect other merchants seeing the same cards, and documents that you acted the moment you knew.
Sorting real customers from the noise
The hard part is that an attack doesn't pause your actual business. Real orders keep arriving, mixed into the flood, and refund-everything is its own expensive mistake.
Card-testing charges tend to share a fingerprint: rapid-fire timing, amounts your product doesn't actually sell for, email addresses that read like keyboard mashing, failed CVC or postal-code checks, card numbers clustered in one BIN, and IP addresses nowhere near the cardholder's country. Legitimate orders have the opposite texture — a browsing session before the purchase, matching address and CVC verification, an amount that corresponds to a real price on your site, an email that belongs to a person. Ten minutes of filtering by these signals usually separates the piles cleanly.
When the chargebacks land, fight the right ones
Weeks after the attack, the disputes start trickling in, and triage becomes the job. The true card-testing disputes are unwinnable on purpose: the cardholder really didn't authorize the charge, so there is no evidence that could prove they did. Fighting them wastes your time and a reviewer's. Accept them — or, if you already refunded the charge before the dispute arrived, respond with proof of that refund, which is one of the few responses that resolves a fraud dispute cleanly.
But swept into the same wave will be disputes from real customers — some coincidental, some emboldened by a bank that's now watching your merchant account more warily. Those deserve a full, evidence-backed response: the order history, the verification matches, the delivery confirmation. The failure mode is treating the wave as one thing — conceding everything out of fatigue, or contesting everything out of anger. Each dispute is its own small case, and the ones you can win are hiding among the ones you can't.
That triage is exactly where a bad month gets worse, because every one of those disputes carries its own deadline, and they all land while you're also patching the checkout that let the bots in. Argeback is built for that moment: it ingests every Stripe dispute as it arrives, drafts an evidence-backed response for the ones worth fighting, and files before the deadline — from your phone, in the gaps of a week that's already on fire. If a wave of tiny charges ever turns into a wall of disputes, you don't have to sort it alone: argeback.lumenlabs.works.