Подписочная модель заманчива: клиент платит один раз, а деньги приходят регулярно сами. Но за словами «сохранённая карта» и «автосписание» прячется целая инженерная система — токенизация, согласия, кассовые чеки на каждый платёж, обработка сбоев. Сделать её кое-как — значит нарваться на споры с клиентами, нарушения 54-ФЗ и потерю части выручки на неудачных списаниях.
В этой статье разберём, как правильно устроить рекуррентные платежи и сохранённые карты для подписок на 1С-Битрикс: почему сайт не хранит данные карты, как проходит первый платёж и последующие автосписания, что требует 54-ФЗ и как обрабатывать ошибки. Настройку платежей и учёта мы закрываем услугой автоматизации продаж и склада на 1С.
Коротко
- Сайт не хранит данные карты — только токен от платёжного провайдера; полные реквизиты остаются в PCI DSS-среде.
- Первый платёж клиент делает вручную с явным согласием на привязку и регулярные списания.
- Каждое автосписание требует кассового чека по 54-ФЗ — он должен формироваться и уходить клиенту автоматически.
- Без логики повторов, уведомлений и управления подпиской в кабинете часть регулярной выручки теряется.
Зачем магазину рекуррентные платежи
Рекуррентные платежи — это автоматические регулярные списания с карты клиента без его участия в каждый момент оплаты. Модель подписки превращает разовые продажи в предсказуемый повторяющийся доход, а для клиента убирает рутину: не нужно каждый месяц вспоминать про оплату и вводить карту заново.
Сценариев много: доступ к сервису или контенту, регулярные поставки товаров (вода, корм, косметика), абонентское обслуживание, SaaS. Общее у них — периодичность и удобство «заплатил и забыл». Но именно автоматизм требует особой аккуратности: раз система списывает деньги сама, каждый шаг — согласие, чек, обработка сбоя — должен быть выверен, иначе автоматизм оборачивается претензиями.
Как это работает: токен вместо карты
Ключевой принцип, который снимает большинство страхов: сайт никогда не хранит данные карты. Вместо номера, срока и CVV он оперирует токеном — обезличенным идентификатором, который выдаёт платёжный провайдер после первой оплаты.
- Клиент вводит карту на стороне провайдера. Данные попадают в сертифицированную PCI DSS-среду, а не на ваш сервер.
- Провайдер возвращает токен. Это ссылка на карту, по которой можно списывать, но нельзя восстановить реквизиты.
- Сайт хранит только токен. Привязывает его к клиенту и подписке в своей базе.
- Списания идут по токену. Для каждого регулярного платежа сайт просит провайдера списать сумму по токену.
Украденный токен бесполезен: без доступа к среде провайдера по нему ничего не сделать. Поэтому токенизация — безопасная и обязательная основа сохранённых карт, а самостоятельное хранение реквизитов недопустимо ни при каких условиях.
Первый платёж и привязка карты
Всё начинается с первого платежа — он особенный. Клиент вводит карту вручную и одновременно даёт согласие на её привязку и будущие регулярные списания. Этот момент критичен и юридически, и с точки зрения доверия.
Согласие должно быть явным и понятным: клиент видит сумму, периодичность списаний и условия отмены до того, как соглашается. Никаких скрытых или заранее проставленных галочек — это и правовой риск, и прямой путь к спорам и возвратам через банк. Хорошая практика — отдельный понятный экран или блок «вы соглашаетесь на подписку N рублей каждый месяц, отменить можно в кабинете». Прозрачность на первом платеже избавляет от конфликтов на последующих.
Автосписания по расписанию
После привязки карты вступает в дело автоматика. По расписанию (раз в месяц, неделю, любой период) система инициирует списание по токену без участия клиента. В 1С-Битрикс регулярные фоновые задачи удобно строить на агентах или cron — они запускают проверку подписок и инициируют платежи по наступившим датам.
Логика планировщика должна быть надёжной и идемпотентной: списание за период выполняется ровно один раз, повторный запуск задачи не должен списать деньги дважды. Для этого фиксируют статус каждого периода (запланировано, оплачено, ошибка) и проверяют его перед списанием. Такая аккуратность в фоновых процессах — та же дисциплина, что и в надёжном деплое: как выстраивать управляемые автоматические процессы без сюрпризов, мы разбираем в статье про CI/CD и деплой в Битрикс.
Безопасность и PCI DSS
Тема платежей неотделима от безопасности, и здесь важно понимать разделение ответственности.
| Что | Где хранится / выполняется | Ответственность |
|---|---|---|
| Номер карты, CVV | Среда провайдера (PCI DSS) | Платёжный провайдер |
| Токен карты | База сайта | Ваш сайт |
| Инициация списания | Сайт → API провайдера | Ваш сайт |
| Само списание | Банк ↔ провайдер | Провайдер, банк |
| Кассовый чек | Онлайн-касса, ОФД | Ваш сайт / касса |
Взаимодействие сайта с провайдером идёт через защищённый API и обычно подкрепляется вебхуками — провайдер уведомляет сайт о результате списания. Настраивать этот обмен нужно с оглядкой на безопасность: проверять подписи уведомлений, закрывать доступ, не доверять входящим данным вслепую. Принципы безопасного API мы подробно разбираем в статье про безопасность REST и вебхуков в Битрикс.
54-ФЗ и кассовые чеки
Автоматизм списаний не отменяет кассовую дисциплину — наоборот, усложняет её. Каждое регулярное списание по 54-ФЗ является расчётом и требует кассового чека. Онлайн-касса должна сформировать чек на каждый успешный платёж и направить его клиенту, обычно на email.
В 1С-Битрикс за это отвечает подсистема кассовых чеков, связанная с платёжной системой и оператором фискальных данных (ОФД). Ключевое требование — чек уходит автоматически при каждом списании, без ручного вмешательства. Легко упустить: настроили автосписания, а чеки формируются только на первый платёж — и с каждым последующим накапливается нарушение. Поэтому фискализацию встраивают в саму логику рекуррента: успешное списание немедленно инициирует чек с корректными реквизитами и составом.
Обработка ошибок списания
Автосписание — не гарантированная операция. Карта могла истечь, на счету недостаточно средств, сработал лимит, банк отклонил платёж. Без продуманной обработки таких сбоев подписочная модель теряет часть выручки просто на технических отказах.
- Повторные попытки. Несколько ретраев с нарастающим интервалом — часто на второй-третий раз средства появляются.
- Уведомления клиенту. «Не удалось списать, обновите карту или пополните счёт» с ссылкой на кабинет.
- Понятная политика. Через сколько неудач подписка приостанавливается, когда отменяется — правила заданы заранее.
- Grace-период. Небольшая отсрочка перед отключением, чтобы не терять клиента из-за случайного сбоя.
Хорошая обработка ошибок нередко возвращает значимую долю «потерянных» платежей — это прямые деньги, а не абстрактное удобство.
Управление подпиской в кабинете
Прозрачность работает в обе стороны: клиент должен управлять подпиской сам. В личном кабинете нужно показать привязанные карты, статус подписки, дату и сумму следующего списания и дать простые действия — отменить подписку, сменить карту, приостановить.
Лёгкая отмена — не потеря клиента, а защита от споров. Если отменить сложно, клиент идёт в банк и оспаривает платёж (chargeback), что хуже для вас, чем добровольная отмена. Плюс понятный кабинет снижает поток обращений в поддержку. Сделайте управление подпиской очевидным и честным — это окупается меньшим числом конфликтов и возвратов.
Реализация в 1С-Битрикс
Технически подписки в Битрикс собираются на базе модуля «Интернет-магазин» и платёжной подсистемы. Общая последовательность:
- Выберите совместимого провайдера. Убедитесь, что платёжная система поддерживает токенизацию и рекуррентные списания по вашему договору.
- Настройте первый платёж с привязкой. Оплата на стороне провайдера, получение и сохранение токена, явное согласие клиента.
- Заведите сущность подписки. Периодичность, сумма, статус, дата следующего списания, привязка токена к клиенту.
- Постройте планировщик. Агент или cron проверяет наступившие даты и инициирует списания идемпотентно.
- Подключите фискализацию. На каждый успешный платёж — кассовый чек через онлайн-кассу и ОФД.
- Добавьте обработку ошибок. Ретраи, уведомления, политика приостановки и отмены.
- Сделайте кабинет. Просмотр карт и подписок, отмена и смена карты в пару кликов.
Особенности для B2B
В B2B подписочная модель работает иначе, потому что бизнес чаще платит не картой, а по счёту с отсрочкой. Рекуррент по карте здесь уместен для абонентских услуг, SaaS и небольших регулярных поставок, где расчёт картой естественен. Для крупного опта регулярность реализуют не автосписанием, а периодическим выставлением счетов и повторными заказами.
Поэтому модель выбирают под реальный способ расчёта клиента: карта — для одних сценариев, счёт с отсрочкой — для других. Часто на B2B-портале уживаются оба механизма: физлица и мелкий бизнес на карточной подписке, крупные контрагенты — на регулярных счетах. Логика повторных заказов, из которой естественно вырастает регулярность поставок, тесно связана со сценариями оптовой корзины — эту тему мы разбираем отдельно. А данные о контрагентах и условиях расчёта приходят из учётной системы, работу с которой удобно вести через D7 ORM.
Частые ошибки
- Хранят данные карты на сайте. Грубейшее нарушение безопасности; хранить можно только токен.
- Скрытое согласие на подписку. Предустановленная галочка ведёт к спорам и chargeback.
- Чек только на первый платёж. Последующие списания без чека — нарушение 54-ФЗ.
- Нет обработки сбоев. Одна неудачная попытка — и клиент молча потерян.
- Неидемпотентный планировщик. Повторный запуск списывает деньги дважды.
- Отмена «через поддержку». Сложная отмена гонит клиента в банк оспаривать платёж.
- Провайдер без поддержки рекуррента. Выяснилось после разработки — а функции нет.
Чек-лист внедрения
- Провайдер совместим. Токенизация и рекуррентные списания подтверждены договором.
- Карта не хранится. На сайте только токен, реквизиты — в PCI DSS-среде провайдера.
- Согласие явное. Клиент видит сумму, период и условия отмены до первого платежа.
- Планировщик надёжен. Списания идемпотентны, статусы периодов фиксируются.
- Чеки автоматичны. Каждый платёж фискализируется и уходит клиенту по 54-ФЗ.
- Ошибки обрабатываются. Ретраи, уведомления, политика приостановки и grace-период.
- Кабинет готов. Клиент видит карты и подписки, легко отменяет и меняет карту.
- Модель под расчёт. Карта или счёт выбраны под реальный способ оплаты клиента.
Вывод
Рекуррентные платежи превращают разовые продажи в предсказуемый доход, но за удобством стоит выверенная система. Её фундамент — токенизация: сайт хранит не карту, а безопасный токен, и списывает по нему через сертифицированного провайдера. На этом фундаменте выстраиваются явное согласие на первом платеже, надёжный планировщик автосписаний, кассовые чеки на каждый расчёт по 54-ФЗ и продуманная обработка сбоев.
Слабое звено обесценивает всю схему: забытые чеки — это нарушение, скрытое согласие — споры, отсутствие ретраев — потерянная выручка, сложная отмена — chargeback. Соберите все элементы аккуратно, дайте клиенту прозрачное управление подпиской в кабинете — и подписочная модель на 1С-Битрикс станет стабильным и юридически чистым источником регулярного дохода.
