Why ecommerce integrations fail

Most ecommerce integrations work on launch day. The test orders flow through, stock updates arrive, and everyone moves on. The problems appear weeks or months later: an order that never reached the warehouse, stock that drifts out of line, an invoice total a penny different from the website. By then, nobody is quite sure how the integration works or who should be looking at it.

Integrations rarely fail for one dramatic reason. They fail through a series of small assumptions that held during testing and did not hold in production. These are the failure modes we see most often, and what a well-built integration does about each of them.

No clear system of record

Every piece of data needs one system that owns it. If the ERP owns stock levels, the ecommerce platform should only ever receive stock, never send it back. If the ecommerce platform owns customer addresses, changes made in the ERP will be overwritten or ignored.

Trouble starts when this is never decided. Prices get edited in both the ERP and the store admin. Product descriptions are updated on the website and then replaced by the nightly product sync. Two systems each think they are authoritative, and the data ends up depending on which job ran last.

Before any code is written, list each data type – products, prices, stock, customers, orders, fulfilments, refunds – and name the system that owns it and the direction it flows.

Identifiers that do not line up

Integrations depend on matching records between systems, and this is where many of them break quietly.

• SKUs that differ slightly. The ERP stores AB-1001, the store has AB1001, and a variation has a trailing space nobody can see.
• One-to-many products. A bundle on the website is three separate lines in the ERP, or one ERP item is sold in packs of different sizes.
• Customers that do not exist yet. Shopify sends the order; the ERP rejects it because the customer account doesn’t exist yet, and the integration has no step to create it first.
• Reused or changed codes. A discontinued SKU is reassigned to a new product, and historical orders suddenly point at the wrong item.

A good integration keeps an explicit mapping between identifiers in each system rather than assuming they match, and treats an unmatched record as an error that someone needs to see.

Timing, volume and partial failure

Polling versus webhooks

Polling – asking a system every few minutes what has changed – is simple and predictable, but it introduces delay and can miss changes if the “changed since” logic is wrong or clocks differ. Webhooks are faster, but they are not a guarantee. Shopify, for example, documents that webhooks can be delivered more than once, may arrive out of order, and that delivery is not guaranteed, and it recommends running reconciliation jobs alongside them. In practice, most dependable integrations use webhooks for speed and a scheduled check to catch anything missed.

Rate limits

Every platform API limits how many requests you can make in a given period. An integration that works fine with twenty orders an hour can start failing during a sale, or when someone triggers a full catalogue resync. If the code does not read the rate limit responses, back off and try again, requests are simply lost.

Partial failures without retries

An order has five lines. Four are written to the ERP; the fifth fails because the product is inactive. Does the integration roll back, retry, or leave a four-line order in place? Networks drop, APIs time out and target systems go down for maintenance. Code that assumes every request succeeds will leave data half-written and never come back to it.

Stock race conditions

Stock is especially vulnerable. The website sells the last unit at the same moment a warehouse adjustment is being sent, and the later update overwrites the earlier one. Sending absolute stock figures from the system of record, rather than adding and subtracting in several places, avoids a lot of this. So does deciding in advance how much buffer stock the website shows for fast-moving lines.

The details that do not match

Some of the most persistent integration faults come from small differences in how systems handle the same data.

• Timezones. One system stores times in UTC, another in UK local time. Orders placed shortly after midnight during British Summer Time land on the wrong day in reports, and “changed since” queries skip records.
• Tax. The store calculates VAT on the order total; the ERP calculates it per line. Prices may be stored inclusive of VAT in one system and exclusive in the other.
• Rounding. Per-line rounding against whole-order rounding produces one-penny differences that stop invoices matching payments and confuse the accounts team.
• Discounts and shipping. A basket discount spread across lines one way on the website and another way in the ERP, or shipping treated as a product in one system and a separate charge in the other.

None of these is difficult to handle once identified. The problem is that they rarely show up in a test run of a handful of simple orders.

Connectors, silence and ownership

Off-the-shelf connectors that almost fit

A ready-made connector between your platform and your ERP can be a sensible choice, and for straightforward setups it often works well. The risk comes when your requirements are close to, but not quite, what the connector supports: a custom field it cannot map, a B2B pricing rule it ignores, an order type it does not recognise. Businesses then work around the gaps with manual steps and spreadsheets, and the connector becomes something nobody can change. Test a connector against your awkward cases, not the vendor’s demo.

Silent errors and no alerting

Many integration failures are only discovered when a customer phones to ask where their order is. Errors are written to a log file nobody reads, or caught and discarded in code. An integration that does not tell anyone when it fails will, sooner or later, fail without anyone noticing.

Nobody owns it after launch

The developer who built the integration moves on, the agency contract ends, or the internal champion leaves. Credentials expire, an API version is retired, a new product type is added. Integrations are not finished when they go live; they need an owner who knows how they work and is responsible for keeping them working.

What good looks like

A dependable integration is not necessarily a complicated one. It is built on a few principles applied consistently.

1. Idempotency. Processing the same message twice has the same effect as processing it once. If an order webhook arrives twice, one order is created, not two. This usually means recording each message or source identifier and checking it before acting.
2. Queues and retries. Incoming events are acknowledged quickly and placed on a queue, then processed separately. Failures are retried with increasing delays, and messages that keep failing are set aside for a person to look at rather than lost.
3. Reconciliation. A scheduled job compares the two systems – orders placed against orders received, stock on the website against stock in the ERP – and reports or corrects the differences.
4. Monitoring and alerting. Someone is told when error rates rise, when a queue stops moving or when no orders have synced for longer than expected. Alerts should go to a named person or team, not a shared inbox.
5. Documentation. A short, current description of what data moves where, which system owns it, how identifiers are mapped, how to replay a failed message and who to contact. It does not need to be long; it needs to exist.
6. Clear ownership. One person or team is responsible for the integration’s health, and knows it.

If an integration is causing repeated manual fixes, or you are planning a new one and want to avoid these problems from the start, an integration review is a sensible first step. We look at how data actually moves between your systems, where it goes wrong, and what would make it dependable, whether that means improving what you have or rebuilding part of it.