Returns on Carriyo: One Reverse Flow From Request to Refund, Ready Before Peak
On Wednesday we wrote about the January returns wave and argued that the returns plan belongs inside the peak plan, set up in September and October rather than improvised after Christmas. This post is the practical follow-up: how returns actually work on Carriyo today, what is configurable ahead of peak, and why we think the reverse flow belongs on the same platform as the order and the outbound delivery rather than in a separate tool.
We will try to be precise about what is live, because returns is an area where it is easy to describe an ambition as a feature. Everything below is in the product now and documented publicly.
The problem a returns tool cannot solve on its own
A return is not a new transaction. It is the original order, or part of it, moving in the opposite direction, and almost everything that makes it easy or hard depends on data that already exists somewhere else: which items were on which shipment, whether that shipment was actually delivered and when, what the customer was promised, which carriers serve that address on the way back, and what the finance team eventually refunded. A standalone returns tool has to fetch all of that from other systems, and most of the friction merchants complain about in January is the seams between those systems rather than any one of them.
That is the plain reason returns sit inside Carriyo as a module of the same platform that holds the order, the fulfillment, the shipment and the customer communication. The return request references the order lines and the forward shipments the items came from. The reverse shipment is a shipment like any other, routed by the same rule engines and tracked by the same status model. The refund is recorded against the request so that the whole loop can be reconciled in one place.
What the customer sees
The starting point is a self-service returns portal that carries the merchant's own brand, with the logo, colours and typography inherited from the merchant's theme and content that can be customised per locale. A customer looks up their order with the order reference plus either the email address or the phone number on the delivery, picks the items they want to send back, picks a reason for each item, and submits.
Quite a lot of policy is applied in that short flow without anyone on the merchant side being involved. Items already in an active return request are subtracted from what can be returned. Non-returnable SKUs are disabled. Eligibility can be restricted to items on delivered shipments, and a return window runs from the delivery date, up to a maximum of 100 days. Each return reason can require a free-text comment, a photo (JPG, PNG or WebP, up to 5 MB each) or a description of the item's condition, so a "damaged" claim comes in with evidence and a "changed my mind" request does not have to. Reasons, resolutions and refund types are chained, so a customer only sees the compensations and refund methods the merchant allows for the reason they picked, and merchants can offer predefined comments alongside free text so that the reasons data is clean enough to analyse later.
Where a home pickup is offered, the customer can schedule it. Collection scheduling is configured per country, with a start date relative to the request, a scheduling horizon, time-slot length and the weekdays and hours on which pickups are allowed. Merchants can also let the customer change the pickup address, within the same country as the original delivery. Once a request is approved, the portal shows the customer the next step straight away: return instructions, drop-off information or the label.
Approval: rules first, people for the exceptions
Every return reason carries an auto-approve flag. If every item on a request has an auto-approve reason, the request is approved the moment it is submitted and the customer gets their return instructions, drop-off details or label straight away. If any item does not, the request waits in "pending" for the operations team, who can approve all or part of it, reject it with one of the merchant's configured rejection reasons, put it on hold, or edit the pickup details before approving. Requests can be assigned to a user, annotated with notes, and split so that some items proceed while others are still being reviewed. Merchants can also switch on auto-close, so a request with no activity for a configurable number of days closes on its own instead of lingering into February.
This is the mechanism behind the advice in Wednesday's post about writing the holiday policy down as rules. The extended January window, the reasons that are safe to approve on submission and the ones that need a look are all configuration, set once in October and applied consistently to every request that arrives in the first week of January.
The reverse shipment: a new shipment, on the same network
On approval, Carriyo creates one or more new reverse shipments for the approved items. A reverse shipment is a Shipment with `entity_type=REVERSE`: the pickup address is the customer's, the drop-off address is the merchant's warehouse, and it is a distinct object from the forward shipment it relates to rather than a modification of it. That matters for reporting, because the outbound delivery keeps its own history and the return keeps its own.
Reverse traffic is routed by the same carrier rule engines as forward traffic, with a direction filter, and most merchants run separate rule sets per direction, because the cheapest or most reliable carrier on the way out is often not the right one on the way back. Capacity rules and costing rules also carry the direction filter, so reverse parcels do not compete with outbound parcels for the same carrier allocation in the last week before Christmas, and the return leg can be costed independently. Carriyo's carrier network, 130+ carriers across the markets we serve, is available on the reverse leg with the same label generation, booking and status normalisation as on the forward leg. The know-how that goes into that, the retries, the status mapping and the reconciliation edge cases, is the part a merchant would otherwise be rebuilding for returns specifically.
Merchants who already run their own returns lifecycle in another system can use the reverse-shipment-only mode, where Carriyo just books and tracks the carrier and the merchant's system makes the decisions. That is the modular point: the returns module can be adopted whole, or the shipping part of it can be adopted on its own, and either way it compounds with the rest of the platform.
Tracking, notifications and receiving
The reverse shipment is tracked the same way as a forward one, through the same carrier integrations and the same normalised status model, and the return request follows it. When the reverse shipment reports delivered, Carriyo updates the returned quantity on the matching items automatically and fires a webhook, so the merchant's systems know the parcel is back before anyone in the warehouse has touched it.
Customer notifications can be triggered on each return-request status change, so the customer hears when the request is approved or rejected and when the return is completed, and the reverse shipment carries the same tracking notifications as a forward one while the parcel is on its way back. The merchant's own team can subscribe to email alerts on the same return events. This is the piece that removes most of the "where is my refund" volume in January, because the customer is told what has happened at each step rather than having to ask.
At the warehouse, the operations team records what was actually received: the received quantity per item and a merchant-defined condition code, tracked separately from what was approved and what the carrier reported as returned. Completing the request confirms the receipt and closes the loop; cancelling is available before or after approval and is final.
Refunds, recorded where the return lives
Refunds are recorded against the return request. Each refund entry carries the payment-system reference, the refund type, the amount and currency, a note and timestamps, and a request can carry several entries. Carriyo does not move the money; the merchant's payment or finance system does that, and the entry ties it back to the return so that finance, operations and customer service are looking at the same record. The practical benefit is reconciliation. A request that is approved but not yet refunded is visible as exactly that, which is also the definition of the pending-returns bucket in the Revenue at Risk report we wrote about last week, where refund liability sitting in open requests is counted in money.
Three ways to run it
Like every Carriyo capability, returns work in three modes, and most merchants will run all three during peak.
The traditional mode is the dashboard, where a returns team filters pending requests, approves, rejects, holds, receives and records refunds. The automated mode is the configuration described above: auto-approve per reason, eligibility and window rules, reverse carrier routing by direction, auto-close and notification triggers, all running without anyone touching a request. The third mode is AI agents. Through Carriyo's native MCP layer, the return-request tools let an agent look up and search requests, create or edit them, approve or reject, create the reverse shipments, mark items received, cancel and complete, with the same permissions as the user it acts for. A merchant could, for example, have an agent review the pending queue each morning in January, approve the requests that match policy but missed the auto-approve rules on a technicality, and hand the rest to a person with a summary. The point of building returns on a governed data model is that an agent can be trusted to do that.
Why this is the de-risked way to be ready for January
It is worth being straightforward about the alternative. A capable team can build a returns portal, and there are standalone tools that will give you one. What is hard to build, and harder to build by October, is the part underneath: a return model that already knows the order and the delivery, reverse routing that uses the same carrier know-how and capacity rules as the outbound, tracking and notifications that behave the same in both directions, and a refund record that reconciles. Carriyo's version of that has been shaped by the delivery data accumulated across 100+ brands and enterprise customers, $5B in GMV and shipments spanning 200 countries, and it comes with the security posture and uptime commitments that an enterprise operations team expects, rather than being something a non-specialist team has to stand up and then keep watching through peak.
Everything in this post can be configured in the weeks ahead of Black Friday and left to run. If you would like to go through your returns setup before peak, or you want to talk about what the returns module would look like on your own orders and carriers, get in touch with our team at carriyo.com/contact. You can read the returns documentation at carriyo.com/docs/platform/returns.
Carriyo is The Intelligent Commerce Platform, from checkout to doorstep.
---
Sources
1. Carriyo. Returns module documentation (return request model, reverse shipments, returns portal). https://carriyo.com/docs/platform/returns/ 2. Carriyo. Returns guide: configure return settings. https://carriyo.com/docs/guides/returns/configure-return-settings/ 3. Carriyo. Returns guide: approve or reject a return request. https://carriyo.com/docs/guides/returns/approve-or-reject/ 4. Carriyo. Returns guide: receive, cancel or complete a return. https://carriyo.com/docs/guides/returns/receive-cancel-complete/ 5. Carriyo. Returns API reference. https://carriyo.com/docs/api/returns/ 6. Carriyo. MCP tools for returns. https://carriyo.com/docs/mcp/tools/returns/ 7. Carriyo. "The January Hangover: Peak Season Does Not End on Christmas Eve, and the Returns Plan Should Say So" (Carriyo blog, September 2026). {{wed_blog_url}} 8. Carriyo. "Carriyo Intelligence: Revenue at Risk and CX Score Are Built, and Open to Customers in Q4 2026" (Carriyo blog, September 2026). https://carriyo.com/blog/carriyo-intelligence-revenue-risk-cx-score-2026-09-17/ 9. Carriyo. "Carriyo's MCP Server Turns AI Agents into Operators" (Carriyo blog, May 2026). https://carriyo.com/blog/carriyos-mcp-server-turns-ai-2026-05-23/