Card testing mitigation is the set of controls that makes it slow, expensive, and visible when someone tries to guess card numbers on your checkout. The short version: rate limit by IP and device, put a challenge in front of suspicious sessions, enforce AVS and CVV, set velocity rules on attempts and declines, and watch for bursts of tiny authorizations. You do not need a fraud platform to start. You need a few rules that turn a cheap attack into a noisy one.
What card testing looks like from the merchant side
Someone runs a list of stolen or generated card numbers through your payment form. Most attempts fail. The ones that work get used for gift cards, digital goods, or resale. The attack is not subtle if you know where to look.
- Many authorization attempts in a short window, often from the same IP range or device fingerprint.
- Small order values, frequently under a dollar, used to check whether a card is live.
- A decline rate that jumps well above your normal baseline on a single payment path.
- Cards from countries you do not ship to, paired with addresses that do not match.
- New accounts, guest checkout, and the same email pattern repeated across orders.
Card enumeration attacks on the authorization endpoint often show up before the orders do. That matters, because the failed attempts are the cheapest place to stop the run.
Controls that cut the volume
Slow the endpoint down
Rate limiting is the first layer. Set limits per IP, per device, and per card BIN over a rolling window. A real customer rarely submits five cards in ten minutes. An attacker needs hundreds. Add a CAPTCHA or a challenge page when a session crosses a threshold instead of blocking outright, so you keep the false positive rate low.
Make the card data work for you
Require CVV and AVS on every transaction that supports them, and decline on mismatch instead of accepting and eating the chargeback. Turn on 3D Secure for high-risk segments: new accounts, digital goods, and orders that fail your velocity checks. Risk-based authentication is not free in conversion terms, so scope it to the sessions that look wrong.
Watch the decline stream
Most merchants watch approvals and ignore declines. Flip that during an attack. A spike in declined authorizations from one ASN or one device is your early warning. Route it into an alert, not a dashboard nobody opens. Block the source at the edge, then review whether the pattern moved.
Response plan
- Confirm the pattern: same endpoint, same timing, same source cluster.
- Apply a temporary block on the source range and device signatures.
- Raise the challenge threshold for the affected payment path.
- Review approved orders from the window for manual capture or refund.
- Log the incident, then tune the rules so the next run trips faster.
What not to do
Do not block whole countries or all guest checkout as a first response. That punishes real buyers and teaches you nothing about the attack. Do not store CVV, and do not loosen AVS to lift conversion during a suspected run. And do not treat a drop in failed attempts as the end of the incident. Attackers move to another endpoint. Keep the rules on for a week and check the decline baseline before you relax them.