Подписки и регулярные платежи (рекуррент) в 1С-Битрикс

Разовая продажа приносит деньги один раз, подписка — снова и снова, без нового захода покупателя в корзину. Именно поэтому подписочная модель так притягательна: предсказуемая выручка, понятное планирование, лояльная аудитория. Но за красивой идеей «плати автоматически каждый месяц» стоит довольно тонкая механика — рекуррентные платежи: привязка карты, хранение токена, автосписания по расписанию, обработка отказов, напоминания и чеки на каждое списание. Ошибка в любом из этих узлов бьёт по деньгам и по доверию. Эта статья — практический разбор того, как устроены подписки и регулярные платежи в интернет-магазине на 1С-Битрикс.

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

Что такое подписочная модель и кому она нужна

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

В российской онлайн-рознице и сервисах подписка встречается в нескольких типичных видах:

• Сервисы и доступ. Онлайн-кинотеатры, обучающие платформы, софт по подписке, закрытые клубы и сообщества. Покупатель платит за доступ, который открыт, пока идут списания.
• Box-подписки (коробки). Ежемесячная коробка с товарами: косметика, кофе, корм для питомца, детские наборы. Каждый период — новая отгрузка по регулярному платежу.
• Регулярная доставка расходников. То, что заканчивается предсказуемо: вода, бытовая химия, линзы, витамины, зоотовары. Покупатель один раз настраивает частоту, дальше товар приезжает и оплачивается сам.
• Членство и абонементы. Фитнес, сервисное обслуживание, пакеты поддержки, программы лояльности с ежемесячной платой.

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

Модели подписок и регулярных платежей

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

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

Как работает рекуррентный платёж

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

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

Стадия 2 — последующие автосписания. Когда наступает время очередного платежа, магазину уже не нужен покупатель у экрана. Магазин обращается к платёжной системе: «спиши по токену такому-то такую-то сумму». Платёжная система списывает деньги с привязанной карты и присылает магазину результат — успех или отказ. Покупатель при этом не вводит ничего: он мог давно закрыть браузер, спать или быть в отпуске.

Из этой двухстадийной механики следуют важные выводы. Во-первых, магазин полностью зависит от токена: если токен потерян или недействителен (карта перевыпущена, истёк срок), автосписание не пройдёт. Во-вторых, автосписание всегда инициирует магазин по расписанию — значит, должен быть надёжный планировщик, который в нужный момент запустит списание. В-третьих, у покупателя нет шанса «подтвердить» очередной платёж вручную, поэтому его согласие на регулярные списания собирается один раз, на первом шаге, и должно быть корректно оформлено юридически.

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

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

При первом платеже с флагом «привязать карту» платёжная система, помимо самого списания, создаёт у себя запись о карте и выдаёт магазину токен — строку-идентификатор. По этому токену нельзя восстановить номер карты: он бесполезен за пределами связки «этот магазин — эта платёжная система». Магазин хранит токен рядом с подпиской покупателя и предъявляет его платёжной системе при каждом следующем списании.

Что важно запомнить про хранение:

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

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

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

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

Что уточнять у провайдера до начала работ:

• Поддерживается ли рекуррент в принципе и на вашем тарифе/типе договора.
• Как оформляется привязка карты и согласие на регулярные списания — какие требования к оферте и интерфейсу.
• Как хранится и передаётся токен, есть ли ограничения по сроку его жизни.
• Поддержка переменных сумм, если у вас box-подписка или регулярная доставка с меняющейся суммой.
• Как формируется чек по 54-ФЗ на каждое списание — есть ли облачная касса «в комплекте».
• Как обрабатываются отказы, есть ли рекомендации по ретраям и лимиты на повторные попытки.

Крупные российские платёжные сервисы — ЮKassa, Т-Касса и другие — рекуррентные списания поддерживают, но детали (лимиты, формат согласия, работа с токеном, чеки) у каждого свои. Базовую механику подключения самих платёжных систем в Битриксе — ключи, обработчики, уведомления об оплате, чеки — мы подробно разобрали в отдельной статье про подключение ЮKassa, СБП и Т-Кассы; здесь же фокус именно на регулярной, а не разовой оплате. Практический совет: возьмите документацию провайдера по рекурренту до проектирования и постройте логику подписки вокруг того, что провайдер реально умеет, а не вокруг идеальной картины.

Как реализовать подписки в 1С-Битрикс

В коробочном 1С-Битрикс нет готовой кнопки «включить подписки на весь магазин», поэтому подписочную логику собирают на базе штатных механизмов модуля «Интернет-магазин» и планировщика задач. Опишем практичную архитектуру, которую мы применяем.

Смысловые сущности, из которых строится подписка:

• Подписка — запись о том, что покупатель подписан: на какой товар/тариф, с какой периодичностью, по какой карте (токен), в каком статусе и когда следующее списание.
• Первый заказ и первый платёж — обычный заказ Битрикса, оплаченный через платёжную систему с флагом привязки карты. Именно он порождает токен.
• Повторяющиеся заказы/платежи — на каждый период создаётся новый заказ (или новый платёж), который оплачивается автосписанием по токену. Так каждое списание оставляет корректный документ с чеком.
• Планировщик (агент) — фоновый механизм, который регулярно проверяет, каким подпискам пора списывать, и запускает списания.

Почему на каждый период удобнее создавать новый заказ, а не «доплачивать» к старому: так у каждого расчёта есть свой документ, свой чек по 54-ФЗ, своя история и своя сумма (важно для переменных подписок). Это чище с точки зрения учёта и обмена с 1С. Как настроить обмен заказами и статусами оплаты с учётной системой, мы разбираем в материалах про интеграции; для подписок это тем более важно, ведь заказов становится много и руками их не сверить.

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

Агент автосписаний и статусы подписки

Автосписания невозможны без планировщика — того, кто «просыпается» по расписанию и запускает списания у подписок, которым пора платить. В 1С-Битрикс для этого используют агенты (штатный механизм отложенных периодических задач), а на нагруженных проектах — задания cron на стороне сервера, чтобы не зависеть от посещаемости сайта.

Как обычно работает такой планировщик:

1. Выборка кандидатов. Планировщик находит подписки, у которых наступила дата очередного списания и статус позволяет списывать (активна).
2. Проведение списания. Для каждой такой подписки магазин создаёт заказ/платёж и обращается к платёжной системе с токеном и суммой.
3. Обработка результата. Успех — заказ оплачен, чек сформирован, дата следующего списания сдвигается на период вперёд. Отказ — запускается сценарий ретраев и уведомлений.
4. Обновление статуса. Подписка переводится в нужное состояние: активна, ожидает повторной попытки, приостановлена, отменена.

Критично важные требования к планировщику списаний:

• Идемпотентность. Если задание случайно запустится дважды, покупателя нельзя списать дважды за один период. Каждое списание должно быть однозначно привязано к периоду.
• Устойчивость к сбоям. Обрыв на середине не должен приводить к «полусписанному» состоянию: либо период оплачен и зафиксирован, либо нет.
• Надёжный запуск. На магазинах с подписками агенты лучше запускать через cron, а не «на хите» — иначе в тихие часы списания могут задерживаться.
• Логирование. Каждая попытка списания фиксируется: когда, по какой подписке, с каким результатом. Без логов разбирать спорные ситуации невозможно.

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

Жизненный цикл подписки: актив, пауза, отмена

Подписка — это не «включил и забыл», а объект с жизненным циклом, по которому она путешествует между состояниями. Ясная картина этих переходов помогает не забыть ни один сценарий: и радостный (продление), и болезненный (неоплата, отмена).

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

Жизненный цикл одного платежа

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

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

Напоминания перед списанием

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

Какие уведомления обычно настраивают:

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

Особенно важно предупреждать перед крупными и годовыми списаниями. Разовое годовое продление на заметную сумму без предупреждения — почти гарантированный всплеск возвратов и негатива. Небольшое письмо за несколько дней снимает большую часть этих проблем и, что приятно, стоит копейки. Канал выбирают по аудитории: почта, СМС или пуш; главное — чтобы уведомления уходили автоматически и заранее, а не как оправдание после списания.

Управление подпиской в личном кабинете

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

Что полезно дать покупателю в кабинете:

• Видимость подписки. Что оформлено, за сколько, когда следующее списание, с какой карты (безопасное представление — тип и последние цифры).
• Управление картой. Заменить карту (перепривязать) без потери подписки — важно при перевыпуске.
• Пауза. Приостановить списания на время, не теряя подписку и карту.
• Отмена. Отменить подписку понятно и честно, без ловушек и лабиринтов из кнопок.
• Изменение параметров. Для регулярной доставки — частота и состав; для тарифов — переход между планами.
• История списаний и чеки. Список прошедших платежей с доступом к чекам по 54-ФЗ.

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

Отказы платежа, ретраи и грейс-период

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

Ключевые понятия:

• Ретрай (повторная попытка). После неудачного списания система повторяет попытку через заданный интервал — например, через день, потом ещё через пару дней. Часто денег к моменту повтора уже хватает (зарплата пришла, счёт пополнили).
• Грейс-период. Отсрочка, в течение которой доступ или отгрузка ещё сохраняются, несмотря на неоплату. Он даёт время ретраям сработать и не наказывает покупателя мгновенным отключением за случайный отказ.
• Исчерпание попыток. Если за серию ретраев деньги так и не списались, подписку переводят в приостановленную или отменённую и закрывают доступ.

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

Отмена и пауза подписки

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

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

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

1. Покупатель инициирует отмену в личном кабинете.
2. Статус подписки меняется на «отменена», фиксируется дата и причина.
3. Подписка снимается с расписания: планировщик больше не должен её выбирать для списания.
4. Доступ или отгрузка закрываются по правилам вашей модели (сразу или до конца оплаченного периода).
5. Покупатель получает подтверждение отмены, чтобы не сомневался, что списаний больше не будет.

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

Возвраты по подпискам

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

Что учитывать по возвратам в рекуррентной модели:

• Возврат конкретного списания. Обычно возвращают не «всю подписку», а один спорный платёж за период. Провайдеры это поддерживают, но сценарий нужно проверить.
• Полный и частичный возврат. Иногда возвращают всю сумму периода, иногда часть (вернули один товар из коробки). Оба варианта проверяют отдельно.
• Чек возврата по 54-ФЗ. На возврат тоже формируется кассовый чек (чек возврата прихода). При облачной кассе провайдера он обычно формируется автоматически — это нужно проверить.
• Возврат ошибочного списания. Если списали после отмены или дважды за период — возврат оформляют быстро и с извинениями, а не «по регламенту через две недели».
• Сроки зачисления. Возврат на карту приходит не мгновенно; честно предупреждайте, чтобы не было звонков «где деньги».

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

Чеки по 54-ФЗ для рекуррента

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

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

Безопасность хранения токенов

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

Базовые принципы безопасности рекуррента:

• Карту и CVV не хранит магазин. Реальные данные карты остаются у платёжной системы; CVV не сохраняется вообще нигде — этого требуют правила платёжных систем.
• Токен — это тоже секрет. Хотя по украденному токену нельзя расплатиться в другом месте, хранить его нужно защищённо, ограничивать доступ и не светить в логах и интерфейсах.
• Только HTTPS. Весь обмен с платёжной системой и уведомления идут по шифрованному каналу.
• Проверка подписи уведомлений. Уведомления об оплате/списании проверяются по секретному ключу, чтобы нельзя было подделать «платёж прошёл».
• Ограничение доступа. К данным подписок, токенам и настройкам платёжных систем имеет доступ ограниченный круг людей.
• Безопасное представление карты. Покупателю показывают только тип и последние цифры карты, а не полный номер.

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

Churn и удержание подписчиков

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

Отток бывает двух видов:

• Добровольный. Покупатель осознанно отменяет подписку: стало не нужно, дорого, не оправдала ожиданий.
• Невольный (технический). Подписка теряется не по желанию человека, а из-за неудавшегося списания: не хватило денег в моменте, карта перевыпущена, истёк срок. Человек хотел остаться, но система его «отпустила».

Невольный отток особенно обиден, потому что борется с ним именно техника, и здесь всё в руках магазина:

• Ретраи и грейс-период дают неудачному списанию второй шанс, вместо того чтобы сразу отключать.
• Уведомления об отказе с просьбой обновить карту возвращают людей, которые просто не заметили проблему.
• Простая замена карты в кабинете спасает подписки при перевыпуске.
• Напоминания перед списанием уменьшают внезапные отмены и споры.

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

Частые ошибки

Ошибки в подписках повторяются от проекта к проекту. Зная их заранее, вы сэкономите деньги, нервы покупателей и репутацию.

• Списали после отмены. Самая репутационно опасная ошибка: покупатель отписался, а автосписание всё равно прошло, потому что отмена не сняла подписку с расписания. Планировщик обязан проверять актуальный статус перед каждым списанием.
• Нет уведомления перед списанием. Внезапное списание, особенно крупное годовое, — это негатив и чарджбэки. Предупреждайте заранее и автоматически.
• Двойное списание за период. Планировщик запустился дважды и списал дважды. Лечится идемпотентностью: одно списание жёстко привязано к одному периоду.
• Нет обработки отказов. Первый же отказ по нехватке средств сразу теряет подписчика, хотя ретрай через день прошёл бы. Настраивайте ретраи и грейс-период.
• Нет чека на списание. Автосписание прошло, а чек по 54-ФЗ не сформировался — нарушение. Каждое списание должно давать чек.
• Спрятанная отмена. Кнопку отмены прячут ради удержания — получают негатив и споры в банке. Отмена должна быть честной и простой.
• Хранение лишних данных. Попытка сохранить у себя номер карты или (тем более) CVV — грубая ошибка безопасности. Храните только токен на стороне платёжной системы.
• Агент «на хите». Списания завязаны на посещаемость сайта и задерживаются в тихие часы. На подписках планировщик запускают через cron.
• Рекуррент не проверен у провайдера. Спроектировали подписку, а платёжная система на вашем договоре рекуррент не поддерживает или требует иной оферты. Уточняйте до старта.
• Не проверили возвраты. Приём настроили, возврат — нет, и первый ошибочный платёж превращается в ручную возню. Включайте возврат в сценарий запуска.

Чек-лист запуска подписок

Короткий список, по которому удобно свериться перед запуском подписочной модели для всех покупателей:

1. Рекуррент подтверждён у платёжной системы: поддержка, условия оферты, работа с токеном.
2. Первый платёж с привязкой карты проходит, токен сохраняется, номер карты и CVV у магазина не хранятся.
3. Планировщик списаний работает через cron, идемпотентен и логирует каждую попытку.
4. Статусы подписки заданы явно: активна, пауза, грейс, приостановка, отмена.
5. Отмена гарантированно снимает подписку с расписания — списаний после отмены нет.
6. Пауза останавливает списания с сохранением карты и корректно возобновляется.
7. Ретраи и грейс-период настроены, отказ по нехватке средств не теряет клиента сразу.
8. Напоминания уходят автоматически: перед списанием, перед концом триала, при отказе.
9. Чек по 54-ФЗ формируется на каждое списание и на каждый возврат.
10. Личный кабинет позволяет видеть подписку, менять карту, ставить паузу и отменять.
11. Возвраты проверены: полный, частичный, ошибочного списания, с чеком возврата.
12. Тест и контрольные боевые списания пройдены прежде, чем открывать подписки всем.

Вывод

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

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