A customer should not see one price online and a different price after the order reaches ERP. Map the records and rules behind that order first. This guide covers the checks needed to keep the storefront and back-office system in agreement.
B2B complexity often sits in account-specific catalogs, contract prices, terms, approvals, units, inventory availability, tax, fulfillment, and partial orders. Integrate these rules deliberately rather than treating the project as a connector installation.
Related service: CRM, ERP & Web Application development- 01Authorize the buyer and resolve the correct business account.
- 02Retrieve approved catalog, price, term, and availability data.
- 03Validate the cart against business rules before checkout.
- 04Create an idempotent order handoff and preserve the storefront reference.
- 05Let the ERP accept, reject, or split the order with an explicit response.
- 06Return fulfillment, invoice, and exception status to the storefront.
- 07Reconcile missed events and route unresolved records to operations.
SECTION 01
Map systems of record before choosing middleware
List customers, contacts, account relationships, products, variants, units, price lists, contract terms, inventory, carts, orders, allocations, shipments, invoices, returns, credits, and documents. For each, name the authoritative system and the party allowed to change it. Some fields can have separate owners; for example, the commerce platform may own merchandising copy while ERP owns item status and cost.
Also define freshness. An inventory number displayed to a buyer may be a calculated availability view rather than an accounting quantity. A contract price may be cached for performance but must carry an effective time and account context. Requirements should state the tolerated delay and what the interface shows when authoritative data is unavailable.
| Object | Typical owner | Direction | Failure response |
|---|---|---|---|
| Business accounts and credit status | ERP or CRM | To commerce | Hold checkout or use approved last-known state |
| Catalog presentation | Commerce | Local | Keep last published content |
| SKU, unit, tax class | ERP | To commerce | Quarantine invalid records |
| Contract price | ERP or pricing service | To commerce/request | Do not substitute retail pricing silently |
| Order | Commerce then ERP acceptance | To ERP with callback | Keep pending; do not create duplicates |
| Shipment and invoice status | ERP/fulfillment | To commerce | Reconcile and expose verified status only |
SECTION 02
Choose synchronous, event, and batch patterns by consequence
Use synchronous calls when the buyer needs an immediate decision, such as eligibility for a restricted product or final validation of a negotiated price. Use events or queues for work that can complete after the interaction, such as sending accepted orders, shipment updates, or account changes. Use batches for large catalogs, historical loads, and periodic reconciliation.
Shopify documents that webhook order is not guaranteed and deliveries can be missed or duplicated. That is a useful general design lesson: verify signatures, store event identifiers, make handlers idempotent, and run reconciliation jobs against update timestamps or checkpoints. A successful HTTP response does not prove the entire business transaction completed.
Synchronous
Immediate answer, strict timeout, visible fallback; avoid long ERP chains in checkout.
Event-driven
Decouple systems, acknowledge safely, process idempotently, and record state transitions.
Batch
Move volume efficiently with checkpoints, validation reports, and repeatable reruns.
Reconciliation
Compare authoritative state to integration state and repair gaps without duplicating work.
SECTION 03
Design for B2B rules and exception states
Resolve the authenticated person to a business account, locations, roles, buying permissions, approvers, price agreements, tax treatment, payment terms, and ship-to restrictions. The API must authorize access to each object; hiding a link in the interface is not access control.
Define what happens when the ERP rejects a line, changes a promise date, splits fulfillment, places an account on hold, or cannot allocate inventory. Buyers and operations need a shared status vocabulary. Avoid a single generic failed state that forces staff to reconstruct the transaction from logs.
SECTION 04
Limit payment and API exposure
Prefer a supported payment flow that minimizes the systems handling cardholder data, then confirm the applicable PCI DSS obligations with the payment provider, acquirer, and qualified advisors. Do not move payment data through ERP or integration logs merely because both systems can store arbitrary fields.
Use scoped credentials, rotate secrets, verify event signatures before parsing, encrypt transport, validate payloads, and restrict outbound destinations. OWASP's API guidance highlights object-level authorization because object identifiers alone do not prove that the caller may read or change a record. Log security-relevant actions without leaking secrets or sensitive payloads.
SECTION 05
Test recovery and operate the integration
Test duplicate orders, out-of-order events, stale prices, timeouts after ERP acceptance, unavailable dependencies, invalid units, partial fulfillment, cancellations during processing, rate limits, and replayed webhooks. Prove that rerunning a message does not create another commercial transaction.
Monitor queue age, failure rate, retry count, reconciliation differences, unacknowledged orders, and records in manual review. Provide operations with searchable correlation identifiers that connect the storefront, integration layer, and ERP. Document who can replay, correct, or cancel work and which actions require approval.
- 01
Trace one correlation ID across every system.
- 02
Reconcile orders, totals, inventory deltas, and statuses.
- 03
Alert on age and business impact, not only server errors.
- 04
Provide a safe replay or manual-continuation tool.
- 05
Review integration changes when either platform updates its API.
SECTION 06
Frequently asked questions
Should ERP or e-commerce own inventory?
The operational inventory source is often ERP or a dedicated inventory system, while commerce holds a buyer-facing availability view. Define the calculation, refresh target, reservations, and unavailable-state behavior explicitly.
Are webhooks enough for ERP synchronization?
No. Webhooks are useful triggers, but handlers need signature verification, duplicate protection, retries, monitoring, and periodic reconciliation because deliveries can be delayed, duplicated, missed, or processed out of order.
How do you prevent duplicate B2B orders?
Assign an idempotency or business transaction key, persist processing state, make retries return the original result, and reconcile ambiguous timeouts before creating another order.
Does ERP integration make an e-commerce site PCI compliant?
No. PCI DSS scope depends on the actual payment architecture and parties that store, process, transmit, or can affect payment data security. Confirm obligations with appropriate payment and compliance specialists.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- About Shopify webhooksShopify Developers
- Integrate Dynamics 365 apps with other systemsMicrosoft Learn
- Salesforce integration patternsSalesforce Developers
- OWASP API Security ProjectOWASP Foundation
- PCI Data Security StandardPCI Security Standards Council
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy