Documentation

Returns & refunds

Returns arrive as structured requests instead of email threads, and refunds are approved from a queue rather than pieced together by hand in Shopify. Money never moves without a person approving it, unless you explicitly configure otherwise.

The return portal

The return portal is a customer-facing page where a shopper looks up their order and submits a return, without emailing you first. Returns are enabled per brand, and each brand gets its own portal — you can run it on a Squid Support URL, or map your own domain such as returns.yourbrand.com.

The shopper journey is short:

1. They find their order.
2. They pick the items they want to return and choose a reason from the list you configured.
3. They see whether the return is allowed, and what they will get — depending on the options you offer.
4. They submit, and the request lands in your inbox.

The portal is translatable, so the language your customers see is a per-brand setting rather than something hardcoded.

Testing before you go live

Each brand has a test mode and a test email address, so you can walk the entire portal flow yourself before pointing customers at it. Do this once before publishing the link — it is the fastest way to catch a return reason that reads oddly or a policy that is stricter than you intended.

Return reasons

Reasons are what turn returns into data you can act on. You start from a reason template and can override it per brand with your own custom set, so a clothing brand asking about fit and a homeware brand asking about damage are not forced into the same list.

Choose reasons a customer can answer honestly and that you would actually act on differently. “Wrong size” and “Arrived damaged” lead to different operational responses; “Other” leads to none.

Return policies

Eligibility is evaluated when the shopper looks up their order, so someone outside your policy is told at the portal rather than after posting a parcel back. The controls available per brand include:

• Time windows — measured from the events that actually matter, with separate limits available for days since delivery, since fulfilment, and since the order date.
• A minimum order age, so an order placed an hour ago is not immediately returnable.
• Blocking in-transit orders, so a parcel still on its way cannot be returned before it has arrived.
• Requiring tracking on the return leg.
• A maximum order value, above which the portal stops and shows a message you write — typically directing high-value returns to a human. This can be given a start date so it applies only to orders placed after you introduced the rule, rather than retroactively changing the deal for existing customers.

Eligibility is decided per product, not just per order, so a mixed basket where only some items qualify behaves sensibly.

The Refund Hub

Refund Hub is the approval queue. It is enabled per organisation — until it is switched on, the section shows an explanation and an Enable Refund Hub button rather than a queue.

Requests arrive with everything needed to decide: the customer, the order, the amount, the reason, the category, and a link through to the conversation the request came from. Each request is either a partial refund covering specific line items and quantities, or a whole order refund — and the queue shows which, so nobody approves a full refund thinking it was for one item.

Every pending request offers three actions:

• Approve — the refund is created in Shopify against the original order. This is a real money movement.
• Deny — recorded with a reason.
• Manual — marks the request for handling outside the normal flow, for the cases that need a human to do something bespoke.

Approving writes the refund to Shopify directly, using an idempotency key so a retry or a double-click cannot produce two refunds for the same request. If Shopify rejects the refund, the request stays pending and the error is recorded against it rather than being lost — so a failed refund stays visible in the queue instead of appearing done.

Photo evidence

For damage and not-as-described claims, you can require photos before deciding. A photo evidence request captures the order, the item, its price, the stated reason and the images the customer uploads.

Reviewing a submission gives you three outcomes: approve it, reject it, or request new photos — the last being useful when what arrived is genuinely unusable, such as a blurry close-up of nothing identifiable. Reviews record who decided, when, and any notes or rejection reason.

Auto-refunds and limits

Refund categories carry policy limits set per organisation: a maximum refund percentage, and whether that category is permitted to refund a whole order at all. Those limits are what the AI refund tool works within, and the limits in force are captured on the request itself, so a decision made months ago can still be read against the policy that applied at the time.

Where auto-refunds are enabled, low-risk refunds inside those limits can be processed without waiting for approval; if an auto-refund does not complete, it falls back to a pending request in the queue rather than being dropped. Anything outside the limits — a larger percentage, or a whole-order refund in a category that does not allow one — arrives as a pending request for a person.

If you want every refund reviewed, leave auto-refunds off. In draft mode the AI does not execute refunds at all.

The audit trail

Each processed request records who approved or denied it — by their email address — and when, along with any notes, the denial reason, and the resulting Shopify refund identifier. Refund history and auto-refund activity are both viewable in Refund Hub, so “who approved this and why” is answerable months later without digging through Shopify.

This matters for more than tidiness: it is what lets you delegate refund approval to your team without losing accountability for money leaving the business.

A reasonable starting configuration

1. Enable returns for the brand and choose your reason set.
2. Set your time window and, if you sell high-value items, a maximum order value with a message directing those customers to your team.
3. Enable Refund Hub and leave auto-refunds off until you have watched the queue for a week or two.
4. Turn on photo evidence for damage-related reasons.
5. Walk the portal yourself in test mode, then publish the link on your storefront.

Loosen the rules once you can see what your actual return traffic looks like — it is much easier to relax a policy than to claw back a refund. Questions about a specific request: email hello@squidsupport.ai with the order number.