ResReturn integration
Where the return portal lives, how a return moves from lookup to outcome, and what your systems are told at each step.
Entry points
- Slug URL —
portal.resreturn.com/{your-slug}, linkable from order emails, the account page and the footer. - In-store path (Shopify) — the same portal served through an app proxy on your own domain, so the shopper never leaves the store.
- Theme embed — a return entry point you can switch on without editing theme code.
One thing to know about framing
The in-store portal path cannot be embedded in an <iframe> — the proxy sets frame-ancestors to none, and same-origin does not exempt you. Link to it or navigate to it; do not try to frame it inside a modal.
Lifecycle
| Stage | What happens |
|---|---|
lookup | Shopper identifies the order. The platform order is fetched live, including line items, delivery events and any existing return. |
eligibility | Per line: merchant window, statutory withdrawal period, per-reason rules and non-returnable flags are evaluated separately. No delivery anchor means no deadline is asserted. |
request | Lines, reasons and any required evidence are recorded. Shipping instructions are generated in the shopper’s language. |
transit | Carrier state is tracked and surfaced in both the portal and the merchant panel. |
outcome | Refund, exchange or store credit is executed against the storefront platform. Restock is an explicit, logged decision, written back to platform inventory when the store has granted that permission. |
webhook | Your systems are notified at request creation and at each outcome, so ERP and accounting stay in sync. |
Custom storefronts (planned)
ResReturn runs today on Shopify, Ticimax and ikas, with T-Soft in early access. For custom storefronts, where there is no platform API to call, the outcome step will invert: we emit the webhook and your systems perform the refund and the stock movement, then confirm back. Everything else in the lifecycle stays identical.