Enterprise commerce projects get estimated as a storefront build with an integration line item. On every build I have been close to, the ratio was the other way around: the storefront was predictable, and the ERP integration was where the calendar went. If you are scoping a Spryker implementation against SAP — or Navision, or an AS/400 that predates the word "ecommerce" — treat the integration as the project and the storefront as the deliverable that falls out of it.

Decide who owns each field, in writing

Every integration problem I have debugged at two in the morning reduces to the same root cause: two systems both believed they owned a piece of data. Prices maintained in the ERP and "temporarily" overridden in the shop. Stock corrected in the warehouse system and cached optimistically in the storefront. A customer record edited on both sides of the fence in the same afternoon.

The fix is boring and organisational, not technical. Before any mapping work starts, produce a table: every entity, every field, one owning system, one direction of flow. Products flow from the ERP (or the PIM) to the shop, never back. Orders flow from the shop to the ERP, never back — the ERP sends order status, which is a different object. Anyone who wants an exception to the table has to argue for it in a meeting, which is exactly as hard as it should be.

Pricing is where B2B integrations earn their reputation

B2C pricing replication is a nightly file and a sanity check. B2B pricing against SAP means condition records — customer-specific prices, quantity scales, date-bounded agreements, sometimes thousands of combinations per account. You have two honest options:

  1. Replicate. Flatten the condition logic into Spryker's price dimensions and import the result. Fast storefront, and a re-implementation of SAP pricing that will drift from the original the first time someone adds a condition type nobody told you about.
  2. Ask SAP at cart time. Always correct, and now your cart's response time includes a round trip to a system that was sized for batch jobs, with a failure mode in the middle of checkout.

The pattern that has held up: replicate list and contract prices for browsing, and make one synchronous pricing call when the cart actually matters — on cart review, not on every quantity change. Cache the response against the cart hash. And decide now what the storefront shows when that call times out, because it will, and "spinner forever" is a decision too, just a bad one.

The order export is a distributed system, own up to it

Posting an order into an ERP is not a REST call, it is a small distributed systems problem wearing a business suit. The ERP will be down for maintenance windows the project plan never heard of. It will accept an order and time out on the acknowledgement. It will reject an IDoc for a reason that is true but useless, like a sales area mismatch on a customer who ordered fine last week.

Minimum viable honesty here is an outbox: the shop commits the order and an export job in one transaction, a worker retries with backoff, and every export carries an idempotency key so a retry after a lost acknowledgement does not book the revenue twice. I have seen the double-booked version. Finance finds it at month end, and they do not describe it as an engineering detail.

The test for any order export design: kill the connection after the ERP has accepted the order but before your system hears about it. If the answer involves a human comparing spreadsheets, the design is not done.

The middleware question

Somebody will propose an iPaaS — Mulesoft, Boomi, SAP's own integration suite — and somebody else will propose "just build it in the shop". Both are wrong as defaults. The iPaaS earns its licence when there are many systems and the mappings are genuinely configuration; it becomes an expensive place to hide business logic when there is really only one integration that matters. Direct integration is fine for one system and gets quadratically worse as systems join.

The question that actually decides it: who will change the mapping in three years, and what tools do they know? An integration layer nobody on the retained team can operate is technical debt with a subscription fee.

Whichever way it goes, put contract tests on the boundary. A fixture file of real (anonymised) IDocs and API payloads, replayed in CI against your mapping code. When the ERP team upgrades and a segment quietly changes meaning, you want a red build, not a warehouse full of wrong picks.

The storefront demo is what sells the project. The field-ownership table, the outbox, and the fixture suite are what let you sleep after it launches.