Приём платежей в WordPress без WooCommerce: рабочие схемы

Если на сайте нужно продать один курс, консультацию или доступ к файлу, WooCommerce часто превращает простую оплату в отдельный интернет-магазин. Для такого сценария достаточно платёжной страницы, заказа с понятным статусом и обработчика уведомлений. Ниже — три рабочих подхода для WordPress 6.x: от ссылки на оплату до собственной связки с API, с ценой каждого решения и ошибками, которые обычно обнаруживаются уже после первого платежа.

Сначала отделите оплату от магазина

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

У минимальной схемы есть четыре независимых объекта:

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

Главная практическая ошибка — считать переход клиента на страницу «спасибо» подтверждением оплаты. Пользователь может закрыть вкладку, открыть старую ссылку или попасть на эту страницу напрямую. Источником истины должен быть подтверждённый статус от платёжного провайдера, полученный через серверное уведомление или проверку по API.

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

Идемпотентность — свойство операции, при котором повторный одинаковый запрос не создаёт второй заказ или второй платёж. Для оплаты это защита от двойного клика, повторной отправки формы и сетевого тайм-аута.

Три схемы без WooCommerce

Подход 1. Платёжная ссылка для простого продукта

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

Что выигрывает владелец сайта

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

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

Не вставляйте в URL сумму, email и идентификатор заказа без проверки на сервере. Пользователь может изменить параметры ссылки. Для фиксированной цены безопаснее использовать ссылку, созданную в кабинете провайдера, а не собирать платёжный URL самостоятельно.

Подход 2. Отдельный платёжный плагин

Некоторые провайдеры выпускают плагины для WordPress, которые работают без WooCommerce или добавляют короткий код, блок редактора и обработку уведомлений. Это компромисс между готовой ссылкой и собственной разработкой.

Что проверить до установки

1. Совместимость с WordPress 6.x и PHP. Смотрите не только заявленную версию, но и дату последнего обновления.
2. Режим уведомлений. Плагин должен уметь принимать серверные уведомления, а не менять заказ только после возврата клиента на сайт.
3. Тестовые платежи. У провайдера должен быть тестовый режим или понятная процедура отмены тестовой операции.
4. Повторная доставка уведомления. Если ваш сервер временно недоступен, провайдер должен повторить запрос либо дать возможность запросить статус вручную.
5. Логи без секретов. В журнале не должны сохраняться ключи API, полные платёжные реквизиты и персональные данные сверх необходимого.

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

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

Подход 3. Собственная связка с API

Собственная интеграция нужна, когда после оплаты должен запуститься определённый процесс: выдать одноразовую ссылку, открыть урок, записать клиента в CRM или зафиксировать доступ на срок. Для примера можно ориентироваться на модель API платёжного провайдера вроде YooKassa: сайт создаёт платёж, получает URL подтверждения, а затем принимает уведомление о смене статуса. Конкретные поля и требования зависят от провайдера и должны сверяться с его документацией.

Минимальный жизненный цикл заказа

1. Создайте внутренний заказ. Сохраните товар, цену в минимальных единицах валюты, email, случайный идентификатор и статус pending. Сумму берите из серверной конфигурации, а не из скрытого поля формы.
2. Создайте платёж у провайдера. Передайте внешний номер заказа, сумму и URL возврата. Для повторного запроса используйте один и тот же ключ идемпотентности.
3. Перенаправьте клиента. Сайт должен отправить пользователя на страницу провайдера, не показывая ему секретные ключи и внутренние параметры API.
4. Примите webhook. Найдите заказ по вашему идентификатору, проверьте подлинность уведомления или запросите актуальный статус через API. Не доверяйте одной сумме из входящего запроса.
5. Измените статус один раз. Только переход из ожидающего состояния в подтверждённое должен запускать выдачу товара. Повторное уведомление не должно отправить файл или письмо повторно.
6. Обработайте возврат и отмену. Это отдельные состояния, а не удаление заказа. Сохраняйте дату, сумму и внешний идентификатор операции.

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

Что ломается первым

Двойной платёж после двойного клика

Кнопка блокируется только в браузере, но пользователь может повторить запрос после тайм-аута. Защита должна быть на сервере: один внутренний заказ — один ключ идемпотентности — один платёж. Перед созданием новой операции найдите незавершённый платёж по вашему идентификатору.

Оплата есть, а доступ не выдан

Обычно webhook не дошёл до сайта, был заблокирован защитным плагином или обработчик вернул ошибку. Оставьте журнал событий с временем, HTTP-кодом и внутренним номером заказа, но без секретов. Нужна и ручная команда повторной проверки статуса по идентификатору.

Страница «спасибо» выдаёт товар бесплатно

Страница возврата должна только показать результат проверки. Она не должна сама переводить заказ в оплаченный статус. Выдача запускается после серверного уведомления или после отдельной проверки статуса у провайдера.

Кэш возвращает старый статус

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

Обновление WordPress ломает форму

Перед обновлением делайте резервную копию базы и файлов, проверяйте платёж в тестовом режиме и фиксируйте версии WordPress, PHP и плагина. Не обновляйте платёжный компонент впервые прямо в день рекламной рассылки.

Когда что выбирать

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

Не пытайтесь сразу повторить весь WooCommerce. Сначала опишите состояния pending, paid, failed и refunded, события для перехода между ними и действие после каждого перехода. Инвалидация доступа, рекуррентные платежи и полноценная корзина — отдельные задачи, их не стоит прятать в первую кнопку оплаты.

Что сделать дальше

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