---
title: "Returns implementation"
canonical: "https://ingrid-support.refined.site/space/KB/741212179/Returns%20implementation"
format: markdown
---
Implementing Ingrid Returns follows the same [five phases](https://support.ingrid.com/space/KB/18219063/Implementation) as any Ingrid project. This page covers what is specific to Returns: the flows you choose, where returned-item information comes from, and the credentials constraint.

## The phases for Returns

| Phase | Who leads | What it covers for Returns |
| --- | --- | --- |
| [1. Scoping](https://support.ingrid.com/space/KB/741539871/Returns+scoping) | Ingrid | Which flows you offer, your return policy, who pays, where returns go, and where returned-item information comes from. |
| [2. Configuration](https://support.ingrid.com/space/KB/741670914/Returns+configuration) | Joint | The portal, product policies, price setups, return addresses, carriers, labels, and emails. |
| [3. Integration](https://support.ingrid.com/space/KB/741900311/Returns+integration) | You | Order data from your e-commerce platform, and returned-item events from your warehouse systems — or Quality check instead. |
| [4–5. Testing and go-live](https://support.ingrid.com/space/KB/741605389/Returns+testing+and+go-live) | You | Every flow end to end, including a real refund, then launching the portal. |

## What makes Returns different

Two things shape a Returns project more than anything else.

### You choose which flows to offer

Returns is not one flow but several, and you decide which are in scope:

- [Return flow](https://support.ingrid.com/space/KB/421658625/Return+flow) — the shopper sends an item back for a refund
- [Exchange flow](https://support.ingrid.com/space/KB/423493635/Exchange+flow) — the shopper swaps for a different size, color, or product
- [Claim flow](https://support.ingrid.com/space/KB/426344454/Claim+flow) — the item arrived damaged or faulty
- [Complaints](https://support.ingrid.com/space/KB/587268097/Complaints+in+Ingrid+Returns) — handled separately from claims

All of them share one entry point in the portal and branch from there, so adding a flow later is configuration rather than a new project. Deciding early still matters, because each flow has its own policy and testing implications.

### How Ingrid learns an item came back

Ingrid needs to know when a returned item physically arrives before a refund or exchange can complete. There are two routes, and this is the main scoping decision:

- **Your warehouse systems tell us.** Your OMS, ERP, or WMS sends returned-item events. See [WMS integration](https://support.ingrid.com/space/KB/420052994/Warehouse+management+system+(WMS)+integration).
- **Or your warehouse staff use Ingrid.** [Quality check](https://support.ingrid.com/space/KB/398393346/Quality+check+in+Returns) gives them a structured inspection workflow inside Ingrid — they find the return, record its condition, and trigger the refund, partial refund, or denial directly.

Which route you take changes how much integration work phase 3 involves, so settle it during scoping.

## The credentials constraint

> ⚠️ **Returns has no fallback for carrier credentials.** Return shipments are booked on your own carrier contracts, so your credentials are always required. As with Transport, there is no reduced mode: without them nothing can be booked and nothing can be tested.
> ⚠️ 
> ⚠️ They are frequently held by a 3PL or logistics team rather than the e-commerce team running the project. Starting that release request is a week-one task. See [Carrier credentials](https://support.ingrid.com/space/KB/739868692/Carrier+credentials).

## Need help

- **During implementation:** your implementation consultant is your first contact.
- **Technical questions:** [support@ingrid.com](mailto:support@ingrid.com)
- **All Returns documentation:** [Ingrid Returns](https://support.ingrid.com/space/KB/104628230/Ingrid+Returns)