Returns and Refund Requests

Let customers start a return from their order and follow it through to a refund.

involved User Experience

What it adds

A self-service return flow attached to each order, with item selection, a reason, and a tracked status through to resolution.

What your agent is told to do

1
Start the flow from the order itself, not from a generic support form. The customer should pick the items and quantities from the order they are already looking at.
2
Ask for a reason from a short fixed list plus an optional note, because the fixed list is what makes the data useful and the note is what makes the customer feel heard.
3
Give the request its own visible status the customer can check without emailing anyone: requested, approved, in transit, received, refunded, or rejected.
4
Notify on every status change through the app's existing notification and email machinery rather than adding a separate mailer for returns.
5
Do not calculate the refund from the current catalogue price. Use the amounts actually charged on that order, including its discounts, shipping, and tax, or you will refund the wrong money.

Edge cases it handles

Eligibility is per item, not per order. Enforce the return window and any item-level rules such as final sale or perishables at the point of selection, and explain why an item cannot be returned rather than hiding it.
Partial returns are the normal case. A customer returning two of three units must leave the rest of the order intact, and items already refunded must be excluded from a second request.
The same line item must not be claimed twice. Reserve the requested quantity when the request is created so a duplicate request cannot be opened in another tab.
Order-level discounts have to be apportioned across the returned items, otherwise a customer returning one item from a discounted order gets back more than they paid.
A rejected return needs a stated reason and a next step, and a return that is approved but never arrives needs an expiry after which the request closes on its own rather than sitting open forever.
Refunding shipping is a policy decision, not an implementation detail. Make it explicit and apply it the same way every time.
Guest orders need a way in. Verify by order number and email rather than requiring the customer to create an account to return something.
A refund issued through the payment provider can fail or arrive days later. Record the provider's own state and never mark the request refunded until the provider confirms it.

Definition of done

A customer can open a return from an order and select specific items and quantities.
Ineligible items are shown as ineligible with the reason, not silently omitted.
The same line item cannot be included in two open requests.
The refund amount matches what was charged for those items including apportioned discounts.
Every status change is visible to the customer and triggers a notification.
Rejected and abandoned returns reach a terminal state rather than staying open indefinitely.
Receipts and invoices remain available after a refund and show the adjustment.
The feature matches the existing design system.
No existing functionality is broken.

Related features

Feedback Widget

Interactive Transcript

Booking Page

How it works

1

Copy the link

Grab the Markdown instruction URL for this feature.
2

Give it to your AI

Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
3

It inspects, then implements

Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.