Вы запустили свой SaaS-продукт, привлекли первых десять платящих клиентов и теперь стоите перед решением, которое кажется куда более серьёзным, чем должно быть: на какой платформе биллинга подписок строить бизнес? Ошибётесь — и через восемнадцать месяцев потратите лихорадочную неделю на перенос тысяч активных подписок, молясь, чтобы ничего не сломалось. Угадаете — и биллинг станет невидимой инфраструктурой, о которой вы больше никогда не вспомните.
Ставки реальны. Примерно 20–40% всего оттока подписчиков — это недобровольный отток: клиенты, которые не собирались отменять подписку, но у которых истёк срок действия карты или платёж был отклонён, а никто не заметил этого вовремя. Один этот сбой, по отраслевым оценкам, съедает около 9% ежемесячного регулярного дохода (MRR), а истёкшие карты сами по себе становятся причиной 42% всех неудачных платежей. Какую бы платформу биллинга вы ни выбрали, она — осознаёте вы это или нет — становится вашей главной линией обороны от тихой ежемесячной потери выручки.
В разговоре о растущих SaaS-компаниях доминируют три платформы: Stripe Billing, Chargebee и Recurly. Каждая оптимизирована под свой тип компании. Вот как понять, какая из них ваша.
Короткий ответ
- Продукт создают разработчики, команда небольшая, важна скорость? → Stripe Billing
- Специалистам без технического бэкграунда нужно менять цены без заявки в тикет-систему? → Chargebee
- Enterprise B2B со сложными контрактами и метрикой использования, или возврат платежей — ваш главный рычаг? → Recurly
Теперь разберём, почему именно так.
Stripe Billing: выбор разработчика по умолчанию
Если ваши инженеры уже интегрировали Stripe для разовых платежей, Stripe Billing — путь наименьшего сопротивления. Это не сторонний инструмент, прикрученный сбоку, — это нативное расширение той платёжной инфраструктуры, которую вы, скорее всего, уже используете.
В чём сила:
- Последовательность API. API Stripe славится отличной документацией, а его CLI делает локальное тестирование вебхуков и событий подписки по-настоящему безболезненным — реальная экономия времени для команды из двух-трёх инженеров.
- Клиентский портал, который не нужно строить самим. Stripe поставляет готовый, брендируемый клиентский портал, где подписчики могут повысить или понизить тариф, обновить способ оплаты — и никогда не написать в вашу поддержку.
- Прозрачное ценообразование по факту использования. Отдельной платы за платформу нет — вы платите примерно 0,5% от обрабатываемого регулярного дохода, хотя дополнительные модули вроде Stripe Tax (+0,5% за транзакцию) и Stripe Revenue Recognition (+0,25%) складываются в заметную сумму, если они вам нужны.
Где возникает напряжение: Stripe Billing мощен, но ориентирован прежде всего на код. Если ваша модель ценообразования усложняется — представьте тарифы с уровнями, использованием и перерасходом, апгрейдами в середине цикла и пропорциональным пересчётом годовых контрактов — вы, скорее всего, будете писать и поддерживать собственную логику для крайних случаев, которые платформа "из коробки" не покрывает. А поскольку продукт рассчитан на разработчиков, специалист по маркетингу или финансам обычно не может безопасно поменять тариф без участия инженеров.
Кому подходит лучше всего: SaaS-компаниям на ранней стадии, где разработка ведёт продукт, с MRR примерно до $500 тыс., которым нужен кратчайший путь от «мы принимаем платежи» до «мы управляем подписками», и которые готовы держать часть логики биллинга в коде.
Chargebee: создан для экспериментов с ценообразованием
Вся причина существования Chargebee — гибкость. Это платформа выбора для команд, которые ожидают менять модель ценообразования, — а если вы основатель SaaS на первом-втором году, вы, вероятно, будете это делать. Почти каждая успешная SaaS-компания хотя бы раз пересматривает цены, разобравшись, что на самом деле ценят клиенты.
В чём сила:
- Управление тарифами без кода. Команды продукта и финансов могут создавать, тестировать и менять тарифные уровни, дополнения, купоны и гибридные модели «использование плюс фиксированная плата» без открытия пул-реквеста.
- Действительно справляется со сложностью. Многоуровневое ценообразование с перерасходом, годовые контракты с апгрейдом в середине срока, биллинг для нескольких юридических лиц — Chargebee часто единственная из трёх платформ, которая обрабатывает всё это нативно, без обходных путей.
- Сильные интеграции с учётными системами. Признание выручки и экспорт в бухгалтерские/ERP-системы здесь, как правило, зрелее, чем встроенные инструменты Stripe Billing, — а это важно, когда у вас появляется контролёр или внешний бухгалтер, закрывающий книги ежемесячно.
Где возникает напряжение: цена Chargebee ощутимо растёт, как только вы перерастаете бесплатный уровень (примерно $100 тыс. накопленного биллинга до того, как включаются фиксированные ежемесячные платежи — от нескольких сотен до более тысячи долларов), так что это более серьёзное финансовое обязательство, чем модель чистого процента от выручки, если вы ещё до выручки или только запускаетесь.
Кому подходит лучше всего: SaaS-компаниям, перерастающим свою первую модель ценообразования, особенно там, где непрофильные специалисты (руководитель отдела роста, финансовый лидер) должны сами управлять настройками биллинга.
Recurly: создан, чтобы остановить утечку
Позиционирование Recurly у́же, но для подходящей компании ценнее, чем у обоих конкурентов: платформа существует, чтобы сократить деньги, которые вы тихо теряете на неудачных платежах.
В чём сила:
- Умный dunning как основа продукта. Оптимизированная машинным обучением логика повторных попыток Recurly решает, когда и сколько раз повторить отклонённый платёж, вместо повторов по фиксированному расписанию, которое либо сдаётся слишком рано, либо раздражает клиента избыточными попытками.
- Прогноз оттока. Аналитика Recurly отмечает аккаунты в зоне риска — необычное снижение использования, повторяющиеся почти-сбои — до того, как они отменят подписку, давая вашей команде шанс вмешаться.
- Ценообразование в процентах от выручки без платы за платформу, похоже на Stripe Billing, что делает Recurly доступным для небольших компаний, оставаясь при этом конкурентоспособным для контрактов enterprise-уровня.
Где возникает напряжение: главная сила Recurly — dunning и возврат платежей — наиболее заметна при реальном объёме транзакций. Стартап из пяти человек с 40 клиентами разницы не почувствует; компания, обрабатывающая десятки тысяч ежемесячных платежей, почувствует её немедленно, ведь цифры это подтверждают: автоматизированный dunning возвращает 40–70% неудачных платежей, которые иначе были бы потеряны, против примерно 15% при отсутствии какого-либо вмешательства.
Кому подходит лучше всего: подписочным бизнесам — особенно B2C или высокообъёмным B2B, — где неудачные платежи представляют собой измеримую и растущую статью потерь, а также enterprise B2B SaaS со сложной метрикой использования и условиями контрактов.
Сравнение бок о бок
| Stripe Billing | Chargebee | Recurly | |
|---|---|---|---|
| Модель ценообразования | ~0,5% от регулярного дохода | Бесплатно до ~$100 тыс. накопленного биллинга, затем $599–$1199+/месяц | ~0,5% от регулярного дохода, без платы за платформу |
| Лучше всего для | Команд, ведомых разработкой, уже использующих Stripe | Специалистов без техбэкграунда, управляющих ценообразованием; сложных тарифных структур | Высокообъёмных бизнесов, борющихся с оттоком из-за неудачных платежей |
| Отличительная особенность | Готовый клиентский портал, чистый API/CLI | Конструктор тарифов без кода, нативная поддержка уровней+использования+контрактов | ML-оптимизированный dunning, аналитика риска оттока |
| Слабое место | Сложное ценообразование требует собственного кода | Ощутимая ежемесячная плата после роста за пределы бесплатного уровня | Менее гибкая для сильно нестандартной логики ценообразования |
| Типичная стадия компании | От pre-seed до Series A | Series A и далее, или частые изменения ценообразования | Любая стадия, где неудачные платежи — измеримая статья затрат |
Издержки переключения реальны — планируйте их заранее
Соблазнительно относиться к этому решению как к малорисковому («потом просто переключимся, если перерастём платформу»). На практике перенос живой базы подписок между платформами биллинга — один из самых болезненных проектов, которые может предпринять растущая SaaS-компания. Вы переносите не просто таблицу в базе данных — вы переносите:
- Активные способы оплаты. В зависимости от вовлечённых платформ вы можете не иметь возможности программно перенести сохранённые карты, а значит, некоторому проценту клиентов придётся повторно вводить платёжные данные — с риском оттока во время перехода.
- Пропорциональный пересчёт и состояние контрактов. Подписки в середине цикла, годовые контракты с неиспользованным кредитом и любые персональные скидки нужно воссоздать в точности, иначе клиентам выставят неверный счёт, а очередь в поддержку быстро заполнится.
- Непрерывность исторической отчётности. Дашборды MRR, оттока и когорт, зависящие от модели данных вашей платформы биллинга, могут показать разрывы после миграции, если вы тщательно не спланировали историческую доливку данных.
- Логику dunning и возврата платежей. Если вы, например, уходите от Recurly ради экономии, вы наследуете ответственность за воссоздание того уровня возврата платежей, который тихо обеспечивали её умные повторы.
Всё это не значит, что вы навсегда заперты на текущей платформе — множество компаний успешно мигрируют. Это лишь значит, что модель мышления «сейчас выберем самый дешёвый вариант, а переключимся потом» недооценивает, насколько дорогим на самом деле оказывается это «потом». Обычно дешевле немного заложиться с запасом на платформу, которая будет подходить вашей модели через двенадцать-восемнадцать месяцев, чем оптимизировать исключительно под сегодняшний счёт.
Простой способ принять решение
Задайте себе три вопроса по порядку:
- Моя инженерная команда небольшая, а логика биллинга простая? Если да, Stripe Billing позволит запуститься быстрее всего.
- Нужно ли непрофильным специалистам менять цены, или моя модель уже сложная (уровни + использование + контракты)? Если да, Chargebee стоит своей более высокой цены.
- Теряю ли я измеримую долю выручки из-за неудачных платежей и недобровольного оттока? Если неудачные платежи становятся растущим центром затрат, специализация Recurly окупает себя — часто уже в первых возвращённых транзакциях.
Основателям с MRR примерно до $100 тыс. стоит придавать большой вес «простоте настройки». Выше $500 тыс. MRR расчёт смещается в сторону эффективности платежей и их возврата, потому что даже небольшие процентные улучшения в возврате dunning превращаются в реальные деньги при таком масштабе.
Какую бы платформу вы ни выбрали, следите за этим
Независимо от того, какая платформа биллинга победит, одна проблема сама собой не исчезает: доход от подписок нужно правильно отражать в учёте, а не просто собирать. Платёж, успешно прошедший в Stripe, Chargebee или Recurly, не становится автоматически «выручкой» в ваших книгах в момент поступления денег на счёт — отложенный доход, возвраты, пропорциональные кредиты и платежи, сначала не прошедшие, а потом возвращённые, — всё это нужно сверять с тем, что показывает ваша платформа биллинга. Основатели, которые считают дашборд своего платёжного процессора источником финансовой истины, обычно оказываются теми, кого удивляет неразбериха в бухгалтерии перед первым привлечением инвестиций или подачей налоговой декларации.
Именно здесь окупаются хорошие привычки ведения учёта. Каждый платёж по подписке, возврат, восстановленный после dunning платёж и изменение тарифа — это транзакция, которой место в вашей бухгалтерской книге, а не только в отчётном интерфейсе платформы биллинга, которая не создавалась для того, чтобы одновременно служить вашей системой учёта.
Держите свои книги в такой же чистоте, как и стек биллинга
Выбор правильной платформы биллинга подписок решает лишь половину проблемы — точный учёт этого дохода составляет вторую половину. Beancount.io даёт основателям SaaS учёт в виде обычного текста — прозрачный, версионируемый и легко сверяемый с выгрузками из Stripe, Chargebee или Recurly, без привязки к вендору и без чёрного ящика вместо бухгалтерской книги. Загляните в документацию, чтобы увидеть, как она обрабатывает регулярную выручку, или изучите Fava для визуального дашборда по вашей книге учёта — а затем начните бесплатно и держите свою финансовую отчётность такой же проверяемой, как ваш код.