Вебхук ЮKassa сообщает магазину об изменении платёжного объекта. Его получение нужно связать с конкретным заказом и проверкой актуального состояния, прежде чем давать складу команду на отгрузку. Официальная документация проверена редакцией 12 октября 2026 года; это руководство по действующему механизму, а не новость о запуске.

Проверьте, куда приходит событие

Для уведомлений требуется HTTPS-адрес с портом 443 либо 8443 и TLS не ниже 1.2. Подтверждением получения служит HTTP 200. При другом ответе ЮKassa продолжает попытки доставки в течение 24 часов от события. В переданном объекте отражены данные на момент изменения статуса.

Составьте короткую схему: внешний адрес, приложение-получатель, журнал событий и процесс выдачи задания складу. У каждого звена должен быть ответственный. После переноса сайта на другой домен или смены сервера проверьте именно рабочий маршрут уведомления: доступность главной страницы ничего не говорит о нужном обработчике.

Сверьте событие с собственной покупкой

ЮKassa рекомендует проверять подлинность уведомления, например по текущему статусу объекта или адресу отправителя. Значение из входящего сообщения не следует автоматически считать окончательным подтверждением всех условий заказа.

В собственной проверке сопоставьте идентификатор платежа, магазин, сумму и заказ. Если связь не найдена, отправьте случай в очередь разбора, сохранив факт получения. Не подбирайте заказ по одному имени покупателя: в один день человек может оформить несколько покупок с одинаковой суммой.

Защитите складскую задачу от повторения

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

Учебный пример: магазин обработал оплату, а ответ обработчика потерялся в сети. Следующее сообщение относится к той же операции. Проверьте, что система находит прежний результат и не создаёт ещё один расходный документ. Исполнитель на складе должен видеть одну действующую задачу с понятной историей.

Проверьте восстановление после сбоя

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

Финальная проверка — сопоставить оплаченные заказы и реальные задания на исполнение. Для общего принципа сверки полезен разбор платёжных ссылок и заказов магазина. Здесь же принимайте интеграцию только после подтверждения, что повторное событие сохраняет один коммерческий результат.