Stopping automated card testing attacks on Stripe requires deploying layered velocity rules and selective 3D Secure friction rather than broad geographic blocking that hurts conversion. Card testing occurs when fraudsters write automated scripts to test stolen credit card numbers across merchant checkouts. Because Stripe charges standard card authorization fees ($0.05 to $0.15 per attempt) regardless of whether a transaction succeeds or fails, an unmitigated bot attack testing 20,000 numbers overnight can generate thousands of dollars in surprise gateway fees and trigger account suspension under Visa’s Acquirer Monitoring Program (VAMP).
Default Stripe Radar machine learning catches obvious fraud, but high-speed card testing scripts exploit low-friction checkout flows (such as donations, $1 digital samples, or free trials with authorization holds) faster than standard algorithms adapt. To protect your business, you must implement custom Radar for Fraud Teams rules combined with frontend rate-limiting and Cloudflare Turnstile. This guide outlines 5 battle-tested Radar rule formulas that eliminate automated carding without rejecting legitimate paying customers.
Key Takeaways: Stopping Card Testing Attacks
- Authorization Fees Add Up: Even failed authorization attempts incur Stripe network fees. A sustained bot attack of 10,000 attempts costs $500+ in raw processing fees within hours.
- Selective 3D Secure (3DS): Instead of blocking suspicious transactions outright, force 3DS authentication. Bots fail 3DS immediately, while legitimate customers easily verify via SMS or banking apps.
- IP and Device Velocity Limits: Legitimate shoppers rarely attempt more than 2 card transactions within 10 minutes. Hard-limiting card attempts per IP address stops bot scripts cold.
- Frontend Bot Defense: Combining Radar rules with Cloudflare Turnstile or reCAPTCHA v3 stops automated scripts before they hit Stripe’s API endpoints.
The True Costs of an Unmitigated Carding Attack
| Impact Category | Financial & Operational Damage |
|---|---|
| Gateway Authorization Fees | Stripe charges $0.05 – $0.15 per authorization attempt, successful or declined. 25,000 bot requests = $1,250+ in unrecoverable fees. |
| Card Brand Fines (Visa VAMP) | Dispute and fraud ratios exceeding 1.5% place merchants into Visa/Mastercard monitoring programs, incurring $5,000+/mo compliance fines. |
| Payment Gateway Suspension | Stripe risk teams will pause account payouts or close accounts completely if carding spikes threaten acquiring bank standing. |
| Legitimate User Drop-off | Overly aggressive blocking rules reject valid customers, permanently damaging checkout conversion rates. |
5 Essential Stripe Radar Rules for Fraud Teams
To use custom rules, your account must have Radar for Fraud Teams enabled ($0.02 per screened transaction or waived on certain plan volumes). Navigate to Stripe Dashboard > Radar > Rules and add the following formulas:
Rule 1: Block High-Velocity Carding from a Single IP Address
Bots frequently execute dozens of payment attempts through a single residential proxy or compromised server. Block any IP attempting more than 3 distinct cards within 1 hour:
Block if :count(:ip_address, 1h) > 5 and :declined_count(:ip_address, 1h) > 2Why it works: Legitimate customers might mistype their expiration date once or twice. If an IP fails 2 payments and tries 5 total times within an hour, it is almost certainly an automated script.
Rule 2: Trigger 3D Secure on Elevated Risk Scores
Instead of outright blocking borderline transactions and losing sales, dynamically request 3D Secure authentication when Stripe’s machine-learning risk score indicates elevated risk:
Request 3D Secure if :risk_score: > 40 and not :is_3d_secure:Why it works: Automated carding bots cannot solve dynamic banking one-time passwords (OTP). When 3DS challenges are presented, bot attacks fail instantly without generating a dispute.
Rule 3: Block When CVC and Zip/Postal Code Both Fail Verification
Stolen card lists dumped on darknet forums often lack correct billing ZIP codes and CVV security codes. Block transactions where both fail verification:
Block if :cvc_check: == 'fail' and :address_zip_check: == 'fail'Why it works: While a typo can cause a single mismatch, a simultaneous failure on both security markers indicates an unauthorized card number test.
Rule 4: Velocity Limits on Card Number Reuse Across Multiple IPs
Sophisticated bot networks rotate proxy IPs for every request to bypass simple IP rate-limiting. Counter this by tracking velocity on the card fingerprint itself:
Block if :count(:card_fingerprint, 24h) > 4 and :declined_count(:card_fingerprint, 24h) > 2Why it works: Prevents fraudsters from repeatedly attempting variations of billing details on the same card number across rotating proxy pools.
Rule 5: Force 3DS on Anonymous Proxy and Tor Connections
Legitimate e-commerce shoppers rarely route purchases through Tor exit nodes or anonymous commercial proxies:
Request 3D Secure if :is_anonymous_proxy: == true or :is_tor: == trueWhy it works: Adds zero friction to standard customers, while forcing automated attackers using Tor to pass banking verification.
Frontend Defense: Cloudflare Turnstile & API Throttling
Radar rules protect your backend, but you should also stop bots from invoking your checkout page in the first place:
- Cloudflare Turnstile: Implement Cloudflare’s non-interactive Turnstile challenge on your checkout form. Unlike legacy reCAPTCHA, Turnstile solves silently in the background for real humans without puzzle friction.
- Backend Endpoint Rate-Limiting: If using custom Stripe Elements, throttle your
/create-payment-intentendpoint at the server level (e.g., using Redis) to a maximum of 5 requests per IP per minute. - Remove $0.00 / Low-Value Open Inputs: Never host completely open donation fields with $0.50 minimums without mandatory email verification and CAPTCHA. Low-value open fields are the #1 target for script testing.
Emergency Checklist: What to Do During an Active Attack
- Temporarily Raise Radar Sensitivity: Navigate to Radar > Settings and adjust the automated block threshold from 75 down to 60 for 24 hours.
- Enable Mandatory CAPTCHA: Turn on Turnstile or reCAPTCHA immediately on all checkout forms.
- Refund Unsettled Fraudulent Charges: Filter by authorization date and issue full refunds for approved test transactions before settlement. Refunding within hours prevents cardholders from initiating formal chargebacks and saves dispute fees.
- Compare Alternative Gateways: For merchants with unique risk profiles or specialized multi-currency needs, review our best payment processing software guide and Authorize.net review.
Frequently Asked Questions
Why does Stripe charge fees on declined card testing transactions?
Card networks (Visa, Mastercard, Amex) bill payment processors for every authorization request sent through their network switch, regardless of outcome. Stripe passes this cost along to merchants to discourage unmonitored checkout abuse.
Does enabling 3D Secure shift chargeback liability away from my business?
Yes. When a customer successfully passes a 3D Secure challenge and the transaction is authorized, liability for fraudulent “unauthorized transaction” (reason code 10.4) chargebacks shifts from the merchant to the card-issuing bank.
Will adding custom Radar rules lower my store’s conversion rate?
Not if you prioritize Request 3D Secure rules over Block rules. Triggering 3DS only presents an extra confirmation screen to suspicious traffic, allowing 100% of legitimate customers to complete their purchase safely.
