Card testing is the practice of verifying whether stolen payment credentials are valid by making small or low-value transactions on real merchant sites. Traditional carding bots were relatively easy to detect: they moved fast, made identical requests at regular intervals, and had fingerprints that matched known automation frameworks. AI-powered card-testing agents are different. They move at human speeds, vary their behaviour, and run inside real browser sessions.
The problem is getting worse. AI frameworks that enable sophisticated browser automation are widely available, and the criminal economy around stolen payment data is well-organized and well-funded. The browser-layer visibility gap that lets legitimate AI agents go undetected creates the same gap for fraudulent ones. For a broader look at fraud costs and card network monitoring programs like Visa's VAMP, see AI Credit Card Testing Bots: How to Stop Them.
What Is AI Card Testing?
Quick answer: AI card testing is the use of AI-powered automation to test whether stolen payment card credentials are valid against real merchant checkout flows. Unlike traditional carding bots that operate via raw API calls or simple HTTP requests, AI card-testing agents use real browser sessions that execute JavaScript, interact with form elements, and mimic human checkout behaviour.
A card-testing operation typically works in stages:
- Obtain a batch of stolen card credentials (from data breaches, purchased on dark web markets, or generated algorithmically)
- Find a merchant site with a checkout flow that can validate cards with small or no charges: donation forms, trial signups, and low-minimum purchases are common targets
- Run automated sessions against the checkout, testing each credential until a successful validation occurs
- Use validated cards for higher-value fraud on other sites or sell them as "verified" in the criminal market
AI-powered card testers add a layer of behavioural sophistication: they vary transaction timing, simulate browsing activity before checkout, and adjust behaviour based on fraud score responses to avoid triggering detection.
Why Traditional Detection Fails Against AI Card Testers
Quick answer: Traditional fraud detection uses velocity rules, IP reputation, device fingerprinting, and user-agent matching. AI card-testing agents defeat these controls by running inside real browsers, varying their timing and behaviour, rotating IPs through residential proxies, and using AI-driven adaptation to responses from fraud systems.
The specific failure modes:
Velocity rules catch bots that hit the same endpoint repeatedly at machine speed. AI card testers slow down, introduce delays, and spread requests across sessions in patterns that avoid triggering velocity thresholds.
IP reputation catches known bad IPs. Card testers use residential proxy networks (real consumer IP addresses that have no prior fraud history). These IPs are clean by all standard reputation measures.
Device fingerprinting catches recycled fingerprints. Sophisticated card testers use browser automation that presents a fresh, realistic fingerprint per session, avoiding the recycled-fingerprint patterns that simple bots produce.
User-agent and header inspection catches systems that don't bother hiding their automation. AI card testers use real browser sessions with standard headers and user-agent strings indistinguishable from legitimate Chrome traffic.
cside engineers bypassed traditional bot detection in 81 out of 100 test scenarios. The result: server-side fraud tools and network-layer controls see what appears to be normal traffic until a successful fraudulent transaction completes.
What Gives AI Card Testers Away at the Browser Layer
Quick answer: Even sophisticated AI card testers cannot perfectly replicate all dimensions of human browser behaviour simultaneously. Inside the session, cside observes the signals that machine-executed checkout flows cannot fully suppress: timing micro-patterns, interaction event sequences, fingerprint characteristics, and checkout path linearity.
The detection signals specific to card-testing behaviour:
Checkout path precision Legitimate customers browse before buying. They read product descriptions, compare options, and sometimes abandon and return. Card testers enter at the checkout or low-value form with minimal prior navigation. The session has a transactional structure without shopping context.
Form interaction patterns Human form fill on payment fields has characteristic behaviour: slower entry on card number fields (reading from a physical or digital card), occasional correction of entry errors, cursor movements between fields. Agent-executed form fill has systematic precision: consistent field-to-field timing, no corrections, no cursor drift.
Session duration distribution A human completing a checkout takes a variable but human-range amount of time. A card tester completing a checkout completes it in the minimum time required for the task, faster than any human would be, but not so fast as to trigger simple velocity rules.
Behavioural response to friction When fraud systems return challenges (CAPTCHA, 3DS prompts, verification codes), AI card testers either stop and rotate to a new session or apply AI-driven CAPTCHA-solving. Both responses are observable as behavioural patterns. A session that encounters a challenge and then immediately re-enters from a clean state is a signal.
Fingerprint state Real consumer sessions have fingerprints shaped by their device history. Card-testing sessions using automation frameworks present fingerprint states that match framework defaults rather than lived-in device environments.
What cside Catches That Fraud Tools Miss: A Concrete Scenario
Quick answer: A card-testing agent targets a charity donation form: low minimum amounts, no cart flow, no login required. It originates from a residential IP, presents a real Chrome user-agent, and clears basic fraud checks. Here is the step-by-step session breakdown, and the browser-layer signals that expose it.
The agent loads the donation page and waits exactly 2.1 seconds before interacting with the amount field. It enters "1.00", then moves to the card number field in 0.3 seconds flat. Card number entry takes 4.2 seconds with no pauses between digit groups, no backspace events, and no cursor repositioning. The expiry and CVV fields are filled in 0.9 seconds each, with identical inter-keystroke intervals. The submit button is clicked 0.4 seconds after the last field is completed.
cside observes: form fill timing outside human variance on all payment fields, zero correction events across 14 consecutive sessions from the same fingerprint cluster, and checkout path with no prior page visits. Server-side fraud tools see a clean residential IP and a sub-threshold transaction. cside flags the session as high-confidence card testing and blocks the payment attempt before submission.
Stopping Card Testers Before the Transaction Completes
Quick answer: The window for stopping card-testing activity is in the browser session before the transaction completes. Server-side fraud tools and payment processors catch fraud after the fact. Browser-layer detection gives you the pre-transaction window where you can apply challenges, abandon the session, or block the payment attempt.
Practical controls:
- Challenge at checkout entry: Sessions matching card-testing behavioural signals should hit a challenge before reaching the payment form, not after. Behavioural CAPTCHA that requires human interaction (not just checkbox ticking) adds friction AI systems cannot perfectly solve without detection.
- 3DS2 for flagged sessions: For sessions with elevated behavioural risk scores, require 3D Secure authentication before completing the transaction. This adds liability protection and creates an additional verification layer.
- Rate limiting on payment form submissions: Limit the number of payment form submissions per session and per fingerprint cluster. This catches bulk credential testing even when individual sessions look normal.
- Correlation across sessions: Card-testing operations run many sessions from the same underlying infrastructure. Session correlation that identifies coordinated patterns (similar fingerprint clusters, similar behavioural timing, similar checkout paths) catches operations that individual session analysis might miss.
cside surfaces named and unnamed agents in a real-time dashboard with session-level detail. For card-testing detection specifically, the dashboard shows the behavioural signals that flagged the session and the correlation data that ties it to related activity.
