Keeping a B2B dealer portal honest against a live ERP

A national IT distributor runs its dealer channel through a Magento 2 B2B portal we build and operate. Thousands of resellers log in, see their own contract pricing, check live stock across warehouses and place orders that land straight in the company’s ERP. No re-keying, no spreadsheets, no “let me check with the branch”.

That last sentence is where most B2B eCommerce projects quietly fail. The storefront is the easy part. Keeping it honest against an ERP that was never designed to talk to a website is the job. This is what that job looks like in practice.

What “live” integration actually means

The portal talks to the ERP over its vendor-supplied API layer rather than nightly file drops. When a dealer looks at a product, the price they see is the price the ERP would quote them on the phone, including their tier and any contract overrides. When they check out, the order is created in the ERP in real time and the ERP’s order number comes back to the customer’s confirmation mail.

The upside is obvious: one source of truth. The cost is that every ERP hiccup is now a website incident. We have had the ERP’s API tier return 503s at the same time most nights, usually around a scheduled job on the finance side. Orders placed in that window must not be lost, so the integration layer queues them, keeps retrying, and reconciles when the API is back. We log every retry so that when a dealer says “I never got a confirmation”, we can tell them exactly what happened and when.

Stock drift is the real enemy

The ugliest problem in any ERP-backed store is a product that shows as out of stock when there are two hundred units in the warehouse. The cause is rarely one bug. In this case the ERP does not emit a stock event when units move between locations, and the sync module drops a quantity field under certain conditions, so the storefront’s view of free stock goes stale and stays stale.

We could not fix the ERP side, so we built a reconciliation sweep that runs every fifteen minutes, pulls the authoritative quantity for every part the storefront considers sellable, and corrects the website. It is not elegant. It is boring, logged, and it works. The lesson we keep relearning: with ERPs you design for drift, you do not hope it away.

Tax at checkout is not a detail

During one API outage the fallback path priced orders with zero VAT. Dealers paid 15% too little and finance had to chase the difference. The fix was a guard at checkout that refuses to complete an order with an impossible tax total, plus a native South African VAT rule that applies whether or not the ERP is reachable. It is the kind of thing nobody asks for in a scope document and everybody notices on an invoice.

Keeping the platform patched without breaking the integration

The integration module is version-sensitive. Every Magento security patch has to be tested against it before it goes near production, which is why this client has a full staging environment on its own database that we upgrade first, run the dealer login and order flow on, and only then promote. We have moved the production store through multiple Magento and PHP versions this way without a day of downtime.

What this looks like for you

Whether you run SYSPRO, Sage, Epicor or something older, the pattern is the same: live API where the ERP offers one, file-based exchange where it does not, a reconciliation loop either way, and guards at the money end. We have done both. If your resellers are still emailing orders to a sales desk, that is the project.