How AI agents read your return policy

Return terms can influence the purchase before an item reaches the cart. Keep the policy page, structured fields and post-purchase workflow aligned so customers know what they can return and how the refund works.

Reviewed October 1, 2026 · 7 min read

A shopper asking for shoes they can return if they do not fit has made returnability part of the buying decision. People and assistants may check the window, item condition, fees and refund method before recommending or purchasing an offer.

The policy needs to be understandable before purchase and workable afterward. A clear page is useful, but it must agree with any merchant-platform settings, structured data and support process.

Review these three parts together:

Check the policy shown beside your listings#

A shopping platform may derive policy information from your website as well as accept merchant submissions. Inspect the actual return annotation on important listings, especially when terms or product exceptions change.

Do not assume that an automatically extracted summary matches every detail. Compare it with the applicable policy and use the platform's correction process if it is wrong. Submitting structured data does not guarantee immediate or identical display.

Translate the policy into supported fields#

Google's merchant return policy guidance describes MerchantReturnPolicy markup. For the organization-level record, it supports an applicable country and policy category, or a policy link alternative. Follow the documented requirements for the placement you use.

For returnPolicyCategory, Google's documented values distinguish a finite window, an unlimited window and returns not being permitted:

• MerchantReturnFiniteReturnWindow: include the number of return days and make the start of that window clear.
• MerchantReturnUnlimitedWindow: use only when the applicable policy genuinely has no time limit.
• MerchantReturnNotPermitted: use for the applicable policy where returns are not offered, while preserving any mandatory rights and exceptions.

A schema value describes the policy; it does not decide whether that policy is lawful or accepted by a platform. Keep category restrictions, defective-item treatment and applicable consumer rights clear. The following example is illustrative, not a policy to adopt without review:

{
  "@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"
}

Use the documented Schema.org values and validate the result. Also check the meaning: a syntactically valid 'FreeReturn' value is wrong if the customer actually pays a return charge. See the JSON-LD guide for validation basics.

Where it goes, and the nesting people get wrong#

Google supports a standard policy under Organization through hasMerchantReturnPolicy, and product-specific policies under the relevant Offer. The offer-level supported properties are more limited, so do not copy every organization field into an offer without checking.

Google recommends a page describing the business's return policy and says repetition on every page is unnecessary. That is not a blanket ban on consistent repeated markup. Keep one maintained policy source and make exceptions explicit.

Explain fees and return reasons#

State who arranges and pays for the return shipment, whether a restocking fee applies and how the customer receives the refund. Use the supported return-fee values and amounts where appropriate. Keep the same explanation on the visible policy page.

Some structured fields distinguish a change of mind from a defective item. Use that distinction where your policy and the target consumer support it. Do not flatten materially different terms into one misleading fee value.

Keep the customer informed after purchase#

A return request, received parcel and completed refund are different events. Your support process and connected applications should report the actual state, not treat all three as 'returned.'

Refund and dispute responsibilities depend on the merchant, payment arrangement and platform contract. Identify who handles the request and how the customer reaches them. The agent payments guide explains the relevant boundaries.

For an integrated checkout, follow the exact versioned order-event contract. Authenticate callbacks where required, handle duplicate delivery and reconcile changes with the payment and order systems. Do not assume one protocol's event names or signature scheme applies to every integration.

These are useful business states to track, regardless of the protocol-specific field names:

Map those states to the events your integration actually supports and provide a support route for information it cannot carry. A partial refund or exchange may need more context than a single order status.

What to do, in order#

1. Compare visible policy text with representative shopping annotations and merchant settings.
2. Publish supported policy fields, including the correct country, category and finite window where applicable.
3. Attach the standard policy and product exceptions at the appropriate level.
4. Explain return shipping, restocking, defect and change-of-mind treatment clearly.
5. Validate the live markup and check that the operational returns process honors the same terms.
6. Test refund and order updates, including retries and partial refunds where supported.
7. Review seasonal boundaries and remove expired promotional wording.

The result should be a policy customers can understand and your team can apply consistently. Good structured data communicates that policy; it does not replace the operational process or resolve a dispute on its own.