Connecting a MERN ecommerce website with inventory and order management for a UAE business

Home / Case studies / MERN ecommerce inventory integration

Ecommerce inventory integration in the UAE is rarely a website problem. It is an operations problem that shows up on the website. This ecommerce inventory integration case study covers a project for a UAE retail business whose online store, stock records and fulfilment process ran in three places that did not speak to each other. Orders arrived on the website, stock lived in the inventory system, and someone in the office moved information between them by hand.

Custom MERN ecommerce development connected the two sides. Tomsher's Dubai-based team built the store as a custom ecommerce application on the MERN stack, MongoDB, Express.js, React and Node.js, then connected it to the client's existing inventory and order management system through documented APIs. The client is not named here, and all screenshots are anonymised.

Ecommerce inventory integration project summary

The challenge, disconnected stock and order information

Website inventory synchronisation did not exist at the start of this project, and everything downstream suffered for it. Five problems came out of the discovery sessions.

• Manual stock updates. Availability on the website was updated by hand from a spreadsheet export, usually once a day, so the store was working from yesterday's numbers.
• Overselling and cancellations. Products showed as available after they had sold out in the warehouse. Around 6% of monthly orders had to be cancelled or partly refunded because of stock that was not there.
• Re-typed orders. Every website order was entered again into the order management system, taking roughly four minutes per order and introducing address and quantity errors.
• No order visibility for customers or staff. Once an order left the website, its status lived in another system, so customer service answered "where is my order" by phoning the warehouse.
• Mismatched product records. The same product carried different codes on the website and in the inventory system, so no automated match was possible until the SKU mapping was fixed.

The cost was not only operational. Cancelled orders after payment are the fastest way to lose a repeat customer, and the team knew it.

What the business needed from the integration

Ecommerce order management integration had to meet five requirements, agreed in writing before development started.

• Accurate stock availability on the website, at variant level, close enough to real time that overselling stopped being routine.
• Automated order transfer, so a paid website order reached the order management system without anyone retyping it.
• Order status back on the website, so customers could see progress and staff could answer questions without calling the warehouse.
• Two-warehouse awareness, so availability reflected stock across both locations and orders were routed to the right one.
• Visible failures. When an integration call failed, someone had to know within minutes rather than discovering it at the end of the day.

Why MERN suited this custom ecommerce development project

Custom MERN ecommerce development in Dubai was chosen for this project because the integration work, not the storefront design, was the hard part. Each part of the MERN stack carried a specific role.

The practical reasons were control and fit. The team needed to model SKU mapping and variant-level stock exactly as the client's systems described them, run scheduled and event-driven synchronisation in the same application, and expose one set of APIs that the storefront, the staff dashboard and the inventory system all used. Using the MERN stack does not by itself make an application real-time, scalable or search-friendly, so those outcomes came from how the integration and the front end were built rather than from the technology choice alone.

Connecting the MERN website to inventory management

Ecommerce stock synchronisation was the first workstream, and it began with data rather than code.

• SKU and variant mapping. Every website product and variant was matched to its inventory code in a mapping collection in MongoDB. Around 240 records had no clean match and were resolved with the client before launch.
• One source of truth. The inventory system owns stock. The website never edits stock levels, it only reads them and reserves against them, which removes the argument about which number is correct.
• Update direction and frequency. Stock flows from the inventory system to the website on a 10-minute scheduled sync for the full catalogue, with an immediate refresh for any SKU touched by an order.
• Variant-level and multi-warehouse stock. Availability is stored per variant per warehouse, and the website shows a combined figure while the order routing logic knows which location holds the stock.
• Reservation at checkout. Stock is checked and reserved when an order is placed and released automatically if payment fails or the customer abandons, so one item cannot be sold twice in the same minute.
• Exception handling. Failed calls are queued and retried with backoff, and anything still failing after the retry window raises an alert and appears on the staff dashboard.

Where a client's stock and pricing sit inside an ERP rather than a standalone inventory system, the same pattern applies through our ecommerce ERP integration work, and our guide to planning an ecommerce ERP integration covers how to scope that.

Connecting checkout to order management

Automated order management removed the retyping. The order lifecycle now runs in six steps.

1. Order created. Checkout writes the order to MongoDB with items, variant codes, quantities, delivery address, emirate and payment status.
2. Validated before payment. Stock, price and delivery charges are re-checked server side, so nothing is confirmed on a stale page.
3. Payment confirmed. The gateway callback marks the order paid, and only paid orders are eligible for transfer.
4. Transferred to order management. A Node.js job posts the order to the order management system with the mapped inventory codes and the assigned warehouse, and records the reference it gets back.
5. Status returned. Confirmed, packed, dispatched and delivered statuses flow back to the website, with courier tracking attached where available, so customers see progress in their account.
6. Visible to staff. The React dashboard shows every order, its transfer state, its warehouse and any exception, so nobody has to open two systems to answer a question.

Handling operational exceptions

Ecommerce order processing automation is judged on the awkward cases, not the clean ones. These were specified as business rules before they were built.

UAE requirements delivered

Ecommerce development for the UAE market brings local requirements that have to be built in, not added later. This project delivered five.

• AED pricing with VAT handled correctly on the storefront, in the order record and on the invoice.
• Emirate-based delivery rules, with charges and expected delivery days set per emirate and reflected at checkout before payment.
• Local payment connection, with the client's existing UAE gateway integrated and the callback treated as the trigger for order transfer.
• Bilingual storefront, with English and Arabic content and right-to-left layouts tested on real devices.
• Warehouse routing across two locations, so orders are fulfilled from the site holding the stock rather than defaulting to one.

Testing and launch

Website inventory synchronisation and order transfer were tested as one system, because either one failing produces the same customer experience.

• Data consistency checks. Stock levels on the website were compared against the inventory system across the full catalogue, with discrepancies investigated rather than averaged away.
• Order path testing. 120 test orders covering single items, multiple items, multi-warehouse baskets, guest and account checkout, and both languages.
• Failure simulation. The inventory system and the payment gateway were both taken offline in staging to confirm queuing, retries, alerts and recovery without lost orders.
• Parallel running. For the first two weeks after launch, orders were reconciled daily between the two systems before the manual check was reduced to weekly.
• Staff training. The warehouse and customer service teams were trained on the dashboard and the exception queue before go-live.

Results of the ecommerce inventory and order integration

Ecommerce inventory integration results were measured against a baseline recorded before launch. The figures compare the 90 days before launch with the 90 days after.

Order volume and promotional activity were broadly comparable across the two periods. The remaining exceptions are mostly genuine stock issues that need a person to decide, which is the point of routing them to a dashboard rather than hiding them.

Discuss a similar ecommerce integration project

Ecommerce inventory integration and order management integration projects start with a scoping review rather than a proposal. Send us the systems you run today, roughly how many SKUs and orders you handle, and where your team is doing manual work. We will come back with what can be connected, what each side needs to expose, and the order we would build it in. For account-based and wholesale ordering, the same approach extends into B2B and B2C portal development, and the API layer is covered by our web application development team.