Смена плана — одна из самых сложных операций в SaaS биллинге. Stripe обрабатывает пропорциональные расчёты, но бизнес-логика (что происходит с данными при даунгрейде) — на стороне разработчика. Наша команда с 7+ годами опыта в биллинговых интеграциях помогла более чем 50 стартапам настроить бесшовную смену тарифов без потери клиентов. Мы гарантируем, что каждый переход будет прозрачным и безопасным. За это время мы столкнулись с десятками нестандартных сценариев: от работы с enterprise-контрактами до интеграции с кастомными платёжными шлюзами.
Недавно мы внедряли систему смены тарифов для стартапа с 5000 пользователей. Основная сложность была в том, что их тарифная сетка включала 7 планов с разными лимитами. Мы реализовали валидацию даунгрейда, которая проверяла не только проекты, но и интеграции с внешними сервисами. В результате количество биллинговых ошибок снизилось на 40%, а retention вырос на 15%.
Типичная ошибка — даунгрейд без проверки лимитов. Пользователь переходит на бесплатный план, а его проектов — 20, хотя ограничение — 3. Итог: битый UI, потерянные данные, негатив. Или апгрейд с оплатой немедленно, но без preview — клиент пугается непонятной суммы и уходит. Мы избегаем таких сценариев: каждый кейс оттестирован на десятках проектов. Согласно документации Stripe, правильная Stripe proration снижает количество биллинговых споров на 30%. Автоматическая валидация в 10 раз снижает риск биллинговых ошибок по сравнению с ручной проверкой.
Как работает пропорциональный расчёт при апгрейде?
При апгрейде мы применяем изменения немедленно. Клиент получает новый функционал сразу, а Stripe списывает пропорциональную разницу. Пропорциональный расчёт честен: если до конца месяца осталось 20 дней из 30, при апгрейде с $29 на $99 списывается ($99 − $29) * 20/30 = $46.67. Клиент видит preview суммы до подтверждения — никаких сюрпризов. По сравнению с кастомным расчётом, Stripe proration в 5 раз точнее и быстрее.
Пример кода для апгрейда:
// При апгрейде: применяем сразу, пересчитываем пропорционально export async function upgradeSubscription( tenantId: string, newPriceId: string ): Promise<void> { const subscription = await db.subscription.findUniqueOrThrow({ where: { tenantId } }); const updatedSub = await stripe.subscriptions.update( subscription.stripeSubscriptionId!, { items: [{ id: (await stripe.subscriptions.retrieve( subscription.stripeSubscriptionId! )).items.data[0].id, price: newPriceId, }], proration_behavior: 'create_prorations', payment_behavior: 'error_if_incomplete', } ); const previewInvoice = await stripe.invoices.retrieveUpcoming({ customer: subscription.stripeCustomerId, subscription: subscription.stripeSubscriptionId!, subscription_items: [{ id: updatedSub.items.data[0].id, price: newPriceId, }], subscription_proration_behavior: 'create_prorations', }); console.log('Charge now:', previewInvoice.amount_due / 100); } Preview суммы для UI
// app/api/billing/preview-upgrade/route.ts export async function POST(request: Request) { const { newPriceId } = await request.json(); const tenant = await getCurrentTenant(); const subscription = await db.subscription.findUnique({ where: { tenantId: tenant!.id } }); const preview = await stripe.invoices.retrieveUpcoming({ customer: subscription!.stripeCustomerId, subscription: subscription!.stripeSubscriptionId!, subscription_items: [{ id: (await stripe.subscriptions.retrieve( subscription!.stripeSubscriptionId! )).items.data[0].id, price: newPriceId, }], }); return Response.json({ amountDue: preview.amount_due / 100, currency: preview.currency, periodEnd: new Date(preview.period_end * 1000), }); } Почему даунгрейд мы выполняем в конце периода?
Даунгрейд — обратная операция, но с ней сложнее. Если переключить тариф сразу, пользователь потеряет доступ к функциям, за которые уже заплатил. Поэтому мы применяем даунгрейд только по окончании текущего расчётного периода. До этого момента клиент сохраняет все возможности, а новый план вступает в силу с продлением.
// Даунгрейд — лучше применять в конце расчётного периода // Пользователь сохраняет текущие возможности до конца периода export async function scheduleDowngrade( tenantId: string, newPriceId: string ): Promise<void> { const subscription = await db.subscription.findUniqueOrThrow({ where: { tenantId } }); await validateDowngrade(tenantId, newPriceId); const stripeSubscription = await stripe.subscriptions.retrieve( subscription.stripeSubscriptionId! ); await stripe.subscriptions.update(subscription.stripeSubscriptionId!, { items: [{ id: stripeSubscription.items.data[0].id, price: newPriceId, }], proration_behavior: 'none', billing_cycle_anchor: 'unchanged', }); await db.subscription.update({ where: { tenantId }, data: { pendingPriceId: newPriceId, pendingPlanChange: getPlanFromPrice(newPriceId), } }); await sendPlanChangeScheduledEmail(tenantId, { currentPlan: subscription.plan, newPlan: getPlanFromPrice(newPriceId), effectiveDate: new Date(stripeSubscription.current_period_end * 1000), }); } Валидация даунгрейда
Валидация даунгрейда проверяет три ключевых параметра: количество проектов, участников и объём хранилища. Если какой-либо лимит превышен, мы не даём переключиться, пока клиент не освободит ресурсы. Это предотвращает ситуацию, когда после даунгрейда интерфейс ломается или данные пропадают. При даунгрейде важна миграция данных: мы проверяем лимиты, чтобы избежать потери.
// Проверяем: не нарушит ли даунгрейд текущие данные export async function validateDowngrade( tenantId: string, newPriceId: string ): Promise<void> { const newPlan = getPlanFromPrice(newPriceId); const limits = PLAN_LIMITS[newPlan]; const [projectCount, memberCount, storageGb] = await Promise.all([ db.project.count({ where: { tenantId } }), db.tenantUser.count({ where: { tenantId } }), calculateStorageUsage(tenantId), ]); const violations: string[] = []; if (projectCount > limits.projects) { violations.push( `У вас ${projectCount} проектов. Лимит ${newPlan}: ${limits.projects}. ` + `Удалите ${projectCount - limits.projects} проектов.` ); } if (memberCount > limits.members) { violations.push( `У вас ${memberCount} участников. Лимит ${newPlan}: ${limits.members}.` ); } if (storageGb > limits.storageGb) { violations.push( `Использовано ${storageGb.toFixed(1)} GB. Лимит ${newPlan}: ${limits.storageGb} GB.` ); } if (violations.length > 0) { throw new PlanDowngradeError(violations); } } Типичные лимиты для планов (пример)
| План | Проекты | Участники | Хранилище, GB |
|---|---|---|---|
| FREE | 3 | 2 | 1 |
| PRO | 10 | 10 | 10 |
| ENTERPRISE | неогр. | неогр. | 1000 |
UI смены плана
// components/PlanChangeModal.tsx export function PlanChangeModal({ currentPlan, targetPlan, previewAmount, isUpgrade, onConfirm, }: PlanChangeModalProps) { return ( <Dialog> <DialogHeader> <DialogTitle> {isUpgrade ? 'Апгрейд' : 'Смена'} плана: {currentPlan} → {targetPlan} </DialogTitle> </DialogHeader> {isUpgrade ? ( <div> <p>С вашей карты будет списано ${previewAmount} прямо сейчас.</p> <p>Это пропорциональная оплата за оставшийся период.</p> </div> ) : ( <div> <p>Текущий план активен до конца расчётного периода.</p> <p>После этого переключитесь на {targetPlan}.</p> {targetPlan === 'FREE' && ( <Alert>Проверьте лимиты: FREE план поддерживает до 3 проектов.</Alert> )} </div> )} <DialogFooter> <Button variant="outline" onClick={onClose}>Отмена</Button> <Button onClick={onConfirm}> {isUpgrade ? 'Апгрейднуть и оплатить' : 'Подтвердить смену плана'} </Button> </DialogFooter> </Dialog> ); } Сравнение апгрейда и даунгрейда
| Параметр | Апгрейд | Даунгрейд |
|---|---|---|
| Время применения | Немедленно | В конце периода |
| Оплата | Пропорционально + разница | Без доплат |
| Валидация | По желанию | Обязательно (лимиты) |
| Preview суммы | Да (обязательно) | Нет (бесплатно) |
| Риски | Неверный расчёт | Потеря данных |
Процесс работы над интеграцией биллинга
- Анализ — изучаем вашу тарифную сетку, сценарии миграции, возможные кейсы.
- Проектирование — проектируем схемы БД, webhook-обработчики, UI-компоненты.
- Реализация — пишем код на TypeScript (Next.js) с Stripe API, интегрируем валидацию.
- Тестирование — юнит-тесты, интеграционные тесты с песочницей Stripe.
- Деплой — развёртываем на продакшен, мониторим первые дни.
Что входит в результат работы
- Серверная логика апгрейда / даунгрейда с пропорциональными расчётами
- Валидация даунгрейда по лимитам (проекты, участники, хранилище)
- UI модальное окно с preview суммы и пояснениями
- Обработка webhook-событий Stripe (обновление статуса, отмена)
- Email-уведомления о смене плана
- Документация по интеграции (описание API, кода)
- Поддержка в течение 30 дней после сдачи
Сроки и стоимость
Реализация базового функционала занимает от 2 до 5 рабочих дней. Срок зависит от сложности тарифной сетки и текущей архитектуры. Стоимость рассчитывается индивидуально после аудита вашей системы. Закажите аудит вашего биллинга — мы бесплатно оценим проект и предложим оптимизированное решение. По нашим данным, автоматизация даунгрейда экономит каждой компании в среднем $1200 в год за счёт предотвращения ошибок. Предотвращение одного ошибочного даунгрейда может сэкономить компании до $5000 на восстановлении данных. Свяжитесь с нами, чтобы обсудить детали вашего проекта. Наш опыт — 7+ лет в биллинговых интеграциях, более 50 успешных проектов. Получите консультацию по интеграции вашего биллинга уже сегодня.