ЮKassa в WooCommerce: почему не меняется статус заказа после оплаты

Одна из самых неприятных ошибок интернет-магазина выглядит так: покупатель видит успешную оплату в ЮKassa, деньги действительно приняты, но в WooCommerce заказ продолжает висеть как Pending payment или On hold. Менеджер начинает вручную менять статусы, а автоматизация склада, писем и CRM перестаёт быть надёжной.

В такой ситуации не стоит сразу переустанавливать платёжный модуль. Сначала нужно понять, на каком участке разорвалась цепочка «платёж → серверное уведомление → обработчик WooCommerce → изменение заказа».

Как должен обновляться заказ после оплаты

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

В документации WooCommerce Pending payment означает созданный, но ещё не оплаченный заказ, а Processing — оплату, которая уже получена, после чего физический товар ждёт выполнения. Официальная таблица статусов: WooCommerce Order Statuses.

Почему успешная оплата может не попасть в WooCommerce

Причины удобно разделить на четыре группы:

• ЮKassa не отправила или не смогла доставить уведомление;
• уведомление дошло до сервера, но его заблокировал WordPress, WAF или хостинг;
• платёжный модуль получил событие, но завершился ошибкой;
• статус обновился, но другой код сразу изменил его снова.

ЮKassa описывает webhook как способ получать события об изменении состояния объектов API. Это особенно важно для платежей, которые могут менять состояние асинхронно. Официальная документация: уведомления ЮKassa.

Шаг 1. Сверить платёж и заказ

Нельзя диагностировать проблему только по словам «клиент оплатил». Нужно сопоставить конкретный WooCommerce order ID и конкретный payment ID. В карточке заказа проверьте способ оплаты, transaction ID, время создания заказа и order notes.

Если в order notes вообще нет записей от платёжного шлюза, это важный сигнал. WooCommerce в своей инструкции по troubleshooting отмечает, что отсутствие сообщений платёжного шлюза может означать сбой коммуникации или обрыв процесса до его завершения.

Шаг 2. Проверить order notes

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

Официальная инструкция WooCommerce по проблемным заказам рекомендует начинать именно с определения платёжного метода и анализа order notes: Troubleshooting Orders.

Шаг 3. Проверить webhook endpoint

Следующий вопрос: доступен ли endpoint, на который должна прийти ЮKassa. Его нельзя проверять только из браузера администратора. Запрос приходит снаружи и может проходить через CDN, WAF, nginx/Apache, WordPress и код платёжного расширения.

Что может заблокировать запрос

• Cloudflare rule или bot protection;
• security-плагин WordPress;
• Basic Auth на staging или всём сайте;
• maintenance mode;
• ошибка SSL;
• редирект HTTP → HTTPS, который обработчик не ожидает;
• ограничение по IP;
• фатальная PHP-ошибка в endpoint.

Если сайт недавно переносили, меняли домен, CDN или конфигурацию nginx, нужно отдельно проверить, что уведомления идут на актуальный URL.

Шаг 4. Посмотреть технические логи WooCommerce

В WooCommerce есть системные журналы, а платёжные расширения часто добавляют собственный source. В логах нужно искать не только строку «error», но и последовательность: пришёл запрос, распознан payment ID, найден order ID, проверено состояние, выполнено изменение заказа.

Не публикуйте логи целиком в открытом доступе. Перед передачей разработчику уберите API-ключи, токены, Authorization headers и персональные данные клиентов.

Шаг 5. Проверить, не меняет ли статус другой код

Иногда webhook работает правильно: заказ на секунду становится Processing, а затем кастомный код, CRM-коннектор или автоматизация переводит его обратно. Причину ищут в hooks, которые реагируют на изменение заказа, и во внешних интеграциях.

Особенно внимательно стоит проверить:

• кастомный код в functions.php и MU-плагинах;
• синхронизацию с CRM или учётной системой;
• автоматизацию статусов доставки;
• плагины управления заказами;
• cron и Action Scheduler;
• код, который вызывает update_status() или похожую логику.

Шаг 6. Убедиться, что Processing — не ошибка

Частая путаница: владелец магазина ждёт, что после оплаты заказ сразу станет Completed. Но для большинства физических товаров Processing — нормальный статус: платёж получен, остаток уменьшен, заказ ждёт сборки или отправки. WooCommerce не обязан автоматически завершать такие заказы.

Если же заказ остался Pending payment при подтверждённом платеже, это уже повод проверять gateway notification flow.

Повторные уведомления — нормальная ситуация

Интеграция должна выдерживать повтор одного и того же события. Нельзя строить обработчик по принципу «при каждом запросе отправить письмо, списать остаток и создать запись в CRM». Сначала нужно проверить, обрабатывалось ли событие, и каково текущее состояние заказа.

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

Что делать, если webhook приходит, но обработчик отвечает 500

HTTP 500 означает серверную ошибку. Типовой порядок диагностики:

1. зафиксировать время запроса;
2. посмотреть PHP error log и WooCommerce log;
3. проверить stack trace;
4. выяснить, падает ли сам платёжный модуль или сторонний hook после него;
5. повторить тест на staging с теми же версиями;
6. исправить конкретную причину и снова проверить событие.

Не стоит временно отключать проверку событий или принудительно ставить Processing всем заказам — так можно замаскировать проблему и создать ложные оплаченные заказы.

Что проверить после обновления WordPress или WooCommerce

Если проблема началась сразу после обновления, сравните версии платёжного расширения, WooCommerce, WordPress и PHP. Также проверьте изменения checkout-блоков и кастомные overrides темы. Платёжный код может зависеть от hooks, структуры checkout или способа хранения заказов.

Для существующего магазина безопаснее сначала делать точечную диагностику и доработку WordPress, чем менять несколько компонентов одновременно.

Минимальный тест после исправления

1. создать новый тестовый заказ;
2. зафиксировать order ID;
3. провести оплату;
4. проверить payment ID;
5. убедиться, что уведомление доставлено;
6. проверить order notes;
7. сверить статус заказа;
8. проверить остатки;
9. проверить письмо клиенту;
10. убедиться, что повтор уведомления не дублирует действия.

Когда проблема не в ЮKassa

Успешный платёж в кабинете ЮKassa и ошибка в WooCommerce не обязательно означают сбой платёжной системы. Платёж мог быть подтверждён корректно, а ошибка возникла уже на сервере магазина. Поэтому сначала разделяют внешний статус платежа и внутреннюю обработку WordPress.

Если магазин связан с CRM, складом или доставкой, платёжный статус лучше считать отдельным source of truth, а дальнейшие интеграции запускать после подтверждённого перехода заказа. Для сложных связок можно использовать отдельную интеграционную архитектуру сайта и CRM.

FAQ

Платёж успешен, а заказ Pending payment. С чего начать?

Сверьте order ID и payment ID, затем посмотрите order notes и логи платёжного шлюза. После этого проверяйте доставку webhook.

Можно ли просто вручную поставить Processing?

Как временная операция для конкретного подтверждённого заказа — возможно, но это не устраняет причину. Следующий заказ может зависнуть так же.

Почему webhook иногда приходит несколько раз?

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

Может ли Cloudflare мешать оплате?

Да, если правило безопасности блокирует endpoint уведомлений или выдаёт challenge. Это проверяется по логам Cloudflare и серверным access logs.

Почему заказ остаётся Processing и не становится Completed?

Для физического товара Processing обычно означает, что платёж уже получен и заказ ждёт выполнения. Это не обязательно ошибка.

Какие данные прислать разработчику?

Версии WordPress/WooCommerce/платёжного расширения, order ID, время теста, order notes и релевантный фрагмент лога без секретных ключей и персональных данных.

Итог

Если ЮKassa приняла деньги, а WooCommerce не меняет статус, проблему нужно искать последовательно: сопоставить платёж и заказ, проверить order notes, webhook endpoint, серверные логи и сторонние hooks. Такой подход быстрее случайной переустановки плагинов и позволяет устранить именно повторяемую причину. Если нужна диагностика существующей интеграции, можно прислать техническое описание проблемы.