Жизненный цикл подписки
У подписки есть состояние: ожидает оплаты, активна, приостановлена, просрочена, отменена или завершена. Конкретные названия могут отличаться, но смысл в том, чтобы система однозначно понимала, должен ли пользователь получать услугу прямо сейчас. После каждого события статус меняется по правилам. Чем чётче эта схема, тем меньше ошибок, когда доступ остаётся активным после отмены или, наоборот, пропадает после успешно проведённого платежа.
Повторяющиеся платежи
Автосписание обычно выполняет платёжный провайдер, а магазин получает подтверждение через серверное уведомление. Нельзя полагаться только на возвращение пользователя на страницу после оплаты: вкладка может быть закрыта, сеть оборваться, а деньги уже списаться. Поэтому важны вебхуки и повторная проверка статуса операции. Каждое уведомление нужно обрабатывать идемпотентно, чтобы повторный запрос не создавал второй заказ.
Продление и ошибки оплаты
Неудачное списание не всегда означает немедленную отмену. Система может предусматривать льготный период и несколько повторных попыток. Пользователю полезно показывать понятный статус и способ обновить платёжные данные. При этом бизнес-логика должна точно определять, сколько времени сохраняется доступ и что происходит после окончательной ошибки. Эти правила лучше задать заранее, а не решать вручную для каждого случая.
Тестирование сценариев
Подписочную систему нужно тестировать не только на успешной покупке. Важны отмена, возврат, неуспешное продление, повторный вебхук, изменение тарифа, истечение карты и ручная активация. Хороший тест проверяет, что заказ, подписка и доступ к услуге остаются согласованными. Особое внимание требуется часовым поясам и датам, потому что даже небольшая ошибка в расчёте периода может массово затронуть клиентов.
Попробуйте на практике
Спроектировать схему состояний подписки для условного магазина.
- Запишите все возможные статусы подписки.
- Для каждого статуса укажите события, которые переводят его в другой.
- Отдельно опишите успешное и неуспешное продление.
- Добавьте правило обработки повторного вебхука.
- Проверьте, при каких статусах доступ должен быть активен.
Как проверить результат. Схема готова, если любое событие приводит к однозначному состоянию и повторное уведомление не создаёт дубли.
Частые вопросы
Почему нельзя просто создавать новый заказ раз в месяц?
Можно, но нужен механизм, который связывает эти заказы с одной подпиской и управляет статусом между платежами.
Что такое идемпотентность?
Это свойство обработки, при котором повтор одного и того же события не создаёт дополнительный эффект, например второй заказ.
Нужны ли вебхуки?
Для надёжной синхронизации с платёжным провайдером они обычно важнее пользовательского редиректа после оплаты.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.