Архитектура subscription-commerce: как строить под регулярную выручку

Мы строили достаточно подписочных систем, чтобы сказать: разрыв между тем, как подписки выглядят на встрече по продукту — клиент платит раз в месяц, получает товар, отменяет когда захочет — и тем, что нужно реально реализовать, огромен. Dunning-логика, пропорциональные расчёты при смене тарифа в середине цикла, расписания повторных попыток при неудачных платежах, налоговые правила по юрисдикциям, флоу паузы — ни одна из этих вещей не сложна сама по себе, но все они должны работать вместе надёжно, каждый биллинговый цикл, бесконечно.

Почему существующие commerce-платформы не справляются

Magento, Shopify и WooCommerce построены вокруг единичных транзакций. Подписки вводят состояние, привязанное ко времени: подписка активна, просрочена, приостановлена или отменена, и это состояние должно быть согласованным в вашем магазине, провайдере биллинга, ERP и системе выполнения заказов. Когда любая из них выходит из синхронизации, вы либо списываете деньги с того, кто отменил, либо не списываете с того, кто должен платить.

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

Выбор биллингового движка

Ключевое решение: строить самостоятельно или использовать специализированный биллинговый сервис. Stripe Billing, Chargebee и Recurly берут на себя сложные части — пропорциональный расчёт, dunning, расчёт налогов, генерацию счетов — и интегрируются с большинством платёжных провайдеров. Они недёшевы в масштабе (1–0,5% от регулярной выручки), но построить аналогичную функциональность корректно занимает больше инженерного времени, чем большинство команд оценивает.

Когда строить своё: у вас биллинговая логика, которую действительно нельзя смоделировать в готовых инструментах, compliance-требования, исключающие сторонних обработчиков данных, или объём, при котором процентная комиссия реально влияет на unit-экономику. По нашему опыту, таких ситуаций — единицы. Большинство команд должны использовать Chargebee или Stripe Billing и потратить сэкономленное инженерное время на то, что отличает их продукт.

Dunning: проблема, которая накапливается

Dunning — это процесс восстановления неудавшихся платежей по подпискам через повторные попытки, уведомления и эскалирующее вмешательство. Наивная реализация — одна повторная попытка, отмена при неудаче — теряет восстанавливаемую выручку. Карты отклоняются по десяткам причин: временные отклонения, недостаточные средства, истёкшие карты, блокировки мошенничества. Большинство из них поддаются повторной попытке.

Рабочий паттерн: повторные попытки по расписанию — примерно день 1, день 3, день 7, день 14 — email при каждом сбое и прямая ссылка для обновления платёжных данных. По нашим наблюдениям, процент восстановления сильно варьируется в зависимости от бизнеса и базы клиентов — от 10 до 30% неудавшихся списаний с нормальным dunning-флоу. Инженерные усилия — скромные. Не делать это — постоянная, накапливающаяся утечка.

Апгрейд, даунгрейд и паузы

Изменение тарифа в середине цикла требует пропорционального расчёта: если пользователь переходит на более дорогой тариф на 15-й день 30-дневного цикла, он должен половину разницы в цене за текущий период. Этот расчёт должен быть согласованным, аудируемым и проверенным на граничных случаях (годовые тарифы, тарифы с разными датами биллинга, тарифы с дополнениями).

Флоу паузы снижает отток. Подписчики, которые иначе бы отменили, часто принимают «пропустить месяц», если опция видима. Инженерная сложность в том, чтобы заранее решить, что «пауза» означает конкретно: получают ли подписчики следующую отгрузку? У них ещё активен аккаунт? Списывается ли с них уменьшенная сумма или ничего? Эти решения нужно принять заранее — они влияют на интеграцию с fulfillment, логику контроля доступа и настройку биллинга. Универсального ответа нет — зависит от вашей модели.

Проблема отчётности

Транзакционная e-commerce отчётность не переносится на подписки. MRR, удержание чистой выручки, churn по когортам, LTV — всё это требует модели данных, которая отслеживает состояние подписки во времени, а не только записи о списаниях в конкретный момент. Стройте это с первого дня. Если пропустить и вернуться позже — восстановить историческое состояние подписок из записей о платежах по-настоящему болезненно и никогда не выходит точно.