Unified Commerce Architecture: Integrating Mobile Apps, Web Stores and 50+ POS Nodes

We inherited a retail integration where the web store, mobile app and 54 POS terminals all appeared to work. The failure was visible only in the stock ledger: a customer bought the last unit in one store, the mobile app still offered it, the web order reserved it, and the ERP received three different versions of the sale.

That was not a POS bug. It was an ownership problem disguised as an integration problem. Every system had a connector, but nobody owned the business event after it crossed the connector.

A unified commerce architecture fixes that by giving orders, inventory, customers and payments a controlled event path. The POS remains responsible for serving the store, the channels remain responsible for customer journeys, and a shared operational backbone governs what happened, when it happened and which system may change the record.

This guide covers the architecture we use to reason about that boundary: why point-to-point integrations collapse, how an event-driven retail platform should be shaped, what offline-first really requires, how to establish one stock truth, and how to roll out across 50 or more stores without stopping trade.

Why point-to-point integrations collapse at scale

Point-to-point integration fails at scale because each new channel multiplies dependencies, ownership and failure paths rather than adding one clean capability. With mobile, web, ERP and 50+ POS nodes, the problem is not the number of applications alone; it is the number of bilateral assumptions about inventory, order status, customer identity and payment completion.

We usually find the same pattern: a POS vendor exports sales to the ERP, the ERP publishes stock to the web store, the mobile app calls a separate inventory endpoint, and a middleware job reconciles exceptions overnight. Each connection works in isolation. The business process does not.

The hidden cost is coordination. A new click-and-collect flow might require a POS change, an ERP mapping, a web checkout change, a mobile release, a fulfilment rule and a support procedure. The feature is described as one project because the customer sees one journey. Technically, it is a chain of systems with no shared contract.

That is why a custom software development company should not begin with a list of APIs. The first design question is: which system owns each business fact? The second is: how does every other system learn about that fact without rewriting it?

Our position is direct: do not add another point-to-point connector to repair a point-to-point architecture. Create a business-event backbone, define ownership, and make every integration consume a durable contract. The common market answer is another integration layer with more mappings. That extends the failure surface while leaving the ownership gap intact.

Event-driven backbone: orders, inventory, customers

An event-driven retail platform should treat a sale, reservation, fulfilment update, refund and customer change as durable business events, not transient messages passed between screens. The event backbone becomes the coordination layer; it does not turn every application into a database or remove the need for clear system ownership.

We implement the backbone around three domains first: orders, inventory and customers. Payments and fulfilment attach to the order domain, while product and pricing data provide the inputs required to make a channel offer. This boundary keeps the architecture useful without pretending that every operational concern belongs in one central service.

Orders: one lifecycle, many views

The order service owns the commercial lifecycle: initiated, authorised, accepted, allocated, fulfilled, cancelled, returned and refunded. A POS can create an order. A web store can create an order. A mobile app can create an order. None of those channels should invent its own meaning for “complete”. They publish an order command or event and receive the canonical state through the order contract.

Every order needs a correlation ID that survives the customer journey, payment attempt, stock reservation, fulfilment action and refund. The ID must appear in POS logs, API traces, event records and support tooling. Without it, a failed order is a collection of plausible records rather than one explainable incident.

Inventory: movements before totals

Inventory should be modelled as a sequence of controlled movements, receipt, sale, reservation, transfer, adjustment, return and release, rather than as a number that several systems overwrite. A calculated available-to-sell value can be exposed to channels, but the underlying movements must remain auditable.

This is where serverless backend development and event infrastructure can fit a variable store network, provided the design preserves durable events, replay controls, observability and a clear recovery path. Serverless does not solve an unclear stock policy; it only changes where the code runs.

Customers: identity is a governed domain

Customer identity needs a canonical identifier and explicit merge rules. Email, phone number, loyalty number and device identity are attributes or matching signals, not interchangeable primary keys. A store associate must be able to find a customer without creating a duplicate record, while privacy and consent rules must remain visible to the systems that use the data.

We keep channel-specific preferences at the edge and customer identity in the governed customer domain. That prevents a mobile app release from silently changing the customer record used by returns or loyalty.

Our rule is simple: a channel may request a business action, but it may not silently redefine the business fact.

For teams expanding a broader product surface, the relevant capability is usually software development across product, application and modernisation work, not a collection of isolated integration tickets. The delivery team has to own the contracts, tests and operational handover together.

Related:AI-driven quality assurance and testing services, useful for building contract, regression and failure-recovery coverage across many connected channels.

Idempotency and offline-first POS realities

Idempotency means processing the same command or event more than once produces the same business result as processing it once. Offline-first POS means a store can continue defined operations during network loss and reconcile them safely later; it does not mean every transaction can be accepted without limits.

• Every command has an idempotency key. A sale, refund, reservation and stock adjustment must carry a stable key generated before retries begin.
• Every consumer records what it has processed. A message broker retry is normal. A second stock decrement caused by that retry is not.
• Every event has a version. Consumers must reject or route incompatible schemas rather than guessing how to interpret them.
• Every offline action has a policy. The business decides which tenders, discounts, returns and stock commitments are permitted without live validation.
• Every reconciliation has an operator path. Exceptions need a queue, evidence and an accountable owner; a dead-letter topic alone is not a process.

The practical POS design starts with a local transaction store. The terminal records the sale, payment result, tax details, device identity, operator identity and local sequence number. It prints or displays a customer result based on the local policy. When connectivity returns, the POS publishes the transaction with its original idempotency key and sequence metadata.

The central platform must distinguish three states that teams routinely collapse: accepted locally, received centrally and financially settled. A store can have accepted a sale while the central system has not received it. A payment terminal can report an approval while settlement remains pending. The user experience and reconciliation process need those distinctions.

We also set a monotonic sequence per POS node. If node 17 sends sequence 104 after sequence 106, the platform does not quietly process both as if ordering were irrelevant. It flags the gap, accepts only under a defined policy, and gives operations a traceable recovery action.

For mobile and web, idempotency protects checkout retries. A customer who taps “pay” twice should not create two orders because the first response timed out. The client sends one checkout key; the order service persists the key and outcome; retries return the stored outcome. This is more reliable than trying to infer duplicates from product lines and timestamps.

Offline-first is the wrong choice when the business cannot tolerate local acceptance under uncertainty. A tightly controlled financial workflow, a regulated product with mandatory live checks, or a high-value transaction requiring immediate central authorisation may need to fail closed. The architecture must reflect that obligation rather than promising uninterrupted trade as a universal benefit.

For a mobile-heavy operation, the same boundary applies to the application layer. Mobile app development for iOS and Android should include offline state, retry behaviour, consent handling and event observability in the product design, not treat them as post-launch integration details.

From offline sale to central reconciliation

1. Record locally — Store sale, payment, tax, device, operator and sequence details.
2. Apply offline policy — Display or print the customer result under local policy.
3. Reconnect and publish — Send the original idempotency key and sequence metadata.
4. Reconcile centrally — Recognise processed transactions; flag sequence gaps for policy-controlled recovery.

Single source of truth for stock across channels

A single source of truth for stock is not one database that every channel queries. It is one governed inventory ledger that records movements, applies reservation rules and publishes a consistent available-to-sell view to mobile, web, POS and fulfilment systems.

The distinction matters because a central database can still contain competing writes. If the ERP overwrites stock after a POS sale, while the web platform reserves stock independently, centralisation has created a larger place for inconsistency to hide.

We define inventory ownership by fact:

• Product master: owns item identity, units, variants and sellability rules.
• Location stock: owns on-hand movements for each store, warehouse or fulfilment node.
• Reservation: owns temporary commitments created by carts, orders or picking workflows.
• Available to sell: is a derived value calculated from on-hand, reservations, safety stock and channel policy.
• Adjustment: requires an actor, reason, location, timestamp and evidence.

POS and ERP integration becomes manageable when the integration carries movements and acknowledgements rather than repeatedly copying totals. A sale at store 23 creates a movement. The inventory service applies it, publishes the resulting availability, and the web and mobile channels update their offers. The ERP receives the same business event for financial and planning purposes, subject to its own posting rules.

Reservation policy is where many designs become dishonest. If ten customers can place the last item in their carts, the platform must define whether the cart reserves stock, whether the reservation expires, whether payment creates the commitment, and which channel wins when two reservations compete. There is no technical default that makes this decision for the operator.

A stock ledger also gives finance and operations an explanation for divergence. “The API returned zero” is not an explanation. “A transfer was dispatched from store 11, receipt was not confirmed, and the available-to-sell policy excludes in-transit units” is an operational fact.

Data quality remains a constraint. If 50 stores use different item codes, pack sizes or tax treatments, no event bus can make the resulting stock meaningful. The first delivery increment should include a master-data audit and a small number of representative nodes, not a promise to connect every SKU at once.

When customer-facing content and commerce logic are changing together, a headless CMS and content platform can keep channel presentation separate from stock and order authority. That separation prevents a campaign editor from becoming an accidental inventory administrator.

One stock truth: Govern the inventory ledger, rather than centralising competing stock writes.

• Record auditable movements instead of repeatedly copying totals.
• Define reservation rules before exposing availability.
• Publish consistent available-to-sell views across approved channels.

Rollout across 50 stores without stopping trading

The safe rollout pattern is parallel operation with bounded scope: establish the event contracts, connect a small store cohort, reconcile every movement against the incumbent system, and expand only when the exception queue is understood. A 50-store cutover is a governance event, not a deployment window.

The concrete symptom of a bad rollout is a store manager keeping a spreadsheet beside the POS. It usually appears after a “successful” launch: the new platform reports available stock, the old ERP reports another figure, and nobody trusts either one enough to process transfers or returns without a manual note.

We use a staged sequence:

1. Map the operational facts. Document order, payment, stock, customer, tax, return and fulfilment ownership. Record the current failure paths, not only the happy path.
2. Define contracts and identifiers. Agree event names, schemas, versions, correlation IDs, idempotency keys, node IDs and error states before connecting channels.
3. Build observability first. Provide event traces, lag dashboards, reconciliation reports and an operator queue before the first store goes live.
4. Choose a representative cohort. Include a high-volume store, a smaller store, a site with weak connectivity, a store with returns complexity and a node using each relevant POS configuration.
5. Run shadow reconciliation. Publish or calculate the new inventory and order views while the incumbent remains operational. Compare movements, not only end-of-day totals.
6. Enable one business capability at a time. Start with sales capture or stock visibility, not every omnichannel promise. Add reservations, click-and-collect, transfers and returns after the base event path is stable.
7. Expand by operational readiness. A store joins when its item master, device configuration, connectivity policy, training, support route and rollback procedure are verified.

The rollback plan must be specific. If the new reservation service is disabled, where do new reservations go? If central stock publication pauses, which channel offer is reduced? If a POS node is offline for a shift, how are sequences reconciled? A rollback that says “restore the previous version” does not answer those questions because the business state has already moved.

We also separate technical rollout from commercial rollout. A store may run the new event capture while click-and-collect remains disabled. A mobile app may consume the new available-to-sell feed while web checkout continues using the incumbent reservation path. This creates more temporary complexity, but it limits the number of unknowns in each release.

Team structure determines whether that complexity is owned or merely passed around. Renting headcount gives you people assigned to tickets. Buying delivered capability gives you a team with a tech lead, QA and DevOps ownership accountable for the event contracts, test evidence, deployment path and operational result.

For an APAC operator, the internal-hiring comparison has to include the calendar. A Singapore senior engineer’s base salary plus 17 percent CPF, roughly 20 percent recruiting fee, and a three-month ramp before the first shipped increment create a different delivery profile from a pod that already has engineering, QA and DevOps roles working against the roadmap.

This is where OmniStack’s model is relevant: our engineers are on our payroll and on the client roadmap, with developers, QA and UX working as a continuous team. The point is not to rent bodies. It is to keep delivery risk with the team accountable for the outcome rather than with the client’s hiring pipeline.

That model is wrong when the capability must be a permanent internal control function, when the organisation already has a mature engineering team with spare capacity, or when the work requires direct employment for legal, security or conflict-of-interest reasons. Hire in-house when the operator needs durable ownership of the domain and can support the hiring, management and continuity burden. Use a dedicated pod when the immediate constraint is a cross-functional delivery gap and the roadmap cannot wait for that pipeline.

Expand only when operations are ready

1. Map facts and define contracts — Name owners; agree schemas, identifiers, versions and error states.
2. Build observability first — Provide traces, lag dashboards, reconciliation reports and operator queues.
3. Select representative stores — Cover volume, weak connectivity, complex returns and POS configurations.
4. Run shadow reconciliation — Compare movements while the incumbent remains operational.
5. Enable capabilities incrementally — Start with sales capture or stock visibility; stabilise before expanding.
6. Expand by operational readiness — Verify data, devices, connectivity policy, training, support and rollback.

Accountability, regulated operations and the next architecture decision

Unified commerce architecture does not transfer accountability to a platform, broker or delivery partner. In regulated financial services, MAS TRM expectations in Singapore and APRA CPS 230 obligations in Australia make third-party governance, operational resilience, access control, incident management and accountability part of the architecture decision.

The code owner must be named. The operator remains accountable for the service, customer outcome, risk acceptance and regulatory obligations even when a delivery-owning pod builds or operates components. Contracts, runbooks, access reviews, evidence retention, incident escalation and exit plans need to reflect that reality.

For a fintech or digital bank extending a mobile and web experience across operational nodes, the design review should answer:

• Which entity approves changes to payment, customer identity and transaction-state logic?
• Which team can demonstrate the complete event trail for a transaction?
• Which controls prevent duplicate commands, unauthorised adjustments and replayed events?
• How are privileged access, secrets, production releases and emergency changes governed?
• What happens if the delivery partner is unavailable, and can the operator recover the service?
• Which service levels, testing evidence and incident records are required for the applicable MAS TRM or APRA CPS 230 control environment?

We do not recommend a single central “commerce API” that owns every decision. That becomes a bottleneck and a concentration of operational risk. The backbone should coordinate events and enforce shared contracts, while domain services retain clear authority. A payment service should not decide stock. A CMS should not decide refunds. A POS should not silently overwrite the enterprise customer record.

The architecture is also a poor fit for a small operator with one store, one channel and no meaningful integration complexity. Introducing an event backbone before there is a real coordination problem creates operational machinery without a business return. It is also the wrong first move when product identifiers, store processes and financial posting rules are not understood. Clean the facts before distributing them.

For a growing operator, the next decision is narrower than “should we modernise?” Draw the current order and stock flows for one web order, one mobile order, one in-store sale, one return and one offline transaction. Mark the owner of each fact, the retry boundary, the reconciliation owner and the regulatory evidence required. If those five flows cannot be traced end to end, do not connect the forty-sixth or fifty-first POS node yet.

Request an architecture drawing for your chain that shows the event backbone, domain ownership, POS offline boundary, ERP posting path, channel reads, reconciliation queues and rollout cohorts. The missing box on that drawing is usually the decision that will determine whether unified commerce becomes a reliable operating model or another collection of connectors.

event backbone readiness

• avoid event backbone — Coordination machinery lacks a business return
• create event backbone — Coordinate events while domains retain authority
• clean the facts — Clarify identifiers, processes and posting rules
• map operational facts — Trace ownership before connecting more nodes

Clean the facts before distributing them.

FAQ

What is unified commerce architecture?

Unified commerce architecture connects channels such as mobile apps, web stores and POS through shared business events, governed domain ownership and consistent operational data. It differs from a set of point-to-point integrations because orders, inventory and customer facts have defined owners and durable event histories.

Why use an event-driven retail platform for 50+ POS nodes?

An event-driven retail platform provides durable, traceable communication between stores, channels, ERP and fulfilment systems. It supports retries, replay, reconciliation and controlled expansion without requiring every new channel to integrate separately with every existing system.

How does offline-first POS prevent duplicate sales?

Offline-first POS uses local transaction storage, stable idempotency keys, node sequence numbers and central reconciliation. When connectivity returns, the central platform recognises a previously accepted transaction and does not apply the same sale or stock movement twice.

What is the right approach to POS ERP integration?

POS ERP integration should exchange governed business events and inventory movements rather than repeatedly overwriting stock totals. The POS owns local transaction capture, the inventory domain owns stock movements and availability, and the ERP receives the financial and planning records required by its processes.

Should a retailer hire an internal team or use a dedicated engineering pod?

Hire in-house when permanent domain ownership, internal control or long-term organisational capability is the priority and the business can support the hiring and management pipeline. Use a delivery-owning pod when the constraint is a cross-functional roadmap gap requiring engineering, QA, DevOps and continuity together.