Собственная инфраструктура заказов для ресторана

Исходная точка

Главная проблема ресторана с онлайн-заказами обычно не техническая, а экономическая: агрегаторы берут комиссию с каждого заказа, а данные клиента до ресторана не доходят. Her Mutfak хотел выйти из этого круга.

Решением стало использовать WooCommerce как ядро, а не писать систему заказов с нуля. Корзина, склад, статусы заказа, налоги и возвраты в WooCommerce давно зрелые. Написать нужно было то, чего ядро не знает: обеденные карты, кухонный экран, курьеров и сменный персонал.

Сайт разделили надвое. Меню и маркетинг — hermutfak.com — статический HTML; сторона заказов — siparis.hermutfak.com — работает на WordPress. Маркетинговые страницы не несут веса WordPress, а система заказов не подвергается риску при каждом изменении лендинга.

Оплата обеденными картами

В Турции значительная часть офисных сотрудников оплачивает обед картами Multinet, Sodexo или Setcard. Сайт заказа еды, который их не принимает, теряет существенную часть аудитории уже на шаге оплаты. В WooCommerce этих карт нет.

Поэтому для Multinet был написан собственный платёжный шлюз WooCommerce. Он расширяет класс WC_Payment_Gateway и управляет следующим процессом:

• Обеденная карта отображается на оформлении заказа как отдельный способ оплаты
• На сторону провайдера уходит запрос на инициацию транзакции, клиент перенаправляется на экран подтверждения
• При возврате факт оплаты подтверждается у провайдера — данным из браузера клиента доверять нельзя, статус запрашивается на стороне сервера
• При подтверждении заказ WooCommerce помечается оплаченным и попадает на кухню
• При ошибке или отмене заказ остаётся неоплаченным, клиент видит понятное сообщение

Критичны последние два пункта. Самая частая ошибка в платёжных интеграциях — прочитать параметры URL, на который провайдер вернул клиента, и считать заказ оплаченным. Этот адрес проходит через браузер клиента и может быть изменён. Правильное поведение — отдельный серверный запрос при возврате, чтобы узнать реальное состояние транзакции. Именно так и построен этот процесс.

Кухонная панель

Настоящая проблема начинается после оформления заказа. Административный список заказов WooCommerce спроектирован для склада интернет-магазина, а не для повара, который стоит у экрана с занятыми руками.

Поэтому была построена отдельная кухонная панель. Её решения родились из наблюдения за кухней:

• Только сегодня. По умолчанию панель показывает только заказы текущего дня. Вчерашние не засоряют экран.
• Время ожидания и цвет. На каждом заказе видно, сколько он ждёт, и карточка меняет цвет по мере роста ожидания. Персонал видит опоздание, не читая список.
• Метка «НОВЫЙ». Поступивший заказ отмечен явно, чтобы не потеряться в час пик.
• Обновление без мерцания. Панель регулярно обновляется, но в первой версии перерисовывала весь список и экран мерцал. Обновление переделали так, чтобы менялись только изменившиеся карточки.

Настоящая инженерная работа в такой панели — не в данных, а в том, чтобы экран оставался читаемым в загруженную смену.

Курьер и доставка

Когда заказ готов, он должен перейти в доставку. Webhook-интеграция передаёт заказ в курьерскую систему, когда статус заказа WooCommerce достигает нужной стадии.

Интеграция написана отдельным плагином ради поддерживаемости: при смене службы доставки или окончании договора отключается один плагин. Остальная система заказов не затрагивается.

Права персонала

Не всем, кто открывает панель, следует видеть одно и то же. Сотруднику на смене нужно управлять заказами; выручка за день, отчёты по продажам и вся база клиентов ему не нужны.

Поэтому настроен ролевой ограниченный доступ персонала на основе преднастроенных наборов прав. Пользователь в роли персонала ведёт поток заказов, а экраны выручки и отчётов для этих ролей скрыты. Так как это построено на собственной системе возможностей WordPress, добавление нового сотрудника сводится к назначению роли.

Скорость и мобильные

Подавляющее большинство заказов еды приходит с телефонов, часто через мобильный интернет. Производительность здесь — не косметика, а напрямую потерянные заказы.

• Формат изображений. Включена серверная генерация WebP при загрузке. Фотографии блюд — самый тяжёлый ресурс сайта; смена формата сама по себе даёт серьёзный выигрыш.
• Предзагрузка LCP. Первое крупное видимое изображение объявляется браузеру через preload, и он начинает загрузку, не дожидаясь обработки CSS.
• Сдвиг макета из-за логотипа. У логотипа в шапке не были заданы размеры, и контент прыгал при загрузке (Cumulative Layout Shift). Исправлено явными размерами.
• Живой индикатор «открыто/закрыто». Индикатор приёма заказов должен быть верным даже на странице из кэша. Поэтому он вынесен в отдельный компонент, который получает актуальные данные независимо от остальной страницы. Кэшированная страница со словом «открыто» при закрытом ресторане — одна из самых частых и самых раздражающих ошибок на подобных сайтах.

Результат

Her Mutfak принимает заказы через собственный домен, со своими способами оплаты и своими данными клиентов. Система работает в продакшене.

Переносимый вывод: при построении системы заказов для ресторана писать ПО с нуля почти всегда неверно. Верно — взять зрелое ядро (WooCommerce) и разработать только то, чего это ядро не знает: обеденные карты, кухонный экран, курьера, сменный персонал. Нагрузка на поддержку остаётся небольшой, и система растёт вместе с рестораном.