Webshop × Pantheon

What this solves.

Trade runs on the webshop, the business runs in the Pantheon ERP - and the two are separate worlds. Orders are re-keyed by hand, statuses drift apart, stock and prices disagree, and Croatian fiscalization happens - if at all - as a separate manual step.

Nobody asked for this, because everyone assumes it cannot work any other way. We built a service that forces the two systems to behave as one: a sale shows up in Pantheon at once, status changes mirror both ways, the catalog stays aligned, and the customer gets a correct fiscalized invoice - without anyone touching it.

The core is platform-independent. The connector isn't.

The service stands on the same foundations as our one-way Pantheon middleware - only it runs both ways. Everything specific to a given store lives in a thin connector; everything beneath it - the job queue, ERP writes, fiscalization, PDF, email, audit trail - is shared and does not change from platform to platform.

The inbound flow works with any webshop. An order arrives either through a platform connector, or directly as our canonical JSON on the published endpoint. A store that can send an HTTP request can send orders - no connector, no waiting on us.

The return flow needs a per-platform connector. To push a status, a stock level or a price back into the store, we have to speak its API. So the connector is a tightly bounded interface with a handful of operations - fetch order, set status, update stock and price, upsert product. A new connector means implementing that interface, not building a new service.

WooCommerce is the first connector - REST API and webhooks, fully covered and integration-tested. The same shape applies to Shopify, Magento, PrestaShop or a custom store.

What the service does, on any platform.

• Orders in. An order is written into Pantheon through stored procedures - never a direct write into tables - after the customer is ensured, with document numbering staying owned by the ERP.
• Status both ways. Store → ERP (paid, cancelled) and ERP → store (confirmed, processing, shipped, completed), with idempotent transitions that create neither loops nor duplicate events.
• Stock, prices and products - both ways. Whether the change starts in the store or in Pantheon.
• Croatian fiscalization, built in-house. ZKI generation, digitally signed XML (XML-DSig), exchange with FINA's service, JIR and a QR code on the invoice. No intermediary, no third-party fiscalization service.
• Invoice in the inbox. A PDF rendered by headless Chromium and emailed to the customer over SMTP the moment the sale is fiscalized.
• Resilient & idempotent. A durable job queue with retries and exponential backoff, crash-safe state, dead-letter handling, and automatic reconnect to both the store and the ERP.
• Observable. Structured JSON logging with a correlation ID across the whole event lifecycle, health and readiness probes for every dependency, and a job-queue dashboard.
• Configurable business rules. Status mapping, warehouses, tax rates, discounts and invoice templates are per-environment configuration, not code changes.

One service, two directions.

Everything that drives a sale.

Three ways to connect.

• WooCommerce - a full connector, REST API and webhooks. Integration-tested.
• Any store, inbound flow - orders are posted as canonical JSON to our published endpoint, against the OpenAPI/Swagger spec. No connector needed.
• Other platforms, full two-way flow - Shopify, Magento, PrestaShop or a custom store, by implementing the same connector interface. The core stays untouched.

Least privilege, nothing in the clear.

• Signature verification on incoming webhooks and token authentication on the canonical endpoint; anything that fails the schema is rejected.
• No direct writes into ERP tables; a dedicated integration user instead of an admin account.
• Secrets, API keys and certificates come from the environment only - never in the repository or the image.
• Source-free delivery: the app is packaged into the image compiled to V8 bytecode, so readable source never reaches anyone else's infrastructure. Only the image ships.

Two ways to host it.

The service ships as a Docker image, so it runs the same anywhere - and the merchant picks where.

Chosen for reliability.

Middleware, not a one-off integration.

The service is built as a product, not as a bespoke build for a single merchant. The core, the Pantheon access layer and the fiscalization layer are generic; what differs from store to store - credentials, certificate, warehouses, status mapping, tax rates, invoice templates - is environment configuration.

For a store on a supported platform, onboarding comes down to configuration and a check on the test environment - not a new development cycle. For a new platform, a connector is added; everything else already exists and already runs in production.

Where it stands.

The project is in active development. The whole loop is built and integration-tested against a live Pantheon instance and a staging store: order in → customer ensure → ERP order → status mirroring → fiscalization → PDF → email.

Containerized and observable. The production fiscalization-certificate cutover is documented as a runbook - the same procedure already carried out on our one-way Pantheon middleware, which is in production.