Когда платёж не проходит, есть два очевидных варианта: сразу отключить клиента или ждать, пока кто-то разберётся вручную. Оба плохие. Первый отключает тех, кто собирался заплатить: карта перевыпущена, банк временно был недоступен, на счёте не хватило суммы в день списания — всё это технические сбои, а не отказ от оплаты. Второй не масштабируется: при росте базы ручной разбор каждой просрочки становится отдельной операционной нагрузкой.
Grace-период — это пауза между неудачным платежом и отключением, во время которой система ждёт оплаты и параллельно отправляет уведомления клиенту. Доступ к сервису может оставаться либо полностью открытым либо частично.
Grace-период затрагивает сразу несколько уровней: статус подписки, поведение доступа, цепочку уведомлений, финансовый учёт. Каждый из них требует явных решений при настройке.
Зачем нужен Grace-период: три ситуации
Ценность grace-периода неодинакова для разных продуктов и зависит от модели оплаты и типа клиентов.
SaaS с автосписаниями по картам. Часть платежей каждый месяц отказывает по техническим причинам: карта перевыпущена, банк временно заблокировал рекуррентные транзакции, на счёте не хватило суммы в момент списания. Большинство из этих ситуаций разрешаются, если дать несколько дней. Без grace-периода каждый такой случай заканчивается либо ручным восстановлением доступа, либо потерей клиента, который готов был платить.
B2B с оплатой по счетам. Корпоративный платёж проходит через цепочку: бухгалтерия получает счёт, согласует, выставляет платёжное поручение, банк проводит перевод. Деньги могут быть уже в пути, пока биллинговая система технически считает оплату просроченной. Grace-период для таких клиентов — не удобная опция, а необходимость: без него любая задержка в банковской цепочке становится поводом для конфликта. Подробнее об особенностях B2B-оплаты: Как принимать оплату по подписке в B2B SaaS.
Продукты с накопленными данными. Чем дольше клиент использует сервис, тем больше у него внутри: история, настройки, интеграции с другими инструментами. Внезапная потеря доступа из-за технического сбоя воспринимается не как временная проблема с оплатой, а как угроза всему накопленному. Grace-период даёт время разобраться, не создавая ощущения потери.
SaaS с автосписаниями по картам. Часть платежей каждый месяц отказывает по техническим причинам: карта перевыпущена, банк временно заблокировал рекуррентные транзакции, на счёте не хватило суммы в момент списания. Большинство из этих ситуаций разрешаются, если дать несколько дней. Без grace-периода каждый такой случай заканчивается либо ручным восстановлением доступа, либо потерей клиента, который готов был платить.
B2B с оплатой по счетам. Корпоративный платёж проходит через цепочку: бухгалтерия получает счёт, согласует, выставляет платёжное поручение, банк проводит перевод. Деньги могут быть уже в пути, пока биллинговая система технически считает оплату просроченной. Grace-период для таких клиентов — не удобная опция, а необходимость: без него любая задержка в банковской цепочке становится поводом для конфликта. Подробнее об особенностях B2B-оплаты: Как принимать оплату по подписке в B2B SaaS.
Продукты с накопленными данными. Чем дольше клиент использует сервис, тем больше у него внутри: история, настройки, интеграции с другими инструментами. Внезапная потеря доступа из-за технического сбоя воспринимается не как временная проблема с оплатой, а как угроза всему накопленному. Grace-период даёт время разобраться, не создавая ощущения потери.
Состояния подписки
Подписка проходит через фиксированный набор состояний. Grace-период — одно из них.
Активна — подписка оплачена, всё работает штатно.
Просрочена — дата платежа наступила, поступления нет. Для платежей по картам — эквайер вернул отказ. Для оплаты по счёту — истёк срок оплаты. Биллинг фиксирует переход и запускает grace-период.
Grace-период — биллинг ожидает оплаты от клиента. Успешный платёж возвращает подписку в статус «активна». Истечение срока без оплаты переводит в «заблокирована».
Заблокирована — grace период истёк, оплата не поступила. В этот момент необходимо отключить доступ клиента к сервису. Успешный платёж возвращает подписку в статус «активна».
Отключена — подписка отменена, возобновление невозможно.
При каждом изменении статуса биллинг отправляет вебхук в продукт с новым статусом, временной меткой и причиной перехода.
Просрочена — дата платежа наступила, поступления нет. Для платежей по картам — эквайер вернул отказ. Для оплаты по счёту — истёк срок оплаты. Биллинг фиксирует переход и запускает grace-период.
Grace-период — биллинг ожидает оплаты от клиента. Успешный платёж возвращает подписку в статус «активна». Истечение срока без оплаты переводит в «заблокирована».
Заблокирована — grace период истёк, оплата не поступила. В этот момент необходимо отключить доступ клиента к сервису. Успешный платёж возвращает подписку в статус «активна».
Отключена — подписка отменена, возобновление невозможно.
При каждом изменении статуса биллинг отправляет вебхук в продукт с новым статусом, временной меткой и причиной перехода.
Как ведёт себя биллинг внутри grace-периода
Поведение зависит от того, как клиент платит.
Платежи по картам. В течение grace-периода биллинговая система ожидает оплаты от клиента. В случае если банковская карта истекла, клиент должен привязать новую карту в личном кабинете.
Оплата по счёту. Банковский перевод занимает от одного до трёх рабочих дней, а с учётом внутреннего согласования — дольше. Счёт стоит выставлять заблаговременно, за 5–10 дней до даты продления. Подтверждение поступает либо автоматически через банковский API или загрузку выписки, либо вручную — менеджер отмечает оплату после получения подтверждения от банка.
Длительность grace-периода. Для B2C с карточными платежами обычно составляет 5–7 дней. Для B2B клиентов с оплатой по счёту около 10 дней, для госкомпаний до 30. Чем выше стоимость подписки и критичнее сервис для клиента, тем длиннее имеет смысл делать этот период.
Важная деталь с датами. Когда платёж проходит внутри grace-периода, следующую дату продления нужно отсчитывать от исходной даты, а не от фактической оплаты. Продление — 4 июня, оплата пришла 7 июня, то следующий период начинается 4 июля, не 7 июля.
Постоплата в B2B работает иначе: клиент сначала пользуется сервисом, счёт выставляется потом. Grace-период в классическом смысле здесь неприменим, но нужен срок оплаты и механизм приостановки при систематическом его нарушении, без этого вы кредитуете клиента без ограничений.
Платежи по картам. В течение grace-периода биллинговая система ожидает оплаты от клиента. В случае если банковская карта истекла, клиент должен привязать новую карту в личном кабинете.
Оплата по счёту. Банковский перевод занимает от одного до трёх рабочих дней, а с учётом внутреннего согласования — дольше. Счёт стоит выставлять заблаговременно, за 5–10 дней до даты продления. Подтверждение поступает либо автоматически через банковский API или загрузку выписки, либо вручную — менеджер отмечает оплату после получения подтверждения от банка.
Длительность grace-периода. Для B2C с карточными платежами обычно составляет 5–7 дней. Для B2B клиентов с оплатой по счёту около 10 дней, для госкомпаний до 30. Чем выше стоимость подписки и критичнее сервис для клиента, тем длиннее имеет смысл делать этот период.
Важная деталь с датами. Когда платёж проходит внутри grace-периода, следующую дату продления нужно отсчитывать от исходной даты, а не от фактической оплаты. Продление — 4 июня, оплата пришла 7 июня, то следующий период начинается 4 июля, не 7 июля.
Постоплата в B2B работает иначе: клиент сначала пользуется сервисом, счёт выставляется потом. Grace-период в классическом смысле здесь неприменим, но нужен срок оплаты и механизм приостановки при систематическом его нарушении, без этого вы кредитуете клиента без ограничений.
Доступ к сервису: кто за что отвечает
Здесь важно разделить ответственность с самого начала. Биллинг не управляет доступом напрямую, он сообщает сервису, в каком статусе находится подписка. Что именно делать с этим статусом — скрывать функции, показывать баннер, ограничивать API, решает сам сервис. Это разделение позволяет менять политику доступа независимо от биллинговой логики.
Три основных подхода к доступу во время grace-периода:
Полный доступ. Клиент продолжает работать в штатном режиме — ничего не меняется, пока не истечёт grace-период или не придёт оплата. Преимущество: минимальный непреднамеренный отток. Недостаток: те, кто сознательно избегает оплаты, пользуются сервисом бесплатно весь период.
Ограниченный доступ. Сервис скрывает часть функций или выводит постоянное уведомление, но ключевые данные и базовая функциональность остаются доступными. Хорошо работает там, где данные клиента являются его основным активом. Клиент понимает ситуацию, но не теряет доступ к тому, что накопил.
Немедленное отключение. Доступ закрывается при первом же неудачном платеже, grace-период отсутствует. Высокий непреднамеренный отток. Подходит редким сценариям с высоким риском злоупотреблений, для большинства продуктов неподходящий выбор.
Три основных подхода к доступу во время grace-периода:
Полный доступ. Клиент продолжает работать в штатном режиме — ничего не меняется, пока не истечёт grace-период или не придёт оплата. Преимущество: минимальный непреднамеренный отток. Недостаток: те, кто сознательно избегает оплаты, пользуются сервисом бесплатно весь период.
Ограниченный доступ. Сервис скрывает часть функций или выводит постоянное уведомление, но ключевые данные и базовая функциональность остаются доступными. Хорошо работает там, где данные клиента являются его основным активом. Клиент понимает ситуацию, но не теряет доступ к тому, что накопил.
Немедленное отключение. Доступ закрывается при первом же неудачном платеже, grace-период отсутствует. Высокий непреднамеренный отток. Подходит редким сценариям с высоким риском злоупотреблений, для большинства продуктов неподходящий выбор.
Корпоративных клиентов принято оставлять на полном доступе значительно дольше. Технически просроченный платёж и реальная неоплата часто разные вещи: деньги часто уже в пути. Отключение без предварительного контакта с клиентом почти гарантированно заканчивается эскалацией.
Начисления и выручка
Grace-период — это ожидание оплаты за текущий период, а не продолжение нормального цикла. Биллинговый период не сдвигается вперёд, пока не получена оплата за текущий.
Когда подписка переходит в статус «заблокирована», начисления прекращаются. Продолжать начислять заблокированному клиенту бессмысленно — это только создаёт задолженность, которая усложнит ему возврат.
По признанию выручки: если платёж прошёл на пятый день после начала периода, дата признания выручки и дата платежа будут расходиться. Этот вопрос нужно согласовать с бухгалтерией до запуска, иначе в конце квартала появятся расхождения в отчётности.
Когда подписка переходит в статус «заблокирована», начисления прекращаются. Продолжать начислять заблокированному клиенту бессмысленно — это только создаёт задолженность, которая усложнит ему возврат.
По признанию выручки: если платёж прошёл на пятый день после начала периода, дата признания выручки и дата платежа будут расходиться. Этот вопрос нужно согласовать с бухгалтерией до запуска, иначе в конце квартала появятся расхождения в отчётности.
Уведомления
Уведомления в grace-периоде эффективны только тогда, когда часть из них уходит до его начала. Клиент может не следить за датами: напоминание за несколько дней до списания позволяет устранить проблему раньше, чем она возникнет.
До даты оплаты. Для платежей по картам нужно отправлять одно напоминание за 2–3 дня. Для счетов лучше настроить серию: за 5 дней, за 3 дня, за 1 день. Бухгалтер не мониторит личный кабинет вашего сервиса, ему нужно письмо с реквизитами, суммой и конкретной датой.
До даты оплаты. Для платежей по картам нужно отправлять одно напоминание за 2–3 дня. Для счетов лучше настроить серию: за 5 дней, за 3 дня, за 1 день. Бухгалтер не мониторит личный кабинет вашего сервиса, ему нужно письмо с реквизитами, суммой и конкретной датой.
С 1 марта 2026 года в России действуют новые требования к уведомлениям об автосписаниях: обязательное предупреждение и возможность отмены через электронный интерфейс. Подробнее: Автосписания 2026: как соблюдать закон и принимать платежи.
В день начала grace-периода. Первое уведомление должно уходить сразу при переходе в grace. Тон письма должен быть транзакционный: что произошло, что нужно сделать.
Внутри grace-периода. Напоминания с интервалом в несколько дней. Незадолго до конца отправлять предупреждение с конкретной датой отключения. «Доступ будет закрыт 20 июня» конвертирует лучше, чем «скоро потеряете доступ».
Перед каждой отправкой должен проверяться актуальный статус. Если оплата прошла за несколько часов до рассылки, а уведомление об отключении всё равно ушло, клиент получает противоречивые сигналы. В B2B это особенно болезненно: перевод поступил, но ещё не отразился в системе, — и клиент читает письмо с угрозой отключения.
В B2B автоматические письма необходимый минимум. Аккаунт-менеджер должен видеть просрочку и подключаться лично, особенно с крупными клиентами.
Внутри grace-периода. Напоминания с интервалом в несколько дней. Незадолго до конца отправлять предупреждение с конкретной датой отключения. «Доступ будет закрыт 20 июня» конвертирует лучше, чем «скоро потеряете доступ».
Перед каждой отправкой должен проверяться актуальный статус. Если оплата прошла за несколько часов до рассылки, а уведомление об отключении всё равно ушло, клиент получает противоречивые сигналы. В B2B это особенно болезненно: перевод поступил, но ещё не отразился в системе, — и клиент читает письмо с угрозой отключения.
В B2B автоматические письма необходимый минимум. Аккаунт-менеджер должен видеть просрочку и подключаться лично, особенно с крупными клиентами.
Итог
Grace-период — это не дополнительная опция «на всякий случай», а часть нормального клиентского опыта в подписочном сервисе. В момент неудачного платежа продукт должен вести себя предсказуемо: не отключать доступ раньше времени, не создавать ощущение потери данных и не превращать временный сбой оплаты в причину ухода.
Проблемы обычно возникают не из-за самого платежа, а из-за непродуманных правил работы с просрочкой. Сколько ждать оплату, что происходит с доступом, когда отправляются уведомления, в какой момент подписка считается потерянной — всё это напрямую влияет на удержание клиентов, нагрузку на поддержку и уровень доверия к сервису.
Хорошо настроенный grace-период снижает непреднамеренный отток и позволяет клиенту спокойно решить проблему с оплатой, не теряя доступ к продукту в критический момент.
Если хотите посмотреть, как grace-период и управление подписками устроены в LBX — запросите демо.
Проблемы обычно возникают не из-за самого платежа, а из-за непродуманных правил работы с просрочкой. Сколько ждать оплату, что происходит с доступом, когда отправляются уведомления, в какой момент подписка считается потерянной — всё это напрямую влияет на удержание клиентов, нагрузку на поддержку и уровень доверия к сервису.
Хорошо настроенный grace-период снижает непреднамеренный отток и позволяет клиенту спокойно решить проблему с оплатой, не теряя доступ к продукту в критический момент.
Если хотите посмотреть, как grace-период и управление подписками устроены в LBX — запросите демо.
Частые вопросы (FAQ)
Что такое grace-период в подписке? Grace-период — время между неудачным платежом и отключением доступа. В этот промежуток биллинг ожидает оплаты. Типичная длительность — от 5 до 30 дней в зависимости от типа клиента и способа оплаты.
Кто управляет ограничением доступа — биллинг или продукт? Биллинг передаёт продукту статус подписки. Что делать с этим статусом: скрывать функции, показывать баннер, отключать API, решает продукт. Такое разделение позволяет менять политику доступа независимо от биллинговой логики.
Нужно ли отключать доступ во время grace-периода? Зависит от продукта и модели. Большинство SaaS сохраняют полный или ограниченный доступ — это снижает непреднамеренный отток из-за технических сбоев. Немедленное отключение оправдано только при высоком риске злоупотреблений.
Как работает grace-период для B2B-клиентов с оплатой по счёту? Для счетов нет автоматических попыток списания, система ждёт поступления банковского перевода. Период ожидания для таких клиентов длиннее и составляет 10–30 дней, счета выставляются заранее, подтверждение приходит через интеграцию с банком или 1С.
Как считается следующая дата продления, если платёж прошёл во время grace-периода? От исходной даты продления, а не от фактической оплаты. Продление — 1 июня, оплата — 6 июня: следующий период начинается 1 июля, не 6 июля.
Влияет ли grace-период на расчёт MRR? Да. Подписки в grace технически не оплачены — включать их в MRR как активные значит завышать метрику. Подробнее: MRR и churn в SaaS: расчёт ключевых метрик.
Кто управляет ограничением доступа — биллинг или продукт? Биллинг передаёт продукту статус подписки. Что делать с этим статусом: скрывать функции, показывать баннер, отключать API, решает продукт. Такое разделение позволяет менять политику доступа независимо от биллинговой логики.
Нужно ли отключать доступ во время grace-периода? Зависит от продукта и модели. Большинство SaaS сохраняют полный или ограниченный доступ — это снижает непреднамеренный отток из-за технических сбоев. Немедленное отключение оправдано только при высоком риске злоупотреблений.
Как работает grace-период для B2B-клиентов с оплатой по счёту? Для счетов нет автоматических попыток списания, система ждёт поступления банковского перевода. Период ожидания для таких клиентов длиннее и составляет 10–30 дней, счета выставляются заранее, подтверждение приходит через интеграцию с банком или 1С.
Как считается следующая дата продления, если платёж прошёл во время grace-периода? От исходной даты продления, а не от фактической оплаты. Продление — 1 июня, оплата — 6 июня: следующий период начинается 1 июля, не 6 июля.
Влияет ли grace-период на расчёт MRR? Да. Подписки в grace технически не оплачены — включать их в MRR как активные значит завышать метрику. Подробнее: MRR и churn в SaaS: расчёт ключевых метрик.
