> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tryoto.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Return portal and customer return requests

> Set up a branded return portal, approve customer return requests, raise returns yourself in store or in the dashboard, and offer exchanges or store credit.

> [!NOTE]
>
> **Where to find it:** Settings → Return Settings → Return Portal — [Open in OTO ↗](https://app.tryoto.com/return-portal)

Every return that arrives as an email is a return you are handling twice. The portal exists so the customer does the first half themselves — and does it properly, with a reason and a photo attached.

## The branded return portal

A page of yours, on your brand, where a customer looks up their order and asks to send something back. It is configured at **Settings → Return Settings → Return Portal**, per brand.

Two things are set on the brand first, at **Settings → Account → Brands**: the **Portal URL** — the link you put on your website and in your support replies — and the **Return Policy URL**, so the rules are one click from the request.

![Return Portal settings](https://mintcdn.com/oto/ft-bRlLvOnJkbVoC/images/ret-2-portal.png?fit=max\&auto=format\&n=ft-bRlLvOnJkbVoC\&q=85\&s=e9c5ae35687869742f8c458f8c14742b)

Fig. 1 — The return period, the reasons list, and instructions written once per language — English, Arabic and Turkish as tabs on the same editor.

### The policy

| Setting | What it decides |
| - | - |
| **Portal Status** | A master switch — *“Enable or disable the return portal for customers.”* |
| **Maximum Return Period (days)** | The window. The product’s own words: *“Returns won’t be allowed past this period from the delivery date.”* |
| **Return Reasons** <sup>required</sup> | Your own list, added as chips — *“List of reasons customers can select from.”* |
| **Return Instructions** | A full rich-text editor — headings, lists, links, images, tables — with **English**, **Arabic** and **Turkish** as separate tabs. *“This information will be displayed to the customer when they initiate a return.”* |
| **Photos Required for Returns** | *“Requires a photo from the customer to submit a return request. When off, photos are optional.”* |

> [!TIP]
>
> **From the delivery date, not the order date**
>
> It is a one-word distinction with real consequences. A thirty-day window counted from purchase quietly shrinks to a fortnight on anything that took two weeks to arrive — and the customer, who has had the item for two weeks, experiences that as a policy that changes depending on how slow you were.
>
> Counting from delivery gives every customer the same thirty days with the product in their hands, which is what the policy was always meant to say.

> [!TIP]
>
> **Requiring a photo is a real choice**
>
> Turned on, every request arrives with evidence, and a damage claim can be assessed without a conversation. Turned off, the request is one step shorter and more people finish it.
>
> The honest trade is friction against certainty, and it is worth setting per business rather than copying a default: a fashion retailer taking size returns wants the shorter path, an electronics retailer taking damage claims wants the photograph.

### How the item comes back

**Allowed Return Methods** is a required choice of one or more, each with the product’s own description:

| | |
| - | - |
| **Pickup** | *“Carrier picks up the return from the customer.”* Easiest for them, most expensive for you. |
| **Drop-off** | *“Drop off at the carrier location.”* Cheaper, and fine for customers who are near one. |
| **In-store** | *“Customer returns the item at a physical store.”* Enabling it prompts them to choose which branch. |

### What they get back

**Refund Options** is a required multi-select of **Money Back**, **Exchange** and **Store Credit** — a refund to the original method, a different item instead, or the value kept with you to spend again.

![Return methods, refund options and bank details](https://mintcdn.com/oto/ft-bRlLvOnJkbVoC/images/ret-3-process.png?fit=max\&auto=format\&n=ft-bRlLvOnJkbVoC\&q=85\&s=bdc21fc6bc7dbb48681c3bc68dff0064)

Fig. 2 — Three methods, three resolutions, and the switch that decides whether the customer is asked how to pay them.

### Paying a cash customer back

Beside the refund options sits **Ask for Bank Details**: *“Request bank details from the customer for paid refunds. For COD orders, bank information is always required.”*

> [!TIP]
>
> **This is the gap cash-on-delivery leaves**
>
> A card refund reverses itself — the money goes back where it came from and nobody has to be asked anything. Cash has no route home. The customer handed notes to a driver, and there is no account to credit.
>
> So for COD the bank details are not optional and the portal insists on them, which is the difference between a refund that completes itself and one that becomes a support thread. In a region where a large share of orders are still paid in cash, that is not a detail — it is the difference between returns working and returns not.

> [!TIP]
>
> **Offer the order you want chosen**
>
> These three cost you very different amounts. A refund is revenue leaving; an exchange keeps the sale and usually keeps the customer; store credit keeps the money and buys a second visit.
>
> All three are worth offering — a customer forced into an exchange they did not want is a worse outcome than a clean refund. But which one the portal presents first, and how it is framed, is a commercial decision worth making on purpose.

### Making it look like yours

The portal carries the same customisation as the other [branded pages](https://docs.tryoto.com/modules/customer-notification/branded-pages.md): **Use Branded Header** and **Use Branded Footer**, advertisement banners and Instagram posts, and an **Advanced Settings** section for background, button and text colours. A live **Preview** renders it in **Mobile** and **Desktop** before you press **Update**.

## Returns in store

A customer who bought online and lives near one of your shops would usually rather walk in than wait for a carrier. Enabling **In-Store** lets them, and asks them to pick the branch — so the shop knows it is coming rather than being surprised by it.

> [!NOTE]
>
> **The cheapest reverse logistics is the customer’s own journey**
>
> An in-store return costs no collection, no label and no transit time, and it puts the item back in a location that can sell it. It also puts the customer in a shop, which is the one return outcome with an upside.
>
> It only works if the branch is prepared: the return still has to be received and confirmed against the request, exactly as a warehouse would — see [Returns receiving](https://docs.tryoto.com/modules/return-management/returns-receiving.md).

## Approval

A submitted request lands on the **In Progress** tab of **Shipping → Returns**, where it is approved or rejected. The customer hears either way, automatically, if the return messages are configured — **Return Request Created**, **Return Request Approved** and **Return Request Rejected** exist on [SMS](https://docs.tryoto.com/modules/customer-notification/sms.md), [WhatsApp](https://docs.tryoto.com/modules/customer-notification/whatsapp.md) and [email](https://docs.tryoto.com/modules/customer-notification/email.md).

The Returns list is built for triage. Alongside **Order ID** and **Customer Name** it carries **Request Date**, **Status**, **Return TO**, **Shipment Number**, **Delivery Company**, **Return Method**, **Return Type**, **Customer Return Reason** and **Return Approval** — all filterable, with a **Tags** column for the labels your team adds.

> [!TIP]
>
> **Filter by reason before you approve by habit**
>
> Approving requests one at a time in date order is the slowest possible way to work through them, and it hides the pattern. Filtering by **Customer Return Reason** groups the decisions that are actually the same decision — and it shows you the product that is generating them.
>
> That second thing is where returns stop being a cost center. A sizing problem visible in the reasons is fixable on the product page; the same problem discovered one refund at a time is not.

## Raising one yourself

When a customer reaches you another way, a return can be started from **Shipping → Shipments → Delivered**: select the order, **Return**, then **Create Return Order**. The form takes return reason comments and attachments, a **Refund Method** — Money Back, Exchange or Store Credit — and a **Return Method** of home pickup or drop-off, then **Confirm Return Request**.

It joins the same queue as a portal request, and from there the two are indistinguishable.

## Exchanges and store credit

An exchange is a return and a new order in one transaction, and it is the outcome worth designing for: the customer keeps their money with you, you keep the sale, and the item that comes back is usually resellable because the reason was fit rather than fault.

Store credit does the same for the cases where an exchange will not do — the customer does not want a different size, they want to choose again later.

## Related

* [Returns receiving](https://docs.tryoto.com/modules/return-management/returns-receiving.md) — what happens when the parcel arrives.
* [Return automation](https://docs.tryoto.com/modules/return-management/return-automation.md) — enforcing the policy without reading every request.
* [Branded pages](https://docs.tryoto.com/modules/customer-notification/branded-pages.md) — the same customisation, on the other pages.


## Related topics

- [Receiving and inspecting returns](https://docs.tryoto.com/modules/return-management/returns-receiving.md)
- [Return automation rules](https://docs.tryoto.com/modules/return-management/return-automation.md)
- [Return Management](https://docs.tryoto.com/modules/return-management/overview.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.