Ошибки окончания бесплатного пробного периода: пограничные случаи и чёткие правила

Почему пробные версии заканчивают раньше или в неверное время

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

Это происходит потому, что время — это грязная вещь. Люди регистрируются в разных часовых поясах. Переход на летнее время меняет часы. Серверы и базы данных хранят метки времени в разных форматах. Даже «30 дней» может означать разное, если одна часть кода считает календарные дни, а другая — часы. Добавьте повторы, фоновые задания и кэширование, и вы получите несколько мест, которые чуть-чуть по-разному считают «активен ли пробный период».

Распространённый источник путаницы — смешение двух разных моментов:

• Пробный период закончился (Trial ended): бесплатный период завершён (точка принятия биллингового решения).
• Доступ отозван (Access revoked): пользователь больше не может пользоваться платными функциями (продуктовое решение).

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

Цель проста: определить один источник истины для времени пробного периода (обычно сохранённая метка trial_ends_at) и покрыть его повторяемыми тестами. Тесты должны включать сложные даты, такие как концы месяцев и переходы DST, а не только «сейчас плюс 7 дней».

Данные, которые нужно хранить (и чему не стоит доверять)

Большинство багов с истечением начинаются с отсутствия или нечётких данных. Если вы храните только trial = true и число «дней пробного периода», каждое последующее решение становится догадкой.

Храните небольшой набор меток времени, которые отвечают на один вопрос: что пользователю разрешено делать прямо сейчас?

Минимум, храните:

• trial_started_at: когда пробный период действительно начался (после успешной регистрации, а не после загрузки страницы)
• trial_ends_at: точный момент, когда доступ пробного периода прекращается
• canceled_at: когда пользователь отменил подписку (если вы поддерживаете отмену во время пробного периода)
• paid_at: когда прошёл первый успешный платёж (не момент создания checkout-сессии)
• ended_at: когда вы пометили пробный период как завершённый (полезно для аудитов и воспроизведения событий)

Сохраняйте эти значения как полные метки времени в UTC. UTC убирает сюрпризы с переходом на летнее время и избегает багов «полуночи», когда пользователь путешествует или сервер работает в другом регионе. Для отображения переводите в локальное время только на уровне UI.

Не доверяйте времени устройства для принудительного выполнения правил. Телефоны могут показывать неверное время, пользователи могут его менять, а время в браузере может дрейфовать. Используйте время сервера (или базы данных) как источник «сейчас» и сравнивайте по нему.

Также избегайте смешения полей «только дата» с реальными метками времени. «2026-01-20» звучит просто, но скрывает подразумеваемый часовой пояс и границу, которую вы не определили. Это может быть полночь в локальном времени пользователя, полночь UTC или конец дня — такая неоднозначность часто вызывает баги с окончанием.

Простое правило: если от этого зависит доступ, храните точную метку времени в UTC.

Правила вычисления времени, которые избегают ошибок на один шаг

Большинство багов с окончанием происходят потому, что продуктовая команда имеет в виду одно («две недели»), а код делает другое («до следующей полуночи»). Исправьте это, написав одно чёткое правило, а затем заставьте все экраны и задачи пользоваться именно им.

Сначала решите, что такое пробный период.

Если нужна самая простая и предсказуемая логика, используйте фиксированную длительность: 14 × 24 часа от trial_started_at. Это избегает споров о том, что означает «полночь».

Если вам действительно нужен пробный период, привязанный к дате («действителен до конкретной календарной даты»), это работает, но только если вы заранее определите часовой пояс (локальный часовой пояс клиента или один биллинговый часовой пояс) и никогда не догадываетесь.

Далее определите границу как исключающую, а не включающую. Чёткое правило: пробный период действителен, пока now < trial_ends_at. В тот момент, когда now == trial_ends_at, пробный период окончен. Это убирает пограничные случаи, когда две системы расходятся на секунду.

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

Наконец, задокументируйте, что для вашего бизнеса означает «полночь». Если вы где‑то используете локальную полночь, вы должны определить, какая локаль и как на это влияет переход на летнее время. Многие команды обходят проблему, хранят и сравнивают всё в UTC.

Льготные периоды: выберите одну простую политику и придерживайтесь её

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

Проблемы возникают, когда фактически действует два разных льготных периода одновременно. Выберите один триггер и сделайте его единственным источником правды.

Выберите начало льготного периода

Выберите одно из:

• Начинать льготу в trial_ends_at.
• Начинать льготу после первой неудачной попытки списания.

Затем сформулируйте правило в одно предложение и держитесь его, например: «Grace начинается в trial_ends_at и длится 72 часа.» Сохраните длительность (или вычисленное grace_end), чтобы изменение политики позже не переписало историю.

Решите, что значит доступ в период льготы

Избегайте «как‑бы работает» доступа. Выберите один ясный режим, который продукт и поддержка смогут объяснить. Полный доступ проще всего, но рискованнее. Режим только для чтения часто используют для панелей. Ограниченный режим (например, просмотр разрешён, а экспорт заблокирован) часто является хорошим компромиссом.

Ручные продления — ещё одно место, где политики молча ломаются. Если вы позволяете продления, относитесь к ним как к явным событиям: кто одобрил, на какой срок, почему и какое новое конечное время. Логируйте это рядом с биллинговыми событиями, чтобы аудит и тесты могли воспроизвести поведение.

Состояния «пробный период завершён»: делайте их явными, а не предполагаемыми

Много багов возникает, когда «пробный период закончился» определяется догадкой: если now > trial_ends_at, система считает, что аккаунт уже не в триале. Это работает, пока не появятся льготы, неудачные платежи, апгрейды, возвраты или ручные правки.

Вместо этого храните явное состояние подписки, о котором система может рассуждать. Держите его маленьким и понятным:

• trialing
• active
• past_due
• canceled
• expired

Затем определите разрешённые переходы и триггеры для них. Например:

• trialing -> active при успешном первом платеже
• trialing -> expired когда достигнут trial_ends_at и не произошло конверсии
• active -> past_due при провале обновления оплаты
• past_due -> active когда платёж позже проходит
• active -> canceled когда пользователь отменяет

Реактивация — это место, где неявная логика создаёт остатки. Если вы позволяете expired -> active (апгрейд после триала), обработайте это как чистый старт: выставьте state=active, запишите новый current_period_ends_at и очистите или проигнорируйте поля, относящиеся только к триалу. Иначе вы получите «active» пользователей, у которых всё ещё действуют блокировки уровня пробного периода.

Наконец, сделайте одно место в коде, которое решает доступ на основе state + timestamps. Не разбрасывайте проверки доступа по контроллерам, UI и фоновых задачам. Храните одну функцию политики, которую вызывают все поверхности.

Пограничные случаи, которые ломают логику окончания

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

• Храните все метки пробного периода в UTC и считайте их источником правды. Переводите в часовой пояс пользователя только для отображения.
• Не переводите туда‑сюда при вычислениях. Именно это делает так, что пробный период «сдвигается» на час в зависимости от того, где выполняется код.

Переход на летнее время — классическая ловушка. «14‑дневный триал» не всегда равен «336 часам», если задействована локальная временная логика. Решите, что вы обещаете, и закодируйте это: либо «истекает через N × 24 часа в UTC», либо «истекает в то же локальное время через N календарных дней». Выберите одно и протестируйте на уикендах с DST.

Концы месяцев и високосные дни создают похожие сюрпризы, когда смешивают календарную математику с длительностью. «Добавить 1 месяц» к 31 января может дать 28/29 февраля, а затем 28/29 марта, что кажется неправильным, если ожидалось «конец месяца». Если пробный период измеряется в днях — избегайте месяцев.

Операционные проблемы тоже ломают сроки:

• Сдвиг системных часов: никогда не используйте время устройства для принудительных проверок.
• Дрейф серверов: опирайтесь на один источник времени для всех сервисов.
• Поздние задания: отложенные задачи могут выполняться поздно, поэтому проверки должны быть идемпотентными.
• Повторы: дублирующие события «пробный период закончен» не должны приводить к двойному списанию.

Отмена, апгрейды и смена плана во время триала

Логика окончания обычно ломается, когда «обычные» временные правила сталкиваются с действиями пользователя. Если вы не определите правила для отмены и смены плана, приложение будет догадываться, и разные экраны будут догадываться по‑разному.

Если пользователь отменяет во время триала

Выберите одну политику и сделайте её явной:

• Отменить сейчас, сохранить доступ до trial_ends_at.
• Отменить сейчас, прекратить доступ немедленно.

«Конец дня» звучит просто, но обычно приводит к спорам о часовых поясах. Если вы его используете — вы обязаны определить, какой именно часовой пояс и что значит «конец дня».

Что бы вы ни выбрали, сохраните это в данных. Например: не изменяйте trial_ends_at, установите canceled_at, флаг вроде will_renew=false и пусть проверки доступа опираются на эти поля. Добавьте тест, который отменяет за 1 минуту до конца триала и подтвердите одинаковый результат в API и UI.

Апгрейды, даунгрейды и смены плана

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

Чистый набор правил может выглядеть так:

• Апгрейд в триале: либо списать немедленно и установить trial_ends_at = null, либо запланировать начало платного плана на trial_ends_at.
• Даунгрейд в триале: не сбрасывайте таймер триала; меняйте только то, что произойдёт после его окончания.
• Смена плана: не пересчитывайте trial_ends_at от «сейчас», если только вы сознательно не даёте больше времени.

Если вы списываете в конце триала, предусмотрите возвраты и спорные операции. Самый безопасный подход — отделять «trial ended» от «payment succeeded». Пробный период может закончиться, платёж может провалиться, и правила доступа должны уметь это обработать без перевода пользователя в случайные состояния.

Пошагово: реализуем окончание пробного периода с одной точкой истины

Разные части приложения часто «решают» статус триала независимо: страница проверяет одну метку, вебхук — другую, биллинг использует третье правило. Почините это, написав правила один раз и заставив всё вызывать одно и то же решение.

Начните с описания политики простым языком с конкретными метками времени, часовыми поясами и результатами. Пример: «7‑дневный триал, начавшийся 2026-01-20 10:15:00Z, заканчивается 2026-01-27 10:15:00Z. Доступ разрешён до точного момента окончания, затем запрещён.» Если вы допускаете льготу, укажите её с той же точностью.

Практическая последовательность:

1. Опишите политику с несколькими реальными примерами (включите один случай около полуночи и один около смены DST).
2. Реализуйте одну функцию принятия решения, которая возвращает can_access и строку с причиной.
3. При создании триала вычисляйте и сохраняйте один trial_ends_at в UTC. Не пересчитывайте его в представлениях, вебхуках и фоновых задачах.
4. Выполняйте переходы состояния в одном месте: либо запланированная задача, которая помечает триалы как завершённые, либо проверка при обращении, которая обновляет состояние при загрузке приложения. Выберите один подход и придерживайтесь его.
5. Логируйте каждое решение с входными данными и результатом (id пользователя, now, сохранённые метки времени, принятое решение). Это ускоряет разбирательства и отладку.

Распространённые ошибки, которые создают баги с окончанием

Большинство багов — это не «математика». Они возникают из-за того, что более одного места решает, должен ли пользователь иметь доступ.

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

Разделённая логика так же болезненна: UI говорит «trial active», а API блокирует запросы, или API разрешает доступ, а UI показывает paywall. Это обычно происходит, когда проверки добавлялись в разное время по разным местам.

Другие распространённые ловушки:

• Сравнение дат как строк ("2026-1-2" vs "2026-01-02")
• Смешение миллисекунд и секунд между сервисами
• Округление меток времени до полуночи без согласованного часового пояса
• В одном месте trial_ends_at считается включающим, а в другом — исключающим

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

Вебхуки добавляют собственную неразбериху. Платёжные события могут прийти с опозданием, повторяться или приходить не по порядку. Делайте обработчики идемпотентными, храните время последнего обработанного события и принимайте решения об доступе, опираясь на сохранённое состояние подписки, а не на «какой вебхук пришёл последним».

Быстрый чек‑лист перед релизом

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

• trial_ends_at хранится в UTC и не меняется после создания, если только вы явно не продлили его.
• Все сравнения используют одно и то же правило везде (например: доступ разрешён, пока now < trial_ends_at).
• Поведение льготного периода согласовано в UI, API и биллинге.
• Поздние события не откатывают состояние назад.
• Логи показывают точные метки времени, использованные при каждом решении о доступе (now, сохранённые конечные времена, результат).

Быстрый сценарий для проверки

Создайте тестового пользователя с окончанием пробного периода в 2026-01-20T00:00:00Z. Проверьте доступ за 1 секунду до, ровно в момент и через 1 секунду после. Повторите для каждого пути, который может регулировать доступ: API‑запрос, запланенная задача окончания и обработчик вебхуков.

Пример сценария и следующие шаги

Пройдите один запутанный таймлайн и запишите, что пользователь должен видеть на каждом шаге.

Пользователь регистрируется в пятницу в 23:30 в регионе, где в воскресенье начинается переход на летнее время (часы переводятся вперёд). При регистрации установите trial_started_at в точную метку времени регистрации и trial_ends_at = trial_started_at + duration.

Суббота: пользователь имеет состояние trialing и доступ. UI должен показывать оставшееся время на основе trial_ends_at, а не на основе сокращённых «календарных дней».

Воскресенье: происходит сдвиг времени (DST). Пользователь всё ещё в trialing. На бэкенде ничего не меняется. Меняется только отображение.

Понедельник 23:35: пользователь открывает приложение и пытается оплатить.

Если вы предоставляете 24‑часовую льготу после окончания пробного периода, ожидаемое поведение должно быть одинаковым везде:

• До trial_ends_at: доступ в рамках пробного периода
• С trial_ends_at до trial_ends_at + grace: доступ в режиме льготы (как вы его задокументировали)
• После окончания льготы без оплаты: expired и блокировка (кроме биллинга)
• В любой момент успешной оплаты: active

Тесты для этого сценария должны существовать до релиза: окончание пробного периода через DST, проверка границ (на 1 секунду до/в/после), успешные и неуспешные пути оплаты, и согласованность UI/API по состоянию учётной записи.

Если ваша логика подписки была быстро сгенерирована и теперь работает непоследовательно, краткий аудит часто находит корень проблемы: смешанные часовые пояса, разбросанные проверки доступа или несколько конкурирующих определений «активного пробного периода». FixMyMess (fixmymess.ai) помогает превратить хрупкие прототипы, созданные ИИ, в боеготовые системы путём консолидации времени и логики состояний в одну проверяемую точку принятия решения.