Picture this: 400 failed orders in your WooCommerce dashboard over 2 hours. Hundreds of $1 and $2 orders. All failed. Different card numbers. Different names. Same IP range. Same checkout pattern. Every order attempted within seconds of the last.
That’s a card testing attack.
And every single one of those failed transactions costs real money.
What Card Testing Actually Is
Here’s how it works. Criminals steal credit card numbers in bulk. Thousands at a time. They don’t know which cards are still active, which have spending limits, which have been cancelled. So they need to test them.
Your WooCommerce checkout is the test.
Bots hit your checkout with stolen card numbers, one after another. Small amounts. $1. $2. $4.99. If the charge goes through, they know the card is live. They take that card and go make a $3,000 purchase somewhere else.
Your store is just the testing ground. You’re not the target. You’re the tool.
The bots don’t care about your products. They don’t browse. They don’t add items to a cart. They POST directly to your checkout page, or hit the Store API checkout endpoint if you’re running block-based checkout, and fire off hundreds of transactions in minutes.
What It Actually Costs You
This is where most store owners get blindsided. They see 400 failed orders and think, “Well, they all failed. No harm done.”
Wrong.
Every failed transaction that touches your payment processor costs you money. Stripe charges around $0.15 to $0.25 per declined transaction. PayPal doesn’t charge per decline, but it’s watching. Multiply 400 Stripe declines over 2 hours and you’re looking at $60 to $100 in fees for an attack you didn’t even know was happening.
And that’s the minor cost.
The real danger is your account getting flagged or frozen. Both Stripe and PayPal track your decline rate and dispute ratio. Stripe can freeze your account for review if your decline ratio spikes. PayPal is even more aggressive. They’ll slap account limitations on you with almost no warning, hold your funds for up to 180 days, and their appeals process is notoriously slow.
I’ve seen more WooCommerce stores get burned by PayPal holds than Stripe freezes. PayPal’s fraud filters are blunter, and when they decide you’re a risk, they lock first and ask questions later. A store doing $50K a month that loses payment processing for 10 days is looking at roughly $16,000 in lost revenue. From an attack they didn’t cause.
There’s also the chargeback risk. If a few of those test transactions actually succeed (because the stolen card happened to be active), you’ll get chargebacks or PayPal disputes within weeks. Stripe chargebacks cost $15 per dispute. PayPal charges $20 or more, and they tend to side with the buyer. You lose the product, the revenue, and the fee. Stack enough disputes and your processor puts you on a monitoring program. Or drops you entirely.
How to Know You’re Being Attacked
Most store owners don’t realize they’re being card tested until the damage is done. They see a pile of failed orders in WooCommerce and assume it’s normal checkout friction. Customers fat-fingering their card numbers, expired cards, insufficient funds.
But card testing has a pattern. Once you know what to look for, it’s obvious.
Rapid-fire failed transactions. 10, 20, 50 failed orders in a few minutes. Normal checkout failures trickle in. Card testing comes in waves.
Small, identical order amounts. Bots often test with the cheapest product on your site, or they try to process a specific dollar amount. Seeing dozens of $1.00 orders is a dead giveaway.
Nonsense customer data. Fake names, random strings as email addresses, addresses that don’t match any real location. The bots generate fake customer data because they don’t need it to be real. They just need the card number field.
Same IP range or geolocation cluster. Bots often operate from the same data center or VPN endpoint. If you see 50 failed orders all originating from the same /24 IP block, that’s not customers. That’s a bot farm.
This is where monitoring matters. If you’re watching transaction patterns and decline rates in real time, you catch attacks in minutes instead of hours. Stripe and PayPal both have dashboards that show activity spikes, and Fraud Guard logs every blocked attempt so you can see the attack developing before your processor flags it.
Layer 1: Block Before Checkout
The best way to stop card testing is to prevent the bot from ever reaching your payment processor. Every transaction that hits your gateway costs you money (or at minimum, risk), even if it fails. So you need to block suspicious activity before the charge attempt.
IP geolocation checks. If your store only ships to the US and Canada, there’s no reason to allow checkout attempts from IP addresses in Eastern Europe or Southeast Asia. Geolocation blocking isn’t perfect (VPNs exist), but it catches the low-effort bots that don’t bother masking their location.
Velocity rate limiting. This is the single most effective defense. Set a limit on how many checkout attempts one IP address can make in a given time window. 3 attempts in 10 minutes is reasonable. 50 attempts in 2 minutes is a bot. Rate limiting stops the volume attack that makes card testing profitable.
Minimum order thresholds. Card testers use small amounts to minimize risk. If your cheapest product is $25, set a minimum order threshold. Any attempt to process an order below that threshold gets rejected before it touches your payment gateway. This alone kills most card testing.
Suspicious email detection. Bots use disposable email addresses. Mailinator, Guerrilla Mail, TempMail, and hundreds of others. Flag or block checkout attempts using known disposable email domains. Also watch for emails that are obviously generated: random strings, no real name patterns, domains registered yesterday.
Refinery Fraud Guard handles all 4 of these checks. IP geolocation, velocity rate limiting, minimum order amounts, and suspicious email detection. It runs pre-checkout, meaning it blocks the attempt before your payment processor ever sees it. No processor fee. No declined transaction on your record.
Layer 2: VPN and Proxy Detection
About 60% of card testing attacks route through VPNs or proxy servers. The attackers know that their real IP address (often from a compromised server or botnet) would get flagged immediately. So they mask it.
VPN detection isn’t about blocking every VPN user. Plenty of legitimate customers use VPNs for privacy. The approach is smarter than a blanket block.
You flag VPN traffic, then combine that signal with other risk indicators. A VPN IP address making one purchase with a valid US shipping address and a real email? Probably fine. A VPN IP address making 15 checkout attempts in 3 minutes with different card numbers and random email addresses? Block it.
Fraud Guard’s VPN and proxy detection works as a risk signal, not a hard block. It adds weight to the fraud score. Combined with velocity checks and email analysis, VPN detection catches the attacks that IP geolocation alone misses.
Layer 3: The Blocklist
Once you’ve identified a bad actor, you don’t want them coming back.
A pre-checkout blocklist lets you permanently ban specific IP addresses, IP ranges, email addresses, and email domains. When a card testing attack happens, you add the source IPs and email patterns to the blocklist. Future attempts from those sources get rejected instantly, before they even load the checkout page.
This is especially important for repeat attacks. Card testers often come back to stores that were easy targets. If you blocked them once, they’ll try again from a slightly different IP range or with a different email pattern. A well-maintained blocklist accumulates intelligence over time.
Fraud Guard’s blocklist works at the pre-checkout level. It’s not waiting for the order to be placed. It checks against the blocklist the moment the checkout request comes in. The bot never sees a payment form.
Layer 4: Monitoring and Alerts
Defense without visibility is just hoping. You need to know when an attack starts, how big it is, and whether your defenses held.
Set up monitoring that tracks:
- Failed transaction rate over time (baseline vs. spike)
- Blocked attempts per hour (so you know your defenses are working)
- New IPs hitting your checkout at unusual volumes
- Decline rate percentage (the metric your payment processor watches)
When your failed transaction rate spikes 5x above baseline in a 15-minute window, you should get an alert. Not tomorrow. Not in your weekly report. Right then.
Fraud Guard gives you this visibility. It logs every blocked attempt with IP, email, and reason. Combine that with your processor’s own monitoring (Stripe’s dashboard or PayPal’s Resolution Center) and you’ll see attacks developing in real time instead of finding out a week later.
And when a card testing attack does create support tickets (customers seeing weird charges, confused about failed orders), Refinery CRM lets you flag those customer profiles and track fraud-related tickets separately from normal support. This matters when you need to report an attack to your payment processor. Having documentation of the incident, the timeline, and the customer impact makes the conversation with Stripe or PayPal much smoother. Especially PayPal, where you’ll need every piece of evidence you can get to lift an account limitation.
Layer 5: Payment Gateway Settings
Your WooCommerce fraud defenses are the front line. But configure your payment gateway as a second layer.
If you’re on Stripe:
Enable Stripe Radar. Radar is Stripe’s built-in fraud detection. The default rules catch some automated attacks. You can add custom rules (block transactions under $5 from new customers, require 3D Secure for international cards, etc.). The custom rules are where Radar earns its keep. Default Radar alone won’t stop a determined card testing bot.
Enable 3D Secure for high-risk transactions. 3D Secure adds an authentication step (like a bank text verification code). It adds friction for legitimate buyers, so use it selectively. High-risk signals: new customer, international IP, VPN detected, order above a threshold.
If you’re on PayPal:
Enable PayPal’s Fraud Protection. In your PayPal business account, go to Account Settings and turn on Fraud Protection. Set up filters for transaction amount limits, maximum number of transactions per time period, and geographic restrictions. These filters are blunter than Stripe Radar, but they’re better than nothing.
Block guest checkout for high-risk signals. PayPal guest checkout (where buyers enter card details without a PayPal account) is the most common vector for card testing through PayPal. If you’re getting hit, consider requiring a PayPal account for checkout temporarily. It kills most bot traffic immediately.
For both gateways:
Enable address verification (AVS). AVS checks whether the billing address provided matches what the card issuer has on file. Bots using stolen card numbers rarely have the correct billing address. AVS won’t stop every attack, but it adds friction that slows automated testing.
Enable CVC verification. Require the 3-digit card security code. Some card testing bots only have the card number. Requiring the CVC eliminates those attempts.
The Defense Stack, Ranked
If you’re starting from zero, prioritize in this order:
- Velocity rate limiting. Stops the volume that makes card testing work. This alone blocks 70%+ of attacks.
- Minimum order thresholds. Eliminates small-amount testing. Takes 2 minutes to configure.
- Suspicious email blocking. Cuts out disposable email addresses. Removes most bot identities.
- IP geolocation checks. Blocks traffic from regions you don’t serve. Broad but effective.
- VPN/proxy detection. Catches masked attackers that get past geolocation.
- Pre-checkout blocklist. Builds long-term defense against repeat attackers.
- Payment gateway hardening. Stripe Radar or PayPal Fraud Protection, AVS, CVC, 3D Secure as your second layer.
- Real-time monitoring and alerts. Know when attacks happen. Track your decline rate.
You don’t need all 8 on day one. Start with the first 3. They’ll handle most attacks. Add the rest as you scale.
The Cost of Doing Nothing
I’ll be direct. If you run a WooCommerce store and you haven’t thought about card testing, you’re exposed right now.
Card testing attacks are increasing year over year. Bots are getting better. Stolen card databases are getting bigger. The attacks are automated, cheap to run, and they target the path of least resistance.
WooCommerce stores are a common target because the platform is open, the checkout endpoints are accessible, and most stores run default checkout configurations with zero fraud prevention.
Here’s a realistic scenario: a 6-hour attack before anyone notices. 1,200 failed transactions. On Stripe, that’s about $200 in processor fees and an account under review for 8 days. On PayPal, that’s an account limitation with your funds held while you submit documentation and wait for a human to review it. Neither is fun.
That’s actually getting off easy. Some stores see card testing attacks run for days before anyone notices. By then, the decline rate is so high that the payment processor suspends the account entirely.
The fix isn’t complicated. It’s a few layers of detection and blocking, configured once, running automatically. The tools exist. You just have to set them up before the bots find you.
Because they will find you. The question is whether you’re ready when they do.
If you’re running a WooCommerce store and want a professional team to audit your full revenue optimization stack (including fraud prevention), that’s worth doing. Same goes for ongoing site operations and security if you don’t want to manage this yourself. And if you’re running subscriptions, make sure your retention systems aren’t leaking revenue through failed payments on the other side of the equation.
But the fraud protection layer? That you can set up today.