October 6, 2026 · Muhammad Rehan · More by Muhammad Rehan
Shopify Split Return Creation From Processing. Rebuild ERPs Now
returnProcess splits return confirmation from return creation, moving when a sale is recorded and when exchange fulfillment orders exist. Here's what ERPs need to rebuild.
Any integration that reads Shopify return or exchange data — an ERP, an OMS, a 3PL system — was built against an assumption that API version 2025-07 quietly broke: that creating or approving a return is the moment the return becomes real. Shopify's returnProcess migration guide splits that single step into two, and the gap between them changes when a sale is recorded, when an exchange's fulfillment order exists, and which exchanges get held for payment.
Create/approve and process are no longer the same event
Before 2025-07, a merchant's financial report included a return as soon as it was created or approved via returnCreate or returnApproveRequest. Shopify's migration doc is direct about what changed: "a return will only be recorded as a Sale when it has been processed" — through the new returnProcess mutation. An integration still watching for return creation as its signal that money moved is now watching the wrong event.
The same gap opens for exchanges. Previously, creating or approving a return with an exchangeLineItem immediately confirmed that line item and created a FulfillmentOrder. Now that confirmation, and the FulfillmentOrder that comes with it, only happens when the exchange line item is processed through returnProcess. A return can sit created and approved with no fulfillment order behind it at all until it's processed.
Fewer exchanges get held on principle
This is the change most likely to surprise an integration that hasn't touched its exchange logic since before 2025-07: every exchange fulfillment order used to be placed on hold automatically, full stop. Shopify's docs now specify a narrower rule — only exchanges with a balance owed by the buyer are automatically placed on hold, with the hold reason AWAITING_PAYMENT. An even or refundable exchange is not held, and is fulfillable immediately once processed.
An ERP that assumed "exchange created" meant "exchange is paused for review" will now see some exchange fulfillment orders become immediately fulfillable with no hold at all. If downstream logic depended on that pause as a manual-review checkpoint, that checkpoint no longer exists for every exchange — only for the ones where the customer owes money.
What to subscribe to and read instead
Shopify's guide for integrations reading exchange data recommends two webhooks: returns/processed, which fires when a return is fully or partially processed (the payload indicates which items were processed, since partial processing is possible), and fulfillment_orders/order_routing_complete, which fires once the new exchange fulfillment order has been routed to a location and is ready to fulfill. Creation and approval events are no longer the trigger an integration should sync on.
For financial reconciliation, the Return.transactions connection is populated for POS returns and exchanges (both refunds and captured payments) and for online returns and exchanges (refunds only). Online exchange payments are the one gap the docs are explicit about: captured payments for an online exchange aren't yet directly associated with the return, so reconciling them still means matching Order transactions to the SalesAgreement by amount and creation timestamp — there's no more precise mechanism documented. The order's agreements connection remains the right place to read the full unified history of a sale, its return, and its exchange, but the docs note returns and exchanges only appear there once they've been processed, not at creation.
One more piece replaces a legacy field rather than a legacy event: suggestedFinancialOutcome replaces suggestedRefund, and it's built as direct input to returnProcess — covering refunds, exchanges, fees, and refund-method allocation in one response, instead of the narrower refund-only shape suggestedRefund produced for refundCreate or returnRefund. Both returnRefund and refundCreate still work, but returnRefund is now a legacy path, and Shopify specifically warns that using refundCreate for returns risks refunding the wrong line item when an order holds multiple quantities of the same product. returnProcess is the one mutation built to handle the entire lifecycle — restocking decisions, refunds, exchanges, and fees — in a single, line-item-precise call.