Выберите тему — соберём контекст
Проектируем и разрабатываем биллинг для SaaS: тарифы и лимиты, учёт потребления, подписки с переходами между планами, счета и закрывающие документы, повторные списания и управленческая картина выручки.
Начинаем с денежной логики, а не с кода. Ошибка в биллинге стоит не часов разработки, а живых денег и доверия клиентов — поэтому корректность начислений мы доказываем прогоном истории и сверкой с вашим учётом до запуска.
Или сразу: +7 (495) 368-39-51 Telegram Пн–Пт, 10:00–19:00 МСК
Расскажите, как вы берёте деньги сейчас. Скажем, что нужно поправить в первую очередь, и оценим объём работ — без обязательств.
У каждой проблемы есть цена: время финансов, споры с клиентами, потерянная выручка или регуляторный риск. Если узнали свою ситуацию — это и есть содержание первого созвона.
Финансы сводят подписки, апгрейды и потребление в Excel, потому что в продукте нет источника правды по деньгам.
Чем обходится: Расхождения всплывают в закрытии месяца, счета уходят с неверными суммами, а бухгалтерия тратит дни на сверку вместо работы.
Что делаем: Единый сервис биллинга: начисление формируется системой и объясняется по шагам — от тарифа и периода до событий потребления.
Апгрейд в середине периода, даунгрейд, пауза, возврат и продление — каждый случай считается «на глаз» или вообще не считается.
Чем обходится: Клиент платит дважды или не платит вовсе. Спорные счета, возвраты, ручные корректировки и потерянное доверие.
Что делаем: Правила пропорционального пересчёта описываются до разработки и реализуются как часть модели начислений, включая кредиты и отложенные изменения.
API-вызовы, гигабайты, минуты и места считаются постфактум или не считаются вообще, поэтому usage-based тариф запустить нельзя.
Чем обходится: Вы теряете самую маржинальную модель монетизации: клиент платит фиксированную цену, даже когда потребляет в десять раз больше.
Что делаем: Metering: приём событий потребления с идемпотентностью, агрегация по периодам и лимитам, пороговые уведомления, пересчёт при спорных начислениях.
Платёжный провайдер присылает один и тот же вебхук дважды, а обработчик создаёт второе начисление или повторно продлевает подписку.
Чем обходится: Возвраты, обращения в поддержку, чарджбэки и репутационный след: списание денег без основания — самая дорогая ошибка в SaaS.
Что делаем: Все операции записи идемпотентны по ключу события, состояние подписки меняется транзакционно, а журнал операций позволяет разобрать любой инцидент.
Просроченная карта или недостаток средств — и подписка просто умирает: без повторных попыток, писем и льготного периода.
Чем обходится: Отток, который выглядит как «клиент ушёл сам», хотя на самом деле не прошёл платёж. Это самый дешёвый в возврате отток — и он теряется.
Что делаем: Dunning: расписание повторных попыток, уведомления клиенту, льготный период с сохранением доступа и понятные правила ограничения.
Счета, акты, корректировочные документы и чеки делают вручную или не делают совсем, 54-ФЗ закрывается «как-нибудь».
Чем обходится: Бухгалтерия собирает документы руками, корпоративные клиенты не могут провести оплату, а по чекам и ЭДО накапливается регуляторный риск.
Что делаем: Документальный контур в биллинге: счёт, акт, чек, корректировки и выгрузка в 1С и ЭДО, сверка сумм с платежами.
Вебхуки приходят с задержкой или не приходят, часть платежей «висит» в неизвестном статусе, а сверка с эквайрингом делается раз в квартал.
Чем обходится: Оплаченный клиент остаётся без доступа, а неоплаченный — с доступом. Обе ошибки стоят денег и разбираются вручную.
Что делаем: Регулярная автоматическая сверка с эквайрингом, «догоняющая» синхронизация статусов и алерты на расхождения, а не отчёт постфактум.
Постоплата по договору, закрывающие документы, лимиты и квоты, мультивалютность, НДС, отдельные условия и скидки за объём.
Чем обходится: Сделки с крупными клиентами закрываются вне продукта, вручную, и каждая такая сделка — это риск ошибки и потерянная масштабируемость.
Что делаем: Контрактные условия как часть модели: индивидуальные тарифы и скидки, постоплата, лимиты, валюты и налоговые правила по юрисдикциям.
Непонятно, из чего сложилась сумма: какой тариф, какой период, какие события потребления и какие скидки.
Чем обходится: Каждый спорный счёт разбирается вручную силами разработчиков, а клиент уходит с ощущением, что ему «насчитали».
Что делаем: Трассировка начисления: сохраняем всю цепочку расчёта, а не только итог, и отдаём её в интерфейсе клиента и в поддержку.
Биллинг работает «как-то», но переписывать его никто не решается: слишком велик риск остаться без выручки.
Чем обходится: Проект замирает на годы, продукт не может запустить новые тарифы, а стоимость изменений растёт с каждым месяцем.
Что делаем: Миграция без остановки продаж: параллельный расчёт на исторических периодах, сверка сумм с текущим учётом, поэтапное переключение с возможностью отката.
Биллинг собирается как отдельный сервис с чёткими границами: продуктовую логику можно менять, не переписывая денежную, и наоборот. Ниже — что именно входит в работу.
Оплата за место, за объём, за функцию или фиксированная подписка — в одном каталоге.
Что входит в план, что считается сверх и как это сообщается клиенту до списания.
Пакеты сверх тарифа: места, хранилище, вызовы API, дополнительные модули.
Trials, промокоды, скидки за период и за объём, индивидуальные условия.
Новая редакция тарифа не ломает уже оформленные подписки: старые условия живут до конца периода.
Что происходит при апгрейде, даунгрейде, паузе, отмене и возобновлении — описано явно.
API и вебхуки для событий потребления, батчи, идемпотентность по ключу события.
Свёртка по периодам, клиентам и метрикам, включая поздние события и корректировки.
Вызовы, объём, минуты, места, проекты — набор метрик задаётся тарифом.
Предупреждение на 80% лимита, мягкое ограничение вместо резкой блокировки.
Пересчёт по обращению с полной историей: что учли, что и почему изменили.
Rate limiting на приём событий и проверка аномалий, чтобы метрику нельзя было раздуть.
Триал, активна, просрочена, приостановлена, отменена, возобновлена — с правилами перехода.
Апгрейд и даунгрейд в середине периода считаются корректно, с переносом остатка.
Смена тарифа вступает в силу в конце периода, если так настроена политика.
Остановка списаний с сохранением данных и правилами возврата доступа.
Каждое изменение подписки видно клиенту и поддержке с датой и причиной.
Тарифы и платежи в разных валютах, курс фиксируется на момент списания.
Автоматическое формирование по периодам, с корректными реквизитами и суммами.
Фискализация через ОФД с учётом возвратов и корректировок.
Пересчёты, скидки и сторно оформляются документами, а не правками «в базе».
Отправка документов через оператора, статусы подписания и хранение.
Синхронизация начислений, платежей и документов, сверка расхождений.
Ставки и правила зависят от страны клиента: закладываем это в модель, а не в отчёт.
Подключение провайдера, токенизация карт, рекуррентные списания, 3-DS-сценарии.
Повторный вебхук или повторный запуск задачи не создаёт второе начисление.
Расписание ретраев с учётом кода ошибки и поведения провайдера.
Доступ сохраняется, пока идут попытки: политика задаётся бизнесом, а не разработчиком.
Письма и напоминания на понятном языке со ссылкой на обновление карты.
Полные и частичные, с привязкой к начислению и отражением в документах.
Ежедневное сопоставление статусов платежей с эквайрингом и алерты на расхождения.
Выручка и её разложение: новые, расширение, сжатие, отток — по правилам SaaS-метрик.
Отток по клиентам и по выручке, отдельно вынужденный (не прошёл платёж).
Юнит-экономика по каналам и сегментам, а не «средняя температура».
Удержание по месяцам подключения, влияние тарифа и онбординга.
Ожидаемые списания и вероятность сбора по активным подпискам.
Реестр начислений, платежей и задолженности в привычном бухгалтерии виде.
Клиенты, подписки, начисления, платежи, лимиты и документы в одном месте.
Начисление и списание вручную с обязательным комментарием и автором операции.
Финансы, поддержка, администратор, аудитор — разные наборы прав и запрет на лишнее.
Кто, что и когда изменил: восстановимость истории для аудита и разбора инцидентов.
Публичный API и события для интеграций, версионирование контракта.
Песочница, где можно прогнать тарифы и списания без реальных денег.
Модель монетизации важнее технологии: от неё зависит и схема данных, и интерфейс, и то, сможете ли вы продавать крупным клиентам. Выбираем её на первом этапе.
Командные продукты, где ценность растёт с числом пользователей
API, инфраструктура, обработка данных, объёмные продукты
B2B-продукты: базовая подписка плюс доплата за объём
Крупные клиенты: счёт по факту периода, закрывающие документы, отсрочка
Подвиньте параметры — это та же арифметика, которую биллинг должен считать сам: фиксированный план, места, потребление и скидка за годовую оплату.
Ставки в примере условные: 49 000 ₽ — план, 990 ₽ за место, 12 ₽ за ГБ. В реальном проекте они задаются в каталоге тарифов и меняются без релиза.
Мы не продаём разработку там, где она не нужна. Если задачу закрывает готовая платформа — скажем это на первом созвоне и сэкономим вам бюджет.
Stripe Billing, вендорные модули подписок
Простые тарифы, оплата картой, нет требований к 1С, ЭДО и закрывающим документам по российским правилам.
Отдельный сервис или модуль внутри продукта
Постоплата, счета и акты, интеграция с 1С, сложный usage-based биллинг, требования держать данные в своём контуре.
Платежи у провайдера, логика начислений у вас
Чаще всего оптимальный вариант: приём денег и токенизация — на стороне провайдера, тарифы, лимиты и начисления — свои.
Мы не обещаем проценты роста: эффект зависит от вашей модели и объёма. Но эти шесть изменений видны сразу после запуска и проверяются по вашим же данным.
Начисления, документы и сверка уходят из таблиц в систему: финансы закрывают месяц, а не собирают его.
Dunning и повторные попытки возвращают платежи, которые раньше превращались в «клиент ушёл».
Идемпотентность и журнал операций убирают самую дорогую ошибку биллинга — списание без основания.
Новый план, лимит или дополнение настраиваются в админке без релиза продукта.
MRR, ARR, churn и когорты считаются по правилам SaaS-метрик, а не в чужой таблице.
Постоплата, счета, акты, ЭДО и лимиты позволяют продавать крупным клиентам без ручных исключений.
Воспроизводимость — главное требование к биллингу: любое начисление должно объясняться, а любая повторная операция — не создавать вторую. Ниже — обязательства, которые фиксируются в договоре и проверяются на приёмке.
Повторный вебхук, ретрай задачи или двойной клик не создают второе начисление: ключ операции уникален.
Храним не только сумму, но и всю цепочку расчёта: тариф, период, события, скидки, кредиты.
Смена состояния подписки и запись платежа происходят вместе: «оплачено, но не продлено» невозможно.
Изменение плана не переписывает историю: старые подписки доживают период по прежним условиям.
Апгрейды, даунгрейды, паузы, возвраты, прыжки через период и переходы на летнее время — в автотестах, а не в голове разработчика.
Ежедневный автоматический прогон: расхождение статусов и сумм превращается в алерт, а не в квартальный сюрприз.
Очереди и ретраи для вебхуков, резервные копии, регламент восстановления и проверка восстановления, а не только бэкап.
Параллельный расчёт на исторических периодах, поэтапное переключение и возможность откатить на прежний контур.
Биллинг — единственное место в продукте, где сходятся платежи, персональные данные и бухгалтерия. Поэтому периметр безопасности и документальный контур мы проектируем до разработки, а не добавляем «когда-нибудь потом».
Обсудить требования ИБ и бухгалтерииДанные карт не хранятся у вас: используется токенизация и платёжные формы провайдера, поэтому область аудита остаётся узкой.
Финансы, поддержка, администратор и аудитор видят ровно то, что нужно: массовые операции и экспорт ограничены правами.
Каждое действие с деньгами и персональными данными фиксируется: субъект, объект, время, результат.
Минимизация полей, шифрование чувствительных значений, экспорт и удаление данных клиента по запросу.
Чеки, акты и корректировки формируются в соответствии с требованиями юрисдикции и выгружаются в учётную систему.
Для требовательных клиентов — работа в вашей инфраструктуре, без выноса персональных данных за её пределы.
Биллинг бесполезен в изоляции: он должен сходиться с эквайрингом, бухгалтерией и учётными системами. Наличие коннектора подтверждаем на этапе архитектуры — и говорим заранее, если у сервиса нет открытого API.
Сначала описываем правила начислений, потом автоматизируем. Каждый этап заканчивается артефактом, по которому можно принять решение — продолжать в том же виде или менять подход.
Описываем тарифы, метрики потребления, правила переходов, политику возвратов и документы. На выходе — согласованная денежная логика, а не догадки.
Модель данных: тарифы, подписки, события потребления, начисления, платежи, документы. Определяем, что выносим в отдельный сервис, а что оставляем в продукте.
Каталог тарифов, metering, жизненный цикл подписки, начисления и документы. Каждые 1–2 недели — работающая версия на тестовом стенде.
Эквайринг и рекуррентные списания, dunning, чеки и ЭДО, выгрузка в 1С, сверка с провайдером и учётной системой.
Пересчитываем прошлые периоды, сверяем суммы с текущим учётом, разбираем расхождения до запуска — а не после первых счетов.
Поэтапное переключение с возможностью отката, обучение команды, документация, регламенты эксплуатации и разбора инцидентов.
Нижние границы — это опубликованные пакеты сайта, а не «средняя цена по рынку». Итоговая смета зависит от модели монетизации, документов, интеграций и миграции, и фиксируется до первой строки кода.
Если биллинг уже есть, но не сходится, или вы только выбираете модель монетизации.
Первая версия SaaS с тарифами, подписками и приёмом платежей — опубликованный пакет SaaS-MVP.
Для работающего продукта: usage-based биллинг, B2B-требования, документы и интеграции — уровень пакета «Рост».
Биллинг живёт: меняются тарифы, провайдеры и требования. Поддержка — это часть эксплуатации, а не «доработки по часам».
Четыре пункта, без которых биллинг не спроектировать. Всё остальное — наша работа.
Как вы берёте деньги сейчас и как хотите брать: тарифы, лимиты, скидки, постоплата, валюты.
Форма счёта и акта, требования бухгалтерии, работа с ЭДО и чеками, налоговые ставки.
Эквайринг, ОФД, ЭДО, 1С: тестовые и рабочие доступы или контакты ответственных людей.
Человек, который принимает решения по спорным начислениям и политике ограничения доступа.
Отвечаем так же, как ответили бы на первом созвоне: про деньги, сроки, готовые платформы, документы, безопасность и миграцию.
Нижняя граница — от 449 000 ₽: это опубликованный пакет SaaS-MVP, в который биллинг входит вместе с тарифами, подписками и приёмом платежей. Выделенный сервис биллинга для работающего продукта с usage-based моделью, документами, постоплатой и интеграциями — ориентир от 890 000 ₽ (уровень опубликованного пакета «Рост»). Итоговая смета зависит от числа моделей монетизации, объёма интеграций и миграции; фиксируем её после аудита и до первой строки кода.
Зависит от модели монетизации и юрисдикции. Если нужны простые тарифы, оплата картой и нет требований к закрывающим документам по российским правилам — готовая платформа дешевле и быстрее. Свой биллинг нужен там, где есть постоплата, счета и акты, интеграция с 1С, сложный usage-based биллинг или требование держать данные внутри контура. Часто оптимален гибрид: приём платежей у провайдера, логика тарифов и начислений — у вас.
Ориентир для биллинга внутри продукта — 10 недель вместе с тарифами, подписками и платежами. Выделенный сервис биллинга — 14–16 недель: добавляются metering, документы, постоплата, интеграции и миграция. Разбор модели монетизации занимает 1–2 недели, проектирование схемы — 2–3 недели, прогон истории и сверка — ещё 2–3 недели. Точный срок фиксируем в договоре после аудита.
Поддерживаем три схемы: оплата по факту за период, предоплата пакета с переносом остатка на следующий период и гибрид с базовой ставкой плюс цена за перерасход. Схема фиксируется в тарифе, а расчёт опирается на агрегированные события потребления, поэтому клиент всегда может открыть детализацию и увидеть, из чего сложилась сумма.
Запускается сценарий dunning: повторные попытки по расписанию с учётом кода ошибки, уведомления клиенту и льготный период, в течение которого доступ сохраняется. Если оплата так и не поступила, доступ ограничивается по заранее определённым правилам, а подписка переходит в статус просроченной — без ручного вмешательства поддержки.
Все операции записи идемпотентны: повторный вебхук или повторный запуск задачи не создаёт второе начисление, потому что операция привязана к уникальному ключу события. Смена состояния подписки и запись платежа происходят в одной транзакции, ведётся журнал операций, а состояние подписок регулярно сверяется с данными эквайринга — расхождения выявляются автоматически, а не по жалобе клиента.
Да, и мы делаем это без остановки продаж. Выгружаем текущие подписки и платежи, приводим их к новой модели тарифов, затем обязательно прогоняем прошлые периоды параллельно с текущим учётом и сверяем суммы. Расхождения разбираются до запуска: это дешевле, чем объяснять клиентам неверные счета после переключения. Переключение идёт поэтапно, с возможностью отката.
Мы проектируем так, чтобы платёжные данные не хранились в вашей системе: используются токенизация и платёжные формы провайдера, а у вас остаётся только идентификатор токена. Это заметно сужает область аудита PCI DSS. Если по каким-то причинам хранение необходимо, это отдельное проектное решение с соответствующими требованиями — и мы скажем об этом на этапе архитектуры, а не после.
Документальный контур входит в биллинг: счёт и акт формируются автоматически по периодам с корректными реквизитами и суммами, чеки фискализируются через ОФД по 54-ФЗ, корректировки и сторно оформляются документами, а не правками в базе. Документы отправляются через ЭДО и выгружаются в 1С, чтобы бухгалтерия не собирала их вручную.
Три уровня. Первый — автотесты денежных сценариев: апгрейды и даунгрейды в середине периода, паузы, возвраты, перерасход лимита, повторные вебхуки, границы месяцев. Второй — прогон исторических периодов с построчной сверкой сумм против текущего учёта. Третий — эксплуатационная сверка с эквайрингом и учётной системой на регулярной основе, с алертами на расхождения.
Начинаем с аудита: разбираем модель начислений, находим источники расхождений, проверяем идемпотентность, сверку с провайдером и документы. Дальше говорим честно — дорабатывать или выносить в отдельный сервис. Иногда дешевле починить текущий контур и добавить недостающие проверки; мы так и скажем, если это ваш случай.
Вам. Исходный код, схема данных, тарифные планы, документация и регламенты передаются в ваши репозитории и инфраструктуру. Мы не удерживаем биллинг в своём контуре: продукт можно передать другой команде или развивать своими силами, потому что денежная логика описана документально.
Да. Постоплата по договору, индивидуальные тарифы и скидки за объём, лимиты доверия, отсрочка, закрывающие документы и отдельные правила ограничения доступа при просрочке. Это часть модели начислений, а не ручные исключения: у каждого клиента свои условия, но считается всё одной системой.
Биллинг — источник правды по деньгам, поэтому он отдаёт события продукту и аналитике: смену тарифа, оплату, просрочку, лимиты. Из этих событий собираются MRR, ARR, отток и когорты по правилам SaaS-метрик, а также триггеры для онбординга и удержания. Так продукт видит выручку в реальном времени, а не в отчёте за прошлый месяц.
Предлагаем сопровождение: мониторинг начислений и расхождений, реакция на инциденты по SLA, добавление тарифов и правил монетизации, обновление интеграций, разбор спорных начислений и отчёт по качеству списаний. Если внутри есть команда — передаём всё с документацией и обучением, чтобы биллинг развивался без нас.
Расскажите, как вы берёте деньги сейчас: тарифы, лимиты, документы, провайдер. Мы скажем, что нужно поправить в первую очередь, что можно оставить как есть, и сколько будет стоить работа.
Опишите модель монетизации, документы и текущий учёт — вернёмся с составом работ, сроком и сметой.
Cookie и аналитика
Мы используем необходимые cookie для работы сайта и форм. Аналитические cookie (Яндекс.Метрика, включая запись сессий) подключаем только с вашего согласия — от него можно отказаться. Подробнее: Политика использования cookie и обработка персональных данных.