Integrations (ERP, PIM, WMS, payments)

The shop is one system. The business runs on five more: ERP for inventory and accounting, PIM for product data, WMS for fulfillment, payments for money, and the CRM for marketing. Most production incidents originate in the integration layer between them.

Systems we connect to

• ERP: SAP Business One, Microsoft Dynamics 365 Business Central, Pohoda, Money S5, Odoo, NetSuite
• PIM: Akeneo, Pimcore, Plytix, and in-house spreadsheets used in place of a PIM
• WMS / 3PL / fulfillment: Zásilkovna, Packeta, GLS, DPD, FedEx, in-house warehouse systems
• Payments: Stripe, GoPay, ComGate, PayU, Adyen, Mollie, plus the fraud-detection and recurring-billing layers on top
• CRM / marketing: HubSpot, Klaviyo, Mailchimp, Salesforce
• Analytics / data: BigQuery, Snowflake, Segment, GA4

How we build them

• Idempotent. Every webhook can fire twice without breaking, because real systems retry.
• Observable. Every cross-system call is logged with a correlation ID, so when an order doesn’t reach the WMS, the logs show where it stopped.
• Resilient. Dead-letter queues, exponential backoff, and manual replay tools mean the integration survives a third-party outage.
• Versioned contracts. The API contract is checked in, and a schema-breaking change from the vendor is caught at deploy time instead of in production.
• Tested, with contract tests against recorded responses and smoke tests against the sandbox on every deploy.

Where those rules come from

None of the above is theory. Each rule comes from an incident on a store we’ve worked on:

• A status sync stalled for weeks without ever failing: the ERP kept sending 300,000 statuses for orders that never existed in the shop, which exhausted the import tool’s error budget and silently truncated every run before the real data. Hence: error budgets are monitored, not just configured.
• A freshly deployed order sync overwrote fields that the marketplace connector owned, and a day’s shipments never reached the marketplaces. Since then, every synced column has exactly one declared owner, and the sync refuses to touch foreign rows.
• An ERP stored procedure threw SQL exceptions while returning “success”. We caught it by replaying 1,300 real orders against the integration before go-live, which is now the standard rehearsal for order-critical flows.
• A broken feed once tried to delete tens of thousands of products in one run. Delete thresholds with a circuit breaker have been part of every catalog sync we’ve built since.
• Payments stopped matching orders because the hosting provider’s firewall was rate-limiting the payment gateway’s webhooks. The fix was a whitelist; finding it meant reading HTTP logs nobody else had looked at.

B2B commerce

Selling to companies changes the shape of the ordering problem. The buyer is someone’s employee, the price comes out of a contract, and the order usually passes through an approval chain. We build that layer too: company accounts with roles and hierarchies, customer-specific catalogs and contract pricing, quote-to-order workflows, payment terms (net 30/60/90, credit limits, ERP invoicing), and procurement integration, meaning punchout (OCI, cXML, Ariba) and EDI for customers that still send 850s.

How an engagement usually starts

Integration work is scoped from the failure you can already see: the order that never reached the WMS, the stock number that drifts every night, the CSV someone re-keys by hand each morning. We map that flow end to end, put the scope and a fixed price in writing, and build the replacement so the next failure shows up in monitoring immediately instead of days later. Ongoing operation, monitoring included, can stay with us on a monthly retainer.