A grocery store in a small Indian town can now show up in the same search results as a listing from a national retail chain, without paying either platform a commission to be discovered. That's the basic promise of the Open Network for Digital Commerce (ONDC), and it's also why the network has become an unusually interesting testbed for applied AI. When discovery, cataloging, and fulfillment are unbundled from a single app's algorithm, someone still has to do the matching, ranking, and translation work that platforms used to do centrally. Increasingly, that work is done by AI models sitting inside seller apps, buyer apps, and the logistics layer in between.
This post explains how ONDC actually works, where AI genuinely helps versus where it's bolted on for marketing purposes, and what a business or developer integrating with the network should realistically expect.
What ONDC Is and How It Works
ONDC is not a marketplace. There's no ONDC app you download, no ONDC-branded checkout page, and no central company taking a cut of every transaction. It's a protocol — a shared set of specifications, built on the open-source Beckn protocol, that lets independent apps talk to each other using a common language for discovery, ordering, fulfillment, and settlement.
The architecture has three main roles:
- Buyer-side network participants (BAPs) — apps that consumers use to search for and order things. A buyer app doesn't need to have its own catalog; it queries the network.
- Seller-side network participants (BPPs) — apps or platforms that represent sellers, exposing their catalogs, inventory, and pricing to the network.
- Gateway — a routing layer that takes a buyer's search request and broadcasts it to relevant seller apps, then relays responses back.
When a shopper searches for "1kg atta" in a buyer app, that request is broadcast across the network to seller apps that have registered relevant categories. Each seller app returns matching listings — price, availability, delivery estimate — and the buyer app assembles those into a results page. The buyer can then place an order that flows back through the same chain: buyer app to gateway to seller app to the actual merchant's point-of-sale or inventory system.
Because the protocol only standardizes the messages exchanged between apps (search, on_search, select, confirm, status, and so on), each participant is free to build its own UI, ranking logic, pricing engine, and business model on top. That's the structural difference from a closed marketplace: the network doesn't own the algorithm that decides which listing a shopper sees first — the buyer app does, and different buyer apps can rank the same underlying inventory completely differently.
The Domains ONDC Spans
ONDC was designed to be category-agnostic from the start, which is part of why it reads more like internet infrastructure than a single shopping app. The same protocol pattern — buyer app queries network, seller apps respond, order flows through standardized messages — has been applied to grocery and retail, food and beverage ordering, mobility (ride-hailing and local transport), logistics and last-mile delivery, financial services onboarding, and even gig-work discovery. A developer who has built one Beckn-based integration for retail can reuse most of that knowledge for a mobility or logistics integration, because the underlying message contract (search, select, confirm, status) doesn't change — only the domain-specific schema fields inside each message do. This is a meaningful difference from platform-specific APIs, where a retail marketplace's API and a ride-hailing API share essentially nothing.
Why This Matters Structurally
In a closed platform, the company that owns the app also owns search ranking, seller onboarding rules, commission structure, and the recommendation engine, all in service of that company's revenue model. In ONDC, those functions are distributed. A logistics company can plug in as a fulfillment provider without also having to build a consumer app. A regional retail chain can register as a seller without needing to run its own marketing funnel. And critically, more than one buyer app can compete on how well it interprets and ranks the same catalog — which is where AI stops being optional.
Where AI Actually Fits
Unbundling discovery from a single company's algorithm doesn't eliminate the need for ranking and interpretation — it just moves that job to whoever builds the buyer or seller app. This creates several concrete points where AI does real work rather than decorative work.
Catalog generation and normalization
Sellers on ONDC come from wildly different starting points: some have clean structured inventory in a POS system, many have a WhatsApp catalog or a handwritten price list. Getting a seller listed requires converting unstructured product information — photos, voice notes, spreadsheets in regional languages — into the structured schema the protocol expects (item name, category taxonomy, price, unit, images, GST details). Language models and vision models are used here to:
- Extract structured fields from product photos and informal descriptions.
- Map free-text category names to the standardized ONDC taxonomy.
- Translate and transliterate listings across Indian languages so a single catalog can serve buyer apps in different regions.
- Flag missing or inconsistent data (a price with no unit, a category mismatch) before it goes live.
Search and ranking on the buyer side
Since the protocol just returns a flat list of matching offers from every seller app that responds, a buyer app needs its own logic to decide what to show first. This is a fairly standard information-retrieval and ranking problem — one that benefits from embeddings-based semantic search (matching "atta" to "wheat flour" listings, or a misspelled query to the right product) and from relevance/ranking models trained on click and conversion data, in addition to simpler filters like distance and delivery time.
Conversational and voice interfaces
Because ONDC explicitly targets inclusion of sellers and buyers who aren't comfortable with app-based UIs, several buyer apps have experimented with voice- and chat-based ordering, particularly in regional languages. This is a natural fit for speech recognition and conversational AI: a buyer describes what they want in Hindi or Tamil, the assistant converts that into a structured search request, and results come back translated into the same language.
Logistics and fulfillment matching
The logistics side of ONDC (delivery partners bidding to fulfill an order) benefits from optimization and prediction models: estimating delivery time given a seller's location and courier availability, dynamically choosing among multiple logistics providers responding to the same fulfillment request, and predicting failed-delivery risk.
Trust, fraud, and quality signals
With thousands of small, independent sellers onboarding without a central platform vetting each one, buyer apps need their own signals for seller reliability — return rates, delivery consistency, complaint patterns. Anomaly detection models are used to flag sellers whose behavior looks inconsistent with their stated catalog or history, since there's no single company doing manual seller review at platform scale.
Practical Implications for Businesses and Builders
If you're a retailer, brand, or developer considering ONDC integration, the practical path differs quite a bit from listing on an existing e-commerce platform, and it's worth being clear-eyed about the tradeoffs.
| Aspect | Closed platform (e.g., a single marketplace) | ONDC network |
|---|---|---|
| Discovery | Controlled by one company's algorithm | Determined by whichever buyer app the shopper uses |
| Onboarding | One-time signup with the platform | Register with a seller app (network participant), which then exposes you to the network |
| Commission model | Set by the platform, often a fixed percentage | Varies by seller app / network participant; several charge lower or no commission |
| Catalog format | Platform-specific template | Standardized Beckn schema, portable across buyer apps |
| Branding & UX | Platform's UI, limited seller customization | Depends entirely on which seller app you integrate through |
| Technical integration | Usually a dashboard + CSV upload | API-based (REST/JSON over the Beckn protocol), or via a seller-app intermediary that abstracts this |
A few practical notes for teams evaluating this:
- You rarely integrate with "ONDC" directly. Most sellers don't build a raw Beckn-protocol integration themselves; they onboard through an existing seller app or network participant (a "Seller Network Participant") that handles protocol compliance, and the seller just manages catalog and orders through that app's dashboard or API.
- Catalog quality determines visibility more than in closed platforms. Because ranking is decentralized across many buyer apps with different logic, a well-structured, complete catalog (accurate categories, images, delivery promises) tends to perform more consistently across the network than trying to game any single app's algorithm.
- Multi-homing is normal and often necessary. Since no single buyer app dominates discovery the way one marketplace might, sellers frequently register through more than one seller-side network participant to maximize the buyer apps their catalog reaches.
- Settlement and logistics are separable decisions. A seller can choose one network participant for order/catalog management and a different logistics network participant for delivery, rather than being locked into one company's fulfillment fleet.
- AI-assisted onboarding lowers the entry barrier but doesn't remove due diligence. Tools that auto-generate structured catalogs from photos or spreadsheets speed up listing, but sellers should still verify pricing, GST, and category mapping before going live — automated extraction errors show up as buyer-facing mistakes.
For developers building on top of the network — whether a new buyer app, a vertical-specific seller app (say, for pharmacies or local grocers), or a logistics integration — the core technical requirement is implementing the Beckn protocol's API contract correctly: the search/on_search, select/on_select, init/on_init, confirm/on_confirm, and status/on_status message pairs, plus the signing and authentication layer for network participant registration. Most of the "AI" work sits on top of that protocol layer, not inside it — the protocol itself is deliberately unopinionated about ranking, personalization, or catalog quality.
Real Limitations and Open Questions
It's worth being honest about where this model creates friction that a single closed platform doesn't have to deal with.
Discovery quality is inconsistent across buyer apps. Because each buyer app builds its own ranking and search logic, the same seller catalog can show up well-ranked and clearly presented in one app and poorly matched or buried in another. There's no single "ONDC search algorithm" a seller can optimize for, which makes catalog and SEO-style optimization harder to reason about than on a single platform.
Trust and dispute resolution are more fragmented. In a closed marketplace, a bad seller experience is resolved by the platform's own customer service and policies. On ONDC, a transaction crosses at least two independent companies (a buyer-app operator and a seller-app operator, sometimes a separate logistics operator too), and dispute resolution has to be coordinated across parties that don't share a single support system.
AI-generated catalog data can introduce its own errors. Automating catalog creation from photos, voice notes, or informal price lists is genuinely useful for onboarding sellers who don't have digital inventory systems, but extraction models make mistakes — wrong units, mismatched categories, mistranslated product names — and those mistakes are harder to catch centrally than they would be under a single platform's manual review process.
Small-seller economics still depend on the seller app they choose. ONDC removes the requirement to pay one dominant platform's commission, but individual network participants set their own fee structures, and a seller's actual economics depend heavily on which seller app they onboard through — the protocol itself doesn't guarantee lower costs.
Network effects take time to build both sides. A protocol is only as useful as the number of active buyer apps and seller apps actually connected to it in a given city or category. Coverage varies significantly by geography and product category, and a seller integrating today may find far more buyer-app reach in groceries than in, say, specialty electronics.
Protocol versions and schema conventions still evolve. Because Beckn is an actively developed open specification rather than a fixed, closed API a single company controls, the schema for a given domain (how a "return policy" or "delivery fulfillment type" is expressed, for example) can change between protocol versions. Teams integrating directly rather than through an intermediary seller app need to track those changes themselves, which is a maintenance burden a closed platform's stable, vendor-controlled API doesn't impose.
What to Watch Next
A few dynamics are worth tracking if you're deciding how much to invest in ONDC integration:
- Vertical-specific buyer and seller apps. Rather than general-purpose shopping apps, expect more narrowly focused apps — for local pharmacies, home services, agri-input supply, or food delivery — where domain-specific AI (drug-interaction checks, service-scheduling logic) becomes the differentiator rather than raw catalog breadth.
- AI-native buyer experiences. Conversational and voice ordering interfaces built specifically for the network are likely to keep expanding, particularly for users who find text-based search and multi-app comparison cumbersome.
- Cross-border and adjacent-network extensions. Because Beckn is an open protocol (not exclusive to India), similar network deployments and interoperability experiments in other countries and adjacent domains (mobility, logistics) affect how transferable ONDC-specific integration work becomes.
- Consolidation among seller-app intermediaries. As more network participants compete to onboard sellers, expect consolidation and differentiation based on how well a given seller app's AI tooling handles catalog quality, multi-language support, and fraud detection — since the protocol layer itself is fixed and can't be a differentiator.
FAQ
What is ONDC in simple terms?
ONDC (Open Network for Digital Commerce) is a shared, open protocol that lets independent buyer apps and seller apps communicate using a common set of messages for search, ordering, and fulfillment. It's not a marketplace app itself — it's the plumbing that lets different companies' apps interoperate.
How is ONDC different from a marketplace like a typical e-commerce app?
A marketplace app owns the catalog, search ranking, and checkout for its own listed sellers. On ONDC, no single company owns search or ranking network-wide — any buyer app can query any registered seller's inventory, and each buyer app decides independently how to present and rank the results.
Do I need to know the Beckn protocol to sell on ONDC?
Not directly, in most cases. Most sellers onboard through an existing seller-side network participant (a seller app) that already handles Beckn protocol compliance, authentication, and message formatting, and the seller just manages their catalog and orders through that app's interface or API.
How does AI actually get used in ONDC integrations?
AI shows up mainly in catalog generation (turning photos, spreadsheets, or voice notes into structured product listings), search and ranking on buyer apps, conversational/voice ordering interfaces, delivery-time and logistics matching, and fraud or quality-anomaly detection for sellers — not inside the protocol itself, which just standardizes the messages exchanged.
Is ONDC only for Indian businesses?
ONDC as a live deployed network is India-specific, but it's built on the open-source Beckn protocol, which isn't exclusive to India and has been explored for similar open-network commerce and mobility deployments elsewhere.
Does selling on ONDC guarantee lower fees than a traditional platform?
Not automatically. The protocol itself doesn't set commission rates — individual seller-side and buyer-side network participants set their own fee structures, so actual costs depend on which network participant a seller chooses to onboard through.
What's the biggest practical challenge for a small seller joining ONDC?
Getting a clean, accurate catalog onto the network and then maintaining visibility across multiple buyer apps with different ranking logic, since there's no single algorithm to optimize for the way there would be on one dominant marketplace.
Teams evaluating ONDC integration — whether building a seller app, a catalog pipeline, or an AI-assisted onboarding tool — can get hands-on help from Woyce Technologies.