Trust, Fraud, Disputes and Returns

Why this module exists

Every agentic commerce discussion is about acquisition. The losses are on the other side.

An agent-initiated order raises questions your operation has never had to answer: who authorised this, what evidence do you hold, who is liable when the cardholder says they did not want it, and how does a machine return something. These are not future problems in the way protocol adoption is a future problem — the first agent order arrives whether or not you have decided, and the answers are then made up by whoever is on shift.

This module is short and unglamorous, and it is the one most likely to save real money.

8.1 What is actually different

Three changes, each with an operational consequence.

The buyer and the payer may be different entities. A person delegates; software acts. Your fraud stack was built on the assumption that unusual behaviour indicates a bad actor — and agent behaviour is, by construction, unusual: fast, precise, comparison-heavy, arriving from unfamiliar infrastructure. Your first agentic commerce problem is likely to be false declines, not fraud.

The mandate is invisible to you. The customer told the agent "buy a rug under €200 in a dark colour." You never see that instruction. If they later dispute the purchase because they expected something else, the evidence sits with the agent platform.

Authorisation is scoped. The payment networks have moved deliberately here: Visa and Mastercard have shipped agent-scoped credentials and identity mechanisms through 2025–2026 precisely so an agent-initiated transaction can be distinguished at the network level, and therefore scored, authorised and disputed differently from a card-present or ordinary card-not-present sale.

8.2 The liability position, stated honestly

This is where a course must be careful, because the honest answer is that it is unsettled.

What is reasonably clear as at August 2026:

Under existing scheme rules, a cardholder is generally responsible for what an authorised agent did within its mandate.
Networks have introduced ways to identify agent transactions, which is the precondition for differentiated rules.
Google's AP2, and the mandate concept it standardises, exist precisely because the signed record of what a human authorised is the missing evidence in this class of dispute.

What is not settled: binding, published chargeback rules specific to agent-initiated disputes. In their absence, disputes flow through existing reason codes, and merchants absorb the ambiguity.

What is settled in Europe, and is not optional

Two European positions are already law and already apply to your agent orders.

PSD2 unauthorised-transaction liability. Where a payment was not authorised by the payer, the payer's bank refunds it and then looks to recover. Whether an agent acting outside its mandate constitutes an authorised transaction is exactly the unsettled question — and it is decided on your evidence.

Consumer withdrawal rights are unaffected by who clicked. A distance sale to an EU consumer carries a 14-day right of withdrawal whether a human or an agent placed the order. Since 19 June 2026, the Consumer Rights Directive as amended also requires a clear withdrawal function in online interfaces — a specific, findable control, not a buried form. If you sell to EU consumers, that is a shipped legal requirement with a date, and it happens to be exactly the programmatic returns path §8.4 asks for. Build it once.

8.3 The evidence to capture

This is the highest-return part of the module. Capture at order time, retain per your policy, and make it retrievable by order ID in one step.

Evidence	Why it matters
Agent identity, cryptographically verified where the surface supports it	Distinguishes a legitimate agent from something wearing its name
Protocol and version used	Determines which rules and terms applied
Scope of the mandate, where passed	The single most useful artefact in a dispute over intent
Exactly what was presented — price, variant, delivery promise, terms	Defends "not as described"
Authorisation trail, including any step-up or confirmation	Defends "I did not authorise this"
Timestamps at each step	Establishes sequence when accounts differ
Fulfilment and delivery confirmation	Unchanged from today, and still decisive

The test of whether you have this: pick one order and try to assemble the pack in under five minutes. If it takes an analyst an afternoon, you do not have an evidence process, you have data in several systems.

8.4 Returns, when the buyer cannot phone you

Returns are where agentic commerce most often meets an operation that cannot serve it.

Three requirements:

A programmatic returns path. An endpoint that can initiate a return, obtain a label and report status. If your returns process begins with a web form and a human, agent-sourced orders will generate support contacts rather than returns — which is worse for both parties.

A policy that survives comparison. Agents compare terms exhaustively and cheaply. A returns window materially shorter than the category norm is now a discovery-time disadvantage, not merely a post-purchase one. This is a commercial decision that has quietly moved from operations into merchandising.

Machine-readable terms. From Module 4: if your returns policy is not marked up, engines answer questions about it from wherever they can find something — frequently a marketplace listing with different terms. Wrong returns information is a conversion problem and a dispute generator at once.

8.5 The fraud rebalance

The specific advice for your risk team:

Do not treat agent traffic as bot traffic. Your existing bot mitigation will decline exactly the transactions you want, and the decline will be invisible in your funnel because it happens at the edge.

Segment your rules. Verified agent, unverified agent, and human should be scored separately. A verified agent's unusual velocity is expected; an unverified one's is not.

Watch the new abuse shapes. Mandate abuse (an agent operating beyond what the customer intended), scoped-credential replay, and promotion or pricing-error exploitation at machine speed — an agent finds a mispriced SKU faster than any human ever did, and tells others.

Measure false declines specifically. Add a decline reason segmented by agent status. If you cannot see it, you cannot know whether your risk stack is quietly closing the channel.

The abuse shape that is genuinely new: prompt injection

Every other item above is a familiar risk with an unfamiliar actor. This one has no analogue.

An agent reads your pages. Text placed in a page — in a review, a Q&A answer, a seller description, a support thread, white-on-white in a template, or in a field a third party can write to — can be read by the agent as instruction rather than as content. Documented forms include hidden text that tells an agent to prefer one product, to ignore a competitor, to apply a discount code, or to disclose what it was told by its user. OWASP ranks prompt injection first among LLM application risks, and there is no reliable general defence.

Three things follow for a retailer, and all three are yours whether or not you ever implement a protocol:

Any surface where third parties can write to your pages is now an attack surface — reviews, community Q&A, marketplace seller content, user-generated imagery with text in it. Moderation was a brand problem; it is now also a security one.

Your own agent, if you run one, must not act on instructions found in retrieved content. Retrieved text is data. That distinction has to be enforced by design, because it cannot be enforced by asking the model nicely.

Never let injected text reach an irreversible action. Price changes, discounts, refunds and order modifications need a deterministic check that a model cannot talk its way past. If your assistant can issue a refund because a page told it to, the page is now your refunds policy.

Marlowe & Finch — the first eleven agent orders

Long before any protocol decision, eleven orders arrive that the payments manager cannot classify: same-minute checkout, unusual infrastructure, and baskets that exactly match a promotion's minimum threshold.

Nine were declined by the risk engine. Two completed; both were fine; one was later disputed.

The post-mortem finds three things.

The declines were probably wrong. Verified afterwards as legitimate delegated purchases. Nobody had told the risk team agent traffic was expected, so the rules treated speed and infrastructure as risk signals. The channel was being closed by default at the edge — the same pattern the team found in Module 2 with the CDN.

The dispute was indefensible. The cardholder said they had asked for something else. Marlowe & Finch could show what was shipped and what was charged, but nothing about what was requested or presented. They lost it, and would lose it again.

Returns had no path. The one return required a customer-service agent to create a case manually, taking eleven days against a four-day standard.

The response is a one-page policy, written before any volume exists: agent orders are segmented in the risk engine rather than blocked; the seven evidence fields are captured at order time and retrievable by order ID; the returns endpoint is on the roadmap with a date; and false declines are reported monthly by agent status.

None of it required a protocol decision. All of it would have been much harder to write after the volume arrived.

Exercise — Write the policy

Time: 60 minutes. Produces the artefact for this module.

One page, six sections.

Definition. What counts as an agent order in your systems, and how it is flagged.
Authorisation. What you require: verified identity, scoped credential, step-up conditions and value limits.
Evidence. Which of the seven fields you capture, where, and the retention period.
Disputes. Who assembles the pack, in what time, and against which reason codes.
Returns. The path an agent uses, and the service level.
Risk. How agent traffic is segmented, and how false declines are reported.

Then run the five-minute evidence test on one existing order. Whatever you cannot assemble is your first engineering ticket.

Self-check

Why is your first agentic commerce problem more likely to be false declines than fraud?
Which single piece of evidence most often decides a dispute about intent, and who holds it?
What is the honest current position on agent-dispute liability, and what does that imply for your evidence practice?
Why has your returns window become a discovery-time issue rather than only a post-purchase one?
Can your team assemble a dispute pack for one order in five minutes today?