Я Максим, веб-разработчик. Рекуррентные платежи — основа любой подписочной модели: фитнес-клубы, SaaS-сервисы, онлайн-школы, доставка еды по подписке, техподдержка сайтов (мой собственный сервис тоже работает на рекуррентах). За последние полтора года я настроил автоматические списания на шести проектах и знаю все подводные камни — от технических до юридических. Расскажу по порядку, как реализовать рекурренты правильно.

Как работают рекуррентные платежи изнутри

Многие думают, что рекуррентный платёж — это когда сайт «помнит» данные карты и списывает деньги. Это не совсем так, и разница принципиальна.

При первом платеже клиент вводит данные карты на защищённой странице платёжной системы (не на вашем сайте — хранить карточные данные на своём сервере запрещено стандартом PCI DSS, если вы не банк). Платёжная система проводит платёж и токенизирует карту — создаёт зашифрованный идентификатор (токен), привязанный к этой карте и вашему магазину. Токен хранится на вашем сервере или в платёжной системе.

Последующие платежи: ваш сервер отправляет API-запрос к платёжной системе с токеном и суммой. Платёжная система списывает деньги без участия клиента — ему не нужно ничего вводить. Каждое списание формирует чек по 54-ФЗ и отправляет его клиенту.

Важно понимать: токен привязан к конкретной карте. Если клиент перевыпустит карту (например, из-за окончания срока действия) — старый токен перестанет работать. Некоторые банки поддерживают автоматическое обновление токенов при перевыпуске (Account Updater), но не все российские банки это реализовали. Поэтому часть подписок «сломается» при перевыпуске карт — и к этому нужно быть готовым.

Платёжные системы с поддержкой рекуррентов в России

Не все платёжные агрегаторы одинаково хорошо поддерживают рекуррентные платежи. Вот мой опыт с основными.

ЮKassa — самый популярный платёжный агрегатор в России, и рекурренты здесь реализованы хорошо. При первом платеже указываете в API-запросе параметр save_payment_method: true. Получаете payment_method_id, который используете для последующих списаний. Документация подробная, поддержка отвечает быстро. Из нюансов: ЮKassa не поддерживает автоматическое расписание подписки — вы сами управляете датами списания через свой сервер (cron-задачи или очереди).

Т-Банк (бывший Тинькофф Оплата) — рекуррентные платежи реализуются через метод Init с параметром Recurrent: true. Первый платёж привязывает карту, дальнейшие списания — через метод Charge. Мне нравится API Т-Банка за чистоту и логичность, но документация иногда отстаёт от реальности — бывали случаи, когда код из документации не работал, и приходилось уточнять в поддержке.

CloudPayments — на мой взгляд, лучший выбор для подписочных моделей. У них встроенная система подписок с гибким расписанием: вы создаёте подписку через API или личный кабинет, указываете сумму, периодичность (ежемесячно, еженедельно, кастомный интервал), и CloudPayments сам управляет списаниями. Плюс автоматические уведомления перед списанием, встроенная retry-логика при неудачных платежах и детальная аналитика. Стоимость выше, чем у ЮKassa — комиссия от 2.7%, но для подписочного бизнеса разница окупается экономией времени на разработку.

Robokassa — поддерживает рекурренты, но функционал базовый. Подходит для простых сценариев, но для серьёзного подписочного бизнеса я бы выбрал CloudPayments или ЮKassa.

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

Если платёжная система не управляет расписанием подписок (как ЮKassa), вам нужна серверная логика. Вот как я это реализую на Node.js.

База данных хранит информацию о каждой подписке: ID пользователя, ID тарифа, токен платёжного метода, дата следующего списания, статус (active, past_due, cancelled, paused), количество неудачных попыток списания.

Cron-задача (или очередь задач через BullMQ / Agenda) запускается ежедневно в заданное время и выбирает все подписки, у которых дата следующего списания — сегодня. Для каждой подписки отправляется запрос на списание через API платёжной системы.

Если платёж прошёл — обновляем дату следующего списания (плюс месяц, квартал, год — в зависимости от тарифа), сбрасываем счётчик неудачных попыток. Если платёж не прошёл — увеличиваем счётчик, планируем повторную попытку через 1 день, отправляем email клиенту. Если 4 попытки подряд не удались — переводим подписку в статус past_due, блокируем доступ, отправляем финальное уведомление.

Эта retry-логика (dunning management) — критически важная часть. По моим данным, она спасает от 15 до 30% подписок, которые были бы потеряны при первой неудачной попытке.

Юридические нюансы: что требует закон

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

Согласие клиента: перед первым списанием клиент должен явно согласиться на автоматические платежи. Это не просто юридическая формальность — это требование и 161-ФЗ, и правил платёжных систем (Visa, Mastercard, МИР). Реализуется через чекбокс при оформлении подписки: «Я согласен на автоматическое списание X рублей каждый месяц». Чекбокс не должен быть предзаполненным. Согласие фиксируется в логах с таймстемпом.

Уведомление перед списанием: 376-ФЗ обязывает уведомлять клиента перед каждым автосписанием и давать возможность отказаться. Я отправляю email за 3 дня до списания: сумма, дата, ссылка для отмены в один клик. Это не только юридическое требование, но и хорошая практика — снижает количество чарджбэков.

Возможность отмены: клиент должен иметь возможность отменить подписку в любой момент — через личный кабинет, через email в поддержку, через чат. Процесс отмены не должен быть намеренно усложнён — никаких «позвоните по телефону с 9 до 18 для отмены».

54-ФЗ и онлайн-касса: каждое рекуррентное списание — это фискальная операция. Необходимо формировать чек и отправлять его клиенту. Большинство платёжных систем интегрированы с онлайн-кассами (АТОЛ, OrangeData) и делают это автоматически, но убедитесь, что интеграция настроена.

UX-аспекты: как не разочаровать клиента

Прозрачность — ключевой принцип. Клиент должен всегда знать: сколько будет списано, когда будет списано, как отменить. Эта информация должна быть доступна в личном кабинете в один клик — не на третьем уровне вложенности настроек.

Страница управления подпиской в личном кабинете должна показывать: текущий тариф и стоимость, дату следующего списания, историю платежей, кнопку «Изменить тариф» и кнопку «Отменить подписку».

При смене тарифа посреди периода (например, переход с базового на премиум в середине месяца) нужна логика proration — пересчёт суммы пропорционально оставшимся дням. Это нетривиальная задача, но CloudPayments и Stripe (для международных проектов) поддерживают пропорциональный пересчёт из коробки.

Сроки и стоимость интеграции

Базовая интеграция рекуррентных платежей через ЮKassa или Т-Банк: 1–2 дня разработки для опытного разработчика. Это включает первый платёж с сохранением токена, эндпоинт для автоматического списания, базовую retry-логику.

Полноценная подписочная система с личным кабинетом, управлением тарифами, dunning management, уведомлениями и аналитикой: 5–10 дней разработки.

Использование CloudPayments с встроенной системой подписок: 2–3 дня — платёжная система берёт на себя управление расписанием и retry.

Итог

Рекуррентные платежи технически не сложнее обычной оплаты — основная работа в обслуживающей логике: retry при неудачах, уведомления, управление статусами, юридическое соответствие. Сделайте процесс максимально прозрачным для клиента — и подписочная модель будет приносить стабильный предсказуемый доход каждый месяц.