Приём платежей без WooCommerce: настройка с первого раза

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

Что должно получиться

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

Инструкция рассчитана на WordPress 6.x и обычный виртуальный хостинг с HTTPS. Точные названия пунктов меню зависят от выбранного провайдера и его модуля для WordPress.

Что подготовить до начала

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

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

Оплата считается подтверждённой не тогда, когда клиент вернулся на страницу «Спасибо», а тогда, когда платёжный сервис сообщил серверу о результате операции.

Пошаговая настройка

1. Выберите схему без корзины

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

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

Проверка: вы можете одним предложением описать, что происходит после нажатия кнопки и где хранится идентификатор заказа.

2. Создайте товар и статусы заказа

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

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

Проверка: для каждого заказа понятно, какую услугу купили, сколько должны заплатить и что делать после каждого результата оплаты.

3. Подключите официальный модуль или платёжную страницу

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

Ключи для тестового и рабочего окружения должны быть разными. Секретный ключ нельзя вставлять в текст страницы, JavaScript, тему или публичный репозиторий. Храните его в настройках модуля, если провайдер это поддерживает, и ограничьте доступ администраторами.

Проверка: кнопка оплаты открывает адрес провайдера по HTTPS, а в настройках не осталось тестового режима или тестовых ключей.

4. Настройте форму и страницу результата

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

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

Проверка: после тестового перехода клиент видит понятный следующий шаг, а отменённая операция не выглядит как оплаченная.

5. Подключите уведомления о платеже

Найдите в кабинете провайдера раздел уведомлений, webhook или callback и укажите адрес, который рекомендует его документация. Не придумывайте путь самостоятельно: разные модули WordPress обрабатывают уведомления по-разному.

Обработчик должен проверять подпись уведомления, идентификатор операции, сумму, валюту и принадлежность заказа вашему сайту. Повторное уведомление не должно повторно выдавать товар или запускать вторую отправку письма. Это называется идемпотентностью^[1].

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

Проверка: тестовая операция меняет статус заказа на «оплачен» даже после закрытия страницы оплаты и возвращения на сайт с другого устройства.

6. Проведите тесты до публикации

1. Откройте страницу в режиме инкогнито и проверьте, что цена и описание совпадают с предложением.
2. Выполните успешную тестовую оплату в тестовом окружении провайдера.
3. Отмените оплату и убедитесь, что заказ не получил статус «оплачен».
4. Перезагрузите страницу результата несколько раз и проверьте, что действие не выполняется повторно.
5. Проверьте уведомление о платеже в кабинете провайдера и запись в WordPress.
6. Сделайте рабочую оплату на небольшую сумму только после проверки тестового сценария и переключения ключей.

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

Что чаще всего ломается

«Оплата прошла, но заказ остался неоплаченным»

Обычно клиент вернулся на сайт, но сервер не получил уведомление. Проверьте URL callback, HTTPS, журнал запросов и блокировки со стороны хостинга. Не переводите такие заказы в оплаченные автоматически по словам клиента и не ориентируйтесь только на страницу «Спасибо».

«Кнопка ведёт на ошибку или пустую страницу»

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

«Письмо отправилось дважды»

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

«После обновления WordPress всё перестало работать»

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

Где схема без WooCommerce подходит плохо

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

В этот момент экономия на WooCommerce превращается в поддержку нескольких разрозненных систем: формы, платежей, писем, доступа и заказов. Сам платёжный провайдер не заменяет каталог и учёт.

Что настроить дальше

После запуска поставьте в мониторинг три события: долю заказов, которые не получили подтверждение, задержку между оплатой и выдачей результата и количество повторных уведомлений. Раз в месяц проверяйте рабочую оплату и состояние SSL-сертификата. Отдельно обновляйте WordPress и платёжный модуль после чтения совместимости, а не сразу после выхода новой версии.

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

^[1] Идемпотентность — свойство операции, при котором повторная обработка одного и того же уведомления не создаёт второй заказ, вторую выдачу товара или повторный возврат.