Биллинг в SaaS: подписки, апгрейды и возвраты без боли
Как устроить биллинг SaaS: выбор между Stripe и Paddle, проратация при смене тарифа, обработка вебхуков, неудачные платежи и учёт налогов.
Биллинг кажется простой задачей ровно до первого апгрейда посреди оплаченного периода. Дальше начинаются перерасчёты, возвраты, налоги, неудачные списания и расхождения между тем, что видит пользователь, и тем, что записано в базе. Разберу, как собрать биллинг так, чтобы он не требовал ручных правок каждую неделю.
Stripe или Paddle
Ключевое различие не в возможностях, а в том, кто является продавцом. Paddle выступает merchant of record: он сам выставляет счета конечному покупателю и отвечает за налоги в разных странах. Stripe — платёжная инфраструктура, налоги и отчётность остаются на вас.
| Ситуация | Подходит | Почему |
|---|---|---|
| Продажи по всему миру, маленькая команда | Paddle | Налоги и счета берёт на себя сервис |
| Нужны нестандартные тарифы и сложная логика | Stripe | Больше гибкости и контроля |
| Важна минимальная комиссия при росте | Stripe | Ниже совокупная стоимость на объёме |
| Нет ресурса на налоговый учёт | Paddle | Меньше юридической нагрузки |
Модель данных: подписка — это состояние, а не запись об оплате
Храните у себя минимум: идентификатор клиента и подписки в платёжной системе, тариф, статус, дату окончания оплаченного периода. Доступ к функциям выдавайте по состоянию подписки, а не по факту последнего платежа. Такой подход переживает частичные возвраты, ручные продления и смену тарифа.
Вебхуки: место, где ломается чаще всего
- Проверяйте подпись запроса до любой обработки данных.
- Делайте обработку идемпотентной по идентификатору события: повторная доставка — норма, а не сбой.
- Сохраняйте все события в базу до обработки — это спасает при разборе спорных ситуаций.
- Отвечайте быстро, тяжёлую работу выносите в очередь.
- События приходят не по порядку: ориентируйтесь на состояние подписки, а не на последовательность.
Апгрейды, даунгрейды и проратация
Договоритесь о правилах до реализации и опишите их в интерфейсе: повышение тарифа обычно применяется сразу с перерасчётом остатка, понижение — с начала следующего периода. Неочевидные перерасчёты — частая причина обращений в поддержку и возвратов.
Неудачные платежи и отток
До 30% оттока в подписочных продуктах — технический: истёк срок карты, банк отклонил списание. Настройте повторные попытки по расписанию, письма с просьбой обновить карту и период ограниченного доступа вместо мгновенного отключения. Это самый дешёвый способ поднять выручку без привлечения новых клиентов.
Хороший биллинг незаметен: пользователь понимает, за что платит, а команда не правит подписки руками.
Чек-лист перед запуском оплаты
- Проверены сценарии: первая оплата, продление, апгрейд, даунгрейд, отмена, возврат.
- Есть страница с историей платежей и счетами.
- Настроены алерты на неудачные списания и на расхождение статусов.
- Тестовый и боевой ключи разделены, вебхуки проверены в обоих окружениях.
- Оферта и условия возврата опубликованы и соответствуют логике продукта.