Integrations

The external systems the Node adapter works with: payments (MollieMollieA European payment provider. Accepts payments (cards, iDEAL, Apple/Google Pay, etc.) and reports payment status via webhooks.) and the restaurant register (LiefersoftLiefersoftA restaurant POS / cash-register system (Germany) with TSE fiscal compliance. The platform pushes orders to it for preparation and fiscal accounting.). This is the most critical part — it needs fault tolerance and idempotencyIdempotencyThe property of an operation yielding the same result when repeated. Protects against duplicate orders/payments when a webhook is redelivered or a request is retried..

Mollie — accepting payments

Principles:

• Don't trust the webhook body. Mollie sends only an id — we fetch the real status ourselves via GET /payments/{id}.
• Idempotency. A handler keyed on provider_payment_id must not move the order to PAID twice.
• Amounts on the server. The adapter computes the total from items and modifiers; the client does not set the price.
• Refunds. Cancelling a paid order → a refund via the Mollie API, status REFUNDED.

:::note To clarify Who legally accepts the payment — the platform or the restaurant (this affects the Mollie contract and payout split). Whether a payout split per brand/kitchen is needed. :::

Liefersoft — pushing the order to the kitchen

The platform is the source of truthPlatformThe entire Ghost Kitchen system and the owning company. Sees all brands, restaurants, orders and cross-brand analytics.: after payment the adapter pushes the order to Liefersoft and listens for preparation statuses. TSE fiscalizationTSE fiscalizationGerman technical requirements (Technische Sicherheitseinrichtung) for cash registers: every sale is securely signed. Handled on the POS side (Liefersoft). stays on the POS side.

Principles:

• Queue + retries between "paid" and "accepted by kitchen"; exponential back-off.
• Dead-letter queueDead-letter queueA queue for messages/tasks that could not be processed after all retries. They are handled manually so that no order is lost when an integration fails. for orders that fail to leave after all attempts, plus an alert. A paid order is never lost.
• Data mapping between our menu model and the Liefersoft format (items, modifiers) — a separate transformation layer.
• Status reconciliation — who sets the final "delivered/handed off" and where.

:::warning The main open question There are two different products called Liefersoft on the market (the classic German POS liefersoft.de and the newer all-in-one liefersoft.lovable.app) — with different APIs and maturity. We need to pin down which one and get its API documentation (order creation, statuses, stop-lists, authentication). This determines the scope of the integration layer. :::

Delivery (open question)

If delivery is not by in-house couriers — integration with Uber Direct / Wolt Drive / Stuart is possible. Architecturally that's just another adapter following the same pattern (queue, retries, status webhooks). For the MVP — confirm whether it's needed.

Summary of open questions

Topic	Question
POS	Which Liefersoft and its API?
Payments	Who accepts the payment, is a split needed, Mollie tier?
Delivery	In-house couriers or an external provider?
Orders	Where are the final statuses changed?
Scale	How many brands/kitchens over 1–2 years, expected SLAs?