Stripe Radar catches fraud after it touches your payment flow. The cheaper, faster win is blocking fraudsters before they ever reach Stripe — at signup, at cart, at checkout initiation. Here's how to do it.

If you run payments on Stripe, you've probably seen the pattern: a sudden burst of 50, 100, 500 micro-charges ranging from $0.50 to $5.00. Most get declined. A handful succeed. A week later the chargebacks roll in, and Stripe flags your account with an elevated dispute rate.

That's card testing. Stolen card numbers get validated against live Stripe endpoints, and your merchant account is the lab rat. It costs you authorization fees on every attempt, dispute fees on the ones that succeed, and — if the dispute rate crosses ~0.75% — Stripe can freeze payouts or drop you entirely.

The fix isn't better Radar rules. It's stopping the traffic upstream of Stripe, at the edge of your own app. By the time a request hits payment_intents.create, Radar only has card data, ZIP, and a CVC. It doesn't know the caller is using a datacenter VPN, a Kameleo antidetect browser, and just made 400 identical requests through a residential proxy network in the last hour.

How card-testing attacks actually work

A modern card-testing operation looks like this:

  1. Stolen BIN lists — the attacker has tens of thousands of card numbers from breaches, dark-web dumps, or skimmer operations.
  2. Rotating residential proxies — services like BrightData, Smartproxy, or ShadowNode route each request through a different US home IP. Rate-limiting by IP is useless.
  3. Antidetect browsers — Kameleo, GoLogin, or AdsPower rotate fingerprints per session: fresh canvas hash, fresh WebGL, fresh timezone, fresh user agent.
  4. Scripts that hit your public checkout — not Stripe directly. Your app submits the payment_intent, so your risk score is what gets burned.

Stripe Radar sees a card number attempt. It doesn't see the 400 identical sessions originating from datacenter ASNs in Moldova, or the browser tampering score of 0.97.

What Sentinel blocks before Stripe sees it

Sentinel sits in front of your checkout as a one-line frontend SDK and one backend verify call. On every checkout initiation you get:

  • VPN / proxy / datacenter flags — with residential proxy detection (not IP-reputation, device-signal based).
  • Antidetect browser detection — Kameleo, GoLogin, AdsPower, Multilogin, Dolphin. Browser tampering score 0-1.
  • Bot / automation flags — headless Chrome, Puppeteer, Playwright, Selenium fingerprints.
  • Visitor ID — persistent across incognito, VPN switching, and device reboots. You can count sessions, not cards.

The full evaluation takes under 40ms globally. You get a verdict before the Stripe call even fires.

A minimal Stripe + Sentinel flow

Add the Sentinel SDK to your checkout page:

<script async src="https://fp.sntlhq.com/agent"></script>

On your server, before calling Stripe, verify the session:

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 })
}).then(r => r.json());

if (sentinel.isSuspicious) {
  // Residential proxy + tampered browser on a 4th-attempt-in-10-minutes session.
  // Don't even call stripe.paymentIntents.create.
  return res.status(403).json({ error: 'declined' });
}

// Safe — proceed to Stripe.
const intent = await stripe.paymentIntents.create({ ... });

That's it. Suspicious traffic never generates a Stripe authorization request, so it never generates an auth fee, a decline, or a dispute.

What results look like

Merchants running Sentinel in front of Stripe typically see:

  • 60–85% drop in fraudulent payment attempts within 48 hours of deployment.
  • ~40% reduction in chargeback rate over the first 30 days — dispute cases are concentrated in high-risk sessions, so removing those traffic sources shows up fast in your Radar dashboard.
  • Lower auth fees — every declined attempt still costs you $0.05–$0.10. Blocking the bots upstream removes that bill entirely.
Stripe's own guidance agrees. Stripe recommends blocking card testing "at the application layer, before the payment request reaches Stripe." That's exactly where Sentinel sits.

Where this fits in your fraud stack

Sentinel is not a replacement for Stripe Radar — it's the layer before it. Think of the stack as:

  1. Cloudflare / WAF — drops obvious drive-by bots.
  2. Sentinel — drops sophisticated sessions (residential proxies, antidetect browsers, automation).
  3. Stripe Radar — catches the fraud that still slips through, using card-level signals.
  4. 3D Secure — pushes final liability to the issuer on anything Radar scores high.

Each layer is doing what it's best at. The payment-layer tools (Radar, 3DS) stop being overwhelmed once you stop feeding them junk traffic.

Getting started

Grab a free API key at sntlhq.com/signup — 1,000 requests/hour on the free tier, no credit card. Drop in the SDK, add the server-side check before paymentIntents.create, and you'll see suspicious traffic start failing silently within the hour.