Продукт «Подписки»
Рекуррентные платежи с триальным периодом
В чём суть
ЮKassa принимает платежи для бизнеса. До этого мерчант мог брать с покупателя разовые платежи, а регулярные списания приходилось собирать самому через API — писать логику расписаний, повторных попыток и отмен. «Подписки» — готовый продукт, который закрывает это без разработки на стороне мерчанта.
Задача
- Еженедельные, ежемесячные и годовые подписки
- Триальный период
- Сквозной сценарий покупателя: оформление → активный период → выход
- Запуск на API с последующей передачей в ЛК
Моя роль
Проектировал сценарии. Сбор требований и интервью — вместе с исследователем.
Контекст
Мерчанту нужно было запускать подписочные продукты, не разрабатывая платёжную логику с нуля. Выделил ключевые сегменты для подписочной модели в России: НКО и благотворительность (крупнейший по доле), EdTech, телеком и интернет-провайдеры, фитнес, медиа и СМИ, МФО.
Механика
Мерчант настраивает подписку: периодичность, цена, длительность триала, повторные попытки при неудачном списании. Дальше платформа списывает деньги по расписанию сама: покупатель заранее получает уведомление о предстоящем списании, чек — после каждого платежа, и может отменить подписку в любой момент.
Что сделал
- Собрал требования: интервью с мерчантами и разбор 6 конкурентов
- Приоритизировал функциональность — что в первый релиз, что позже
- Спроектировал сквозной сценарий покупателя от оформления до отмены
- Прописал JTBD отдельно для мерчанта и для покупателя
- Разобрал сбойные сценарии: неудачное списание, исчерпание попыток, замена карты
пользователей API, выставляющих счета, использовали подписочную модель за первый месяц
из них повторили операцию
Подход
Исследования
Глубинные интервью с 10 мерчантами (6 Small, 4 Middle), у всех рекурренты уже настроены через API. Ключевые наблюдения:
- Внутри масс-сегмента обнаружились две подгруппы по техническим компетенциям: разработчики сайтов и ботов с опытом интеграций и владельцы микро-бизнеса, привлекающие специалистов. Ручная настройка привлекательна для обеих, но по разным причинам: первым — консолидация настроек в одном месте, вторым — контроль за платежами и экономия на подрядчике
- Middle-сегмент уже использует несколько платёжных шлюзов — для них гибкость API приоритетнее готовых настроек в ЛК
- Попытки списания после неудачного платежа настроены у всех мерчантов, хотя у конкурентов это не базовая функция
- Название подписки формально не базовая настройка, но мерчанты с несколькими тарифами активно его используют
- Уведомления о предстоящем платеже нужны не всем: там, где есть эмоциональные или социальные драйверы (доступ к экспертному каналу, благотворительность), мерчанты предпочитают оповещать; в сугубо функциональных продуктах наоборот, считая, что это снижает конверсию
Гипотезы по итогам интервью
- Масс-сегмент мотивирован перейти на ручную настройку сильнее, чем Middle: для Middle это означает пересмотр бизнес-процессов
- Для новых мерчантов, только подключающих ЮKassa, ручная настройка — потенциальное УТП
- Для Middle гибкое API важнее ручной настройки рекуррентов
- Настройка повторной попытки списания должна быть базовой, а не продвинутой
- Уведомления нужны не всем типам бизнеса — делать опциональными
Приоритеты из интервью
Ранжировал функциональность по тому, насколько часто и остро её называли мерчанты.
- Разовый и рекуррентный платёж, пробный период, выбор или ввод суммы, комментарий
- Контактные данные для отправки чека и возможность пропустить ввод почты — для самозанятых
- Уведомление о предстоящем платеже
- Выбор тарифа, пакета, вида платежа и срока подписки; уведомление о неудачном платеже
- Выбор способа оплаты, повторное списание, отключение доступа после неудачной попытки, отписка руками пользователя (требование регулятора)
Бенчмарки
Проанализировал 6 сервисов с ручной настройкой регулярных платежей из ЛК — CloudPayments, RoboKassa, Stripe, Loop, Продамус, Аинокс. У самих платёжных провайдеров функционал представлен слабо, но рынок насыщен вспомогательными сервисами под конкретные ниши (благотворительность, телеграм-каналы, обучающие курсы).
Классифицировал весь функционал по четырём уровням:
- База (есть у 4–6 из 6): даты начала и окончания, периодичность, количество списаний, название и цена товара, количество единиц, управление подпиской из ЛК
- База+: покупатель — поиск или создание, НДС, способ расчёта, настройка уведомлений
- Продвинутые: купоны и скидки, шаблоны и методы уведомлений, отмена подписки со стороны плательщика, скидки в зависимости от поведения
- Уникальные: выбор магазина, загрузка подписчиков списком из файла, время списания, пробный период, счёт-фактура для постоплаты вручную
Приоритизация
Итоговый список фич собрал из трёх источников: база и база+ по конкурентам; то, что не базовое у конкурентов, но настроено у всех мерчантов (попытка списания после неудачного платежа); то, что не базовое, но есть у коннекторов и полезно для разных тарифов (название подписки).
Проектирование
JTBD-сценарии отдельно для мерчанта (запуск, управление, доверие) и покупателя (оформление, активный период, контроль/выход). Сквозной сценарий покупателя: оформление (прозрачные условия списания, триал, привычный способ оплаты) → активный период (напоминания перед крупным списанием, чек после каждого платежа) → контроль и выход (быстрая отмена без препятствий, обновление платёжных данных без потери подписки, обзор всех подписок разом).
Метрики
Фин-модель строилась не на дополнительной комиссии, а на приросте числа мерчантов — тарификация осталась транзакционной. Поэтому ключевая метрика — доля мерчантов, начавших использовать подписочную модель, и повторное использование как индикатор того, что механика прижилась.
Сбойные сценарии
самый частый: карта заблокирована, перевыпущена или без средств. Настройку повторных попыток заложил в базовый уровень, а не в продвинутый, опираясь на данные интервью.
на API-этапе управление отдали мерчанту: платформа отправляет webhook о событии, решение об отключении доступа принимает система мерчанта. С реализацией кассовой части планируется перенести логику статусов на сторону платформы.
требование регулятора: покупатель должен иметь возможность отменить подписку самостоятельно, без звонков и удерживающих экранов. Заложил как обязательный элемент.
перевыпущенная карта не должна означать отмену подписки.
Сценарий подписки
Финальное решение — сквозной сценарий покупателя: оформление подписки с триалом, подтверждение и управление из письма. Сейчас реализована только часть с подключением через API — решение для личного кабинета в проработке.
Финальное решение — сквозной сценарий покупателя: оформление подписки с триалом, подтверждение и управление из письма. Сейчас реализована только часть с подключением через API — решение для личного кабинета в проработке.
Оформление
Условия списаний собраны на одном экране до оплаты: срок триала, периодичность, срок действия подписки и магазин. Кнопка показывает сумму к оплате сейчас — на триале это 0 ₽, чтобы покупатель не ждал списания. Почта нужна для чека и управления подпиской.
Подтверждение
На экране успеха главное — дата следующего списания: она отвечает на основной страх покупателя. Вход в управление подпиской доступен сразу, без поиска в письме.
Управление подпиской
Страница управления — единая точка контроля: статус, цена, периодичность, срок и почта, на которую уходят чеки и напоминания. Здесь сценарий расходится на две ветки: отмена подписки и смена почты.
Дальше — две ветки из одной точки. Обе построены одинаково: подтверждающая модалка поверх страницы управления, затем финальный экран с однозначной формулировкой результата и одним выходом в магазин.
Отмена подписки
Одно подтверждение без удерживающих экранов, скидок и вопросов «почему уходите» — так честнее и не раздражает пользователя.
Итог фиксируем прямым текстом: подписка отменена, списаний больше не будет. Дальше — только возврат в магазин.
Смена почты
Смена контакта не должна ставить подписку под угрозу, поэтому это отдельное короткое действие. Подписка остаётся активной.
В финале объясняем последствие, а не просто факт: новый адрес сохранён, и все важные уведомления пойдут на него.
Ограничения
Запуск начали с API-части — решение продуктовое/техническое, для быстрой поставки и тестирования в одной команде с последующей передачей в команду личного кабинета.