Гостевой заказ навынос и с доставкой

Настройте доступ

В настройках обслуживания заведения настройте публичный канал: опубликованный канал продаж, активного служебного пользователя, public handle и разрешённые origin. Настройте проверку контакта и политики исполнения. Этот flow использует гостевые токены черновика и управления, а не ключ партнёра.

Маршрут кабинета: /venues/:venueId/settings/fulfillment → Ресурсы → Публичный канал. Настройка публичного канала требует preorders.external.manage; правила исполнения — preorders.policies.manage.

fulfillmentOptions каталога перечисляет настроенные сейчас пары serviceMode/timingModes для заказа вне зала. Выбирайте PICKUP или DELIVERY только при наличии нужного ASAP или SCHEDULED. Для DELIVERY используйте отдельный список deliveryMethods. Пустой fulfillmentOptions означает отсутствие публичной политики заказа вне зала. Подсказки не резервируют вместимость и не обходят allowedOrigins канала, допустимость меню, зону доставки или проверку quote.

Виджет читает catalog/availability и создаёт draft при фактическом изолированном frame Origin и текущем x-hallify-widget-context. Proof связывает точные parent/connection/resource и не доказывает принадлежность draft/manage. Исходный повтор и приватное продолжение сохраняют нативные provenance и сроки без обязательного обновления proof. SDK использует те же canonical contracts без cookies или Origin override.

Первый успешный сценарий

Выполните шаги по порядку. Откройте каждый метод для точного тела, обязательных заголовков и схемы ответа.

Публичный каталог — ограниченное типизированное представление одного опубликованного меню для одного заведения Hallify и канала продаж. Используйте опубликованные варианты выбора, доступность, версию меню и непрозрачный токен графа. Окончательную цену и конфигурацию проверяет расчёт Hallify; публичные поля не раскрывают себестоимость, остатки и политики сотрудников. Браузерные запросы сохраняют фактический Origin и не передают доступ учётной записи. При входе через Storefront ordering сохраняйте точный locator connection/resource/venue/channel и передавайте connectionId в объявленном несекретном x-hallify-connection-id при выдаче черновика, в том числе на каноническом Origin Hallify. Он не заменяет allowedOrigins каталога или привязку представления, сохранённую в выданном черновике.

Выберите фактический нативный публичный канал. Если Storefront возвращает ordering, используйте ordering.publicChannelHandle вместо handle представления и сохраняйте все поля его scoped locator.
Прочитайте каталог и fulfillmentOptions; соберите корзину из допустимых позиций меню, вариантов, модификаторов и component selections. Сохраняйте точную версию меню, непрозрачный токен графа, валюту и часовой пояс заведения.
Выберите допустимый timing mode. Для SCHEDULED прочитайте ограниченную availability и передайте startsAt выбранного слота как scheduledFor. Для ASAP передайте timingMode: 'ASAP', полностью исключив scheduledFor; сервер определит обещанное время при создании quote.
Создайте черновик с Idempotency-Key. Сохраните draftReference, Bearer-токен черновика и исходный timing/presentation контекст. Для повтора используйте те же ключ и точное тело.
Подтвердите контакт через нативный draft flow. Проверьте одноразовый quote: зафиксированный scheduledFor, позиции, итоги, валюту, депозит и expiresAt. Явно примите именно этот quote до срока; документация не отправляет OTP или запрос принятия.
Обменяйте выданный одноразовый manage grant на Bearer-токен управления. Прочитайте исходный fulfillment, сохранённые timingMode, scheduledFor и allowed actions; исходное принятие/replay не ищет заменяющее время.
Если гостевая оплата включена и текущие полномочия допускают её, следуйте отдельному существующему checkout consent flow. Создание заказа само по себе не принимает финансовое согласие и не доказывает оплату.
Для разрешённого изменения получите расчёт поправки и примите его с ожидаемой ревизией; отменяйте заказ только в пределах гостевой политики.

Сохраняйте опубликованную конфигурацию вместе с приватным черновиком

Собирайте строку корзины из фактических menuItemId/menuVariantId каталога и применимых modifierOptionIds/componentSelections. Соблюдайте опубликованную структуру, обязательные группы, границы выбора, варианты и доступность; не создавайте вымышленные selectable IDs и цены. Сохраняйте стабильные clientLineId и quantity каждой строки. Публичные числовые selling prices нужны для показа; достоверные коммерческие суммы определяет нативный quote.

Create/update используют один ASAP-or-scheduled body union. Обновление заменяет допустимый выбор корзины, контакта и обслуживания и делает прежний quote недействительным; изменение защищённого контакта возобновляет проверку. Для восстановления исходного request и текущего quote читайте сохранённый черновик. Не подставляйте молча текущую версию меню, не пересобирайте ожидающий запрос после потери ответа и не переносите черновик в другое заведение/канал.

Токены черновика и управления остаются отдельными и приватными в соответствующем домене. Тела черновика/контакта и ответы с токенами не должны попадать в Redux, URL, cookies, логи и аналитику. Все примеры вымышлены и не выполняются документацией: они не отправляют заказ, OTP, платёж или запрос курьеру.

Выберите явный ASAP или сохраните плановый запрос

Плановый ввод использует PublicPreorderScheduledDraftBodyDto с точным scheduledFor и явным UTC-смещением. timingMode: 'SCHEDULED' необязателен: отсутствие сохраняет legacy scheduled body и исходный fingerprint запроса. Не вставляйте поле при повторе запроса, где его изначально не было. ASAP использует PublicPreorderAsapDraftBodyDto, требует timingMode: 'ASAP', поддерживает только PICKUP/DELIVERY и запрещает само свойство scheduledFor, включая null.

При создании quote ASAP запрашивает у сервера самое раннее нативно допустимое обещанное время в пределах 120 минут от расчёта. Учитываются нативные lead time, календари опубликованных пакетов, cutoff, ограничения зоны доставки и вместимость заведения. На момент расчёта нужен запас на планирование/проверку не менее пяти минут. Это ограниченный поиск, а не безусловное обещание доставки; сервер может не найти допустимое время.

Quote фиксирует обещание обслуживания вместе с поколением черновика, исходными request/policy hashes и безопасным сроком принятия. Показывайте возвращённые scheduledFor и expiresAt; запас не отсчитывается заново при получении ответа. Принятие и исходный replay используют ровно эти сведения и не ищут более поздний слот. При устаревшем или истёкшем quote требуется явная новая проверка/quote по текущим правилам вместо молчаливого переноса времени.

Явный timingMode сохраняется в draft request, quote, результате принятия и manage projection. У legacy scheduled записей поле может отсутствовать. Запросы сотрудников и контракты amendment сохраняют прежнее поведение; не добавляйте в них ASAP-поля. Вымышленные объекты ниже иллюстрируют только timing-фрагменты, а не полные запросы или реальные доступные слоты.

Примеры запросов

const asapTiming = {
  serviceMode: 'PICKUP',
  timingMode: 'ASAP',
};

const scheduledTiming = {
  serviceMode: 'DELIVERY',
  timingMode: 'SCHEDULED',
  scheduledFor: '2030-01-15T12:00:00+04:00',
};

Выберите время планового обслуживания

Запросите availability с публичным handle, serviceMode, partySize и границами from/to в RFC 3339 с явным смещением UTC. Поддерживаются плановые PICKUP, DELIVERY и CATERING; у заведения должна действовать политика выбранного режима. Браузер сохраняет фактический Origin. Для выбранного представления Storefront передайте его несекретный x-hallify-connection-id: актуальные connection и ресурс PREORDER проверяются точно, в том числе на основном Origin Hallify.

Окно не превышает семи суток и ограничивает начало слотов: from включается, to не включается. Конец слота может быть позже to. Ответ содержит часовой пояс и валюту заведения, а также полный хронологический список — не более 500 слотов. Слишком большой объём исходных данных или результатов вызывает ошибку вместо усечения; при необходимости сузьте окно.

Передайте startsAt выбранного слота как scheduledFor и сохраните тот же partySize в черновике. available отражает текущую общую вместимость для этой группы; чтение не создаёт hold или бронь. Перед принятием окончательный quote также проверит актуальную корзину, зону доставки и политику обслуживания. Если меню изменилось, заново загрузите каталог и пересоберите затронутые варианты с его текущей версией и непрозрачным токеном графа.

Получить ограниченный список слотов гостевого предзаказа

Откройте отдельный платёжный доступ для допустимого нативного заказа

Уполномоченный сотрудник должен явно включить allowGuestPayments в /venues/:venueId/settings/fulfillment → Ресурсы → Публичный канал; по умолчанию false. Также нужны допустимая merchant-привязка и текущие нативные Orders, доступные к оплате. Настройка не превращает черновик, quote или observer READ-grant в платёжные полномочия.

Для платёжного источника PREORDER_MANAGE используются точный UUID принятого нативного fulfillment и его текущий приватный manage-токен допустимого ASAP или планового заказа. Следуйте руководству guest-payments: откройте отдельный платёжный доступ, проверьте серверные сведения получателя и offer, затем явно примите неизменяемый manifest. Токен источника остаётся на исходном origin; при другом настроенном checkout origin нужен receiver-first handoff.

Прочитайте необязательный nullable manage.paymentActorReference для стабильного sourceContextKey приватного журнала preorder:<hint>. Непрозрачная SHA-256 ссылка в нижнем регистре выдаётся только для проверенной линии исходного публичного EXCHANGE/первоначального CREATE; сохраняйте её при SESSION exchange и ротации токена. Отсутствие/null или недоказуемая LEGACY-линия делают платёжный вход недоступным без fallback на fulfillmentId. Ссылка только разделяет UI-состояние: она не является токеном или финансовым разрешением; чтение manage не выдаёт доступ.

Команда предзаказа и платёжная команда имеют отдельные ключи, результаты и полномочия. При reload или UNKNOWN сохраняйте исходный платёжный сценарий и читайте его progress вместо создания другого intent. Отмена предзаказа не является публичной гостевой финансовой командой refund, void или capture.

Нативный платёжный допуск и согласие гостя

Выберите нативную доставку и сохраните исходный расчёт

Уполномоченный администратор настраивает подключения перевозчиков и версии секретов в /organizations/:organizationId/delivery-connections, затем способы доставки, политику сбора и привязки пункта выдачи в /venues/:venueId/settings/delivery. Соответствующие account API используют /organizations/{organizationId}/delivery-connections и /organizations/{organizationId}/venues/{venueId}/delivery/policy или /delivery/bindings. Это приватные API настройки вне гостевого SDK. Наличие маршрута или среды LIVE не доказывает активацию у перевозчика, доступность региона или успешную боевую доставку.

Каталог и доступность запланированного исполнения могут вернуть deliveryMethods со значениями SELF, UBER_DIRECT или WOLT_DRIVE. Выбирайте только возвращённый способ и передавайте deliveryMethod для DELIVERY. Отсутствие deliveryMethod сохраняет исходное поведение SELF; при неизменном повторе сохраните отсутствие поля. Другие serviceMode должны его опускать. Список предварительный: нативный расчёт повторно проверяет маршрутизацию, вместимость и правила. Wolt Drive требует настоящие latitude и longitude точки доставки; строка адреса не выполняет геокодирование, а фиктивные координаты не заменяют реальные.

Сохраняйте исходный draft, объявленный Idempotency-Key, точное тело и возвращённый deliveryQuoteId при проверке контакта и принятии расчёта. Клиентский delivery quote отличается от последующего staff dispatchQuoteId. Подготовка запроса перевозчику может вернуть PREORDER_DELIVERY_QUOTE_UNKNOWN или PREORDER_DELIVERY_QUOTE_NOT_READY до выпуска нативного расчёта. Таймаут или неопределённый результат требуют явного повтора исходного endpoint с неизменным запросом и capability; не создавайте заменяющий draft или расчёт с новым ключом. В прямом HTTP details конфликта могут содержать исходные preparation и delivery quote ID; в SDK используйте SdkError.apiCode и собственный сохранённый запрос, не предполагая наличие error.details.

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

Проекция delivery управляемого предзаказа может содержать method и tracking с нормализованным состоянием курьера, ETA получения/вручения и requiresAttention. Отсутствующий или null tracking не доказывает ошибку, отмену или оплату. Отмена курьера, неопределённый вызов и дальнейшее движение отделены от отмены еды, возвратов, депозита и действий исполнения заказа. Staff-расчёт, вызов, отмена, readback, локальное прерывание и их ограниченные истории остаются авторизованными операциями кабинета; гостевой SDK их не предоставляет.

Состояния, повторы и восстановление

Создание черновика не создаёт заказ. Изменение защищённых контактных данных запускает повторную проверку. Разделяйте токены черновика и управления. Использованный или истёкший grant не создаёт новую сессию; используйте восстановление доступа соответствующего гостевого flow.

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