Prodamus и WooCommerce: полная настройка интеграции и подводные камни

Подключить Prodamus к WooCommerce можно за двадцать минут — инструкция короткая, полей мало. А потом начинается интересное: платежи проходят, деньги приходят, но покупатель шестнадцать секунд смотрит на спиннер, в логах платёжки висит Operation timed out, а клиенту прилетает четыре письма вместо двух.

Ниже — полная настройка интеграции и разбор подводных камней, каждый из которых стоил мне отдельного вечера. Самый неочевидный из них лечится одной галочкой в карточке товара.

Что вообще происходит при оплате

Прежде чем нажимать на кнопки, стоит понять схему. Без неё диагностика превращается в гадание.

1. Покупатель оформляет заказ в WooCommerce и уходит на платёжную страницу Prodamus.
2. Платит картой или через СБП.
3. Prodamus отправляет на ваш сайт веб-хук — POST-запрос «оплата прошла». Это запрос с сервера на сервер, покупатель его не видит.
4. Плагин на сайте проверяет подпись, переводит заказ в оплаченный статус и отвечает кодом 200.
5. Параллельно покупатель попадает на страницу ожидания, которая опрашивает сайт, пока не увидит подтверждение, и только потом пускает его дальше.

Ключевой момент: пункты 3 и 5 — это две разные вещи. Веб-хук может отработать мгновенно, а покупатель всё равно будет ждать. И наоборот. Половина ложных диагнозов рождается из того, что эти два процесса путают.

Веб-хук отправляется POST-запросом. При успешной обработке сайт обязан ответить кодом 200 — иначе Prodamus будет повторять попытки, пока не достучится.

Шаг 1. Собираем данные в Prodamus

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

Адрес платёжной страницы

Вида https://вашмагазин.payform.ru/. Просто скопируйте из браузера.

Секретный ключ

И кстати, пока не отошел от кассы. У Prodamus работают 2 личных кабинета — старый и новый. Главное понять принцип настройки. А так кабинеты примерно похожи. Так что не удевляйтесь, если у вас кабинет продамуса фиолетового цвета

Канал продаж → раздел «Интеграции» → «Сгенерировать ключ» (новый кабинет).

Настройки → Секретный ключ (старый кабинет).

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

Шаг 2. Настраиваем URL для уведомлений

Это тот самый веб-хук, без которого заказы навсегда останутся в статусе «Ожидает оплаты». Откройте канал продаж → раздел «Уведомления».

1. Включите тумблер «Уведомления о разовых оплатах».
2. В поле «URL адреса для уведомлений» вставьте адрес (подставьте свой домен):

https://{домен_вашего_сайта}/?wc-api=wc_gateway_prodamusplugin

Например: https://school.example.ru/?wc-api=wc_gateway_prodamusplugin

3. Поставьте галочку «Заказ оплачен».
4. Сохраните.

Адрес нужно скопировать символ в символ. Никаких www, если сайт живёт без него, и обязательно https. Опечатка в этой строке даёт самый обидный баг интеграции: деньги списываются, а заказ висит неоплаченным, и понять почему без лога невозможно.

Подводный камень: Success URL и Fail URL

Чуть выше блока уведомлений есть раздел «Настройка адресов» с полями Success URL и Fail URL. Рука тянется вписать туда страницу «Спасибо за заказ».

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

Шаг 3. Ставим плагины

Сначала WooCommerce, если его ещё нет: Плагины → Добавить новый → поиск «WooCommerce» → установить и активировать.

Затем шлюз: Плагины → Добавить новый → поиск «Prodamus» → «Установить сейчас». Плагин называется Prodamus Gateway for WooCommerce. Его же можно поставить вручную — скачать архив с официальной страницы и загрузить через «Загрузить плагин». Для вашего удобства я уже его скачал. Скачивайте тут: плагин Prodamus Gateway for WooCommerce .

Шаг 4. Настраиваем шлюз в WooCommerce

WooCommerce → Настройки → вкладка «Платежи» → напротив Prodamus нажать «Править».

Поле	Что вписать
Включение/отключение	Галочка «Включить способ оплаты Prodamus»
Название	То, что увидит покупатель в списке способов оплаты
Описание	Короткая поясняющая строка под названием
URL платежной страницы	Адрес из шага 1
Секретный ключ	Ключ из шага 1
Тестовый режим	Включить на время проверки, выключить перед запуском
Группы методов оплаты	Оставить пустым, если не нужно ограничивать способы
Статус заказа после успешной оплаты	«Выполнен» для цифровых товаров
Таймаут ожидания на странице успеха	По умолчанию 300 секунд

В тестовом режиме оплата проходит только специальными тестовыми картами — список есть в справке Prodamus. Реальные деньги при этом не списываются.

Про поле «Таймаут ожидания на странице успеха» стоит сказать отдельно: это максимальное время, которое страница ожидания готова ждать подтверждения. Не интервал опроса и не задержка. Уменьшать его в надежде ускорить редирект бессмысленно — вы только сломаете сценарий для медленных платежей.

Шаг 5. Галочки в товаре — главный подводный камень

Вот это место, из-за которого пишется вся статья. Инструкция Prodamus про него не говорит ни слова, потому что это особенность WooCommerce, а не платёжки. Но именно оно ломает интеграцию тише всего.

В карточке товара, в блоке «Данные товара», есть две галочки: «Виртуальный» и «Скачиваемый».

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

Дальше происходит цепная реакция.

	Обе галочки стоят	«Скачиваемый» снят
Переходов статуса	1 (сразу «Выполнен»)	2 («Обработка» → «Выполнен»)
Писем отправлено	2	4
Прогонов хуков заказа	1	2
Время ответа на веб-хук	меньше секунды	до 10+ секунд

Почему писем становится вдвое больше, хотя настройки писем в WooCommerce не менялись? Потому что галочки в настройках писем не отправляют письма — они только разрешают их отправлять. Запускает отправку смена статуса заказа. Письмо «Заказ в обработке» привязано к статусу «Обработка»: если заказ через этот статус не проходит, письмо не уходит, хотя и включено.

Лишний статус — это лишнее письмо клиенту, лишний прогон всех обработчиков, а если на сайте стоит LMS или CRM — ещё и повторный запуск их логики. Всё это происходит внутри того самого запроса, на ответ которого Prodamus отводит десять секунд.

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

Как читать лог уведомлений

Это главный диагностический инструмент, и о нём почему-то мало кто знает.

Личный кабинет Prodamus → «Список платежей» → кликнуть на ID заказа → блок «URL-оповещения». Там история всех попыток отправки веб-хука с ссылками «запрос» и «ответ».

Как выглядит здоровая интеграция:

Заголовки ответа:
HTTP/1.1 200 OK
Date: Tue, 04 Aug 2026 13:04:13 GMT
Content-Type: application/json; charset=UTF-8

Тело ответа:
{"result":"ok","message":"ok"}

Как выглядит больная:

Код ответа: -
Заголовки ответа: -
Тело ответа: -
Operation timed out after 10001 milliseconds with 0 bytes received

0 bytes received означает, что соединение установилось, но сайт за десять секунд не отдал вообще ничего. Не «сайт недоступен» — а «сайт думает слишком долго».

Приём, который экономит часы

Сравните две метки времени: поле date в теле запроса и заголовок Date в ответе сервера. Только не забудьте, что Date отдаётся в GMT, а тело запроса — в вашем часовом поясе.

Если разница меньше секунды — ваш сайт ни при чём, оптимизировать нечего. Если несколько секунд — тормозит обработка на стороне WordPress, и надо искать, что именно съедает время.

Отдельно сравните время регистрации платежа (шапка страницы платежа) и время отправки веб-хука. Разрыв между ними — это задержка на стороне Prodamus, и повлиять на неё с сайта нельзя никак. По СБП такой разрыв бывает заметно больше, чем по карте: если у вас «долго крутится после оплаты», проведите один платёж картой и сравните.

Тестовая отправка без реальных денег

В настройках уведомлений справа от поля с URL есть кнопка 🔁. Она отправляет тестовый веб-хук: выбираете тип уведомления, жмёте «Отправить». Можно гонять сколько угодно раз, не оплачивая каждый прогон.

Повторить отправку по конкретному реальному платежу тоже можно: «Список платежей» → ID заказа → иконка 🗘 в блоке «URL-оповещения». После ручной отправки рядом с датой появляется иконка человечка — так отличают ручные попытки от автоматических.

Остальные подводные камни

Магазин в режиме «Скоро»

WooCommerce → Настройки → «Видимость сайта». Свежие установки часто стоят в режиме «Скоро» с галкой «Применить только к страницам магазина». В админ-баре при этом висит бейдж «Магазин скоро откроется».

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

Тестируйте только в инкогнито

Правило, которое стоит написать на стене. Под админом работает всё: и закрытый магазин, и заблокированная корзина, и форма без капчи. Любая проверка витрины — приватное окно, всегда.

Гостевое оформление и регистрация

Если магазин продаёт доступ к чему-то (курс, членство, личный кабинет), решите заранее, покупает гость или зарегистрированный пользователь. Тупик выглядит так: покупателю говорят «войдите», а зарегистрироваться негде, потому что регистрация выключена в трёх местах сразу.

Проверьте все точки:

• Настройки → Общие → «Любой может зарегистрироваться»
• WooCommerce → Аккаунты и приватность → гостевое оформление и создание аккаунта при оформлении
• Настройки самой LMS или плагина членства, если он есть — они перебивают настройки WooCommerce

Для LMS обычно правильнее второй сценарий: курс надо к кому-то привязать, а гостевая покупка это усложняет. Тогда включайте «создавать учётные записи во время оформления заказа» — аккаунт создастся автоматически, и доступ будет куда выдать.

И сразу ставьте капчу на регистрацию — открытая форма собирает ботов за считанные дни.

Миф про SMTP-плагин

Популярный совет при долгом ответе на веб-хук — «поставь SMTP-плагин». Он помогает, но не так, как думают.

SMTP-плагин заменяет функцию mail() на нормальную отправку через почтовый сервер. Он не делает отправку асинхронной: письма по-прежнему уходят внутри того же запроса, одно за другим, и каждое требует своего соединения. Если ваш SMTP-сервер отвечает за две секунды, четыре письма — это восемь секунд, плагин там или нет.

Правильный порядок действий: сначала сократить количество писем (см. галочки в товаре), потом уже разбираться со скоростью отправки. Замерить одно письмо просто — почти в любом SMTP-плагине есть кнопка тестовой отправки, засеките, сколько она выполняется.

Куда попадает покупатель после оплаты

Отдельного поля «редирект после оплаты» ни в WooCommerce, ни в плагине Prodamus нет. По умолчанию покупатель попадает на стандартную страницу «Заказ получен». Если он оказывается где-то ещё — значит, редирект прописан кодом: в теме, в сниппете или в плагине LMS.

Тут есть неустранимая гонка: редирект от платёжки может обогнать веб-хук. Отправлять покупателя сразу в личный кабинет — плохая идея: он увидит пустой кабинет с надписью «вы ещё никуда не записаны» и решит, что деньги пропали.

Надёжнее вести на «Заказ получен» с честным текстом: «Оплата принята, доступ откроется в личном кабинете в течение минуты» — и кнопкой в кабинет рядом.

Таблица диагностики

Симптом	Вероятная причина	Где смотреть
Деньги списались, заказ «Ожидает оплаты»	Неверный или невключённый URL уведомлений	Prodamus → Уведомления; лог по платежу
Operation timed out, 0 bytes received	Обработка на сайте дольше 10 секунд	Галочки товара, количество писем
Клиенту приходит 4 письма вместо 2	Заказ проходит через лишний статус «Обработка»	Карточка товара → «Скачиваемый»
Долго крутится спиннер после оплаты	Задержка отправки веб-хука на стороне Prodamus	Сравнить время платежа и время веб-хука
Покупатель не может добавить товар в корзину	Режим «Скоро» или требование входа	Видимость сайта; настройки LMS
После оплаты пустой личный кабинет	Редирект обогнал веб-хук	Код редиректа в теме или сниппете

Чек-лист перед запуском

• URL уведомлений вставлен, галочка «Заказ оплачен» стоит, тумблер включён
• Success URL и Fail URL пустые
• Секретный ключ сохранён в надёжном месте
• Тестовый режим выключен
• У всех цифровых товаров стоят обе галочки — «Виртуальный» и «Скачиваемый»
• Видимость сайта — «Публичный»
• Проведена реальная оплата на минимальную сумму из окна инкогнито
• В логе Prodamus по этому платежу — код 200 и {"result":"ok"}
• Заказ автоматически стал «Выполнен», клиенту ушло 2 письма
• Тестовые заказы удалены, чтобы не портить статистику

Коротко

Настройка Prodamus в WooCommerce — это четыре поля и один URL. Проблемы начинаются не в настройках платёжки, а в том, как WooCommerce обрабатывает заказ после оплаты.

Если запомнить из статьи одну вещь, пусть это будет галочка «Скачиваемый» в карточке цифрового товара. Она выглядит бессмысленной, когда скачивать нечего, — и именно поэтому её снимают. А потом ловят таймауты веб-хука, лишние письма клиентам и двойной прогон всей логики заказа.

Второе по важности — научиться читать лог уведомлений и сравнивать в нём метки времени. Это ровно та цифра, которая отличает «тормозит мой сайт» от «тормозит платёжка», и она экономит вечера отладки не в ту сторону.

И еще один момент ниже. Иначе все будет работать через жопу.

Своя страница оформления заказа

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

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

Почему фильтр «не работает»

Поля чекаута убираются фильтром woocommerce_checkout_fields — это классический способ, он описан в сотне статей. Вы добавляете сниппет, чистите кэш, обновляете страницу — и ничего не меняется.

Причина в том, что новые установки WooCommerce используют блочную страницу оформления заказа — блок «Оформление заказа» вместо старого шорткода. Блок берёт поля из собственной схемы, а не из PHP-массива, и фильтр woocommerce_checkout_fields на него попросту не действует. Сниппет исправен, применять его не к чему.

Решение — вернуться к классическому чекауту на шорткоде.

Создаём страницу

1. Страницы → Добавить новую. Название — «Оформление заказа».
2. В тело страницы вставьте единственный шорткод, больше ничего:

[woocommerce_checkout]

3. Опубликуйте.
4. WooCommerce → Настройки → вкладка «Дополнительно» → поле «Страница оформления заказа» → выберите созданную страницу. Сохраните.

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

Добавляем сниппет

Код кладём в менеджер сниппетов (WPCodeBox2, Code Snippets) или в functions.php дочерней темы. В functions.php родительской темы — нельзя, обновление темы его сотрёт.

add_filter('woocommerce_checkout_fields', function ($fields) {
    unset($fields['billing']['billing_company']);
    unset($fields['billing']['billing_country']);
    unset($fields['billing']['billing_address_1']);
    unset($fields['billing']['billing_address_2']);
    unset($fields['billing']['billing_city']);
    unset($fields['billing']['billing_state']);
    unset($fields['billing']['billing_postcode']);
    unset($fields['billing']['billing_last_name']);

    $fields['billing']['billing_first_name']['label'] = 'Имя';
    $fields['billing']['billing_first_name']['required'] = true;
    $fields['billing']['billing_first_name']['class'] = ['form-row-wide'];

    $fields['billing']['billing_email']['required'] = true;
    $fields['billing']['billing_email']['class'] = ['form-row-wide'];

    $fields['billing']['billing_phone']['required'] = true;
    $fields['billing']['billing_phone']['class'] = ['form-row-wide'];

    return $fields;
});

Что он делает: вычищает компанию, страну, обе строки адреса, город, область, индекс и фамилию. Остаются три поля — Имя, Email, Телефон. Все три помечаются обязательными и растягиваются на всю ширину формы через класс form-row-wide, чтобы не висели половинками.

Что нельзя удалять

Email и телефон. Рука тянется убрать телефон — «зачем он для курса». Но Prodamus передаёт оба поля в платёж: в теле веб-хука приходят customer_email и customer_phone, по ним же формируется чек и уходит уведомление покупателю. Уберёте — сломаете фискализацию и оставите себя без контактов клиента.

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

После настройки

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