Подписки и биллинг в SaaS: тарифы, пробный период, рекуррентные платежи

Материал для основателей и разработчиков, которые проектируют подписки в SaaS и хотят заранее понять, где в биллинге прячутся сложности. Разберём, из каких сущностей состоит биллинг для SaaS, как устроены пробный период и автосписания, что делать при смене тарифа и неуспешной оплате, какие документы нужны юрлицам и физлицам и как надёжно обрабатывать уведомления от платёжного провайдера.

Из чего состоит биллинг

Снаружи биллинг выглядит как кнопка «Оплатить». Внутри это несколько связанных сущностей, и их стоит описать до начала разработки.

• Тариф — что входит в продукт и какие лимиты действуют: число пользователей, проектов, объём хранилища.
• Подписка — связь организации-клиента с тарифом: статус, начало и конец текущего периода, дата следующего списания.
• Платёжный метод — сохранённая у провайдера карта клиента. На вашей стороне хранится только идентификатор, а не номер карты.
• Платёж — попытка списания со статусом, суммой и ответом провайдера.
• Счёт — документ для юрлица, который оплачивают переводом.
• Событие — запись о каждом изменении: создана подписка, списание не прошло, тариф изменён. Из этих событий потом собирается история для поддержки и бухгалтерии.

Главное в этой схеме — статус подписки. От него зависит, что видит пользователь и какие действия выполняет система.

Тарифы и пробный период

Тарифы строят по одной из трёх логик: фиксированная цена за организацию, цена за пользователя или оплата по объёму (документы, сообщения, гигабайты). Для первой версии почти всегда хватает одного тарифа — как объясняем в статье о MVP SaaS, линейку тарифов вы ещё будете менять.

Лимиты тарифа проверяются на сервере в момент действия. Если на тарифе пять пользователей, шестое приглашение должно отклоняться API, а не только скрываться в интерфейсе.

С пробным периодом нужно решить, просить ли карту при регистрации. С картой меньше случайных регистраций и продление проходит автоматически, без карты — ниже порог входа, но к концу пробного периода клиента нужно отдельно довести до оплаты. Оба варианта рабочие, выбор зависит от того, как вы продаёте: самообслуживанием или через менеджера.

Рекуррентные платежи: как работают автосписания

Схема у большинства платёжных провайдеров похожа. Клиент один раз проводит оплату на странице провайдера и соглашается на автоматические списания. Провайдер сохраняет карту и возвращает вам идентификатор платёжного метода. Дальше в дату продления ваш сервер сам создаёт платёж по этому идентификатору, без участия клиента.

Данные карты при этом не попадают на ваши серверы, а значит, вам не нужно выполнять требования к хранению карточных данных — этим занимается провайдер. Условия подключения автоплатежей, способы отмены и требования к оферте уточняются у конкретного эквайринга.

Смена тарифа и перерасчёт

Переход между тарифами в середине периода — место, где биллинг чаще всего ошибается. Распространённая практика такая.

• Повышение тарифа применяется сразу. Клиент доплачивает разницу за оставшиеся дни: разница в месячной цене, умноженная на долю оставшегося периода. Допустим, клиент переходит на тариф дороже ровно в середине месяца — доплата составит половину разницы.
• Понижение тарифа обычно вступает в силу со следующего периода, чтобы не возвращать деньги и не пересчитывать уже оказанную услугу.
• Добавление пользователей на тарифе с оплатой за место считается так же, как повышение: доплата пропорционально оставшимся дням.
• Превышение лимитов после понижения тарифа: заранее решите, что происходит с лишними пользователями или проектами — блокировка, только чтение или запрет на понижение, пока лимит превышен.

Все суммы считайте в копейках целыми числами и фиксируйте правило округления, иначе на сверке с бухгалтерией появятся расхождения.

Неуспешные платежи и работа с просрочкой

Автосписание может не пройти: на карте нет денег, карта перевыпущена, банк отклонил операцию. Терять клиента из-за этого обидно, поэтому нужен понятный сценарий возврата к оплате.

1. Подписка переходит в статус «просрочена», доступ пока сохраняется.
2. Клиент получает письмо и видит баннер в интерфейсе со ссылкой на смену карты.
3. Система повторяет списание по расписанию, например через день и через несколько дней — график вы выбираете сами.
4. После льготного периода подписка приостанавливается: данные остаются доступны для просмотра и выгрузки, но изменять их нельзя.
5. Как только оплата прошла, доступ восстанавливается автоматически, без обращения в поддержку.

Данные клиента при просрочке не удаляйте. Срок хранения после окончания подписки закрепите в оферте и предупредите клиента до удаления.

Документы: счета и акты для юрлиц, чеки для физлиц

B2B-клиенты в России часто платят не картой, а по счёту. Значит, в сервисе нужна форма с реквизитами компании и генерация счёта, а после оплаты — закрывающие документы. Какие именно документы оформлять (акт, УПД) и как часто, определяет ваша бухгалтерия.

В первой версии оплату счёта можно отмечать в админке вручную после проверки выписки. Когда счетов станет много, подключают автоматическую сверку с банком или передачу документов в учётную систему — о связке с учётом подробнее в статье интеграция с 1С.

При оплате от физлиц действует 54-ФЗ: покупателю нужно выдать кассовый чек. На практике это решают через онлайн-кассу, подключённую к эквайрингу, или через кассовое решение самого провайдера — чек формируется и отправляется на email клиента автоматически. Конкретную схему и налоговые настройки чека согласуйте с бухгалтером и провайдером.

Если часть продаж идёт через мессенджер, там свои правила оплаты; о них — в статье приём оплаты в Telegram-боте.

Вебхуки и идемпотентность

Итог платежа приходит не на страницу «спасибо», куда вернулся клиент, а в уведомлении от провайдера на ваш сервер. Именно его нужно считать источником правды.

• Проверяйте подлинность уведомления способом, который описан в документации провайдера: подпись, секретный ключ или повторный запрос статуса платежа через API.
• Отвечайте быстро, а тяжёлую обработку выносите в фоновую задачу. Иначе провайдер решит, что уведомление не доставлено, и пришлёт его снова.
• Готовьтесь к повторам и нарушенному порядку. Одно событие может прийти дважды, а уведомление об отмене — раньше уведомления об оплате.
• Храните идентификатор события с уникальным ограничением в базе: повторное уведомление просто игнорируется, подписка не продлевается дважды.
• Передавайте ключ идемпотентности при создании платежа, если провайдер это поддерживает, чтобы повторный запрос после сетевой ошибки не создал второе списание.
• Сверяйтесь регулярно: фоновая задача сравнивает статусы платежей у себя и у провайдера и сообщает о расхождениях.

Мы обычно закладываем на обработку платёжных событий отдельные тесты: повтор, обратный порядок, таймаут. Это небольшая работа, которая избавляет от самых неприятных обращений в поддержку.

Чек-лист перед запуском биллинга

• Описаны статусы подписки и переходы между ними.
• Лимиты тарифа проверяются на сервере.
• Клиент видит дату и сумму следующего списания и может отключить автопродление.
• Есть сценарий для неуспешного платежа, данные при просрочке не удаляются.
• Правила перерасчёта при смене тарифа зафиксированы и покрыты тестами.
• Для юрлиц формируются счета, для физлиц отправляются чеки.
• Вебхуки проверяются, обрабатываются идемпотентно, есть регулярная сверка.

Частые вопросы

Обсудим проект

Нужна похожая разработка?

Расскажите о задаче — уточним детали, предложим формат запуска и подготовим предварительную оценку. Это бесплатно.

Ваше имя Способ связиTelegramVKMAXТелефонПочта

Контакт

Отправить заявкуНаписать напрямую

Опубликовано 12 октября 2026 г. · Обновлено 12 октября 2026 г.