What should I change in my returns process before agent volume grows?

Two things. Record which agent or surface placed each order so you can analyse behaviour by channel. And publish your returns policy in a machine-readable form so assistants state it accurately when a shopper asks, rather than guessing.

← Insights

Returns, Refunds and Chargebacks on Agent-Placed Orders

Q: Who handles a return when an AI agent placed the order?

You do. You are the merchant of record, so the return runs through your normal policy and process. The practical complication is matching the order to a customer, because the identity details may have been supplied by the agent rather than entered by the shopper.

Q: Who loses the chargeback on an agent-placed order?

The merchant, in the same way as any card-not-present transaction. The difference is evidentiary: the usual defence material such as session and browsing logs may not exist for an agent-placed order, so capturing agent and authorisation metadata at order time matters more than usual.

Q: Do agent orders have higher return rates?

Where they do, the cause is usually ambiguous product data rather than the agent itself. If variants, sizing or compatibility are unclear in your feed, an agent resolves the ambiguity with its best guess and the shopper returns the result.

The question every ops team asks second, right after "can an agent buy from us". Here is how returns, refunds and disputes actually work on agent-placed orders.

Tru Commerce Team · September 17, 2026 · Checkout & Protocols

Returns, Refunds and Chargebacks on Agent-Placed Orders — Tru Commerce guide

This post in 30 seconds

You remain the merchant of record on an agent-placed order, so the refund obligation and the chargeback liability are yours - the assistant is a referrer, not a reseller.
The hard operational problem is identity: your returns flow assumes an email address and an account, and an agent-placed order may arrive with neither in the usual place.
Disputes are harder to defend because the usual evidence - session logs, browsing history, on-site consent - either does not exist or sits with the agent platform.
Fix the boring things first: make sure the order record captures which agent placed it, and that your returns policy is machine-readable so agents state it correctly up front.
Most returns on agent orders trace back to ambiguous product data, not to the agent. Variant and sizing precision is a returns lever, not just a visibility one.

This is the question ops teams ask second, right after "can an agent buy from us at all". It gets much less coverage than the first one.

TL;DR

You are the merchant of record, so the refund obligation and chargeback liability are yours. The assistant referred the sale; it did not resell it.
The real difficulty is identity matching - your returns flow assumes an email and an account, and an agent-placed order may not present either in the usual place.
Disputes are harder to defend, because the evidence you normally submit either does not exist or sits with the agent platform.
Most elevated return rates on agent orders trace back to ambiguous product data, not to the agent.

The liability question, answered plainly

When an assistant places an order with you, you are still the seller. That means the refund runs through your policy, the return runs through your process, and if the cardholder disputes the charge, you defend it.

This surprises people who assume the agent platform acts as a marketplace intermediary. On the current rails it generally does not. It is closer to an affiliate that can also press the button.

Where it actually gets difficult

Identity. Your returns portal asks for an order number and an email. If the agent supplied a relay address, or completed the purchase through a flow that did not create an account, the shopper arriving to return something may not match any record they can prove is theirs. This is the single most common operational failure, and it is boring to fix and cheap to fix early.

Evidence for disputes. A card-not-present dispute is usually defended with session data: the IP, the device, the browsing path, the consent checkbox, the delivery confirmation. For an agent-placed order, several of those either do not exist or belong to the agent platform. Capture what you can at order time - which agent, which authorisation reference, what the agent was told about price and policy - because you cannot reconstruct it later.

Policy mismatch. If an assistant tells a shopper your returns window is 30 days and it is 14, the shopper will act on the assistant's answer. You will absorb the difference or take the complaint. Assistants get this wrong when your policy is not stated in a form they can read reliably.

The returns cause nobody expects

When agent-placed orders come back at higher rates, the instinct is to blame the agent for buying carelessly. In practice the cause is usually upstream and fixable.

An agent resolves ambiguity by guessing. If your feed lists three variants with near-identical titles, if sizing is described only in an image, if compatibility is implied rather than stated, the agent picks the option it can describe most confidently - which is not necessarily the one the shopper wanted.

That is a data problem wearing a returns problem's clothes. Tightening variant titles, stating sizing and compatibility as text, and keeping availability accurate reduces returns and improves visibility at the same time, because the same clarity that prevents a wrong pick also makes the product easier to recommend.

What to do before volume arrives

Tag the channel. Record which agent or surface placed each order. Without it you cannot tell whether agent orders behave differently, and you will be guessing when someone asks.

Make the policy machine-readable. Returns window, conditions, who pays return shipping. If an assistant can read it, it will quote it correctly.

Capture dispute evidence at order time. Agent identifier, authorisation reference, the price and policy presented. Cheap to store, impossible to recover.

Audit the top-returned SKUs for data ambiguity. Not for quality problems - for description problems.

Every agent purchase ends on a rail a merchant already runs: a Link single-use card, Shop Pay, Google Pay, a Stripe Shared Payment Token or a saved card behind a login, and Stripe put Link's agent purchases at more than 1 million businesses that accept it (Stripe, 8 September 2026). Which rail a disputed agent order came in on decides who you call first; the rails, the protocols and the liability map are in the agentic payments guide, and the fraud question is in who is liable when an AI agent makes a fraudulent purchase.

Where Tru Commerce fits

The catalog work that reduces wrong picks is the same work that makes your products legible to agents in the first place. If you want to see how assistants currently describe and rank your products, start with a free Citation Rank scan.

FAQs

Q: Who handles a return when an AI agent placed the order? A: You do. You are the merchant of record. The complication is matching the order to a customer when identity details were supplied by the agent.

Q: Who loses the chargeback on an agent-placed order? A: The merchant, as with any card-not-present transaction. The difference is that the usual defence evidence may not exist, so capture agent and authorisation metadata at order time.

Q: Do agent orders have higher return rates? A: Where they do, ambiguous product data is usually the cause rather than the agent itself.

Q: What should I change before agent volume grows? A: Record which agent placed each order, and publish your returns policy in a machine-readable form.

FAQ

Book a demo

September 19, 2026

From recommended to transacted: agentic commerce

Getting recommended is the on-ramp; being transactable is the destination. Adobe has AI-referred retail visits converting 60% higher than other traffic in July 2026, yet most brands still make an agent find them and then dead-end it at a checkout it cannot complete. The series finale: why discovery without transactability leaks the value, what ACP, UCP and AP2 do, and how a recommendation becomes a purchase inside the chat.

September 17, 2026

Who Is Liable When an AI Agent Makes a Fraudulent Purchase

Three parties could plausibly carry an unauthorised agent purchase. Today, in most cases, it is the merchant. Here is why, and what reduces the exposure.