Рекуррентные платежи и подписки: токены, оферта, ретраи, отмены

Что такое рекуррентные платежи и когда они нужны

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

Типичные сценарии:

SaaS и онлайн‑сервисы (месячная/годовая подписка);
медиа и EdTech (периодическая подписка на контент);
фитнес, приложения, сервисные пакеты (продление memberships);
аренда ПО, домены/хостинг, корпоративные лицензии.

Если вы только выбираете, как подключить оплату, посмотрите наш гид по интеграции провайдеров на страницу «Подключение платёжной системы к сайту».

Как это работает: путь плательщика

Пользователь выбирает план и создаёт подписку на сайте.
Проходит привязка карты: первый платёж подтверждается по 3‑D Secure (CIT) и карта токенизируется.
Провайдер возвращает токен — безопасный идентификатор карты.
По расписанию вы инициируете повторные списания (MIT) с токена без участия клиента.
При неуспехе запускаются ретраи и уведомления (dunning).
Пользователь может изменить карту, паузить или отменить подписку.

![Схема процесса рекуррентного платежа: привязка карты, токен, списания, ретраи, отмена]

Получить CloudPayments бесплатно

Привязка карты и токенизация

«Привязка карты токен» — ключ к безопасным автосписаниям. Вместо хранения PAN и CVV вы храните токен, который работает только у вашего провайдера эквайринга.

Как это устроено:

Первый платёж (или нулевая предавторизация) проводится с 3‑D Secure, чтобы получить согласие держателя карты.
Провайдер возвращает token/recurringId. С ним вы инициируете будущие списания.
Токены не являются карточными данными, но всё равно требуют корректного обращения и контроля доступа.

Рекомендуется настроить привязку через флоу с 3‑D Secure и параметрами recurring/mit, подробно об этом — в разделе «PCI DSS, безопасность и 3‑D Secure».

Оферта и согласие на списания

Для подписок на сайте важно юридически корректное согласие пользователя:

публичная оферта с понятными условиями: размер платежа, периодичность, дата первого списания, порядок продления, условия отмены и возврата;
чек‑бокс «Я принимаю условия и даю согласие на регулярные списания»;
уведомление о цене после пробного периода и о любых изменениях тарифа;
прозрачная механика отмены с сайта/кабинета.

Если провайдер требует передачи «макс. суммы» или «описания услуги» в MIT, добавьте это в оферту. Для некоторых категорий полезны превентивные уведомления за 3–7 дней до списания.

![Пример экрана настройки подписки с чек‑боксом согласия на регулярные списания]

Расписание платежей и биллинг-циклы

Грамотно заданное расписание платежей снижает отток и количество неуспешных списаний.

Модель	Пример	Комментарий
Ежемесячно	15 числа каждого месяца	Перенос на следующий рабочий день при выходных
С пробным периодом	14 дней бесплатно, затем 990 ₽	В оферте указать дату первого платёжа
Годовая подписка	1 раз в год	Напоминание за 7 дней до продления
Анкор‑биллинг	Все списания 1 числа	Первую оплату рассчитать пропорционально

Dunning и ретраи платежей

Dunning — это процесс работы с неуспешными платежами: повторные попытки списания (ретраи), уведомления, предложения обновить карту.

Почему платежи отклоняются:

недостаточно средств;
истёк срок действия карты, неверный CVV, 3‑D Secure не пройден на первичном шаге;
банк отклоняет по риску или лимитам.

Настройка ретраев:

Тип отклонения	Действие	Пауза между попытками
Soft decline	Повтор через 6–12 часов	6–24 часа
Недостаточно средств	Напоминание клиенту, повтор утром/вечером	12–48 часов
Hard decline	Запрос обновления карты, остановка ретраев	—

Лучшие практики dunning:

умные интервалы (не чаще 3–5 попыток за цикл);
письма/SMS/мессенджеры с безопасной ссылкой «Обновить карту»;
вебхуки и событийная логика для точных статусов — см. «Тестирование, вебхуки и sandbox».

54‑ФЗ и фискализация подписок

Каждое успешное списание по подписке должно фискализироваться. Важно корректно передавать признак расчёта, наименование услуги и ставку НДС, а также своевременно отправлять электронные чеки.

Особенности:

при пробном периоде с оплатой 0 ₽ чек не нужен; при списании после триала чек обязателен;
при частичных возвратах оформляется чек корректировки/возврата;
если ретраи успешны на следующий день, дата чека — дата успешного списания.

Детали реализации смотрите в разделе «54‑ФЗ: онлайн‑касса и фискализация».

Отмена, пауза, возвраты

Пользователь должен легко управлять подпиской:

отмена подписки — немедленно прекращает будущие списания;
пауза — временно относит автосписания без потери настроек;
возвраты — полные или частичные в рамках вашей политики и правил провайдера.

Желательно показывать дату следующего списания, статус подписки и способ оплаты в личном кабинете. После отмены — подтверждение на email и смена статуса токена (деактивация/отвязка).

Выбор провайдера и интеграция

На рынке РФ популярны решения с поддержкой рекуррентных списаний: ЮKassa, CloudPayments, Тинькофф Касса и др. Сравнить условия, комиссии и возможности можно на странице «Сравнение провайдеров РФ».

Пошаговые гайды по подключению:

Готовые CMS/конструкторы:

Методы оплаты: рекуррентные оплаты чаще всего выполняются по банковским картам. СБП не всегда поддерживает подписки; функциональность автоплатежей через СБП доступна ограниченно у отдельных банков. Подробнее — «Методы оплаты: карты и СБП».

PCI DSS и хранение токенов

Хранение токенов PCI безопаснее, чем хранение карт, но не отменяет базовых требований безопасности:

не сохраняйте PAN/CVV на своей стороне;
ограничьте доступ к токенам, шифруйте секреты API, используйте роль‑базированную модель;
защищайте вебхуки подписью и проверкой источника;
обновляйте зависимости и проводите регулярные ревью безопасности.

Подробности по требованиям, 3‑D Secure и снижению PCI‑скоуп — в разделе «PCI DSS, безопасность и 3‑D Secure».

Тестирование и вебхуки

Перед запуском подписок проверьте полный жизненный цикл:

привязка карты, первичная оплата, получение токена;
списания по расписанию, ретраи при soft/hard decline;
уведомления клиенту и обновление карты;
отмена, пауза, возвраты и корректная фискализация чеков;
идемпотентность запросов и обработка таймаутов.

Используйте песочницы провайдеров и симуляцию статусов через вебхуки. Практические примеры — «Тестирование: вебхуки и sandbox».

Частые ошибки и рекомендации

Нет явного согласия на регулярные списания — исправьте оферту и интерфейс чек‑бокса.
Первый платёж не помечен как recurring/CIT — последующие MIT могут отклоняться банками.
Агрессивные ретраи (10+ попыток в день) — ухудшение одобряемости и репутации мерчанта.
Нет удобной отмены подписки — приводит к жалобам и чарджбэкам.
Отсутствует уведомление о повышении цены — юридические риски и рост оттока.
Неверная фискализация при триалах и частичных возвратах — проверяйте логику кассы.

Практические лайфхаки:

планируйте списания на утро будних дней и по локальному часовому поясу клиента;
отправляйте напоминание за 3–7 дней до крупного списания или годового продления;
позволяйте заменить карту заранее, не дожидаясь отказа;
отслеживайте метрики dunning: доля recovery после ретраев, время до успешного списания.

Итоги и что делать дальше

Рекуррентные платежи на сайте — это не только токены и автосписания картой, но и продуманная юридическая часть (оферта и согласие на списания), корректное расписание платежей, качественный dunning/ретрай и прозрачная отмена подписки. Настройте безопасность, фискализацию и тестовые сценарии — и подписки будут расти без лишних рисков.

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

Получить CloudPayments бесплатно