Жизненный цикл заказа

Путь заказа от нажатия «Оплатить» до выдачи на кухне. Это центральный сценарий платформы — здесь встречаются витрина, оплата (MollieMollieЕвропейский платёжный провайдер. Принимает оплату (карты, iDEAL, Apple/Google Pay и др.) и присылает статус платежа через вебхуки.) и касса ресторана (LiefersoftLiefersoftPOS/кассовая система ресторана (Германия) с TSE-фискализацией. Платформа передаёт ей заказы для приготовления и фискального учёта.).

Источник правды — платформа

Заказ создаётся и хранится у нас в PostgreSQLТенантЛогически изолированный клиент в multi-tenant системе. В Ghost Kitchen тенант — это бренд: его данные отделены от других по `brand_id` и правам доступа.. После оплаты Node-адаптер передаёт заказ в POSPOSPoint of Sale — кассовая система ресторана. Здесь — Liefersoft: принимает заказы от платформы, печатает чеки, ведёт фискальный учёт. (Liefersoft) для приготовления и TSE-фискализацииTSE-фискализацияТехнические требования Германии (Technische Sicherheitseinrichtung) к кассам: каждая продажа защищённо подписывается. Обеспечивается на стороне POS (Liefersoft).. То есть платформа — ведущая система, POS — ведомая. Это даёт полный контроль над данными и аналитикой и убирает зависимость от возможностей POS API.

Поток (happy path)

Статусы заказа

Надёжность

Связь с внешними сервисами — самое хрупкое место, поэтому адаптер проектируется устойчивым к сбоям:

• ИдемпотентностьИдемпотентностьСвойство операции давать один и тот же результат при повторе. Защищает от дублей заказа/платежа при повторной доставке вебхука или ретрае.. Повторная доставка вебхукаWebhookHTTP-уведомление, которое внешний сервис (например, Mollie) шлёт платформе при событии — например, «платёж оплачен». Альтернатива постоянному опросу API. Mollie или ретрай не создаёт второй заказ/платёж — операция распознаётся по ключу.
• Повторные попытки. Если Liefersoft недоступен, адаптер повторяет отправку по нарастающей паузе.
• Dead-letter queueDead-letter queueОчередь для сообщений/задач, которые не удалось обработать после всех повторов. Их разбирают вручную, чтобы не потерять заказ при сбое интеграции.. Заказы, не ушедшие в POS после всех попыток, попадают в отдельную очередь и поднимают алерт — оператор разбирает вручную, заказ не теряется.
• Деньги уже у нас. Так как оплата проходит до передачи в POS, сбой на стороне кухни не приводит к потере оплаченного заказа — его можно до-отправить или вернуть деньги через Mollie.

Открытые вопросы к заказчику / Liefersoft

:::warning Требует уточнения

• Какой именно Liefersoft используется и какие у него API (приём заказа, статусы, стоп-листы)?
• Кто и где меняет финальные статусы (доставлен/выдан) — KDS, курьер, оператор?
• Нужна ли интеграция с провайдерами доставки (Uber Direct, Wolt Drive) или доставка своими силами?
• Тариф Mollie и кто юридически принимает платёж (платформа или ресторан). :::