Рекуррентные платежи на Битрикс: автосписания через ЮKassa, Т-Банк, Сбербанк и CloudPayments

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

Почему наивная привязка карты — это мина замедленного действия

Соблазн понятен: взять один шлюз, прикрутить сохранение карты, запустить ежемесячное списание и считать задачу закрытой. На демонстрации это работает идеально. Проблемы начинаются на объёме. Часть карт перевыпускается, и токены устаревают. На части карт в день списания не хватает денег. Банк изредка отклоняет операцию по своим причинам. Вебхук о смене статуса не доходит из-за сетевого сбоя, и в системе платёж висит в подвешенном состоянии, хотя в банке он давно прошёл или отклонён. Без отдельной логики на каждый из этих случаев вы либо теряете выручку молча, либо списываете дважды, либо не понимаете, кто вам реально заплатил.

Поэтому рекуррентные платежи мы рассматриваем не как кнопку, а как небольшую систему с понятными состояниями: карта привязана, списание запланировано, попытка прошла, попытка отклонена, идёт повтор, подписка приостановлена, оформлен возврат. Каждое состояние имеет свой обработчик, своё уведомление и своё отражение в учёте. Именно эта дисциплина отличает работающие автосписания от хрупкой связки, которая ломается на первом же нестандартном сценарии.

Токенизация и безопасность: почему карты не должны быть у вас

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

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

Dunning: где на самом деле теряется и возвращается выручка

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

Dunning — это и есть стратегия повторных попыток. Мы настраиваем график ретраев: повтор через несколько часов, через сутки, через несколько дней, в моменты, когда вероятность успешного списания выше. Параллельно клиент получает мягкое уведомление о том, что списание не прошло, с возможностью обновить карту. На практике грамотный dunning возвращает значимую долю отказных платежей без единого звонка менеджера. Именно поэтому на этой странице есть умный расчёт: он помогает заранее прикинуть, сколько денег вы сейчас теряете на отказах и сколько из них реально вернуть.

Фискализация по 54-ФЗ при платежах без участия клиента

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

Параметры чека — ставку НДС, признаки расчёта, наименование позиции — мы согласуем на старте под вашу номенклатуру. Это важно сделать заранее: переделывать настройки фискализации задним числом, когда чеки уже уходят клиентам, заметно дороже, чем продумать их при запуске. Мы закладываем это в этап настройки и проверяем на тестовых операциях до выхода в боевой режим.

Вебхуки и сверка: чтобы статусы всегда сходились

Когда платёж проходит на стороне банка, ваша система должна узнать об этом и отразить результат. Основной канал — вебхуки: шлюз присылает уведомление о смене статуса операции. Но вебхуки не дают стопроцентной гарантии доставки: сетевой сбой, перезапуск сервера, временная недоступность — и одно сообщение может не дойти. Если полагаться только на них, рано или поздно в системе появятся платежи с неверным статусом.

Поэтому поверх вебхуков мы всегда настраиваем регулярную сверку: задача периодически опрашивает шлюз и сопоставляет состояние операций с тем, что записано в Битриксе, и устраняет расхождения. Такая двойная защита — реактивные вебхуки плюс плановая сверка — даёт надёжную картину: вы видите ровно те платежи, которые реально прошли, и не списываете повторно то, что уже оплачено. Это особенно важно при больших объёмах, где даже доля процента ошибок выливается в заметные суммы и потерю доверия клиентов.

Зачем подключать все четыре шлюза

Один шлюз — это одна точка отказа и одни условия. Когда вы подключаете ЮKassa, Т-Банк, Сбербанк и CloudPayments сразу, вы получаете устойчивость и гибкость. Если провайдер временно недоступен или массово отклоняет операции, списание уходит через другой банк. Если у банков различаются комиссии или условия по отдельным типам карт, можно маршрутизировать платежи туда, где выгоднее. И вы перестаёте зависеть от решений одного партнёра, который в любой момент может изменить тарифы или правила.

При этом подключение всех шлюзов не обязано быть единовременным. Часто разумно стартовать с одного привычного провайдера, запустить автосписания и убедиться, что всё работает, а затем добавлять остальные банки итерациями. Архитектуру мы строим так, чтобы новый шлюз подключался как отдельный модуль и не требовал переделки уже работающей логики списаний, dunning и фискализации. Так вы наращиваете надёжность платежей в комфортном темпе.

Возражения, которые мы слышим чаще всего

«Это рискованно — хранить карты клиентов». Вы их не храните. Вся суть токенизации в том, что реквизиты остаются у сертифицированного шлюза, а у вас только токен. Списание по токену не раскрывает номер карты, поэтому риск утечки с вашей стороны снимается на уровне архитектуры, а не обещаний.

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

«У нас уже есть приём оплаты, зачем что-то менять». Разовый приём оплаты и рекуррентные платежи — это разные механизмы. Если сейчас клиенты продлевают подписку вручную, вы теряете тех, кто просто забыл. Перевод на автосписания с dunning и уведомлениями обычно окупается быстро именно за счёт снижения оттока по забывчивости и возврата отказных платежей.

Как мы ведём проект и что вы получаете на выходе

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

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

Сценарии, под которые мы собираем автосписания

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

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

Что важно продумать заранее

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

С чего начать

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