Card testing mitigation comes down to two goals: make each attempt expensive to try, and make the pattern easy to see. Attackers push stolen card numbers through your checkout in bursts, keep the ones that authorize, and discard the rest. You stop the burst before it scales, using rate limits, velocity rules, bot detection at the form, and a fraud screen that flags behavior rather than individual orders. The cart usually tells you where to look first. Cheap items with instant delivery get hit hardest, because the attacker wants a fast yes or no and nothing to ship.

related article

What card testing looks like from the inside

I look for a few signatures before anything else. A spike in declined authorizations that outpaces order volume. Many attempts from a small set of IPs, or a huge spread of IPs hitting one SKU. Email addresses that look generated. Billing and shipping details that do not match. Guest checkouts with no browsing history behind them. Card numbers entered fast, one after another, sometimes with the same last four digits cycling through.

related article

On the payment side, the giveaway is the decline mix. Testers generate a lot of specific decline codes in a short window, and they will retry the same card or PAN ranges until they get a different answer. Your processor sees it before you do, which is why processor fraud alerts and your own logs should be read together.

related article

Why small merchants get targeted

Testers prefer sites with weak friction and thin monitoring. A small shop with a simple checkout, no CAPTCHA, and a digital product is a better target than a large retailer with a mature fraud stack. Donation pages, gift card purchases, and trial signups attract the same traffic for the same reason: the value is immediate and the risk of a chargeback lands on you later.

card testing mitigation v2

Layer one: rate limits and velocity rules

These are the cheapest controls and the ones most merchants skip. Set limits on attempts per IP, per card fingerprint, per email, and per session within a rolling window. Cap failed authorizations per account and throttle the checkout endpoint itself. A hard limit on how many distinct cards one session can try is the single most effective control I have seen.

• Limit checkout submissions per session and per IP per hour.
• Block a card fingerprint after repeated declines across different accounts.
• Add a delay or challenge after the second failure, not the tenth.

Layer two: bot detection and form hardening

Most card testing is automated. Invisible bot scoring, device fingerprinting, and a challenge on suspicious traffic cut the volume without touching legitimate buyers. Watch for headless browsers, missing headers, and scripted form fills. Server-side validation matters too: reject submissions that skip your checkout flow entirely, because scripted attacks often post straight to the payment endpoint.

Layer three: verification that costs the attacker something

Require CVV and address verification on every transaction and act on the results instead of logging them. Apply 3-D Secure to high-risk segments: new accounts, mismatched geolocation, digital goods, and any order above a threshold you set from your own chargeback data. It adds friction, so target it rather than applying it everywhere.

Layer four: monitoring and response

Build one dashboard that puts authorization attempts, declines, and order volume on the same timeline. Set an alert for decline spikes that is loud enough to wake someone. When an attack starts, block the source ranges and device IDs, disable the targeted SKU or raise its verification requirements, and tell your processor what you are seeing. Keep a written runbook so the response does not depend on who is on call.

A short checklist

1. Rate limit the checkout endpoint and count attempts, not just orders.
2. Turn on bot detection and challenge suspicious sessions early.
3. Enforce CVV and AVS, and route risky traffic through 3-D Secure.
4. Alert on decline spikes and review them the same day.
5. Keep a runbook with blocklists, processor contacts, and SKU kill switches.

The merchants who come out of this cleanly are not the ones with the fanciest tooling. They are the ones who noticed the pattern in hours rather than weeks and had a switch to flip when they did.