Card-testing fraud: how merchants detect and stop it

Most merchants discover card testing the same way: the dashboard suddenly shows hundreds of declined payments for one or two dollars, at three in the morning, from customers called “asdf qwer”. Nothing was stolen from the merchant directly, yet the attack leaves real damage behind. This guide covers what is happening, how to confirm it and how to make your checkout an unattractive target.

What card testing is, from a merchant’s point of view

Card testing — also called enumeration, account testing or card checking — is the use of someone else’s checkout to find out which payment credentials are valid. Visa describes enumeration as systematically testing or guessing card numbers, expiry dates, CVV2 values or postal codes to identify credentials that can later be used for fraud. Stripe describes the same pattern: scripts submit large numbers of cards, read the issuer or 3-D Secure responses, and keep the ones that pass.

Two variants matter for defense:

• Testing stolen card lists. The attacker already has card numbers from a breach or phishing and wants to know which are still active.
• Guessing missing details. The attacker has partial data and cycles through possible expiry dates, security codes or postal codes until the issuer approves.

Either way, your checkout is being used as a free oracle. The attacker needs an endpoint that sends card details to an issuer and returns the answer quickly, with as little friction as possible.

Which endpoints get targeted

Stripe notes that targeted endpoints usually let an attacker do one of two things: save a card or make a payment. Card saving is popular with attackers because verification authorizations rarely appear on cardholder statements, so the real cardholder is less likely to notice. Visa and Cybersource single out donation pages and any form that accepts a free-text amount, where an attacker can submit tiny charges.

What an attack costs you

Even when almost every attempt is declined, card testing has consequences that outlast the attack:

How to recognize a card-testing attack

Stripe says most attacks are obvious once you look: a significant increase in failed authorizations and payments. The signals below are drawn from Stripe’s and Visa’s guidance.

Controls that stop card testing

Attackers rotate IP addresses, devices and identities, so Stripe warns that simple rules based on one heuristic — such as IP address alone — are usually not enough. The goal is to stack controls so that testing on your site becomes slow and expensive while real customers barely notice.

Bot protection and CAPTCHA

Card testing depends on automation. A CAPTCHA or bot-detection service blocks a large share of scripted traffic. Stripe’s guidance is specific about getting it right: validate the CAPTCHA on the server, require it on every request that can create a payment or save a card, tune the threshold if your provider returns a score, and try a different or visible challenge if attacks continue. Visa adds a web application firewall configured to limit repeated submissions and block known malicious sources, and device fingerprinting that can see through proxies.

Velocity limits on several dimensions

Velocity rules cap how often something can happen in a time window. Visa gives the example of limiting authorizations from one IP address or one card number within a set timeframe, and recommends tracking velocity across several data elements, not just transactions. Typical limits to consider:

• Payment attempts per IP address, device, email and customer account per hour.
• Cards added per account and per session.
• New accounts created per IP address per day.
• Changes of payment method per account.
• Purchases of the same product in a short window.

A minimal server-side counter, written with Django’s cache API, shows the idea. Count every dimension on each attempt so one fresh value cannot hide the others:

from django.core.cache import cache

LIMITS = {              # kind: (max attempts, window in seconds) – tune to your normal traffic
    'ip': (5, 3600),
    'device': (5, 3600),
    'email': (3, 3600),
    'account': (3, 86400),
}

def over_limit(kind: str, value: str) -> bool:
    limit, window = LIMITS[kind]
    key = f'pay-attempts:{kind}:{value}'
    cache.add(key, 0, timeout=window)   # starts the window on the first attempt
    return cache.incr(key) > limit

def allow_payment_attempt(ip: str, device_id: str, email: str, account_id: str) -> bool:
    values = {'ip': ip, 'device': device_id, 'email': email.strip().lower(), 'account': account_id}
    results = [over_limit(kind, v) for kind, v in values.items() if v]
    return not any(results)             # if False: show a CAPTCHA or refuse, and log it

A softer variant from Stripe’s guidance combines both ideas: let the first attempt from an IP address through, then require a CAPTCHA for further attempts from that address for the next few hours.

Protect the endpoints that reach the issuer

• Require a session. The easier your payment form is to reach — guest checkout, public donation pages — the easier it is to abuse. Requiring a login or a validated session before the card step raises the cost of each attempt.
• Use CSRF tokens. Both Stripe and Visa note that cross-site request forgery protections also stop simple automated attacks.
• Create payments on the server. Do not let the browser choose amounts or call card-saving operations without your server’s checks in between.
• Limit card saves. Cap the number of cards per account and rate-limit the “add card” step, which Visa also calls out for tokenization flows.
• Keep keys safe. If your secret API key leaks, attackers can create payments directly. Roll API keys if an attack is hitting your API rather than your web form.

Require CVV and AVS

Visa recommends requiring the security code and address verification on all card-not-present transactions, because together they significantly increase the cost and complexity of guessing. Decline or challenge payments where the issuer reports a CVV mismatch, and decide how to treat postal code failures for your market. See our guide to CVV, CVC and CID codes for the details.

3-D Secure

Visa’s merchant guidance lists 3-D Secure as a defensive measure. Authentication puts the issuer and the cardholder’s banking app in the loop, which a script holding only card details cannot complete. You can apply it to all payments or only to risky ones, such as first purchases or orders that trip a velocity rule. Our 3-D Secure guide explains frictionless and challenge flows.

Minimum amounts

Attackers prefer tiny charges because cardholders rarely notice them. If you accept donations or custom amounts, set a minimum that is as high as is reasonable for genuine customers — both Visa and Cybersource recommend this.

Fraud rules from your payment provider

Payment providers run their own models across many merchants. Stripe, for example, applies rate limiters, machine-learning models and CAPTCHA triggers when you use its hosted Checkout or Payment Element, and those models work better the more data you send: IP address, email, name and billing address. Radar-style custom rules let you block or review payments on velocity, CVC results or BIN country. Use the tools you already pay for before building your own.

What to do during an active attack

1. Confirm it. Check the decline rate, the amounts and the customer details. Look for one IP range, device or account behind many cards.
2. Tighten controls now. Turn on or harden the CAPTCHA, lower velocity thresholds, require login for checkout, and raise minimum amounts temporarily.
3. Block what you can see. Add the offending IP addresses, devices, emails and accounts to block lists, knowing attackers will rotate them.
4. Refund suspicious successes. Refund payments that got through before cardholders dispute them, and cancel any orders tied to them.
5. Roll keys if needed. If requests are hitting your API directly, rotate your API keys and check where they leaked.
6. Do not retry. Stripe warns that retrying cards saved by fraudulent customers repeats the attack. Exclude them from dunning and subscription retries.
7. Tell your provider. Your acquirer or payment provider can apply network-level protections and may ask for attack details such as IP addresses and user agents.
8. Monitor. Watch the same metrics for several days to confirm the mitigations hold, then relax temporary measures carefully.

Testing your defenses safely

For the checks that apply to a single payment, see how to spot a fake card number. Never test fraud controls with real card numbers or against your live environment. Build and verify rules in your provider’s test mode, using documented test card numbers and generated format-valid numbers for client-side validation. In Stripe test mode, 4100 0000 0000 0019 is always blocked by Radar and 4000 0000 0000 0101 fails the CVC check, which lets you confirm that your code handles a fraud block and a CVC failure gracefully. Test your velocity limits in staging with a script you control, and make sure the rate limiter is active before the payment provider is ever called.

Mistakes that make things worse

• Relying on IP blocking alone. Attacks move to new IP addresses within minutes.
• Client-side-only CAPTCHA. A check that is not verified on the server is ignored by scripts that call your endpoint directly.
• Blocking all foreign cards. This hurts real customers and does little against attackers using domestic stolen cards.
• Aggressive automatic retries. Excessive retries look like card testing to issuers and can harden their risk stance against you.
• Ignoring the save-card flow. Many teams protect the payment button but leave “add a card” in account settings unprotected.