Оплата и оформление
ЮKassa: уведомление об оплате не меняет статус заказа
ЮKassa подтверждает оплату, а сайт не меняет заказ. Разберём путь серверного уведомления и то, что должно быть сохранено до ответа провайдеру.
Что происходит и с чего начать
После изменения состояния платежа ЮKassa может отправлять сайту настроенные уведомления. Их обработка не зависит от возврата покупателя на страницу магазина. Поэтому сначала проверьте, существует ли соответствующее событие, куда оно направлено и какой результат получил сервис. Если запрос не дошёл, ищут проблему маршрута и доступности. Если дошёл, но заказ не изменился, исследуют код и сохранённую связь. Одна надпись об успешном HTTP-ответе ещё не доказывает выполненное бизнес-действие внутри приложения.
Что можно проверить самостоятельно
- Сопоставьте платёж и заказ по сохранённому идентификатору, сумме и времени. Проверьте, что рассматривается нужная операция, а не другая попытка оплаты того же заказа.
- Уточните настроенный адрес уведомлений и сохраните результат конкретной доставки. После смены домена или защиты особенно важно проверить фактический доступ к этому адресу извне.
- Посмотрите журнал приложения за время события. Не создавайте новый платёж для проверки уже подтверждённого: сначала разберите доставку и обработку существующего результата.
Как понять результаты проверки
Обработчик проверяет подлинность и существенные параметры события предусмотренным интеграцией способом, затем надёжно сохраняет результат или задачу обработки. Он не должен доверять произвольному сообщению только потому, что в нём указан знакомый номер заказа. Также требуется защита от повторного применения: событие может быть доставлено ещё раз. Разработчик должен объяснить, где фиксируется принятие и как после сбоя определяется уже выполненная работа. Это важнее наличия самого маршрута, который просто возвращает успешный ответ на любой запрос.
Что проверяет разработчик
Для этой части понадобятся доступ к настройкам, журналам ошибок или коду. Её можно передать специалисту вместе с результатами предыдущих шагов.
- Проверьте регистрацию нужного события и адрес обработчика в используемой схеме подключения. Убедитесь, что адрес относится к рабочему сайту.
- Сопоставьте идентификатор платежа с запросом в серверном журнале. Если запрос не найден, проверьте DNS, TLS, защиту и маршрут.
- Если запрос дошёл, проверьте результат проверки подлинности, разбор события и сохранение статуса. Не считайте любой входящий JSON подтверждением оплаты.
На что обратить внимание
Обработчик может вернуть успешный HTTP-ответ до надёжного сохранения результата, после чего ошибка внутри приложения останется незаметной. Возможна и обратная ситуация: запись выполнена, но ответ не дошёл и уведомление повторяется.
Как исправляют причину
Организуйте проверку события и устойчивое принятие обработки. Связывайте платёж с заказом по сохранённому идентификатору, сверяйте существенные параметры и обеспечьте идемпотентность.
Как убедиться, что проблема решена
Проверьте уведомление для тестовой операции и его повтор. Один подтверждённый платёж должен один раз изменить бизнес-состояние, независимо от количества доставок.
Проверьте обычное подтверждение и повтор того же события на тестовой покупке. Заказ должен обновляться корректно, без дополнительных писем и резервов сверх предусмотренных правил. Затем проверьте ошибку обработки в контролируемом окружении: она должна быть заметна и допускать восстановление. Сверка старых зависших оплат проводится отдельно, чтобы успешная новая попытка не скрыла прежние незавершённые подтверждения.