How returns flow through your integration

Returns involve more systems than most flows: the customer starts a return in a returns portal, the warehouse receives and inspects it, the refund is issued on the storefront, and the financials post to your ERP. HC connects returns platforms including Loop Returns, ReBOUND, ZigZag, Swap, and ReturnGO.

The typical journey of a return

1. Return initiated — the customer requests a return in your returns portal, which notifies HC

2. Return registered — HC creates the return (RMA) in your warehouse or ERP so the warehouse knows to expect the parcel. The return references the original order, which is why the original order must have flowed successfully first

3. Return received — when the warehouse books the parcel in, HC flows the confirmation back, including item conditions where the warehouse records them

4. Refund and financials — depending on your configuration, the refund is triggered on the storefront and/or a credit note is created in the ERP

The exact steps depend on which systems you use and how your integration was designed — your integration documentation describes your specific flow, and HC can confirm details.

Common issues with returns

• The original order never synced — a return cannot reference an order that does not exist in the destination system. If a return fails, check the original order's entity first

• Return notifications not arriving — if returns are not appearing in HC at all, the webhook connection from the returns platform may be misconfigured; contact HC

• Duplicate or partial returns — exchanges and partial returns have more edge cases than simple refunds; if values look wrong in the ERP, raise it with HC with the return reference and original order number

What you can check yourself

Search the Control Panel for events referencing the return or the original order number. If the return event failed, the error will usually point at the missing piece — most often the original order or SKU not being found in the destination system.