Card Testing: How Fraudsters Test Stolen Cards on Your Store and How to Stop It

Card testing is a type of fraud in which criminals use your checkout to find out which stolen card numbers still work. They run hundreds or thousands of tiny payments, usually through bots, and keep the cards that go through for bigger fraud elsewhere. You may never ship a product, yet you pay for every authorization attempt, collect fraud chargebacks on the ones that succeed, and risk being flagged by the card networks. Stores that accept payments without card data, such as crypto payments sent from the customer’s own wallet, are not exposed to it at all, but most stores still take cards.

This guide explains how a card testing attack works, how it differs from BIN attacks and card cracking, the warning signs to watch for, what it costs under Visa’s current rules, and the controls that stop it.

What Card Testing Is

Stolen card data is cheap and plentiful. One industry guide counted 142 million stolen card records listed on dark-web markets in a single year. But a stolen number is only valuable if it works. Many have already been cancelled, have expired, or are missing the CVV.

Card testing solves that problem for the fraudster. They pick a merchant with a weak checkout, often a small store, a donation page or a subscription sign-up, and use it to check cards automatically. Cards that are approved get resold at a higher price or used for large purchases at other stores. The merchant who was used as the test lab rarely sees the rest of the crime.

The scale has grown with automation. Stripe reported that card testing attempts on its network rose more than 100-fold between 2019 and its 2022 wave, when its fraud tools were blocking over 20 million testing attempts per day at the peak. Merchant Risk Council research found that about a third of merchants experienced card testing in 2025.

How a Card Testing Attack Works

A typical attack follows a predictable pattern.

1. Find a target. Fraudsters look for checkouts that accept small amounts, do not require an account, and lack bot protection or CAPTCHA.
2. Script the checkout. A bot fills in the payment form or calls the payment API directly, using lists of card numbers, expiry dates and CVVs.
3. Run small payments. Amounts are tiny, often $0 to $5, or authorization-only checks, to avoid attention from both the merchant and the cardholder.
4. Rotate identities. The bot changes IP addresses, devices, emails and names to slip past simple velocity rules.
5. Harvest the results. Approved cards are marked as “live” and sold or used. Declined ones are discarded.

The whole run may take minutes. Attacks often start at night or on weekends, when no one on the merchant’s team is watching the dashboard.

Card Testing, BIN Attacks and Card Cracking

Several related techniques use the same weakness. The terms are often mixed up, so here is how they differ.

Visa calls the generated-number variant “enumeration”, and it now tracks it separately in its monitoring rules, which is one reason the topic has moved from the fraud team to the finance team in many companies.

Warning Signs on Your Checkout

Card testing is usually noisy once you know what to look for:

• a sudden spike in payment attempts with no matching rise in traffic from real visitors
• many failed authorizations in a short time, with decline codes such as “incorrect CVC”, “invalid number” or “do not honor”
• lots of very small payments or $0 authorizations
• many different cards used from the same IP address, device or browser fingerprint
• new accounts or guest checkouts with random-looking names and emails
• sequential card numbers or the same first digits appearing again and again
• attempts concentrated at unusual hours for your customer base
• a rise in fraud alerts or early fraud warnings from your processor a few days later

If you see several of these at once, treat it as an active attack.

What It Costs You (Including Visa VAMP)

Merchants often underestimate card testing because few orders actually ship. The costs add up elsewhere.

Visa’s monitoring program, VAMP, now combines disputes and reported fraud into a single ratio. Processor guidance for 2026 puts the “excessive” merchant threshold at 1.5% in the US and several other regions from April 1, 2026, with fines of about $8 per counted transaction. Enumeration is measured separately, with a threshold reported at 20% of transactions for merchants above a minimum volume. A single bad weekend of card testing can push a small store over these lines.

A merchant used for card testing can be penalized even when it shipped nothing. The card networks count the fraud and the attempts against the merchant’s account, not against the people who ran the bots.

Anatomy of an Attack: A Typical Weekend

Here is how a card testing attack commonly plays out for a small online store. The details are illustrative, but the pattern is one that fraud teams see again and again.

Friday, 11:40 p.m. A bot starts submitting payments of $1.00 to $2.00 through the store’s guest checkout. Each attempt uses a different card and a different email address. The store’s dashboard is not being watched.

Saturday, 2:00 a.m. About 1,800 attempts have been made. Roughly 90% are declined, with “incorrect CVC”, “invalid number” and “do not honor” codes. The remaining 10% are approved, so the store now has around 180 small payments on stolen cards.

Saturday, 9:30 a.m. The owner notices dozens of new orders for the cheapest product, all with strange names. The processor has already sent an email about unusual activity.

Monday. The store refunds the approved payments, blocks the IP ranges it can identify and adds CAPTCHA. It still pays authorization fees on 1,800 attempts.

Two to six weeks later. Some of the real cardholders spot the $1 charges and dispute them as fraud before the refunds land, or report the cards stolen. Each dispute brings a fee and counts toward the store’s fraud and dispute ratios. The processor places a temporary reserve on payouts while it reviews the account.

None of these orders produced a sale. The total bill, in fees, staff time and frozen cash flow, can run to thousands of dollars.

What to Do During an Active Attack

If you catch an attack in progress, speed matters more than perfection.

1. Turn on stricter rules immediately: CAPTCHA on checkout, lower velocity limits and blocking of the IP ranges or countries involved.
2. Temporarily raise the minimum order amount or disable guest checkout if the attack targets low-value products.
3. Rotate your API keys if there is any sign the bot is calling your payment API directly.
4. Contact your processor. Tell them you are under attack; they may apply network-level blocks and will note that you responded quickly.
5. Refund approved test payments before cardholders dispute them, so they do not become chargebacks.
6. Keep records of what happened and when, in case the processor or a card network asks.

After the attack, review which control would have stopped it earliest, and make that control permanent.

How to Stop Card Testing

No single setting stops every attack. The most effective approach layers controls before the payment and monitoring after it.

Before the payment reaches the card network

1. Add bot protection and CAPTCHA on checkout, sign-up and “add payment method” forms, ideally invisible or risk-based so real customers are not slowed down.
2. Set velocity limits per IP address, device, email and card: for example, block more than three failed attempts from one device in ten minutes.
3. Require CVV and address verification on every card-not-present payment, and decline mismatches.
4. Raise minimum order values where it makes sense, since testers favor tiny amounts.
5. Disable or protect $0 authorizations and card-saving flows you do not need.
6. Protect your API. Many attacks bypass the checkout page and call the payment endpoint directly. Use secret keys correctly, require authentication, and rate-limit requests.
7. Watch donation and free-trial pages, which are frequent targets because small amounts look normal there.

After the payment

1. Monitor decline rates in real time and alert someone when they jump.
2. Refund and block quickly when you confirm an attack, before the real cardholders notice and dispute.
3. Use your processor’s fraud tools, such as machine-learning risk scoring, and review their rules after every incident.

Platform-Specific Tips

Where attacks come in depends on how your checkout is built.

WooCommerce and WordPress. Fraudsters frequently target the “add payment method” page in the customer account area, which can validate a card without placing an order. If you do not need saved cards, disable that feature. Add a CAPTCHA or bot-protection plugin to checkout, registration and donation forms, and rate-limit requests to the checkout endpoints. Donation plugins are a common target because $1 gifts look normal.

Shopify. Shopify includes bot protection on checkout and your payment provider runs its own fraud screening, which blocks much of the volume. Watch for spikes in abandoned checkouts and failed payments, and review fraud analysis on suspicious orders before fulfilling them.

Custom checkouts and APIs. If you built your own checkout on a payment provider’s API, make sure card details are tokenized in the browser and that your server does not create unlimited payment attempts on demand. Require a logged-in session or a server-side challenge before creating a payment, cap attempts per session, and never expose secret keys in front-end code.

Free trials and $0 authorizations. If you verify cards at signup for a free trial, you are offering exactly what testers want. Add bot protection to the signup flow and consider requiring email verification before the card step.

Does 3D Secure Stop Card Testing?

3D Secure (3DS) is the authentication step where the card issuer asks the cardholder to confirm a payment, usually in their banking app or with a one-time code. It helps, but it is not a complete answer.

Use 3DS for higher-risk payments and combine it with bot protection and velocity limits. Applied everywhere without risk scoring, it adds friction and can reduce conversion for genuine customers.

Checkouts That Cannot Be Card-Tested

Card testing depends on one thing: a form that accepts a card number and tells the fraudster whether it works. Payment methods without card numbers give the attacker nothing to test.

With crypto, the customer sends funds from a wallet they control. There is no card number, no CVV and no authorization request for a bot to submit. A fraudster cannot use your checkout to validate stolen wallets, because a crypto payment either arrives on the blockchain or it does not. There are no per-attempt fees and no enumeration ratio.

That makes a crypto option especially useful on the pages fraudsters target most: small-ticket digital products, donation pages, top-ups and international orders. Plugins for platforms such as WooCommerce let you add it alongside cards without changing the rest of your checkout. Bcon Global routes each payment straight to your own wallet for a flat 1% fee and, as a no-KYC crypto gateway, adds no sign-up friction for your customers.

If card testing also left you with disputes, our explainer on what a chargeback is covers how to handle them and keep your ratio under control.

Card testing turns your checkout into free infrastructure for fraudsters, and the card networks bill you for the damage through fees, chargebacks and monitoring programs. The fix is a layered defense: bot protection, velocity limits, CVV and address checks, API security and fast monitoring.

Those controls protect your card payments. For the pages and markets where attacks keep coming back, adding a payment method without card numbers removes the target entirely, while still giving genuine customers a fast way to pay.