There is no switch inside Shopify that puts your catalogue on ONDC. An ONDC Shopify integration means one of two things: you sign up with a seller network participant who already speaks the protocol and feed them your products, or you build your own adapter that sits between Shopify's Admin API and ONDC's Beckn-based call-and-callback flow. The first takes days and costs little. The second takes a couple of months of engineering and only makes sense if you have volume, margin, or a catalogue that no off-the-shelf seller app maps cleanly. Either way, the hard part is not the plumbing. It is that ONDC asks for product data Shopify does not store, and order events Shopify does not naturally emit.
What sits between your store and the network
ONDC is a protocol, not a marketplace. Your store never talks to a buyer. It talks to a seller network participant (SNP), which registers on the network, holds signing keys, and answers calls from buyer apps. When a shopper searches on a consumer app, that app broadcasts a search across the network and every SNP replies with a catalogue payload. Then come select, init, confirm, status, track, cancel, update. Each is asynchronous: the buyer app calls, you acknowledge, you call back on the matching on_ endpoint. The spec sets response targets per call, measured in seconds. A storefront that takes four seconds to answer an inventory query is not going to pass.
If you build your own SNP, you also take on registry subscription, Ed25519 request signing, and hosting a verification file at your domain root. None of that is exotic. It is just a second production system with its own uptime obligation, sitting beside a Shopify store you did not previously have to monitor at 2am.
Most brands should start with an existing seller app. Prove demand first. Build the adapter when the order volume makes the control worth paying for.
How to list Shopify products on ONDC without redoing your catalogue twice
Shopify gives you title, body HTML, vendor, product type, tags, variants with SKU and barcode, weight, and an HS code field per variant tucked into the shipping section. ONDC wants considerably more, and it wants it in fixed shapes.
The fields that trip people up on the first pass:
- Category code. Not your collection name. The network has its own category and sub-category taxonomy per domain, and your 40 collections have to collapse into it. A "Festive Edit" collection is not a category.
- Statutory fields. Manufacturer or packer name and full address, net quantity, country of origin, month and year of manufacture. For packaged food, FSSAI licence number and shelf life. For electronics, warranty terms. These are legal metrology obligations that apply whether or not you are on ONDC, but on your own storefront nobody blocks the listing when they are missing. Here they do.
- Tax data. HSN and the applicable GST rate at item level. Shopify's HS code field can carry the HSN, but the rate usually lives in a tax app or a spreadsheet. Pull it into a metafield so there is one source of truth.
- Time to ship. An ISO-8601 duration per item. If you say P1D and your Delhivery pickup is a day late, that is a breach the buyer app can see.
- Returnable, cancellable, return window, seller-pickup-return. Four booleans and a duration that decide what happens in the worst week of your year.
Put all of it in Shopify metafields with a defined metaobject per category, not in tags. Tags are where catalogue data goes to die. Once the attributes are structured, the side benefit is that your own collection pages can finally filter on fabric, net quantity or shelf life, which is a job for something like FilterPro rather than another round of manual collections.
Budget real time for this. For a 200-SKU apparel catalogue we would expect one person to spend the better part of two weeks on attributes alone, and we still get roughly a third of the mappings wrong on the first sync. Grocery and packaged food are worse because the statutory set is longer and varies by sub-category.
Pincode serviceability is a pricing decision, not a config screen
Every catalogue response carries your fulfilment footprint. You can declare pan-India, a pincode list, a geo radius around a store, or a polygon. Most D2C brands shipping through Shiprocket or Delhivery pick pan-India because that is what their courier aggregator promises, then discover that the serviceability they declared and the serviceability they actually have diverge in the North East, in Jammu and Kashmir, and in a long tail of rural pincodes where only India Post delivers and the TAT doubles.
The clean approach: export your courier's serviceable pincode list, intersect it with your own last-90-day delivery data, and declare the intersection. Then split it. Metros where you ship next day get one time-to-ship value; everything else gets another. Declaring P2D nationally when half your orders take five days to reach the customer will cost you more in buyer-app ratings than the extra GMV from those pincodes is worth.
If you run more than one location, this gets genuinely messy. ONDC expects a provider location per fulfilment origin, and Shopify's multi-location inventory does not map one-to-one to it. We usually model each warehouse as its own provider location and route on the adapter side, which means your stock sync is now per-location, not per-variant.
Order management and the Shopify sync that bites
An ONDC order arrives as a confirm call. You create the corresponding order in Shopify through the Admin API, tag the source, decrement inventory, and call back. Straightforward. The problems start after that.
Money does not flow through your gateway. The payment was collected by the buyer app and reaches you through network settlement. So the order in Shopify is, from Shopify's point of view, unpaid or paid by a manual method. Hitting Refund in the Shopify admin moves nothing. Your finance process has to treat ONDC refunds as a settlement adjustment, and your ops team has to be told, in writing, not to press that button. We have seen this go wrong more than once.
Status has to be pushed, not polled. Buyer apps expect on_status updates as the shipment moves. That means subscribing to Shopify's fulfilment webhooks and your courier's tracking webhooks, then translating both into the network's fulfilment state vocabulary. Shiprocket's status strings do not line up with ONDC's, and you will write a mapping table.
Cancellation is bidirectional and time-bound. The buyer can cancel pre-dispatch. You can cancel for stock-out, which carries a penalty in the network's rules. Both have to reach Shopify as a real cancellation with restock, and reach your WMS before the picker tapes the box. If your pick-pack cycle is 20 minutes and your webhook retry window is longer than that, you will ship cancelled orders.
Oversell. Catalogue responses are cached by buyer apps. Push inventory on every inventory_levels/update webhook rather than on a schedule, and hold a small buffer on anything with fewer than five units during the Diwali run-up.
Logistics and returns: who picks up, and who eats it
You can fulfil yourself with your existing courier account, or use a logistics participant discovered on the network. Self-fulfilment with Delhivery or Blue Dart is simpler at the start because you keep your rate card and your escalation contacts. Network logistics becomes interesting when you want per-order price discovery across providers.
Returns are where the economics get real. If you declared seller-pickup-return true, you are arranging and paying for reverse pickup, and reverse legs in tier-3 pincodes routinely run two to three times the forward cost once failed attempts are counted. COD availability varies by buyer app and logistics partner, so treat prepaid as your baseline and model COD separately when it appears, with the RTO rate you already see on your own store rather than a hopeful one.
GST invoicing stays your job. The invoice you issue is the invoice the customer sees in the buyer app, with your GSTIN on it, and e-way bill rules apply exactly as they do elsewhere.
ONDC seller app integration cost, honestly
Going through an existing seller app: onboarding is typically free or a small monthly fee, with a commission on orders. Your real cost is catalogue preparation, which for a mid-sized catalogue is one to three weeks of a person's time. Call it ₹40,000–₹1,20,000 if you outsource it.
Building your own adapter and running as an SNP: this is a protocol implementation with signing, a registry subscription, a callback service, idempotency handling, retries, a reconciliation job for settlement, and a staging environment for network certification. We scope that as an eight-to-twelve-week build. In Indian agency terms that lands in the ₹6–15 lakh band depending on how many domains and how many fulfilment models you support, which is in line with the rest of our Shopify development cost ranges. Then add a maintenance retainer, because the spec version changes and you have to keep up. If you want the adapter packaged so other merchants can use it, that is a different conversation and closer to app development than to a one-off integration.
Do the arithmetic before you commission anything. If the build is ₹8 lakh and your blended contribution margin is ₹300 an order, you need roughly 2,700 incremental orders just to clear the build, before anyone touches a keyboard for maintenance. At 300 ONDC orders a month that is nine months to break even. Fine for some brands. Nonsense for most.
ONDC versus Amazon and Flipkart for a D2C brand
The comparison people make is commission, and on commission the network generally wins because buyer-app finder fees sit well below marketplace category rates. Take a ₹1,200 order. At a 15% marketplace commission plus a ₹60 closing fee plus ₹70 shipping, you are down ₹310 before COGS. If a buyer app takes 4% and you ship on your own rate card at ₹65, you are down ₹113. Those are illustrative rates, not quoted ones, but the shape of the gap is the point.
Demand is the other half, and it is where the marketplaces still win comfortably. Amazon and Flipkart bring an audience with intent and a search box people already use. ONDC brings reach through whichever consumer apps are live in your category, and that set changes. Before you commit a quarter to this, open the main buyer apps, search your category, and look at how many sellers are there and how the listings render. If your category looks thin, that is a signal, not a gap in the market.
The honest framing: ONDC is a cheaper incremental channel, not a replacement for your own store. Your Shopify storefront is still where Meta and Google traffic lands, where your WhatsApp retention flows point, and where you control the data. Nothing on the network changes that.
Is it worth it for your brand?
Worth it, usually:
- Grocery, packaged food and daily needs, where the hyperlocal buyer apps have real traffic and repeat frequency does the heavy lifting.
- Low-AOV, high-frequency products where a 25–35% marketplace take rate kills the unit economics outright.
- Brands with physical stores who can serve a radius and want store-level discovery.
- Anyone whose Meta CAC has drifted past a third of AOV. If you are paying ₹450 to acquire on a ₹1,200 order, a 4% channel fee looks like a gift.
Probably not worth it yet: high-consideration categories where the purchase needs your brand story, anything with heavy sizing or fit returns, made-to-order products with variable dispatch times, and catalogues under about 50 SKUs where the fixed attribute work swamps the upside. Fashion sits awkwardly in the middle. The returns are the reason.
Questions we get asked in the first call
Can I use the same inventory pool for my store and the network? Yes, and you should, with a buffer. Separate pools sound safer and in practice leave stock stranded on the slower channel during festive week.
How long before the first order? Through an existing seller app, two to four weeks from kickoff, most of it catalogue work and buyer-app review. Own adapter, add the build time plus network certification.
Does it affect my store's SEO? No. Your listings live on buyer apps, not on indexable pages you control.
What breaks most often? Status callbacks timing out during traffic spikes, and serviceability declared wider than reality. Both are fixable. Both are embarrassing in front of a buyer app's rating system.
If you are weighing this up, the useful first step is not a vendor demo. Export your product CSV, pick your twenty best sellers, and try to fill in every statutory and fulfilment attribute listed above by hand. Whatever you cannot fill in within an hour is the actual project. Happy to look at that list with you in a free store audit and tell you whether the integration is worth your quarter.