Интеграция с iiko связывает цифровой канал заказа с реальной работой ресторана. Проверяем не только загрузку меню, но и выбранную организацию, доступность блюд, обязательные модификаторы и подтверждение заказа. Доступные операции зависят от используемого продукта iiko, лицензии, прав и интерфейса.
Обследование ресторана и интерфейса
Уточняем продукт и версию iiko, организации, терминальные группы, точки и модель обслуживания. Для iikoCloud и иных интерфейсов отдельно проверяем актуальные методы и права. Сайт не должен направлять заказ в случайную точку только из-за общего каталога.
Определяем источник меню, времени работы и условий получения. Если в сети несколько ресторанов, согласуем правило выбора точки и различия ассортимента. Разработка нового приложения и интеграция действующего канала имеют разные границы проекта.
Меню, размеры и модификаторы
Сопоставляем блюда, группы, варианты и внешние идентификаторы. Проверяем обязательность и допустимое количество модификаторов по доступной модели меню. Цена выбранного размера или набора дополнений должна совпадать между интерфейсом заказа и ресторанной системой.
Не сводим меню к названию и картинке. Для пользователя важны состав, доступные варианты и возможность заказать корректную комбинацию. Изменение меню проверяем на уже открытой корзине: сервер должен повторно подтвердить допустимость заказа перед отправкой.
Стоп-листы и доступность
Подключаем доступные данные о недоступных позициях и согласуем частоту обновления. Уведомление о стоп-листе и фактическая доступность в момент создания заказа могут различаться по времени. Проверяем отказ и понятное предложение изменить корзину.
Для разных точек учитываем собственную доступность, не распространяя автоматически стоп-лист одного ресторана на всю сеть. При недоступности интерфейса заранее определяем поведение канала: ограничение заказа, ручное подтверждение или другой согласованный вариант.
Создание заказа и подтверждение обработки
Передаём согласованные позиции, модификаторы, контакты и условия получения в доступном составе. Отдельно сопоставляем тип обслуживания, способ оплаты и выбранную точку. Принятый HTTP-запрос не всегда равен принятому рестораном заказу.
Сохраняем внешний идентификатор и проверяем результат обработки доступным методом. При тайм-ауте сначала выясняем, не создан ли заказ, затем решаем вопрос повторной отправки. Иначе одно действие покупателя способно сформировать несколько заказов.
Статусы, оплата и исключения
Определяем, какие состояния получает канал и что они означают для клиента. Подтверждение оплаты в платёжном сервисе, создание ресторанного заказа и готовность блюда — разные события. Их согласуем в общей цепочке без подмены статусов.
Проверяем отмену и изменение в поддерживаемом объёме. Если действие требует участия сотрудника или ограничено интерфейсом, не обещаем автоматическое выполнение. Для ошибки показываем понятный статус пользователю и диагностическую информацию ответственному без раскрытия служебных данных.
Контрольный заказ и запуск
Испытываем разные точки, модификаторы, стоп-позицию, изменение цены, повтор и временный сбой. Сверяем состав заказа в канале и iiko вместе с сотрудником ресторана. Массовый запуск выполняется после проверки маршрутизации и подтверждения результата.
По итогам интеграции с iiko передаём карту данных, правила повторов и порядок обработки исключений. Доставка курьером, программа лояльности и разработка нового интерфейса включаются только как самостоятельные согласованные задачи, а не подразумеваются подключением API.
Вопросы по услуге
Подойдёт ли один обмен для всей сети ресторанов?
Можно использовать общую интеграцию, но организации, терминальные группы, меню и доступность необходимо сопоставить по точкам. Проверяем маршрутизацию каждого типа заказа. Общая база меню не означает одинаковые условия всех ресторанов.
Почему блюдо видно, но заказ не принимается?
Проверяем актуальность меню, стоп-лист, точку, обязательные модификаторы и условия заказа. Отображение в ранее загруженном каталоге не подтверждает текущую доступность. Ошибка должна возвращаться пользователю понятным способом.
Можно использовать готовую корзину сайта?
Да, после сопоставления её модели с меню и доступными операциями iiko. Особенно проверяем размеры, модификаторы и суммы. Иногда требуется доработать серверную проверку корзины, а не полностью переписывать сайт.
Что делать после тайм-аута создания заказа?
Не отправлять новый заказ вслепую. Проверяем состояние по сохранённым идентификаторам и доступным методам, затем применяем согласованный порядок повтора. Возможность такой проверки уточняется для конкретного интерфейса.
Входит ли оплата в подключение iiko?
Платёжный контур согласуем отдельно: провайдер, момент подтверждения и связь с ресторанным заказом. Успешная оплата не гарантирует успешное создание заказа. Интеграция должна корректно обработать расхождение этих состояний.