Skip to main content

Order lifecycle

An order's path from pressing "Pay" to handoff at the kitchen. This is the platform's central scenario — where the storefront, payment (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.) meet.

The platform is the source of truth​

The order is created and stored with us in PostgreSQLTenantA logically isolated customer in a multi-tenant system. In Ghost Kitchen a tenant is a brand: its data is separated from others by `brand_id` and access rules.. After payment, the Node adapter pushes the order to the POSPOSPoint of Sale — a restaurant's cash-register system. Here it is Liefersoft: it receives orders from the platform, prints receipts and handles fiscal accounting. (Liefersoft) for preparation and TSE fiscalizationTSE fiscalizationGerman technical requirements (Technische Sicherheitseinrichtung) for cash registers: every sale is securely signed. Handled on the POS side (Liefersoft).. That is, the platform is the leading system and the POS is the follower. This gives full control over data and analytics and removes the dependency on the POS API's capabilities.

Flow (happy path)​

Order statuses​

Reliability​

The link to external services is the most fragile spot, so the adapter is designed to be fault-tolerant:

  • 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.. A redelivered Mollie webhookWebhookAn HTTP notification an external service (e.g. Mollie) sends to the platform on an event — for example, "payment paid". An alternative to constantly polling the API. or a retry does not create a second order/payment — the operation is recognized by a key.
  • Retries. If Liefersoft is unavailable, the adapter retries with a growing 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.. Orders that fail to reach the POS after all attempts go into a separate queue and raise an alert — an operator handles them manually, the order is not lost.
  • Money is already with us. Since payment happens before the push to the POS, a failure on the kitchen side does not lose a paid order — it can be re-sent or refunded via Mollie.

Open questions for the client / Liefersoft​

:::warning Needs clarification

  • Which exact Liefersoft is used and what are its APIs (order intake, statuses, stop-lists)?
  • Who changes the final statuses (delivered/handed off) and where — KDS, courier, operator?
  • Is integration with delivery providers (Uber Direct, Wolt Drive) needed, or is delivery in-house?
  • Mollie tier and who legally accepts the payment (platform or restaurant). :::