Returns
Create and process RMAs end to end — receive, inspect, disposition, and refund — plus the reason codes customers pick from.
Returns is reverse logistics across all clients: each RMA from creation through receiving, inspection, and disposition to the refund that follows — plus the reason codes customers choose from. A brand watches this happen; you run it.
Operator vs. client view
A client tracks their RMAs and sees the results. You do the hands-on work they can't: create an RMA, process it — receive, inspect, and disposition each unit — and manage the reason codes.
The RMA list
Returns → All RMAs lists every return authorization and where it is.

| Status | Meaning |
|---|---|
| Pending | Created; awaiting the customer's shipment. |
| In Transit | On its way back. |
| Received | Arrived at the warehouse. |
| Inspecting | Being checked over. |
| Completed | Done — items dispositioned and refund resolved. |
| Cancelled | Cancelled. |
A Completed RMA shows a refund chip — Refunded, Refund pending, or Refund failed. RMAs from a connected store carry a Shopify badge; one that synced from a store without matching to an order shows as blind (you don't create those — the system does). Tabs filter by status, and you can search by RMA number, tracking, or customer.
The operator additions are the action buttons: a Pending RMA gets Receive, an in-progress one gets Continue — both open the processing flow — and Create RMA sits at the top right.
Creating an RMA
Returns → Create RMA (operator-only). Most RMAs flow in automatically when a customer requests a return in their store, but you can also raise one by hand:

Processing a return
Receive / Continue on an RMA opens the scan-guided processing flow — the operator-only work clients never touch.

Scan & Inspect. Scan the returned unit, set the quantity, and record its inspection result and disposition. The Expected Items panel tracks received against expected per line.
Disposition to a bin. The disposition is auto-suggested from the inspection result — undamaged and opened → Restock, defective → Dispose, wrong item → Quarantine. Restock suggests the Returns zone; Quarantine and Return to vendor suggest the Quarantine zone; Dispose takes no bin at all (the unit is written off, so the bin picker is hidden). Add notes, then Record Receipt.
Complete RMA. Once every unit is handled, complete the return. Restocked units flow back into sellable inventory; the refund resolves per the RMA's terms.
The inspection result constrains which dispositions are allowed — damaged or wrong-item goods can't be restocked into sellable stock:
| Inspection result | Allowed dispositions |
|---|---|
| Undamaged | Restock, Quarantine |
| Opened (still resellable) | Restock, Quarantine, Dispose |
| Defective | Quarantine, Dispose, Return to vendor |
| Wrong item | Quarantine, Return to vendor |
For lot-tracked SKUs, restocking is blocked until you pick a lot (the flow suggests the lots shipped on the order); the escape hatch is to Quarantine instead. A bin can't hold two lots of one SKU.
A raw all-caps line status shows in the Status column of the Expected
Items panel and the detail Items table (the Received column, by contrast, is a
received-vs-expected count like 0 / 1, not a status):
| Line status | Meaning |
|---|---|
PENDING | Nothing received against the line yet. |
PARTIAL | Some but not all expected units received. |
COMPLETE | All expected units received. |
OVER | More received than expected. |
SHORT | Finished with fewer than expected. |
Following an RMA
Open any RMA for the full picture across Details, Attachments, and
Timeline: the customer and reason, the return label, each returned line and
its refund type, and the receipt log (per-unit inspection result and
disposition, shown as raw all-caps like WRONG ITEM / RETURN TO VENDOR). The
detail page also carries the stage actions the list rows don't — Start
Receiving / Continue Receiving, Complete (needs at least one receipt),
and a destructive Cancel (Pending / In Transit only) — plus a Generate
Label button (only for a Pending RMA with no label or tracking yet, whose reason
policy is store-paid or flat-rate) that mints a Stallion return label emailed to
the customer.

The Refund card shows the computed breakdown and its state: Not yet issued, Ready, Issued, or Failed — retry available (the button becomes Retry Refund). Issue Refund pays it out; Adjust opens a dialog to override the subtotal or add a structured adjustment — Restocking fee, Return shipping fee, Goodwill credit, Shipping refund, or Other (negative to deduct, positive to credit). Adjustments propagate to Shopify.

A header badge tracks channel sync — Synced with Shopify, Sync pending, or Sync failed (with a Retry sync button) — so you know whether the refund and return status made it back to the store.
Return reason codes
Returns → Return Codes is the list of reasons a customer picks when starting a return, and — crucially — who pays for the return label.

| Policy | Who pays / what happens |
|---|---|
| Return Paid By Store | You cover the label; the warehouse generates it. |
| Flat Rate Shipping | The customer pays a set fee, deducted from their refund. |
| Return Paid By Customer | The customer ships it back themselves. |
| Not Returnable | An RMA can't be created with this reason. |
As an operator you Add Return Code, edit a code's label policy, or disable one (kept for history, never deleted). Codes can map to a channel's native return reasons (e.g. a Shopify reason) for round-trip sync.
