Card testing: what actually happens to your checkout before the first chargeback arrives
A decline spike that isn't a chargeback yet
One morning your payment dashboard shows something odd: dozens of new signups in the last hour, each one adding a card and running a small charge, most of them declined. Nobody has called to complain. No dispute has landed. If you check back next week, there may still be no chargebacks at all. It is tempting to read this as nothing, a bot problem for your support inbox rather than a payments problem for your merchant account. That reading is wrong, and by the time it produces a chargeback you can point to, the damage that matters most has usually already been done elsewhere.
What you are looking at is card testing: someone running a batch of stolen or guessed card numbers through your checkout, or your "add a card" form, to find out which ones still work. Your site is not the target. It is the tool. The fraudster does not want anything you sell; they want your payment form to tell them, for free, which of the numbers on a list they bought is a live card and which is dead plastic.
This matters to an adult classifieds operator specifically because the usual advice written for online merchants assumes a mainstream retailer with a mainstream processor. Your account almost certainly runs through a high-risk gateway, with its own reserve terms and its own, tighter tolerance for exactly the kind of decline spike a testing attack produces. The mechanism is the same everywhere; what it costs you is not.
This piece is about that mechanism: how testing works, what it actually costs before a single dispute exists, why a high-risk account absorbs it worse than a standard one, and what to change on your checkout this week rather than after the next attack.
None of this requires you to become a fraud analyst. It requires knowing what the spike in your dashboard actually is, so you stop treating it as noise.
What card testing actually is, and why a checkout like yours is convenient
A fraudster who buys or scrapes a batch of card numbers has a problem before they have an opportunity: most of those numbers are already dead, cancelled, or reported. Testing them one by one against a real purchase would be slow and would burn through legitimate merchants fast, because a declined purchase is the kind of thing a cardholder notices and a bank flags. So the fraudster looks for a cheaper, quieter way to ask the same question: is this card still alive.
The quiet way is to attach a card to an account, or run an authorization check, rather than complete a purchase. Stripe's own documentation says fraudsters prefer this route because the checks involved typically do not show up on a cardholder's statement, so the real cardholder has no obvious reason to notice and report anything. When that route is not available, a small purchase, a dollar or two, is the fallback, chosen because it is still small enough that most cardholders scan past it on a statement full of real charges.
Either way, the request has to land somewhere, and a script does not care what that somewhere sells. It cares whether the form is easy to reach and whether anything stands between a submitted card number and an answer. A signup flow that lets a visitor create an account and attach a card without a login wall, a CAPTCHA, or a limit on how many attempts one visitor can make, is exactly that kind of form, whatever the business behind it happens to be.
J.P. Morgan's merchant guide to these attacks makes the targeting pattern explicit: fraudsters look for merchants that are not equipped to detect or defend against the attack, often using them as what the guide calls a mule, an intermediate target used purely to find out whether an account is still active. A small or mid-sized classifieds operator running a lean checkout, often on a cheaper high-risk gateway that does not bundle the CAPTCHA and machine-learning defenses a platform like Stripe ships by default, fits that description more closely than a large retailer does, not because of what the site is about but because of what it can afford to build.
The result is a form of fraud that has nothing to do with your listings, your moderation, or your advertisers' honesty, and everything to do with how exposed your card-entry flow is to a script that has nowhere else productive to go.
What it costs you before anyone disputes anything
The instinct to wait for a chargeback before treating this as a problem is understandable, and it is the wrong instinct. J.P. Morgan's guide puts it plainly: do not rely on the chargeback process to identify a card-testing attack, because the window between a transaction and a dispute is long enough that a site can be hit repeatedly before anyone realizes there is a problem at all. By the time the first dispute lands, the attack that caused it may already be over, and a second one may already be running.
The cost that arrives first is not a dispute, it is a fee. Every authorization request your gateway sends to the card networks on your behalf, approved or declined, is a transaction your acquirer processes and typically bills for. A testing script that fires hundreds of attempts in an hour is not costing you in failed sales; it is costing you in authorization traffic you pay for regardless of outcome, on top of whatever flat or percentage fee your processor already charges for being a high-risk account.
The second cost is reputational in a very literal, mechanical sense: Stripe describes a spike in declines as something that can, on its own, damage how card issuers and networks read your business, making every one of your transactions look riskier even after the attack stops, which can mean legitimate customers' cards start getting declined too. Checkout.com's guidance says the same thing from the acquirer's side: a high decline rate signals risk to the people deciding how closely to watch your account, independent of whether any of those declines ever becomes a chargeback.
The third cost is the one that does eventually show up as a dispute. Some share of a testing attack succeeds, because some of the numbers are live cards attached to real people. Those small successful charges are exactly the ones a cardholder eventually notices on a statement and reports as fraud, turning into the chargebacks you were waiting to see as your first signal. For how those disputes count against your account once they land, see what actually decides a classifieds site's dispute ratio: the testing attack is often the quiet first act of a problem you only meet later in that form.
Why a high-risk account absorbs the same attack worse
The network-level programs that watch dispute and fraud ratios are not the first line of defense your processor relies on. Underneath them sits your acquirer's own, tighter internal threshold, the one it sets for itself precisely because it answers to the network if its whole merchant portfolio drifts too close to the line. By the time an account would officially cross a threshold a card network publishes, the acquirer has usually already acted on its own, earlier number, often with a reserve increase or a manual review rather than a formal notice naming the program.
For a high-risk merchant account, that earlier, private threshold is already the one you live under day to day; it is why the account carries high-risk pricing and a reserve term that a mainstream merchant's account does not. A weekend of card-testing declines does not have to touch any number a card network ever publishes to produce a response: it only has to move the number your own acquirer is already watching more closely than it watches a mainstream account, which is a lower bar to clear by definition.
The reserve itself compounds the problem rather than just reflecting it. A processor that reacts to a decline spike by holding back a larger share of revenue, or holding it longer, is removing working capital from a business that is already paying more than a mainstream merchant to process the same volume. That is money you cannot spend on the fraud tooling that would have stopped the next attack, which is exactly the trap a lean, cash-constrained high-risk operator is most likely to fall into.
None of this means your account is fragile because of what you sell. It means the acquirer was already watching your numbers more closely before the first test transaction ever hit your checkout, and a testing attack is one of the fastest ways to move a number it is watching.
What to check and change this week
Start by finding out whether you would even notice. Pull your decline rate for the last month and look for a pattern J.P. Morgan flags directly: a cluster of new accounts, created in a short window, each adding a card or running a low-value charge that gets declined, often from a narrow range of IP addresses or devices. If your dashboard does not make that pattern visible at a glance, that is itself the finding: you are currently relying on a chargeback, weeks later, to tell you something your decline log already knows today.
Refund immediately, do not wait. If any of the test transactions succeeded, refunding them as soon as you spot the pattern, rather than waiting to see if the cardholder notices, is the single cheapest thing you can do, and it is also the first step on Stripe's own card-testing checklist. A refund you issue counts against your account very differently from a dispute the cardholder files: the charge never becomes a chargeback, so it never reaches how disputes actually get resolved against your ratio at all.
Turn on the checks that already exist. Address verification and CVV matching are standard features on essentially every gateway, and they are frequently left on a permissive default because tightening them can decline a few legitimate customers along with the bots. For a business already absorbing high-risk pricing, that trade is usually worth making deliberately rather than leaving to a default setting nobody chose on purpose.
Put friction specifically on account creation and card entry, not just on checkout. A testing script's real target is your signup and card-add flow, not your purchase page, so a CAPTCHA and a hard limit on how many accounts or cards one IP address can create in a day belong there first. Ask your gateway directly what velocity and rate-limit tools your specific plan includes, because high-risk providers vary enormously on this, and the cheaper ones often sell the account without the defenses a mainstream gateway bundles by default.
Finally, stop telling declined customers why they were declined. Exposing a specific reason, a wrong CVV, a mismatched address, hands a testing script exactly the missing piece of a stolen card record it needs to refine the next attempt. A generic decline message costs you nothing with a real customer, who can call support either way, and it costs the fraudster the one piece of feedback that makes their next attempt more accurate than the last.
