Рекуррентные платежи на сайте нужны, если бизнес продаёт не разовую покупку, а доступ на постоянной основе: курс с ежемесячной оплатой, SaaS-сервис, подписку на контент или коробку с товарами раз в месяц. Я настраивал такие связки и на Tilda, и в WooCommerce, и в кастомных сервисах на Laravel, и каждый раз всплывают одни и те же вопросы: как хранить токен карты, что делать с отвалившимся платежом и как синхронизировать статус подписки с CRM, чтобы менеджер не звонил клиенту, у которого списание не прошло уже три дня.
Что такое рекуррентные платежи и когда без них не обойтись
Рекуррентный платёж это списание по ранее сохранённому реквизиту карты без повторного ввода данных клиентом. Технически это два платежа: первый, «родительский», с явным согласием клиента на автосписания и сохранением токена, и все последующие, которые банк проводит по этому токену уже без участия покупателя. Разница с обычной оплатой в одну кнопку в том, что рекуррент можно инициировать по расписанию сам продавец, а не только клиент по клику.
Схема оправдана, если у продукта есть регулярный цикл оплаты: ежемесячная подписка на сервис, абонемент в фитнес-клуб, годовое обслуживание софта, доступ к закрытому клубу или курсу с оплатой по модулям. Для разового интернет-магазина рекуррент не нужен, здесь хватает обычного приёма оплаты и, при необходимости, доставки через СДЭК. А вот для любого бизнеса с моделью подписки без автосписаний придётся либо вручную выставлять счета каждый месяц, либо терять клиентов, которые забыли продлить.
Как подключить рекуррентные платежи через эквайринг T‑Bank и ЮKassa
У обоих банков логика одинаковая, различаются только названия полей в API. Беру для примера связку, которую чаще всего собираю на практике: T‑Bank Эквайринг плюс кастомный бэкенд.
Шаг 1: получаем согласие и сохраняем токен
Первый платёж клиент проводит вручную, вводя карту на форме оплаты. В запросе на создание платежа передаётся флаг рекуррентности, и в ответе банк возвращает RebillId, привязанный к карте клиента. Этот идентификатор и есть тот самый токен, который дальше используется для автосписаний, сам номер карты сайт не хранит и хранить не должен.
Шаг 2: настраиваем расписание списаний
Дальше на своей стороне держим таблицу подписок с датой следующего платежа, суммой и RebillId. По крону (или таском в очереди) в нужный день вызываем метод повторного платежа с этим идентификатором, банк списывает деньги без участия клиента и присылает webhook с результатом.
Шаг 3: обрабатываем webhook
Webhook обязателен, без него узнать об успехе или отказе списания можно только опросом API, что менее надёжно. На вебхуке обновляем статус подписки, продлеваем доступ и, если платёж не прошёл, запускаем сценарий ретраев из следующего раздела.
Комиссия эквайринга по подписочным платежам зависит от тарифа банка и оборота, а не от того, какой у вас сайт, лендинг или интернет-магазин, поэтому закладывайте её отдельной строкой в юнит-экономику, а не привязывайте к типу площадки.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Автоматические списания в WooCommerce и на Tilda
На WordPress с WooCommerce задача решается быстрее всего: плагин WooCommerce Subscriptions берёт на себя расписание, продления и частично дожим неудачных платежей, а платёжный шлюз T‑Bank или ЮKassa докручивается через их официальные модули для WooCommerce. Из коробки логика заточена под западные процессинги, поэтому под T‑Bank обычно приходится дорабатывать хук на стороне сайта, который дергает метод повторного списания и обновляет статус заказа по webhook.
С Tilda сложнее: встроенной поддержки подписок там нет вообще. Рабочая схема, которую я обычно собираю: форма Tilda отправляет заявку на бэкенд через кастомный скрипт, бэкенд создаёт первый платёж и получает RebillId, дальше все повторные списания и уведомления идут уже не через Tilda, а через отдельный сервис. Сама Tilda в этой связке остаётся витриной и формой, а логика подписок живёт снаружи. Если нужна именно такая интеграция под ключ, с эквайрингом и CRM, у меня есть готовая услуга по разработке комплексных интеграций для сайта, где я беру на себя и связку с банком, и синхронизацию статусов.
Биллинг подписок в CRM: статусы, ретраи и дожим неудачных платежей
CRM здесь нужна не как красивая витрина сделок, а как источник правды о том, кто платит, кто просрочил и кому пора звонить. Обычно завожу у сделки или у карточки клиента поле со статусом подписки и датой следующего списания, дальше все статусы связаны цепочкой.
Основные статусы подписки
- active: доступ открыт, следующее списание по расписанию
- past_due: платёж не прошёл, идёт цикл ретраев, доступ пока сохраняется
- canceled: клиент отменил подписку или ретраи исчерпаны, доступ закрыт
- paused: клиент временно приостановил оплату по договорённости
Расписание ретраев
На практике неудачное списание чаще всего связано не с мошенничеством, а с банальной нехваткой средств на карте или её истечением. Поэтому вместо одной попытки делаю несколько с паузами: повтор через 1 день, потом через 3 дня, потом через 7 дней. Если все три попытки провалились, подписка переходит в canceled, а клиенту уходит письмо с прямой ссылкой на обновление карты. Такая схема в моих проектах обычно вытягивает 60-70% платежей, которые с первого раза не прошли просто из-за технического сбоя на стороне банка-эмитента.
Каждая попытка и её результат обязательно пишутся в CRM отдельной записью в истории сделки, иначе через полгода никто не вспомнит, почему клиенту трижды списали деньги за один месяц или наоборот не списали ни разу.
Уведомления и автоматизация: n8n и Telegram-бот
Ручная сверка списаний с CRM работает, пока клиентов десять. При сотне подписчиков нужна автоматизация, и здесь я обычно ставлю n8n между эквайрингом и CRM: webhook от банка приходит в n8n, сценарий проверяет статус, обновляет сделку через API CRM и параллельно шлёт уведомление клиенту.
Для внутренних уведомлений менеджерам часто собираю отдельного Telegram-бота на aiogram: как только платёж переходит в past_due, бот присылает ответственному менеджеру карточку клиента с суммой и датой следующей попытки списания. Это дешевле и быстрее, чем городить отдельный модуль внутри CRM, а по ощущениям от эксплуатации ничем не хуже коробочных решений. Данные клиентов при этом храню на серверах в РФ, без выгрузки контактов в зарубежные облачные таблицы, это требование 152-ФЗ по локализации персональных данных, а не моя прихоть.
Как выбрать способ подключения: сравнение вариантов
Три рабочих варианта, которые я закрываю на проектах, отличаются не ценой продукта, а тем, сколько своей логики придётся написать и насколько гибко потом можно менять правила ретраев и тарифы.
| Вариант | Срок внедрения | Гибкость логики ретраев | Нужна ли доработка под несколько тарифов |
|---|---|---|---|
| Прямая интеграция с API эквайринга | от 2 недель | полная, всё пишется под задачу | да, каждый тариф описывается в коде |
| Готовый плагин (WooCommerce Subscriptions, Tilda-скрипт под конкретный банк) | от 3-5 дней | ограничена настройками плагина | частично, через фильтры и хуки |
| Заказной сервис-биллинг с CRM на бэкенде | от 4 недель | полная, включая мультивалютность и паузы | да, изначально закладывается в архитектуру |
Для WordPress-магазина с одной-двумя подписками обычно хватает плагина. Если тарифов много, нужны триалы, паузы, апгрейд между тарифами внутри цикла, дешевле сразу закладывать заказной биллинг, чем потом переписывать логику поверх готового плагина.
Частые вопросы
Сколько стоит подключить рекуррентные платежи на сайте?
Простая доработка Tilda-скрипта под передачу RebillId и приём webhook обойдётся от 3 000 ₽, если логика укладывается в разовый скрипт. Комплексная интеграция с CRM и эквайрингом, с расписанием ретраев и статусами подписки, стоит от 40 000 ₽. Заказной биллинг-сервис на бэкенде с личным кабинетом клиента, где он сам меняет карту и тариф, начинается от 300 000 ₽ и занимает от 8 недель.
Можно ли делать рекуррентные платежи без сохранения карты клиента?
Да, и это единственный законный способ. Сайт никогда не хранит номер карты, CVC или срок действия, вместо этого банк-эквайрер после первого платежа возвращает токен вроде RebillId у T‑Bank, и все последующие списания идут по этому токену через API банка. Хранение реквизитов карт на своей стороне требует сертификации PCI DSS, для обычного бизнеса это не нужно и не оправдано.
Что делать, если рекуррентный платёж не прошёл?
Запускать цепочку повторных попыток с паузами, а не пытаться списать ещё раз сразу же. Я обычно ставлю ретраи через 1, 3 и 7 дней, параллельно отправляя клиенту письмо или сообщение в мессенджер с просьбой обновить карту. Если все попытки исчерпаны, подписка переводится в статус canceled и доступ закрывается, чтобы не оказывать услугу бесплатно.
Нужна ли отдельная CRM для управления подписками?
Необязательно заводить новую систему, чаще хватает доработки существующей CRM полями статуса подписки, даты следующего списания и истории попыток оплаты. Отдельный биллинговый модуль имеет смысл, когда подписчиков больше нескольких сотен и ручной контроль статусов через фильтры CRM уже не справляется с нагрузкой.