Ошибка оформления заказа в WooCommerce почти всегда всплывает в худший момент - во время рекламной кампании, распродажи или через час после того, как маркетолог наконец запустил трафик на карточки товаров. Клиент доходит до кнопки «Оформить заказ», жмёт - и вместо страницы с номером заказа получает белый экран, зависшую кнопку или сухое «Произошла ошибка при обработке заказа». За несколько лет поддержки интернет-магазинов на WooCommerce я разбирал десятки таких случаев: от конфликта кэширующего плагина с блочным чекаутом до опечатки в секретном ключе эквайринга T‑Bank. Ниже - порядок действий, которым реально пользуюсь на диагностике, без теории из документации.
Логи WooCommerce - с чего начинать диагностику
Первый шаг - не гадать, а смотреть логи. В разделе WooCommerce → Статус → Логи собираются записи платёжных шлюзов, если в настройках метода оплаты включено логирование (у большинства плагинов эквайринга это отдельный чекбокс «Debug log» или «Логирование запросов»). Если список пуст - режим отладки WordPress выключен, и это первое, что я включаю в wp-config.php:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);После этого фатальные ошибки PHP падают в wp-content/debug.log, а специфичные для WooCommerce события - в wp-content/uploads/wc-logs/. Обычно там сразу видно, на каком шаге всё сломалось: до создания заказа (сбой в хуках woocommerce_checkout_process), во время создания (проблема с валидацией полей формы) или уже при обращении к платёжному шлюзу.
Чаще всего за ошибкой оформления заказа в WooCommerce стоит одна из четырёх вещей:
- конфликт свежеобновлённого плагина с темой или с ядром WooCommerce;
- тема без поддержки блочного чекаута, собранная под старую версию WooCommerce;
- упёршийся в потолок memory_limit на слабом тарифе хостинга;
- таймаут при обращении к внешнему API - платёжному шлюзу или службе доставки.
Ошибка оплаты в WooCommerce: коды эквайринга и что за ними стоит
Если заказ создаётся, но зависает на оплате, смотрю не логи WooCommerce, а ответ от платёжного шлюза. У T‑Bank, ЮKassa и Сбербанка свои коды отказа, и по ним обычно сразу понятно, где искать причину.
| Код / сообщение шлюза | Типичная причина | Что проверить |
|---|---|---|
| Do not honor / «Отказано банком-эмитентом» | Недостаточно средств, лимит по карте или блокировка банком клиента | Сайт тут ни при чём - попросить клиента другую карту или способ оплаты |
| Invalid amount | Сумма заказа не совпадает с суммой в запросе на оплату - часто из-за пересчёта скидки или доставки после редиректа | Хуки пересчёта корзины перед отправкой на оплату, порядок применения купонов |
| Terminal not found / неверный ключ | Ошибка в TerminalKey или Password в настройках плагина эквайринга, либо тестовый ключ забыт на боевом сайте | Сверить значения с личным кабинетом эквайринга построчно |
| Заказ висит в «Ожидании оплаты» после списания денег | Уведомление от эквайринга (webhook) не дошло до сайта | Доступность Notification URL извне, firewall хостинга, логи входящих запросов |
Отдельная история - когда деньги с карты списались, а заказ так и остался в статусе «Ожидает оплаты». Это почти всегда значит, что уведомление от эквайринга не долетело: сервер режет запросы без нужного user-agent, хостинг поставил свой firewall перед сайтом, либо после переезда на HTTPS в настройках плагина остался старый адрес уведомлений.
Классический чекаут против блочного - где чаще ломается WooCommerce
Начиная с версии 8.3 WooCommerce по умолчанию использует блочный чекаут на React (Cart & Checkout blocks) вместо старого шорткода [woocommerce_checkout]. Многие плагины подписок, кастомных полей доставки и купонов написаны под старые хуки и с блоками не дружат - форма загружается нормально, но по клику на «Оформить заказ» ничего не происходит, а в консоли браузера сыплются ошибки React.
Когда клиент говорит «ничего не происходит после клика», в большинстве случаев причина - старый плагин, который трогает чекаут через устаревшие хуки. Быстрая проверка: временно переключаю чекаут на классический шорткод (WooCommerce → Настройки → Функции → выключить «Чекаут блоками») и смотрю, воспроизводится ли ошибка на старой версии. Если нет - ищу среди активных плагинов тот, что последним обновлялся до перехода на блоки, и проверяю его совместимость по changelog.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Ошибки расчёта доставки: СДЭК, зоны доставки и кэш стоимости
Если на чекауте виснет расчёт доставки, а не оплата, ищу проблему в другом месте. Плагин СДЭК для WooCommerce обращается к внешнему API за расчётом стоимости и сроков, и при недоступности сервиса или превышении таймаута WooCommerce просто не показывает ни одного метода доставки - форма оформления заказа блокируется целиком, потому что без выбранного способа доставки кнопка «Оформить заказ» неактивна.
Вторая частая причина - пересекающиеся зоны доставки в настройках WooCommerce: два региона совпадают по почтовым индексам, и система не может однозначно выбрать метод. Третья - агрессивное кэширование AJAX-запросов плагинами вроде WP Rocket или LiteSpeed Cache: стоимость доставки закэширована для одного адреса и подставляется всем последующим покупателям, пока кэш не сбросится вручную.
Если нужно быстро понять, на каком шаге отваливается расчёт доставки, я обычно вешаю логирование на хук woocommerce_after_calculate_totals - в разделе готовых скриптов для WordPress есть шаблон такого логгера, который пишет в отдельный файл каждый пересчёт корзины с деталями по выбранным методам доставки и суммам.
Ошибки JavaScript на чекауте: консоль браузера, кэш и минификация
При жалобе «кнопка не реагирует» первым делом открываю консоль разработчика и вкладку Network прямо во время оформления заказа. Самая частая находка - агрессивная минификация и объединение скриптов плагинами кэширования: checkout.js склеивается с другими файлами не в том порядке, зависимость от jQuery ломается, и вместо перехода к оплате пользователь видит зацикленное «Ошибка при обработке заказа. Пожалуйста, попробуйте ещё раз».
Лечится исключением скриптов чекаута из минификации и объединения в настройках кэш-плагина, плюс полной очисткой кэша страницы оформления заказа после изменений. Второй по частоте случай - блокировщики рекламы вроде uBlock Origin: если тема синхронно дергает трекинг-скрипты (gtag, fbq) прямо в обработчике клика по кнопке заказа, а блокировщик обрывает запрос с исключением, весь последующий код обработчика может не выполниться из-за необработанной ошибки в синхронной цепочке.
Когда ошибка воспроизводится не у всех клиентов
Самые неприятные случаи - когда лично на тестовом заказе всё проходит гладко, а часть клиентов пишет о сбое. Практика показывает несколько типичных сценариев:
- заказ не оформляется только из встроенного браузера Instagram или Telegram - WebView не поддерживает нужный JS API или блокирует сторонние cookies;
- ошибка появляется только при оплате через СБП, а картой всё проходит - проблема в отдельном модуле плагина эквайринга, а не в чекауте целиком;
- сбой ловят клиенты из определённого региона или через VPN - антифрод-система эквайринга режет транзакцию по гео, к сайту это отношения не имеет;
- ошибка всплывает только при повторном заказе - в localStorage браузера залип старый купон или устаревший nonce корзины.
Чтобы такие кейсы не тянулись неделями, тестирую оформление заказа в нескольких браузерах, в режиме инкогнито, с VPN и без него, а также с мобильного устройства - большая часть «неповторяемых» багов воспроизводится именно на этом наборе условий.
Интернет-магазин под ключ
Интернет-магазин
от 80 000 ₽
Подробнее →Частые вопросы
Как узнать причину ошибки оформления заказа в WooCommerce, если логи пустые?
Включите WP_DEBUG и WP_DEBUG_LOG в wp-config.php, но учтите, что не все хостинги пишут в wp-content/debug.log - иногда ошибки уходят только в общий error_log хостинга, доступный через панель управления. Дальше полезно поставить Query Monitor и воспроизвести заказ с включённым только необходимым минимумом плагинов через встроенный в WooCommerce режим устранения неполадок (Troubleshooting Mode в разделе Статус).
Почему заказ создаётся, но не переходит к оплате?
Обычно дело в редиректе на страницу платёжного шлюза после клика по кнопке: либо его блокирует ошибка JavaScript где-то на странице, либо плагин эквайринга обращается по неверному API-адресу. Проверяю вкладку Network в браузере - там видно, ушёл ли POST-запрос к шлюзу и какой код ответа вернулся.
Может ли причиной быть хостинг, а не сама WooCommerce?
Да, и довольно часто. Низкий memory_limit обрывает выполнение скрипта на середине оформления заказа, короткий max_execution_time вызывает таймаут при обращении к API доставки или оплаты, а правила mod_security на некоторых тарифах блокируют POST-запросы с кириллицей в адресе или спецсимволами в полях - заказ просто не доходит до сервера.
Как быстро вернуть заказы, пока разбираюсь в причине ошибки?
Включаю запасной способ оплаты - банковский перевод или оплату при получении, чтобы заказы продолжали приходить, пока чиню основной канал оплаты. Если проблема в блочном чекауте, временно переключаюсь на классический шорткод - это не решение, а костыль на несколько часов, пока не найдена настоящая причина.