How AI agents read your return policy

Returns are filed under after-sales, which is why almost nobody treats them as a discovery problem. In an agentic purchase the order reverses: the agent asks whether the item can come back before it decides to buy, and it reads the answer from typed fields rather than from your returns page. Most merchants have never written those fields, and a surprising number have a policy published anyway, by Google, on their behalf.

Reviewed September 17, 2026 · 11 min read

A human shopper reads your return policy after something goes wrong. An agent reads it before deciding whether to put the item in the cart at all, because returnability is a filterable attribute in exactly the way that price and availability are. Ask an assistant for running shoes you can send back if they do not fit and you have handed it a constraint, and it will satisfy that constraint using whatever data it can actually parse.

This is not a speculative reading of where things are going. Google describes its Universal Commerce Protocol as covering the whole shopping journey, from discovery and buying through to post-purchase support, and the Agentic Commerce Protocol carries refunds in its order webhooks rather than leaving them outside the spec. The people building these rails treat the return as part of the transaction. Most merchants still treat it as a page in the footer.

The gap between those two views is where this guide lives. Your return policy exists as three separate objects, and they are maintained by different people, updated at different times, and read by different consumers.

If you publish nothing, Google writes one for you#

Start here, because it is the fact that changes how merchants feel about the rest of it. Google does not treat a missing return policy as a blank. Its documentation explains that a listing annotated with the phrase "For most items" means Google was able to determine your return policy without you uploading it.

Read that again. The policy shown next to your products, which an agent may read and repeat to a buyer as though you had said it, can be Google’s inference from your site rather than your statement of your own terms. You do not get to opt out of having a return policy in this channel. You only get to choose whether it is yours.

The enumerations are the policy#

"Thirty-day hassle-free returns" is a sentence. What a machine consumes is a typed record with a small set of permitted values, and the translation between the two is where merchants lose information they meant to convey. The structure is MerchantReturnPolicy, and it is unusually forgiving: you satisfy the requirement either by giving a country and a category, or by giving a link to your policy page and nothing else.

The category has exactly three permitted values, and choosing between them is the single most consequential decision in the whole record:

• MerchantReturnFiniteReturnWindow, which then requires merchantReturnDays as an integer. This is almost everyone.
• MerchantReturnUnlimitedWindow, for a lifetime or no-deadline policy.
• MerchantReturnNotPermitted, which is a complete and legitimate answer rather than an admission of failure.

That third value deserves defending, because merchants avoid it out of a sense that saying no will cost them placement. It will cost you the buyers who needed returns, which is the point: those are the buyers who would otherwise have returned the item. Stating MerchantReturnNotPermitted plainly is better for you than leaving the field empty and letting an inference promise something you do not offer, and it is better for the buyer than a surprise at the end.

{
  "@context": "https://schema.org",
  "@type": "MerchantReturnPolicy",
  "applicableCountry": "US",
  "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
  "merchantReturnDays": 30,
  "returnMethod": "https://schema.org/ReturnByMail",
  "returnFees": "https://schema.org/FreeReturn",
  "refundType": "https://schema.org/FullRefund"
}

Note that the enumeration values are full schema.org URLs, not bare strings. Writing "FreeReturn" where the parser expects the URL is the most common way this markup silently fails validation, and the same trap catches people in JSON-LD generally.

Where it goes, and the nesting people get wrong#

There are two placements and they are not interchangeable. Your standard, business-wide policy nests under Organization using the hasMerchantReturnPolicy property. A policy that applies to one product nests under that product’s Offer, and supports a smaller subset of properties.

The organization-level placement inherits a rule worth remembering from how agents identify your business: Organization markup belongs on one page describing your company, not injected sitewide by a plugin. A return policy repeated on four hundred pages is not four hundred times more convincing. It is four hundred opportunities for one of them to fall out of date.

Free returns became a filter, not a nicety#

Who pays for the return trip is expressed in returnFees, with three values: FreeReturn, ReturnFeesCustomerResponsibility, and ReturnShippingFees, the last of which then requires returnShippingFeesAmount so the number is stated rather than discovered. Once that is a typed field, it is something an agent can sort and filter on, which changes it from a marketing line into a selection criterion.

The part almost nobody uses is the split between two different reasons for a return. The schema carries customerRemorseReturnFees and itemDefectReturnFees as separate properties, each with its own label source and shipping amount. That lets you say the thing most merchants actually believe but cannot express on a returns page without sounding grudging: if the item arrived broken we pay, and if you simply changed your mind you pay.

After the sale it stops being a document and becomes an event#

Everything above is the pre-purchase half. The post-purchase half is a different discipline, and merchants who nail the markup often miss it completely, because it is engineering work rather than content work.

Under the Agentic Commerce Protocol, you are the merchant of record. The buyer sees your name on their statement, and the documentation is direct about what follows: your platform is responsible for handling refunds and chargebacks, because you accepted the payment. There is no intermediary absorbing that. How AI agents pay covers the custody question underneath it.

What is easy to miss is that the obligation is not only financial. You emit order_created when the order is placed and order_updated for every subsequent change, both carrying a valid HMAC signature, and the spec asks you to notify the agent when a refund or chargeback status changes so that order state stays synchronized on both sides. A refund you process quietly in your own dashboard leaves the agent holding a stale order.

The order status values are worth knowing precisely, because there are six of them and one thing is conspicuously absent:

There is no returned status. The return is not modelled as a stage of the order’s life; it surfaces as a refund attached to an order update. That is a reasonable design given that a refund is the part with money attached, but it means the return journey your customer experiences has no direct representation in the protocol, and anything you want the agent to be able to tell them has to ride on the refund event or on your own support surface.

What to do, in order#

1. Look at your live listings for a returns annotation reading "For most items". If it is there, an inference is standing in for your policy and step two is urgent rather than optional.
2. Write the typed record: applicableCountry plus returnPolicyCategory, and merchantReturnDays if the window is finite. Use the full schema.org URLs for every enumerated value.
3. Nest the standard policy under Organization with hasMerchantReturnPolicy, on the single page that describes your company, and add product-level policies only where a product genuinely differs.
4. Split remorse from defect using customerRemorseReturnFees and itemDefectReturnFees rather than flattening both into one grudging number.
5. Make your returns page and your typed record say the same thing. A model summarising you will read the prose; an agent filtering will read the fields. Disagreement between them is worse than either one being modest.
6. If you are integrated for agentic checkout, confirm your order_updated webhook actually fires on refunds and not only on shipping. This is the single most common gap, and it is invisible until a customer asks an agent where their money went.
7. Set the seasonal override now if you extend for the holidays, with a deliberate end date.

None of this is expensive. The typed record is perhaps forty lines of JSON-LD, the webhook is a callback you probably already emit for shipping, and the whole job is smaller than the returns page most merchants have already written. What makes it worth doing is that it is one of the few remaining places where stating a fact clearly is still a competitive advantage, because so few of your competitors have stated it at all.