Start a project →
work/Backend · Integration

WooCommerce × Pantheon

A two-way middleware service that connects a WooCommerce store to the Pantheon ERP - orders, statuses, stock, prices and products all sync in both directions, and every sale runs through to a fiscalized, emailed invoice.

Role

Backend architecture + Integration build

Stack

NestJS · BullMQ · WooCommerce REST

Year

2026

architecture · two-way sync
SourceWooCommerce
order webhook→
Process 01Receiver
200 · enqueue→
BrokerRedis Queue
job→
Process 02Worker
stored procs→
ERPPantheon
└▶
ERPPantheon
status + JIR→
Process 02Worker
REST API→
ChannelWooCommerce
PDF · SMTP→
RecipientCustomer
2-wayOrders, status & catalog - both directions
0Manual re-keying between systems
0%Sales through to a fiscalized invoice
The challenge

What it needed to do.

The client sold through WooCommerce but ran the business in Pantheon ERP. Orders were copied over by hand, order statuses drifted apart between the shop and the ERP, and Croatian fiscalization happened - if at all - as a separate manual step.

They wanted the two systems to behave like one: a sale in WooCommerce should appear in Pantheon instantly, status changes should mirror both ways, and the customer should get a proper fiscalized invoice - all without anyone touching it.

Our approach

How we built it.

We built a two-way sync service on the same foundation as our forward-only Pantheon middleware - but bidirectional. WooCommerce webhooks push events in; a worker writes safely into Pantheon and pushes ERP changes back out through the WooCommerce REST API.

  • Orders in - a new WooCommerce order is captured via webhook and written into Pantheon through stored procedures, with the customer ensured first and ERP-owned document numbering.
  • Status both ways - order-status changes mirror in both directions: shop → ERP (paid, cancelled) and ERP → shop (confirmed, in progress, shipped, completed), kept consistent with idempotent updates.
  • Stock, price & products - both ways - stock levels, pricing and product records stay in sync in both directions, so the storefront and the ERP always agree, whether a change starts in WooCommerce or in Pantheon.
  • Croatian fiscalization - in-house ZKI/JIR generation, signed XML and QR codes via FINA, with a controlled demo → production certificate cutover.
  • Invoice to inbox - a headless-Chromium PDF invoice rendered and emailed to the customer over SMTP the moment the sale is fiscalized.
  • Resilient & idempotent - a durable job queue with retries and backoff, crash-safe state, dead-letter handling and auto-reconnect to both WooCommerce and the ERP.
Architecture

One service, two directions.

Events flow in from WooCommerce webhooks and out through the WooCommerce REST API. Orders, statuses, stock, prices and products all reconcile in both directions, and the same durable queue carries work each way - so neither system blocks the other.

Process 01

Webhook Receiver

Receives WooCommerce webhooks, validates and authenticates them, enqueues the work and returns 200 OK immediately - the shop never waits on the ERP.

Process 02

Sync Worker

Writes orders into Pantheon, mirrors statuses, syncs stock and price, fiscalizes, and emails the invoice - pushing ERP changes back to WooCommerce via REST, with retries at every step.

Connections - the WooCommerce REST API and the Pantheon ERP - auto-reconnect; local state, idempotency keys and the audit log live in PostgreSQL, with Redis as the broker.
What syncs

Everything that moves a sale.

New orderWooCommerce → PantheonOne-way
Order statusWooCommerce ⇄ PantheonTwo-way
Stock, price & productsWooCommerce ⇄ PantheonTwo-way
FiscalizationZKI / JIR · FINA
InvoicePDF → customer emailOne-way
The stack

Chosen for reliability.

Runtime / languageNode.js 20+ · TypeScript 5 (strict)
FrameworkNestJS 10
Job queueBullMQ + Redis
State storePostgreSQL + Prisma
Store APIWooCommerce REST + Webhooks
ERP accessMS SQL Server - direct TDS
Invoice PDFHeadless Chromium (Puppeteer)
EmailSMTP (nodemailer)
FiscalizationSigned XML · node-forge · QR codes
DeliveryDocker + Docker Compose
Status

Where it stands.

The full loop is built and integration-tested against a live Pantheon instance and a staging WooCommerce store: order in → customer ensure → ERP order → status mirror → fiscalization → PDF → email.

Containerized and observable; the production fiscalization-certificate cutover is documented as a runbook, ready for go-live.

integration-tested · live Pantheon + staging WooCommerce
  • ✓ order ingest (webhook)
  • ✓ customer ensure
  • ✓ ERP order & invoice
  • ✓ status mirrored both ways
  • ✓ stock, price & products sync
  • ✓ fiscalization (ZKI / JIR)
  • ✓ invoice PDF emailed
  • runbook production cert cutover
Next project

UKCA

→
OPEN FOR NEW PROJECTS

Have a project like this one?

Tell us what you're building. We'll come back within one business day with a clear plan, a timeline, and a real human to talk to.

Start a project →Back to all work →