Card Testing Attacks Don't Just Cost You Fees. They Cost You Customers.

A Weekend Attack. Six Weeks of Lost Revenue.

A mid-market D2C merchant processing $2M per month on Stripe gets hit on a Saturday night. Bots run 3,000 stolen card numbers through the checkout in small amounts. By Sunday morning the attack is over, and the $900 in processing fees feels manageable.

Then the real damage starts. Card testing activity has jumped 65% between Q2 2024 and Q2 2025. But the fees aren't why this trend should worry you.

The merchant's authorization rate drops from 94% to 87%. It stays there for six weeks. At $2M in monthly volume, each lost point is roughly $20,000 in orders that real customers tried to place and couldn't. Seven points over six weeks adds up to close to $200,000 in revenue that never shows up on a fraud report.

What Card Testing Actually Costs You

The processing fees and chargebacks are visible. Every $1 lost to fraud costs US merchants $5.13 in total once you factor in fees, chargebacks, labor, and operational costs, according to the LexisNexis True Cost of Fraud Study 2026. Stripe charges $15 per dispute, and the average chargeback dispute value reached $84 in 2025.

Those numbers hurt, but the authorization rate damage is worse, and most merchants don't see it coming.

Issuing banks score every merchant ID based on the traffic they process. A weekend of thousands of declines looks, from the issuer's side, like a merchant with a fraud problem. Their models respond by tightening approval thresholds on your account. They don't distinguish between the bot that caused the spike and the legitimate customer who shows up on Tuesday.

As Shopify's engineering team puts it: "The real cost isn't failed transactions. It's months of degraded trust with banks and soft declines on legitimate customers long after the attack has stopped."

The declines during the attack are correct. You want stolen cards blocked. The problem is that issuers can't see the bot separately from your business. They see one merchant ID with a fraud spike, and they react accordingly.

For a SaaS company running monthly subscription renewals on Stripe, this is especially dangerous. According to ClearSale's False Declines report, only 22% of customers retry after being declined. A false decline on a renewal isn't a failed transaction. It's involuntary churn.

Three Signals to Spot an Attack

Before you act, confirm what you're looking at. These three patterns take 30 seconds to check and tell a clear story when they appear together.

1. Velocity spike with micro-amounts. Normal checkout traffic follows predictable rhythms. Card testers submit hundreds of transactions per hour in amounts under $2.00, small enough to avoid alerts and go unnoticed on a cardholder's statement.

2. One source, many cards. A single IP address or email submitting transactions with 20, 50, or 100 different card numbers in minutes is almost certainly a bot. Legitimate customers use one or two cards.

3. Decline rate spike. A sudden jump in declines concentrated in a short window means issuers are rejecting a flood of invalid or stolen numbers hitting your checkout.

All three at once? That's a card testing attack.

Why Generic Controls Hit a Wall

Stripe provides every merchant with a baseline defense: Radar's rules engine, rate limiters, hCaptcha triggers, and network-level models. You should have these turned on. They're the floor.

The problem is that generic controls are tuned for an average merchant, not for your business. A velocity rule that blocks three attempts per card per hour makes sense for a one-time-purchase store. For a SaaS company whose renewal run charges the same cards on the same day every month, that rule declines your own subscribers.

Tighten the rule to stop bots, and you block real buyers. Loosen it to protect renewals, and you let testers back in.

This is the core tension: every static threshold you add to catch card testing also catches legitimate transactions. Attackers know this. Modern card testers use residential proxies, distribute low-volume attempts across thousands of merchants, and send AI-generated traffic that mimics real shoppers. HUMAN Security reports that AI-driven traffic grew 187% over the course of 2025, nearly tripling within the year.

A rule written for everyone can't tell the difference between a bot rotating through residential IPs and a real customer on a VPN.

The deeper you go on generic rules, the more real revenue you lose. That's the limit, and it's structural.

What Merchant-Specific Scoring Does Differently

The durable fix is scoring each payment attempt against your own transaction history instead of a universal profile.

A model trained on your data learns what normal looks like for your business: typical order sizes, time-of-day patterns, geography, repeat-card cadence, and how your real customers move through checkout. It scores every attempt based on how far it deviates from that baseline.

Here's why that changes the math. Consider the $2M D2C merchant from the opening scenario:

• Generic velocity rule: flags the attack, but also flags the merchant's loyal customers who make multiple purchases per week. Tightening the rule during the attack blocks the bots and blocks returning buyers. Loosening it after the attack lets stragglers through.

• Merchant-specific model: recognizes that the bot's velocity pattern deviates from the merchant's historical baseline. It flags the geographic anomalies and temporal clustering of the attack traffic. It blocks the test cards. But it also recognizes the returning customer who orders every Thursday from the same city, because it has seen that pattern for months. The renewal run or repeat buyer isn't flagged because the model knows the difference.

Blocking the attack and approving real buyers turn out to be the same optimization. Shopify's engineering team proved this at scale: their ML model, which scores every payment before it reaches the processor, blocks approximately 90% of card testing attacks on guest checkouts while delivering a 13% improvement in authorization rates for legitimate transactions.

Stripe merchants can't borrow Shopify's proprietary model, and Stripe's network-level scoring isn't trained on your business specifically. The path to an even better result is a merchant-specific model sitting in front of your Stripe decisioning, trained on your data, scoring your traffic.

How Card Testing Works: A Quick Primer

Understanding the mechanics helps explain why generic defenses have a ceiling.

Fraudsters acquire stolen card data for as little as $5 per set on the dark web. A stolen number is worthless until they confirm it's active and has available credit line or debit balance. Your checkout is the testing lab.

The flow follows two steps:

1. Test: Automated scripts submit small-dollar transactions through your payment form, often hundreds per hour. Each successful charge confirms a working card.

2. Monetize: Validated cards are sold at a premium or used for larger purchases elsewhere.

BIN attacks skip the stolen-data step entirely. Attackers generate thousands of plausible card numbers from a known Bank Identification Number range using the Luhn algorithm, then test them against live checkouts. No breach required.

These aren't crude scripts anymore. Modern attackers rotate through residential proxies, spread attempts across merchants, and generate traffic patterns that look human. That's why rules designed to catch bots increasingly catch people instead.

What to Do Right Now If You're Under Attack

If you've confirmed an active attack, work through this sequence:

1. Activate Radar velocity rules. Start with tight thresholds (five payment attempts per IP per 10 minutes, three per card per hour) and plan to loosen them once the attack stops.

2. Refund the small charges that went through. Charges from the attack window will be disputed later. Refunding now avoids the $15-per-dispute fee and keeps chargebacks off your ratio.

3. Confirm your integration signals. Your checkout needs to send IP address, billing address, email, and device fingerprint data to Stripe. Missing signals reduce the protection you're already paying for.

4. Monitor for 48 to 72 hours. Attackers probe, pause, and return. Watch your decline rate and velocity patterns after implementing rules.

5. Track your authorization rate on legitimate traffic. This is the number the attack will damage next. Most merchants aren't watching it.

The emergency rules are a tourniquet, not a treatment. The tight thresholds that stopped the bots will keep declining real customers if you leave them in place. As soon as the attack subsides, you need a scoring layer that can tell the difference.

Protecting Your Revenue After the Attack

Stopping the attack is half the work. Rebuilding your authorization profile with issuers takes deliberate effort.

• Clean up your decline ratio. Refund fraudulent charges and let legitimate transaction volume re-establish a healthy baseline.

• Monitor weekly. Track your authorization rate as a leading indicator. If it hasn't recovered within 30 days, issuers may still be flagging your merchant ID.

• Replace emergency rules with scoring. Static rules react to patterns you've already seen. A model trained on your data adapts to new attack patterns and approves the traffic that rules were blocking.

Visa's VAMP program (effective October 2025) adds another reason to act quickly: merchants who cross 300,000 enumerated transactions per month with a 20% or higher enumeration ratio face penalties. Clean traffic through better scoring is the most direct path to staying under that threshold.

Where Corgi Model Fits

Corgi Model is custom fraud decisioning trained on your transaction data, built to work with your existing Stripe setup. It learns your baseline (order sizes, billing cadence, geography, customer behavior) and scores every attempt against it. Card testing traffic gets caught because it deviates from what's normal for your business. Your renewal run doesn't get flagged because the model has seen it every month.

You can see the result before it touches a live transaction. Shadow mode scores three months of your payment history and shows which attempts it would have blocked and which real orders it would have approved. Across the Corgi Labs merchant base, merchants running Corgi Model cut chargebacks by 70% or more and add 3% to 12% in revenue from real buyers who were being declined.

If card testing has damaged your authorization rate, the fix isn't more rules. It's scoring built for your traffic, not everyone's.

Book a Demo →

Sources

1. LexisNexis Risk Solutions, "True Cost of Fraud Study 2026": https://risk.lexisnexis.com/about-us/press-room/press-release/20260624-tcof-retail-and-commerce

2. Fidro, "Card Testing Attacks: How Fraudsters Validate Stolen Cards on Your Checkout" (April 2026): https://fidro.io/blog/card-testing-attacks-prevention

3. Shopify Engineering Blog, "How Shopify's Machine Learning Blocks Approximately 90% of Card Testing Attacks" (June 2026): https://www.shopify.com/enterprise/blog/block-card-testing-attacks

4. Stripe Documentation, "Protect yourself from card testing" (2026): https://docs.stripe.com/disputes/prevention/card-testing

5. HUMAN Security, "The 2026 State of AI Traffic & Cyberthreat Benchmark Report" (April 2026): https://www.humansecurity.com/learn/resources/2026-state-of-ai-traffic-cyberthreat-benchmarks/

6. Chargeflow, "Card Testing Fraud: Signs, Costs & Prevention" (August 2026): https://www.chargeflow.io/blog/what-is-card-testing-fraud

7. Chargebacks911, "2026 Chargeback Field Report / Chargeback Stats" (July 2026): https://chargebacks911.com/chargeback-stats/

8. Chargebacks911, "Card Testing Statistics & Financial Impact" (September 2025): https://chargebacks911.com/ecommerce-fraud/card-testing/card-testing-statistics-financial-impact/

9. Experian, "What is a BIN Attack?" (August 2025): https://www.experian.com/blogs/insights/what-is-a-bin-attack/

10. ClearSale, "False Declines and Ecommerce Fraud Prevention Report": https://offer.clear.sale/false-declines-ecommerce-fraud-prevention-report