The customer says they did not buy it. Your evidence is a log you wrote yourself.

First party misuse is the dispute a merchant usually loses, because the evidence submitted is data the merchant generated about itself. Agentic checkout makes that worse in a specific and under discussed way: every signal in the evidence package now describes the agent rather than the human. The next compelling evidence is not more telemetry.

Picture the dispute queue at a mid-size online retailer on a Tuesday morning. Four hundred and twelve open cases. The analyst working them has a template, and the template is good, because the team has been refining it for three years.

For each case, the template assembles the same package. The IP address the order came from, and a note that it matches the IP on four previous orders from the same account. The device identifier, with its first seen date fourteen months ago. The account creation date. The email address, verified. The delivery confirmation with a GPS coordinate and a photograph of a parcel on a doormat. The login timestamp, eleven minutes before checkout. The shipping address, unchanged since 2024.

It is a thorough package. It represents real engineering effort and a real annual spend. And in the specific category the analyst is working today, first party misuse, where the cardholder genuinely made the purchase and later told their bank they did not, the team wins well under half.

The reason is not that the package is weak. The reason is that every single item in it is a statement the merchant made about itself. The IP address is in the merchant's log because the merchant's server wrote it there. The device identifier is a value the merchant's own script generated and stored. The delivery photograph was taken by a carrier the merchant paid. When an issuer weighs a cardholder saying "I did not authorise this" against a merchant saying "our records show they did", the issuer is not comparing two pieces of evidence. It is comparing a person's statement against an interested party's file, and there is an obvious default.

What is first party misuse, and why does it dominate disputes?

The industry term of art has shifted over the last few years from friendly fraud to first party misuse, and the change is more than cosmetic. Friendly fraud sounds like a category of criminal, which frames it as a fraud detection problem. First party misuse describes what actually happened: the party who made the purchase is the party who disputed it.

It covers a spectrum that is worth separating, because the cases are genuinely different and lumping them together is part of why the problem is handled badly.

The deliberate abuser

Someone orders goods, receives them, and disputes the charge knowing exactly what they are doing. This is theft with extra steps. It is the smallest of the three groups and the one most discussion focuses on.

The confused household

A teenager makes an in-app purchase. A partner orders something on a shared card. A subscription renews under a billing descriptor that reads like a company nobody recognises. The cardholder is entirely sincere when they say they did not make the charge, because they did not. Someone in their home did.

The customer using the wrong tool

This is the largest and least discussed group. A customer wants a refund, finds the merchant's returns process slow or hostile, and discovers that their bank will reverse the charge in a phone call. The chargeback system, designed as a consumer protection mechanism of last resort, has become the fastest customer service channel available. Many customers do not know it is supposed to be a last resort at all.

Published estimates put first party misuse at a majority of all disputes in card-not-present retail, with figures commonly quoted in the sixty to seventy five percent range. Treat those as industry estimates rather than measured facts, because there is no authoritative census: the classification depends on the issuer's reason coding and on judgments no external party audits. On the returns side, the National Retail Federation's annual returns research has put total United States retail returns in the high hundreds of billions of dollars with a single digit percentage assessed as fraudulent, which produces a fraud figure in the tens of billions. Again, worth citing and worth hedging: the fraudulent share is a survey based estimate from retailers, not a count.

Whatever the precise share, the operational reality in the dispute queue is not in doubt. This is the largest category, and it is the category with the worst win rate.

Why does merchant telemetry fail as evidence?

Here is the analogy that makes it click. Imagine you are in a dispute with your landlord about whether you paid rent in cash last March. You produce your own handwritten ledger showing the payment. The ledger is neat, contemporaneous, internally consistent, and covers three years without a gap. It is also entirely in your handwriting, in a book you control.

The ledger is not worthless. A judge might find it persuasive alongside other things. But it is categorically different from a receipt signed by the landlord, because the receipt carries something your ledger cannot: an assertion by the other party, made at the time, that they cannot now retract by simply disagreeing.

Merchant dispute evidence is the handwritten ledger. Consider each item:

Notice the pattern in the weight column. The two rows that carry real weight are the two where the evidence did not come from the merchant. 3-D Secure works as evidence precisely because the issuer performed the authentication and therefore cannot dispute its own record. That is not a coincidence, and it is the design principle worth extracting.

The privacy tooling problem, which is nobody's fault

There is a second, quieter erosion happening underneath. The signals in the low weight rows are also the signals that browser vendors, operating systems, and privacy regulation have spent a decade weakening on purpose. IP addresses are relayed or masked. Third party storage is partitioned or blocked. Device identifiers are randomised. Every improvement in consumer privacy, all of it defensible and much of it legally required, removes another element from the merchant's evidence package.

Merchants are therefore investing in collecting a class of data that is simultaneously getting harder to collect and less persuasive when collected. That is a bad trend to be on the wrong side of.

Does Visa's Compelling Evidence 3.0 fix this?

It genuinely helps, and it deserves to be described fairly rather than dismissed.

Visa's Compelling Evidence 3.0 remedy, introduced in 2023 and expanded since, addresses card-absent fraud disputes under the reason code used for fraud claims. The mechanism is elegant. If a merchant can show that the disputed transaction shares identifying elements with prior transactions from the same cardholder that were never disputed, and those prior transactions are at least a certain age and count, the merchant can have the dispute reclassified. The shared elements are things like the device identifier, the IP address, the delivery address, or the account login.

Why this is real progress: it changes the question from "prove this single transaction was authorised", which is nearly impossible after the fact, to "show this is an established relationship", which is often provable. It gives merchants a defensible path in a category where they previously had none, and reported win rates on qualifying disputes improved meaningfully.

Now the limitation, stated precisely. The remedy establishes a history. It does not establish intent at the moment of purchase. It says this cardholder has bought from you before under these conditions without complaint, which is a strong circumstantial argument and is not the same class of thing as evidence that this person authorised this order.

And the remedy's matching elements are, by design, drawn from exactly the low weight rows in the table above. It is built on device identifiers and IP addresses. Which means the remedy inherits both of the erosions already described: privacy tooling degrades the matching elements, and, as the next section covers, agentic checkout makes them describe something other than the human.

What happens to dispute evidence when an agent does the buying?

This is where the problem changes from difficult to structurally broken, and it is worth working through slowly because the industry has not yet absorbed it.

An AI agent completes a purchase on a person's behalf. Perhaps it is booking travel from an itinerary, reordering supplies, or acting on a standing instruction. Now walk the evidence package line by line and ask who generated each item.

The IP address belongs to the agent's execution environment, which may be a cloud region in a different country from the customer. The device identifier, if one exists at all, identifies a headless browser instance created for this task and destroyed afterwards. There is no session in the human sense, no mouse movement, no dwell time on the product page, no cart abandonment and return. The login, if any, used a credential the human granted the agent at some earlier point. The behavioural signals that fraud models depend on either do not exist or look, correctly, like automation.

So the merchant's evidence package is not weakened. It is describing a different entity. Every element accurately characterises the agent. None of it characterises the human whose card was charged and who is now disputing.

Then the dispute arrives, and it is a sentence that has no resolution procedure anywhere in the current system: my agent did it, and I did not authorise that.

Consider how genuinely hard this is. The claim might be entirely true. The human may have granted an agent broad access and the agent may have bought something outside what any reasonable person would have intended. It might be false, and the human simply regrets the purchase. It might be somewhere in between: authorised in general, not authorised in this instance, a boundary nobody wrote down. Neither party holds an artifact that distinguishes these cases, because no artifact was ever created.

This is why the problem is structural. Pre-agent, merchant telemetry was weak evidence about the right subject. Post-agent, it is strong evidence about the wrong subject. Improving the telemetry makes it better at describing software.

What would receipt grade evidence look like?

The principle to extract from the 3-D Secure row of the table: evidence carries weight when it was produced by a party that cannot later retract it, and can be verified by someone who trusts neither side.

A signed purchase receipt has that shape. At the moment of order confirmation, for transactions above whatever threshold the merchant chooses, the buyer's own device signs the order details. Not a click on a button, which is a merchant recorded event. A cryptographic signature from a key held in the buyer's hardware, over the specific contents of this order.

{
  "type": "purchase.authorization",
  "merchant_id": "mrc_481cc",
  "order_id": "ord_2026_0917734",
  "amount": "1849.00",
  "currency": "USD",
  "items_digest": "sha256:4c1f...9ab2",
  "ship_to_digest": "sha256:7d20...1e55",
  "authorized_at": "2026-09-09T14:22:41Z"
}

payload_hash = SHA-256(canonical_json(payload))
assertion    = WebAuthn.get({ challenge: payload_hash,
                              userVerification: "required" })
receipt      = { payload, assertion, credential_id }

Three properties matter, and each one addresses a specific failure described above.

First, the merchant cannot forge it. The signature is produced by a private key in the buyer's secure element, which the merchant never has. A merchant that fabricated a receipt would need the customer's hardware. This is what moves the artifact out of the handwritten ledger category.

Second, it binds to this order. The signature covers the amount, the merchant, the order identifier, and digests of the items and destination. A receipt for a different purchase does not verify against this one. Compare that to a prior transaction match, which argues from pattern rather than from the transaction in question.

Third, anyone can check it without asking anyone. Verification is a signature check against a published key. An issuer, an arbitrator, or a court can perform it offline, years later, without an API call to the merchant or to any vendor. Nobody has to be trusted for the check to be meaningful.

And when an agent is the one buying

The agent case uses the same machinery arranged differently. The human signs a delegation once, describing what the agent may do:

{
  "type": "delegation",
  "delegateKey": "ed25519:9f2c...ba71",
  "scope": { "actions": ["purchase.execute"],
             "merchants": ["mrc_481cc"] },
  "constraints": { "max_amount_per_txn": "500.00",
                   "max_total": "2000.00",
                   "currency": "USD" },
  "notBefore": "2026-09-01T00:00:00Z",
  "notAfter":  "2026-12-01T00:00:00Z",
  "maxChainDepth": 1,
  "revocationId": "rev_a71f22"
}

The agent then signs each purchase under that delegation, and the chain verifies back to the human's key. When the dispute arrives, the question stops being a contest of assertions and becomes a check anyone can run. Did a human sign a delegation covering this merchant and this amount, valid at this time, not revoked? If yes, the human authorised it and the answer is on the record. If the purchase fell outside the constraints, the agent exceeded its authority, the human did not authorise it, and the merchant should lose. Either way the dispute has an answer, and neither party had to be believed.

That last point is the one worth dwelling on. The goal is not for merchants to win more disputes. It is for disputes to have determinate answers. A merchant who loses a dispute they should lose, quickly and without a five month arbitration, is better off than one who wins slowly and randomly.

Honest limits

Network rules do not currently recognise this artifact. This is the largest caveat and it should be first. Visa and Mastercard define what counts as compelling evidence, and a third party signed receipt is not in the rule books today. A merchant cannot submit one and expect it to be dispositive. What it can do now is carry weight in issuer review, in arbitration, and in pre-dispute resolution, where discretion exists. Pretending otherwise would be dishonest.

Manav has not shipped card network integration. The receipt format and the delegation chain exist and verify. Acceptance by a card network as formal dispute evidence is a policy outcome that has to be earned through pilots and rule change proposals, not a feature that can be switched on.

A signature does not prove delivery. It proves authorisation of an order. The item not arriving is a different dispute with different evidence, and delivery confirmation remains what it always was. Do not let anyone tell you one artifact solves both.

Checkout friction is a real cost with a real number attached. Every additional step at purchase loses some conversions. If signing costs more in abandoned carts than it saves in disputes, it is a bad trade, and for a fifteen dollar order it almost certainly is. This is why thresholds matter and why any sensible deployment signs a small fraction of transactions.

It does not resolve the household case. If a family member uses the enrolled device, with the cardholder's knowledge or without it, the signature is valid. The dispute becomes a question about the household, not about the merchant, which is arguably progress, and it is not a resolution.

Adoption is two sided and therefore slow. Receipts help most when issuers accept them, issuers accept them when they see volume, and volume requires merchants to attach them first. That is a chicken and egg problem with no clever escape, only patient sequencing.

What to do this week

1. Pull your dispute win rate broken down by evidence type, not in aggregate. Most teams have never separated the categories and are surprised by which package actually wins.
2. Separate first party misuse from third party fraud in your reporting if you have not. They are different problems and averaging them hides both.
3. Count how many of your evidence elements were generated by your own systems. That count is the honest measure of your position.
4. Find out what fraction of your orders already arrive through automated or agent mediated channels. Ask engineering rather than guessing, and expect the answer to be higher than you think.
5. Set a value threshold above which a signed authorisation is worth the friction. Model it against your actual dispute cost per order rather than against a rule of thumb.
6. Check whether your payment service provider's dispute API can carry an arbitrary evidence attachment. That is the practical constraint on piloting anything.
7. Fix the customer service path that sends people to their bank. A meaningful share of first party misuse is a returns experience problem wearing a fraud costume.
8. Write down, now, what your policy will be when a customer says an agent made a purchase they did not intend. You will need it sooner than the industry timeline suggests.

The developer documentation covers the signature and delegation calls, and the demo shows the buyer side of a signed action end to finish in a browser.

Frequently asked questions

What is Visa Compelling Evidence 3.0? It is a Visa remedy for card-absent fraud disputes that lets a merchant have a dispute reclassified by showing the transaction shares identifying elements, such as device identifier, IP address, or delivery address, with prior undisputed transactions from the same cardholder. It establishes an established relationship rather than intent at the moment of purchase.

What is first party misuse? It is a dispute where the cardholder genuinely made the purchase and later told their issuer they did not. It spans deliberate abuse, honest household confusion where someone else used the card, and customers using a chargeback as a faster refund channel. Industry estimates place it at a majority of card-not-present disputes.

Why do merchants lose friendly fraud disputes? Because their evidence is telemetry they generated about themselves. IP addresses, device identifiers, session logs, and delivery scans all come from merchant controlled systems. When an issuer weighs a cardholder's statement against an interested party's own file, the cardholder's statement usually prevails.

Who is liable when an AI agent makes a purchase? Liability is unresolved, and the deeper problem is evidentiary. Every merchant side signal was generated by the agent, so it describes software rather than the human being charged. Without a delegation record showing what the human authorised, neither party holds an artifact that distinguishes an authorised agent purchase from an unauthorised one.

How can a merchant prove a customer authorised a purchase? The durable method is a signature from the buyer's own device over the specific order details, producing a receipt that the merchant cannot forge and that any third party can verify offline. For agent purchases, the equivalent is a delegation chain proving the human authorised an agent within a scope covering this transaction.

Would signed receipts add friction to checkout? Yes, and that is why thresholds matter. Signing every transaction would cost more in abandoned carts than it saves in disputes for low value orders. A sensible deployment signs a small fraction of transactions, chosen by value or risk, where the dispute cost per order justifies one extra step.

Do card networks accept signed receipts as evidence today? No. Network rules define what counts as compelling evidence, and a third party signed receipt is not in the rule books. It can carry weight in issuer review, arbitration, and pre-dispute resolution where discretion exists, but formal acceptance requires rule changes that have to be earned through pilots.

Sources

1. Visa, core rules and product and service rules, including the compelling evidence remedy for card-absent dispute categories. usa.visa.com Visa Rules
2. National Retail Federation, annual research on retail returns and returns fraud. nrf.com
3. Mastercard, chargeback guide and first party trust programme documentation. mastercard.us
4. EMVCo, EMV 3-D Secure specifications, for what issuer authentication asserts and how liability shifts. emvco.com
5. Merchant Risk Council, industry research on dispute categories and win rates. merchantriskcouncil.org
6. Agent Payments Protocol, specification for agent mediated payment mandates. ap2-protocol.org
7. Stripe, disputes and evidence submission documentation, as an example of what a payment service provider evidence package carries. docs.stripe.com/disputes
8. World Wide Web Consortium, Web Authentication specification, for the assertion and challenge mechanics referenced above. w3.org WebAuthn

Evidence you generated about yourself is a ledger in your own handwriting. The receipt has to come from the other side of the transaction.