Every attempt costs you a fee, and every decline drags down the approval rate your processor watches. Here's how to confirm it's card testing, limit the damage today, and stop the next wave before it reaches your gateway.
Card testers use your checkout to find out which stolen cards still work. It rarely looks like fraud at first. It looks like a flood of declines.
Dozens or thousands of declines in a short window, usually at a small, fixed amount — the same few dollars, over and over.
Many different cards sharing the same first six digits. Testers work through a batch of stolen numbers from one issuer at a time.
The attacker has card numbers but not the billing details, so security-code and address checks fail on nearly every attempt.
Submissions seconds apart, sustained for hours — often overnight, when nobody is watching the dashboard.
The same card retried with small variations, or showing up across several of your storefronts or merchant IDs.
Your approval rate drops while real order volume looks unchanged. That's the number your processor and the card networks watch.
None of these require Cardvera. Do them today, whoever you end up working with.
Pull the last few hours of declines from your gateway dashboard and check them against the signs above. Note when it started and which endpoint is being hit — checkout, a card-update page, a donation form.
Temporarily require login or 3-D Secure on the targeted flow, raise the minimum order amount, or pause the endpoint being abused. Every attempt you stop now is one you don't pay for.
Tighten velocity rules and temporarily block the IP ranges and BINs you're seeing. They run after the attempt reaches the network, so they won't stop the per-attempt fees — but they cut approvals, which is what the attacker is after.
Authorizations the tester got approved are billed Misuse of Authorization if they're never settled or reversed. Void them rather than letting them sit. Don't fulfil anything from the attack window without a second look.
Tell your processor or acquirer what's happening and what you're doing about it. A merchant who reports an attack is in a far better position than one flagged by a falling approval rate.
Export the timestamps, IPs, BINs, amounts, and decline codes. You'll want them for the conversation with your processor, and to confirm the attack has actually stopped.
Gateway rules, blocklists, and reversals all act once the authorization has already been requested, so the per-attempt fees are charged either way. And testers come back in waves: they rotate IPs, cards, and timing until something gets through. Stopping the next wave means turning the attempts away before they become authorizations at all.
Blocked attempts never become authorizations, so there's no fee on them and no hit to your approval rate.
Real customers never see a challenge. Suspicious sessions get a silent proof-of-work that bot farms pay for.
Four detection layers adapt to the attack as it changes. Nobody has to chase thresholds at 2 a.m.
One script tag on the checkout, one API call before you charge. No cardholder data, and your PCI scope is unchanged.
Send us the export from your gateway and we'll turn it into a written assessment of the attack — whether it's happening now or happened last month. No charge, no obligation.
What we need: timestamp, amount, approved or declined, decline code, BIN, and IP address for each attempt. Strip names, emails, and full card numbers first — we don't need them, and we'd rather not have them. After you submit, we'll send a secure link for the file.
We'll reply with a secure link for your export.
In the meantime, work through the next-hour steps →
No spam. No drip campaigns. Just a reply from a human.