WooCommerce заказ не создается после оплаты через YooKassa: как найти причину и исправить

Автор: Виктор Белов | Опубликовано: 17.09.2026

Сценарий типичный: покупатель оплачивает заказ, деньги списываются, а в WooCommerce заказ остается в статусе pending или вообще не появляется в админке. Для магазина это неприятнее, чем просто ошибка на странице оплаты: платеж прошел, а автоматизация не сработала, склад не списался, письмо не ушло, менеджер не увидел заказ.

Чаще всего проблема не в самом WooCommerce, а в связке checkout → платежный шлюз → webhook → обновление статуса заказа. Ниже — практический разбор, что именно ломается, как это проверить и как исправить без лишних догадок.

Как выглядит проблема на практике

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

Что обычно видит администратор

в WooCommerce нет нового заказа после успешной оплаты;
заказ есть, но статус не меняется с pending или on-hold;
в журнале платежного шлюза нет входящего webhook;
в логах сайта встречаются ошибки 403, 404, cURL error или сообщения о неверной подписи;
платеж в кабинете YooKassa отмечен как успешный, а WooCommerce продолжает считать заказ неоплаченным.

Диагностика: где именно рвется цепочка

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

1. Проверьте, создается ли заказ вообще

Если заказ появляется в админке, но не оплачивается — это одна история. Если записи нет совсем, значит проблема раньше: на этапе оформления заказа, AJAX-запроса или редиректа после оплаты. Для начала откройте WooCommerce → Статус → Журналы и найдите лог платежного шлюза. У многих шлюзов для WooCommerce есть собственный лог-файл, который можно включить в настройках.

2. Посмотрите, приходит ли webhook

Именно webhook обычно сообщает WooCommerce, что оплата завершена. Если он не доходит, магазин не узнает о платеже. Причины банальные: неверный URL, блокировка на уровне CDN/WAF, закрытый доступ к wp-json, защита от ботов, Basic Auth на staging-сайте.

Проверить endpoint можно вручную. У YooKassa адрес webhook задается в настройках магазина в личном кабинете, а на стороне WordPress нужно убедиться, что сайт доступен извне и не режет POST-запросы.

3. Проверьте логи WordPress и сервера

Если есть доступ к wp-config.php, временно включите логирование. Это не решение, а способ поймать ошибку в момент оплаты.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

После тестовой оплаты смотрите файл wp-content/debug.log. Если там есть ошибки вида REST API route not found, 403 Forbidden, Invalid signature или Call to undefined function, круг поиска резко сужается.

Пошаговое решение

Ниже порядок, который обычно экономит время. Идите сверху вниз: сначала исключаем внешние блокировки, потом проверяем настройки шлюза, затем — совместимость и кодовые конфликты.

Шаг 1. Убедитесь, что webhook URL доступен извне

Если сайт защищен Basic Auth, Cloudflare Access, IP-ограничением или режимом обслуживания, webhook может не пройти. Для теста откройте URL, который использует платежный шлюз, с внешней сети. Если запрос получает 401, 403 или редирект на страницу входа, YooKassa не сможет подтвердить оплату.

Если у вас включен CDN или WAF, добавьте исключение для путей WooCommerce REST API и callback-адресов платежного шлюза. Точный путь зависит от плагина, но обычно это что-то вроде /wp-json/ и callback-эндпоинт самого шлюза.

Шаг 2. Проверьте настройки платежного шлюза

В настройках YooKassa важно сверить:

shop ID и секретный ключ;
режим тест/боевой;
адрес сайта без лишних редиректов;
включен ли прием уведомлений о платежах;
какой статус WooCommerce должен ставиться после успешной оплаты.

Если магазин работает на http в настройках, а фактически открывается по https, webhook и callback могут вести себя нестабильно. После переезда на HTTPS особенно важно проверить, что в Настройки → Общие указан один и тот же домен и протокол везде.

Шаг 3. Уберите конфликт с кэшем и редиректами

Платежные callback-страницы не должны попадать под кэширование. Если кэшируется checkout, order-received или REST-эндпоинт, шлюз может получать не тот ответ, который ожидает. Исключите из кэша:

/cart/
/checkout/
/my-account/
страницы благодарности и callback-URL платежного модуля;
/wp-json/, если шлюз использует REST API.

Если стоит плагин безопасности, проверьте, не блокирует ли он POST-запросы к REST API. Иногда достаточно временно отключить защиту и повторить тестовую оплату, чтобы подтвердить причину.

Шаг 4. Проверьте совместимость с темой и плагинами

Частая ошибка — кастомная тема или плагин меняют шаблон checkout и ломают стандартный сценарий WooCommerce. Особенно это заметно, если на странице оформления заказа есть собственные AJAX-скрипты, дополнительные поля или редиректы после нажатия кнопки оплаты.

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

Шаг 5. Сравните подходы к исправлению

Подход	Когда подходит	Минус
Настроить webhook и исключения в WAF/CDN	Если платеж успешен, но статус не обновляется	Нужно иметь доступ к панели хостинга или CDN
Отключить конфликтующий плагин/скрипт	Если checkout или редирект ломается после оплаты	Потребуется ручная проверка совместимости
Исправить шаблон темы и AJAX на checkout	Если заказ не создается до оплаты	Нужен доступ к коду темы

Пример: как проверить webhook через код

Если нужно быстро понять, доходит ли запрос до WordPress, можно временно повесить логирование на REST API. Это не постоянное решение, а диагностический инструмент. Добавьте код в functions.php дочерней темы или в небольшой mu-plugin:

add_action( 'rest_api_init', function () {
    register_rest_route( 'wpbono/v1', '/ping', array(
        'methods'  => 'POST',
        'callback' => function( WP_REST_Request $request ) {
            error_log( 'Webhook test received: ' . wp_json_encode( $request->get_params() ) );
            return new WP_REST_Response( array( 'ok' => true ), 200 );
        },
        'permission_callback' => '__return_true',
    ) );
} );

После этого отправьте тестовый POST-запрос на /wp-json/wpbono/v1/ping любым HTTP-клиентом. Если лог не появляется, значит проблема не в YooKassa, а в доступности REST API, правилах сервера или блокировке запросов.

Для проверки самого сайта полезно также посмотреть, не режет ли сервер обращения к wp-json. Если запросы к REST API возвращают HTML-страницу вместо JSON, платежный модуль может не распознать ответ.

Как проверить, что исправление сработало

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

создайте тестовый заказ;
оплатите его в тестовом режиме или на минимальную сумму в боевом, если это допустимо;
убедитесь, что заказ появился в WooCommerce;
проверьте, что статус сменился на ожидаемый — обычно processing или completed;
посмотрите, пришло ли уведомление на почту администратора и покупателя;
откройте лог платежного шлюза и убедитесь, что webhook обработан без ошибки.

Если заказ создается, но статус не меняется, это уже не проблема checkout. Тогда смотрите, какой именно ответ возвращает шлюз, и не перехватывает ли его кастомный код через фильтры WooCommerce.

Частые ошибки и как их исправить

Webhook ведет на старый домен или старый протокол

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

Страница checkout кэшируется

Если кэш попадает на оформление заказа, WooCommerce может отдавать устаревшую форму или ломать nonce. Исключите checkout, корзину и страницу благодарности из кэша на уровне плагина, сервера и CDN.

Плагин безопасности блокирует REST API

Некоторые security-плагины слишком агрессивно режут POST-запросы. Если после их отключения проблема исчезает, настройте исключения для WooCommerce и платежного шлюза, а не держите защиту выключенной постоянно.

Кастомный код меняет поведение checkout

Часто в теме есть хук, который меняет редирект после оплаты или подменяет шаблон благодарности. Если такой код написан без проверки условий, он может перехватывать стандартный сценарий WooCommerce. Ищите woocommerce_thankyou, template_redirect, woocommerce_checkout_process и похожие места, где мог появиться лишний редирект.

Смешаны тестовый и боевой режимы

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

Что делать для стабильности дальше

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

держите checkout без лишних скриптов и тяжелых виджетов;
не кэшируйте страницы оплаты и благодарности;
сохраняйте включенным логирование платежного шлюза хотя бы на время внедрения;
после обновлений WooCommerce и платежного плагина повторяйте тестовый платеж;
если используете кастомную тему, проверяйте совместимость после каждого крупного апдейта.

Если у вас много правок в checkout и шаблонах магазина, полезно держать отдельную дочернюю тему и не смешивать бизнес-логику с визуальными изменениями. Так проще найти, что именно сломало создание заказа после оплаты.

Когда в магазине важна не только оплата, но и дальнейшая автоматизация, лучше заранее выстроить понятную схему: платежный шлюз пишет в лог, WooCommerce получает webhook, статус меняется без ручного вмешательства, а исключения из кэша и защиты задокументированы. Это дешевле, чем каждый раз разбирать «оплата прошла, заказа нет» вручную.