При задержке или отсутствии вебхука от платежного шлюза статус транзакции на сервере может не обновиться автоматически. В этом случае необходимо вручную инициировать повторную проверку статуса через API-методы провайдера, так как отсутствие системы обработки ошибок (retry logic) приводит к тому, что транзакции остаются в статусе 'pending' или 'unknown', даже если оплата прошла.

1. Диагностика причины задержки

Перед изменением статуса определите, почему вебхук не пришел. Основные причины: таймауты на стороне вашего сервера, ошибки 5xx (ошибки сервера), блокировка IP-адресов шлюза или перегрузка сети.

Проверьте логи веб-сервера (Nginx/Apache) в момент ожидаемого события. Ищите записи об ошибках соединения с адресом платежного шлюза. Если ошибок нет, но статус не обновился, проблема может быть в логике обработки входящих запросов вашего приложения.

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

2. Подтверждение факта оплаты

Не меняйте статус транзакции до подтверждения факта оплаты у провайдера. Многие шлюзы предоставляют возможность проверить статус транзакции через API-метод (например, GET /transactions/{id}).

Запросите отчет о транзакциях у платежного сервиса или проверьте статус в личном кабинете. Если там статус 'success' или 'completed', значит, деньги списаны, и ваша база данных просто не получила уведомление.

Важно: при ручной корректировке статуса следует учитывать правила платежного шлюза (например, запрет на изменение статуса 'failed' в пользу 'success' без подтверждения).

3. Программное обновление статуса

Используйте API-методы провайдера для инициирования повторной проверки статуса транзакции. Это безопаснее, чем менять статус напрямую в базе данных.

Если у вас есть административная панель или возможность выполнить SQL-запрос (с осторожностью), обновите запись в таблице заказов. Измените поле status на актуальное значение и закомментируйте поле webhook_received или добавьте флаг manual_update.

Запустите скрипт проверки, который будет опрашивать шлюз по списку транзакций со статусом 'pending' более N часов.

4. Предотвращение повторных ситуаций

Внедрите логику повторных попыток (retry logic) для обработки вебхуков. Если первый запрос не прошел, сервер должен отправить его повторно через заданный интервал.

Настройте мониторинг доставки вебхуков. Используйте инструменты алертинга, которые будут уведомлять вас о пропущенных уведомлениях.

Улучшите техническую базу сайта: увеличьте время ожидания ответов (timeout), оптимизируйте обработку входящих запросов и убедитесь, что сервер доступен 24/7.

Вопросы и ответы

Можно ли просто удалить вебхук из очереди?

Нет. Удаление уведомления не подтверждает факт оплаты и может привести к потере данных о транзакции. Сначала проверьте статус у провайдера, затем обновите запись в базе.

Что делать, если шлюз тоже показывает ошибку?

Если и у вас, и у провайдера есть ошибки, значит, транзакция не прошла. Не меняйте статус вручную. Дождитесь ответа от платежной системы или свяжитесь с поддержкой шлюза.

Как часто нужно проверять статусы 'pending'?

Рекомендуется проверять транзакции со статусом 'pending' каждые 15–30 минут в течение первых двух часов после оплаты. После этого можно переходить к периодической проверке раз в час.

По теме

Похожие статьи