Чеклист перед запуском в проде

Пройдите этот список перед тем, как первый реальный заказ пойдёт через вашу интеграцию.

Ключи и подпись

API-ключ и HMAC-секрет получены отдельно для прод-окружения (не переиспользован секрет из тестового контура) и хранятся только в секретном хранилище backend — не в коде, не в клиенте. См. Безопасность.
Формула подписи реализована и сверена с тестовым вектором — оба примера (POST с телом и GET без тела) дают заявленные значения.
X-Timestamp берётся из системных часов backend, синхронизированных по NTP (допуск сервера — 60 секунд).
X-Request-ID — новый UUID на каждый HTTP-запрос, включая повторные попытки одного и того же заказа.
Секрет вебхука (webhookSecret) отличается от API-секрета и хранится отдельно.

externalOrderId генерируется и сохраняется на вашей стороне до первой отправки заказа, не заново при каждой попытке.
Ретраи POST /v1/orders при таймауте/5xx используют тот же externalOrderId и то же содержимое, но новый X-Request-ID.
409 idempotency_conflict обрабатывается как стоп-сигнал (не как «попробовать ещё раз»), см. Идемпотентность.

Список точек читается через GET /v1/points и active=false/точки вне ответа скрываются в UI, а не хардкодятся.
Перед показом блюда на сайте проверено, что оно есть в GET /v1/points/{id}/products — это устраняет заранее известный класс 422 product_mapping_not_found.
Адрес проверяется через POST /v1/addresses/check до оплаты, обработаны все четыре статуса (ok/ambiguous/not_found/unknown), включая то, что unknown не блокирует оформление.

Реализована обработка каждого кода из Справочника ошибок, не только 200/201.
413 (превышение размера тела) распознаётся отдельно — это не JSON-ответ.
Неизвестный статус/код не интерпретируется как успех.

Эндпоинт приёма вебхуков публично доступен по https://, проверяет подпись (ingressclient.VerifyWebhook или эквивалент) до разбора тела как доверенных данных.
Дедупликация по eventId реализована на уровне, предшествующем бизнес-эффекту (уникальный индекс или проверка «уже обработан»).
Обработчик отвечает 2xx быстро (тяжёлая работа — асинхронно), учитывая 5-секундный таймаут воркера на попытку.
Реализован резервный поллинг на случай, если вебхук так и не доставлен (после исчерпания ретраев запись помечается dead) — см. Вебхуки.

UI не блокируется ожиданием CookingStarted/CookingCompleted — текущие кассы ВиЛ (iiko Front API V8 8.7) их не присылают, см. Жизненный цикл заказа.
deliveryStatus, deliveryStatusAt, cancelReason, cancelDetail обрабатываются как поля, которые могут быть null, а не как опциональные ключи.
Русскоязычные подписи состояний в вашем UI взяты из таблиц Жизненного цикла заказа, а не придуманы заново — это упрощает будущую сверку с другими партнёрами на этом же API.

Кнопка/сценарий отмены на сайте отправляет валидный reason из фиксированного набора (guest_request/payment_failed/duplicate/other).
202 (запрос принят, но отмена не гарантирована) и 200 (немедленная отмена/no-op) различаются в UI, если это важно для вашего сценария.
409 cancel_rejected не приводит к автоматическому повтору — гостю показывается «свяжитесь с рестораном», см. Отмену заказа.

Ни в одном логе на вашей стороне нет API-ключа, HMAC-секрета, webhookSecret или заголовка X-Signature в открытом виде.
Номер телефона, имя и адрес гостя не пишутся в логи в открытом виде на вашей стороне (симметрично тому, что делает AploDelivery — см. Безопасность).
Если интеграция когда-либо перейдёт на guest/loyalty-эндпоинты (v2, планируется) — прочитана и понята модель доверия к гостю: AploDelivery доверяет присланному телефону, аутентификация гостя — обязанность партнёра.

Известен канал обращения в поддержку AploDelivery и что к обращению нужно приложить — см. Поддержку.
На вашей стороне логируется собственный X-Request-ID каждого исходящего запроса (сервис его пока не эхает в ответе) — это единственный способ найти конкретный запрос при разборе инцидента.

Пройден полный сценарий end-to-end на staging: точка → товары → адрес → создание заказа → получение вебхуков state/delivery-status → (опционально) отмена → сверка итогового состояния поллингом.
<уточняется>: отдельный sandbox с POS-симулятором (docs/PARTNER_API_V2_SPEC.md §9.4) пока не задеплоен — «staging» здесь означает реальный staging-контур AploDelivery с настоящим плагином на тестовой точке, а не автономный симулятор.