Интеграции

Внешние системы, с которыми работает Node-адаптер: оплата (MollieMollieЕвропейский платёжный провайдер. Принимает оплату (карты, iDEAL, Apple/Google Pay и др.) и присылает статус платежа через вебхуки.) и касса ресторана (LiefersoftLiefersoftPOS/кассовая система ресторана (Германия) с TSE-фискализацией. Платформа передаёт ей заказы для приготовления и фискального учёта.). Это самая ответственная часть — здесь нужны устойчивость к сбоям и идемпотентностьИдемпотентностьСвойство операции давать один и тот же результат при повторе. Защищает от дублей заказа/платежа при повторной доставке вебхука или ретрае..

Mollie — приём оплаты

Принципы:

• Не доверяем телу вебхука. Mollie присылает только id — реальный статус запрашиваем сами через GET /payments/{id}.
• Идемпотентность. Обработчик по provider_payment_id не должен дважды переводить заказ в PAID.
• Суммы — на сервере. Адаптер считает итог из позиций и модификаторов, клиент не задаёт цену.
• Возвраты. Отмена оплаченного заказа → refund через Mollie API, статус REFUNDED.

:::note Уточнить Кто юридически принимает платёж — платформа или ресторан (это влияет на договор Mollie и сплит выплат). Нужен ли сплит-пейаут по брендам/кухням. :::

Liefersoft — передача заказа на кухню

Платформа — источник правдыПлатформаВся система Ghost Kitchen целиком и компания-владелец. Видит все бренды, рестораны, заказы и сквозную аналитику.: после оплаты адаптер пушит заказ в Liefersoft и слушает статусы приготовления. TSE-фискализацияTSE-фискализацияТехнические требования Германии (Technische Sicherheitseinrichtung) к кассам: каждая продажа защищённо подписывается. Обеспечивается на стороне POS (Liefersoft). остаётся на стороне POS.

Принципы:

• Очередь + ретраи между «оплачено» и «принято кухней»; экспоненциальная пауза.
• Dead-letter queueDead-letter queueОчередь для сообщений/задач, которые не удалось обработать после всех повторов. Их разбирают вручную, чтобы не потерять заказ при сбое интеграции. для заказов, не ушедших после всех попыток, + алерт. Оплаченный заказ не теряется.
• Маппинг данных между нашей моделью меню и форматом Liefersoft (позиции, модификаторы) — отдельный слой преобразования.
• Сверка статусов — кто и где ставит финальный «доставлен/выдан».

:::warning Главный открытый вопрос На рынке два разных продукта под именем Liefersoft (классический немецкий POS liefersoft.de и новый all-in-one liefersoft.lovable.app) — с разными API и зрелостью. Нужно зафиксировать, какой именно, и получить документацию его API (создание заказа, статусы, стоп-листы, аутентификация). Это определяет объём слоя интеграции. :::

Доставка (под вопросом)

Если доставка не своими курьерами — возможна интеграция с Uber Direct / Wolt Drive / Stuart. Архитектурно это ещё один адаптер по той же схеме (очередь, ретраи, вебхуки статусов). В MVP — уточнить необходимость.

Сводка открытых вопросов

Тема	Вопрос
POS	Какой Liefersoft и его API?
Платежи	Кто принимает платёж, нужен ли сплит, тариф Mollie?
Доставка	Свои курьеры или внешний провайдер?
Заказы	Где меняются финальные статусы?
Масштаб	Сколько брендов/кухонь в горизонте 1–2 лет, ожидаемые SLA?