Платёж не прошёл. Что делать прямо сейчас: отключить пользователя? подождать? Если подождать, то сколько и на каких условиях?

Причины неудачного платежа бывают временными: недостаточно средств в момент списания, карта перевыпущена, банк временно недоступен, бухгалтер в отпуске и счёт лежит неоплаченным.

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

Без данного периода вы либо теряете платящих пользователей из-за случайных технических сбоев, либо держите всех бесплатно до ручного разбора.

Жизненный цикл подписки

Подписка — это конечный автомат.

active — подписка оплачена, доступ открыт.

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

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

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

cancelled — подписка отменена. Доступ полностью закрыт, подписка не возобновляется по оплате.

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

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

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

Разовая оплата банковскими картами. В течение периода ожидается оплата от клиента.

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

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

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

Постоплата в B2B: сначала клиент пользуется услугами, потом оплачивает. Grace-период как таковой здесь отсутствует. При выставлении счета клиенту устанавливается срок (обычно 10 дней) для оплаты. Таких клиентов редко блокируют, но все равно нужен механизм контроля и приостановки при систематической неоплате, иначе вы просто кредитуете клиента бесконечно.

Доступ во время grace-периода

Здесь нет единственно правильного ответа, всё зависит от продукта и выбранной внутренней политики.

3 основных варианта:

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

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

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

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

Начисления во время grace-периода

Grace-период означает, что подписка находится в состоянии ожидания оплаты, расчетный период при этом не продвигается вперёд, а остается первоначальным.

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

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

Уведомления

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

До даты списания. Для платежей по банковским картам достаточно одного напоминания за 2-3 дня. Для оплаты по счёту серия более длинная: за 5 дней, за 3 дня, за 1 день до срока оплаты. Бухгалтер не следит за датами оплаты различных сервисов, ему нужно письмо со счетом, где указана конкретная сумма, дата и реквизиты.

В день начала grace-периода. Если платёж не прошёл, то биллинг переходит в grace и сразу отправляет уведомление. Здесь важен тон: транзакционный, без маркетинга. Не «мы скучаем по вам», а конкретно что случилось и что нужно сделать.

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

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

В B2B автоматических писем недостаточно. Аккаунт-менеджер должен видеть просрочку в своём интерфейсе и подключаться лично, особенно если клиент крупный или платит по счёту первый раз.

Технические подводные камни

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

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

Итог

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

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

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

Кто управляет ограничением доступа: биллинг или продукт?

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

Как считать MRR, если часть подписок в grace-периоде?

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

Что происходит с данными клиента после окончания grace-периода?

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