TL;DR: payment fraud detection software
- The gap: There is a checkout evidence gap. Server-side risk scores miss the client-side device continuity Visa CE 3.0 requires.
- The numbers: 60-80% of e-commerce chargebacks are friendly fraud, not criminal. Standard evidence wins 15-20%. CE 3.0 evidence wins 40-60%.
- The fix: Device fingerprinting at checkout captures the CE 3.0 signal set. Same device on prior undisputed orders creates a presumption of legitimacy.
Short on time? See cside's chargeback-evidence tooling. It covers everything below in one deployment.
The evidence gap in payment fraud
A fraudulent transaction and a legitimate one look identical in the database. The card number passed validation, the billing address matched, the CVV was correct, and the order shipped. The difference only surfaces when the real cardholder raises a dispute, usually 30 to 90 days later.
By then the browser session is gone. The device fingerprint, the VPN or proxy status, and the way the checkout form was filled all existed only in the browser during those few minutes. If nothing recorded it at the time, it cannot be reconstructed. Merchants lose disputes they should win, not because the transaction was genuine, but because they cannot produce the session evidence that would settle it.
What to capture at transaction time
Five signals live in the browser during a checkout session, and none of them survive into the transaction record. All of them matter for both the real-time decision and the later dispute.
- Device fingerprint. A stable identifier for the device that persists across incognito mode, VPN use, and cookie clearing. It lets you correlate the transaction with prior activity from the same device. A device with no history for this cardholder, or one already tied to past disputes, is worth acting on.
- AI-agent flag. A growing share of card testing and payment fraud runs through autonomous agents rather than a person typing card numbers by hand. Whether a checkout was driven by an automated tool is a material fact in a dispute, and it is only visible in the browser.
- VPN and proxy status. Fraudsters mask their location through VPNs and residential proxies. TLS fingerprinting exposes an anonymized connection during the session; the IP address in the transaction record does not.
- Session behavior. A human pauses to re-read a card number, hesitates before confirming, and moves the cursor with organic imprecision. A scripted checkout does not. That difference is measurable in the browser and invisible in the payment record.
- Session replay. A timestamped record of what happened on screen is the most directly human-readable form of transaction-time evidence.
How this evidence is used in disputes
Visa's Compelling Evidence 3.0 framework accepts device fingerprint data and session evidence in chargeback disputes. That gives browser-layer evidence captured at transaction time a defined path into the formal dispute process.
A device fingerprint showing that the cardholder's known device was present at the time of the disputed transaction can be decisive against a friendly-fraud claim. Session replay showing natural human interaction supports the same case. A VPN flag or an AI-agent detection strengthens a merchant's position when the transaction really was fraudulent. The requirement is the same in every case: the evidence has to be captured during the session and exportable in a format the dispute process accepts. A CE 3.0 export that bundles device ID, session replay, and timestamp is the output that actually moves a dispute.
How browser-layer detection works in practice
A browser-layer payment fraud tool runs as a PCI-compliant script on the checkout page. It loads with the page, collects the five signals above during the session, and makes them available in real time and for later export. A CE 3.0 evidence packet with device ID, session replay, and timestamp can be generated in seconds.
The same approach covers card testing, where attackers run small automated transactions to validate stolen card numbers before a larger purchase. Those runs are automated tools, detectable by their session behavior even when each individual charge is too small to trip a velocity rule.
cside works on this model. It combines 250+ signals per session into a real-time risk score and returns a verdict that flags AI-agent and automated sessions, including named tools such as OpenAI Operator, Claude for Chrome, Playwright, Puppeteer, and Selenium. cside integrates with Chargebacks911, and merchants using both can pull a CE 3.0 evidence packet per dispute. See how cside approaches this on the chargeback evidence page.
PCI DSS 4.0.1 and the compliance overlap
Payment pages are in scope for PCI DSS 4.0.1. Requirement 6.4.3 mandates an inventory and integrity controls for every script loaded on a payment page, and Requirement 11.6.1 requires tamper detection for payment-page content. Both became mandatory on 2025-03-31. Browser-layer attacks such as Magecart payment skimming steal card data before the payment processor ever receives it, making client-side monitoring both a compliance requirement and a fraud prevention control on the same page.
A PCI-validated browser-layer script serves both jobs at once. It captures fraud signals and dispute evidence while also meeting the script-monitoring and tamper-detection controls PCI DSS 4.0.1 places on checkout pages. Teams often run fraud detection and PCI compliance as separate workstreams with separate tooling, and a validated browser-layer script collapses that into one deployment. cside runs as a PCI-validated script and helps merchants meet Requirements 6.4.3 and 11.6.1 (see the PCI compliance page).
For context on what checkout-page exposure costs, IBM put the global average cost of a data breach at $4.88 million in 2024, up from prior years:
| Year | Global average cost of a data breach |
|---|---|
| 2022 | $4.35M |
| 2023 | $4.45M |
| 2024 | $4.88M |
Source: IBM Cost of a Data Breach Report 2024. Payment-page skimming and checkout fraud drive a meaningful share of that exposure for merchants.
What payment fraud detection does not solve
Browser-layer detection cannot stop a stolen card from being used in the first place. Once a card number is compromised, someone can attempt it. What the browser layer does is create the evidence that decides what happens next.
For genuinely fraudulent transactions, that evidence establishes the facts of the session and supports either real-time blocking or a post-transaction dispute defense. For friendly-fraud claims, where a real cardholder disputes a purchase they actually made, the same evidence shows the cardholder's device was present and the session was human. It does not replace fraud rules, velocity checks, or card-network monitoring. It fills the one gap all of those leave open: the session itself.
Transaction Fraud Detection: Closing the Loop
Transaction fraud detection is the practice of identifying fraudulent payment transactions at the moment they occur, not after the chargeback arrives 60 days later. It combines the real-time signal read during the session with the historical record of prior sessions from the same device, so a single suspicious transaction can be evaluated against a pattern rather than in isolation.
The signal gap that server-side fraud rules leave open is continuity. A rules engine can flag a transaction if the billing address is new, the order value is high, or account velocity is suspicious. What it cannot do is confirm whether the person placing the order is the person who created the account, whether their device has appeared in prior fraud, or whether the session behavior looks like a real human or an automated carding script.
Three transaction-level signals close that gap, and all three exist only in the browser during the checkout session:
Device continuity. A device fingerprint matching the device on prior undisputed orders creates a strong presumption of legitimacy. A device never associated with this cardholder, or tied to past disputes, creates the opposite. Neither signal lives in the transaction record.
Behavioral authenticity. A real human filling a checkout form pauses, re-reads card numbers, and corrects mistakes. An automated carding script fills the same fields in milliseconds with no hesitation or correction. That difference is measurable in the browser and invisible in the payment data.
Session-to-history match. Card testing typically runs through automated tools, using small charges to validate a stolen card number before a large fraudulent purchase. When a session flagged as automated matches the device and timing pattern of prior small charges on the same card, the fraud chain becomes visible in a way no server-side model can reconstruct after the fact.
The practical reason transaction fraud detection needs to run in the browser is that these signals exist only at session time. A risk model that receives only the transaction record receives none of them.
