Минимальный биллинг для MVP: что нужно настроить до первого платного запуска

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

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

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

Оплата прошла. Что дальше?

Возьмем сервис для email-рассылок, который запускает платную подписку. Пользователь открывает платежную форму, вводит данные карты, платеж проходит успешно. Деньги списаны, чек выбит. А продукту ещe только предстоит понять, когда и насколько открывать доступ к сервису: купил ли клиент месяц или год, тариф на 1000 писем или безлимит, и что показать ему в личном кабинете.

Здесь важно разделить несколько связанных сущностей: покупку, платeж, период и статус доступа. Покупка фиксирует, что именно выбрал клиент. Платеж подтверждает, что этот выбор оплачен. На основании оплаты система определяет конкретные даты начала и окончания оплаченного срока подписки. А уже период определяет, должен ли пользователь иметь доступ к сервису в текущий момент.

Поэтому после успешной оплаты нужно определить, на какой срок произведена оплата и с какой даты он действует. Если это первая покупка, период может начинаться с момента оплаты. Если пользователь продлевает действующую подписку заранее, новый срок начинается после окончания текущего, а не в момент нового списания. Пока оплаченный период действует, доступ остается активным. Когда он заканчивается, система должна определить следующий шаг: получить оплату за новый период, если включено автопродление, или перевести подписку в другое состояние, если продление не состоялось.

При автопродлении по окончании срока подписки выполняется новая попытка оплаты. Если она успешна, создается следующий оплаченный период, и доступ продолжается без перерыва. Если списание не проходит, система действует по правилам продукта: например, запускает грейс-период или закрывает доступ.

При ручной оплате нового срока автоматического списания нет. Клиент сам оплачивает продление, а система после успешного поступления средств определяет новый оплаченный период и обновляет статус доступа. Если текущий период уже закончился, доступ может быть закрыт до новой оплаты; если пользователь оплатил заранее, новый период может начаться после окончания текущего.

Таким образом, схема выглядит так: 

При этом платeж — только одно из событий в этой цепочке, а оплаченный период задаeт временные границы, в которых доступ должен оставаться корректным.

Какие сценарии нужно предусмотреть до запуска стартапа

До старта продаж стоит заранее определить, как продукт будет действовать в трех ключевых сценариях, даже если на первом этапе сам процесс ещe не автоматизирован.

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

Неудачное списание. Здесь на старте допустим полуручной процесс, но правила важно определить заранее. Доступ закрывается сразу или сначала начинается грейс-период? Какой статус в этот момент видит пользователь? Кто узнает о проблеме: сам клиент, поддержка или никто, пока клиент сам не обратится?

Окончание оплаченного периода. Что делать при завершении оплаченного периода зависит от модели оплаты. При автопродлении система выполняет новую попытку списания: если платеж успешен, то начинается следующий оплаченный период и доступ продолжается. Если нет — срабатывает заранее определенное правило: грейс-период или закрытие доступа. При ручной оплате нового списания нет: период заканчивается, и клиенту можно напомнить о продлении. Главное заранее определить правила для каждого сценария.

Для второго и третьего юзкейс на старте не обязательно сразу все автоматизировать. При автопродлении по окончании периода выполняется новая попытка оплаты. Важно сначала определить правила и понять, как команда будет обрабатывать такие случаи. Если их немного, на первых этапах это вполне можно делать вручную. По мере роста числа операций отдельные сценарии можно автоматизировать.

Что не стоит делать при запуске стартапа

Десяток тарифов, гибкая система скидок, промокоды, автоматический пересчет стоимости при смене тарифа и подробная аналитика по платежам просто не нужны. Это имеет смысл добавлять только тогда, когда понятно, кто платит, за что и по какой модели монетизации. До подтверждения product-market fit вкладываться в гибкость, которая может не понадобиться, дороже, чем потом переделать простую версию под подтвердившийся спрос.

Но не всe, что можно отложить, стоит делать вручную. Если сценарий напрямую связан с деньгами клиента, цена ошибки может оказаться выше стоимости автоматизации. Например, пересчeт стоимости при апгрейде тарифа посреди оплаченного периода может происходить регулярно, и ошибка в нeм приведeт к неправильному списанию. В такой ситуации готовый биллинг позволяет сразу закрыть критичный сценарий, не разрабатывая его самостоятельно. А менее критичные функции можно добавить позже, когда появится реальная потребность.

Ниже семь пунктов, которые стоит сделать до запуска платежей.

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

• Что именно покупает клиент: тариф, набор функций, объeм использования.

• Как рассчитывается стоимость: цена, период оплаты и правила для разных вариантов покупки.

• Как определяется оплаченный период: когда он начинается, когда заканчивается и что происходит при досрочном продлении.

• Что происходит после успешной оплаты: какой статус получает подписка и какой доступ открывается пользователю.

• Что происходит при изменении подписки: апгрейде, даунгрейде, отмене или смене тарифа посреди оплаченного срока.

• Что происходит при неуспешном платеже: какой статус получает подписка, сохраняется ли доступ и когда он закрывается.

• Как подписка продлевается: автоматически или вручную, кто запускает продление и что происходит после окончания периода.

Если на все семь пунктов есть ответ, минимальный биллинг для стартапа готов к запуску.

Когда MVP биллинга становится мало

MVP биллинга перестаeт справляться, когда сама модель монетизации становится сложнее. Появляются апгрейды и даунгрейды посреди оплаченного периода, разные правила расчeта для клиентов, usage-based тарификация, B2B-сценарии с закрывающими документами. Одновременно растет число операций, которые уже сложно контролировать вручную.

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

Итог

До product-market fit биллинг не должен становиться отдельным большим проектом. На старте достаточно определить основные правила монетизации и автоматизировать критичные сценарии, связанные с оплатой, периодом подписки и доступом.

Если для проверки модели монетизации уже нужен полноценный расчeт подписок, продления и статусов, необязательно разрабатывать эту систему с нуля. Готовый биллинг позволяет закрыть необходимые сценарии без большой первоначальной разработки, а по мере роста продукта можно добавлять новые правила и усложнения вместе с самой моделью монетизации.