/ THE SHORT ANSWER
- 01Identify whether the business is a merchant, network participant or both.
- 02Separate order acknowledgement from physical fulfilment evidence.
- 03Use a case owner without confusing ownership with control over every system.
/ dotSuper point of view
dotSuper analysis: distributed commerce needs explicit handoffs between what happened physically and what each system recorded.
Identify the parties before assigning the work
[2] That matters when an order goes wrong.
The merchant may control stock and packing while another party controls the application integration or a different part of the transaction.
The definitions linked from the policy index distinguish an inventory seller node from a marketplace seller node representing third-party merchants.
[3] A merchant using an ONDC-connected seller application is therefore not automatically the network participant for every obligation.
Write down the business's actual role and the parties named in its arrangement.
Identify the application support route and relevant contractual responsibilities.
A generic chart of the ONDC ecosystem is useful background, but the operating team needs to know which organisation can resolve its specific problem.
Connect technical messages to physical facts
[1] These are relevant to integration teams.
They should not be mistaken for a requirement that every merchant independently build or maintain the network connection.
Ask the seller application provider to explain the statuses visible to the merchant.
Distinguish receipt of an order message from stock allocation, packing, handover and delivery evidence.
A successful technical acknowledgement does not by itself prove a physical event occurred.
Keep stable references between the order, fulfilment record and support case.
If the application retries a message, staff should not create another physical dispatch merely because a status appeared twice.
The provider should explain how duplicates and delayed events are handled, while the merchant maintains the corresponding real-world evidence.
Build an exception table around the next decision
Owners must be adapted to the actual contracts and application capabilities.
A case owner coordinates resolution even when another participant controls the required system action.
Use language that describes the unresolved decision.
Refund pending can mean a request is under review, an approved instruction was not processed or a payment is not visible.
Those situations need different evidence and should not disappear into a single shared inbox label.
| Exception | Merchant case owner | Evidence and handoff |
|---|---|---|
| Stock conflict | Inventory lead | Available quantity and seller-app request |
| Duplicate-looking order | Order administration | Order references and provider confirmation |
| Packed but no pickup | Dispatch lead | Readiness record and logistics escalation |
| Delivery status disputed | Customer support | Handover and delivery evidence |
| Refund status unclear | Finance operations | Applicable decision and payment trace |
| Application event missing | Commerce coordinator | Timestamped case and provider support route |
A hypothetical Coimbatore tools merchant
Its own stock record shows four available, while the seller application displayed six when the buyer ordered.
Two employees notice the discrepancy through different screens and each opens a support request.
The commerce coordinator creates one case tied to the order and records the physical stock count.
The seller application provider confirms which permitted options are available under the actual transaction arrangement.
Staff do not invent a partial fulfilment or cancellation rule from a general explanation of ONDC.
After the authorised decision, the team records the outcome in the application and its own inventory process.
It also investigates why the stock records diverged.
The fictional scenario does not specify a mandatory buyer remedy.
It shows how a clear owner can prevent duplicate work while the relevant parties resolve the transaction.
Separate service communication from settlement conclusions
Give customer-facing staff the status they can substantiate and a route to finance for missing evidence.
Avoid promising a completed payment based only on an internal approval message.
Keep the case history factual: what was requested, what each party confirmed and which action remains pending.
AI can summarise this history with links to the underlying records.
It should not fill gaps with assumptions about which participant caused the delay.
There is a tradeoff between detailed logging and excessive administration.
Capture the identifiers, timestamps and evidence that distinguish one failure from another.
Avoid collecting unrelated customer information or copying entire records into uncontrolled tools when a bounded reference would support the investigation.
Review the handoff that keeps failing
Recurring stock conflicts may need a better inventory process; recurring missing application events may need provider investigation.
The same symptom on a merchant screen can have different underlying causes.
Agree how urgent cases reach the appropriate substitute owner.
A distributed arrangement becomes fragile if the only person who understands the support relationship is absent.
Keep contact routes and operating responsibilities accessible to the team that handles orders each day.
Start with one frequent exception and trace it from the physical event to its final record.
Improve the handoff and closure evidence before adding automated actions.
The selling operation should explain what happened and who can resolve the remaining question.
That clarity can prevent the same administrative work being repeated for every affected order.
What this page cannot conclude
- 01Responsibilities depend on the participant model, current policies, contracts and domain implementation; no universal refund or cancellation deadline is asserted.
- 02The linked ONDC definitions are dated March 2023 and provide role context, not a complete current contractual assessment.
- 03This article was researched and drafted with AI assistance. Sources and limitations are provided for scrutiny; it is not an independent professional review or a compliance certification.
Sources
- 01ONDC technical resourcesOpen Network for Digital Commerce · accessed Sep 15, 2026
- 02ONDC Network PolicyOpen Network for Digital Commerce · accessed Sep 15, 2026
- 03ONDC Network Policy definitions, March 2023Open Network for Digital Commerce · accessed Sep 15, 2026
This article was researched and drafted with AI assistance. Sources and limitations are provided for scrutiny; it is not an independent professional review or a compliance certification.
Our editorial standard · Found an error? Send a correction with its source.
/ CITE OR SHARE THIS GUIDE
Make the evidence easy to verify.
When you reference this guide, link to its canonical URL. That gives readers one stable place for the evidence, limitations and future updates.
dotSuper Research Desk. (September 15, 2026). Give Every ONDC Order Exception a Clear Owner. dotSuper. https://dotsuper.net/feeds/applied-systems/india-15-ondc-order-exception-ownership