Omnichannel Retail App Development

Building an omnichannel retail platform is primarily an inventory, order, and data consistency problem. When a customer places a click-and-collect order, the platform must atomically reserve stock from the correct store, route the order to that location's fulfilment queue, and update available inventory across all channels, all within the same transaction. When inventory moves in-store (sale, return, adjustment), that change must propagate to the e-commerce storefront, the marketplace listings, and the OMS within seconds, not minutes.

Scrums.com builds the unified inventory layers, order management systems, and channel integration infrastructure that retailers and D2C brands need to operate across physical and digital touchpoints without overselling, misrouting, or data inconsistency. Our teams work with retailers building their own platforms, and with retail software companies building omnichannel tooling for their customers.

Omnichannel Platform Architecture

The components most omnichannel builds underestimate are inventory consistency across write sources and order routing conflict prevention.

Unified Inventory Ledger

Inventory is modelled as a ledger of adjustment events (receipts, sales, returns, write-offs, transfers), not as a mutable stock count. The available-to-sell quantity is derived from the ledger in real time, so every channel reads from the same source of truth. Reservation events (checkout initiated, click-and-collect order placed) create a short-lived reserve that reduces ATP before the sale confirms, preventing oversells during concurrent checkout activity across channels. Reserve expiry is handled by a scheduled cleanup worker, not by the checkout flow itself.

Order Routing Engine

The routing engine assigns each order to a fulfilment node (DC, store, dropship supplier) based on configurable priority rules: stock availability, distance to customer, store capacity and pick queue depth, and margin contribution (factoring in split-shipment cost). Click-and-collect orders are routed to the elected store with an inventory reservation and a pick task created in that store's task queue. Ship-from-store orders are routed to the closest stocked location that meets a minimum capacity threshold, avoiding routing to stores already at queue capacity.

Customer Data Unification

Customer profiles are unified across in-store (POS transaction records), e-commerce (account orders), and app (session + purchase history) using a deterministic merge on email address + phone number, with probabilistic merge as a secondary pass for unmatched records. The unified profile drives loyalty point balance, cross-channel returns eligibility (online purchase returned in-store), and personalisation inputs; the profile is a view, not a single editable record, to avoid overwriting clean source data with merged errors.

Channel Integration Layer

Integrations with Shopify, BigCommerce, Magento, and custom storefronts are event-driven rather than polling-based: inventory changes publish to a message queue, channel adapters consume and push updates to each channel's API. Marketplace integrations (Amazon Seller Central, eBay Marketplace, Google Shopping) use platform-specific listing update APIs with retry logic and delivery confirmation; a failed update is retried with exponential backoff and surfaced as an alert if not resolved within a configurable SLA window.

Types of Omnichannel Platforms We Build

• Unified commerce platform (OMS + inventory). Single order management system across e-commerce, POS, marketplace, and phone channels; unified inventory ledger with channel-level ATP allocation; distributed fulfilment orchestration.
• D2C brand omnichannel stack. Headless Shopify or BigCommerce storefront, custom OMS for flexible fulfilment rules, Klaviyo/Attentive customer data sync, and in-store POS integration for a unified customer profile.
• Click-and-collect / BOPIS system. Store inventory reservation at checkout, pick task generation per store, store-side pick and confirm workflow, customer notification triggers, and same-day availability cut-off logic.
• Multi-seller marketplace with omnichannel fulfilment. Per-seller inventory management, order routing to seller warehouse or brand retail network, seller SLA monitoring, and consolidated customer-facing tracking.
• Retail ERP and e-commerce integration. Bidirectional sync between SAP Retail/SAP S/4HANA/Microsoft Dynamics and Shopify or Magento; product catalogue, pricing, inventory, and order data flowing in both directions with conflict resolution and error alerting.

Scrums.com's mobile app development teams build across the full range of omnichannel retail platform types. Start a conversation about your omnichannel retail platform build.

Technology Stack for Omnichannel Retail Platforms

• OMS and inventory engine. Java Spring Boot or Node.js (TypeScript) API; inventory ledger in PostgreSQL (append-only events); Redis for ATP caching with short TTL to reduce ledger reads under high concurrent checkout load
• Event streaming. Apache Kafka for inventory change events (sale, return, adjustment, transfer) consumed by channel adapters; event sourcing pattern for full inventory audit trail and point-in-time replay
• Channel integrations. Shopify Admin API + Webhooks; BigCommerce Management API; Magento REST API; Amazon SP-API (Selling Partner); eBay Trading/Inventory API; Google Content API for Shopping
• POS integration. Lightspeed Retail API, Square for Retail API, Shopify POS, custom EPOS via OPOS/UnifiedPOS driver layer; real-time transaction streaming to the inventory ledger
• ERP integration. SAP IDoc/BAPI (RFC), SAP S/4HANA REST OData, Microsoft Dynamics 365 Commerce API, Oracle Retail REST; dbt for data normalisation across ERP schemas
• Search and discovery. Elasticsearch or Algolia for product search with real-time inventory availability filtering; personalisation layer consuming unified customer profile for ranking signals
• Infrastructure. AWS or Azure; microservices with separate scaling for OMS, inventory, and channel adapters; Kubernetes for container orchestration; CloudFront/Akamai CDN for storefront assets

Regulatory Compliance for Omnichannel Retail Platforms

PCI-DSS: Payment Data Across Channels

Payment card data must never flow through or be stored in the OMS. The integration pattern uses tokenisation: payment is captured via Stripe Elements, Adyen Drop-in, or equivalent at the channel (storefront, app, POS), and the OMS receives only the payment token and authorisation status. Split-shipment orders that require partial captures require coordination between the OMS order state and the payment gateway's capture flow; partial capture is triggered by the OMS fulfilment event, not by a separate manual step.

GDPR and CCPA: Customer Data Platform

A unified customer profile aggregates data from multiple source systems. Under GDPR, the consolidated profile must be tied to a documented lawful basis per data category, and deletion requests must cascade to all source systems. The deduplication process must not create ghost profiles that survive a deletion request by being present in an unmerged source. CCPA Do Not Sell/Share flags must propagate to all channel systems and suppress personalisation processing for flagged profiles.

Consumer Rights: Returns and Refunds

UK Consumer Rights Act (14-day return for distance selling), EU Consumer Rights Directive, and US state-level return policies must be enforced by the OMS; a return initiated online for an in-store purchase (or vice versa) must validate eligibility, generate the correct refund path (original payment method where required by law), and update inventory in the correct location. Return eligibility rules are stored as configuration, not hardcoded, so policy changes do not require code deployment.

Accessibility: WCAG 2.1 AA for Storefronts

Where Scrums.com builds or integrates the customer-facing storefront, the implementation targets WCAG 2.1 Level AA compliance, covering keyboard navigation, sufficient colour contrast, ARIA labelling for interactive elements, and screen reader compatibility for checkout flows. This is a legal requirement under the European Accessibility Act (from June 2025) and the UK Equality Act for retail websites serving those markets.

Omnichannel Retail App Development: Common Questions

How do you prevent overselling during peak traffic when multiple channels are writing to inventory simultaneously?

The inventory ledger model prevents overselling structurally: available-to-sell is derived from committed ledger entries, not from a mutable count that can be decremented by concurrent writes. Reservation events (checkout initiated) create a time-limited hold on ATP before the sale commits, so concurrent checkouts on the same SKU across different channels each see the reduced ATP including pending reservations. Database-level optimistic locking on the reservation write prevents two simultaneous reservations from each seeing the same available quantity.

How does order routing decide which fulfilment node to use for ship-from-store?

Routing rules are configured as a weighted priority matrix: stock availability at candidate locations, distance to the customer delivery address, current pick queue depth at each store, and split-shipment cost if no single location holds all items. The routing engine evaluates all candidate nodes in real time against live inventory and queue data, not against cached snapshots, so routing decisions reflect the current state of the fulfilment network. Rules are stored as configuration data editable by operations teams without code deployment.

Should we build on a headless commerce platform or build a custom OMS?

These are separate questions. A headless commerce platform (Shopify Plus headless, Commercetools, VTEX) handles the catalogue, pricing, cart, and storefront rendering layer. A custom OMS handles the fulfilment routing, unified inventory, and cross-channel order lifecycle. Most enterprise retailers use a commerce platform for the former and build or buy a separate OMS for the latter, because the built-in OMS in most commerce platforms lacks the routing flexibility needed for multi-node fulfilment. We typically integrate with the client's chosen commerce platform and build the OMS and inventory layer separately.

What is the typical build timeline?

A unified inventory and OMS with Shopify integration and basic click-and-collect takes 16-22 weeks. Adding ship-from-store routing and multi-location pick workflow extends this to 24-30 weeks. ERP integration (SAP, Dynamics) adds 6-10 weeks depending on the ERP's integration surface. The first sprint establishes the inventory ledger schema and event model; this is the foundation everything else builds on, so getting it right before the channel integration work starts is critical.

How does the engagement work?

Omnichannel retail projects run on a dedicated team model. A typical team is 4-5 engineers, a product lead, and a delivery lead. Most clients start with a 2-week discovery sprint that maps the inventory data model, fulfilment network topology, and channel integration surface before sprint work begins. Teams are available within 21 days of contract signature. See how we work on our teams page, or get in touch to scope your project.