Архітектура 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 — все це потребує моделі даних, що відстежує стан підписки з часом, а не лише записи про списання в конкретний момент. Будуйте це з першого дня. Якщо пропустити і повернутися пізніше — відновити історичний стан підписок із записів про платежі по-справжньому болісно і ніколи не виходить точно.