E-commerce integrations: connect your store, stock and accounts

An e-commerce integration is the link that moves orders, stock, prices, customers and payments between your online store and the systems that run the rest of the business: stock or order management, ERP, the warehouse or 3PL, couriers and the accounts package. There are three ways to build one: a ready-made app or connector, a middleware platform (often called iPaaS), or custom code against each system's API.

Start with the ready-made connector if one exists and your process is standard. Move to middleware when you have three or more systems to join or rules a connector cannot handle. Commission custom code only for the part that is truly unusual, and budget to maintain it.

Most integration projects that go wrong do so because nobody wrote down which system owns each piece of data and what should happen when something fails. The technology is rarely the hard part.

The short version

• Decide which system is the master for each type of data (stock, price, product, customer, order status) before you choose any tool.
• A native app is cheapest and quickest, middleware is the sensible middle for most growing retailers, and custom code is for the exceptions.
• Stock and order flows need to be close to real time, while accounts can usually post once a day in summary.
• Every integration needs monitoring, alerts and a named person who acts on them, because silent failures are the expensive ones.
• Scope the awkward cases first: bundles, part shipments, refunds, pre-orders, multiple warehouses and tax.

What needs connecting to what?

For a typical UK retailer the map looks like this. You may not have every box, and one product sometimes fills two of them.

If you sell on marketplaces as well, the stock system usually sits in the middle and the website becomes one channel among several. Our guide to multichannel e-commerce covers that setup.

Native app, middleware or custom build?

Native apps

Most major stock systems and accounts packages publish a connector for Shopify, BigCommerce and Adobe Commerce. They install in an afternoon and work well when your needs match what the vendor assumed. Test them with your real data before you commit: a product with variants, an order with a discount and a gift card, a part refund.

Middleware

iPaaS stands for integration platform as a service. In plain terms it is a hosted hub: each system plugs into the hub once, and you set rules for how data moves between them. Patchworks is a UK platform built for retail, and Celigo is widely used with NetSuite. The value is in what surrounds the connection: a log of every message, automatic retries, alerts when something fails, and the ability to swap one system without rebuilding the rest. We cover this in more depth on our iPaaS integrations page.

Custom builds

Sometimes custom is right. An older ERP with no modern API, pricing rules nobody else has, or a warehouse process built around your product can all justify it. When Notcutts moved to Magento, the platform had to work with their existing Mercatus and Epicor data and with Microsoft Dynamics, and that gave them real-time stock across their operational systems for the first time. No app store connector would have done that.

Custom code carries a running cost. APIs change: Shopify, for example, now treats its older REST Admin API as legacy and has required new public apps to use its GraphQL API since April 2025. Somebody has to keep up with changes like that for as long as the integration lives.

What breaks, and why

These are the failures we see most often when we are asked to rescue an integration.

• Two systems both think they own stock. Each overwrites the other and the figure drifts. One master, always.
• Product codes do not match. The SKU in the store has a trailing space, a different case or a variant suffix the ERP does not use. Orders then fail to import, often silently.
• Bundles and kits. The store sells one line, the warehouse needs three. If nothing breaks the bundle down, stock is wrong from the first order.
• Part shipments, cancellations and refunds. The happy path was tested. The order that was half shipped, then part refunded, was not.
• Rate limits at peak. Every platform limits how many API calls you can make. An integration that copes in June can queue for hours on Black Friday if it sends one call for each stock change.
• Tax and rounding. The store calculates VAT per line, the ERP per order, and the totals differ by a penny. Finance then has thousands of penny differences to reconcile.
• Nobody is watching. A connector stops at 2am, no alert fires, and you find out when a customer chases an order three days later.

The last one matters most. Snowdonia Cheese Company hit a serious error in their order management setup at peak season, and we put an emergency team on it and added safeguards afterwards. Safeguards are the part worth copying. For any integration that means alerts, a view of stuck orders, and a written plan for working by hand if a system is down.

How to scope an integration

1. List the data, not the systems. Products, prices, stock, customers, orders, shipments, refunds, payouts. For each one, write down the master system and which direction it flows.
2. Set how fresh each flow must be. Stock within minutes, orders within minutes, accounts daily. Real time everywhere costs more and is rarely needed.
3. Write out the exceptions. Bundles, pre-orders, back orders, part shipments, exchanges, gift cards, multiple warehouses, trade customers with their own prices. Each one is a decision.
4. Count the volumes. Orders a day on a normal day and at peak, number of products, how often prices change. This decides whether a connector will cope.
5. Decide what happens on failure. Who is alerted, how fast, what the retry rule is and what the team does by hand in the meantime.
6. Plan the test. Run real orders of every awkward type through a test environment, then run old and new side by side for a short period before switching.
7. Agree who maintains it. Named owner, support hours and a budget for changes when either system updates.

Common mistakes

• Choosing the tool first. A middleware subscription does not design your data flows for you.
• Integrating everything on day one. Stock and orders pay back at once. A customer sync to the ERP often never does.
• Posting every order to the accounts package. For most retailers a daily summary by payment method, tax rate and channel is cleaner and keeps the ledger usable. Ask your accountant before deciding.
• Replatforming and re-integrating at the same time without a plan. It can be done, but the integration work is often the longest task in a replatforming project and is the one most often left out of the quote.
• Integrating when a spreadsheet would do. At twenty orders a day, a person keying orders into the accounts package once a day is cheaper than any integration. Automate when the manual work costs more than the build and upkeep.

How we'd approach it

We begin with a half-day mapping session and produce a single page: every system, every data flow, its master and its timing. That page usually shows two or three flows that matter and several that can wait.

We then check for a native connector, test it with your awkward orders, and only recommend middleware or a custom build for the gaps. Where the stock system is the hub we most often implement Linnworks, and our integrations team builds and supports the rest. If the wider question is what all of this adds to the bill, our guide to what an e-commerce platform really costs covers it.

Questions we get asked

Want a second opinion on your own setup? Thirty minutes with a strategist, and you leave with a clear next step.