Управление подписками и рекуррентными платежами

Подписка выглядит просто со стороны покупателя: оплатил один раз — и дальше доступ, товар или сервис продлеваются сами. Но за этой простотой стоит целый механизм: платёж должен списаться по расписанию без участия клиента, при отказе банка — повториться, а подписчик — вовремя получить письмо, что списание прошло или что карта истекает. В 1С-Битрикс из коробки готового «модуля подписок» нет: рекуррентные платежи, автопродления, паузы и повторные попытки собираются из штатных заказов, агентов, событий и платёжного шлюза с поддержкой списаний по токену.

Ниже — практическая схема управления подписками: как устроен жизненный цикл подписки, как настроить регулярные списания и повторные попытки при отказе, как дать клиенту паузу и отмену в личном кабинете и какие уведомления отправлять на каждом шаге. Это выжимка из наших проектов по интеграции платёжных сервисов и внешних систем с 1С-Битрикс — с опорой на реальную механику эквайринга, а не на общие слова.

Подписки и рекуррент: что это и зачем

Подписка — это бизнес-модель, в которой покупатель платит регулярно за длящийся доступ: коробка товаров раз в месяц, доступ к сервису, повторяющаяся поставка расходников, членство в клубе. Рекуррентный платёж (от англ. recurring — повторяющийся) — техническая часть этой модели: автоматическое списание фиксированной или расчётной суммы по расписанию, которое не требует, чтобы клиент каждый раз заходил и оплачивал вручную.

Важно с самого начала разделить два понятия, которые часто путают. Подписка — это сущность на стороне магазина: она знает тариф, период, дату следующего списания, статус и историю. Рекуррентное списание — это операция на стороне платёжного шлюза: магазин просит эквайера снять сумму с ранее привязанной карты. Одна подписка за свою жизнь порождает много рекуррентных списаний, и каждое из них может пройти или не пройти. Управление подписками — это, по сути, управление тем, что происходит между этими списаниями и вокруг них.

Зачем бизнесу переходить на подписочную модель, понятно из экономики: вместо того чтобы каждый месяц заново «покупать» клиента через рекламу, вы получаете предсказуемую регулярную выручку с уже привлечённой базы. Но у этой медали есть обратная сторона: если механика продлений работает плохо, вы так же предсказуемо теряете подписчиков — не потому что они разочаровались, а потому что у кого-то не прошло списание, кто-то не нашёл кнопку паузы и отменил всё целиком, а кому-то не пришло уведомление. Поэтому качество технической реализации подписок прямо конвертируется в деньги.

Ещё один момент, который стоит зафиксировать сразу: подписка — это не «заказ, который повторяется сам». Между продлениями сумма может меняться (проиндексировали тариф, применили промо на первый период, добавили позицию), карта может истечь, клиент может уехать в отпуск и попросить паузу, а закон и платёжная система требуют заранее уведомлять о списаниях. Всё это — состояния и переходы, которые нужно спроектировать явно, а не оставлять на «как-нибудь само».

Архитектура подписочной модели в Битриксе

Чтобы управлять подписками осознанно, полезно держать в голове, из каких частей собрана модель. В 1С-Битрикс подписка — это не один объект, а связка нескольких слоёв, каждый со своей ответственностью.

• Сущность подписки. Запись, которая хранит клиента, тариф, период, дату следующего списания, статус, платёжный токен и историю. Обычно реализуется highload-блоком или отдельной таблицей, связанной с заказами.
• Тариф (план). Что и как часто продлевать: сумма, период (месяц, год), пробный период, правила индексации. Один тариф обслуживает много подписок.
• Заказ и оплата. Штатный заказ модуля «Интернет-магазин» — каждое успешное списание фиксируется как оплата, чтобы работали бухгалтерия, чеки и отчётность.
• Платёжный шлюз. Эквайер, который хранит карту, выдаёт токен и выполняет рекуррентные списания по запросу магазина.
• Агент-планировщик. Фоновый процесс Битрикса, который по расписанию находит подписки с наступившей датой платежа и запускает списания и продления.
• Слой уведомлений. Почтовые события и SMS/мессенджеры, которые сообщают клиенту об успешном списании, скором продлении, неудаче и истечении карты.
• Личный кабинет. Интерфейс, где подписчик видит свои подписки и управляет ими: пауза, возобновление, смена карты, отмена.

Ключевая мысль: заказ и подписка — это разные сущности, которые связаны, но не тождественны. Подписка живёт долго и меняет статусы; каждый её платёжный цикл материализуется в отдельный заказ (или платёж), чтобы не ломать штатную логику магазина — чеки по 54-ФЗ, скидки, складской учёт. Такая двухуровневая архитектура позволяет добавить подписки, не переписывая ядро интернет-магазина.

Жизненный цикл подписки: статусы

Управление подписками — это, по сути, управление её состояниями. Подписка не «включена» или «выключена»: она проходит через набор статусов, и от того, насколько аккуратно описаны переходы между ними, зависит и выручка, и опыт клиента. Минимальный, но полноценный набор статусов выглядит так.

• Пробная (trial). Действует пробный период — бесплатно или за символическую сумму. По его окончании происходит первое полноценное списание.
• Активная (active). Оплачена, доступ открыт, назначена дата следующего списания. Основное «здоровое» состояние.
• Просрочена (past due). Очередное списание не прошло, идут повторные попытки. Доступ обычно ещё сохраняется в рамках grace-периода.
• На паузе (paused). Клиент временно приостановил подписку. Списания не идут, дата следующего платежа сдвинута.
• Отменена (canceled). Клиент отказался от продления. Доступ может действовать до конца оплаченного периода, но нового списания не будет.
• Завершена (expired). Все попытки исчерпаны или период истёк без продления. Доступ закрыт, подписка в архиве, но история сохранена.

Главная ошибка проектирования — сводить всё к двум состояниям «активна/неактивна». Тогда клиент, у которого просто не прошло списание из-за истёкшей карты, мгновенно теряет доступ и уходит, хотя он вовсе не собирался отказываться. Промежуточные статусы «просрочена» и «на паузе» — это как раз те буферы, которые превращают технический сбой или временную нужду в перерыв, а не в потерю подписчика.

Как устроено списание по токену

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

При первом платеже клиент вводит реквизиты карты на платёжной странице шлюза (не на сайте магазина). Магазин при инициации платежа помечает его как «рекуррентный/родительский» — просит шлюз запомнить карту. Если оплата успешна, шлюз сохраняет карту у себя и возвращает магазину токен — обезличенный идентификатор связки (его называют rebill ID, recurring token, связка). Этот токен магазин сохраняет в подписке.

При каждом последующем списании магазин не показывает клиенту никакой формы. Агент по расписанию берёт токен из подписки и отправляет шлюзу запрос: «спиши такую-то сумму по такой-то связке». Шлюз выполняет операцию и возвращает результат — успех или отказ с кодом причины. Реквизиты карты при этом не покидают инфраструктуру эквайера, а магазин оперирует только токеном и суммой.

Отдельно стоит различать модели инициации. При «серверном» рекурренте (merchant-initiated) списание запускает магазин по расписанию — это классическая подписка. При «клиент-инициированном» повторном платеже (customer-initiated) клиент сам нажимает «оплатить сохранённой картой» — это удобная оплата в один клик, но не подписка. Для регулярных списаний нужен именно merchant-initiated сценарий, и его поддержку у шлюза важно проверить до старта.

Тарифы, периоды и пробные подписки

Тариф (план подписки) описывает коммерческие правила: сколько, за что и как часто списывать. Хорошо спроектированная система тарифов позволяет менять условия без переписывания кода, поэтому тариф стоит выносить в отдельную сущность (highload-блок или инфоблок), а не «зашивать» в подписку.

Пробные периоды — мощный инструмент конверсии, но с ними связаны две частые ошибки. Первая — не уведомить клиента об окончании пробного периода: списание «внезапно» приходит, клиент оспаривает платёж, и вы получаете chargeback вместо подписчика. Правило простое: за 1–3 дня до конца триала отправьте письмо «пробный период заканчивается, спишем столько-то тогда-то». Вторая ошибка — разрешить бесконечно перезапускать бесплатный триал на новые аккаунты; здесь помогает привязка триала к карте или телефону.

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

Автопродление и агент регулярных списаний

Двигатель всей подписочной модели — агент, фоновый механизм 1С-Битрикс, который выполняется по расписанию. Именно он превращает статичную запись подписки в живые регулярные списания. Логика агента, если описать её по шагам, выглядит так.

1. Выборка кандидатов. Агент находит все активные подписки, у которых дата следующего списания наступила или наступит сегодня. Выборку делают порциями (батчами), чтобы не грузить базу и уложиться в таймаут.
2. Проверка условий. Для каждой подписки проверяется, что она не на паузе и не отменена, что токен валиден, а сумма и тариф актуальны.
3. Запрос списания. Агент отправляет шлюзу запрос на списание по токену. Ответ (успех/отказ) записывается в историю подписки.
4. Обработка успеха. При успехе создаётся заказ/оплата, пробивается чек, продлевается доступ, дата следующего списания сдвигается на период, клиенту уходит уведомление об оплате.
5. Обработка отказа. При отказе подписка переходит в «просрочена», запускается сценарий повторных попыток (dunning), клиенту уходит письмо с просьбой обновить карту.
6. Идемпотентность. Агент помечает обработанные подписки, чтобы повторный запуск в тот же день не списал дважды. Это критично: двойное списание — прямой путь к возвратам и жалобам.

Отдельно продумайте окно запуска. Списывать всех подписчиков ровно в полночь — плохая идея: в этот момент базы банков сами перегружены, и доля отказов растёт. Разумнее «размазать» списания по утренним часам и, если у клиента отказ, повторять попытку в другое время суток — вероятность успеха у второй попытки в другой момент дня заметно выше.

Повторные попытки оплаты и dunning

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

Хорошая dunning-стратегия строится на двух осях: когда повторять списание и как в это время общаться с клиентом. Типовой сценарий:

Разделяйте два вида оттока. Добровольный (voluntary churn) — клиент сознательно отменил подписку, здесь помогают продукт и удержание. Недобровольный (involuntary churn) — клиент не отказывался, но подписка прервалась из-за неудачного списания. Второй вид оттока лечится чисто технически — грамотным dunning, и это самый дешёвый способ поднять выручку: вы возвращаете тех, кто и так хотел остаться. Мы подробно разбираем механику частичных и повторных списаний в статье о частичной оплате и депозитах в Битрикс — многое из dunning применимо и там.

Пауза, возобновление и отмена

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

Пауза — самый недооценённый инструмент. Клиент уезжает в отпуск, временно не пользуется сервисом, хочет сэкономить месяц — вместо полной отмены он ставит подписку на паузу. Технически пауза меняет статус на paused, останавливает начисления и сдвигает дату следующего списания на выбранный срок (или до ручного возобновления). История и токен сохраняются, поэтому возврат к активности — в один клик, без повторного оформления.

Возобновление должно быть максимально гладким: клиент нажимает «возобновить», система назначает новую дату списания и, если нужно, сразу проводит платёж. Важно не «наказывать» за паузу — не терять накопленные бонусы, не сбрасывать «стаж» подписчика, если от него зависят скидки.

Отмена тоже должна быть предсказуемой. Хорошая практика — не отключать доступ мгновенно, а дать доработать оплаченный период: клиент уже заплатил за него. На экране отмены уместно предложить альтернативу — паузу, смену тарифа на более дешёвый, скидку на удержание. Но предлагать это нужно честно, без тёмных паттернов и обязательного «звонка менеджера»: навязчивое удержание бьёт по репутации сильнее, чем сама отмена.

Уведомления клиенту на каждом шаге

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

• Оформление подписки. Подтверждение: что оформлено, на какой период, сколько и когда спишется в следующий раз.
• Скорое продление. За 1–3 дня до списания — напоминание с суммой и датой. Особенно важно для годовых подписок и после триала.
• Успешное списание. Чек и подтверждение продления, новая дата следующего платежа.
• Неудачное списание. Сообщение с причиной (по возможности) и прямой ссылкой на обновление карты.
• Истечение карты. Заблаговременное предупреждение, что карта скоро истечёт и списание может не пройти.
• Пауза и возобновление. Подтверждение изменения статуса и новой даты списания.
• Отмена/завершение. Подтверждение отмены, дата, до которой действует доступ, и лёгкий путь вернуться.

Технически в Битриксе это удобно строить на почтовых событиях (mail events) и шаблонах писем, а для срочных сообщений — на SMS и мессенджерах. Ключевой принцип: уведомление о деньгах должно приходить до списания, а не только после. Клиент, которого предупредили о предстоящем платеже, почти никогда не оспаривает его; клиент, для которого списание стало сюрпризом, — оспаривает часто.

Реализация в 1С-Битрикс: модули и события

Разберём, из каких штатных механизмов платформы собирается управление подписками. Готового модуля «из коробки» нет, но есть все кирпичи, чтобы построить надёжную систему без «велосипедов» в обход ядра.

• Модуль «Интернет-магазин» (sale). База для заказов, оплат, статусов и платёжных систем. Каждый цикл подписки материализуется как заказ, чтобы работали чеки по 54-ФЗ, скидки и отчётность.
• Highload-блоки. Хранилище сущностей «подписка» и «тариф»: клиент, тариф, период, дата следующего списания, статус, токен, история. Highload удобен объёмом и скоростью выборок для агента.
• Агенты (agents). Регулярный системный агент, запускаемый по cron, который находит подписки к списанию и запускает продления. Именно cron, а не «агенты на хитах».
• Обработчики событий платёжной системы. Классы платёжных систем модуля sale, расширенные для инициации первого «родительского» платежа и последующих списаний по токену.
• Почтовые события (mail events). Шаблоны писем для каждого шага жизненного цикла, привязанные к событиям смены статуса подписки.
• Компоненты личного кабинета. Свой компонент или доработка sale.personal.*, где клиент видит подписки и управляет ими.

Логика связывается через события. Успешное списание вызывает создание заказа и оплаты, смена статуса подписки — отправку письма, приближение даты — постановку задачи агенту. Такой подход держит бизнес-правила в одном месте и не ломает штатную механику магазина. Если рекуррент нужно связать ещё и с внешними системами — CRM, сервисом рассылок, аналитикой — это делается через ту же событийную модель; общие принципы такой связки мы разбираем в статье про подписки и рекуррентные платежи в Битрикс.

Как это выглядит в админке

Карточка подписки в административной части — это, по сути, сводка её состояния и история платежей. Схематично интерфейс управления одной подпиской выглядит так:

Платёжные шлюзы и рекуррент

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

Что важно уточнить у эквайера или платёжного сервиса до старта:

• Поддержка merchant-initiated списаний. Может ли магазин инициировать платёж по токену без участия клиента — это и есть основа подписки.
• Формат токена и его срок жизни. Как выдаётся rebill ID, как долго живёт, что происходит при перевыпуске карты.
• Обновление данных карты (account updater). Умеет ли шлюз автоматически подтягивать новый срок действия карты — это резко снижает недобровольный отток.
• Коды ответов при отказе. Насколько детально шлюз объясняет причину отказа — от этого зависит качество dunning-сценария.
• Онлайн-кассы и чеки. Как связаны списания и фискализация по 54-ФЗ, кто пробивает чек на регулярный платёж.
• Возвраты и частичные возвраты. Как оформить возврат по рекуррентному платежу, если клиент отменил в середине периода.

С точки зрения архитектуры разумно не «прибивать» логику подписок к одному шлюзу гвоздями, а вводить тонкий слой абстракции: подписка знает «сумму и токен», а конкретный способ их передать инкапсулирован в обработчике платёжной системы. Тогда смена или добавление второго эквайера не потребует переписывать весь механизм продлений.

Метрики подписочной модели

Обычный магазин меряет разовые продажи, подписочный — регулярную выручку и её динамику. Управлять подписками вслепую нельзя: без метрик вы не увидите, что модель незаметно «протекает». Базовый набор показателей выглядит так.

Отдельно стоит выделить недобровольный отток. Часто бизнес видит «отток 8% в месяц» и думает, что проблема в продукте, а на деле половина этих 8% — просто неудачные списания, которые вернулись бы при нормальном dunning. Разложите churn на добровольный и технический — и вы, скорее всего, найдёте самый дешёвый источник роста выручки. Данные для этих метрик собираются из статусов подписок и истории платежей, а дальше выгружаются в CRM или BI. Как подписочная модель влияет на экономику магазина в целом и как считать её юнит-экономику, мы разбираем в материале о подписочной модели магазина на Битрикс.

Правовые и платёжные требования

Рекуррент — область, где технику нельзя отделить от юридических и платёжных правил. Их несоблюдение оборачивается не «замечаниями», а блокировкой эквайринга, штрафами и волной оспариваний платежей. Ключевые требования, которые нужно закрыть до запуска:

• Согласие на регулярные списания. Клиент должен явно согласиться на автосписания при оформлении — отдельным чекбоксом и понятной формулировкой в оферте: что, как часто и в каком размере будет списываться.
• Прозрачность условий. Сумма, период, порядок отмены и возвратов должны быть доступны и понятны до оплаты, а не спрятаны мелким шрифтом.
• PCI DSS. Реквизиты карты не хранятся на стороне магазина — только токен у шлюза. Форма ввода карты — на защищённой странице эквайера.
• Фискализация (54-ФЗ). На каждый регулярный платёж нужен чек. Продумайте, кто и в какой момент его пробивает при автосписании.
• Лёгкая отмена. Отмена подписки должна быть доступна так же просто, как оформление, — это и требование платёжных систем, и фактор доверия.
• Уведомление перед списанием. Заблаговременное предупреждение о предстоящем платеже резко снижает долю оспариваний (chargeback).

Частые ошибки

• Запускают регулярные списания на «агентах по хитам» вместо cron — в тихие часы платежи не выполняются, а даты продлений плывут.
• Не делают агент идемпотентным — повторный запуск списывает дважды, следом идут возвраты и жалобы.
• Сводят статусы к «активна/неактивна» — клиент с истёкшей картой мгновенно теряет доступ вместо перехода в «просрочена».
• Не настраивают повторные попытки (dunning) — весь недобровольный отток уходит навсегда, хотя большую часть можно было вернуть.
• Не уведомляют о предстоящем списании и об окончании триала — клиент оспаривает «внезапный» платёж, растут chargeback.
• Прячут отмену и паузу или требуют звонить менеджеру — растёт негатив, а не удержание.
• Хранят или пытаются хранить данные карты на своей стороне — нарушение PCI DSS и риск для эквайринга.
• Забывают про чеки на регулярные платежи — списание проходит, а фискализация по 54-ФЗ отсутствует.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность подписок перед запуском:

1. Шлюз поддерживает рекуррент. Проверены merchant-initiated списания по токену, формат и срок жизни rebill ID, коды отказов.
2. Сущности спроектированы. Подписка и тариф вынесены отдельно, хранят статус, дату списания, токен и историю; связь с заказами настроена.
3. Статусы и переходы описаны. Есть пробная, активная, просрочена, на паузе, отменена, завершена — с явными правилами переходов и grace-периодом.
4. Агент на cron. Регулярные списания идут по системному расписанию, батчами, идемпотентно, с «размазыванием» по времени.
5. Dunning настроен. Заданы интервалы повторных попыток и коммуникации на каждом шаге; отдельно считается recovery rate.
6. Личный кабинет готов. Клиент видит подписки и может поставить паузу, возобновить, сменить карту и отменить без звонка.
7. Уведомления подключены. Письма/SMS на оформление, скорое продление, успех, отказ, истечение карты, паузу и отмену — с предупреждением до списания.
8. Право и фискализация. Согласие на автосписания, прозрачная оферта, чеки по 54-ФЗ, соответствие PCI DSS.
9. Метрики собираются. Считаются MRR, churn (добровольный и недобровольный), LTV, доля успешных продлений; данные выгружаются в CRM/BI.

Вывод

Управление подписками в 1С-Битрикс — это не одна кнопка, а связка из хорошо описанных статусов, надёжного агента регулярных списаний, продуманного dunning, удобной паузы и отмены в личном кабинете и своевременных уведомлений. Готового модуля из коробки нет, но все нужные механизмы — заказы, highload-блоки, агенты, события и почтовые шаблоны — в платформе есть. Соберите их правильно, подключите шлюз с рекуррентом по токену, разложите отток на добровольный и технический — и подписочная модель начнёт давать предсказуемую регулярную выручку, а не тихо «протекать» на неудачных списаниях.