Как мы за один месяц разработали кастомную систему кэшбэка для крупного проекта на WooCommerce

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

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

Одному из наших клиентов требовалось полноценное решение для крупного e-commerce-проекта. Система должна была соответствовать подробным бизнес-требованиям и при этом оставаться достаточно гибкой для будущего развития.

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

Вывод был однозначным: ни один из существующих продуктов не поддерживал все необходимые правила в рамках одной надёжной системы.

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

Полное решение было спроектировано, разработано, протестировано и запущено всего за один месяц.

Задача

У клиента уже был действующий интернет-магазин с большим количеством покупателей и заказов.

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

Система должна была:

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

Главная сложность заключалась не просто в расчёте процента от суммы заказа.

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

Почему готовые плагины не подошли

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

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

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

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

Система должна была:

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

Некоторые плагины поддерживали одно или два из этих условий, но не все одновременно.

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

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

Кроме того, важным вопросом была долгосрочная гибкость.

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

Поэтому для этого проекта кастомная разработка стала наиболее практичным и надёжным решением.

Наше решение

Мы разработали отдельный плагин кэшбэка специально для WooCommerce-магазина клиента.

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

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

Система различает несколько типов операций:

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

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

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

Расчёт кэшбэка после применения купонов

Одно из ключевых требований клиента касалось суммы, на основании которой должен рассчитываться кэшбэк.

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

Кэшбэк рассчитывался только от оставшейся суммы, соответствующей условиям программы.

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

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

В зависимости от настроек программы из расчёта также могут исключаться:

• налоги;
• стоимость доставки;
• отдельные товары;
• выбранные категории товаров;
• сборы, не участвующие в программе;
• другие промокорректировки.

Плагин повторно рассчитывает сумму, участвующую в начислении кэшбэка, при каждом изменении корзины, а также при добавлении или удалении купона.

Благодаря этому отображаемая сумма кэшбэка всегда соответствует актуальному составу заказа, а не устаревшему расчёту корзины.

Ожидающий и доступный кэшбэк

После оформления заказа кэшбэк не становится доступным для использования сразу.

Сначала он фиксируется как ожидающий и связывается с соответствующим заказом WooCommerce.

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

Разделение ожидающего и доступного кэшбэка также помогает покупателям лучше понимать состояние своего баланса.

Они могут отдельно видеть:

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

Использование кэшбэка при оформлении заказа

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

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

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

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

Во-вторых, кэшбэком можно было покрыть только заранее определённую часть заказа.

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

Например, магазин может настроить систему таким образом, чтобы кэшбэк:

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

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

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

Перед применением кэшбэка система проверяет:

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

Эти проверки повторяются при каждом обновлении страницы оформления заказа.

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

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

История кэшбэка в личном кабинете

В личном кабинете WooCommerce был добавлен отдельный раздел кэшбэка.

Покупатели могут увидеть:

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

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

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

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

Срок действия кэшбэка

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

Каждая подходящая транзакция получает собственную дату окончания срока действия.

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

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

Благодаря этому и покупатель, и сотрудники магазина могут видеть прозрачную запись о произошедшем изменении.

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

Возвраты и отменённые заказы

Обработка возвратов — одна из самых важных частей любой системы кэшбэка.

Без корректной логики покупатель может сохранить кэшбэк, начисленный за возвращённые товары, или получить неправильный баланс после отмены заказа.

Кастомный плагин отслеживает соответствующие изменения статусов WooCommerce и автоматически корректирует кэшбэк.

В зависимости от ситуации система может:

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

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

Если возврат оформляется после начисления кэшбэка, система может списать необходимую сумму с баланса.

Частичные возвраты требуют более сложного расчёта. В таких случаях плагин пересчитывает кэшбэк на основании оставшейся суммы заказа, участвующей в программе, вместо автоматической отмены всего вознаграждения.

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

Управление в административной панели

Система включает административные инструменты для управления программой лояльности.

Уполномоченные сотрудники могут:

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

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

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

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

Промоакции и кастомные правила начисления

Проект должен был поддерживать не только одну стандартную ставку кэшбэка.

Архитектура плагина позволяет добавлять различные промомеханики, включая:

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

Эти механики можно добавлять без замены основной системы кэшбэка.

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

Совместимость с существующим магазином

Систему кэшбэка необходимо было внедрить без нарушения работы действующего проекта на WooCommerce.

В магазине уже использовались собственные:

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

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

Особое внимание было уделено:

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

Благодаря этому система кэшбэка стала естественной частью существующего магазина, а не отдельным несвязанным дополнением.

Разработка за один месяц

Полная система кэшбэка была создана за один месяц.

За это время мы:

1. проанализировали бизнес-требования клиента;
2. изучили и протестировали готовые плагины кэшбэка;
3. связались с разработчиком стороннего решения;
4. спроектировали архитектуру кастомной системы;
5. разработали логику расчёта кэшбэка и ведения баланса;
6. интегрировали использование кэшбэка в оформление заказа;
7. создали интерфейсы личного кабинета и административной панели;
8. добавили обработку сроков действия, возвратов и статусов заказов;
9. протестировали различные сценарии покупок, купонов, отмен и возвратов;
10. запустили систему на действующем проекте.

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

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

Результат

Клиент получил полноценную систему кэшбэка, адаптированную под реальные операционные потребности магазина.

Теперь плагин:

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

Система уже успешно работает на крупном действующем e-commerce-проекте.

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

Готовность к дальнейшей доработке

Одно из главных преимуществ кастомной разработки — гибкость.

Плагин создавался не как временное решение для одной конкретной акции. Его архитектура позволяет добавлять новые функции по мере изменения требований клиента.

В будущем система может быть дополнена такими возможностями, как:

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

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

Когда кастомная разработка оправдана

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

Кастомная разработка становится более оправданной, если:

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

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

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

Заключение

Этот проект начался с поиска подходящего плагина кэшбэка для WooCommerce.

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

За один месяц мы разработали и запустили полноценную систему кэшбэка, которая соответствует бизнес-правилам проекта, интегрирована с действующим интернет-магазином и готова к дальнейшему расширению.

Результатом стал не просто плагин бонусных баллов, а гибкая платформа лояльности, созданная специально под процессы клиента.

В 4pixels мы разрабатываем кастомную функциональность для WordPress и WooCommerce в тех случаях, когда возможностей стандартных плагинов недостаточно.

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