If you've been asked to "add ONDC support" to a client's e-commerce backend, here's the technical reality: ONDC isn't an SDK you drop in, it's an implementation of the Beckn Protocol, an open API specification for decentralized commerce built on discovery, order, fulfillment, and settlement transaction flows between a Buyer App (BAP) and Seller App (BPP).
For most dev teams, the practical entry point isn't building a full Network Participant from scratch — it's building a middleware connector that maps your client's existing product and order APIs into Beckn-compliant JSON payloads, validates against ONDC's sandbox, and handles the async callback pattern the protocol uses (search → on_search, select → on_select, and so on through confirm/status/cancel).
Three things catch teams off guard: the callback-based async flow requires a message-queue-backed architecture rather than simple synchronous request/response; catalog data needs structured attributes (category codes, GTIN/HSN where applicable) that most existing product databases don't have cleanly; and settlement reconciliation across multiple buyer apps needs its own ledger logic if you're running as a Network Participant rather than through an aggregator.
We recently wrote up the full cost and architecture breakdown for the three integration paths — aggregator listing, middleware connector, and full custom BPP — with real 2026 INR pricing for each: ONDC Integration for Indian Businesses in 2026 →
If you're scoping an ONDC integration for a client, start with the connector path unless they specifically need to onboard other sellers under their own brand — it's a fraction of the engineering effort of a full BPP build.
Top comments (0)