TL;DR: payment fraud detection software
- There is a checkout evidence gap. Server-side risk scores miss the client-side device continuity Visa CE 3.0 requires.
- 60-80% of e-commerce chargebacks are friendly fraud, not criminal. Standard evidence wins 15-20%. CE 3.0 evidence wins 40-60%.
- Device fingerprinting at checkout captures the CE 3.0 signal set. Same device on prior undisputed orders creates a presumption of legitimacy.
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 100+ 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.
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.
