Подключить онлайн-оплату к WooCommerce можно готовым расширением или собственной интеграцией с API банка, эквайринга или платёжного сервиса. Но технически надёжная оплата — это не один запрос на списание денег.
Нужно согласовать checkout, создание заказа, переход на сторону провайдера, подтверждение платежа, callbacks или webhooks, повторные уведомления и статусы WooCommerce. Ошибка в этой цепочке может оставить оплаченный заказ в ожидании или, наоборот, отметить неоплаченный как завершённый.
Какие варианты платежных шлюзов поддерживает WooCommerce
В официальной документации WooCommerce выделяются form-based, iframe, direct и offline gateways. При form-based схеме покупатель переходит на страницу платёжного сервиса. При iframe платёжная форма загружается внутри магазина. Direct gateway принимает поля оплаты непосредственно на checkout, а offline не выполняет онлайн-платёж.
Для бизнеса выбор влияет не только на внешний вид. Чем больше платёжных данных обрабатывается непосредственно на сайте, тем выше требования к безопасности. WooCommerce отдельно отмечает, что direct gateways требуют защищённого сервера, SSL и могут затрагивать требования PCI.
Правильная архитектура: заказ и платёж — разные состояния
Одна из самых частых ошибок в кастомной интеграции — считать успешный редирект клиента доказательством оплаты. Пользователь может закрыть вкладку, потерять соединение или вообще не вернуться на сайт после страницы банка.
Поэтому финальный статус заказа должен опираться на подтверждение платёжного провайдера: callback, IPN или webhook. Возврат покупателя на thank-you page полезен для интерфейса, но не должен быть единственным источником истины.
Что должен делать payment flow
- WooCommerce создаёт заказ и получает его ID.
- Платёжный модуль формирует запрос провайдеру и передаёт сумму, валюту, идентификатор заказа и необходимые параметры.
- Покупатель проходит оплату по выбранной схеме.
- Провайдер отправляет серверное подтверждение на callback/webhook endpoint.
- Интеграция проверяет подпись, идентификатор операции, сумму и соответствие заказу.
- Только после подтверждения заказ переводится в оплаченный статус.
В WooCommerce для успешно оплаченного заказа рекомендуется использовать $order->payment_complete(), а не вручную выставлять случайный статус. Документация указывает, что этот механизм корректно связывает оплату со статусами и обработкой остатков.
Почему callbacks и webhooks должны быть идемпотентными
Платёжный сервис может отправить одно и то же уведомление повторно. Это нормальный механизм надёжной доставки, а не обязательно ошибка. Поэтому обработчик должен безопасно принять повтор и не выполнять критическое действие второй раз.
Практически это означает: хранить ID платёжной операции, проверять текущий статус заказа и не повторять уже подтверждённый переход. Если интеграция дополнительно отправляет данные в CRM, склад или уведомления, эти действия тоже лучше защищать стабильным ключом операции.
Проверка подлинности webhook
Встроенные webhooks WooCommerce могут использовать secret для формирования HMAC-SHA256 подписи тела запроса. На стороне получателя подпись следует проверять до обработки данных. Аналогичный принцип используется и у многих платёжных API: серверное уведомление нельзя принимать на доверии только потому, что в JSON указан правильный номер заказа.
Для кастомной интеграции нужно придерживаться конкретной схемы подписи, которую задаёт платёжный провайдер, а секреты хранить вне публичного кода и логов.
Какие статусы заказов учитывать
Статус зависит от типа оплаты и бизнес-логики. Если платёж подтверждён, WooCommerce сам определит подходящее состояние через payment_complete(). Если операция не прошла после создания заказа, может использоваться Failed. Если требуется ручная проверка, подходит On-Hold.
Главное — не строить собственную таблицу статусов поверх WooCommerce без необходимости. Чем меньше нестандартных переходов, тем проще совместимость с письмами, складом, аналитикой и сторонними плагинами.
Что обязательно тестировать до запуска
| Сценарий | Что проверить |
|---|---|
| Успешная оплата | Заказ оплачен один раз, transaction ID сохранён, статус корректный |
| Отказ банка | Покупатель получает понятное сообщение, заказ не отмечается оплаченным |
| Закрытие вкладки | Серверный callback всё равно способен завершить заказ |
| Повторный webhook | Нет двойной обработки и повторных бизнес-действий |
| Неверная подпись | Уведомление отклоняется и фиксируется в логах |
| Недоступный сайт | Повторная доставка не ломает состояние заказа |
| Несовпадение суммы | Заказ не подтверждается автоматически |
Логи нужны до первого реального сбоя
WooCommerce сохраняет delivery logs для собственных webhooks, включая URL, метод, заголовки, тело, код ответа и длительность запроса. В кастомной платёжной интеграции нужен аналогичный диагностический след, но без записи секретов и полных платёжных данных.
Минимально полезно фиксировать order ID, transaction ID, тип события, время, результат проверки подписи и итог обработчика. Тогда спорный заказ можно разобрать по фактам, а не гадать по статусу в админке.
Готовый плагин или собственная интеграция
Если провайдер имеет актуальный официальный плагин для WooCommerce, чаще всего разумно начать с него. Собственная разработка нужна, когда банк или сервис не имеет подходящего расширения, требуется нестандартная схема, несколько мерчантов, дополнительная маршрутизация, особые статусы или интеграция оплаты с CRM и другими системами.
Кастомный шлюз лучше оформлять отдельным WordPress-плагином, а не добавлять платёжный код в тему. WooCommerce также описывает payment gateway как отдельный plugin-class, расширяющий WC_Payment_Gateway. Это упрощает обновления темы, тестирование и поддержку.
A.S Groups занимается разработкой и доработкой WooCommerce, а для нестандартной логики можно использовать отдельный WordPress-плагин.
Если оплату нужно связать с CRM или внешним API
После подтверждения платежа часто требуется передать заказ в CRM, сервис доставки, учётную систему или внутренний backend. Здесь важно не смешивать обработчик платежа со всей бизнес-логикой.
Надёжнее разделить этапы: платёж подтверждает заказ, затем отдельный обработчик ставит внешнюю синхронизацию в очередь или выполняет повторяемый idempotent request. Похожий подход используется при интеграции WordPress с CRM, REST API и webhooks.
Чек-лист подключения онлайн-оплаты
- определить redirect, iframe или direct flow;
- использовать HTTPS и требования провайдера по безопасности;
- создавать заказ до перехода на оплату;
- не считать browser redirect подтверждением платежа;
- проверять серверный callback/webhook;
- валидировать подпись, сумму, валюту и order ID;
- использовать
payment_complete()после подтверждения; - защитить повторные callbacks от двойной обработки;
- сохранять transaction ID;
- настроить диагностические логи без секретов;
- протестировать success, fail, timeout и повтор webhook;
- проверить письма, остатки и сторонние интеграции после смены статуса.
Частые вопросы
Можно ли подключить любой банк к WooCommerce?
Если банк или платёжный сервис предоставляет подходящий API и разрешает интернет-эквайринг для вашего мерчанта, техническую интеграцию обычно можно реализовать. Конкретная схема зависит от документации провайдера.
Почему заказ иногда остаётся Pending после успешной оплаты?
Частая причина — сайт не получил или неправильно обработал серверное уведомление провайдера. Нужно проверять callback/webhook, подпись, логи и связь transaction ID с заказом.
Нужно ли хранить данные банковской карты в WordPress?
Обычно нет. Предпочтительнее использовать токены или hosted payment UI провайдера. Для direct gateway требования к безопасности существенно выше.
Почему webhook приходит несколько раз?
Повторная доставка используется для надёжности. Обработчик должен быть идемпотентным и безопасно распознавать уже обработанную операцию.
Можно ли после оплаты сразу отправлять заказ в CRM?
Да, но лучше отделить подтверждение платежа от внешней синхронизации и предусмотреть повтор запроса без дублей.
Что получает бизнес от корректной интеграции
Хорошо подключённая оплата не требует ручного сравнения банковских операций с заказами при каждом нестандартном сценарии. Состояние заказа формируется из проверяемого события провайдера, повторные уведомления не создают дублей, а логи позволяют быстро найти место сбоя.
Если нужно подключить эквайринг, заменить старый платёжный модуль или связать оплату с внешней системой, можно описать текущий checkout и API через контакты A.S Groups.
Обсуждение
Вопросы и комментарии
Можно уточнить детали статьи или поделиться своим опытом. Первый комментарий проходит проверку.