Как устроена подписка на сайте: тарифы, рекуррентные платежи и защита от неплатежей
Подписочная модель работает просто для пользователя: он платит раз в месяц и пользуется сервисом. Но за этой простотой стоит связка из платёжного шлюза, базы данных, логики тарифов и защиты от неплатежей. Разбираем, как это устроено технически и что нужно учесть, чтобы не терять деньги.
Рекуррентный платёж: что происходит после первой оплаты
Рекуррент - это автоматическое списание денег по сохранённым реквизитам карты. Пользователь оплачивает подписку один раз, платёжная система запоминает токен карты, и дальше сервис сам инициирует списание каждый месяц.
Технически это работает так: после первого платежа шлюз (ЮКасса, Stripe, Тинькофф) возвращает вам токен - зашифрованный идентификатор карты. Вы сохраняете его в базе вместе с ID пользователя и датой следующего списания. Когда приходит срок, ваш сервер отправляет запрос в API шлюза: списать сумму с токена такого-то. Шлюз пытается провести платёж и возвращает результат.
Важный момент: рекуррент работает только если пользователь согласился при первой оплате. Галочка «сохранить карту для автосписания» - не формальность, а требование законодательства. Без явного согласия рекуррент запустить нельзя.
На практике первый платёж часто проваливается не из-за технических проблем, а из-за того, что банк блокирует непонятную операцию. Если пользователь никогда не платил вашему сервису, банк может попросить подтверждение по СМС или вообще отклонить платёж. Поэтому первая оплата должна быть максимально прозрачной: название компании в назначении платежа, понятная сумма, отправка чека на почту сразу после списания.
Тарифы и переключение между планами
Тарифы хранятся в базе как набор параметров: название, цена, период (месяц, год), набор функций. Когда пользователь выбирает тариф, вы создаёте запись в таблице подписок: ID пользователя, ID тарифа, дата начала, дата следующего платежа, статус (активна, отменена, просрочена).
Переключение между тарифами - самая частая головная боль. Пользователь может апгрейднуться в середине месяца, и тут два варианта: пропорциональный перерасчёт (пользователь доплачивает разницу за оставшиеся дни) или переход с новой даты (текущий тариф действует до конца периода, новый стартует со следующего месяца). Первый вариант честнее, но сложнее в реализации.
Если делаете пропорциональный перерасчёт, логика такая: считаете, сколько дней осталось до конца текущего периода, вычисляете стоимость этих дней на текущем тарифе, вычитаете из цены нового тарифа за месяц и списываете разницу. Дата следующего платежа остаётся прежней, меняется только сумма.
Даунгрейд (переход на более дешёвый тариф) лучше делать с начала следующего периода. Возвращать деньги пропорционально - это и технически сложнее, и с точки зрения бухгалтерии геморройнее. Пользователь продолжает пользоваться текущим тарифом до конца оплаченного месяца, а потом автоматически переходит на новый.
Пробный период и отложенное списание
Пробный период (trial) выглядит просто: пользователь регистрируется, пользуется бесплатно 7-14 дней, потом автоматически списывается оплата. На практике здесь два подхода.
Первый: привязка карты сразу, но списание через N дней. Вы токенизируете карту при регистрации (списываете и сразу возвращаете 1 рубль для проверки), сохраняете токен и ставите дату первого реального списания через две недели. Плюс: меньше оттока после trial, потому что карта уже привязана. Минус: часть пользователей откажется вводить карту на старте.
Второй: пробный период без карты, запрос оплаты в последний день. Пользователь регистрируется на почту, пользуется две недели, в последний день получает письмо со ссылкой на оплату. Плюс: выше конверсия в регистрацию. Минус: большая часть пользователей не вернётся оплачивать.
Мы обычно рекомендуем первый вариант, если продукт дорогой (от 2-3 тысяч в месяц) и ориентирован на бизнес. Второй вариант работает для дешёвых сервисов (300-500 рублей), где важен объём аудитории.
Что делать, если платёж не прошёл
Рекуррентный платёж может провалиться по куче причин: недостаточно денег на карте, карта заблокирована, истёк срок, банк отклонил операцию. По статистике платёжных систем, 10-15% рекуррентных списаний проваливаются с первой попытки.
Стандартная схема: три попытки списания с интервалом в сутки. Первая неудача - ждёте день, пытаетесь снова. Вторая - ещё день. Третья - блокируете подписку и отправляете письмо с просьбой обновить карту.
Важно: не блокируйте доступ сразу после первой неудачи. Проблема может быть временной (задержка зачисления зарплаты, технический сбой в банке), и если вы заблокируете аккаунт мгновенно, пользователь уйдёт раздражённым. Дайте несколько дней на решение вопроса.
Логика в коде: при каждой неудаче увеличиваете счётчик failed_attempts в таблице подписок. Если счётчик = 3, меняете статус на suspended и отправляете письмо. Пользователь может зайти в настройки, обновить карту (это новая токенизация), и вы сразу пытаетесь списать долг. Если прошло - обнуляете счётчик, возвращаете статус active.
Часть платёжных шлюзов умеет делать ретраи автоматически - вы задаёте правило в настройках, и система сама пытается списать три раза. Но контроль статуса подписки всё равно остаётся на вашей стороне.
Как считать выручку с подписок правильно
Подписочная выручка считается не в момент списания, а равномерно в течение периода. Это называется revenue recognition. Если пользователь заплатил 12 тысяч за год 1 января, вы не можете записать всю сумму в выручку января - бухгалтерски это 1000 рублей в месяц на протяжении года.
Технически это значит, что в базе должна быть не только дата платежа, но и период действия подписки. Вы списали деньги 15 марта, период подписки - с 15 марта по 15 апреля. В отчётах вы размазываете сумму пропорционально дням каждого месяца: часть уходит в март, часть в апрель.
Для этого удобно вести таблицу revenue_log: ID платежа, дата начала периода, дата конца, сумма. Когда строите отчёт за месяц, выбираете все записи, у которых период пересекается с этим месяцем, и суммируете пропорциональную часть.
Если пользователь отменил подписку в середине месяца и вы вернули деньги - это вычитается из выручки того периода, на который приходился возврат. Не из того месяца, когда списали, а из того, за который пользователь не получил услугу.
Отмена подписки: как не нарваться на чарджбэк
Отмена должна быть простой и доступной. Если пользователь не может найти кнопку «отменить подписку» в личном кабинете, он идёт в банк и делает chargeback - оспаривание платежа. Для вас это штраф от платёжной системы плюс потеря денег.
Правильная схема: кнопка отмены в личном кабинете, одно подтверждение («точно отменить?»), и подписка переводится в статус cancelled. Доступ остаётся до конца оплаченного периода - пользователь заплатил за месяц, пусть пользуется месяц. Рекуррентное списание просто не запускается в следующий раз.
Не делайте отмену через службу поддержки. Да, это даёт шанс удержать клиента разговором, но раздражает сильнее, чем помогает. Лучше показать форму обратной связи после отмены: «почему уходите?» с вариантами ответа. Часть пользователей напишет, и вы узнаете, что чинить.
Чарджбэки проверяйте вручную. Если пользователь оспорил платёж, платёжная система пришлёт уведомление. У вас есть 7-14 дней, чтобы предоставить доказательства: скриншот личного кабинета с активной подпиской, лог использования сервиса, согласие на рекуррент. Если не ответите - деньги вернут автоматически, плюс штраф.
Технический стек для подписок
Если делаете подписки с нуля, вам нужен платёжный шлюз с поддержкой рекуррента (в России это ЮКасса, Тинькофф, CloudPayments), база данных для хранения подписок и токенов, cron-задача для проверки дат списания.
Cron запускается раз в час, выбирает из базы все подписки, у которых next_payment_date <= сейчас и статус = active, отправляет запросы на списание. Если списание прошло - обновляете next_payment_date (добавляете месяц), если нет - увеличиваете failed_attempts.
Если объём подписок большой (тысячи активных), лучше использовать очередь задач (RabbitMQ, Redis Queue). Cron кладёт в очередь ID подписок, воркеры разбирают очередь и обрабатывают платежи параллельно. Это быстрее и надёжнее.
Готовые решения типа Stripe Billing или Paddle берут на себя всю механику: вы просто создаёте тариф в их интерфейсе, подключаете вебхуки, и дальше они сами списывают, делают ретраи, отправляют уведомления. Удобно, если вы работаете на западный рынок. Для России придётся писать свою обёртку или использовать российские шлюзы напрямую.
Если задача уже на столе - вот как мы делаем это под ключ: Разработка веб-приложений, веб-сервисов и SaaS.
Частые вопросы
Можно ли принимать подписки без рекуррента, просто напоминать пользователю оплатить вручную?+
Можно, но конверсия в повторную оплату будет в разы ниже. Пользователь забудет, проигнорирует письмо или просто не захочет заходить в банк каждый месяц. Рекуррент даёт в 3-4 раза больше удержания, особенно на дешёвых тарифах.
Сколько стоит подключить рекуррентные платежи?+
Зависит от шлюза. ЮКасса и Тинькофф берут комиссию 2,5-3,5% с каждого платежа, фиксированной платы за подключение обычно нет. Если оборот большой, можно договориться о снижении процента. Техническая интеграция - это несколько дней работы разработчика.
Что будет, если у пользователя кончились деньги на карте и все три попытки списания провалились?+
Подписка блокируется, доступ к функциям закрывается, пользователь получает письмо с просьбой обновить способ оплаты. Часть сервисов даёт grace period (ещё 3-5 дней доступа после блокировки), чтобы человек успел решить вопрос. Если не оплатит - подписка отменяется, данные остаются, но функционал недоступен.
Можно ли сделать подписку на год со скидкой?+
Да, это стандартная практика. Создаёте отдельный тариф с периодом 12 месяцев и ценой ниже, чем сумма 12 месячных платежей. Технически ничего не меняется, просто next_payment_date сдвигается не на месяц, а на год. Годовые подписки снижают отток и дают предсказуемую выручку, поэтому выгодны обеим сторонам.