Retail POS and omnichannel apps in India: what a 2026 build actually involves

Summary. India's Open Network for Digital Commerce has recorded 83,864,322 retail orders across 862 districts from 167,468 sellers, according to ONDC's own open data portal checked on 3 August 2026, and Gurugram is the single highest-ordering district in the country. Retailers reaching those buyers now need one inventory view across store, web, marketplace and network, and the software decision is no longer "which POS" but "how much of this do we buy and how much do we build". Shopify, one of eCorpIT's platform partners, prices its retail stack at $39 to $399 USD a month by plan plus $89 USD a month for each POS Pro location, with in-person card rates from 2.6% + 10¢ down to 2.4% + 10¢ depending on plan. That covers a standard store. It does not cover a UPI-first checkout, an ONDC seller integration, a counter that keeps billing when the internet drops, or a loyalty programme built on DPDP-aligned consent. Those are build, and they are what an Indian omnichannel programme actually spends its engineering budget on. Two 2026 deadlines set the schedule: Google Play requires new apps and updates to target Android 16 (API level 36) from 31 August 2026, and Apple has required iOS 26 SDK builds for App Store Connect uploads since 28 April 2026.

Where the buy-versus-build line actually falls

Most Indian retailers we speak to have already bought a POS. The problem is rarely the till. It is that the till, the ecommerce site, the marketplace listings and the WhatsApp orders each hold a different version of stock, and nobody can promise a customer that the item is there.

A platform POS solves the store-plus-web half of that. Shopify's omnichannel product documents buy online with in-store pickup, buy in store and ship, browse in store and buy online, automatic inventory syncing across locations, centralised order management for local delivery, pickup, returns and exchanges, and automatic customer profile syncing. Gosia Piatek, Founder and Creative Director at Kowtow, describes the practical effect: "With Shopify, we can easily look up a customer's previous orders and make our in-store service feel like a natural extension of what they experience online."

What no global platform ships out of the box is the India layer. That is the part worth building, and the part worth costing carefully.

The honest version of the advice: buy the commodity, build the differentiator. A retailer who builds their own card processing is burning money. A retailer who treats ONDC publishing and offline billing as configuration is going to be disappointed twice.

The offline problem is the hard problem

Every India retail build eventually reduces to one question: what happens at the counter when connectivity drops mid-transaction?

The naive answer is a local cache. The real answer is a conflict model. If two tills in the same store sell the last unit of a SKU while both are offline, the system has to decide which sale wins, what the second customer is told, and how the stock ledger reconciles when both come back online. Getting that wrong produces oversell, which in an omnichannel setup means a cancelled online order and a refund, which is more expensive than the sale was worth.

The design decisions that matter:

• Choose an append-only local transaction log, not a mutable local copy of stock. Sales are events; stock is derived.

• Assign every offline transaction a device-scoped identifier at creation, so replays are idempotent when the till reconnects.

• Decide per-SKU whether the business prefers to oversell and apologise or block the sale. Fast-moving low-margin items and slow-moving high-value items usually deserve opposite answers.

• Reconcile on a server-authoritative clock, not device time. Counter tablets drift and staff change them.

• Make the sync state visible to the cashier. A silent queue is how a store discovers three days of unsynced sales.

This is the single most common reason an Indian retail rollout stalls at store number twelve. It is also why an enterprise mobile app development approach beats treating the POS app as a thin front end.

ONDC: what integration actually means

ONDC's open data portal is the sober counterweight to network hype and the best planning input available. As of 3 August 2026 it shows 83,864,322 total retail orders placed, 167,468 sellers and coverage across 862 districts, with Karnataka recording the highest order count and Gurugram, Bengaluru Urban and Gautam Buddha Nagar the top three districts by orders.

Two things follow for a retailer. First, the demand is real but concentrated: if your stores are in those districts, network participation is a live channel, not an experiment. Second, becoming a seller on the network is a data-quality project before it is an integration project. The network needs catalogue, price, availability and fulfilment promises that stay accurate, and if your inventory truth is already split across four systems, publishing it to a fifth makes the problem worse rather than better.

The sequencing we recommend is unglamorous and it works:

1. Establish one system of record for stock and price. Everything else reads from it.

1. Instrument accuracy before you publish. Measure how often store stock and system stock disagree for a month.

1. Publish a narrow catalogue to the network first, ideally one category from one fulfilment location.

1. Only then widen, and only as fast as the accuracy numbers allow.

Retailers who invert steps two and three end up with cancellations on the network, and cancellations are the one thing a new seller cannot afford.

The 2026 deadlines that set your timeline

Two platform requirements constrain any retail app schedule this year, and both are published by the platform owners.

Google's target API level page, last updated 15 July 2026, states that starting 31 August 2026, "New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play; except for Wear OS and Android Automotive OS apps, which must target Android 15 (API level 35) or higher, and Android TV and Android XR apps, which must target Android 14 (API level 34) or higher." Existing apps must target Android 15 (API level 35) or higher "to remain available to new users on devices running Android OS higher than your app's target API level". The page adds that "if you need more time to update your app, you'll be able to request an extension to November 1, 2026".

Apple's requirement already applies. Its developer news post of 3 February 2026 states that starting 28 April 2026, iOS and iPadOS apps uploaded to App Store Connect "must be built with the iOS 26 & iPadOS 26 SDK or later", with equivalent floors for tvOS, visionOS and watchOS.

For a retailer whose customer app or store app is a year old, this is the difference between a September launch and a January one. It is the first thing worth checking, before the feature list.

Three more dates that catch retail apps specifically

Google's Play Console policy deadlines table lists two changes dated 28 October 2026, both announced on 15 April 2026, that land squarely on retail features. The Contacts Permissions policy will require apps that do not need broad contact access to use the Android Contact Picker instead, which affects any loyalty flow that imports a customer's contacts. The Location Permissions policy introduces the location button as the recommended minimum scope for precise location, which affects store locators and delivery-address capture.

Separately, Android developer verification starts to bite. Google's developer verification page states that starting in September 2026, apps downloaded from participating stores in select regions must be registered by a verified developer to be installed on certified Android devices, with organisations needing a D-U-N-S number and a verified website alongside identity documents, and package names registered by proving ownership with a signed APK. Google's 15 July 2026 policy announcement adds that while 99% of Play apps were registered automatically, developers should check Play Console and register any remaining apps "to avoid global removal from Google Play". Retailers who side-load a staff-only store application outside Play are the group most likely to be caught by this.

One clarification in the same announcement deserves a line in your privacy review: Google states that its User Data requirements "also apply to third-party AI integrations and that developers remain responsible for ensuring compliance with this policy, including limited use, disclosure and consent". If your POS app added an AI assistant this year, that assistant is inside your data-policy perimeter.

What a realistic programme looks like

An omnichannel programme that works in Indian retail is usually four workstreams running in parallel rather than one big-bang launch.

Foundation

One inventory and price system of record, an event log for sales, and an integration layer that every channel reads from. Nothing customer-facing ships until this exists, because everything downstream inherits its errors.

Store

The counter application: offline data synchronization, UPI and card checkout, GST-compliant invoicing, returns and exchanges across locations, and a vernacular interface that a new hire can use on day one. This is where most of the custom engineering sits.

Channels

Web and app storefronts, marketplace listings, ONDC publishing, and WhatsApp or RCS ordering where the customer base already lives. Each channel is a read of the same truth, never its own truth.

Data

Customer profiles, loyalty, and analytics, with consent captured at the point of collection and purpose recorded against it. Retrofitting consent into an existing customer database is significantly more expensive than designing it in, which is the argument for doing this in the foundation phase even though it feels like a phase-three concern.

A first release covering foundation plus store for a pilot cluster of stores is a realistic scope for an initial engagement. Channels and data follow once the accuracy numbers hold. Anyone promising all four in a single release is either scoping thinly or planning to rewrite.

India-specific considerations

Three points that global vendors will not raise in a demo.

Payments

In-store payment mix in India is not a card-first mix. Shopify's published in-person card rates start at 2.6% + 10¢ USD and fall to 2.4% + 10¢ USD on higher plans, which is the right frame for card volume but not for the UPI share of a typical Indian counter. Model the blended cost of acceptance across your actual method mix before you assume a platform's headline rate is your rate.

Hardware reality

Counter hardware in Indian retail is heterogeneous by default: Android tablets of several generations, thermal printers of several makes, and barcode scanners bought at different times. A build that assumes one device profile will fail at store number three. Target the oldest device you actually have in the field, not the newest.

Data protection

Under the Digital Personal Data Protection Act 2023, a retail loyalty programme is a consent-driven system, not a mailing list. The engineering implications are concrete: capture consent at the point of collection with a recorded purpose, keep the consent record joinable to the customer record, and make deletion propagate to every downstream copy including the analytics warehouse. eCorpIT designs applications aligned with DPDP Act requirements, and the practical advice is to build the consent ledger in the foundation phase rather than bolt it on after launch. Teams already working through DPDP-ready app development will recognise the pattern.

How we work

eCorpIT was founded in 2021 and is based in Sector 83, Gurugram, in the district that ONDC's own data shows placing the most retail orders in the country. Our retail engagements follow a consistent shape:

1. Discovery, two to three weeks: application portfolio analysis of the current stack, a stock-accuracy measurement against real store data, and an integration map. The output is a phased plan with the buy-versus-build line drawn explicitly.

1. Foundation build: system of record, event log and integration layer, with the consent ledger designed in.

1. Store pilot: counter application in a small cluster of stores, with offline data synchronization proven under real connectivity, not in a lab.

1. Channel rollout: web, app, marketplace and ONDC publishing, sequenced against accuracy metrics.

1. Run and improve: support, release management against the platform deadlines above, and iteration on the numbers the pilot produced.

We are a senior-led, multi-disciplinary organisation rather than a body shop, and we are CMMI Level 5, ISO 27001:2022 certified and MSME certified. Our platform partners include AWS, Microsoft, Google, Shopify and Kaspersky, which means we can take a retailer down a buy-heavy Shopify path or a build-heavy custom path and be honest about which one their situation calls for. Related work we do sits alongside this: ecommerce app development, quick commerce and dark store apps, and WhatsApp and RCS business messaging.

Who this is not for

Two situations where we will say so early. If you run a single store with a simple catalogue, a platform POS on its own is almost certainly the right answer and a custom build is not worth the money. And if your stock accuracy is unmeasured, no amount of software will fix the symptom; the first engagement should be measurement, not development. We would rather scope a three-week diagnostic than a six-month build that solves the wrong problem.

FAQ

How eCorpIT can help

eCorpIT builds retail POS and omnichannel systems for Indian and global retailers from Gurugram, covering the parts a platform does not ship: offline counter billing, UPI-first checkout, ONDC publishing, GST-compliant invoicing and consent-driven loyalty. Our senior engineering teams start with an application portfolio analysis and a stock-accuracy measurement, then draw the buy-versus-build line explicitly before any code is written. As a CMMI Level 5, ISO 27001:2022 certified and MSME certified organisation with AWS, Microsoft, Google and Shopify partnerships, we can take you down either path honestly. Talk to us via /contact-us/ about scoping a retail discovery.

References

1. ONDC Open Data, retail orders. ONDC, network totals for orders, sellers and districts, checked 3 August 2026.

1. Shopify POS pricing. Shopify, plan prices, POS Pro per-location pricing and in-person card rates.

1. Omnichannel POS. Shopify, on buy online and pick up in store, inventory syncing, order management and the Kowtow quote.

1. POS inventory system. Shopify, on real-time stock visibility across channels, warehouses and retail locations.

1. Meet Google Play's target API level requirement. Android Developers, last updated 15 July 2026, on the 31 August 2026 requirement and the extension to 1 November 2026.

1. Upcoming SDK minimum requirements. Apple Developer, 3 February 2026, on the 28 April 2026 iOS 26 SDK floor.

1. Policy announcement: July 15, 2026. Play Console Help, on the target API deadline, app registration and the third-party AI clarification.

1. Policy Deadlines. Play Console Help, the dated table including the 28 October 2026 permissions deadlines.

1. Android developer verification. Android Developers, on verification from September 2026 and package-name registration.

1. Permissions and APIs that access sensitive information. Play Console Help, the permissions policy the October 2026 deadlines amend.

1. Announcing Web Search on Amazon Bedrock AgentCore. AWS News Blog, on managed grounding for the AI assistants retailers increasingly bolt onto commerce data.

1. Amazon Bedrock AgentCore pricing. AWS, consumption pricing for the agent infrastructure behind retail AI features.

Last updated: 3 August 2026.