Grace-период: как не терять клиентов из-за сбоя платежа

Когда платёж не прошёл: первые секунды решают многое

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

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

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

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

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

• active — подписка оплачена, доступ открыт.
• past_due — наступила дата списания, но деньги не поступили. Биллинг фиксирует событие, пишет в лог и запускает grace-период.
• grace — система ждёт оплаты. Для карт — повторные попытки списания по расписанию. Для счётов — ожидание перевода или ручного подтверждения. Успешная транзакция возвращает подписку в active. Истечение grace без оплаты переводит в suspended или сразу в cancelled — зависит от политики.
• suspended — grace-период истёк. Доступ закрыт, но подписку можно восстановить после получения оплаты.
• cancelled — подписка отменена. Доступ закрыт, восстановление невозможно.

Что происходит внутри grace-периода

Поведение биллинга зависит от способа оплаты.

Рекуррентные платежи по картам. Биллинг делает повторные попытки списания ежедневно до конца grace-периода или до успешной оплаты другим способом. Для B2B-клиентов на корпоративных картах логика та же.

Оплата по счёту. Банковский перевод идёт 1–3 рабочих дня, а с учётом внутреннего согласования в компании — и дольше. Счёт имеет смысл выставлять заранее, за 5–10 дней до даты продления. Подтверждение прихода денег может быть ручным (менеджер отмечает в системе) или автоматическим — через банковский API или загрузку выписки.

Длительность grace-периода

• B2C с оплатой по картам — обычно 5–7 дней.
• B2B с оплатой по счёту — около 10 дней, для госкомпаний иногда до 30 дней.
• Чем выше стоимость подписки и чем критичнее сервис для клиента — тем длиннее имеет смысл делать grace-период.

Дата следующего списания

Если платёж прошёл внутри grace-периода, следующую дату нужно считать от исходной даты продления, а не от даты фактической оплаты. Дата продления — 1 мая, платёж прошёл 6 мая: следующий период начинается с 1 июня, а не с 6-го.

Стратегия доступа: три варианта

Единственно правильного ответа нет — всё зависит от продукта и внутренней политики.

Полный доступ. Пользователь ничего не замечает, пока проблема не решится или grace-период не закончится. Минимальный непреднамеренный отток. Обратная сторона: те, кто намеренно не платит, пользуются сервисом бесплатно весь период.

Немедленное отключение. Доступ закрывается сразу при неудачном платеже, grace-период служит только окном для восстановления. Высокий риск потерять добросовестных пользователей из-за технических сбоев. Для большинства продуктов — плохой выбор.

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

В B2B принято сохранять полный доступ значительно дольше, чем в B2C. Отключить корпоративного клиента в день просрочки — почти всегда ошибка, которая заканчивается звонком аккаунт-менеджеру и претензией.

Финансовый учёт: когда признавать выручку

Grace-период означает, что подписка находится в состоянии ожидания оплаты, расчётный период при этом не сдвигается. Если платёж прошёл на 5-й день grace за период, начавшийся 1-го, дата платежа и дата начала периода не совпадают. Когда признавать выручку — по дате платежа или по дате начала периода? Это нужно согласовать с бухгалтерией заранее.

Когда подписка уходит в suspended, попытки списания должны прекратиться: для карт заканчивается retry-цикл, для счётов перестают выставляться новые. Накапливать задолженность за несколько неоплаченных периодов не имеет смысла — это только усложнит клиенту путь к возврату.

Уведомления: начинайте раньше, чем думаете

Хорошая система уведомлений начинается не в момент, когда платёж уже не прошёл, а заранее.

• До даты списания. Для карт — одно напоминание за 2–3 дня. Для счётов — серия: за 5 дней, за 3 дня, за 1 день до срока. Бухгалтер не следит за датами оплаты всех сервисов — ему нужно письмо с суммой, датой и реквизитами.
• В день начала grace-периода. Сразу после того, как биллинг перешёл в grace — транзакционное уведомление без маркетинга. Не «мы скучаем по вам», а конкретно: что случилось и что нужно сделать.
• Внутри grace-периода. Напоминания через несколько дней, если проблема не решена — но не каждый день. Ближе к концу grace — предупреждение с конкретной датой отключения. «Доступ будет закрыт 15 июня» работает лучше, чем «скоро потеряете доступ».

Перед каждой отправкой проверяйте актуальный статус подписки. Если платёж прошёл за несколько часов до рассылки, а письмо об отключении всё равно ушло — это подрывает доверие. В B2B такая ситуация особенно болезненна.

Технические нюансы

Идемпотентность списаний. Если запрос к эквайеру завис и неизвестно, прошёл ли платёж, повторный запрос не должен приводить к двойному списанию. Используйте idempotency key на уровне каждой транзакции.

Вебхуки от эквайера. Статус платежа лучше получать через вебхуки, но они могут приходить с задержкой и дублироваться. Обрабатывайте их идемпотентно, проверяйте, не обработано ли уже это событие по его идентификатору. Логируйте все входящие события с временной меткой.

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

Частые вопросы при внедрении

Кто управляет ограничением доступа — биллинг или продукт?
Биллинг отвечает за статус подписки и уведомляет продукт о его смене. Что делать с этим статусом — скрывать функции, показывать баннер, переводить в read-only — решает продукт. Такое разделение позволяет менять политику доступа, не трогая биллинговую логику.

Как считать MRR, если часть подписок в grace-периоде?
Подписки в grace технически не оплачены. Включать их в MRR как активные — значит завышать метрику. Стандартная практика: держать их отдельно и переводить в реальный MRR только после подтверждения оплаты.

Что происходит с данными клиента после окончания grace-периода?
Зависит от политики хранения. Стандартная практика: после перехода в suspended данные сохраняются ещё 30–90 дней — в течение этого срока подписку можно восстановить.

Итог

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

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

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