Stop Card Testing Bots, Auth Floods & Chargeback Fallout
Bots use checkout and donation forms to validate batches of stolen cards, and you pay twice — authorization fees now, chargebacks weeks later. Sentinel detects the automation and proxy infrastructure behind the run — invisibly, in under 40ms, before the payment intent exists.
What you're up against
Small-amount authorization floods
Bots cycle stolen card batches through your checkout with tiny authorizations to find which cards are live. Each attempt costs you a processor fee whether it approves or not, and a wall of declines wrecks your approval rate with the acquirer.
Donation forms as free card validators
Any form that accepts an arbitrary amount is a perfect card tester: no inventory, no shipping address, instant confirmation that a stolen card works. Nonprofits and tipping flows get hit hardest precisely because they keep friction low.
Chargebacks land weeks after the test
Cards validated on your site get drained elsewhere — and the test charges themselves come back as disputes. The fallout pushes your chargeback ratio toward the card networks' monitoring programs, where fines and processor termination live.
Velocity rules that proxies walk around
Per-IP rate limits and per-card counters assume the attacker keeps one address. Testing runs rotate residential proxies so every attempt arrives from a fresh "clean" IP, and your velocity rules never fire.
What Sentinel does for you
- Score every checkout before the payment intent is created — blocked cards never reach your processor
- Detect scripted and headless browsers on payment pages without showing a CAPTCHA
- Link an entire testing run to one device across IP and browser rotations
- Flag datacenter, VPN, and residential-proxy traffic on the payment path
- Return a verdict in under 40ms — real buyers never notice the check
in fraudulent chargebacks blocked in 90 days by a D2C apparel brand that screened every checkout before payment
[ Read Full Case Study ]Where the check goes
One call site covers this vector: the server route that creates the payment intent — your checkout submit and any donation or tipping endpoint that charges a card. Run the check after the form posts but before you talk to your processor; a block means the stolen card is never authorized, so there's no auth fee and nothing to charge back. The client snippet rides along in your existing payment page and issues the token your server sends to Sentinel.
// Score the checkout before creating a payment intent
const res = await fetch('https://sntlhq.com/v1/evaluate', {
method: 'POST',
headers: {
'Authorization': 'Bearer ' + process.env.SENTINEL_KEY,
'Content-Type': 'application/json'
},
body: JSON.stringify({ token: req.body.sentinel_token })
});
const risk = await res.json();
if (risk.decision === 'block') return res.status(403).json({ error: 'Request rejected' });
if (risk.decision === 'review') flagForReview(risk.reasons);The signals that matter here
Automation, before the first authorization. Nobody types stolen card numbers by hand — card testing is scripted end to end, usually headless Chrome with stealth patches that pass naive bot checks. The device layer measures what the patches can't fake, and the response says so directly: device.automation comes back true and the reasons array carries automation_detected or antidetect_browser, before the first authorization is ever attempted.
One device, many cards. A testing run rotates card numbers, emails, and IPs, but rarely hardware. Sentinel keys its cross-browser "times seen" counter to the device underneath, so the fiftieth attempt from the same machine scores as the fiftieth — not the first — even when each one arrives from a fresh browser profile and a different residential IP. Sustained hammering trips the high_activity_device reason on its own.
Network context on the payment path. Legitimate buyers overwhelmingly check out from home and mobile networks. Card-testing traffic runs through infrastructure: network.datacenter, network.vpn, and network.proxy light up, with datacenter_asn and proxy_detected in the reasons. A VPN alone on a purchase can be privacy hygiene, which is why Sentinel returns the raw signals plus a 0–100 risk_score instead of a bare yes/no — your threshold can treat a lone VPN differently from a VPN plus automation plus a device seen dozens of times this hour.
A blocked attempt can't become a chargeback. Every authorization that reaches your processor costs a fee, approved or declined, and every approval on a live stolen card matures into a dispute weeks later. Screening before the payment intent exists means the attempt dies in your own backend — no auth fee, no decline-rate damage with your acquirer, and no new friction for real buyers, because the verdict is an API response rather than a challenge.
Common questions
Start protecting your checkout
Free tier: 1,000 requests/hour. No card, no expiry. Detects residential proxies, antidetect browsers, and AI bots.