Динамические цены WooCommerce: скидки по количеству, роли клиента и условиям заказа

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

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

Какие правила цен можно реализовать

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

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

Скидка по количеству: считать товар или всю группу

Даже простое правило «от 10 штук цена ниже» требует уточнения. Десять единиц одного SKU и десять разных товаров из категории — это разные сценарии.

Для вариативного товара нужно решить, суммируются ли разные вариации. Например, пять футболок размера M и пять размера L могут считаться как десять единиц одного товара или как две независимые позиции. Правильный вариант определяется бизнесом, а не WooCommerce автоматически.

Цены по ролям клиентов

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

Лучше хранить правило централизованно и применять его в одном слое расчёта. Тогда цена одинаково определяется в каталоге, карточке товара, корзине, checkout и серверном расчёте заказа.

Что делать, если одновременно подходит несколько правил

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

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

Если этот порядок не определить заранее, результат будет зависеть от того, в какой последовательности сработали плагины и hooks.

Каталог, корзина и checkout должны показывать одну логику

Покупатель не должен видеть 1000 ₽ в каталоге, 900 ₽ в карточке и 950 ₽ после перехода в корзину без объяснения причины. Если итоговая цена зависит от контекста, интерфейс должен показывать условия понятно.

Для quantity pricing можно вывести таблицу уровней: 1–4, 5–9, 10+. Для цены по роли достаточно показывать фактическую доступную клиенту стоимость. Для скидки от суммы корзины полезно сообщать, сколько осталось добавить до следующего уровня.

Купоны и автоматические скидки

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

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

Налоги и отображение цены

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

Особенно внимательно нужно тестировать магазины, где налог зависит от адреса покупателя или где B2B-клиенты работают по отдельным условиям.

Кэширование может показать чужую цену

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

Иначе оптовая цена может попасть в кэш и временно показываться розничному посетителю. При внедрении я отдельно проверяю WP Rocket, серверный кэш, CDN и object cache, если они используются.

Почему не всегда нужен отдельный тяжёлый плагин

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

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

Если цена приходит из CRM или ERP

Иногда WooCommerce не является источником истины: персональные цены рассчитывает ERP, CRM или внутренний сервис. Тогда задача превращается в интеграцию API.

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

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

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

Разработка динамических цен WooCommerce в A.S Groups

A.S Groups занимается разработкой и доработкой WooCommerce. Можно настроить готовое расширение, если оно действительно закрывает задачу, либо реализовать отдельную логику под конкретные правила магазина.

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

Вывод

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

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