According to the MRC 2026 Global eCommerce Payments and Fraud Report, 64% of merchants report a meaningful increase in first-party misuse. Behind that number are cardholders who authorised transactions and then disputed them: purchases they made, subscriptions they started, digital goods they consumed. Winning those disputes requires compelling evidence. Most merchants try to defend them with what their fraud platform provides: a risk score or a visitor ID. Neither is what card scheme dispute frameworks ask for.
This is not a criticism of event-based fraud detection or device identification as categories. Risk scoring platforms serve an important purpose at the moment of transaction: they tell you whether to approve or decline. Device identification platforms tell you whether a returning visitor is who they claim to be. Both are the right tools for those jobs. The problem is that after a transaction has been processed and disputed, those outputs are not the evidence format that dispute resolution teams, issuers, and card scheme frameworks evaluate.
This post explains what compelling evidence actually requires, why risk scores and visitor IDs fall short of that requirement, and what browser-layer session evidence provides that the alternatives do not.
What compelling evidence actually requires
Quick answer: Card scheme dispute frameworks for first-party misuse require the merchant to demonstrate that the cardholder was present and actively participated in the disputed transaction. This means a factual record of the device, browser, and session behaviour at the moment of authorisation, not a model's probability output and not a persistent identifier. The distinction between evidence and verdict is the core issue.
Visa's Compelling Evidence 3.0 framework and Mastercard's dispute resolution requirements for friendly fraud set out specific criteria for what constitutes acceptable evidence in a first-party misuse dispute. The central requirement is demonstration of prior undisputed transactions from the same device and browser environment: establishing that the cardholder has used the same technical setup to make purchases they did not dispute, creating a pattern that makes it implausible they were not present in the disputed session.
That requirement has two components. First, a consistent device and browser record across multiple transactions, not just a persistent identifier, but enough technical detail to establish that the sessions share an environment. Second, the absence of signals that would indicate the transaction was made by someone other than the cardholder: no VPN or proxy obscuring the network origin, no automation artefacts indicating the session was not human-generated, no device signals inconsistent with the cardholder's established pattern.
The evidence requirement is factual and forensic: what was in the browser at the moment of authorisation. A risk score does not provide that. It provides a probability. A visitor ID does not provide that. It provides a consistent pseudonymous identifier. The difference matters when an issuer's dispute review team, or a card scheme arbitration panel, is evaluating whether a merchant's submission meets the compelling evidence standard.
What a risk score tells your dispute team
Quick answer: A risk score tells your dispute team that a model assigned a probability to the transaction at the moment it was processed. It does not record what device was used, what browser was running, whether the session showed human behaviour, or whether any manipulation was present. Dispute review teams evaluate evidence about what happened in the session; a risk score is a verdict about whether the transaction looked suspicious, which is a different thing.
An event-based fraud platform processes the signals available in the transaction event and returns a score. That score reflects the model's assessment of fraud probability based on the inputs available at decision time: IP address reputation, device signal, transaction amount, merchant category, and so on. It is the output of a model, not a record of the session.
When a merchant uses a risk score as chargeback evidence, they are presenting the issuer with a retrospective probability assessment produced by a third party. The issuer's dispute review team is not evaluating whether the transaction looked suspicious to a fraud model. They are evaluating whether the cardholder was present, whether the session was authentic, and whether the merchant can demonstrate that the disputed transaction fits a pattern of genuine prior authorisations from the same user.
There is also a timing problem. A risk score produced at the moment of transaction approval was designed to inform an approve-or-decline decision. It was not designed to serve as a forensic record. It typically does not include the session-level detail (the specific browser fingerprint, the scripts executing in the page, the session depth and timing) that a dispute review team needs to evaluate presence and authenticity. Risk scores are snapshots of a model's confidence at a point in time; they are not audit trails.
For merchants who relied on event-based risk scoring as their primary fraud detection layer, this gap becomes visible when the first first-party misuse chargebacks arrive. The risk scores did not flag those transactions as suspicious, by definition, first-party misuse involves real cardholders making real authorisations, which is exactly what well-calibrated fraud models are designed to approve. The session looked legitimate because it was legitimate. The problem is that the cardholder disputed it anyway.
What a visitor ID tells your dispute team
Quick answer: A visitor ID tells your dispute team that a persistent pseudonymous identifier was present in the session. It establishes identity persistence (this identifier has appeared in previous sessions) but it does not record the browser environment, the session behaviour, the scripts present, or the network context. A visitor ID proves that a recognised device pattern appeared; it does not prove the session was authentic or unmediated.
A visitor ID from a device identification platform is a stable pseudonymous identifier derived from the browser and device characteristics at the time of the visit. The same device produces the same identifier across sessions, making it useful for recognising returning users. For the purpose of chargeback evidence, it can establish that the device associated with the disputed transaction has appeared in previous sessions with the same merchant.
That is a useful starting point. It is not sufficient on its own to meet the compelling evidence standard. A visitor ID establishes identity persistence without providing the forensic detail about what else was present in the session. Did the session show normal human browsing behaviour, or was it unusually short and direct? Were any third-party scripts executing that are not typically present in authentic sessions? Was the network connection clean, or was there a VPN layer between the cardholder and the merchant that was not present in previous undisputed transactions?
A visitor ID also does not distinguish between a cardholder using their own device and an attacker who has stolen the device or established persistent access to it. A device fingerprint that appears consistently across many sessions may belong to the cardholder using their own hardware across time, or it may belong to an attacker who has persistent access to that hardware. The visitor ID alone cannot distinguish those cases.
The dispute team reviewing a submission that contains only a visitor ID has a persistent identifier but not a session record. They can see that a recognised device pattern was present. They cannot see what the browser environment looked like, what behaviour the session showed, or whether the technical context of the disputed transaction was consistent with the cardholder's established pattern. Meeting the compelling evidence standard requires more detail than a visitor ID provides.
What browser-layer evidence actually looks like
Quick answer: Browser-layer evidence is a structured record of the session at the time of the transaction: the stable device fingerprint, the browser environment including scripts executing, the network context, and the session behaviour including depth, timing, and interaction patterns. This record can demonstrate device and browser consistency with prior undisputed transactions, absence of automation or proxy mediation, and session behaviour consistent with a real cardholder authorisation.
cside captures a structured session record at the time of every transaction event. That record includes the stable device fingerprint derived from hardware and browser characteristics, the third-party and first-party scripts executing in the page at the moment of the transaction, the network context including VPN and proxy signals, and session behaviour signals including page depth, interaction timing, and the sequence of events preceding the transaction action.
Each of these maps directly to what dispute resolution frameworks ask for. Device and browser fingerprint consistency across multiple transactions establishes the "prior undisputed transactions from the same device" requirement. The absence of automation signals in the browser environment establishes that the session was not mediated by a tool operating on the cardholder's behalf without their knowledge. The absence of a VPN or proxy establishes that the network context was consistent with the cardholder's typical session pattern. Session depth and interaction timing establish that the cardholder browsed, selected, and authorised in a sequence that reflects real intent.
The format matters as much as the content. cside's session record is structured and exportable in a format that dispute teams can review and that card scheme arbitration processes accept as a merchant submission. It is a factual record, not a vendor's probability assessment. An issuer reviewing a merchant submission that contains a timestamped record of the session environment, device fingerprint consistency with prior undisputed transactions, and absence of manipulation signals is evaluating evidence. An issuer reviewing a risk score number is evaluating a vendor's claim.
The browser-layer record also covers the script environment in a way that no other evidence format does. Merchants who operate complex third-party script environments (analytics, advertising, checkout tooling) may have session-level script anomalies that are relevant to dispute context. A session where a third-party script behaved unexpectedly, or where a script present in the disputed transaction was absent in previous undisputed ones, is a detail that a forensic session record captures and a visitor ID or risk score does not.
In cside's chargeback evidence deployments, the session elements that dispute resolution teams most consistently request are the device fingerprint consistency record across prior undisputed transactions and the network context at the transaction moment, specifically the absence of VPN or proxy mediation. These two elements correspond directly to what Visa CE3.0 and Mastercard's dispute frameworks require, and they are elements that a risk score or visitor ID submission typically cannot provide.
More on cside's chargeback evidence capability and how it integrates with dispute workflows.
The first-party misuse problem and why evidence quality is the determining variable
Quick answer: Friendly fraud (a cardholder authorising a transaction and then disputing it) is an evidence problem, not a fraud detection problem. The risk score correctly approved the transaction because it looked like a real authorisation, because it was one. The cardholder denies presence at the moment of dispute. Without session-level forensic evidence demonstrating presence, the evidentiary asymmetry defaults in the cardholder's favour.
The MRC 2026 Global eCommerce Payments and Fraud Report found that 64% of merchants report a meaningful increase in first-party misuse. The defining characteristic of first-party misuse is that the cardholder was genuinely present and authorised the transaction. The dispute is filed after the fact, often with the assertion that the charge was not recognised or was not authorised.
Standard fraud detection is not designed to catch this. A real cardholder using their real device and browser to make a purchase that they intend to dispute later will produce a session that looks entirely legitimate. There are no automation signals, no proxy network, no device anomalies. The risk score is low because the transaction is genuinely not fraudulent at the moment of occurrence. The fraud (the disputed chargeback) happens weeks later.
The merchant's problem at the moment of dispute is asymmetric: the cardholder says they did not do it, and the merchant has to demonstrate that they did. With a risk score and a visitor ID, the merchant can say: "Our fraud model approved this transaction and we recognise the device." With browser-layer session evidence, the merchant can say: "Here is the specific browser environment and session record from the moment of authorisation, here is how it matches the three prior undisputed transactions from the same device in the previous 60 days, and here is the absence of any signal that would indicate the session was not a real, unmediated human authorisation."
The second statement meets the compelling evidence standard. The first does not. That is the operational difference between evidence and verdict.
For merchants where first-party misuse has become a meaningful portion of dispute volume, the investment in browser-layer evidence changes the financial outcome of those disputes without changing the fraud detection logic at the transaction moment. The transaction was correctly approved; the question is what evidence exists to defend it if disputed. cside is SOC 2 certified. Full security posture and integration documentation is at trust.cside.com.
