Returns, refunds, and stock are three separate decisions

A parcel arriving at the warehouse does not answer whether its contents can be sold again. A refund being requested does not tell support staff whether payment processing has completed. An exchange adds another item moving in the opposite direction.

A useful returns workflow keeps these questions visible instead of compressing them into one status.

Separate the records

Shopify's returns documentation distinguishes a refund, which sends payment back to a customer; a return, which receives an item; and an exchange, which sends an alternative item. That distinction is a useful starting point for mapping your own process.

For an illustrative damaged-item case, the business might decide that a returned product should not re-enter saleable stock even though a refund is due. The payment and inventory outcomes need their own records and references.

Map the workflow to your actual returns policy and applicable requirements. This article covers software process design; it does not prescribe customer eligibility, deadlines, or refund entitlements.

Give each decision a clear owner

Bring customer service, warehouse, and finance representatives into the same walkthrough. Ask who can approve each action and what evidence they need.

The names of these states can match your existing tools. Their meaning matters more than the labels.

Walk through a partial return

Use a sample order with multiple items. Return only part of it. Then ask the team to identify what remains fulfilled, what is awaiting inspection, and what has been refunded.

Add an exchange with a different value only if your operation supports it. Have the responsible team explain how amounts are determined and how the relevant system records the adjustment. Do not invent calculation rules in the integration.

Include the physical location. A product received at one branch should not appear available somewhere else unless the inventory process explicitly makes that change.

Design for a split outcome

Consider what the operator sees if an inventory update succeeds but the refund request fails. Repeating the entire workflow may be inappropriate if it repeats an action that already completed.

Ask the developer to demonstrate recovery from that state. The screen should show which action needs attention and retain the link to the original request. Our integration failure guide explains how to make retries and reconciliation part of the brief.

Give customer support a view that explains progress without requiring access to every administrative tool. They need a reliable answer to “What is still waiting?” rather than a reassuring but ambiguous “processed.”

Reconcile the case before closing it

Define closure around the agreed outcomes: the item's disposition is recorded, required payment actions are confirmed in the relevant system, and any replacement has reached the appropriate stage.

Review exceptions using business references across the connected systems. Keep reporting definitions explicit too: returned units, refunded value, and exchanged items describe different things.

If the online store and physical locations share this process, use the same vocabulary when planning POS and ecommerce connections.