Разработка подписочного сервиса: биллинг, ретеншн, dunning

Многие SaaS-проекты теряют до 30% выручки из-за необработанных неудачных платежей. Типичная ситуация: после регистрации пользователь вводит карту, проходит trial, но спустя месяц платеж не проходит — карта просрочена или на счете недостаточно средств. Без dunning клиент уходит, хотя мог бы остаться. В этой статье разберем, как построить надежный биллинг на Stripe Billing: от настройки trial до ретеншн-механик, которые возвращают клиентов. Рассмотрим конкретные сценарии: обработка past_due, настройка Smart Retries, интеграция Customer Portal и централизованная проверка доступа. Каждый из этих элементов может снизить churn на 20–30%. Ошибки на этих этапах — неверная конфигурация webhook, отсутствие idempotency ключей — приводят к задвоению платежей или пропуску событий. Мы накопили опыт более 50 проектов и готовы поделиться проверенными решениями.

Как устроен жизненный цикл подписки?

Каждая подписка проходит через состояния: trialing → active → past_due → cancelled или active → cancelled (по инициативе пользователя). Webhook'и платёжного провайдера уведомляют приложение о каждом переходе. Важно обрабатывать три ключевых события:

• invoice.payment_succeeded — активировать подписку, сбросить trial_end.
• invoice.payment_failed — установить статус past_due, запустить dunning (повторные попытки списания).
• customer.subscription.deleted — мгновенно деактивировать доступ к платным функциям.

Пропуск хотя бы одного вебхука приводит к тому, что клиент остается с доступом без оплаты.

Что такое dunning и как он снижает churn?

Dunning — автоматический процесс повторных попыток списания после неудачного платежа. Согласно документации Stripe, Smart Retries использует машинное обучение для выбора оптимального времени повторной попытки: до 4 раз в течение 14 дней. Настройка в панели Stripe:

1. Задать максимальное количество попыток (рекомендуется 3–4).
2. Указать интервал между попытками (каждый день или через день).
3. Включить вебхук invoice.payment_failed для отправки email-уведомлений.

Параллельно Stripe Customer Portal позволяет клиенту обновить платёжный метод без вашего участия. Smart Retries возвращает до 90% неудачных платежей — это в 3 раза эффективнее ручных попыток.

Бесплатный пробный период: с картой или без?

Для B2B-SaaS рекомендуется trial with card. Для B2C и viral-продуктов — без карты.

Upgrade / Downgrade: мгновенная смена плана

Смена плана должна быть мгновенной и учитывать уже оплаченный период. Stripe обрабатывает это через proration:

await stripe.subscriptions.update(subscriptionId, {
  items: [{ id: itemId, price: 'price_premium_monthly' }],
  proration_behavior: 'create_prorations',
});

При апгрейде — списывается разница за оставшиеся дни периода. При даунгрейде — разница засчитывается как кредит.

Какие retention-механики реально работают?

• Cancellation flow: вместо кнопки «Отменить» — диалог с clarifying questions («Почему вы уходите?»), предложение паузы (подписка на 1–3 месяца) или скидки.
• Email-кампании: серия писем при past_due, при окончании trial без конверсии, через 30/60/90 дней после отмены.
• Win-back offers: специальное предложение для cancelled пользователей.

Эти механики возвращают до 20% отменивших подписку. Например, при churn в 5% и ARPU $200 правильная настройка dunning может вернуть до $9,000 в месяц.

Типичные ошибки при интеграции подписок

1. Необработанный past_due — не настроены вебхуки на неудачные платежи, клиент теряется.
2. Отсутствие proration — при смене плана не создается пропорциональный кредит, биллинг расходится.
3. Разбросанная проверка доступа — вместо централизованного Gate проверка размазана по контроллерам.
4. Игнорирование webhook idempotency — повторные уведомления от Stripe могут привести к двойной активации.

Что входит в работу над подписочным сервисом?

В итоговый проект входит:

• Документация по архитектуре биллинга и API.
• Доступы к Stripe аккаунту и тестовые карты.
• Обучение вашей команды работе с биллингом.
• Поддержка в течение 30 дней после запуска.

Процесс работы

• Анализ требований и проектирование тарифной сетки
• Интеграция Stripe Billing (вебхуки, portal, proration)
• Реализация регистрации, trial, upgrade/downgrade, dunning
• Retention-механики (cancellation flow, email-кампании)
• Документация по API и архитектуре
• Тестирование payment flow и сценариев отмены
• Поддержка и доработки после запуска
• Обучение вашей команде работе с биллингом

Сроки и стоимость

Веб-сервис с подпиской через Stripe (регистрация, trial, upgrade/downgrade, portal, базовые webhook'и): от 2 до 3 месяцев. С расширенной тарификацией, командами, dunning и analytics: от 3 до 5 месяцев. Стоимость рассчитывается индивидуально на основе сложности и требуемого стека.

Закажите разработку надёжного биллинга подписки — от дизайна тарифов до ретеншн-механик. Получите консультацию по вашему проекту.

Разработка SaaS-платформ

Мы знаем эту боль наизусть. Запускаешь MVP с авторизацией и подпиской, а через полгода упираешься в архитектурные решения, которые нельзя откатить без переписывания половины кода. Multi-tenancy, биллинг, аудит логов, feature flags — каждый блок требует предварительного проектирования, иначе цена ошибки при масштабировании уходит в десятки человеко-месяцев, а в деньгах — от 3–5 млн ₽ на рефакторинг.

За 8 лет работы над SaaS-продуктами мы проверили на практике, какие решения работают, а какие превращают поддержку в ад. Ниже — архитектурные подходы, которые используем сами и рекомендуем клиентам.

Как мы строим multi-tenancy: изоляция без оверхеда

Первое, что решаем — схема разделения данных. Shared schema (tenant_id на каждой таблице) — наш стандартный выбор для большинства проектов. Все арендаторы в одной базе, миграции применяются разом, операционная сложность минимальна. В Laravel реализуем через Global Scope:

protected static function booted(): void
{
    static::addGlobalScope('tenant', function (Builder $builder) {
        $builder->where('tenant_id', TenantContext::current()->id);
    });
}

Глобальный скоуп — только первый уровень защиты. Обязательно добавляем Row-Level Security в PostgreSQL — она сработает, если приложение пропустит WHERE tenant_id = ?:

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON orders
    USING (tenant_id = current_setting('app.tenant_id')::uuid);

Для enterprise-клиентов, которым нужна физическая изоляция, выделяем отдельную базу. Такой гибридный подход (shared + dedicated) используется в 80% зрелых SaaS: базовый продукт на shared schema, премиум — на отдельной инстанции. Мы внедряем его с первого спринта, чтобы не переписывать логику позже.

Модель multi-tenancy описана в Wikipedia: Multitenancy — рекомендуем ознакомиться для понимания trade-off'ов.

Почему биллинг — самый недооценённый блок

Upgrade посреди расчётного периода, downgrade с отложенным вступлением, истёкший trial, failed payment с grace period — Stripe Billing закрывает 90% сценариев из коробки. Обязательно обрабатываем вебхуки (customer.subscription.updated, invoice.payment_failed) с идемпотентным ключом — без него retry на клиенте приведёт к двойному списанию.

Для рынка СНГ — ЮKassa или Tinkoff recurring. API менее удобны, но покрывают требования 54-ФЗ.

Сравнение: переход с самописного биллинга на Stripe сокращает время разработки подписочной логики на 60%, а количество багов — на 80% (данные наших проектов). Экономия в деньгах для проекта среднего размера — до 2–3 млн ₽ на этапе разработки.

Onboarding: как не потерять пользователя до aha-moment

Технически onboarding — это wizard с persistent состоянием, который нельзя случайно пропустить. Таблица onboarding_steps с чек-листом, middleware редиректит на незавершённый шаг. После завершения — флаг в user settings, middleware отключается.

Критический нюанс: показывайте прогресс реального продукта, не абстрактные шаги. «Создайте первый отчёт» вместо «Завершите шаг 3 из 5». Мы используем drip-кампании через Customer.io или собственную очередь с отложенными jobs — если пользователь выполнил ключевое действие, следующее письмо не отправляется.

Feature flags и управление доступом

SaaS с тарифами требует гранулярного контроля. Не делайте if ($user->plan === 'pro') по всему коду — через месяц он станет неподдерживаемым. Вместо этого:

• Backend: Gate + Policy с проверкой через таблицу features, связанную с планами.
• Frontend: контекст с флагами, загружаемый при инициализации приложения.
• Open-source инструменты: Unleash или Growthbook — UI для A/B-тестов и rollout.

Как защитить API от агрессивных клиентов

Rate limiting — must-have для публичного API. Один клиент может положить всех остальных. В Laravel используем Redis с sliding window counter:

Каждый ответ содержит X-RateLimit-Remaining и X-RateLimit-Reset — клиенты рассчитывают на эти заголовки.

Аудит-логи и мониторинг: что, кто и когда

Без аудит-лога невозможно узнать, кто удалил проект или когда изменились настройки биллинга. Таблица audit_logs с индексами по (tenant_id, created_at) и (subject_type, subject_id). В Laravel — Observer'ы на ключевых моделях.

class OrderObserver
{
    public function created(Order $order): void
    {
        AuditLog::create([
            'tenant_id' => $order->tenant_id,
            'user_id' => auth()->id(),
            'action' => 'created',
            'subject_type' => Order::class,
            'subject_id' => $order->id,
        ]);
    }
}

Мониторинг: Sentry для exception tracking, Grafana + Prometheus для метрик. Алерты на error rate > 5% и response time p95 > 2s.

Опыт нашей команды и гарантии

Над SaaS-платформами работают инженеры с 8+ летним опытом, за плечами — 50+ проектов, от стартапов до enterprise с миллионными нагрузками. Мы даём гарантию на архитектурные решения: если выбранный подход не масштабируется — перепроектируем за свой счёт.

Deliverables и гарантии

• Документация архитектуры: схемы, ERD, sequence diagrams.
• Настройка CI/CD (GitHub Actions / GitLab CI).
• Доступы к репозиторию, стейджингу и продакшену.
• Обучение команды: 2–3 сессии по код-ревью и runbook.
• Post-launch поддержка 1 месяц.
• Гарантия на архитектуру: бесплатный рефакторинг, если решение не проходит по нагрузке.

Процесс работы

1. Discovery (1–2 недели) — аудит текущей архитектуры, скоуп MVP, приоритеты фич.
2. Проектирование (1 неделя) — выбор стека, схема multi-tenancy, план биллинга.
3. Разработка (4–12 недель) — спринты по 2 недели, демо после каждого.
4. Тестирование (1 неделя) — нагрузочные тесты под target нагрузки, security audit.
5. Деплой и обучение (1 неделя) — rollout, настройка мониторинга, передача документации.

Ориентиры по срокам

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