AploDelivery Partner API — портал разработчика · v2 (2026-10-16)

Checkout (купон, бонусы, оплата)

Работает
Доступность (2026-10-03): POST /v1/checkout/calculate, payment в POST /v1/orders, списание бонусов (bonusToSpend — на кассе вторая строка оплаты «Вкускоин» VKUS2) и купоны (coupon — скидка правилом программы лояльности на уровне заказа) работают на проде. Скидка купона на кассе применяется на уровне всего заказа. В релизе от 04.10 исправлен coupon.status: применённый купон возвращает applied. Серверная логика сертификатов опубликована 15.10.2026; приём включён на Боброво (точка 3), реальные оплата и отмена проверены. См. алгоритм и API сертификатов.

Поток в двух шагах

  1. POST /v1/checkout/calculate — предпросмотр цены без побочных эффектов. Отдаёт
  2. POST /v1/orders с телом заказа + calculationId (+ payment, опционально

Подробности жизненного цикла удержания (какие статусы у купона/бонуса бывают, что происходит при таймауте) — в PARTNER_API_V2_SPEC.md §4.2/§4.3, пока не вынесены в отдельное руководство портала.

Как «Вкускоины» (бонусы) списываются на кассе

Списанный бонус вычитается из payment.amountMinor (цена заказа уже учитывает скидку), но сама по себе эта строчка ничего не говорит кассе о том, откуда взялась разница между ценой блюд и суммой оплаты — а значит, без отдельного шага чек на кассе не сойдётся.

Решение (2026-09-23): у ВиЛ на кассе уже есть тип оплаты «Вкускоин» (VKUS2), той же валютой ведётся списание бонусов ArgoCard. Поэтому списанный бонус приходит на кассу как отдельная, вторая строка оплаты с кодом VKUS2 (внешняя/обрабатываемая предоплата — тем же механизмом, что и обычная оплата картой онлайн ECARD), а не как скидка. Это техническая деталь интеграции с плагином кассы — партнёру для нормальной интеграции достаточно знать про payment.amountMinor (это то, что реально списывается с гостя через ЕГО способ оплаты) и что общая сумма заказа на кассе всегда сойдётся.

Как плата за доставку попадает на кассу

deliveryFee в ответе /v1/checkout/calculate и payment.amountMinor/total в заказе всегда уже включают плату за доставку по зоне — с этим проблем не было. Проблема была в том, что сам заказ, который сервис отправляет на кассу плагину, не содержал явной строки за доставку: итог заказа на кассе оказывался меньше суммы, которую реально заплатил гость, ровно на размер платы за доставку, и чек не сходился.

Решение (2026-09-23): заказ на кассу теперь дополнительно несёт строку deliveryFeeLine — обычную позицию каталога (товар из iiko с кодом DELIVERY_FEE_PRODUCT_ID, у ВиЛ это услуга «Доставка Приложение») по цене реально начисленной платы за доставку. Это техническая деталь интеграции с плагином кассы (см. plugin/WIRE_CONTRACT.md) — партнёру достаточно знать, что deliveryFee/total, которые уже отдаёт API, продолжают быть единственным источником правды для суммы, показываемой гостю; строка на кассе — это то, как сервис теперь гарантирует, что чек на кассе с ней совпадёт. Для самовывоза (deliveryType: "pickup") строки нет — платы за доставку там нет вовсе.

Модель доверия к номеру телефона гостя (предложено, ожидает подтверждения владельца)

⚠️ Этот раздел — предложенная формулировка, ещё не подтверждённая владельцем продукта. Он описывает то же правило, что уже зафиксировано для будущих GET /v1/guests/{phone}/... эндпоинтов (Безопасность → Модель доверия к гостю), но применительно к уже работающим checkout-эндпоинтам — а не к спецификации на будущее.

POST /v1/checkout/calculate и POST /v1/orders принимают guest.phone и используют его для обращения к AploCard (баланс бонусов, применимость купона, удержание суммы). AploDelivery доверяет присланному номеру телефона и не проверяет самостоятельно, что он принадлежит текущему пользователю партнёра. Партнёрский backend обязан аутентифицировать гостя (SMS-код, логин в своей системе и т. п.) до вызова checkout-эндпоинтов с его номером — иначе чужой баланс лояльности можно раскрыть или потратить, просто подставив чужой телефон в запрос.

Что уже есть на стороне AploDelivery как частичная защита (но НЕ замена аутентификации партнёром):

Формулировка требует явного решения владельца перед тем, как считаться нормативной частью контракта (а не просто наблюдением) — см. PARTNER_API_V2_SPEC.md §4/§5 и запись «Trust model» в отчёте фазы 3.

Связанное