Card testing happens in your payment flow, and you need to stop it before the transaction settles

Card testing is when someone runs small charges—usually $0.50 to $2—through your payment system to see if a stolen card works. They're not trying to buy anything. They're validating the card for resale or for larger fraud later. If you process thousands of transactions, card testers will find you, and each test that succeeds costs you a chargeback fee, a decline fee, or both.

Detection means catching the pattern before it becomes a problem: multiple small charges from different cards in a short window, charges that fail then succeed with slight variations, or charges that come from the same device or IP address but different card numbers. The earlier you stop it—ideally before the transaction clears—the less you pay.

Most payment processors offer some detection built in. But if you're running volume or operating in a high-risk category (digital goods, travel, subscription services), you need to layer detection into your own checkout flow and monitor what's happening after the fact.

Key Takeaways

  • Card testing costs you money through chargebacks and processor fees even when the charge is small, so prevention is cheaper than cleanup.
  • Detection works by flagging patterns—multiple small charges, rapid retries, same device with different cards—not by blocking individual transactions.
  • Your payment processor likely has built-in detection, but you should also monitor your own transaction logs for patterns they might miss.
  • The fastest way to reduce testing is to require CVV verification, add friction to checkout (CAPTCHA, email confirmation), and decline cards that fail multiple times in quick succession.
  • If you see a spike in small failed charges, contact your processor immediately; they can often pause your account to prevent further testing.

Where card testing happens in your payment flow

Card testing typically occurs at three points: during checkout (if you allow guest purchases without verification), during a free trial signup (where the card is tested but no charge is intended), or through your API if you accept direct card submissions. The tester runs the card, gets a response code, and moves on. If the charge succeeds, they know the card is live. If it fails, they try again with a different card.

The damage compounds because each attempt—whether it succeeds or fails—generates a transaction record, a processor fee, and potentially a chargeback if the cardholder disputes it later. A single tester running 50 cards through your system can cost you $50 to $200 in fees alone, before chargebacks arrive weeks later.

Detection needs to happen at the moment of transaction, not after. Your processor's gateway can decline a card in real time. Your own system can flag the pattern and stop accepting new attempts from that source. The goal is to make your checkout uneconomical for testing.

Use your processor's built-in detection tools

Stripe, Square, Adyen, and other major processors include fraud detection that flags card testing patterns automatically. Stripe's radar system, for example, watches for velocity (how many charges in how short a time), geographic mismatches, and device fingerprinting. Square's fraud tools decline suspicious transactions before they settle. These systems are not perfect, but they catch the majority of obvious testing.

Check your processor's dashboard for fraud settings. Most allow you to set a velocity limit—a rule that declines a card after N failed attempts in M minutes. A common setting is 3 failed attempts in 15 minutes. You can also enable 3D Secure (also called Strong Customer Authentication or SCA), which requires the cardholder to verify their identity through their bank. This adds friction that deters testers.

Ask your processor whether they offer chargeback protection or chargeback insurance. Some cover a portion of chargeback fees if you meet certain fraud prevention standards. This doesn't stop testing, but it reduces the financial impact.

Add friction to your checkout to discourage testing

Testers want speed. They run hundreds of cards through multiple merchants in an hour. If your checkout takes 30 seconds and requires email confirmation, CAPTCHA, or phone verification, they'll move to an easier target. You don't need to make checkout painful for legitimate customers—just enough to make testing uneconomical.

Common friction points that work:

  • Require CVV (the three-digit code on the back of the card). Testers often don't have this for stolen cards.
  • Add a CAPTCHA or similar bot check before payment processing.
  • Send a confirmation email and require the customer to click a link before the charge goes through.
  • For free trials, require a valid card but don't charge immediately; charge only when the trial ends.
  • Use address verification (AVS), which checks that the billing address matches the card issuer's records.

If you're seeing a spike in testing, you can temporarily increase friction—add a CAPTCHA, require phone verification, or move to 3D Secure for all transactions—then dial it back once the spike ends.

Monitor your transaction logs for testing patterns

Your processor's dashboard shows you what's happening, but you should also pull your own transaction data and look for patterns. Export your failed transactions for the last 30 days and sort by:

  • Charge amount (testers cluster around $0.50 to $2)
  • Decline reason (look for "insufficient funds" or "card declined" repeated many times)
  • Time window (testing often happens in bursts—dozens of attempts in an hour)
  • Device or IP address (multiple different cards from the same source)
  • Geographic mismatch (card issued in one country, IP address in another)

If you see 20+ failed charges in an hour, all under $2, all from different card numbers but the same IP address or device, you're being tested. Contact your processor immediately and ask them to review the pattern. Many processors can pause your account temporarily to prevent further testing, then resume once the spike ends.

Tools like Splunk, Datadog, or even a custom script can automate this monitoring. Set an alert that fires if you see more than 10 failed charges in 10 minutes. The faster you catch it, the less damage it does.

Decline cards that fail multiple times, and block repeat offenders

Your payment gateway can be configured to decline a card automatically after a set number of failures. This is called velocity-based decline or retry limiting. A typical rule: decline any card that fails 3 times in 15 minutes, or 5 times in an hour.

Beyond the card itself, you can block the source: the IP address, the device fingerprint, or the email address. If the same IP address tries 50 different cards in an hour, block that IP for 24 hours. If the same device fingerprint appears with 20 different card numbers, flag it for manual review or decline all future attempts from that device.

Be careful not to block legitimate customers. A customer retrying a card because they mistyped the number should not be permanently blocked. But a pattern of 30 different cards from the same IP in 30 minutes is clearly testing, and blocking it is justified.

What to do if you're being actively tested right now

If you notice a spike in small failed charges or see the pattern described above, take these steps in order:

  1. Log into your processor's dashboard and check the fraud settings. Enable velocity limits if they're not already on. Set the limit to 3 failed attempts in 10 minutes.
  2. Enable 3D Secure or Strong Customer Authentication if your processor offers it. This will decline most testing attempts because testers don't have the cardholder's authentication credentials.
  3. Add a CAPTCHA to your checkout if you don't have one already. This stops automated testing scripts.
  4. Pull your transaction logs and confirm the pattern. Look for the IP address, device, or email address that appears most often in the failed charges.
  5. Contact your processor's fraud team. Provide them with the time window, the IP addresses, and the card numbers involved. Ask them to review the pattern and take action on their end.
  6. If the testing continues, consider temporarily blocking the IP addresses or requiring phone verification for all transactions.

Most testing spikes last a few hours or a day. Once the tester moves to another merchant, the activity stops. Your processor's detection usually catches the bulk of it, but your own monitoring and quick response can prevent the worst cases.

Frequently Asked Questions

Do I have to pay for every card test that goes through?

You pay a processing fee for every transaction attempt, whether it succeeds or fails. If a charge succeeds and the cardholder disputes it later, you also pay a chargeback fee (usually $15 to $100). If a charge fails, you pay only the processing fee, which is typically $0.10 to $0.30 per attempt. A tester running 50 cards costs you $5 to $15 in processing fees, plus chargebacks if any succeed.

Can I block all international cards to stop testing?

You can, but it also blocks legitimate international customers. A better approach is to require 3D Secure for international transactions, which adds verification without blocking the sale. If you're seeing testing from a specific country, you can block that country temporarily, but most testing comes from the same countries as your legitimate customers.

What's the difference between card testing and a data breach?

Card testing is when someone runs stolen card numbers through your checkout to see if they work. A data breach is when someone steals card numbers from your system. Testing uses cards stolen elsewhere; a breach creates new stolen cards. If you're seeing testing, it doesn't mean your system was breached—it means your checkout is accessible to testers.

Will requiring CVV stop all card testing?

No, but it stops most. Testers often don't have the CVV for stolen cards, so requiring it eliminates a large portion of attempts. Some testers do have full card data including CVV, so you still need velocity limits and other detection. CVV is one layer, not a complete solution.

How long does it take to see results after I enable fraud detection?

Velocity limits and 3D Secure take effect immediately—the next transaction attempt will be subject to the new rules. Chargeback protection and processor-side detection may take a few days to show results because chargebacks arrive weeks after the original charge. You should see a drop in failed transaction attempts within hours of enabling velocity limits.