Не меняется статус заказа в WooCommerce: причины и как исправить

Заказ в WooCommerce оплачен, но остаётся в статусе «Ожидание оплаты». Или висит «На удержании», хотя деньги уже пришли. Иногда обратная ситуация: заказ должен перейти в «Выполнен», но продолжает числиться «В обработке».

Это не одна ошибка, а несколько разных сценариев. Статус заказа — итог работы оплаты, уведомления платёжного шлюза, логики WooCommerce, фоновых задач и иногда сторонних плагинов. Поэтому менять статус вручную — не диагностика, а временная маскировка симптома.

Что означают статусы заказов WooCommerce

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

Для виртуальных и скачиваемых товаров переход может отличаться. Поэтому сам по себе статус «В обработке» после успешной оплаты физического товара — не ошибка. WooCommerce обычно ждёт, что магазин завершит такой заказ после отправки.

Что это значит: прежде чем искать поломку, определите, какой статус должен быть у конкретного заказа с учётом способа оплаты и типа товара.

1. Посмотрите примечания внутри заказа

Откройте WooCommerce → Заказы → нужный заказ и изучите примечания справа. Это самый быстрый способ понять, видел ли WooCommerce ответ платёжной системы.

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

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

2. Проверьте, действительно ли платёж подтверждён

Фраза клиента «я оплатил» ещё не означает, что WooCommerce получил серверное подтверждение. Браузер покупателя может показать успешный экран, а webhook от банка или платёжного сервиса — не дойти до сайта.

Сверьте ID транзакции в заказе и личном кабинете платёжной системы. Затем проверьте журналы шлюза в WooCommerce → Статус → Журналы. Название файла зависит от используемого платёжного модуля.

Если видите это — вероятнее всего: деньги есть у эквайера, но в заказе нет transaction ID и примечания об успешной оплате — WooCommerce не получил или не обработал callback.

3. Проверьте webhook или callback платёжного шлюза

Современные шлюзы обычно подтверждают оплату серверным запросом. Если endpoint недоступен, защищён Basic Auth, блокируется firewall, Cloudflare, security-плагином или возвращает 403/500, заказ может остаться в старом статусе.

Проверьте журнал платёжного плагина и журнал ошибок сервера именно в момент транзакции. Для теста используйте sandbox/test mode шлюза, если он предусмотрен. На рабочем магазине не стоит делать серию реальных платежей «на удачу».

Если callback получает HTTP 500, сначала разберите серверную причину по инструкции как исправить ошибку 500 в WordPress.

4. Не путайте Processing и Completed

После успешной оплаты WooCommerce не обязан переводить любой заказ сразу в «Выполнен». Для обычного физического товара нормальный статус — «В обработке»: оплата получена, склад уже должен готовить заказ.

Автоматически завершаться обычно могут заказы, где все позиции виртуальные и скачиваемые. Если магазин продаёт физические товары, принудительный автопереход в Completed может сломать бизнес-процесс: менеджер увидит заказ как завершённый ещё до упаковки и отправки.

Универсальный принцип: статус заказа должен отражать реальное состояние операции, а не просто делать список заказов визуально «чистым».

5. Проверьте тип товара и его настройки

Откройте товары проблемного заказа. Для каждого проверьте флаги «Виртуальный» и «Скачиваемый». Ошибочная настройка может менять ожидаемую логику завершения заказа.

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

6. Проверьте Action Scheduler

WooCommerce использует фоновые задачи для ряда процессов. Откройте WooCommerce → Статус → Запланированные действия и посмотрите Failed и Pending.

Одна просроченная задача ещё не доказывает причину. Ищите повторяющиеся ошибки с одинаковым hook, совпадающие по времени с проблемными заказами. Откройте действие и посмотрите сообщение ошибки.

Быстрая проверка: если статусы начинают «догонять» нормальное состояние после запуска просроченных задач, проблема может быть в WP-Cron, Action Scheduler или серверном cron.

Не делайте так: не удаляйте массово таблицы Action Scheduler и не очищайте очередь SQL-запросом на рабочем магазине. В очереди могут находиться платежи, письма, подписки, синхронизация и другие бизнес-задачи.

7. Проверьте плагины, которые меняют статусы

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

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

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

8. Учитывайте кэш объектов и HPOS

Иногда заказ сохранён правильно, а административный интерфейс показывает устаревший счётчик или фильтр. В августе 2026 года в WooCommerce был зарегистрирован подтверждённый баг: после активации плагина с пользовательским статусом сам статус мог до 24 часов отсутствовать в строке фильтров Orders, а количество заказов отображалось неверно. Очистка object cache исправляла отображение сразу.

Поэтому различайте две ситуации: статус самого заказа неверный или неверно только отображение списка/счётчика. Откройте конкретный заказ и сравните его фактический статус с фильтрами списка.

Если используется Redis/Memcached, очищайте объектный кэш штатным способом. Не удаляйте записи заказов напрямую из базы, особенно при включённом HPOS.

9. Проверьте логи PHP и WooCommerce

Если изменение статуса запускает fatal error, выполнение PHP может оборваться посередине цепочки. Это особенно вероятно, если одновременно перестают отправляться письма, обновляться остатки или выполняться интеграции.

Ищите ошибки с timestamp проблемного заказа в WooCommerce → Статус → Журналы, журнале PHP хостинга и, при временно включённой безопасной диагностике, в WordPress debug.log.

Если появляется Fatal Error, не лечите его увеличением memory_limit вслепую. Сначала определите файл, плагин и стек вызовов. Для этого есть отдельная инструкция как найти причину Fatal Error в WordPress.

10. Почему ручная смена статуса может быть опасной

Статус связан не только с подписью в админке. Его изменение может запускать письма, списание или возврат остатков, интеграции, вебхуки и пользовательские хуки.

Например, актуальная документация WooCommerce указывает: при Processing оплата уже получена и остаток уменьшен; при Cancelled остаток возвращается в доступный запас, если управление запасами включено. Поэтому хаотичное переключение статусов способно создать второй уровень проблемы — рассинхронизацию склада.

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

Актуальные нюансы WooCommerce в 2026 году

Свежие Issues показывают, почему диагностику статусов нельзя сводить к одному переключателю. В августе 2026 года подтверждена проблема кэширования пользовательских статусов в Orders: заказ хранится правильно, но фильтр и счётчики временно показывают другое состояние.

В июле разработчики исправляли отдельный сценарий, когда при переходе заказа из On hold в Failed ранее уменьшенный остаток не восстанавливался. А в текущей документации WooCommerce уже явно указано, что при Failed ранее списанный остаток возвращается в inventory. Это хороший пример того, почему советы двухлетней давности для WooCommerce иногда опаснее самой ошибки.

Ещё один важный момент из официальной Payment Gateway API: после успешной оплаты разработчикам шлюзов рекомендуется вызывать $order->payment_complete(), позволяя WooCommerce самому выбрать Processing или Completed и корректно обработать склад. Жёстко выставлять статус после платежа сторонним кодом — менее надёжная архитектура.

Коротко: что делать сейчас

1. Откройте проблемный заказ и прочитайте его примечания.
2. Сверьте transaction ID и фактический платёж у шлюза.
3. Проверьте webhook/callback и журнал платёжного плагина.
4. Убедитесь, что ожидаете правильный статус: Processing не равен ошибке.
5. Проверьте типы товаров и настройки вариаций.
6. Посмотрите Failed/Pending в Action Scheduler.
7. Исключите плагины и сниппеты, меняющие order status.
8. При HPOS и object cache проверьте, не ошибается ли только интерфейс.
9. Сопоставьте PHP/WooCommerce logs со временем заказа.

Когда пора остановиться

Остановите самостоятельные эксперименты, если деньги списаны, а WooCommerce не фиксирует оплату; несколько заказов одновременно получают неправильный статус; статусы расходятся с CRM/1С; появились повторные списания или возвраты остатков; либо изменение статуса вызывает PHP Fatal Error.

В этих случаях проблема уже затрагивает не только интерфейс WordPress, но и платежи, склад и учёт. Исправление «методом выключения всего подряд» на рабочем магазине может стоить дороже самой диагностики.

FAQ

Почему оплаченный заказ WooCommerce остаётся «Ожидание оплаты»?

Чаще всего WooCommerce не получил или не обработал серверное подтверждение платёжного шлюза. Проверьте примечания заказа, transaction ID, webhook/callback и журнал шлюза.

Почему заказ после оплаты остаётся «В обработке»?

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

Можно ли автоматически переводить все заказы в «Выполнен»?

Технически можно, но для физических товаров это часто неправильная бизнес-логика. Автозавершение стоит внедрять только после проверки типов товаров, оплаты, доставки и процессов склада.

Почему статус меняется обратно после ручного сохранения?

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

Может ли кэш показывать неправильный статус?

Да, особенно речь может идти о фильтрах и счётчиках списка заказов. Сначала откройте сам заказ и проверьте фактическое состояние. Для Redis/Memcached используйте штатную очистку object cache.