Списание отклонили, и клиент просто исчез
Повторных попыток нет, письмо не отправляется, доступ закрывается сразу после первой ошибки. Клиент не понимает, что произошло, и уходит молча.
Выберите тему — соберём контекст
Проектируем подписку как платёжный процесс, а не как галочку в карточке: расписание списаний, повторные попытки при отказе, пауза и смена тарифа с пересчётом, письма до и после списания. Всё, что происходит с деньгами, видно и покупателю, и вашей команде.
Или сразу: +7 (962) 368-39-51 Telegram
Большая часть оттока в подписках — техническая: она связана с обработкой отказов и с тем, насколько просто клиенту управлять своей подпиской.
Повторных попыток нет, письмо не отправляется, доступ закрывается сразу после первой ошибки. Клиент не понимает, что произошло, и уходит молча.
Привязка не обновляется автоматически, изменить способ оплаты в кабинете нельзя. Подписка умирает из-за новой карты с тем же счётом.
При переходе на другой план в середине периода непонятно, сколько списывать и с какой даты. Поддержка считает разницу вручную, клиент видит неожиданную сумму.
Кнопка спрятана в глубине кабинета, причина отмены не собирается. Клиент звонит и требует отключить, а стоимость возвратов и жалоб превышает потери от честного оттока.
Выручка видна только в отчёте платёжного сервиса, когорты не строятся. Непонятно, сколько стоит привлечение и через сколько месяцев подписка окупается.
Автоматические списания проходят без фискального документа. Это заметно не сразу, а при первой же проверке или жалобе клиента.
Четыре слоя, которые нужно собрать, чтобы подписка работала без ручного вмешательства.
Фундамент: возможность списывать деньги повторно и безопасно хранить согласие клиента.
Механика, которая возвращает деньги, когда первый раз не получилось.
Правила, по которым меняется план и считается стоимость неполного периода.
Отчётность и документы, без которых подписку нельзя масштабировать.
Сначала описываем правила и сценарии отказов, потом пишем код — иначе спорные случаи придётся закрывать вручную.
Описываем тарифы, циклы, правила пересчёта, паузы и отмены. Фиксируем, что происходит с доступом при каждой ошибке оплаты.
Подключаем привязку карты и рекуррент, планировщик списаний, повторные попытки и фискализацию. Прогоняем сценарии отказов.
Собираем кабинет подписчика и лестницу писем: напоминание, неудачная попытка, пауза, возврат клиента после отмены.
Настраиваем отчётность по MRR, оттоку и когортам, запускаем подписку и разбираем первые циклы списаний.
Классический вариант — привязка банковской карты и последующие списания по согласию клиента: платёжный провайдер хранит токен, вы храните только идентификатор привязки. Второй путь — автоматические платежи через СБП, когда согласие оформляется в приложении банка клиента, а списание инициируется по расписанию.
Практика показывает, что стоит поддерживать оба способа: часть клиентов не хочет оставлять карту, часть предпочитает карту и не пользуется банковскими приложениями. Важнее то, что при смене способа оплаты подписка обязана сохраниться, а не создаваться заново.
Основа — платёжный слой: привязка карты, расписание списаний, повторные попытки, обработка истёкших и перевыпущенных карт, фискализация каждого автоматического платежа. Второй блок — управление тарифами: пересчёт при смене плана, пробные периоды, промокоды, пауза и отмена.
Третий блок — личный кабинет подписчика и коммуникации, четвёртый — отчётность по метрикам и выгрузки для бухгалтерии. Стоимость заметно растёт, если требуется несколько платёжных провайдеров или поддержка нескольких юрисдикций, поэтому такие требования лучше выявлять на старте.
Самые частые потери возникают не из-за цены, а из-за обработки отказов: клиент не получает письма, доступ закрывается мгновенно, оплатить вручную негде. Мы всегда закладываем несколько попыток списания с разными интервалами, письма с понятной формулировкой и возможность обновить карту без обращения в поддержку.
Вторая распространённая проблема — отсутствие гибкости: нет паузы, нет перехода на младший тариф, нет понятной отмены. Клиенту проще уйти совсем, чем разбираться. Реалистичный срок запуска подписки — от двух до четырёх месяцев с учётом интеграций и фискализации.
От двух до четырёх месяцев в зависимости от числа платёжных провайдеров и сложности тарифов. Быстрее всего запускается один тариф с одним циклом и одной попыткой повторного списания. Дольше всего занимает не разработка, а настройка фискализации автоматических списаний и согласование правил пересчёта при смене тарифа.
Из платёжного слоя с привязкой карты, расписанием списаний и повторными попытками, управления тарифами с пересчётом неполного периода, личного кабинета подписчика, лестницы писем и отчётности по метрикам. Отдельно считаются фискализация каждого списания и выгрузки для бухгалтерии. Если платёжных провайдеров несколько или нужна поддержка разных способов оплаты, стоимость интеграции и объём тестирования заметно возрастают.
Главный риск — технический отток: клиент уходит не из-за цены, а из-за того, что списание не прошло без объяснений или карту нельзя обновить. Второй риск — расхождение сумм при смене тарифа и претензии по чекам. Оба снимаются заранее: повторные попытки с письмами, понятный кабинет и фискализация на каждое автоматическое списание.
Опишите продукт, который будет поставляться регулярно, и желаемый цикл оплаты: месяц, квартал или год. Затем определите, что происходит при неудачном списании и как клиент может поставить подписку на паузу. С этими ответами мы предложим схему рекуррента и покажем, как считать отток и выручку подписки.
Смежные задачи, которые обычно решаются в одном проекте с этой.
Расскажите про продукт и цикл оплаты — предложим схему рекуррента и покажем, как считать отток с первого месяца.
Cookie и аналитика
Мы используем необходимые cookie для работы сайта и форм. Аналитические cookie (Яндекс.Метрика, включая запись сессий) подключаем только с вашего согласия — от него можно отказаться. Подробнее: Политика использования cookie и обработка персональных данных.