Система подписок в SaaS: 6 мест, где чаще всего ломается биллинг

Система подписок в SaaS: 6 мест, где чаще всего ломается биллинг

Подписка — не просто кнопка «оплатить». Это состояние аккаунта, права доступа, лимиты, счета, отмены и возвраты. Ошибка в одном месте быстро превращается в ручную поддержку и недоверие к продукту.

Что проверить в архитектуре:
— отдельная сущность Subscription, а не поле is_paid в User;
— статусы: trial, active, past_due, canceled, paused;
— история изменений тарифа и периода;
— идемпотентная обработка вебхуков;
— единый источник прав: не фронт, не кэш, а серверная проверка.

Типовые edge cases:
— пользователь оплатил, но вебхук пришёл позже;
— карта не списалась, но доступ нельзя рубить мгновенно;
— апгрейд тарифа в середине периода;
— отмена подписки с доступом до конца оплаченного срока;
— повторная отправка одного события от платёжки.

Главное правило: биллинг должен быть конечным автоматом. Любое событие переводит подписку из одного понятного состояния в другое, а не «чуть-чуть меняет несколько полей».

Сначала нарисуйте состояния и переходы, потом пишите код. Это дешевле, чем чинить деньги через админку.