Ви — SaaS-стартап, і вам потрібно впровадити підписки? Або у вас уже є система, але ви втрачаєте до 20% виручки через проблеми з автоплатежами? Реалізація підписної моделі потребує не просто прикрутити платіжний шлюз — треба продумати життєвий цикл: тріал, грацієнт, обробка відмов, апгрейди та аналітику. Наша команда вже 10 років будує такі системи для десятків проєктів. За 5 років ми випустили понад 20 підписних рішень — від простих щомісячних планів до складних enterprise-схем з мультивалютністю та пробними періодами. У цьому матеріалі розберемо ключові технічні рішення.
Як влаштована реалізація підписної моделі?
Підписна модель потребує продуманої схеми даних та бізнес-логіки. Розглянемо структуру бази даних та вибір платіжного провайдера.
Модель даних
plans ( id, name, billing_period: monthly | yearly | weekly, price, currency, trial_days, features (jsonb), is_active ) subscriptions ( id, user_id, plan_id, status: trialing | active | past_due | canceled | expired, current_period_start, current_period_end, trial_ends_at, cancel_at_period_end (boolean), canceled_at, payment_method_id, external_subscription_id (id в платіжній системі) ) subscription_invoices ( id, subscription_id, amount, currency, status: draft | open | paid | failed | void, attempt_count, next_attempt_at, paid_at, payment_id ) Вибір платіжного провайдера
| Провайдер | Особливості | Ринок |
|---|---|---|
| Stripe Billing | Вбудоване управління підписками, Smart Retries, Customer Portal | Міжнародний |
| ЮKassa | Автоплатежі через збережені картки, потрібна власна логіка | РФ |
| CloudPayments | Вбудовані підписки з Webhooks | РФ |
Stripe Billing — оптимальний вибір для міжнародного SaaS: він сам керує retry-логікою та надає готовий Customer Portal. Наш досвід показує: використання Stripe скорочує час розробки на 30% порівняно з ЮKassa. Для російського ринку ЮKassa теж підходить, але потребує реалізації власного scheduler'а для повторних списань.
Чому вибір платіжного провайдера критичний?
Від правильного вибору залежить складність розробки та стабільність автоматичних списань. Stripe Dunning Management повертає до 15% успішних платежів завдяки ML-оптимізації часу retry Stripe. Це дозволяє повернути більше клієнтів без вашої участі.
Як працює grace period?
Після першого невдалого списання підписка переходить у статус past_due — користувач зберігає доступ, але отримує сповіщення. Повторні спроби:
- +1 день: перший retry
- +3 дні: другий retry з email-нагадуванням
- +7 днів: фінальна спроба, попередження про відключення
- +10 днів: статус
expired, доступ відкликано
Stripe Dunning Management робить це автоматично. Порівняйте з ручною реалізацією: у першому випадку ви отримуєте до 15% додаткових платежів, у другому — 5–7%. Ефект очевидний.
Автоматичні списання
При використанні Stripe: підписка створюється один раз, Stripe сам керує renewals. При використанні ЮKassa — потрібен власний scheduler:
// Scheduled Job: кожну годину $dueSubscriptions = Subscription::where('status', 'active') ->where('current_period_end', '<=', now()) ->get(); foreach ($dueSubscriptions as $subscription) { dispatch(new RenewSubscriptionJob($subscription)); } RenewSubscriptionJob намагається провести списання через збережений payment method. При успіху — оновлює current_period_end. При невдачі — переводить у past_due та планує повторні спроби.
Апгрейд та даунгрейд тарифу
Зміна тарифу — нетривіальне завдання. Перерахунок суми виконується пропорційно залишку періоду:
- Апгрейд (на дорожчий тариф): негайно, доплата за решту часу періоду
- Даунгрейд (на дешевший тариф): набирає чинності з початку наступного періоду, кредит враховується
$unusedDays = $subscription->daysRemainingInPeriod(); $creditAmount = $unusedDays * ($currentPlan->dailyPrice()); $chargeAmount = $unusedDays * ($newPlan->dailyPrice()) - $creditAmount; Клієнтський портал та управління підпискою
Користувач повинен мати можливість:
- Переглядати поточний тариф та дату наступного списання
- Змінювати тариф (з розрахунком пропорції)
- Оновлювати платіжний метод (введення нової картки через hosted fields)
- Скасовувати підписку з поясненням причини (exit survey)
- Завантажувати інвойси
Stripe надає готовий Customer Portal — hosted-сторінка для управління. Для кастомного UI на ЮKassa потрібно будувати своє. У середньому розробка власного порталу займає 1–2 тижні, але ми зазвичай пропонуємо готове рішення на основі Stripe — це дешевше та швидше на 40%.
Запобігання churn
Технічні рішення для зниження відмови від підписок:
- Email за 3 та 7 днів до списання з нагадуванням суми
- Сповіщення про закінчення терміну дії картки за 30 днів
- Можливість поставити підписку на паузу (замість скасування)
- Офер при скасуванні: знижка 20% на наступний місяць
Ці заходи знижують churn на 15–20% у типових проєктах. Ми гарантуємо, що впровадимо ці механізми у вашу систему. Отримайте консультацію — оцінимо поточну ситуацію.
Типові помилки при реалізації підписок
- Не враховувати зміну платіжного методу при втраті картки — втрачаються клієнти
- Пропускати dunning з постійним терміном життя — йдуть гроші
- Ігнорувати часові пояси — списання спрацьовують у незручний час
- Не перевіряти дублікати списань — подвійні платежі
Аналітика підписок
Ключові метрики: MRR (Monthly Recurring Revenue), Churn Rate, LTV, Trial-to-Paid Conversion, Average Revenue Per User. Для розрахунку потрібні спеціалізовані запити за історичними даними підписок — недостатньо просто підсумувати платежі. Ми будуємо дашборди на цих метриках, щоб ви бачили реальну картину.
Терміни розробки: 4–6 тижнів для повної системи з управлінням lifecycle, retry-логікою, клієнтським порталом та базовою аналітикою. Зв'яжіться з нами для оцінки вашого проєкту — ми підберемо оптимальне рішення та назвемо точні терміни.