Пошаговый план создания веб‑приложения для подписочного бизнеса: тарифы, платежи, счета, прорейтинг, налоги, безопасность, тестирование и запуск.
Приложение для подписок почти всегда начинается не с платежей, а с ответа на вопрос: какой продукт вы продаёте по подписке и какие решения должны принимать пользователи и команда поддержки. Если границы не зафиксировать, «биллинг» быстро расползается в бесконечный список хотелок.
Подписочная модель встречается в B2C (контент, обучение, утилиты), B2B (SaaS, сервисы для команд), а также в гибридных продуктах с доп. опциями. Во всех случаях пользователю важно одно и то же: выбрать план, оплатить, изменить или отменить, увидеть историю списаний и понять, что будет дальше.
Для бизнеса ключевое — предсказуемая выручка и минимум ручной работы: меньше «потерянных» платежей, меньше обращений в поддержку, больше прозрачности по статусам.
Чтобы не переделывать архитектуру через месяц, сразу заложите базовые сущности:
Это скелет, который позже позволит добавить скидки, доп. места, промокоды и т. п. без хаоса.
MVP обычно включает: создание подписки, автосписание, смену плана, отмену, страницу «Оплаты и документы», админ-инструменты для просмотра статусов.
«Полный» биллинг добавляет сложные сценарии: комбинированные планы, детальные начисления, массовые операции, тонкую налоговую логику и исключения под отдельных клиентов.
Заранее договоритесь о метриках, чтобы оценивать проект не по количеству экранов:
Хорошая тарифная сетка — это не «таблица с ценами», а набор чётких правил: за что именно вы берёте деньги, когда списываете, что происходит при смене плана и как система ведёт себя в спорных ситуациях. Чем раньше вы это формализуете, тем меньше ручной работы будет у поддержки и бухгалтерии.
Обычно подписочные продукты укладываются в несколько моделей — их можно комбинировать:
Базовые решения, которые влияют на биллинг:
Заранее заложите поддержку разных вариантов:
Определите поведение для:
Даже не фиксируя публичную политику заранее, полезно описать статусы, которые система должна уметь хранить: «запрошен», «на рассмотрении», «одобрен», «отклонён», «в обработке», «завершён», «ошибка».
Отдельно продумайте типы: полный/частичный возврат, отмена подписки с сохранением доступа до конца периода, возврат при двойном списании.
Биллинг для пользователя — это несколько повторяющихся «петель», которые должны работать предсказуемо: от первой оплаты до смены тарифа и восстановления после неуспешного списания. Чем проще сценарии, тем меньше обращений в поддержку и тем выше удержание.
Начинайте с понятной связки: регистрация, затем выбор плана на странице /pricing, дальше — оплата и подтверждение статуса. После успешного платежа пользователь должен сразу увидеть, что именно активировалось: текущий тариф, дата следующего списания, сумма, способ оплаты и кнопка «Управлять подпиской».
В минимальном наборе интерфейсов обычно достаточно:
/pricing — сравнение тарифов, условия пробного периода (если есть), частота списаний, что включено/не включено./account/billing — текущий план, смена/отмена, дата продления, история статуса (например, «активна», «ожидает оплаты»)./invoices — список счетов/инвойсов, скачивание PDF/чека (если применимо), статусы «оплачен/не оплачен/возврат»./payment-methods — привязанные способы оплаты, смена карты, установка «по умолчанию».Когда списание не прошло, интерфейс должен отвечать на два вопроса: «почему?» и «что делать дальше?». Не ограничивайтесь «Платёж отклонён». Покажите понятную причину (недостаточно средств, истёк срок карты, банк отклонил) и действие: «Обновить карту», «Повторить попытку», «Связаться с банком».
В /account/billing важно отображать дедлайн, до которого доступ сохранится (грейс‑период), и что будет после.
Дайте пользователю возможность самостоятельно:
/payment-methods;Минимальный набор уведомлений по email и/или внутри приложения:
/invoices);Главное правило: уведомления и экраны должны согласованно отражать один и тот же статус подписки — без сюрпризов и «пропавших» платежей.
Хорошая архитектура биллинга — это не «красота схемы», а предсказуемость денег: чтобы списания не дублировались, статусы не путались, а поддержка могла быстро разобраться, что произошло.
На старте чаще всего выигрывает монолит или модульный монолит: один деплой, проще отлаживать цепочки «пользователь → оплата → доступ». При этом биллинг лучше выделить хотя бы логически (папка/пакет/модуль), чтобы позже не переписывать половину приложения.
Микросервисы оправданы, когда:
Если сомневаетесь — начинайте с модульного монолита и заранее продумайте границы.
Типовой набор выглядит так: веб‑клиент (страницы тарифов, оплата, управление подпиской), API, биллинг‑модуль (правила начислений, статусы подписок), очередь задач и воркеры (повторные попытки, генерация инвойсов, отправка писем).
Критично, чтобы «долгие» процессы (ожидание провайдера, ретраи, сверка) выполнялись асинхронно: интерфейс не должен зависать, а повторный запуск задачи не должен ломать данные.
Если ваша цель — быстро собрать MVP подписок и проверить тарифы на реальных пользователях, полезно иметь среду, где продукт, админка и биллинг‑контуры можно поднять без долгой сборки инфраструктуры.
TakProsto.AI — это vibe‑coding платформа, где веб‑приложение (обычно на React), бэкенд (Go + PostgreSQL) и базовые экраны вроде /pricing, /account/billing, /invoices можно спроектировать и собрать через чат, а затем экспортировать исходники, развернуть и хостить с поддержкой снапшотов и отката. Для биллинга особенно удобны planning mode (чтобы заранее зафиксировать правила статусов/прорейтинга) и быстрые итерации интерфейсов для самообслуживания.
Отдельный плюс для российского рынка: платформа работает на серверах в России, использует локализованные и open‑source LLM‑модели и не отправляет данные в другие страны.
Биллинг удобно строить вокруг журнала событий: попытка списания, успешный платёж, возврат, смена тарифа, пауза, отмена. Плюс — аудит действий операторов/админки (кто и почему изменил статус или выдал доступ). Это помогает разбирать спорные случаи и снижает ручной хаос.
Любые операции оплаты и начислений должны быть идемпотентными: повторный запрос (из‑за таймаута, вебхука, ретрая) не создаёт второй платёж/инвойс. Практика: идемпотентные ключи, уникальные ограничения в БД, «единственный источник правды» по статусам.
Подключайте внешние системы только когда понятна польза: CRM/поддержка для контекста клиента, аналитика для MRR/оттока, уведомления для коммуникаций.
Главное правило — интеграции не должны быть единственным местом, где хранится истина о подписке: источник — ваше приложение.
Правильная модель данных в подписках — это способ «прибить гвоздями» бизнес‑правила: что такое тариф, как считается период, почему клиенту выставлен именно этот счёт и что произошло, если платёж не прошёл. Чем раньше вы зафиксируете сущности и статусы, тем меньше будет спорных случаев в поддержке.
Обычно достаточно пяти таблиц/сущностей:
Важно разделять «счёт» и «платёж»: один invoice может иметь несколько payments (повторные попытки, частичная оплата, смена карты).
Для subscriptions удобно держать небольшой, но строгий набор: trial / active / past_due / canceled. Для invoices — draft / paid / void.
Старайтесь, чтобы переходы были проверяемыми: например, invoice не должен стать paid без подтверждённого платежа.
Если вы обновили стоимость или состав тарифа, нельзя «переписать прошлое». Добавьте версионность: например, в plans храните записи с полями version, effective_from, effective_to, а в subscriptions фиксируйте ссылку на конкретную версию плана.
Так вы сможете объяснить, почему счёт за прошлый месяц был на одну сумму, а новый — на другую.
Модель «subscription 1 → N invoices» обычно самая прозрачная. В subscription храните current_period_start и current_period_end, а в invoice — конкретный billing_period_start/end.
Это помогает и с прорейтингом, и с восстановлением событий при сбоях.
Не тащите в биллинг лишние персональные данные. Храните только то, что нужно для выставления счёта и возвратов (например, идентификатор клиента и данные для документов), а платежные реквизиты заменяйте токенами провайдера в payment_methods.
Чувствительные поля (ФИО, адрес) лучше держать отдельно и ограничивать доступ ролями — биллингу часто достаточно ссылок и агрегатов.
Платёжная интеграция — это не «подключить кнопку оплаты», а выстроить надёжный контур: провайдер → ваше приложение → подтверждения (webhooks) → финальный статус подписки. Чем раньше вы заложите правила обработки статусов и ошибок, тем меньше будет «зависших оплат» и ручных разборов.
Смотрите на практику, а не на маркетинг:
Типовой поток выглядит так:
В вашем приложении создаётся Customer/Client у провайдера (или вы привязываете существующего).
Пользователь вводит платёжные данные на стороне провайдера (виджет/redirect), а вы получаете токен платёжного метода, а не «сырые» реквизиты.
Этот токен сохраняется у вас как ссылка на метод оплаты и используется для рекуррентных списаний.
Так вы снижаете требования по хранению чувствительных данных и упрощаете соответствие стандартам безопасности.
Нельзя полагаться только на ответ API при создании платежа: финальная правда приходит webhook’ами. Минимальный набор:
Логируйте: ID события, тип, время, подпись, payload, ваш внутренний объект (invoice/payment), результат обработки.
Обязательно делайте идемпотентность: одно и то же событие может прийти повторно.
Заранее продумайте, как вы покажете пользователю шаг подтверждения:
/billing/payment-status);Заложите повторные попытки (retry) при временных сбоях, таймауты с повторным запросом статуса у провайдера и периодическую сверку (reconciliation) для платежей со статусом pending.
Если API говорит одно, а webhook — другое, приоритет обычно у webhook, но с обязательной проверкой подписи и источника.
Эта часть — «двигатель» подписки: как формируются счета, что происходит при смене тарифа и как система ведёт себя при неудачных списаниях. Важно заранее договориться о правилах, иначе поддержка утонет в ручных корректировках.
Обычно инвойс создаётся в начале биллингового периода (например, раз в месяц) и фиксирует сумму к оплате, валюту и состав позиций.
Решите, создаёте ли вы инвойс заранее (за X часов/дней до списания) или ровно в момент попытки платежа — это влияет на уведомления и отчётность.
Если поддерживаются разные валюты, храните их на уровне тарифа/подписки и запрещайте «тихую» смену валюты посреди периода.
Для округлений задайте единое правило: до копеек/центов, банковское округление или всегда в пользу клиента. Это критично для прорейтинга и частичных возвратов.
При апгрейде/даунгрейде есть несколько подходов:
Выбор влияет на ожидания пользователей и количество возвратов. Главное — одинаково применять правило во всех интерфейсах и письмах.
Задайте «окно попыток» (например, 7–14 дней): сколько раз и как часто вы повторяете списание. Полезно разделять статусы: past_due (есть долг), unpaid (окно попыток исчерпано), paused/suspended (доступ ограничен).
Также решите, когда отправлять напоминания и когда отключать функциональность, чтобы не создавать неожиданностей.
Возвраты лучше хранить как отдельные сущности, связанные с платежом и инвойсом: сумма, валюта, причина, комментарий, кто инициировал (пользователь/поддержка), дата.
Частичные возвраты требуют аккуратности: они должны уменьшать «оплачено» по инвойсу и попадать в отчёты, чтобы MRR и выручка не расходились.
Налоги и первичные документы в подписочной модели лучше спроектировать до первой транзакции. Иначе «костыли» появятся везде: в счетах, в админке поддержки и в выгрузках для бухгалтерии.
Даже если сейчас вы не плательщик НДС, заложите структуру данных так, чтобы режим можно было поменять без миграций «вручную». Обычно достаточно хранить:
Важно: фиксируйте налоговые параметры в момент выставления счёта/инвойса, а не пересчитывайте задним числом при смене настроек.
Разделите ответственность:
Так вы сможете повторно отдать клиенту документы из /billing даже при смене провайдера.
Для компаний добавьте отдельный профиль плательщика: название юрлица, ИНН/КПП (или локальные аналоги), юрадрес, e-mail для документов.
Валидации делайте мягкими: часть полей обязательна только для «юридического» типа клиента.
Заранее определите сроки хранения инвойсов, актов и событий (создание счёта, изменение ставки, возврат). Нужен журнал операций с неизменяемыми записями и привязкой к пользователю/роли.
И не забудьте про локализацию документов: язык, валюта, формат дат и правила округления должны «замораживаться» на момент выставления счёта, чтобы повторная выгрузка выглядела идентично.
Биллинг — это не только «снять деньги», но и зона повышенного риска: здесь сходятся персональные данные, платёжные статусы, скидки и права сотрудников. Ошибка в доступах или логах может стоить дороже любой фичи.
Если вы интегрируетесь с платёжным провайдером, храните у себя только токены (payment method token) и технические идентификаторы транзакций. Никаких PAN и CVV в вашей базе, логах, аналитике или письмах поддержки.
Практично: показывайте пользователю только маску карты (например, **** 4242) и срок действия, если провайдер возвращает их в безопасном виде.
Разделите доступы минимум на три роли: админ, финансы, поддержка. Поддержке обычно нужны просмотр подписки, история инвойсов и возможность запустить «повторить оплату», но не менять тариф, скидки или реквизиты.
Для критичных действий включайте дополнительные барьеры: подтверждение паролем, 2FA, обязательный комментарий «почему меняем».
Для внешних запросов используйте rate limiting и защиту от перебора. Вебхуки проверяйте по подписи провайдера, а также делайте идемпотентность: одинаковое событие не должно повторно менять статус подписки или создавать лишний инвойс.
Отдельно ведите учёт «повторов» (replay): сохраняйте идентификатор события и время обработки.
Добавьте простые сигналы: частые попытки оплаты, резкие смены тарифов, серия возвратов, массовое применение скидок. Такие случаи отправляйте в очередь на ручную проверку.
И, наконец, аудит: фиксируйте, кто и когда изменил тариф, скидку, статус подписки и настройки клиента. Это помогает разбирать инциденты и защищает команду поддержки от «невидимых» правок.
Хорошая админка для подписок — это не «панель для галочки», а способ снизить нагрузку на поддержку и убрать хаос в ручных правках. Чем быстрее оператор находит клиента, видит причину проблемы и может аккуратно исправить ситуацию, тем меньше потерь выручки и нервов.
Начните с простого сценария: оператор вводит email/ID/номер счёта и сразу получает карточку клиента.
Минимальный набор экранов:
Важно: все статусы и даты должны быть «человеческими», без внутренней терминологии.
Операционные действия стоит делать кнопками с понятными последствиями:
Добавьте «сухой прогон»: перед применением система показывает, как изменятся дата списания и сумма.
Ручные правки нужны (компенсация, частичный возврат, исправление суммы), но только с контролем:
Для бухгалтерии обычно достаточно CSV/интеграции с полями: ID клиента, ID подписки, номер инвойса, дата, сумма, налог/ставка, статус оплаты, валюта, способ оплаты.
Заранее подготовьте шаблоны писем: подтверждение оплаты, уведомление о просрочке, финальное предупреждение. В идеале — ссылки на /billing и /help, чтобы клиент мог сам обновить оплату без обращения в поддержку.
Биллинг ломается не «громко», а неприятно: часть платежей проходит, часть — нет, деньги списались, а доступ не выдан (или наоборот). Поэтому тестирование и запуск лучше строить как отдельный мини‑проект со своими чек‑листами и метриками.
Начните с изолированного окружения (staging) и песочницы платёжного провайдера. Важно уметь воспроизводить не только «успешный платёж», но и специальные события: отказ по карте, недостаток средств, 3‑D Secure, отмену/возврат, повторные попытки, частичный платёж.
Если провайдер позволяет отправлять тестовые webhooks — заведите набор фиксированных «сценариев событий» и запускайте их как часть регресса. Это быстрее и надёжнее, чем вручную кликать в кабинете.
Проверьте:
Смоделируйте «день продлений», когда тысячи подписок пытаются списаться в один час. Измеряйте очередь webhook, время обработки, блокировки в базе и скорость расчёта инвойсов. Хороший ориентир — удерживать обработку событий в стабильном темпе и иметь понятную деградацию.
Запускайте через фича‑флаги: сначала включите новый биллинг только для сотрудников и небольшой доли пользователей. Миграции делайте обратимыми, а сценарий отката — заранее прописанным (что будет с доступом и статусами).
Здесь же полезно заранее продумать операционную дисциплину: снапшоты, rollback и контроль версий схемы. Например, в TakProsto.AI можно держать стабильные снапшоты окружений и откатываться при проблемах релиза без «ручного спасения» продакшена — это особенно важно для подписок, где цена ошибки высока.
Минимум: алерты на падение приёма webhook, рост ошибок провайдера, аномалии конверсии оплаты, резкий скачок просроченных инвойсов.
Полезно завести дашборд «здоровья биллинга» и ссылку на него в runbook (/docs/billing-runbook).
Биллинг — это не только «чтобы списывалось», но и источник точных данных о росте. Если заранее договориться, какие метрики и события считаем, проще принимать решения о цене, trial и годовых планах — без гаданий.
Начните с набора, который понятен бизнесу и хорошо объясняет динамику:
Чтобы метрики были объяснимыми, фиксируйте ключевые события и их контекст:
Стройте когорты по дате первой оплаты или старта trial и сравнивайте удержание по тарифам и каналам. Часто видно, что «дешёвый» тариф даёт худшее удержание, а канал с низким CAC приносит более капризных клиентов.
Проверяйте гипотезы аккуратно: меняйте цены, длину trial, офферы годовых планов (например, «2 месяца в подарок») и заранее определяйте KPI (конверсия, churn, expansion MRR).
Важно фиксировать версию предложения в данных, чтобы потом честно сравнить группы.
Сделайте понятную страницу справки со счетами и подпиской: /help/billing. Хорошая FAQ (как скачать счёт, почему не прошла оплата, как сменить план, как отменить) уменьшает нагрузку на поддержку и снижает «раздражающий churn» из‑за недопонимания.
Если вы делаете контент и делитесь практикой внедрения подписок, обратите внимание, что у TakProsto.AI есть программа начисления кредитов за публикации и реферальные приглашения — это может помочь частично покрыть затраты на прототипирование и итерации, пока вы доводите биллинг‑контур до стабильного состояния.
Начните с фиксации границ: что именно продаёте (доступ, места, потребление), какие статусы и действия нужны пользователю и поддержке. Для MVP обычно достаточно:
Всё «сложное» (комбинированные планы, детальная налоговая логика, массовые операции) лучше отложить до появления реальных кейсов.
Минимальный «скелет» — 5 сущностей:
Важно разделять инвойс и платеж: один инвойс может иметь несколько попыток оплаты (смена карты, повторные списания, частичная оплата).
Выбирайте модель, которая совпадает с тем, как клиент воспринимает ценность:
Для начала зафиксируйте правила на 1–2 тарифах, а не пытайтесь покрыть все комбинации сразу.
Определите ответы на три вопроса:
Технически важно хранить current_period_start/end в подписке и «замораживать» условия (цена, валюта, налоговые параметры) в инвойсе на момент выставления.
Сделайте скидки отдельным объектом с явными ограничениями:
В биллинге лучше фиксировать эффект скидки в инвойсе (сумма/позиции), чтобы потом не пересчитывать историю задним числом.
Определите единые правила и показывайте их в интерфейсе до подтверждения:
Практика: перед применением показывайте «сухой прогон» — как изменятся сумма, дата продления и статус.
Обычно цепочка такая:
Нельзя полагаться только на ответ API при создании платежа: вебхук — источник финальной истины (с проверкой подписи и идемпотентной обработкой).
В биллинге идемпотентность нужна в двух местах:
Используйте:
Цель простая: повторная обработка не должна менять деньги второй раз.
Сведите статусы к «скучному» и проверяемому набору и явно задайте переходы.
Пример:
subscriptions: ;Минимальный набор, который реально снижает нагрузку на поддержку:
При ошибке оплаты показывайте причину и следующий шаг (обновить метод, повторить попытку) и дедлайн грейс‑периода.
trial → active → past_due → canceledinvoices: draft → paid или draft → void;payments: pending → succeeded/failed.Правило контроля: инвойс не может стать paid без подтверждённого успешного платежа; подписка не должна «прыгать» туда‑сюда при задержке вебхуков.