Разработка SaaS в России: мультиарендность и биллинг без Stripe
Большинство гайдов по разработке SaaS написаны с расчётом на Stripe или Paddle — сервисы, которые фактически недоступны российскому бизнесу. Это не деталь, а причина, по которой чужую архитектуру биллинга нельзя скопировать один в один: нужен российский платёжный провайдер с самого начала. Разбираем архитектуру мультиарендности и биллинга под реальные условия.
Разработать SaaS под ключ в российских реалиях значит с самого начала закладывать не Stripe, а локального платёжного провайдера.
Три модели мультиарендности
Мультиарендность (multi-tenancy) — это то, как SaaS-продукт хранит данные разных клиентов в одной системе, не давая им видеть данные друг друга. Есть три основных подхода:
| Модель | Изоляция данных | Стоимость инфраструктуры | Когда подходит |
|---|---|---|---|
| Общая база, разделение по ID клиента | Минимальная — на уровне логики приложения | Самая низкая | Много небольших клиентов, невысокие требования к изоляции |
| Своя схема в общей базе на клиента | Средняя — разделение на уровне БД | Средняя | Компромисс между стоимостью и требованиями безопасности |
| Отдельная база данных на клиента | Максимальная — физическая изоляция | Самая высокая | Корпоративные клиенты с жёсткими требованиями к данным |
Смена модели после того, как в системе уже работают клиенты — это отдельный проект миграции данных, а не быстрая правка конфигурации. Разумнее заложить архитектуру с запасом под ожидаемый рост клиентской базы сразу, чем экономить на старте и переделывать всё через год.
Биллинг и подписки без Stripe
Российские платёжные системы — ЮKassa, CloudPayments, Robokassa и подобные — закрывают ту же задачу, что Stripe за рубежом: приём разовых платежей и привязку карты клиента для последующих автоматических списаний по подписке. Разница не в принципе, а в конкретном API и деталях интеграции, которые нужно закладывать в архитектуру с первого дня, а не пытаться подключить как позднюю замену.
Что закладывать в архитектуру с первого дня
- Обработку неуспешных платежей. Часть списаний не проходит с первого раза — карта истекла, недостаточно средств. Нужна логика повторных попыток и понятное уведомление клиента, а не молчаливая блокировка доступа.
- Разделение прав внутри тарифа. Если у клиента несколько сотрудников с разными ролями внутри одной подписки — это отдельный слой прав доступа поверх мультиарендности, который проще спроектировать сразу, чем добавлять постфактум.
- Метрики использования по каждому клиенту, если тариф зависит от объёма использования (число пользователей, объём данных, число запросов) — считать это нужно точно и в реальном времени, а не оценочно.
- План на рост нагрузки. Архитектура, которая работает для десяти клиентов, не обязательно выдержит тысячу без изменений — стоит закладывать это в план развития заранее, а не как экстренную переделку при внезапном росте.
Как выбрать подрядчика
Разработчика для такой задачи стоит выбирать по конкретным признакам, а не по общему впечатлению от презентации:
- Сразу обсуждает архитектуру мультиарендности, а не откладывает этот вопрос до момента, когда придут первые клиенты.
- Проектирует биллинг под российского платёжного провайдера с самого начала, а не копирует чужую Stripe-архитектуру с расчётом заменить провайдера позже.
- Продумывает сценарии неуспешных платежей и повторных попыток — это не мелкая деталь, а то, что напрямую влияет на удержание клиентов.
- Предлагает архитектуру с запасом на рост, а не минимально достаточную для текущего числа клиентов.
Частые вопросы
Почему нельзя просто использовать Stripe для биллинга SaaS в России?
Stripe и Paddle фактически недоступны для регистрации и приёма платежей российским юрлицам — большинство SaaS-гайдов по биллингу написаны с расчётом именно на них, что делает такие материалы бесполезными для разработки в РФ. Нужно закладывать в архитектуру российского платёжного провайдера с самого начала, а не пытаться подключить его как замену готовой Stripe-интеграции постфактум.
Какая модель мультиарендности самая дешёвая?
Общая база данных с разделением по идентификатору клиента (shared schema) — самая дешёвая в эксплуатации и самая быстрая для запуска, но даёт наименьшую изоляцию между клиентами. Отдельная база данных на каждого клиента — самая дорогая в инфраструктуре, но и самая безопасная с точки зрения изоляции данных. Выбор зависит от требований клиентов к безопасности и от бюджета на инфраструктуру.
Можно ли поменять модель мультиарендности после запуска?
Технически можно, но это отдельный проект миграции данных, а не быстрая правка — чем больше клиентов уже работает в системе, тем дороже и рискованнее такой переход. Разумнее заранее спроектировать архитектуру так, чтобы она выдержала ожидаемый рост, а не откладывать этот вопрос до момента, когда менять уже дорого.
Как устроены рекуррентные (повторяющиеся) платежи по подписке в России?
Российские платёжные системы поддерживают привязку карты клиента с его согласия и последующее автоматическое списание по расписанию — аналог того, что делает Stripe за рубежом, но через локального провайдера. Важно заранее продумать сценарии неуспешных списаний (карта истекла, недостаточно средств) и логику повторных попыток, а не полагаться на то, что каждое списание пройдёт с первого раза.
Нужна ли изоляция данных между клиентами, если продукт для небольшого сегмента бизнеса?
Требования к изоляции определяются не размером клиента, а чувствительностью данных, с которыми работает продукт, и требованиями самих клиентов — часть корпоративных заказчиков в принципе не подпишет договор с SaaS-провайдером без гарантий физической изоляции данных, независимо от размера продукта.
Расскажите про продукт и ожидаемое число клиентов — на созвоне за 40 минут поймём, какая модель мультиарендности и биллинга подойдёт именно вам.
Обсудить проект