Условные способы оплаты WooCommerce по правилам

Стандартный WooCommerce показывает покупателю все доступные payment gateways, которые подходят текущей конфигурации магазина.

Но в реальном бизнесе способы оплаты часто зависят от условий заказа.

Например:

наложенный платёж разрешён только для курьерской доставки;
оплата при получении запрещена для дорогих товаров;
банковский перевод доступен только B2B-клиентам;
определённый gateway работает только в одной стране;
для цифрового товара нельзя использовать cash on delivery;
для конкретной категории разрешена только предоплата.

Такие правила лучше реализовывать централизованно, а не набором случайных snippets вокруг checkout.

Какие условия можно использовать

WooCommerce даёт достаточно данных, чтобы строить payment rules практически под любой business process.

Категория товара

Например, для категории «Индивидуальное производство» можно оставить только онлайн-оплату или банковский перевод.

Сумма корзины

Наложенный платёж доступен до 30 000 ₽, а выше — только предоплата.

Способ доставки

Cash on delivery можно показывать только для local pickup или конкретной courier method.

Страна и регион

Некоторые gateways доступны только для определённых стран, валют или billing regions.

Роль пользователя

B2B-клиенту можно дать invoice/bank transfer, а обычному покупателю оставить cards и СБП.

Тип товара

Для virtual/downloadable products можно отключить способы оплаты, рассчитанные на физическую доставку.

Наличие конкретного товара

Если в корзине есть определённый SKU или product type, можно изменить набор gateways.

Как работает логика checkout

CartСобираем состав корзины и totals
CustomerОпределяем роль, billing country и другие данные
ShippingПолучаем выбранный способ доставки
RulesПрименяем payment conditions
Available gatewaysПоказываем только разрешённые способы оплаты
Server validationПовторно проверяем правило при создании заказа

Почему скрыть кнопку JavaScript недостаточно

Самая частая ошибка — спрятать ненужный способ оплаты только на фронтенде.

Это визуально работает, но не гарантирует безопасность business rule.

Пользователь может:

изменить request;
повторить старый checkout request;
вызвать endpoint напрямую;
попасть в race condition после изменения корзины.

Поэтому правило должно применяться на сервере через доступные payment gateways и дополнительно проверяться перед созданием/оплатой заказа.

Правило по категории

Пример:

обычные товары — все способы оплаты;
товары категории «Под заказ» — только карта и банковский перевод;
наложенный платёж скрыт.

Важно заранее определить, что делать со смешанной корзиной.

Если один товар разрешает cash on delivery, а второй запрещает, обычно безопаснее применять более строгое правило ко всей корзине.

Правило по сумме

Популярный сценарий:

если total > 30000:
    скрыть cash_on_delivery

Но нужно решить, какая именно сумма участвует:

subtotal;
total после скидок;
total с доставкой;
total с налогом;
только стоимость определённой категории.

Если это не определить, разные части checkout могут давать неожиданный результат.

Правило по доставке

Payment method часто логически связан со shipping method.

Например:

самовывоз — можно платить наличными;
курьер — карта или наличные;
международная доставка — только online payment;
транспортная компания — банковский перевод.

При переключении доставки checkout должен сразу пересчитать gateways.

Правило по стране

Некоторые способы оплаты доступны только для конкретного рынка.

Можно учитывать:

billing country;
shipping country;
state/region;
currency.

Важно понимать, какой адрес является юридически значимым именно для вашего payment provider.

Правило по роли пользователя

Для B2B-магазина это один из самых полезных сценариев.

Например:

Роль	Доступные способы
Guest	Карта
Customer	Карта, СБП
Wholesale	Банковский перевод, счёт
VIP	Карта, счёт, оплата при получении

Так можно связать payment policy с договорными условиями клиента.

Гость и авторизованный пользователь

До login роль неизвестна или равна guest.

Если пользователь авторизуется прямо во время checkout, gateway list нужно пересчитать.

Это ещё одна причина не хранить набор способов оплаты статически при первой загрузке страницы.

Условия по конкретному товару

Иногда правило связано не с категорией, а с отдельным product flag.

Например custom field:

requires_prepayment = yes

Если такой товар находится в корзине, COD скрывается.

Это удобно, когда бизнес-условие не совпадает с taxonomy каталога.

Условия для вариаций

У variable product разные variations могут иметь разные правила.

Например:

товар со склада — можно оплатить при получении;
кастомная вариация — только предоплата.

Тогда проверять только parent product недостаточно.

Комбинация нескольких условий

В реальном проекте правило часто выглядит так:

если:
  страна = RU
  и доставка = courier
  и total < 20000
  и в корзине нет категории "Под заказ"
то:
  разрешить COD

Такие правила лучше описывать в одном месте, а не разбрасывать по нескольким hooks.

Приоритет правил

Если правил много, может возникнуть конфликт.

Например:

роль VIP разрешает COD;
категория товара запрещает COD.

Нужно заранее определить priority.

Обычно security/business restriction должна иметь приоритет над permission:

deny > allow

То есть наличие запрещающего условия убирает gateway независимо от других разрешений.

Как менеджеру менять правила без кода

Если conditions часто меняются, их можно вынести в admin UI.

Например:

gateway;
условие;
operator;
value;
priority;
enabled.

Для небольшого магазина достаточно конфигурации в коде. Для крупного каталога удобнее управляемая система.

Производительность checkout

Payment filter вызывается часто во время AJAX refresh checkout.

Поэтому нельзя каждый раз делать тяжёлые запросы по всем товарам и taxonomy.

Лучше:

использовать уже загруженные cart items;
не делать внешние API requests внутри gateway filter;
кэшировать статические правила;
не запускать сложный SQL на каждый refresh.

Blocks Checkout и Classic Checkout

Современный WooCommerce может использовать Checkout Block или classic checkout.

Business rule должна работать на backend независимо от UI.

Но frontend refresh и отображение ошибок могут отличаться.

После реализации нужно проверить именно тот checkout, который работает на production.

Что делать, если выбранный gateway стал недоступен

Например, пользователь выбрал COD, затем добавил товар категории «Под заказ».

Checkout должен:

пересчитать available gateways;
снять недоступный выбранный method;
предложить оставшиеся варианты;
не создавать order со старым запрещённым gateway.

Связь с доставкой

Payment и shipping rules часто лучше проектировать вместе.

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

Мы отдельно разбирали условия доставки WooCommerce.

Логи для спорных заказов

Если правило влияет на деньги, полезно сохранять причину выбора.

Например order note:

COD unavailable: cart contains made-to-order item

Это помогает менеджеру понять, почему клиент не видел определённый gateway.

Payment gateway plugin тоже может иметь свои ограничения

Ваш код не должен насильно показывать gateway, который сам provider считает недоступным.

Лучше фильтровать уже доступный список WooCommerce, а не создавать gateway вручную поверх internal validation plugin.

Что определить до разработки

Какие gateways участвуют в правилах.
Какие условия нужны: категория, сумма, страна, роль, доставка.
Что делать со смешанной корзиной.
Какой приоритет у конфликтующих правил.
Работает ли Checkout Block или classic checkout.
Нужно ли admin UI для менеджера.
Нужны ли логи причины скрытия.
Есть ли B2B-роли и индивидуальные условия.
Как правила проверяются сервером.

Когда достаточно готового plugin

Для простого условия «скрыть COD при total выше X» готового plugin часто достаточно.

Кастомная разработка нужна, когда:

правил много;
есть несколько ролей;
условия зависят от конкретных товаров/variations;
shipping и payment связаны;
есть B2B-процесс;
нужна интеграция с CRM;
важен строгий server-side контроль.

Доработка способов оплаты WooCommerce

Я дорабатываю WooCommerce под нестандартные checkout-процессы: payment rules, shipping conditions, custom statuses, роли клиентов, B2B и интеграции с внешними системами.

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

Подробнее: разработка и доработка WooCommerce. Для общего изменения оформления заказа также есть материал «Доработка Checkout WooCommerce под бизнес».

Следующий шаг