Сценарий типичный: оплата в Stripe проходит, деньги списываются, а в WooCommerce заказ остаётся в статусе «Ожидает оплаты» или «В обработке» без движения. Чаще всего проблема не в самом платёжном модуле, а в том, что сайт не получает callback от Stripe или получает его, но не может обработать.
Если у вас включён кеш, защита от ботов, нестандартный редирект на checkout или сайт за прокси/CDN, webhook может ломаться тихо: в админке нет явной ошибки, но статус заказа не меняется. Ниже — рабочая схема диагностики и исправления без выдуманных «магических» настроек.
Как понять, что проблема именно в webhook
Сначала отделите проблему связи от проблемы плагина. Если оплата в Stripe создаётся, но WooCommerce не меняет статус заказа автоматически, проверьте три вещи:
- в Stripe в разделе Developers → Webhooks есть событие, отправленное на ваш сайт;
- ответ вашего сайта на запрос webhook не 200 OK;
- в логах WooCommerce или сервера есть ошибки на пути
/wc-api/или/wp-json/, если плагин использует REST endpoint.
Для Stripe важен не только факт доставки, но и корректный ответ. Если сайт отвечает 301/302, 403, 404 или 500, Stripe будет считать доставку неуспешной и повторять попытки.
Что смотреть в первую очередь
- Статус события в Stripe: delivered, failed, pending.
- URL webhook: без лишних редиректов и с HTTPS.
- Логи плагина оплаты в WooCommerce → Status → Logs.
- Не блокирует ли запрос WAF, Cloudflare, security-плагин или basic auth на staging-сайте.
Пошаговое решение
1. Проверьте URL webhook в Stripe
В большинстве интеграций WooCommerce Stripe использует отдельный endpoint, который плагин показывает в настройках. Не подменяйте его вручную, если не понимаете, как плагин формирует callback URL. Откройте настройки платёжного метода и скопируйте адрес webhook именно оттуда.
Если сайт работает через редирект с http на https, убедитесь, что Stripe отправляет запрос сразу на конечный HTTPS-адрес. Лишний редирект часто ломает подпись webhook.
2. Убедитесь, что сервер не режет POST-запросы
Webhook Stripe — это обычный POST-запрос. Если на сервере включён жёсткий ModSecurity, ограничение по user-agent или защита от внешних POST на уровне CDN, запрос может не доходить до WordPress. В таком случае нужно смотреть access/error-логи веб-сервера, а не только WordPress.
# Пример проверки ответа webhook-URL вручную через curl
curl -i -X POST https://example.com/?wc-api=wc_stripe \
-H 'Content-Type: application/json' \
-d '{"id":"evt_test_webhook","type":"payment_intent.succeeded"}'Если в ответе видите редирект, HTML-страницу авторизации или ошибку сервера, проблема на стороне маршрутизации или защиты, а не Stripe.
3. Посмотрите логи WooCommerce
В WooCommerce многие платёжные плагины пишут диагностические логи. Откройте WooCommerce → Status → Logs и найдите файл, связанный со Stripe. Ищите строки с ошибками подписи, таймаутами, неверным secret key или невозможностью разобрать payload.
Если логов нет вообще, это тоже сигнал: либо логирование отключено, либо запрос не доходит до обработчика плагина.
4. Отключите конфликтующие ограничения только для webhook-URL
Не нужно выключать защиту сайта целиком. Достаточно сделать исключение для конкретного endpoint. Обычно это:
- исключение из кеширования;
- исключение из WAF/Firewall;
- отключение редиректа на странице webhook;
- разрешение POST-запросов без авторизации.
Если у вас Cloudflare, проверьте, не включены ли правила, которые блокируют запросы к /wc-api/ или /wp-json/. Если стоит basic auth на staging, Stripe туда не достучится без отдельной настройки.
5. При необходимости добавьте точечное исключение в WordPress
Иногда мешает не сервер, а код темы или плагина, который вмешивается в запросы. Например, если у вас есть фильтры на редиректы или принудительная авторизация, можно не трогать весь сайт, а исключить webhook-адрес.
<?php
add_action('template_redirect', function () {
if (isset($_SERVER['REQUEST_URI']) && str_contains($_SERVER['REQUEST_URI'], 'wc-api')) {
return;
}
// Здесь может быть ваш код редиректа, защиты или ограничения доступа.
});Этот пример не «чинит Stripe» сам по себе, а показывает принцип: любые глобальные правила должны обходить технические endpoint'ы платежей.
Сравнение подходов: плагин, сервер, код
| Подход | Когда подходит | Минус |
|---|---|---|
| Настройки Stripe/WooCommerce | Неверный URL, отключён webhook, ошибка ключей | Не помогает, если запрос режет сервер |
| Правки на сервере/CDN | 403, 301, 404, 5xx на webhook | Нужен доступ к хостингу или панели CDN |
| Точечный код-исключение | Конфликт с редиректами, защитой, кастомной логикой | Нужно аккуратно тестировать после обновлений |
Проверка результата после внедрения
После исправления не ограничивайтесь тестовой оплатой в админке. Проверьте цепочку целиком:
- Создайте тестовый заказ в WooCommerce.
- Проведите оплату в тестовом режиме Stripe.
- Откройте событие webhook в Stripe и убедитесь, что статус delivery успешный.
- Проверьте, что заказ в WooCommerce сменил статус автоматически.
- Посмотрите, не создались ли дубликаты заказов или повторные попытки обработки.
Если статус меняется только после ручного обновления страницы или входа в админку, значит webhook всё ещё не работает как надо, а не «просто медленно доходит».
Частые ошибки и как их исправить
Webhook ведёт на старый домен или staging
После миграции сайта в Stripe часто остаётся старый URL. Обновите endpoint в настройках webhook и проверьте, что в WooCommerce указан актуальный домен с HTTPS.
Сайт отвечает 301/302
Это бывает из-за принудительного редиректа с www на non-www, с http на https или из-за каноникал-редиректов. Для webhook нужен прямой ответ без лишней цепочки.
Подпись webhook не совпадает
Обычно причина в неверном signing secret или в том, что запрос изменяется по пути: прокси, кеш, WAF, нестандартная обработка тела запроса. Проверьте секрет именно для этого endpoint и не копируйте его из другого окружения.
Кеширующий плагин трогает технический URL
Иногда плагины кеша не должны работать на checkout, cart и технических endpoint'ах, но в реальности правила настроены слишком широко. Добавьте исключение для webhook-адреса и очистите кеш после изменения.
Что проверить для безопасности и стабильности
- Webhook должен быть только на HTTPS.
- Не открывайте endpoint шире, чем нужно: исключение должно касаться только технического URL.
- Не храните ключи Stripe в открытом коде темы.
- После обновления WooCommerce и платёжного плагина повторно проверьте webhook.
- Если используете staging, не смешивайте тестовые и боевые ключи.
Если проблема повторяется после каждого обновления, имеет смысл вынести диагностику в отдельный чек-лист для хостинга и CDN. В сложных магазинах это экономит время лучше, чем бесконечная переустановка плагина оплаты.
Для похожих задач по чистке конфликтов и дублей в WooCommerce иногда помогает аудит технических настроек сайта через Clearfy Pro, но только если проблема действительно в лишних редиректах, дублях и агрессивных оптимизациях, а не в самом Stripe.