ONDC + AI: Selling on India's Open Commerce Network

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 integration 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. It covers the buyer-app, seller-app, and gateway roles; the specific places AI earns its keep, from catalog generation to logistics matching; a comparison with closed marketplaces; a step-by-step path to getting listed; and the limitations that still make the network harder to work with than a single platform.

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. ONDC follows a pattern India has used before: UPI unbundled payments the same way, letting many competing apps run on top of shared rails rather than one company owning the transaction.

AI Use Cases in ONDC Integration

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:

1. Extract structured fields from product photos and informal descriptions.
2. Map free-text category names to the standardized ONDC taxonomy.
3. Translate and transliterate listings across Indian languages so a single catalog can serve buyer apps in different regions.
4. 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.

Benefits of ONDC Integration

For sellers and builders, the open network offers a different set of trade-offs from a single marketplace. These are the advantages that follow from its design, with the caveat that actual results depend heavily on the participants a business chooses.

Reach Across Many Buyer Apps From One Catalog

A seller listed through one seller app can appear in every buyer app on the network that serves its category and area. One structured catalog, built once to the standard schema, reaches shoppers wherever they search. On a closed platform, each new marketplace means a new account, a new template, and a new set of rules to learn.

Choice Over Fees and Partners

Because no single company sets the terms, sellers can compare seller apps on fees, tools, language support, and settlement timelines, and switch or add participants when another offers a better deal. Logistics is a separate decision, so a seller is not tied to one company's delivery fleet. That choice does not guarantee lower costs, but it gives sellers negotiating room they rarely have on a dominant platform.

A Portable Catalog Under the Seller's Control

The catalog follows a standardized Beckn schema rather than one marketplace's proprietary format. Work spent cleaning product data, mapping categories, and translating listings is reusable across participants. If a seller changes seller app, the structured catalog moves with them, which reduces the cost of switching and the risk of being locked in.

Room for New Apps and Specialised Services

Developers can build a buyer app, a vertical seller app, or a logistics service without building the rest of the marketplace. A pharmacy-focused app or a regional-language ordering assistant can plug into existing supply on the network. That lowers the barrier to launching a focused commerce product and lets builders compete on how well they serve a specific audience.

Inclusion for Small and Offline Sellers

With AI-assisted catalog tools turning photos, voice notes, and price lists into structured listings, sellers without digital inventory systems can get online with far less effort. A neighbourhood store can be discovered alongside larger retailers without paying a platform for visibility, which is the inclusion goal the network was built around.

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.

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.

Common ONDC Integration Mistakes

Sellers and builders new to the network tend to carry habits over from closed marketplaces. These are the ones that cost the most.

Publishing AI-Generated Catalogs Without Review

Catalog extraction from photos and price lists saves real time, but models get units, categories, and translations wrong. On a closed platform, a manual review step might catch those errors; on ONDC, they go straight to buyer apps. Wrong prices or units lead to cancelled orders and complaints. Someone who knows the products should review every listing before it goes live, at least for the first few batches.

Optimizing for a Single Buyer App

Sellers used to tuning listings for one marketplace's algorithm sometimes do the same for whichever buyer app sends their first orders. With ranking spread across many apps, that effort rarely carries over. Complete, accurate catalogs with clear delivery promises perform more consistently across the network than tweaks aimed at one app.

Choosing a Seller App on Commission Alone

A low headline commission can hide weak catalog tools, poor language support, slow settlement, or limited logistics options. Total cost and capability matter more than one percentage. Compare fees alongside the features that affect visibility and operations.

Overpromising Delivery Times

Ambitious delivery estimates win the first order and lose the second. Missed promises show up in the reliability signals buyer apps use to rank and trust sellers. Set delivery promises per location based on what you or your logistics partner can actually meet.

Building a Direct Protocol Integration Too Early

Implementing the Beckn protocol directly is a multi-month project with ongoing maintenance as schemas evolve. Businesses that only need to sell usually get there faster and cheaper through an existing seller app, saving direct integration for when they serve many merchants or need functionality no participant offers.

ONDC Integration Best Practices: A Step-by-Step Path

For most sellers and brands, getting onto the network is an onboarding and catalog project rather than a protocol-engineering one. A practical sequence:

1. Decide your role. Most businesses join as sellers through an existing seller-side network participant. Building your own seller app, buyer app, or logistics integration only makes sense if you plan to serve many merchants or need deep custom functionality.
2. Compare seller-app participants. Look at fees, supported categories, catalog tools, language support, logistics options, settlement timelines, and whether they offer an API to connect your existing POS or inventory system.
3. Prepare your catalog data. Gather product names, units, prices, images, GST details, and category mappings. This is where AI-assisted extraction from photos and spreadsheets saves the most time, provided someone reviews the output.
4. Map to the ONDC taxonomy and validate. Check that categories and attributes match what buyer apps expect. Missing units or wrong categories are the most common reason listings perform poorly.
5. Choose fulfillment. Decide whether you deliver yourself or use a logistics network participant, and set realistic delivery promises per location.
6. Run a soft launch. List a subset of products in one area, place test orders through more than one buyer app, and confirm how your listings appear, how orders reach you, and how cancellations and returns flow.
7. Monitor and expand. Track which buyer apps send orders, which listings convert, and where complaints arise, then broaden your catalog and consider registering with a second seller app.
8. Keep inventory and prices in sync. Connect your seller app to whatever stock record you already keep, even a simple spreadsheet, and set a routine for updating it. Orders for items that are out of stock or wrongly priced lead to cancellations, which buyer apps notice when deciding how to rank you.

For developers building a seller app or catalog pipeline, the same steps apply, plus implementing the Beckn message pairs and network participant registration. The Beckn protocol documentation is the starting point for the specification.

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.

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.

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. ONDC was set up as an initiative backed by India's Department for Promotion of Industry and Internal Trade. A shopper uses any participating buyer app, a seller lists through any participating seller app, and the protocol connects the two.

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. Sellers aren't locked into one platform's rules, commissions, or fulfillment fleet. The trade-off is less central control: support, dispute resolution, and quality checks are spread across several companies rather than handled by one.

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. Developers building their own seller or buyer app do need to implement the protocol's message pairs, signing, and registration, which is closer to a payments-style integration than a typical marketplace 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. The most immediate return usually comes from catalog generation, because poor catalog data limits visibility on every buyer app. Ranking and conversational ordering matter more for teams building buyer apps.

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. A foreign brand that wants to sell to Indian consumers through ONDC would still go through Indian seller-side participants and meet local requirements such as GST registration, so in practice participation is tied to operating in India.

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. Compare the full cost, including seller-app fees, buyer-app fees where applicable, logistics charges, payment settlement terms, and any subscription costs, rather than looking at commission rates alone.

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. Small sellers without digital inventory systems also struggle to keep stock and prices current. Choosing a seller app with good catalog tools and connecting it to whatever inventory record you already keep makes the biggest difference.

How long does ONDC integration take?

For a seller onboarding through an existing seller app, getting listed can be a matter of days to a few weeks, mostly spent preparing and reviewing catalog data. Building a custom seller app, buyer app, or catalog pipeline that implements the Beckn protocol directly is a multi-month engineering project, because it involves message handling, signing and registration, testing with other participants, and network compliance checks. AI-assisted catalog tooling speeds up the data work in both cases.

Conclusion

ONDC changes where the work of commerce happens. Instead of one marketplace owning the catalog, search ranking, and fulfillment, those jobs are split across buyer apps, seller apps, and logistics providers that speak the same Beckn-based protocol. That opens the door for small sellers and new apps, but it also means someone in each part of the chain has to do the interpretation work a platform used to do centrally.

That's where AI does real work: turning photos, voice notes, and spreadsheets into structured catalogs; matching queries to listings across languages; supporting voice and chat ordering; estimating delivery and choosing logistics providers; and flagging unreliable sellers. None of it lives inside the protocol, and all of it depends on good data.

The caveats are practical. Discovery varies between buyer apps, disputes cross company boundaries, AI-generated catalog data still needs human review, fees depend on the participant you choose, and coverage differs by city and category.

For most sellers, the right first step is choosing a seller app and getting a clean catalog live in one area. If you're building a seller app, catalog pipeline, or AI-assisted onboarding tool on the network, our AI and machine learning team can help you plan it.