Stripe estimates that roughly 32 million card-testing attempts hit merchant accounts every month in 2025. Your checkout form is the laboratory. The bots running through it don't care about your product — they're just checking which numbers still work.
One morning in Q3 2024, the fraud team at a mid-size e-commerce company opened their Stripe dashboard to find 1,847 failed payment attempts from the previous night, all between 2:00 AM and 4:30 AM. Charge amounts clustered tightly between $0.50 and $1.50. The billing addresses hit all 50 US states. No two shared an IP address. By the time their on-call engineer was awake, Stripe had already flagged the account for an elevated dispute rate — and suspended same-day payouts.
That's a card testing attack. And it's getting harder to stop, not easier.
What Card Testing Actually Is
Card testing — also called carding verification or BIN attacks — is the process of using automated scripts to verify whether stolen payment card numbers are still active. Fraudsters acquire card data in bulk: from data breaches, dark-web dumps, phishing kits, or skimmer networks. Raw stolen card data is nearly worthless on its own because a significant fraction of cards in any dump have already been cancelled, expired, or flagged by issuing banks.
The economic logic is cold and precise. A live, verified card sells for $5 to $50 on fraud marketplaces depending on card type, credit limit, and whether it has a verified billing address (AVS match). A dead card is worth $0.10 or less — barely worth the bandwidth to transmit. So before selling or using a batch of 50,000 stolen card numbers, the fraudster runs them through a checker: a bot that makes small charges against a real merchant's checkout to see which ones succeed.
The verification cost per card is typically a fraction of a cent. The upside of finding a live card is $5–$50. The economics are overwhelmingly favorable — which is why the volume is enormous.
The Mechanics: How Card Testing Bots Operate
Modern card testing operations have professionalized over the past three years. The tools are sophisticated, the infrastructure is rented, and the bots are optimized to evade exactly the defenses most merchants have in place.
Step 1 — Acquiring card databases. Operators buy BIN (Bank Identification Number) lists and full card dumps from automated dark-web shops like the now-defunct BidenCash marketplace and its successors. A typical batch purchase is 10,000–100,000 card records, priced at $0.10–$1.00 each unverified.
Step 2 — Selecting a target merchant. The ideal target has a public-facing checkout, no CAPTCHA, low order minimums, and a donation or "pay what you want" flow where small arbitrary amounts are accepted. Nonprofit donation pages are notoriously overrepresented. So are SaaS checkout flows and marketplace top-up systems.
Step 3 — Routing through residential proxies. This is the move that defeats most IP-based defenses. Services like BrightData, Oxylabs, and shadier alternatives route each request through a different real home IP address — the kind that belongs to an actual household broadband subscriber in Des Moines or Phoenix. Stripe Radar's IP reputation signals see what looks like a normal customer. IP rate-limiting by address is useless when the address changes every request.
Step 4 — Rotating device fingerprints. Antidetect browsers (Kameleo, GoLogin, AdsPower, Multilogin) generate a fresh browser fingerprint per session: a different canvas hash, WebGL renderer string, screen resolution, timezone, installed fonts, and user-agent string. Standard device fingerprinting that would catch a bot re-using the same device profile fails when every profile looks unique.
Step 5 — Timing and volume randomization. Naive bots fire a fixed number of requests per second, making burst detection trivial. Sophisticated operators introduce jitter — randomized inter-request delays between 200ms and 8 seconds — and spread attempts across a multi-hour window. Some operations now use "low-and-slow" strategies: 3–5 card tests per hour, sustained over days, staying well below any fixed rate threshold.
What the Economics Look Like — For Both Sides
Understanding the fraud economics explains why this problem won't go away by itself.
On the attacker's side, a batch of 50,000 unverified card numbers costs roughly $5,000–$50,000 to acquire. Running them through a card checker using residential proxy bandwidth costs maybe $200–$500 in proxy fees plus verification charges. If 8% of cards come back live (a realistic figure for fresh dumps), that's 4,000 live cards. Sold at an average of $15 each, revenue is $60,000 — a comfortable margin even before using the cards directly for fraud purchases.
On the merchant's side, the costs pile up whether or not any charge succeeds:
- Authorization fees: Stripe charges $0.05–$0.10 per authorization attempt, including declined ones. A 10,000-attempt attack costs $500–$1,000 in fees alone.
- Dispute fees: Every successful fraudulent charge that results in a chargeback costs $15 on Stripe. If 200 charges succeed and are later disputed, that's $3,000 in dispute fees on top of the reversed revenue.
- Account risk: Stripe's dispute threshold sits around 0.75% of transaction volume. Breaching it means enhanced monitoring, payout delays, and — in repeat cases — account termination. Losing a Stripe account mid-growth is a company-threatening event.
- Engineering time: A fraud team reacting to a card testing incident typically spends 8–20 hours investigating, adding rules, and cleaning up. At $150/hr fully loaded, that's $1,200–$3,000 per incident.
The Signals That Betray Card Testing Bots
Despite the sophistication of modern card testing infrastructure, these operations leave a behavioral fingerprint that's detectable — if you're looking at the right signals.
Burst timing with jitter patterns. Even randomized delays cluster statistically. A human checking out makes one or two attempts over several minutes with irregular pauses. A bot producing Poisson-distributed inter-request times at high volume creates a distinct statistical signature when you look at the session-level distribution across a cohort of sessions.
IP clustering despite residential routing. Residential proxy networks have finite pools in any given city or ASN. An attack using 500 residential IPs will often show geographic clustering — 40 IPs all in the same /16 subnet of a major ISP, or temporal clustering where the same proxy IP reappears across multiple sessions within the same hour window.
Device fingerprint reuse beneath antidetect obfuscation. Antidetect browsers randomize surface fingerprints but leave lower-level traces: WebGL shader precision errors that are consistent across a vendor's browser build, AudioContext fingerprints that cluster by browser engine version, and CSS font rendering metrics that don't match the declared OS. These sub-surface signals are far harder to spoof convincingly at scale.
Velocity on persistent visitor ID. A genuine visitor ID — one that persists across incognito sessions, IP changes, and even device reboots — reveals the same underlying device making attempt number 47 through IP address number 47. No legitimate customer makes 47 payment attempts in 6 hours.
Checkout behavior anomalies. Real customers read product pages, spend time on cart pages, and exhibit micro-interactions (mouse movement, scroll depth, focus events on form fields) that bots either skip entirely or emulate imperfectly. A checkout session where a payment form is submitted 0.8 seconds after page load, with no mouse movement and no field focus events, is not a human.
Why Stripe Radar Alone Is Not Enough
Stripe Radar is a card-level fraud model. It ingests card number, BIN, billing ZIP, CVV match result, and card velocity across the Stripe network. It is genuinely good at what it does — and it improves constantly as Stripe's transaction volume grows.
But Radar has a fundamental architectural constraint: it only sees signals that exist at the moment a payment_intent is created. It does not see:
- Whether the browser session is an antidetect browser with a spoofed fingerprint
- Whether the IP resolves to a residential proxy network's exit node
- Whether the same underlying device has made 40 payment attempts in the past hour under different IPs
- Whether the checkout page interaction pattern is consistent with human behavior
These are application-layer signals, not payment-layer signals. By the time Radar sees a request, it's already become a Stripe API call — meaning you've already paid the authorization fee, and the card's decline has already been logged against your merchant account's health score.
"The best card testing defense isn't a better fraud model — it's ensuring sophisticated bot traffic never generates a payment intent in the first place." — Fraud engineering team, mid-size SaaS (name withheld)
How Sentinel Stops Card Testing Before It Reaches Stripe
Sentinel sits at the application layer, in front of your checkout, evaluating every session before your backend calls Stripe. The architecture is two components:
A lightweight frontend SDK (<script async src="https://fa.sntlhq.com/agent"></script>) that runs on your checkout page and collects device signals — browser fingerprint quality, behavioral entropy, WebGL/AudioContext sub-surface signals, and interaction patterns. It generates a session token asynchronously while the user fills out the checkout form, so there's no added latency on the user's path.
A server-side evaluate call that your backend makes before creating any Stripe object. The evaluate endpoint cross-references the session token against IP reputation (including residential proxy network detection), device fingerprint analysis, and cross-session velocity on the persistent visitor ID. The response comes back in under 40ms globally and includes a risk score, specific signal flags, and the persistent visitor ID.
Here's the minimal integration before a Stripe charge:
// Node.js / Express — before stripe.paymentIntents.create
const sentinel = await fetch('https://sntlhq.com/v1/evaluate', {
method: 'POST',
headers: {
'Authorization': 'Bearer sk_live_YOUR_SENTINEL_KEY',
'Content-Type': 'application/json'
},
body: JSON.stringify({
token: req.body.sentinelToken, // generated by frontend SDK
event: 'checkout.initiated'
})
}).then(r => r.json());
// Block if: residential proxy + antidetect browser + high session velocity
if (
sentinel.signals.isResidentialProxy &&
sentinel.signals.browserTamperingScore > 0.7
) {
return res.status(402).json({ error: 'payment_declined' });
}
// Also block pure bot automation regardless of proxy status
if (sentinel.signals.isBot) {
return res.status(402).json({ error: 'payment_declined' });
}
// Check cross-session velocity on the persistent visitor ID
if (sentinel.visitorData.paymentAttemptsLast1h > 10) {
return res.status(429).json({ error: 'too_many_attempts' });
}
// Safe — proceed to Stripe
const intent = await stripe.paymentIntents.create({
amount: req.body.amount,
currency: 'usd',
// ... rest of your Stripe params
});The response structure gives you enough signal granularity to tune your policy. A user on NordVPN with a clean device and normal behavior won't hit the residential proxy + tampering combination. A card testing bot rotating through BrightData will fail every check simultaneously.
Merchants integrating Sentinel in front of Stripe typically report a 70–85% reduction in fraudulent payment attempts within 72 hours. Chargeback rates drop 40–60% over the first 30 days. Authorization fees on declined attempts — a cost most fraud teams don't even track — disappear almost entirely for bot traffic.
Building a Layered Defense
Card testing defense works best as a layered system, with each layer doing what it's architecturally suited for:
- Cloudflare / WAF rules — drops unsophisticated bots using known bad ASNs and obvious attack patterns. Catches maybe 30% of card testing volume.
- Sentinel (application layer) — catches residential proxies, antidetect browsers, behavioral anomalies, and velocity patterns. Blocks the sophisticated 60–70% that WAF rules miss.
- Stripe Radar rules — catches card-level signals: BIN velocity, billing address mismatches, issuer-level risk scores. Handles the fraud that slips through the upstream layers.
- 3D Secure (3DS2) — for anything Radar scores above your threshold, trigger SCA. This pushes liability to the card issuer on successful charges, eliminating your chargeback exposure even if a live card transacts.
The goal is to ensure Stripe Radar is only processing sessions that have already cleared application-layer checks. When you stop feeding Radar with junk traffic, its signal-to-noise ratio improves — and your legitimate customer conversion stays clean.