Подписочная модель: как устроить биллинг и рекуррентные платежи в России

Как запустить подписку на цифровой продукт: каталог тарифов, токенизация карт и СБП, планировщик списаний, 54-ФЗ, повторные попытки и вынужденный отток, метрики MRR, churn и LTV, архитектурные решения и порядок запуска.

Подписка выглядит простой моделью: пользователь платит раз в месяц, компания получает предсказуемую выручку. На практике за кнопкой «Оформить подписку» стоит один из самых сложных контуров цифрового продукта: привязка платёжного средства, регулярные списания, фискальные чеки, повторные попытки при неуспешной оплате, смена тарифов посреди периода, промокоды, возвраты, отмены, учёт в бухгалтерии и аналитика, без которой невозможно понять, растёт бизнес или тихо теряет клиентов. Ниже — как устроен подписочный биллинг в российских условиях: из каких частей он состоит, какие решения нужно принять до разработки, где теряются деньги и клиенты и какие метрики показывают здоровье подписочной модели. Материал для компаний, которые запускают платный доступ к медиа, SaaS-сервису, образовательной платформе или приложению. Чем подписка отличается от разовой продажи Разовая продажа заканчивается в момент оплаты. Подписка в момент первой оплаты только начинается. Из этого различия вытекает всё остальное. Платёж повторяется без участия пользователя. Компания инициирует списание сама, и каждое списание может не пройти: закончились деньги, истёк срок карты, банк заблокировал операцию. У клиента есть состояние. Пробный период, активная подписка, просроченная оплата, льготный период, приостановка, отмена с доступом до конца оплаченного срока. Продукт должен знать это состояние в любой момент. Выручка распределена во времени. Годовая подписка, оплаченная в январе, — не январская выручка, а двенадцать месяцев обязательств по предоставлению доступа. Главная угроза — отток. Привлечь подписчика дорого; потерять — легко. Экономика модели держится на том, сколько месяцев клиент остаётся. Из чего состоит подписочный биллинг Каталог тарифов Описание того, что продаётся: тарифные планы, их стоимость, периодичность списаний, что входит в каждый план, пробные периоды, ограничения. Хорошо спроектированный каталог позволяет маркетингу запускать новый тариф или акцию без участия разработчиков. Решения, которые стоит принять заранее: какие периоды поддерживаются — месяц, квартал, год; как хранится история цен: подписчик, оформивший подписку по старой цене, продолжает платить старую или переводится на новую, и как его об этом уведомляют; нужны ли семейные и корпоративные тарифы с несколькими пользователями на одной подписке; как устроены дополнения, которые покупаются поверх основного тарифа. Привязка платёжного средства Для регулярных списаний нужно сохранить возможность повторно списывать деньги без ввода данных пользователем. Хранить номера карт самостоятельно почти никогда не нужно и очень дорого с точки зрения требований безопасности. Стандартная схема — токенизация: данные карты вводятся на стороне платёжного провайдера, а продукт получает токен, по которому может инициировать последующие списания. Первая оплата обычно проходит с подтверждением пользователя — например, через 3-D Secure. Последующие списания инициирует продавец без участия пользователя, и банк-эмитент принимает решение о каждом из них отдельно. Планировщик списаний Сервис, который в нужный момент инициирует списание для каждой подписки, обрабатывает результат и переводит подписку в следующее состояние. Задача кажется тривиальной, пока подписчиков немного. С ростом появляются вопросы: как не списать дважды при сбое, как распределить сотни тысяч списаний так, чтобы не упереться в ограничения провайдера, в какое время суток списывать, как учитывать часовые пояса. Повторные попытки и работа с неуспешными платежами Часть регулярных списаний не проходит с первого раза. Отдельный процесс решает, когда повторить попытку, сколько попыток сделать, как и когда уведомить пользователя, сколько дней сохранять доступ после неудачного списания и когда окончательно приостановить подписку. Этот процесс напрямую влияет на выручку — подробнее ниже. Фискализация По 54-ФЗ при расчётах с физическими лицами, в том числе при автоматических списаниях по подписке, формируется кассовый чек, который отправляется покупателю в электронном виде. На практике фискализацию обычно берёт на себя облачная касса платёжного провайдера или отдельный сервис, но продукт должен передавать корректные данные для чека: наименование услуги, сумму, признак способа расчёта, контакт покупателя. Ошибки в этих данных — частая причина претензий при проверках. Возвраты и отмены Пользователь просит вернуть деньги за списание, о котором забыл. Подписку отменили посреди оплаченного периода. Списание прошло дважды из-за сбоя. Каждый случай требует понятного правила, исполнения на стороне провайдера, чека возврата и корректного изменения доступа. Учёт и интеграция с бухгалтерией Данные о платежах, возвратах и чеках передаются в учётную систему. Для годовых подписок выручка распределяется по периодам. Сверка поступлений от провайдера с данными биллинга — регулярная операция, которую стоит автоматизировать с самого начала. Личный кабинет подписчика Где пользователь видит свой тариф, дату следующего списания, историю платежей и чеки, меняет карту, переходит на другой тариф и отменяет подписку. Возможность отменить подписку должна быть очевидной. Спрятанная отмена почти не снижает отток, зато увеличивает число жалоб в банк, возвратов по оспариванию и негатива в отзывах. Способы оплаты в России Банковские карты Основной способ для регулярных списаний. Через платёжного провайдера или эквайера, поддерживающего рекуррентные платежи и токенизацию. Отдельного внимания заслуживает обновление карт: срок действия истекает, карты перевыпускаются, и у заметной доли подписчиков через год привязанная карта уже не работает. Система быстрых платежей СБП развивает сценарии повторных платежей с привязкой счёта покупателя. Для бизнеса это привлекательная альтернатива картам благодаря более низкой стоимости операций, но поддержка сценария зависит от банка покупателя и платёжного провайдера. Разумный подход — предлагать СБП как один из способов оплаты и проектировать биллинг так, чтобы способ оплаты был отдельной сущностью, а не вшитой в код логикой карточных платежей. Кошельки и платёжные сервисы Некоторые платёжные сервисы поддерживают привязку кошелька для повторных списаний. Полезны для отдельных аудиторий, но редко становятся основным каналом. Оплата в мобильных приложениях Если продукт существует как мобильное приложение, нужно отдельно разобраться с правилами магазинов приложений: какие цифровые товары обязаны продаваться через встроенные покупки магазина, можно ли и как направлять пользователя к оплате на сайте, как синхронизировать подписку, купленную на разных платформах. Правила меняются и различаются между магазинами, поэтому решение принимается по актуальным условиям на момент разработки. Несколько провайдеров Крупные подписочные сервисы подключают больше одного платёжного провайдера. Причины: отказоустойчивость при сбое одного из них, разная доля успешных списаний для разных банков-эмитентов, разная стоимость операций. Архитектура с абстракцией над провайдерами стоит дороже на старте, но позволяет переключать трафик без переделки продукта. Где подписочный бизнес теряет деньги Вынужденный отток Отток бывает добровольным — пользователь сам решил отказаться — и вынужденным: пользователь не отказывался, но списание не прошло, и подписка закончилась. Вынужденный отток часто недооценивают, хотя он во многом управляем техническими средствами. Что помогает: Умные повторные попытки. Не повторять списание сразу же и не через фиксированные сутки, а учитывать причину отказа и время: отказ «недостаточно средств» имеет смысл повторить в другой день, отказ «карта заблокирована» повторять бессмысленно. Уведомления до списания. Напоминание о предстоящем списании за несколько дней снижает количество спорных операций и даёт пользователю время пополнить карту. Уведомления после неудачи. Письмо и уведомление в приложении с прямой ссылкой на обновление карты, без необходимости искать нужный раздел. Льготный период. Доступ сохраняется несколько дней после неудачного списания. Пользователь, у которого просто закончились деньги на карте, не теряет доступ в тот же момент. Альтернативный способ оплаты. Предложение оплатить через другой способ, если основной не работает. Неудачная первая оплата Пользователь дошёл до оплаты и не завершил её: форма не открылась на телефоне, 3-D Secure завис, способа оплаты, которым он пользуется, нет. Конверсия страницы оплаты — отдельная метрика, которую стоит отслеживать по устройствам, браузерам и способам оплаты. Ошибки биллинга Двойные списания, списание после отмены, неправильная сумма при смене тарифа. Каждая такая ошибка оборачивается возвратом, обращением в поддержку, а при повторении — потерей клиента и репутационными последствиями. Биллинг — код, в котором стоит закладывать больше тестов, чем в любой другой части продукта. Нагрузка на поддержку Значительная часть обращений в поддержку подписочных сервисов связана с деньгами: «почему списали», «где чек», «как отменить», «не прошла оплата». Прозрачный личный кабинет, понятные уведомления и самостоятельное управление подпиской снимают большую часть таких обращений. Метрики подписочной модели MRR — ежемесячная регулярная выручка. Годовые подписки учитываются как одна двенадцатая. Раскладывается на новую выручку, выручку от повышения тарифов, потери от понижения и потери от оттока. Отток (churn) — доля подписчиков или выручки, потерянных за период. Считается отдельно для добровольного и вынужденного оттока: у них разные причины и разные способы работы. LTV — ожидаемая выручка от подписчика за всё время. Зависит от цены и от продолжительности подписки. Сравнивается со стоимостью привлечения: если привлечение стоит дороже, рост подписчиков означает рост убытков. Доля успешных списаний — какая часть регулярных списаний проходит с первой попытки и после всех повторов. Прямо показывает качество работы платёжного контура. Конверсия пробного периода — какая доля пользователей после пробного периода становится платящими. Удержание по когортам — какая доля подписчиков, оформивших подписку в определённом месяце, остаётся через один, три, шесть, двенадцать месяцев. Показывает, улучшается ли продукт для новых клиентов со временем. Метрики нужно считать из данных биллинга, а не собирать вручную из выгрузок провайдера. Для этого биллинг проектируется с аналитическим хранилищем событий: оформление, списание, неудача, повторная попытка, смена тарифа, отмена. Пример из практики: платёжный контур медиахолдинга Мы проектировали и внедряли биллинговую платформу подписок для крупного делового медиахолдинга. Задача включала миграцию существующих подписчиков без потери данных, поддержку множества тарифов и способов оплаты, фискализацию по 54-ФЗ, интеграцию с учётной системой и финансовую аналитику в реальном времени. Результаты из опубликованного кейса : число платных подписчиков выросло на 420% — с 50 тысяч до 260 тысяч; регулярный доход от подписок — 87 млн ₽ в месяц; доступность платёжного контура — 99,97%; обработка более 500 тысяч транзакций в месяц, средняя скорость проведения платежа — 0,8 секунды; доля успешных платежей с первой попытки — 92%; отток — 4,2%; обращений в поддержку по финансовым вопросам стало на 75% меньше; пожизненная ценность подписчика выросла на 35%. Важно понимать, что рост аудитории — результат работы всей компании над продуктом и контентом. Задача биллинга в такой истории — не мешать росту: выдерживать нагрузку, не терять платежи, не создавать поводов для обращений в поддержку и давать бизнесу точные данные для решений. Архитектурные решения, которые стоит принять до разработки Своя система или готовый сервис Готовые биллинговые сервисы и функции подписок у платёжных провайдеров быстро запускаются и закрывают типовые сценарии. Собственная разработка оправдана, когда тарифная модель нестандартна, нужны глубокие интеграции с продуктом и учётом, подключается несколько провайдеров или объём операций делает комиссии готового сервиса существенной статьёй расходов. Промежуточный вариант — собственный слой управления подписками поверх API провай