Подписки в WooCommerce: рекуррентные платежи, продления и статусы

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

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

Из чего состоит подписка в WooCommerce

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

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

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

Автоматические и ручные продления — это разные сценарии

Официальная документация WooCommerce разделяет продления на automatic и manual. При автоматическом продлении платёжный метод должен поддерживать повторное списание. При ручном WooCommerce создаёт renewal order, а клиент оплачивает его через обычный checkout.

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

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

Обычный тест «карта прошла, заказ создан» проверяет только первый checkout. Для подписочной модели нужно отдельно убедиться, что gateway умеет обработать последующее списание без повторного ввода карты, если именно этого требует бизнес-модель.

WooCommerce показывает совместимые возможности платёжных расширений отдельно. Например, WooPayments, Stripe и PayPal Payments могут поддерживать автоматические продления в определённых конфигурациях, но набор поддерживаемых способов оплаты внутри одного gateway тоже может отличаться.

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

Что происходит в день продления

Когда наступает следующая дата оплаты, WooCommerce Subscriptions запускает renewal-процесс и создаёт связанный заказ. Дальнейшее поведение зависит от способа продления и возможностей gateway.

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

Для магазина важно понимать, что новый платёж — это отдельный renewal order, а не редактирование первоначального заказа. Это влияет на отчёты, интеграции с CRM, склад, письма и собственный код.

Failed payment — нормальная часть подписной модели

Карта может быть просрочена, банк может отклонить операцию, на счёте может не хватить средств. Поэтому хороший subscription-flow проектируется не только для успешного списания.

В базовом сценарии WooCommerce Subscriptions может перевести подписку в on-hold, уведомить клиента и дать ему возможность оплатить неуспешный renewal order. Также у Subscriptions есть система автоматических повторных попыток для подходящих failed recurring payments.

Здесь особенно важно проверить письма, страницу My Account и логику возврата подписки в активное состояние после успешной оплаты.

Личный кабинет клиента должен быть частью сценария

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

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

Auto-renew можно сделать управляемым

WooCommerce Subscriptions имеет настройку, позволяющую покупателю переключаться между автоматическим и ручным режимом продления через My Account. По умолчанию эта возможность не обязана быть включена.

Если бизнес хочет дать клиенту такой выбор, нужно проверить, поддерживает ли текущий gateway переход обратно на automatic renewal и может ли пользователь добавить подходящий платёжный метод.

Интеграции с CRM должны различать первый и повторный заказ

Если WooCommerce передаёт заказы в CRM, учётную систему или Telegram, обычное правило «каждый новый заказ = новая продажа» может создать шум. Renewal orders относятся к существующей подписке и часто требуют другого сценария обработки.

Например, CRM может получать тип события, ID подписки, номер renewal order, статус оплаты и дату следующего продления. Тогда менеджер понимает, что произошло: новый клиент оформил подписку или существующий клиент успешно продлил её.

Для таких задач я использую API и webhooks, а общую логику интеграций можно посмотреть на странице интеграции CRM с сайтом.

Подписки и HPOS

На современном WooCommerce важно учитывать High-Performance Order Storage. Любой кастомный код, который напрямую работает с заказами через старые таблицы WordPress, нужно проверять на совместимость с HPOS.

Это особенно актуально для подписок, потому что один клиент со временем создаёт цепочку связанных renewal orders. Если собственная интеграция читает данные неправильно, ошибка может проявиться не на первом заказе, а только через месяц при продлении. Отдельно я разбирал переход в статье WooCommerce HPOS: проверка совместимости.

Как тестировать рекуррентный платёж до запуска

Ждать месяц до первого реального renewal — плохой способ тестирования. WooCommerce рекомендует проверять продления на staging-сайте и в test mode платёжного шлюза.

Для активной тестовой подписки можно использовать действие Process renewal или запустить соответствующее scheduled action, если выбранный gateway поддерживает такой тестовый путь. Важно, чтобы тест не затронул реальные карты и production-заказы.

1. создать тестовый subscription product;
2. оформить подписку через тестовый gateway;
3. проверить первоначальный заказ и статус подписки;
4. запустить тестовое продление;
5. проверить renewal order, списание и письма;
6. отдельно воспроизвести failed payment;
7. проверить восстановление после успешной повторной оплаты.

Scheduled Actions тоже нужно контролировать

Фоновая обработка WooCommerce зависит от Action Scheduler. Если cron или очередь scheduled actions на сайте не работает, проблема может выглядеть как «подписки перестали списывать деньги», хотя платёжный gateway исправен.

Поэтому при диагностике я смотрю не только логи платёжного модуля, но и WooCommerce Status, Scheduled Actions, серверные ошибки и фактическое время запуска задач.

Когда нужна кастомная логика

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

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

Сколько стоит настройка подписок WooCommerce

Стоимость зависит прежде всего от платёжной схемы и числа интеграций. Подключить готовый совместимый gateway и настроить один subscription product проще, чем строить несколько тарифов, миграцию существующих клиентов, CRM, внешнюю выдачу доступа и нестандартные правила failed payments.

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

Когда имеет смысл заказать настройку под ключ

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

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

Официальные источники

• WooCommerce: Subscriptions Payment Methods & Gateways
• WooCommerce: Subscription Renewal Process
• WooCommerce: Testing Subscription Renewal Payments

Итог

Рабочая подписка WooCommerce — это связка продукта, расписания, renewal orders, платёжного gateway, статусов, фоновых задач и понятного личного кабинета. Проверять нужно не только первый checkout, но и следующий платёж, отказ, повторную оплату и передачу данных во внешние системы.

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