Orders, couriers, NDR, RTO, serviceability — the ops layer most India stores duct-tape together from three different tools. Here it’s one 21-state machine, one courier layer your buyers never see, and one queue for every exception. Built into the platform, not bolted on.
Delivery exceptions, manual reroutes and holdbacks that need a person.
VLX 8341 0072Courier attempted once — “customer unavailable.” Confirm and re-attempt.
No provider services this pincode yet. Prepaid — refund is one click.
Every order rides the same guarded, forward-only machine: Placed through Refunded, plus every way a delivery can go sideways. The order console carries the controls for all twenty-one: GST-correct invoices, labels, the refund launcher and a manual courier override.
Twenty-one states, and not one renders red. A return isn’t a failure to bury; it’s a state to handle. Exceptions read amber; only shipped and delivered read green.
The orchestrator tries your primary provider first and falls back the instant a pincode isn't serviceable. Create, retry, cancel, track, label and pickup are one idempotent contract; the providers are just adapters behind it.
VLX 8341 0072First serviceable provider wins. Create-shipment, retry, cancel, track, label and pickup are one idempotent interface, and the providers are pure adapters behind it.
The courier provider name never appears in customer-visible text. That’s a hard rule enforced in code, not a setting you can flip off by accident.
Unserviceable pincodes, NDR, RTO, failed shipment creation, COD confirmations — every delivery exception lands in one queue, each with exactly the actions that clear it, and a tap-to-call for the moment a human call is the fix.
The type decides which actions the queue offers.
No provider services this pincode yet. The sweep caught it off the checkout path.
Prepaid → the refund fires automatically on cancel; the customer is emailed.
One courier webhook sets off the whole chain — status, tracking, refunds, inventory, the right lifecycle email, a review request when it's earned. Idempotent by design, so a re-sent scan never changes anything twice.
One webhook. Seven things happen. None of them by you.
A courier scan lands and the engine does the busywork a person would otherwise babysit. It runs in one idempotent pass, so the same scan arriving twice never double-charges or double-emails.
And the serviceability sweep runs off the checkout critical path, so a slow courier API can never slow a customer down at the till.
Deduped on a unique event id, so a re-sent scan never fires twice
Mapped onto the 21-state machine, forward-only
The public /track page updates on its own
On RTO / return / unserviceable — Razorpay refund fires; a failed refund raises an attention alert
Stock goes back the moment an order won’t complete
One of seven, matched to the new state
On delivery only — never on a return
Order- and subscription-linked tickets, auto-prioritised, with a 4-hour first-response SLA in copy, an in-ticket Razorpay refund launcher, and a 7-day reopen window. It's also the desk your Support-Triage agent drafts into: it writes the reply, you decide to send.
Ticket #ZT-4471 · Order #RS-9188 · first response within 4 hours
Resolved tickets stay reopenable for 7 days. Up to 3 attachments per message, wallet balance and the linked order always in the sidebar.
Selling is the easy half. This is the other one.
Storefront and checkout get the applause. Orders, couriers and returns are where the money quietly leaks, so we built them into the platform, running on our own store, before we ever asked you to trust them with yours.