Оплата и оформление
CloudPayments: Pay-уведомление возвращает ошибку
Pay-уведомление CloudPayments получает ошибку. Покажем, как отличить блокировку запроса от отказа платёжного обработчика и проверить подтверждение результата.
Что происходит и с чего начать
Уведомление о платеже приходит на сервер сайта отдельно от действий браузера. Его могут отклонить ещё до платёжного кода: например, общая авторизация или защита формы. Поэтому первым делом нужно установить, дошёл ли запрос до нужного обработчика. Затем проверяют результат по контракту используемой интеграции. Обычная страница «ОК» или успешный сетевой статус не всегда являются правильным подтверждением для провайдера. Важны и формат ответа, и то, что приложение успело надёжно сохранить перед его отправкой.
Что можно проверить самостоятельно
- Найдите идентификатор операции и связанный заказ, запишите время. Сверьте состояние у провайдера, прежде чем вручную менять оплату или просить клиента повторить её.
- Сохраните код и безопасную часть ответа на уведомление. Уточните, менялся ли адрес обработчика, защита, авторизация или конфигурация прокси перед появлением отказов.
- Проверьте наличие записи в журнале приложения. Если запроса там нет, сообщите это специалисту вместе с результатом доставки, чтобы искать блокировку до платёжного кода.
Как понять результаты проверки
Внешнему уведомлению нужен собственный маршрут с предусмотренной проверкой подлинности. Он не должен требовать пользовательского входа, но это не означает, что его следует принимать без проверки подписи и параметров. Разработчик сверяет формат с документацией конкретной интеграции и возвращает подтверждение после устойчивого принятия. Если результат уже записан, повтор должен распознаваться безопасно. Исправление только ответа без проверки состояния заказа может прекратить повторы провайдера и одновременно оставить магазин с неучтённой оплатой.
Что проверяет разработчик
Для этой части понадобятся доступ к настройкам, журналам ошибок или коду. Её можно передать специалисту вместе с результатами предыдущих шагов.
- Найдите попытку уведомления для конкретной транзакции. Проверьте URL, HTTP-статус и тело ответа обработчика.
- Сверьте проверку подписи с форматом фактически полученного запроса. Изменение исходных данных до проверки может приводить к неверному результату.
- Проверьте соответствие идентификатора заказа, суммы и валюты. Уточните, не возвращает ли приложение HTML ошибки вместо ожидаемого протоколом ответа.
На что обратить внимание
Прокси, CSRF-проверка или общая авторизация способны отклонить запрос ещё до платёжного кода. Если обработчик дошёл до записи, причиной может быть повторная транзакция или неверный поиск заказа.
Как исправляют причину
Настройте отдельный защищённый обработчик по контракту уведомлений установленной интеграции. Возвращайте предусмотренный ответ только после надёжного принятия операции. Не отключайте проверку подписи ради прохождения теста.
Как убедиться, что проблема решена
Проверьте успешное уведомление, неверную подпись и повтор той же транзакции. Неподлинный запрос не должен менять заказ, а повтор подлинного — создавать второй платёж.
После ремонта проверьте успешное уведомление, повтор и запрос с неверной проверкой подлинности в тестовом окружении. Последний не должен менять заказ. Сверьте оплату и все связанные действия: письмо, резерв или выдачу доступа. Старые ошибки доставки разберите отдельно по операциям. Корректный код ответа полезен только вместе с подтверждённым и однократным бизнес-результатом на стороне магазина.