A retailer publishes its catalogue to a new channel and the first order arrives. At almost the same moment, a walk-in customer buys the final unit. Both transactions looked valid when they started. Now someone must cancel an order, explain the outcome and repair the inventory count.
For an Indian business evaluating ONDC integration, the catalogue is only the entrance. The software must make a stock promise that remains coherent across existing tills, warehouses and online channels. The right development brief starts with the last available item, not the first successful product search.
Define which participant and contract you are building for
ONDC's official developer quickstart introduces the network's technical resources and participant flows. Its retail specifications repository covers discovery, ordering, fulfilment and post-fulfilment across relevant retail models. These are primary starting points, not a licence to mix examples from different domains or versions.
Identify your role, the applicable current network contract, intended category and onboarding requirements with the relevant ONDC resources and partners. Pin the specifications and test environment used in the project. A working example from an older repository may illustrate a concept without being the contract your production integration must satisfy.
Also decide whether your business needs its own participant software or an integration with an existing seller solution. If an established product handles the required network operations well, custom work may be most valuable between that product and your inventory system. Owning more code is not automatically owning a better operation.
Available stock is a business decision
Physical stock, reserved stock and available-to-sell stock are different quantities. A damaged unit may still be physically present but unavailable. An order being packed may reserve stock before the accounting system records a completed sale. Your new channel needs the quantity it is allowed to promise, not a convenient total from a warehouse export.
Choose the authoritative reservation system. If each sales channel independently subtracts from its own cached count, simultaneous orders can oversell the same unit. Centralise the decision where practical or explicitly define the limits and reconciliation behaviour of a distributed arrangement.
Document when a reservation begins, how it expires and which event turns it into a committed allocation. Align those decisions with the chosen network contract and fulfilment process. Do not invent a reservation at every search request, and do not assume that a catalogue update can resolve an order already accepted.
Follow one item through competing actions
An illustrative acceptance case starts with one saleable unit. A store sale and a network order arrive close together. The intended result is not that both return success quickly. It is that the system makes one coherent allocation and gives the other journey the appropriate truthful outcome.
Then introduce cancellation. If an order is cancelled before picking, stock may become available again under your process. If it has already been dispatched, the system cannot simply add the unit back to the shelf. A return needs its own receipt and condition review before the item becomes saleable.
Separate cancellation requested, cancellation confirmed, return expected and stock received. Those states answer different questions for the buyer, warehouse and finance teams. A shortcut that adds stock on the first cancellation message can create a new oversell before the original parcel even returns.
Keep protocol messages connected to business identity
Network messages may be retried, delayed or observed after staff have taken action through another channel. Store the identifiers required by the agreed contract and link them to your internal order, fulfilment and payment records. Keep enough event history to reconstruct the sequence.
A repeated callback should not create a second internal order. An older status should not erase a later confirmed outcome. A network acknowledgement and a completed business action should remain distinguishable in the support screen. These behaviours need concrete tests against the selected integration partner.
Protect the interfaces as well as the stock counter. Validate messages according to the applicable protocol and trust arrangements, restrict operational access and keep sensitive customer data out of broad diagnostic logs. A test environment should use suitable synthetic or authorised sample data rather than copied customer records.
Map catalogue changes to active orders carefully
Product descriptions, prices and availability can change while an order is in progress. Preserve what was agreed for the order and track subsequent changes through the permitted process. A catalogue refresh should not silently rewrite an accepted order's item or commercial terms.
Variant mapping deserves particular attention. A shared product title is not enough to distinguish size, colour, pack quantity or unit of measure. Test the specific variant from discovery through picking. A product image that looks correct can conceal an incorrect warehouse SKU mapping.
If your ERP stores bundles differently from the network-facing catalogue, document the decomposition into stock components. Reserving a bundle needs to account for the required components. A bundle that appears available because its parent record has a positive count may still be impossible to fulfil.
Build a seller operations desk
The useful administration screen groups orders by the action your team can take: allocation conflict, picking issue, cancellation awaiting response, shipment discrepancy or return awaiting inspection. Show the responsible system and last confirmed external state alongside the internal task.
Give staff a supported way to investigate and resolve exceptions without manually editing inventory in several places. Record the reason for an adjustment and its relationship to the order. Restrict high-impact actions such as cancelling an accepted order or overriding stock to authorised roles.
The seller should also be able to pause new promises when inventory is uncertain while preserving support for orders already accepted. A partial outage is a reason to reduce new commitments, not to make existing customer history disappear.
Purchase a pilot with measurable fulfilment evidence
Start with one location, a manageable set of variants and the real inventory source. Test competing orders, duplicate callbacks, cancellation during picking and a returned item that cannot be resold. Include a product mapping correction after an order has already been accepted.
Measure accepted orders that can be fulfilled, manual stock corrections and unresolved cancellation cases using your own baseline. Network connectivity is necessary, but it is not the business outcome. Require a handover covering specification changes, partner support and daily reconciliation.
Our ecommerce migration guide helps assess integration boundaries, and the MVP acceptance checklist turns operational expectations into tests. TuniCyberLabs provides custom software development for inventory and commerce workflows. Discuss an ONDC integration pilot with your seller solution, stock system and one example of a promise your existing channels struggle to keep.