Card testing is the use of scripts to find out which stolen or guessed payment card details still work. The attacker submits card after card through a merchant's checkout, add-card form, or payment API, usually with small amounts or card-verification checks, and reads which attempts the issuer approves. The valid cards are then used for fraud or sold. The merchant never loses the cards, but it pays for the declines, fees, disputes, and payment-network scrutiny that follow.
Stripe's card-testing guide lists "carding," "account testing," "enumeration," and "card checking" as other names for the same activity. The payment networks draw a finer line, which the next section explains.
Card testing, enumeration and carding
Visa's guidance on enumeration attacks and account testing separates two schemes that both run on automated scripts:
| Term | What the attacker has | What the script does |
|---|---|---|
| Account testing | Card details obtained illegally | Submits one or two low-amount transactions to see if each account is active |
| Enumeration | A card range (BIN), without the full details | Iterates through card numbers, expiry dates, CVV2 and postal codes until the issuer approves |
The OWASP automated threats list uses a similar split: OAT-001 Carding tests bulk stolen card data, and OAT-010 Card Cracking guesses the missing values. For a merchant the difference matters less than the shared pattern: many automated payment attempts, most of them failing, sent through a flow that was built for customers.
How a card-testing attack runs
- Get the cards. The list comes from a breach, a phishing kit, or a criminal marketplace. For enumeration, the attacker starts from a card range instead.
- Find a weak merchant. Visa's merchant guidance on enumeration names legitimate online merchants with weak fraud controls as the most common target. Guest checkout and card-saving forms with no limits are attractive.
- Script the attempts. Stripe describes testers using both card setup and payments. They prefer card setup, because a validation during setup usually does not appear on the cardholder's statement. Payment-based tests use small amounts that cardholders are less likely to notice. Visa notes that attack transactions are often under 10 US dollars.
- Read the responses. Approvals, declines, and 3D Secure results tell the script which cards are live.
- Use or sell the results. Visa says the valid details are sold on underground carding sites or used for fraud elsewhere, often at another merchant.
Not every attack goes through a shop's front end. Scripts can call a payment API directly with a leaked or public key, and Visa also describes attackers opening merchant accounts under false identities or taking over a merchant's gateway login to test cards.
What it costs the merchant
The cards belong to someone else, but the merchant carries the side effects. Stripe lists:
- disputes on the test charges that succeed;
- a higher decline rate, which can make issuers treat the merchant's legitimate payments as riskier even after the attack ends;
- extra fees, such as authorization and dispute fees;
- load on infrastructure from the burst of requests;
- test payments that look like new customers in the business data.
The payment networks also watch for it. Under Visa's Acquirer Monitoring Program (VAMP), in effect since June 2025, Visa monitors enumeration every month alongside fraud and disputes. Acquirers must keep merchants below an enumeration threshold: 20% of authorization attempts identified as enumerated, with at least 300,000 such attempts in the month. Visa's merchant guide puts the losses from enumeration across the payments ecosystem at more than a billion dollars a year.
Signs of card testing
Most of the evidence sits in payment data, not in page views. Look for several of these together:
| Sign | Where you see it | Also consistent with |
|---|---|---|
| A sudden rise in failed or blocked payments | Payment provider dashboard, decline logs | A provider incident or a broken release |
| Many low-value attempts or zero-amount card verifications | Authorization records | A free trial or card-on-file flow working normally |
| Declines for invalid numbers, expired cards or failed CVV, grouped by card range | Decline codes by BIN | A card issuer's own outage |
| Many different cards from one account, session, device, or email | Your order and account data | Families or businesses sharing a device |
| Nonsense customer names and email addresses on small payments | Payment details | Test orders from your own team |
| Reversals sent right after approvals | Authorization and reversal logs | Legitimate order cancellations |
| Payment calls that skip the checkout page | API and server logs | A mobile app or partner integration |
Stripe's guide also flags a rise in requests failing with its 402 card errors and the
generic_decline result. It warns that testers vary their techniques, so a firewall rule or
filter based on one heuristic, such as IP address, is usually not enough on its own.
Watch for your own automation too. Stripe notes that aggressive retries of failed subscription payments can look like card testing when they produce spikes with a low success rate.
How to stop it
The controls work at two layers: before the request reaches the payment provider, and inside the payment flow.
- Use the provider's current integration and send it the risk data it asks for. Stripe says its card-testing protection depends partly on the information the integration supplies, such as IP address, email, name, and billing address.
- Limit the operations that validate cards. Cap cards added per account and per session, new accounts per IP address, and attempts per time window. Visa and Stripe both recommend these limits, and Visa extends them to the add-card and save-card steps.
- Check the client before the payment call. A challenge or bot check has to run on every request that can validate a card or create a payment, and has to be verified on the server. A check that only guards the checkout page does nothing against a script that calls the API.
- Require the card checks. Visa recommends CVV2 and address verification on card-not-present transactions, 3D Secure, and network tokens where available.
- Protect your keys. Stripe warns that testers can reuse a publishable key and that an exposed secret key lets them create payments directly. Visa suggests rotating API keys during an attack that targets the API.
- After an attack, refund successful test charges to head off disputes, and do not retry cards attached to fraudulent customers.
The carding prevention guide walks through these controls in order, including retry budgets and how to test changes without real cards.
What bot detection can and cannot tell you
Bot detection answers a question about the client: was this request sent by a person in a browser, by a script, or by an automated browser, and does it repeat a workflow across many sessions? That is useful here, because card testing only pays off at scale, and scale needs automation.
It does not answer questions about the card. A bot signal does not prove a card is stolen, a payment is fraudulent, or a cardholder was involved. Those answers come from the issuer and the payment provider. Legitimate automation reaches payment flows too: subscription billing, your own monitoring, and partner integrations. And a human-looking browser session does not prove that a payment is safe.
Keep the two decisions apart. Use automation evidence to decide which requests may reach the payment step, and let the provider's fraud checks decide the payment. Label findings as "automated card-verification attempts," not "fraud," until the payment data supports that.
Where Centinel fits
In supported web checkouts, Centinel evaluates browser and request evidence on checkout and card routes, so a site can challenge or block scripted attempts before they reach the payment provider. It does not score cards or transactions and does not replace the provider's fraud checks. The checkout and carding use case describes that boundary, and How to detect browser automation covers the evidence involved.