What card testing is and why it matters to your business
Card testing is when someone uses stolen or randomly generated card numbers to make small purchases—often just a few dollars—to see which ones work. They're not trying to steal large amounts in a single transaction. Instead, they're testing whether the card is active and what your payment system will accept, so they can sell that information or use it for bigger fraud later.
For your business, card testing creates two when ready problems. First, you absorb the cost of processing those small transactions, plus chargeback fees when the real cardholder disputes them. Second, a sudden spike in card testing attempts can trigger your payment processor to flag your account as high-risk, which can slow down legitimate sales or increase your processing fees.
The good news is that card testing has recognizable patterns. Unlike random customer purchases, testing attempts cluster in time, use different cards but similar amounts, and often come from automated systems. You can build detection into your payment flow to catch these patterns before they become a problem.
Key Takeaways
- Card testing uses small transactions to verify stolen card numbers, and you pay the chargeback fees when the real cardholder disputes them.
- Detection works by watching for patterns—multiple failed transactions in short time, same dollar amounts across different cards, or transactions from the same IP address or device.
- The simplest approach is to decline transactions that fail verification checks (like CVV mismatch or address mismatch) rather than retrying them automatically.
- Your payment processor and fraud detection service can flag suspicious activity automatically, but you should also set your own rules based on your business type and customer base.
- Blocking card testing early reduces chargebacks, protects your processor relationship, and prevents criminals from confirming stolen cards through your system.
Recognizing the patterns that signal card testing
Card testing attempts follow predictable patterns because they're usually automated. The first sign is a cluster of failed transactions in a short window—sometimes dozens in an hour. A legitimate customer might try a card twice if it fails; a testing bot tries fifty different cards in ten minutes.
The second pattern is consistency in the transaction amount. Testers often use the same small dollar value ($0.99, $1.00, $2.00) across many different card numbers. A real customer buys different things at different prices. If you see the same amount charged repeatedly to different cards in a short period, that's a red flag.
The third pattern is the source. Multiple transactions from the same IP address, the same device fingerprint, or the same email domain—but using different card numbers—suggests automation rather than a customer with a legitimate reason to try multiple cards. Geographic mismatches also matter: a transaction from a card issued in Japan, processed from an IP in Nigeria, being shipped to an address in Ohio warrants closer inspection.
Setting up basic checks before payment processing
The simplest detection happens before you even send the card to your processor. Require the cardholder to provide the CVV (the three-digit security code on the back), the billing ZIP code, and ideally the full billing address. These details are not stored on the card's magnetic stripe, so a stolen card number alone won't have them.
When the cardholder enters these details, your payment processor checks them against the card issuer's records. If the CVV doesn't match, the ZIP code doesn't match, or the address doesn't match, the transaction fails. A legitimate customer will correct the information and retry. A testing bot cannot, because it doesn't have the real details—it only has the card number.
The key rule: do not retry failed transactions automatically. If a transaction fails verification, decline it and ask the customer to re-enter their information. If it fails again, decline it again. Do not keep trying in the background. Testers rely on systems that auto-retry, because each retry gives them data about what the system will accept.
Monitoring transaction velocity and patterns
Velocity rules track how many transactions happen in a given time window. Set a threshold based on your business: if you're a coffee shop, maybe you expect 100 transactions per hour during lunch. If you're a software company, maybe you expect 10 per hour. Anything significantly above your normal pattern warrants a pause.
Within that velocity rule, add a sub-rule for failed transactions specifically. If you see more than three failed transactions from the same IP address in five minutes, or more than five failed transactions using the same billing ZIP code in ten minutes, flag the account and require additional verification before processing the next transaction.
You can also set rules based on the transaction amount. If your average order is $25 but you suddenly see twenty $1 transactions from different cards in the same hour, that's testing. Some payment processors let you set a rule that says "if more than X transactions under $Y occur in Z minutes, hold them for review."
Using your payment processor's built-in fraud tools
Your payment processor (Stripe, Square, PayPal, or your bank's processor) already has card testing detection built in. They see patterns across millions of transactions, so they can spot testing attempts faster than you can. Most processors flag suspicious transactions automatically and either decline them or hold them for review.
Check your processor's dashboard for fraud settings. Stripe calls this "Radar"; Square has "Advanced Fraud Tools"; PayPal has "Seller Protection." Each one lets you set sensitivity levels. A higher sensitivity catches more potential fraud but may also decline some legitimate transactions. A lower sensitivity lets more transactions through but misses some testing.
Start with your processor's default settings, then adjust based on what you see in your transaction history. If you're declining too many legitimate customers, lower the sensitivity. If you're seeing chargebacks from card testing, raise it. Your processor also sends you alerts when it detects suspicious patterns, so read those emails—they often tell you exactly what triggered the flag.
Adding a third-party fraud detection service
If your payment volume is high or you operate in a high-risk category (digital goods, high-ticket items, or subscription services are common targets), consider adding a dedicated fraud detection service. Services like Kount, Sift, or Forter integrate into your payment flow and analyze dozens of signals—device fingerprinting, geolocation, email reputation, phone number validation, and behavioral patterns.
These services cost money (usually a percentage of transactions or a monthly fee), so they make sense if chargebacks are already costing you more than the service would. They're also useful if your processor's built-in tools aren't catching the testing attempts you're seeing.
When you add a third-party service, it sits between your checkout and your processor. It scores each transaction as low-risk, medium-risk, or high-risk. You decide what to do with each score: auto-approve low-risk, auto-decline high-risk, or send medium-risk to manual review. This gives you more control than relying on your processor alone.
Responding to card testing when you detect it
If you detect a card testing attempt in real time, decline the transaction when ready. Do not process it, do not hold it for later, do not contact the customer. The person entering the card is not the cardholder—they're a criminal testing stolen information.
After you decline it, you have two options. The first is to block the IP address, email address, or device from making further purchases for a set period (24 hours, 7 days, or permanently). This stops the bot from continuing to test cards through your system. The second is to flag the account for manual review if the same source tries again.
If you see a pattern of testing attempts, report it to your payment processor. Most processors have a fraud reporting channel in their dashboard. Reporting helps them improve their detection and protects other merchants from the same attacker. You should also check whether your processor has already flagged the activity—they often catch it before you do and will tell you in your account alerts.
Balancing fraud prevention with customer experience
The risk of aggressive fraud detection is that you'll decline legitimate transactions and frustrate real customers. A customer traveling internationally, a new customer with a different billing address, or someone using a gift card might all trigger your fraud rules.
To balance this, use tiered responses. For low-risk transactions, process them normally. For medium-risk transactions, ask for additional verification—a one-time password sent to their email, a phone call, or a CAPTCHA. For high-risk transactions, decline and ask the customer to contact you directly. This way, you catch testing attempts without blocking legitimate sales.
You should also whitelist known good sources. If a customer has made five successful purchases from the same IP address and email, lower their risk score. If a corporate account always orders from the same office network, whitelist that network. This reduces false positives and keeps your fraud detection from becoming a barrier to sales.
Frequently Asked Questions
What's the difference between card testing and a legitimate customer retrying a failed card?
A legitimate customer retries once or twice with the same card, then either uses a different card or contacts you. A testing bot tries many different card numbers in rapid succession. If you see the same dollar amount charged to ten different cards in five minutes, that's testing. If you see one customer retry the same card twice, that's normal.
Should I block all transactions under a certain amount?
No. Many legitimate customers make small purchases. Instead, block patterns: multiple small transactions from the same source in a short time, or the same small amount repeated across different cards. A single $1 transaction is fine. Fifty $1 transactions in an hour is testing.
Can I detect card testing without a third-party service?
Yes. Your payment processor's built-in fraud tools catch most testing. You can also set your own rules: require CVV and address verification, decline failed transactions instead of retrying, and watch for velocity spikes. A third-party service adds more sophistication but isn't necessary for most businesses.
What happens if I decline a card testing transaction?
The transaction fails and the cardholder (the criminal) sees a decline message. They move on to test your system with a different card or test a different merchant. You don't process the transaction, so you don't pay a chargeback fee. The real cardholder never sees it because the transaction never went through.
Do I need to contact the cardholder if their card was used for testing?
No. The card was tested through your system, but you declined it, so no charge went through. The cardholder won't see anything on their statement. If you're concerned, you can report the card number to your processor, and they may contact the issuing bank, but that's the processor's job, not yours.