Рекуррентные платежи на сайте: как подключить подписки и биллинг

Рекуррентные платежи на сайте — это фундамент подписной экономики: стабильная выручка, предсказуемый LTV и меньше потерь на ручной биллинг. В статье разберём, как реализовать подписки и повторные списания технически и юридически грамотно, какую архитектуру выбрать и как снизить риски чарджбеков.

Рекуррентные платежи на сайте: что это и как работают

Рекуррентные платежи — это автоматические повторные списания по сохранённому платёжному инструменту клиента (карта, аккаунт платёжной системы), согласованные офертой и подтверждённые при первой оплате. Базовые элементы:

• Токенизация карты: провайдер заменяет PAN токеном, вы не касаетесь «голых» данных.
• Мандат (consent): пользователь подтверждает согласие на автосписания, вы храните доказательства.
• Расписание: период, триал, грейс‑период, ретраи при неуспехе.
• Нотификации: письма/мессенджеры о списаниях, изменениях тарифа и отмене.
• Панель администратора/биллинг‑ядро: создание планов, купоны, prorate, налоговые ставки.

Чем рекуррент отличается от «сохранить карту»

Сохранение карты без мандата — это «one‑click»; рекуррент требует явного согласия на автосписания и юридической фиксации условий.

Модели подписки и биллинга: что выбрать под ваш продукт

• Фиксированная подписка: один тариф/период (месяц/год). Проста в запуске.
• Многоуровневые планы: разные лимиты и функции (SaaS, сервисы).
• Usage‑based (по употреблению): списание за фактический объём (минуты, запросы, гигабайты). Нужны метрики и отложенная агрегация.
• Гибрид: фикс + оверплатёж за превышение.
• Триал и freemium: бесплатный период с последующим автосписанием — обязателен явный дисклеймер и напоминание до списания.
• Прорейтинг (prorate): доначисление/возврат при апгрейде/даунгрейде внутри периода.

Для интернет‑магазина рекуррентные модели встречаются в форматах подписки на товары (расходники, питание, медиа) и клубной подписки. Для SaaS — биллинг‑ядро, вебхуки и отчётность обязательны.

Провайдеры и способы оплаты: на что смотреть

В РФ распространены ЮKassa (YooKassa), СберPay, CloudPayments, Тинькофф Касса, Payler и др. Ключевые критерии:

• Автоплатежи: наличие подписок/рекуррентов (автоплатежи ЮKassa, СберPay, CloudPayments), поддержка токенизации и расписаний.
• Способы оплаты: МИР/Visa/Mastercard (в рамках доступности), СБП, СберPay, кошельки, invoice‑линки.
• Комиссии и фрод‑профиль: тарифы по MCC, антифрод‑инструменты, 3‑D Secure 2.
• Вебхуки и SDK: стабильность, ретраи вебхуков, идемпотентность API.
• Эквайер и операционка: время зачислений, отчёты, реестры возвратов.
• Поддержка подписок в СБП: не у всех провайдеров реализована одинаково; уточняйте механику мандатов.

Совет: запросите у провайдера схему статусов событий (invoice.created, charge.succeeded, refund.succeeded, charge.failed) и политику ретраев — это основа корректной интеграции.

Архитектура биллинга для SaaS и интернет‑магазина

Надёжная схема строится вокруг событийной модели:

1. Ваш бэкенд создаёт Customer и привязывает PaymentMethod (токен).
2. Создаётся Subscription с планом/периодом/датой начала.
3. Провайдер шлёт вебхуки о статусах инвойса и списаний.
4. Ваш биллинг‑воркер обрабатывает вебхуки идемпотентно, обновляет статус подписки, начисляет доступы, запускает ретраи.
5. CRM/ERP и аналитика получают события через шину (Kafka/RabbitMQ/HTTP) или напрямую.

Минимальные сущности вашего ядра:

• Customer (профиль/юрданные)
• Subscription (планы, статусы: active, past_due, canceled, unpaid)
• Invoice/Charge (сумма, валюта, налог, статусы)
• PaymentMethod (тип, маска, токен провайдера)
• Events/Logs (аудит, источник, payload)

Для магазинов с подпиской на товары добавьте фичи: окна доставки, управление паузами, замена позиций. Для SaaS — лимитеры и учёт потребления. Рассмотрите выделение кабинета клиента: это упрощает самообслуживание отмены и смену тарифов. Если нужна разработка — смотрите наши услуги E-commerce и интернет-магазины и Личные кабинеты и порталы B2C/B2B.

Правовые аспекты подписки: оферта, согласия, уведомления

• Оферта и тарифы: чётко опишите периодичность списаний, стоимость, пробный период, условия продления и отмены.
• Согласие на автосписание: чекбокс/текст с отсылкой к оферте, отметка в логах (время, IP, user‑agent, версия оферты).
• Уведомления: отправляйте напоминание за 1–3 дня до списания и при изменении тарифа. Для триала — до автостарта платного периода.
• Законы о защите потребителей и персональных данных: корректный DPA/ПДн, хранение логов согласий и логика отзыва согласия.
• Электронные чеки: фискализация (54‑ФЗ) через ОФД при необходимости, корректные теги для подписок/частичных возвратов.

Юридическая прозрачность снижает спорность транзакций и риск чарджбеков.

PCI DSS и хранение карт: чего нельзя делать

«Хранение карт PCI DSS» — частый запрос, но ответ прост: не храните PAN/CVV у себя, если вы не сертифицированный процессинг. Безопасный путь — токенизация у провайдера (PCI DSS Level 1 на их стороне). Что важно у вас:

• Никогда не логируйте полные PAN/CVV, маскируйте чувствительные поля.
• Шифруйте секреты и ключи, используйте HSM/KMS.
• Минимизируйте скоуп: перенесите ввод карт на хостед‑пейдж/виджет провайдера.
• Проводите регулярные пентесты и сканирования уязвимостей.
• Разделяйте роли и доступы, храните артефакты аудита.

Если нужна комплексная автоматизация и связка биллинга с бизнес‑процессами — изучите CRM/ERP модули и автоматизация.

Интеграция платежей с CRM и аналитикой

«Интеграция платежей с CRM» — критична для LTV и удержания:

• CRM: синхронизируйте статусы подписки, суммы, даты следующего списания, причины отмены. Запускайте триггеры (ожидаемое списание, просрочка, апгрейд).
• DWH/BI: выгружайте инвойсы и события в хранилище, стройте MRR, ARR, churn, dunning‑эффективность, ретеншен‑когорты.
• Маркетинг: сегменты «истекает подписка», «не прошёл платёж» для цепочек в e‑mail/мессенджерах.
• Сквозная аналитика: связывайте рекламные клики с фактическими повторными оплатами. В помощь — статья «Сквозная аналитика: что это, как работает и кому нужна» (https://lightson.agency/blog/stati/skvoznaya-analitika-chto-eto-kak-rabotaet-i-komu-nuzhna).

Технически это вебхуки от провайдера + очередь событий и коннекторы в CRM/BI. Проверяйте идемпотентность: одно событие — один апдейт.

Чарджбек и возвраты: политика и процессы

• Политика возвратов: опубликуйте простые условия (когда делаете full/partial refund, сроки). Уберите двусмысленность.
• Dispute‑процедуры: храните логи согласия и коммуникаций, фискируйте факт использования сервиса. Это помогает в оспаривании.
• Dunning (борьба с неуспехами): каскад ретраев (например, +1д, +3д, +7д), изменение платёжного метода, напоминания клиенту.
• Лимиты и антифрод: velocity‑лимиты, device‑fingerprint, проверка e‑mail/телефона. Включите 3‑DS2, где это возможно.
• Разделение кодов отказа: различайте insufficient_funds, do_not_honor, expired_card — разная логика ретраев и сообщений.

Отмена подписки: как настроить корректно

«Отмена подписки как настроить» — частый UX‑вопрос. Рекомендации:

• Кнопка отмены — в 1–2 клика в личном кабинете, без скрытых барьеров.
• Уточняйте причину отмены (список + свободное поле) и сохраняйте её в CRM.
• Показывайте, когда доступ сохранится до конца оплаченного периода.
• Предлагайте даунгрейд/паузу вместо отмены, но без агрессии.
• Подтверждение на e‑mail/мессенджер с номером запроса отмены.

Это снижает негатив и чарджбеки, повышая шанс возврата клиента.

Пошаговая интеграция: чек‑лист

• Определите модель монетизации: фикс/usage/hybrid, периоды, триал, prorate.
• Выберите провайдера: автоплатежи ЮKassa/СберPay/CloudPayments, способы оплаты, комиссии, вебхуки.
• Подготовьте оферту и UX: согласие на автосписания, напоминания, страница тарифов.
• Спроектируйте сущности: Customer, Subscription, Invoice, PaymentMethod, Events.
• Реализуйте биллинг‑воркеры: идемпотентность, ретраи, обработка статусов.
• Настройте CRM/ERP и BI: статусы подписок, сегменты, отчёты MRR/ARR/churn.
• Включите антифрод: 3‑DS2, лимиты, поведенческие правила.
• Проведите QA: юзкейсы списаний/отмен, prorate, возвраты, сбои вебхуков.
• Запустите мониторинг: алерты по fail‑rate, задержкам вебхуков, MRR‑аномалиям.
• Подготовьте саппорт‑скрипты: ответы на частые вопросы, шаблоны писем.

Тестирование и ввод в эксплуатацию

• Песочница провайдера: пройдите успешные/неуспешные платежи, 3‑DS, истёкшая карта, insufficient funds, отмена до и после списания.
• Нагрузочное тестирование: пик первого дня месяца, каскадные ретраи, «шторма» вебхуков.
• Катастрофоустойчивость: очереди с DLQ, повторная обработка событий, хранимые ретраи.
• Observability: метрики (успешность списаний по провайдерам/банкам), логи вебхуков, трассировка воркеров.
• Пост‑мортемы: фиксируйте инциденты, улучшайте правила ретраев и тексты уведомлений.

Когда стоит выделить отдельный модуль биллинга

• 3+ модели списаний и usage‑учёт.
• Мультивалюта и налоговые режимы.
• Несколько провайдеров и каскад эквайринга.
• Сложные скидки/купонные кампании.
• Требования к SLA и отчётности на уровне ERP.

Если вы доросли до этого уровня, полезно строить выделенный сервис биллинга и единый кабинет. Наши проекты по E-commerce и интернет-магазины и Личные кабинеты и порталы B2C/B2B закрывают такие задачи вместе с интеграциями CRM/ERP модули и автоматизация.

Полезные материалы по теме

• Интеграция CRM с сайтом: как автоматизировать заявки и продажи: https://lightson.agency/blog/stati/integracziya-crm-s-sajtom-kak-avtomatizirovat-zayavki-i-prodazhi
• Сквозная аналитика: что это, как работает и кому нужна: https://lightson.agency/blog/stati/skvoznaya-analitika-chto-eto-kak-rabotaet-i-komu-nuzhna

Вывод

Рекуррентные платежи — это не только «включить автосписания», а целая система: провайдеры, биллинг‑ядро, юридическая база, UX отмены, антифрод и аналитика. Начните с модели монетизации и карты событий, затем соберите интеграцию вокруг вебхуков и CRM. Нужна помощь с архитектурой, интеграцией и разработкой кабинета? Оставьте заявку — команда LightsOn соберёт решение под ваши процессы, без лишней сложности и с прицелом на масштаб.