TL;DR: card testing prevention with pre-auth velocity
- IP-rate velocity rules were designed for one lazy fraudster and one static IP. Distributed card testing spreads across rotating IPs and small amounts, so every individual attempt sits below your threshold and the transaction ML tools score them one by one.
- cside reads cursor movement, form-fill timing, session cadence and AI-agent signatures at checkout before the authorization is submitted, so a blocked card-testing session produces zero chargeback exposure. Stolen credentials appeared in 39% of breaches per Verizon DBIR 2026, and the stack routes right into CE 3.0 export if anything slips through.
- If you run Stripe Radar and only see a post-authorization score, add pre-auth session detection. If your checkout is genuinely low-volume with no automation risk, stay with velocity rules.
Card testing fraud prevention software stops automated attempts to validate stolen card numbers before any charge completes. Testing runs are driven by scripts and AI agents, so the signal that flags them lives in the checkout session behavior: mechanical timing, absent cursor movement, and AI agent signatures that browser-layer detection reads before the charge fires.
Card testing fraud is the practice of running automated transactions through a merchant's checkout to validate whether stolen card numbers are active before using them for larger purchases. The attacker has a list of stolen card numbers and does not know which are still active. They run small transactions (often $0.00 or $1.00) to test each card against a real payment processor. The merchant absorbs the chargeback volume from the declines, and the cards that pass become ammunition for larger fraud.
Card testing causes harm in two distinct ways. The direct harm is the chargeback volume and processor fees generated by failed test transactions. The indirect harm is that each validated card is then used for larger purchases elsewhere, contributing to the broader fraud ecosystem. The Verizon DBIR 2026 found that stolen credentials appear in 39% of all data breaches, and stolen card data from those breaches feeds card testing operations at scale.
| Tool | Detection layer | Catches AI agent card testing | Detects before transaction fires | Chargeback evidence | Free tier |
|---|---|---|---|---|---|
| cside | Browser (session behavior + device fingerprint) | Yes | Yes | Yes (CE 3.0 export) | Yes (1,000 API calls/mo) |
| Stripe Radar | Transaction ML (post-authorization) | Limited | No (scores after transaction) | No session evidence | No (Stripe customers only) |
| Velocity rules | Request rate limiting | No (distributed testing evades it) | Partial | No | Varies |
Why transaction-layer tools miss distributed card testing
Transaction-based fraud scoring systems like Stripe Radar evaluate the risk of individual transactions using machine learning trained on historical payment data. They are effective for flagging individual suspicious transactions based on card behavior patterns.
The limitation for card testing specifically is timing and distribution. Modern card testing operations distribute tests across many cards, many small amounts, and sometimes many merchant accounts simultaneously. Individual test transactions look unremarkable because the amount is small, the card is real (it just may be stolen), and the operation is slow enough to stay below velocity thresholds. The pattern is only visible when you aggregate across many sessions over time, which requires session-level data that transaction-layer tools do not collect.
Velocity rules (rate limits on transaction frequency per IP or per card) are evaded by rotating IPs and spreading tests across time. Distributed card testing operations are specifically designed to stay below the thresholds that velocity rules enforce.
cside: browser-layer card testing detection
Card testing is conducted by scripts and AI agents rather than humans, and that distinction shows up in the checkout session itself, before any transaction fires.
cside card testing detection collects browser-layer signals during the checkout session: cursor movement (or the absence of it), timing between form fill events, session cadence, AI agent signatures, and device fingerprint characteristics. A human shopper navigating a checkout form moves the cursor, pauses before confirming payment, and fills fields with natural timing variation. An automated card testing script fills fields at computed intervals, moves the cursor in straight lines or not at all, and completes the checkout at mechanically consistent speed regardless of form complexity.
The API returns a real-time risk verdict before the payment authorization is submitted. Your checkout flow uses this signal to block the session, inject a CAPTCHA challenge, or flag the transaction for manual review. A card testing session that is blocked before authorization produces zero chargeback liability. The session evidence (device fingerprint, an AI-agent verdict, session behavior score) is available for export in Visa Compelling Evidence 3.0 format if any test transaction does complete and generates a dispute.
Stripe Radar
Stripe Radar is a machine learning fraud scoring system available to Stripe customers. It evaluates transaction risk based on card behavior, velocity, and patterns across the Stripe network.
For card testing prevention, Stripe Radar provides a useful signal on individual suspicious transactions but operates after the payment authorization is initiated. It does not collect browser-session signals before the transaction fires, and it does not detect the AI agent or automation characteristics that identify a session as card testing before any charge is attempted. Organizations using Stripe Radar for card testing prevention are operating with a response-after-the-fact model rather than a pre-authorization block.
Buyer checklist
- Does it detect testing sessions before authorization? Pre-authorization detection is the only way to achieve zero chargeback liability on test transactions.
- Does it catch AI agent-driven testing? Modern card testing increasingly uses AI agents that pass CAPTCHA and look like humans at the network layer.
- Does it work on distributed testing operations? Single-session detection that cannot aggregate device fingerprints across sessions will miss coordinated attacks.
- Does it produce evidence usable in disputes? When test transactions do complete, CE 3.0 formatted evidence determines whether the dispute is winnable.
- Does it integrate at the checkout page level? Server-side integration at the transaction layer misses the session signals that identify testing operations.
