Selling on a single category over ONDC is one problem; running fashion, electronics, F&B, home and mobility on the same network — from one seller operation, with one buyer-facing surface — is a different game entirely. The Open Network for Digital Commerce (ONDC) was built precisely so a seller could list once and be discovered across many buyer apps, but multi-category sellers quickly hit the hard parts: every category has its own attribute schema, its own fulfilment and return rules, its own settlement timing, and its own grievance path. This is the 2026 playbook for the multi-category ONDC network seller who wants to run the entire buyer-to-seller lifecycle — catalogue, order, fulfilment, delivery, grievance and reorder — over WhatsApp, where the customer already is. Every ONDC, regulator and market specific below is hedged: the network, its policies and the rules around it evolve fast, so treat each one as "verify as of 2026," and treat every cohort number as illustrative. This is operational guidance, not legal advice.
The mental model that makes ONDC click. ONDC is not a marketplace you "sell on" — it is an open protocol that decouples the buyer app from the seller app. A buyer can search on any buyer app and land on your catalogue; the order routes through the network to your seller app; a logistics node picks the fulfilment. For a multi-category seller this is the unlock and the complexity in one breath: one network, many categories, many buyer apps, and a settlement-and-grievance fabric that has to reconcile across all of them. WhatsApp does not replace any of those nodes — it becomes the seller-side conversation layer that keeps the human buyer informed and engaged across every category cycle. Verify ONDC network roles and policy as of 2026.
The ONDC network roles a multi-category seller must understand
Before you wire a single WhatsApp message, you need a clean picture of who does what on the network. ONDC separates the commerce stack into participant roles, and an order is a relay across them rather than a transaction inside one app. The table below maps the roles at a high level — every entry is directional, so verify the current participant taxonomy and your own agreements as of 2026.
| Network role (verify ONDC 2026) | What it does | Where WhatsApp fits |
|---|---|---|
| Buyer app (Buyer NP) | Where the customer searches, discovers and places the order on the network | Not yours to control — but the buyer may also reach you on WhatsApp for enquiry and post-order support |
| Seller app (Seller NP / SNP) | Hosts your multi-category catalogue, receives orders routed from any buyer app, manages fulfilment state | WhatsApp mirrors order and fulfilment state to the buyer as human-readable updates |
| Logistics node (LSP) | Picks up, ships and delivers; provides tracking and proof of delivery (POD) | WhatsApp surfaces pickup, in-transit, out-for-delivery and POD events to the buyer |
| Gateway / network | Routes search, select, init, confirm and status calls between participants | Invisible to the buyer; WhatsApp is the friendly face over an otherwise machine-to-machine flow |
| Settlement / reconciliation layer | Splits and settles money across participants per the agreed terms | WhatsApp can confirm payment status and refunds; reconciliation itself stays in your back office |
| IGM (Issue & Grievance Management) | The network's standard path for raising, tracking and resolving issues and returns | WhatsApp captures the complaint and reflects IGM status; the resolution flows through the network process |
The single most important realisation: as a multi-category seller you sit at the seller-app side, you cannot dictate which buyer app a customer used, and your WhatsApp layer must therefore be buyer-app-agnostic. It speaks to the human regardless of where the order originated, while your seller app and the network handle the protocol underneath.
Onboarding a multi-category catalogue and mapping attributes
The first real work of a multi-category seller is catalogue onboarding, and this is where most of the pain lives. ONDC categories are not interchangeable: a fashion SKU needs size, colour, fabric and return-window attributes; an electronics SKU needs warranty, model and serialisation fields; an F&B SKU needs FSSAI, veg/non-veg and shelf-life markers; a home SKU needs dimensions and assembly notes. Onboarding well means mapping your internal product data to each category's required attribute schema on your seller app, so discovery, filtering and fulfilment behave correctly on every buyer app. Get the attribute mapping wrong and orders arrive with missing data, returns get disputed, and your grievance load climbs. WhatsApp does not do the catalogue mapping — that lives in your seller app — but it can do two adjacent jobs well: collecting enquiries against specific SKUs ("is this kurta available in L?") and confirming the exact variant before an order is finalised, which reduces wrong-item returns later. Treat ONDC's per-category attribute requirements as evolving and verify the current schemas as of 2026.
Order routing: one order, any buyer app, one WhatsApp thread
On a closed marketplace, the buyer, the order and the support thread all live in one place. On ONDC they do not — an order can originate on any buyer app, route through the gateway to your seller app, and be fulfilled by an independent logistics node. The customer experience can feel fragmented unless someone owns the human narrative. That is the job WhatsApp does best for a multi-category seller: it becomes the single continuous thread that follows the buyer across the whole lifecycle, no matter which buyer app they started on or which logistics node moves the parcel. The buyer placed a fashion order on one app and an electronics order on another? Both can reconcile into one familiar WhatsApp conversation with your brand, with category-aware messaging for each. The discipline is to key your WhatsApp updates off the network order state (confirmed, packed, shipped, delivered, returned) so the thread stays accurate regardless of origin.
The WhatsApp lifecycle, stage by stage, across categories
Here is the end-to-end lifecycle a multi-category ONDC seller can run over WhatsApp, mapped to the automation at each stage and the compliance guardrail that keeps it clean. Treat the automation column as a reference pattern and the compliance column as principles to verify against current ONDC and data-protection rules as of 2026.
| Lifecycle stage | WhatsApp automation | Compliance guardrail (verify 2026) |
|---|---|---|
| Catalogue / enquiry | SKU enquiry, variant check, category browse via buttons/lists | Only message buyers who opted in; no unsolicited bulk sends |
| Order confirm | Confirm variant, address and price; acknowledge the network order id | Reflect, do not alter, the order placed on the network |
| Fulfilment + logistics handoff | Packed and shipped notifications; logistics-node tracking link | Share only fulfilment-necessary buyer data with the logistics node |
| Delivery + POD | Out-for-delivery, delivered, and proof-of-delivery confirmation | Honour Consumer Protection (E-Commerce) Rules on accurate status |
| IGM grievance / return | Capture complaint, route to IGM, reflect resolution status | Use the network's standard grievance path; keep an auditable trail |
| Reorder by category cycle | Category-aware reorder nudges (consumables vs durables) | Separate marketing consent; respect opt-out and purpose limitation |
Notice the rhythm: WhatsApp narrates a lifecycle that the network executes. Every message is a human-readable reflection of an authoritative state held by your seller app, the logistics node or the IGM process — never a parallel source of truth. That separation is what keeps a multi-category operation coherent instead of chaotic.
Settlement and reconciliation across category nodes
Settlement is where multi-category selling on an open network gets genuinely hard, and it is worth being honest about it. On a closed marketplace, one platform collects and remits. On ONDC, money and responsibility are split across participants, and different categories can carry different fulfilment models, return windows and SLA expectations — which means your reconciliation has to line up the order, the logistics leg, the buyer-app collection and any returns or refunds, per category, before your books balance. The table sketches an illustrative settlement-and-SLA matrix to show the shape of the problem; the actual splits, timings and SLAs depend on your participant agreements and category, so verify each against your contracts and ONDC policy as of 2026.
Get a 1-minute BSP audit on WhatsApp
Drop your WhatsApp number — we line-item your current invoice against Meta India rates in under 60 seconds. India-hosted, DPDP-compliant.
| Category node (illustrative) | Typical fulfilment shape | Return / SLA sensitivity | Reconciliation note |
|---|---|---|---|
| Fashion | High return rate; size/fit driven | Return window matters most | Reconcile heavy return-and-refund volume per order |
| Electronics | Higher value; warranty and serialisation | Defect / DOA windows | Match serial numbers to fulfilment and any warranty claims |
| F&B / grocery | Perishable; fast fulfilment | Tight delivery SLA | Reconcile quickly; spoilage and short-shelf-life returns differ |
| Home / furniture | Bulky; assembly and inspection | Damage-on-delivery sensitive | Reconcile against POD with inspection sign-off |
| Mobility / logistics | Service-led leg of the order | SLA on pickup-to-delivery time | Reconcile the logistics fee separately from goods value |
WhatsApp's contribution to reconciliation is indirect but real: by confirming the variant before order, surfacing accurate delivery and POD events, and capturing returns cleanly through the IGM path, it reduces the disputed, mismatched and "where is my refund" cases that make reconciliation slow. The fewer ambiguous touchpoints, the cleaner your category-node settlement. The actual money-splitting stays in your settlement layer — verify timings and terms with your participants as of 2026. If in-chat payment is part of your flow, our WhatsApp catalogue and UPI checkout architecture guide covers the payment mechanics.
ONDC vs own D2C vs marketplace: which channel for which category
A multi-category seller rarely lives on one channel. The smart play is to understand what each channel is good at and let WhatsApp be the consistent conversation layer across all of them. This comparison is directional — verify current economics and network terms as of 2026.
| Dimension | ONDC network | Own D2C site | Closed marketplace |
|---|---|---|---|
| Discovery | Across many buyer apps on the network | You drive all traffic yourself | Marketplace's own audience |
| Commission / take | Network-distributed; often lower take (verify) | No marketplace commission | Marketplace commission per category |
| Catalogue control | Per-category attribute mapping on your seller app | Full control of your own store | Marketplace's schema and rules |
| Buyer relationship | You can support and re-engage via WhatsApp | You own the relationship fully | Often mediated by the marketplace |
| Grievance / returns | Standard IGM process across participants | Your own policy and process | Marketplace's dispute system |
| WhatsApp as conversation layer | Yes — buyer-app-agnostic narration | Yes — direct and native | Possible, within marketplace policy |
The conclusion most multi-category sellers reach: run ONDC for open-network discovery, keep a D2C site for margin and brand, list on closed marketplaces where their audience is — and use WhatsApp as the one consistent thread that ties every channel's post-order experience together. That is how you stop fragmenting the customer across surfaces. For the broader relationship layer, the best WhatsApp CRM for India guide is a useful companion, and if you also sell groceries, our existing ONDC kirana seller onboarding playbook covers the single-category kirana path in depth.
Regulators, IGM and the DPDP carve-out
A multi-category ONDC operation touches several bodies and rules at once, and you do not need to be a lawyer to stay clean — you need to know which rule each part of your flow leans on. At a high level, and to be verified as of 2026: ONDC's own network policy and participant agreement govern how you behave on the network; DPIIT sits behind ONDC as the policy sponsor; the Consumer Protection (E-Commerce) Rules 2020 shape accurate listings, status and grievance redressal; the network's IGM framework is the standard issue-and-grievance path you must use rather than improvise; and India's data-protection rules (DPDP) govern buyer personal data.
The DPDP carve-out, in one principle. On an open network, data flows between participants — but that is not a licence to over-share. Practise buyer-PII minimisation: as a seller you should share only the fulfilment-necessary data with the logistics node (name, delivery address, contact for the drop), and no more. Do not propagate the buyer's full profile, order history or marketing preferences across nodes that do not need them. On your WhatsApp layer, take separate, specific consent for transactional updates versus marketing reorder nudges, honour opt-out promptly, collect the minimum, and keep an auditable trail for grievance. Verify the operative DPDP provisions and any e-commerce-specific obligations as of 2026; this is operational guidance, not legal advice.
The mindset is "least data, standard process": minimise what you share at each node, route grievances through IGM rather than ad-hoc channels, keep listings and status accurate under the e-commerce rules, and be able to answer, for any buyer data you hold, what the lawful basis is and when you will delete it.
The economics: an illustrative multi-category cohort
Compliance and architecture are the floor; the reason to run WhatsApp over your ONDC operation is fewer disputes, fewer wrong-item returns and more reorders across category cycles. Consider an illustrative multi-category seller doing 4,000 orders a month across fashion, electronics, F&B and home, where a meaningful share of cost is wrong-variant returns and "where is my order" support load. Every figure below is illustrative — model your own on the calculator — but it shows the shape.
| Metric (illustrative) | Without WhatsApp layer | With WhatsApp lifecycle |
|---|---|---|
| Monthly orders across categories | 4,000 | 4,000 |
| Wrong-variant / avoidable returns | ~Higher (no pre-confirm) | ~Lower (variant confirmed in chat) |
| "Where is my order" support contacts | ~Higher (no proactive status) | ~Lower (proactive POD updates) |
| Reorder rate on consumables (F&B) | Baseline | Lifted by category-cycle nudges |
| WhatsApp messaging cost | ₹0 | Utility updates at the cheapest tier |
The asymmetry is the argument: order-status and delivery updates are utility-category conversations — the cheapest tier — and they directly reduce two of the most expensive things in multi-category commerce, namely avoidable returns and repeat support contacts, while category-aware reorder nudges lift repeat revenue on consumables. The messaging bill is a rounding error against the returns and support cost it removes. Run your own figures on the WABA pricing and cost-optimisation guide and the calculator before committing.
Build the seller-side layer on RichAutomate
You can stand up the entire seller-side conversation layer — SKU enquiry, variant confirmation, order and fulfilment narration, logistics tracking, POD confirmation, IGM grievance capture and category-cycle reorder nudges — without engineering lift, while your seller app and the network keep doing the protocol work underneath. RichAutomate charges ₹0 platform fee, ₹0 setup, ₹0 monthly. On Client Pay you pay only ₹0.10 per message plus Meta's own per-conversation charge billed to you directly by Meta at Meta's rates; on SaaS Pay it is an all-in ₹1.20 per marketing conversation and ₹0.30 per utility conversation — and order-status, shipping and delivery updates are utility conversations, the cheaper category. There is a 14-day free trial with 100 credits, so you can measure the returns-and-support reduction before committing. Keep WhatsApp as the narration layer, keep the network as the source of truth, and verify ONDC network policy, IGM, the Consumer Protection (E-Commerce) Rules and DPDP as of 2026. See the full pricing page for details.
Run every ONDC category on one WhatsApp thread
A multi-category ONDC seller does not have to let the open network fragment the customer experience. While the gateway routes orders from any buyer app to your seller app and independent logistics nodes move the parcels, WhatsApp can be the one continuous, buyer-app-agnostic thread that narrates the whole lifecycle — catalogue enquiry, variant confirmation, order confirm, fulfilment and logistics handoff, delivery and POD, IGM grievance and return, and category-cycle reorder — while the network stays the source of truth and you minimise buyer PII at every node. On illustrative numbers that means fewer wrong-variant returns, fewer "where is my order" contacts, and more reorders, for a messaging bill that is a rounding error. RichAutomate's pricing stays flat through all of it: ₹0 platform fee, ₹0 setup, ₹0 monthly — Client Pay at ₹0.10 per message with Meta conversation charges billed direct by Meta, or SaaS Pay at ₹1.20 marketing / ₹0.30 utility all-in. Start the 14-day free trial with 100 credits, WhatsApp us at 917434901027, or book a 30-minute walkthrough at https://calendly.com/inrichdaddy/30min. (All cohort, returns and revenue figures here are illustrative — model your own on the calculator — and all ONDC network roles and policy, IGM, DPIIT, the Consumer Protection (E-Commerce) Rules 2020 and DPDP data-protection rules change; verify the current position as of 2026. This is operational guidance, not legal advice.)
Start your 14-day free trial → · See full pricing · Read the UPI checkout architecture