eCommerce Integration Architecture: Connecting Your Store to ERP, Inventory, and Fulfilment

The short answer

Most ecommerce projects are not hard because of the storefront. They are hard because the store has to agree with an ERP, a warehouse system, an accounting package, a payment processor and three marketplaces about what is true — and those systems all disagree by default.

Four decisions determine whether an ecommerce integration is stable or a permanent source of incidents:

1. Where is the source of truth for each data type? Inventory, price, product content, customer, order — each needs exactly one owner.

2. Synchronous or event-driven? Real-time calls fail when the other system does. Events survive outages but introduce lag.

3. How do you handle the systems that cannot be changed? Legacy ERPs with no API, nightly batch windows, flat-file exchanges.

4. What happens when they disagree? Because they will, and reconciliation is a designed feature or an unplanned incident.

The default that works for most mid-sized operations: event-driven sync with a defined source of truth per data type, an idempotent integration layer, and a reconciliation job that runs nightly and reports discrepancies rather than silently correcting them.

Across 180+ software products delivered at Akoode — including ecommerce platforms and the custom integration work behind them — the integration layer is consistently where the cost and the risk concentrate.

Why integration is where ecommerce projects actually fail

The storefront is a solved problem. Themes, checkout flows, payment gateways, product listings — mature, well-documented, and largely commoditised. A competent team ships one predictably.

Then it has to talk to everything else.

The ERP was implemented in 2011 and its API is a SOAP endpoint that returns a 200 status code with an error in the body. The warehouse system exports stock as a CSV to an SFTP server at 2am. The accounting package expects invoices in a format that predates the company's current product structure. Two marketplaces have their own inventory models and neither matches yours.

None of that appears in the project brief. It appears in month three, and it is the single widest source of estimate variance in ecommerce work — the 1.3× to 2.5× multiplier described in our software development cost analysis, and the reason we price every unknown integration as a separate discovery spike before quoting a total.

The pattern to recognise: a project that looks like a storefront build is usually an integration project with a storefront attached. Scope it that way and the estimate holds. Scope it as a storefront and you will be renegotiating.

The systems you are connecting

A typical mid-market ecommerce operation has six to twelve systems that must agree. Each owns something, wants something, and has opinions about timing.

The absent OMS is the most common structural gap. Without an order management system, order state gets spread across the storefront, the ERP and the WMS, with no system owning the answer to "where is this order right now." Every operational question then requires a human to check three places.

For operations above roughly 500 orders a day, an OMS — bought or built — usually pays for itself in support cost alone.

Four integration patterns, and when each is right

1. Point-to-point synchronous

Storefront calls ERP directly, waits for the response.

Right when: two systems, low volume, both reliable, and the data must be current to the second.

Fails when: the other system is slow or down — your checkout now fails because the ERP is doing month-end. Every point-to-point connection also means N systems require up to N(N-1)/2 connections, which is unmanageable past four systems.

Use for: real-time price checks, address validation, payment authorisation. Things that genuinely cannot be stale and where failing loudly is correct.

2. Event-driven with a message broker

Systems publish events; interested systems subscribe. Order placed, stock adjusted, price changed.

Right when: several systems, moderate to high volume, and eventual consistency is acceptable — which it is for most ecommerce data, more often than teams assume.

Trade-off: lag between event and processing, and you must design for out-of-order and duplicate delivery. Every consumer needs to be idempotent, which is a discipline rather than a feature.

Use for: order propagation, stock updates, customer record sync, marketplace listing updates. This is the default for most mid-market operations.

3. Batch file exchange

Scheduled export and import, usually CSV or fixed-width over SFTP.

Right when: the other system offers nothing else. Legacy ERPs, older WMS platforms, some 3PL providers.

Design carefully: file naming and sequencing, partial-file handling, what happens when a run is missed, and idempotency on reimport. A batch integration that cannot safely reprocess yesterday's file will eventually corrupt data.

Use for: systems you cannot change. Do not choose it when an API exists.

4. Middleware or integration platform

A dedicated layer between systems handling transformation, routing and retry.

Right when: more than four systems, or several with incompatible data models.

This is where most operations should end up structurally, whether the middleware is a purchased iPaaS or a custom service. See the section below on which to choose.

Choosing between them

The practical rule: synchronous for the few things that genuinely cannot be stale, events for everything else, batch only where forced, and middleware once you pass four systems.

Mixing patterns is normal and correct. What is not correct is choosing synchronous by default because it is conceptually simpler — that decision produces a system where any one dependency failing takes checkout down.

Inventory sync: the hardest problem

Every other integration issue is tractable. Inventory is genuinely hard, and it is where most operations lose money.

Why it is hard

Stock changes from multiple directions simultaneously. A customer buys online. A different customer buys the same unit on a marketplace. Someone returns one. The warehouse counts and finds three fewer than the system says. A purchase order arrives.

All of these can happen within the same second, in different systems, and the sync interval between them is measured in minutes.

Oversell — selling stock you do not have — is the visible failure. The invisible one is safety-stock buffering set so conservatively that you are sitting on unsellable inventory to avoid it.

The decisions that matter

One system owns physical stock. Usually the WMS or the ERP. Everything else holds a cached view and never writes authoritatively. Two systems both believing they own stock is the root cause of most oversell incidents.

Decide where allocation happens. Physical stock and available-to-sell are different numbers. Available = physical − allocated to unfulfilled orders − safety buffer. Whichever system computes that must see all channels, or it will compute it wrong.

Push, do not poll. Polling every fifteen minutes means a fifteen-minute oversell window. Event-driven stock updates close it to seconds. Where the source system cannot push, poll frequently on fast-moving SKUs and less often on the long tail rather than treating all SKUs identically.

Reserve at cart, not at checkout for high-demand items. It costs you some abandoned-cart inventory and it prevents the worst customer experience in ecommerce — a successful checkout followed by a cancellation email.

Set safety stock per SKU velocity, not globally. A fast-moving SKU with a three-minute sync lag needs a larger buffer than one selling twice a month. A single global buffer is either too conservative for the tail or too thin for the head.

Multi-channel is where it breaks

Selling on your own store plus two marketplaces means three systems each believe they can sell the same unit. Marketplace rate limits mean you cannot update all three instantly. Marketplace penalties for cancellation are severe.

The workable approach: allocate a channel-specific buffer for high-velocity SKUs rather than exposing the full pool everywhere. You will underutilise inventory slightly, and you will avoid the cancellation penalties that damage marketplace standing. That is usually the right trade.

Order flow: where state lives

An order passes through five or six systems. Each has an opinion about its status, and those opinions drift.

The single-owner principle

One system owns order state. Every other system holds a reference and reports events into it.

Without this, "is this order shipped" has three answers. Support checks all three. The customer receives whichever the agent found first.

Preferred owner: a dedicated OMS if you have one, the ERP if you do not, the storefront only for small operations. Whichever you choose, make it explicit and enforce that other systems report rather than decide.

Status vocabulary

Every system has its own status names. The storefront says processing, the ERP says released, the WMS says allocated, the carrier says in transit.

Define one canonical vocabulary and map every system into it. Write the mapping down. Without it, every dashboard, report and support script implements its own translation, and they will disagree — usually in the customer-facing one.

The states people forget

Partial fulfilment, partial refund, returned-then-resold, backordered, cancelled-after-picking, exchange. These break naive models that assume linear progression.

Design the state machine before writing the integration. Include the reverse paths. A model that only moves forward will need surgery the first week returns start arriving.

Idempotency

Webhooks retry. Batch files get reprocessed. Users double-click.

Every order operation must be idempotent — safe to apply twice with the same result. Use a client-supplied idempotency key on writes, and store processed event IDs so duplicates are recognised and discarded.

This is the single most common defect in ecommerce integrations. Duplicate orders, double refunds and double stock deductions almost always trace back to a non-idempotent handler.

Product data: the source of truth question

Product data has more competing owners than any other type, and the disagreements are usually organisational rather than technical.

The variant problem

This is the specific issue that derails product integrations.

ERPs typically model a variant as a distinct SKU — a flat list. Ecommerce platforms model a parent product with option axes. Translating between them is not a mapping; it is a structural transformation, and it is lossy in both directions.

Decide early which system defines the variant structure, and build the transformation deliberately with a documented rule for what happens when a variant exists in one and not the other. Discovering this in week ten is a rescope.

Pricing is the second trap

Promotional pricing, customer-specific pricing, quantity breaks, and channel-specific pricing can each be computed in the ERP or the storefront. If both compute, they will disagree, and the customer sees one price at listing and another at checkout.

Decide where price is computed, and let the other system display only. If the ERP owns pricing, the storefront must not apply its own promotion engine on top.

Customer and financial data

Identity resolution

The same person is a storefront account, an ERP customer record, a CRM contact and a marketplace buyer with an anonymised email. Matching them is a real problem, not a lookup.

Decisions to make: what constitutes a match — email, phone, address, or a combination — what happens on partial matches, and whether guest checkouts create records at all.

The practical answer for most operations: email as the primary key with normalisation (lowercase, strip plus-addressing), a manual merge tool for support, and an explicit rule for marketplace orders where you may never receive a real email address.

Financial integration

Accounting has period locks. Once a period closes, you cannot post to it. Integration must handle a refund arriving for an order in a closed period — the finance team has a rule for this, and it needs to be in the code rather than in someone's head.

Tax is computed somewhere specific. Storefront, ERP or a dedicated tax service. Only one, and it must be the one whose calculation appears on the invoice.

Payment reconciliation is a separate flow from order flow. Payments settle in batches, days later, with fees deducted. Matching settlements to orders is its own integration and it is routinely forgotten until finance asks why the bank balance does not match order revenue.

Multi-currency: store the amount, the currency, and the rate used, with a timestamp. Never store only the converted figure — someone will need to explain a historical number, and "we converted at the rate that day" is not an answer without the rate.

Middleware, iPaaS, or custom

Once you pass four systems, direct connections become unmanageable. The question is what sits in the middle.

Choose an iPaaS when your systems are mainstream, transformations are simple, volume is moderate, and you want speed. It is genuinely the right answer for many operations and building custom would be over-engineering.

Choose custom when you have a legacy system no connector supports, transformations involve real business logic, transaction volume makes per-transaction pricing painful, or the integration logic is itself a competitive advantage — which it is more often than people expect, particularly in inventory allocation.

The hybrid that usually wins: iPaaS for the standard connections and a small custom service for the two or three that are genuinely specific to you. Most operations do not need to choose one exclusively.

Watch the per-transaction pricing model. iPaaS costs that are trivial at 200 orders a day can be significant at 5,000. Model it at your projected volume, not your current one, before committing.

Failure modes and how to design against them

The downstream system is down. Your integration must queue and retry rather than fail the customer transaction. Anything not required to complete an order should be asynchronous.

Retry storms. A failing system that gets hammered by retries stays down longer. Use exponential backoff with jitter, and a circuit breaker that stops calling after repeated failures.

Duplicate delivery. Message brokers deliver at-least-once. Webhooks retry. Every handler must be idempotent — this is not optional.

Out-of-order events. A stock update from 10:00 arriving after one from 10:05 must not overwrite the newer value. Include a version or timestamp and discard stale updates.

Partial failure. An order that saved in the ERP but not the WMS is in an inconsistent state. Either use a saga with compensating actions, or make the operation idempotent and retry the whole thing until it completes.

Silent drift. The most dangerous, because nothing alerts. Stock counts drift 2 percent over a month; nobody notices until a stocktake. Run a nightly reconciliation job that compares counts across systems and reports discrepancies rather than silently correcting them. Auto-correction hides the underlying bug.

Schema change upstream. The ERP is upgraded and a field changes type. Validate incoming data against a schema and fail loudly rather than writing garbage.

Rate limits. Marketplaces and shipping carriers enforce them. Design for throttling from the start; discovering limits in production during peak season is a bad time.

What integration actually costs

Consistently underestimated because it is invisible in a feature list.

A typical mid-market ecommerce build with ERP, WMS, accounting, payments and two marketplaces runs 120 to 250 engineer-days of integration work alone — roughly $35,000 to $75,000 at Indian blended rates, before any storefront work.

That is frequently 40 to 60 percent of total project cost, and it is the portion most often missing from a cheap quote.

The single most valuable thing you can do before committing to a total: price each unknown integration as a separate three-to-five-day discovery spike. Output is a written assessment of the API, its reliability and its data model. It costs a fraction of one percent of the project and removes the largest source of variance from the estimate.

Broader cost context in our ecommerce development cost guide.

Migration: integrating a system already in production

Greenfield integration is comparatively easy. Adding integration to a running operation is harder, because you cannot stop selling.

Start read-only. Sync data one direction, compare against the existing process, and let it run for two weeks without acting on it. Discrepancies at this stage are cheap.

Shadow-write before cutting over. Write to the new path while the old one remains authoritative. Compare outputs. Only when they agree consistently do you switch.

Backfill deliberately. Historical orders, customers and products need to exist in the new system with consistent identifiers. Decide how far back — usually 12 to 24 months is sufficient — and reconcile after.

Keep a rollback path for the first month. The old integration should be switchable back on. This is the difference between a bad week and a bad quarter.

Do not migrate during peak. Obvious, routinely ignored under commercial pressure. Post-peak, when volume is lowest, is when this work should happen.

If you are inheriting an existing integration landscape from another vendor, the assessment in our architecture review guide applies directly — particularly enumerating every external consumer, since integrations are frequently undocumented.

The pre-build checklist

• Every system enumerated, with what it owns and what it needs

• Source of truth defined for stock, price, product content, order state, customer identity

• Integration pattern chosen per connection, with a stated reason

• Every unknown API assessed via a discovery spike before the total is quoted

• Idempotency strategy defined for every write operation

• Canonical order status vocabulary written down, with per-system mapping

• Order state machine designed including partial, reverse and exception paths

• Variant structure ownership decided, transformation rules documented

• Available-to-sell calculation defined, and which system computes it

• Safety stock strategy per SKU velocity, not global

• Marketplace rate limits identified and designed around

• Retry, backoff and circuit breaker policy defined

• Nightly reconciliation job specified — reports, does not auto-correct

• Payment settlement reconciliation treated as a separate flow

• Accounting period-lock behaviour agreed with finance

• Monitoring and alerting on integration lag and queue depth

• Rollback path for the first month after cutover

Seventeen items. Each is minutes at a whiteboard and weeks to retrofit.

Frequently asked questions

What is ecommerce integration architecture?

It is the design of how an online store exchanges data with the other systems in an operation — ERP, warehouse management, accounting, payment gateways, marketplaces and CRM. The core decisions are which system owns each data type, whether exchange is synchronous or event-driven, and how disagreements between systems are detected and resolved.

How do you integrate an ecommerce store with an ERP?

Establish the ERP as the source of truth for product master data, pricing and cost, with the storefront holding a cached view. Push orders to the ERP as events rather than synchronous calls so checkout does not fail when the ERP is unavailable, make every write idempotent, and run a nightly reconciliation that reports discrepancies rather than silently correcting them.

What is the hardest part of ecommerce integration?

Inventory synchronisation across multiple sales channels. Stock changes from several directions simultaneously while sync intervals are measured in minutes, which creates oversell windows. It requires one system owning physical stock, a clearly defined available-to-sell calculation, event-driven updates rather than polling, and per-channel buffers on high-velocity SKUs.

Should ecommerce integrations be real-time or batch?

Use synchronous real-time calls only for data that genuinely cannot be stale — price checks, address validation, payment authorisation. Use event-driven asynchronous exchange for order propagation, stock updates and customer sync, which covers most cases. Use batch file exchange only where a legacy system offers nothing else.

How much does ecommerce integration cost?

A single modern documented API integration runs 5 to 12 engineer-days; an undocumented legacy system can exceed 60. A typical mid-market build connecting ERP, warehouse, accounting, payments and two marketplaces requires 120 to 250 engineer-days of integration work — roughly $35,000 to $75,000 at Indian rates, often 40 to 60 percent of total project cost.

What is an OMS and do I need one?

An order management system owns order state across all channels and fulfilment paths. Without one, order status is spread across the storefront, ERP and warehouse system with no single authoritative answer. Above roughly 500 orders a day, an OMS usually pays for itself in reduced support cost alone.

How do you prevent overselling across multiple channels?

Designate one system as the owner of physical stock, define available-to-sell as physical minus allocated minus buffer computed by a system that sees all channels, push stock updates as events rather than polling, and allocate channel-specific buffers on high-velocity SKUs rather than exposing the full pool everywhere.

What is idempotency in ecommerce integration?

Idempotency means an operation can be safely applied more than once with the same result. It is essential because message brokers deliver at least once, webhooks retry, and users double-click. Non-idempotent handlers are the most common cause of duplicate orders, double refunds and double stock deductions.

Should I use an iPaaS or build custom integration?

Use an iPaaS when your systems are mainstream, transformations are simple and you want speed. Build custom when you have a legacy system no connector supports, transformations carry real business logic, volume makes per-transaction pricing expensive, or the integration logic is itself a competitive advantage. Many operations correctly use both.

How do you handle product variants between an ERP and an ecommerce platform?

ERPs typically model each variant as a distinct SKU in a flat list, while ecommerce platforms model a parent product with option axes. Translating between them is a structural transformation rather than a mapping, and it is lossy in both directions. Decide which system defines variant structure before building, and document what happens when a variant exists in one system and not the other.

What is reconciliation in ecommerce integration?

A scheduled job comparing key figures — stock counts, order totals, payment settlements — across systems and reporting discrepancies. It should report rather than auto-correct, because automatic correction hides the underlying defect. Without it, small drift accumulates silently until a stocktake or a finance query surfaces it.

How do you add integration to a live ecommerce operation?

Start read-only and compare against the existing process for two weeks without acting on the results. Then shadow-write to the new path while the old one remains authoritative, comparing outputs until they consistently agree. Backfill 12 to 24 months of history, keep a rollback path available for the first month, and never cut over during peak season.

Conclusion

The storefront is the visible part of an ecommerce project and the smaller half of the work. What determines whether the operation runs smoothly is whether six to twelve systems can agree about stock, price, orders and customers — and they will not agree by default.

Four decisions carry most of that: who owns each data type, whether exchange is synchronous or event-driven, how you handle systems you cannot change, and what happens when they disagree. Made deliberately, integration becomes infrastructure. Made by accident, it becomes the permanent source of every incident and every support ticket.

The question worth asking before any ecommerce build: for each of stock, price, product content, order state and customer identity — which single system is right when they conflict? If you cannot answer all five, that is the work to do before anything else.

How Akoode approaches this

We treat integration as the primary risk in ecommerce projects and scope it first, not last. Every unknown API becomes a paid discovery spike — three to five days, fixed price, producing a written assessment of the API, its reliability and its data model — before we quote a total. It costs a fraction of one percent of the project and removes the widest source of estimate variance in this kind of work.

Across 180+ software products delivered in 15+ industries, the ecommerce operations that ran smoothly shared three traits: one documented owner per data type, idempotent write handlers throughout, and a reconciliation job that reported rather than corrected. The ones that generated constant incidents were missing at least one.

We are rated 4.9 out of 5 from 110 Google reviews and 5.0 on GoodFirms.

If you are planning a build or fixing an integration landscape that already exists, book a call with me directly. Bring a list of the systems involved — that alone is usually enough to identify where the risk sits.

You can also read how we approach ecommerce development and the custom software work behind complex integrations, or post your requirement for a response within one business day.