ONDC, Explained Properly: How the Open Network for Digital Commerce Actually Works

ONDC — the Open Network for Digital Commerce — is one of those initiatives that is easier to dismiss than to understand. The pitch sounds either utopian or absurd depending on the room: a single open network where any buyer app can transact with any seller app, decoupling the discovery, ordering, fulfilment, and payment layers that Amazon, Flipkart, and Meesho currently bundle. As of 2026, ONDC processes roughly 12 million transactions per month — small compared to the established marketplaces, but no longer a curiosity. The interesting question is no longer whether ONDC is a real thing. The interesting question is what its actual architecture is, and what builders should do about it.

I want to walk through the protocol, the participant roles, the data flow, and what the experience is like in 2026. This is not policy commentary. This is the technical shape, written for engineers who have to integrate.

The Beckn protocol and why it matters#

ONDC’s protocol layer is Beckn — an open transport protocol for commerce that predates ONDC by a few years and is also being used outside India (for example by some Kenyan and ASEAN open-commerce experiments). Beckn defines a small set of HTTP/JSON message types: search, on_search, select, on_select, init, on_init, confirm, on_confirm, status, on_status, track, on_track, cancel, on_cancel, rating, on_rating, support, on_support, and a few more for updates and reconciliation.

The model is asynchronous. A buyer app does not call a seller app directly. Instead, both sides talk to a gateway which broadcasts and aggregates. A buyer’s search request is broadcast to all seller apps that match a domain (grocery, electronics, mobility, etc.) and the responses come back asynchronously as on_search messages over the next several seconds. The buyer app aggregates, ranks, and presents.

This is fundamentally different from the marketplace model. In the marketplace model, Amazon’s catalogue is a closed database; you cannot search it from outside. In Beckn, every seller’s catalogue is reachable through the network; the buyer app does not own discovery. The buyer app owns presentation — ranking, filtering, recommendations — which is where it competes.

Each message is signed with the participant’s identity (issued by the network’s registry) so the gateway can route trustfully. Settlement is separate; the protocol carries enough metadata that money and goods can be reconciled across counterparties without a central clearer.

The participants#

There are five primary roles.

Buyer Apps (BAPs) — the consumer-facing surface. They take a user’s intent (a search, a cart, a checkout) and translate it into Beckn messages. Examples in 2026 include Paytm’s ONDC integration, the ONDC store on PhonePe, Magicpin, the standalone Mystore app, the Tata Neu integration, and a long tail of vertical apps for grocery and food.

Seller Apps (BPPs) — the catalogue surface. They expose a merchant’s products, prices, inventory, and fulfilment options via Beckn endpoints. The largest BPPs aggregate many merchants; for example eSamudaay and Mystore-as-seller carry tens of thousands of small businesses. Larger merchants (Reliance Smart, Spencer’s, ITC, Tanishq) run their own BPPs.

Gateways — the broadcasters. They take a buyer’s search and fan it out to all relevant BPPs. They do not store catalogue data; they only route.

Logistics Service Providers (LSPs) — the fulfilment layer. A BPP that doesn’t have its own delivery (most don’t) selects an LSP via Beckn’s Logistics profile — Loadshare, Shadowfax, Dunzo Daily, Borzo, Porter — and that LSP picks up and delivers. The handoff is also Beckn-spec.

Network participants in the financial and trust layer — the settlement provider, the dispute resolution body (ONDC IGM — issue and grievance management), the network operator (ONDC itself, which is a Section 8 non-profit), and the registry (which signs and validates identities).

This separation of roles is the entire point. A failure or fee increase from any one participant does not bring down the network. A new buyer app can launch by integrating once and reach every seller. A new seller does not have to negotiate listing fees with the dominant marketplace.

The data flow for a single order#

To make this concrete, here is what happens when a user buys a 5kg bag of rice on a Paytm ONDC integration in 2026.

1. User types “rice 5kg” into the search bar. The buyer app constructs a Beckn search message with the query, the user’s location (truncated to a 1km cell for privacy), and the relevant domain. The message is signed and posted to the ONDC gateway.

2. The gateway looks up all BPPs registered for the nic2004:55204 domain (retail-grocery) within the geo-cell and forwards the message to each. As of 2026, this is typically 80-200 BPPs depending on the city.

3. Each BPP queries its own catalogue and responds with an on_search message containing matched products, prices, fulfilment options, and a TTL. Some BPPs respond in 200ms, some in 4 seconds, some never. The buyer app waits for a configurable window (typically 8 seconds) and then closes the search.

4. The user picks a product. The buyer app sends select to the chosen BPP (now a direct call), which responds with on_select confirming availability, the final price including any taxes, and the available fulfilment slots.

5. User taps “checkout.” The buyer app sends init, the BPP sends on_init with the payment link (almost always UPI), the user pays via UPI, the BPP confirms via on_confirm, and the order is placed.

6. The BPP triggers its LSP — typically by emitting another Beckn search on the nic2004:80100 (logistics) domain — to find a delivery partner. The LSP responds, picks up, delivers, and emits on_status updates throughout.

7. Settlement happens through the ONDC settlement provider (Yes Bank is the most common in 2026) which reconciles the money flow from the buyer through the BAP to the BPP, minus the LSP fee, minus the network fee, minus the BAP commission. The buyer sees a single UPI debit; the settlement is netted across counterparties on T+1.

Eight participants, one user, one debit. The plumbing is invisible to the buyer.

What’s actually working in 2026#

After three years of beta-flavoured launches, ONDC has found three product-market fits.

Restaurant food is the largest category and the most contested. Magicpin’s ONDC integration has eaten meaningfully into Zomato and Swift in the cities where it launched aggressively. The pitch to restaurants is simple: ONDC commissions are 3-5% versus 20-30% on Zomato/Swiggy. Restaurants list once, get orders from any BAP. The pitch to consumers is that the same restaurant menu costs 15-25% less because the commission savings are passed through. Whether this margin compression survives Zomato and Swiggy’s predictable counter-pressure is the open question.

Pharmacy and grocery are the second-largest categories, with a long tail of local pharmacies and kirana stores listing through aggregator BPPs. The unit economics work because the average ticket size is small and the delivery distance is short; the LSP costs do not crush the margin.

Mobility — auto-rickshaws and bikes — is the surprise. The Namma Yatri app in Bengaluru runs on ONDC’s mobility profile and has captured serious share from Ola and Uber in the auto-rickshaw segment. Drivers prefer it because the commission is 0-2% versus 25-30% on Ola/Uber. Bengaluru’s auto union actively promotes it.

The categories that are not yet working: electronics, apparel, anything where return rates matter and trust is brand-mediated. These categories need the kind of inventory-managed catalogue model that ONDC’s open network does not enforce. They may take years.

Integration practicalities for builders#

If you are a small business or D2C brand wondering whether to list on ONDC, the practical answer in 2026 is: list through an aggregator BPP rather than building your own. eSamudaay, Mystore, Lukshmi, and a dozen others provide BPP-as-a-service with a familiar admin UI, and they handle the Beckn integration, the registry signing, and the settlement reconciliation. The marginal cost is a small percentage of GMV.

If you are building a buyer app, the integration is more involved. You implement the full Beckn message set, you obtain a BAP registration from ONDC, you wire up identity signing with the registry’s private key infrastructure, you handle the async broadcast/aggregate model, and you build your own ranking and presentation. Open-source reference implementations exist — protocol-server from ONDC’s GitHub — but the production stuff is largely your own.

If you are an LSP or a settlement provider, the integration is heavy but the volume is becoming worth it.

The honest assessment#

ONDC is not Amazon. It does not have a single curated catalogue, a single trust signal, or a single brand. It is a protocol with participants. That is its strength in the categories where commodity goods + price sensitivity + local delivery dominate — food, groceries, mobility — and its weakness in the categories where brand, trust, and presentation matter.

For builders, the question is not whether to participate. The question is which role you play and whether the network reaches the volume that makes that role economically viable. In 2026, that volume is reachable in three categories and questionable in the rest. Watch the next eighteen months.

Where pdpspectra fits#

We integrate ONDC for retailers, D2C brands, and buyer-app builders out of our Kathmandu and Boston offices, and the data engineering team builds the catalogue ingestion, the BAP/BPP integration, and the settlement reconciliation.

Related reading: the Indian fintech stack post, the Beckn protocol overview, and the digital public infrastructure comparison.

---

ONDC is the most ambitious open-commerce experiment in any major market. Talk to our team about where it fits in your roadmap.