WooCommerce не принимает оплату после перехода на HTTPS: как найти и исправить проблему

Сценарий типичный: сайт уже открывается по HTTPS, корзина работает, а на этапе оплаты WooCommerce начинает вести себя странно — кнопка не отправляет форму, платежный шлюз возвращает ошибку, а в консоли браузера появляются сообщения о mixed content или blocked request. В таких случаях проблема редко находится в самом плагине оплаты. Чаще ломается связка из URL сайта, редиректов, кэша, сертификата и настроек конкретного шлюза.

Ниже — рабочий порядок проверки, который помогает не гадать, а быстро сузить причину. Подходит для магазинов на WooCommerce, где HTTPS уже включили, но checkout или callback от платежной системы перестали работать.

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

После перевода магазина на HTTPS обычно всплывает один из нескольких симптомов:

• страница оформления заказа открывается, но после нажатия на кнопку оплаты ничего не происходит;
• платежный шлюз пишет об ошибке подписи, неверном URL возврата или недоступном callback;
• в браузере видно mixed content: часть скриптов или изображений грузится по HTTP;
• после оплаты клиент не возвращается на сайт, а заказ остается в статусе pending payment или failed;
• в логах WooCommerce появляются ошибки от платежного плагина, но без явной причины.

Что проверить первым делом

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

• адрес сайта в Настройки → Общие должен быть с https://;
• все страницы магазина должны открываться без редирект-цепочек и без смешанного контента;
• сертификат должен быть валидным для основного домена и, если используется, для www;
• платежный шлюз должен быть настроен на актуальные URL возврата и уведомлений;
• кэш плагина, CDN и серверный кэш не должны отдавать старые HTTP-версии страниц.

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

1. Проверьте адреса WordPress и WooCommerce

Если в базе остались старые HTTP-адреса, WooCommerce может генерировать ссылки на оплату и возврат с неправильной схемой. Сначала проверьте значения home и siteurl. Если доступ есть только через админку, откройте Настройки → Общие и убедитесь, что оба адреса начинаются с https://.

Если нужно быстро проверить через код, можно временно вывести значения в functions.php или в mu-plugin:

<?php
add_action('admin_notices', function () {
    if (! current_user_can('manage_options')) {
        return;
    }

    echo '<div class="notice notice-info"><p>home: ' . esc_html(home_url()) . '<br>siteurl: ' . esc_html(site_url()) . '</p></div>';
});

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

2. Найдите mixed content на checkout

Даже один скрипт по HTTP может ломать отправку формы оплаты. Откройте страницу оформления заказа в браузере, затем:

• посмотрите вкладку Console в DevTools;
• проверьте вкладку Network на запросы с http://;
• обратите внимание на CSS, JS, изображения и iframe от платежного провайдера.

Если проблема в старых ссылках внутри контента или настроек темы, их нужно заменить на HTTPS. Для массовой замены в базе данных используйте только инструменты, которые умеют корректно работать с сериализованными данными. Простой поиск и замена в SQL здесь опасен.

Пример безопасной замены через WP-CLI, если у вас есть доступ к консоли:

wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --all-tables

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

3. Сбросьте кэш и пересоберите правила редиректов

После перехода на HTTPS старый кэш часто продолжает отдавать HTTP-версии страниц, а платежный шлюз получает не тот callback URL. Очистите:

• кэш плагина;
• кэш на сервере, если он есть;
• CDN-кэш;
• кэш браузера для теста в режиме инкогнито.

Если используется редирект с HTTP на HTTPS, проверьте, что он один, а не цепочка из двух-трех переходов. Длинные цепочки иногда ломают возврат с платежной страницы или проверку подписи.

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

У разных провайдеров свои требования к URL уведомлений и возврата. После смены схемы на HTTPS часто нужно заново сохранить настройки в кабинете платежной системы или в WooCommerce-плагине. Ищите поля вроде:

• Return URL;
• Callback URL;
• Webhook URL;
• Success URL;
• Fail URL.

Если провайдер хранит адреса на своей стороне, старый HTTP-адрес там может остаться даже после обновления настроек в WordPress. Это особенно заметно, когда заказ создается, но статус не меняется после оплаты.

5. Проверьте, не блокирует ли сервер входящие callback-запросы

Иногда платежи не проходят не из-за WooCommerce, а из-за защиты на сервере: WAF, mod_security, правила в Cloudflare или плагин безопасности режут POST-запросы от шлюза. В этом случае в логах может быть пусто, а на стороне провайдера видно, что уведомление не доставлено.

Для проверки временно:

• отключите агрессивные правила защиты только на время теста;
• добавьте whitelist для IP или URL уведомления, если провайдер это рекомендует;
• посмотрите access log и error log веб-сервера;
• сравните, доходит ли запрос до WordPress.

Сравнение подходов: что делать быстрее и безопаснее

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

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

1. Откройте сайт в режиме инкогнито и убедитесь, что в адресной строке сразу HTTPS.
2. Добавьте товар в корзину и перейдите к оформлению заказа.
3. Проверьте консоль браузера: не должно быть ошибок mixed content и заблокированных запросов.
4. Создайте тестовый заказ через реальный платежный сценарий или тестовый режим шлюза.
5. Убедитесь, что заказ меняет статус после callback или возврата с платежной страницы.
6. Проверьте, что письма и страницы thank you открываются без редиректов и ошибок.

Если у платежного плагина есть журнал событий, откройте его и сравните время отправки запроса, ответ сервера и статус заказа. Это самый быстрый способ понять, на каком этапе цепочка еще ломается.

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

Оставили старый HTTP в базе

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

Сделали два редиректа подряд

Например, сначала HTTP → www, потом www → HTTPS. Для обычного пользователя это незаметно, а платежный шлюз может считать URL нестабильным. Лучше привести схему к одному понятному правилу.

Не обновили callback в кабинете платежной системы

В WordPress все выглядит правильно, но провайдер продолжает слать уведомления на старый адрес. После смены домена или схемы проверьте настройки не только в админке магазина, но и в личном кабинете платежного сервиса.

Кэширует не только WordPress

Если на сервере есть Nginx FastCGI cache, Cloudflare или другой CDN, очистка только в админке WooCommerce не поможет. Старые страницы могут продолжать отдавать HTTP-ссылки или старые формы оплаты.

Плагин безопасности режет webhook

Иногда защита от брутфорса или WAF блокирует входящие запросы от платежной системы. В таких случаях нужно не отключать безопасность навсегда, а точечно разрешить нужный endpoint и проверить логи блокировок.

Практические советы по безопасности и производительности

После перехода на HTTPS не стоит оставлять магазин в режиме постоянной отладки. Лучше:

• сделать резервную копию перед массовой заменой URL;
• не использовать ручной SQL для замены HTTP на HTTPS в сериализованных данных;
• проверить, что сертификат обновляется автоматически;
• не держать включенным debug log на боевом сайте дольше, чем нужно для диагностики;
• после исправления очистить временные логи и тестовые заказы, если они не нужны;
• проверить, что платежный шлюз использует актуальные версии API и не требует старых callback-адресов.

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

Когда причина найдена, возвращайте изменения по одному и каждый раз повторяйте тест оплаты. Это скучно, но именно так видно, что сломало checkout: редирект, кэш, callback или смешанный контент.