Реализация Grace Period при неудачном списании подписки

Пользователь не заметил сбой списания — через день он заблокирован, retention падает на 30% при первом же отказе. Grace period даёт 3–16 дней на исправление без потери доступа. Мы реализуем механизм льготного периода под ключ: от включения в консолях до серверной валидации, чтобы ваше приложение соответствовало гайдлайнам App Store и Google Play.

Как grace period влияет на выручку?

Без grace period каждый сбой списания оборачивается потерей подписчика. Даже если он вернётся, негативный опыт снижает LTV. По данным отчёта RevenueCat, правильный grace period увеличивает retention на 15–20%, что при среднем чеке $10/мес даёт $1.5–2 дополнительной выручки с пользователя в месяц. Это прямой эффект на bottom line без изменения цены.

Что такое grace period и как его включить?

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

iOS: настройка в App Store Connect

Перейдите в App Store Connect → Subscriptions → выберите группу → Grace Period. Доступны варианты: 3, 6 или 16 дней. После активации Apple автоматически отправляет статус inGracePeriod в StoreKit. Обрабатываем его на клиенте:

import StoreKit func checkSubscriptionStatus(productId: String) async -> SubscriptionAccessLevel { guard let product = try? await Product.products(for: [productId]).first, let statuses = try? await product.subscription?.status else { return .notSubscribed } for status in statuses { switch status.state { case .subscribed: return .active case .inGracePeriod: // Списание не прошло, но grace period активен // Показываем мягкое предупреждение, не блокируем контент return .gracePeriod case .inBillingRetryPeriod: // Grace period истёк, Apple продолжает попытки списания (до 60 дней) // Контент НЕ доступен return .billingRetry case .expired, .revoked: return .notSubscribed default: continue } } return .notSubscribed } enum SubscriptionAccessLevel { case active, gracePeriod, billingRetry, notSubscribed } 

App Store Server Notifications V2 дублируют событие DID_FAIL_TO_RENEW с причиной IN_GRACE_PERIOD. Сервер должен обрабатывать оба канала для надёжности.

Android: настройка в Google Play Console

В Google Play Console выберите продукт → Подписка → Льготный период. Длительность зависит от цены и региона: обычно 1–7 дней. Google отправляет RTDN-уведомление SUBSCRIPTION_IN_GRACE_PERIOD:

fun handleSubscriptionNotification(notification: SubscriptionNotification) { when (notification.notificationType) { SubscriptionNotification.SUBSCRIPTION_IN_GRACE_PERIOD -> { showGracePeriodWarning() } SubscriptionNotification.SUBSCRIPTION_EXPIRED -> { revokeAccess() } } } 

Сервер получает уведомление через Pub/Sub и обновляет статус в базе. Клиент может проверять через Purchase.purchaseState и isAutoRenewing, но полагаться только на клиент не стоит.

Что показывать пользователю в grace period

Ключевой принцип: контент не блокировать, но мягко предупредить. Агрессивный paywall в grace period — плохой UX и нарушение Section 4.2 гайдлайнов App Store.

// SwiftUI-баннер if subscriptionStatus == .gracePeriod { GracePeriodWarningBanner( message: "Не удалось списать оплату. Обновите данные карты, чтобы сохранить доступ.", actionTitle: "Управление подпиской", action: { openManageSubscriptions() } ) } func openManageSubscriptions() { Task { try? await AppStore.showManageSubscriptions(in: windowScene) } } 

На Android — аналогичный баннер с кнопкой перехода в Google Play для смены способа оплаты.

Сравнение grace period на iOS и Android

Серверная валидация: почему это важно?

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

Схема работы с App Store Server Notifications V2

1. Apple отправляет POST-запрос на ваш endpoint с типом DID_FAIL_TO_RENEW и причиной IN_GRACE_PERIOD.
2. Сервер валидирует подпись и обновляет поле subscription_status в базе на grace_period.
3. Мобильный клиент при запуске запрашивает /me/subscription и получает актуальный статус.
4. Если grace period истёк — Apple присылает GRACE_PERIOD_EXPIRED, сервер меняет статус на expired и блокирует доступ при следующем запросе.

То же самое для Android c RTDN: SUBSCRIPTION_IN_GRACE_PERIOD и SUBSCRIPTION_EXPIRED.

Типичные ошибки реализации

• Блокировка контента сразу после сбоя списания (игнорирование grace period).
• Непроверка статуса inBillingRetry — контент либо открыт, либо закрыт неверно.
• Отсутствие серверной валидации — пользователь может получить доступ без подписки.
• Слишком агрессивный paywall в grace period (нарушение гайдлайнов).

Процесс работы над проектом

1. Аудит текущей подписочной логики и консолей разработчика.
2. Включение grace period в App Store Connect и Google Play Console.
3. Реализация клиентской обработки статусов (Swift/Kotlin) и UI-баннеров.
4. Интеграция серверных уведомлений (App Store Server Notifications V2 / RTDN).
5. Тестирование сценариев: сбой списания, вход в grace period, выход из grace period.
6. Нагрузочное тестирование и мониторинг.

Сроки внедрения

Клиентская часть с UI-логикой занимает 2–3 дня. Полный цикл с серверной обработкой уведомлений — 4–5 дней. Стоимость рассчитывается индивидуально. Свяжитесь с нами для оценки вашего проекта. Получите консультацию инженера с 10+ лет опыта в мобильных подписках.