Тарифы и подписки

Подписки управляются через каталог тарифов и синхронизируются с Remnawave Panel. Этот раздел объясняет доступные модели и связывает настройку каталога, сценарии покупки и жизненный цикл подписки.

Страницы раздела

Настройка тарифов — каталог, периоды, цены, premium-сквады, трафик и HWID.
Платежи — общая настройка оплаты и инструкции по провайдерам.
Подарочные подписки — покупка для другого пользователя, активация и история подарков.

Модели подписок

Period — подписка на срок с лимитом трафика и настраиваемой стратегией сброса.
Traffic — покупка пакетов трафика без привязки к периоду.
Premium — отдельные premium-сквады, счётчик и стратегия сброса.
HWID-устройства — базовый лимит одновременных устройств и временные дополнительные права.

Лимиты period-подписки

Для обычного и premium-трафика важно различать три независимых слоя:

Слой	Как появляется	Когда сбрасывается
Базовый лимит тарифа	`monthly_gb` или `premium_monthly_gb`	По стратегии обычного или premium-счётчика.
Гибкий итоговый лимит	Пользователь выбирает итоговое значение слайдером при покупке или продлении	Действует вместо базового лимита в оплаченном временном окне и сбрасывается по той же стратегии.
Переносимый баланс	Отдельная докупка, фиксированный GB-бонус промокода или конвертация	Не создаётся заново при сбросе счётчика; расходуется поверх периодического лимита по правилам соответствующего баланса.

Гибкий лимит — это не пакет дополнительных несгораемых гигабайтов. Например, выбор 200 GB при базовых 100 GB означает итоговую квоту 200 GB в каждом применимом периоде сброса, а не ежемесячное добавление 100 GB в переносимый баланс. При NO_RESET счётчик не сбрасывается, хотя цена шага всё равно задаётся за оплачиваемый месяц подписки.

Переносимый баланс обычного трафика списывается при фактическом сбросе счётчика панели. Worker хранит вместе дату периода, опору lifetimeUsedTrafficBytes − usedTrafficBytes, его квоту и уже подтверждённый расход сверх квоты. Поэтому истечение прав на устройства или гибкий лимит не превращает трафик закончившегося периода в расход оплаченного пакета. При уменьшении квоты внутри периода сохраняется уже обслуженная её часть; неиспользованная часть истёкших прав не переносится. Увеличение квоты не возвращает ранее подтверждённый расход пакета.

При последовательных сбросах из баланса вычитается расход закрытого периода сверх его квоты. Поздний ответ панели сохраняет этот расчёт, а повторный ответ не списывает трафик второй раз. Неизрасходованный пакет переносится дальше, после его исчерпания остаётся квота периода. Обычный и premium-трафик используют один расчёт расхода сверх квоты; premium учитывает статистику выбранных нод и сохраняет уже списанную часть в лимите текущего периода, а обычный пакет закрывается по счётчикам панели.

Если пропущено несколько сбросов, worker использует историю панели по UTC-суткам только при полном совпадении её суммы с изменением lifetime-счётчика. Каждый период получает свою квоту: неиспользованный лимит соседнего периода не покрывает его расход. Для прав, изменявшихся внутри исторического периода, применяется консервативная верхняя квота этого периода, поскольку суточная статистика не определяет время каждого байта относительно изменения прав.

Если история отсутствует, обрезана сроком хранения или границы сброса находятся внутри UTC-суток, списывается только расход, который worker успел достоверно подтвердить раньше. Неизвестный расход не восстанавливается предположительно из суммарного счётчика. При отсутствии lifetime-счётчика снимок учёта сохраняется целиком; дата уведомлений не подменяет дату его опоры. Новая привязка пользователя панели и перезапуск его lifetime-счётчика начинают новое наблюдение без списания старого расхода. Безлимитный режим не создаёт нового расхода оплаченного пакета.

После обновления первый достоверный ответ панели начинает наблюдение текущего периода; закрытые ранее периоды не списываются задним числом. Миграции 0098_topup_period_lifetime и 0099_regular_topup_accounting добавляют опору счётчика и снимок его квоты; действующие миграции не изменяются.

Жизненный цикл

Начисление периода по приглашению относится к собственной оплаченной period-подписке; оплата личным балансом учитывается. Пополнение, покупка подарка, трафик и личная операция с нулевой ценой не занимают место первой покупки. При включённом REFERRAL_GIFT_ACTIVATION_ENABLED успешная активация подарка получателем также учитывается по его существующей реферальной связи. С ограничением REFERRAL_ONE_BONUS_PER_REFEREE первым событием становится либо личная покупка, либо учитываемая активация подарка; второе событие не начисляет период обоим участникам. Выключение опции подарков не стирает уже учтённую активацию. Возврат после принятого решения не сбрасывает этот факт и не отзывает начисленный период. Подробности — в правилах подарков.

С успешной оплатой сохраняются отдельные обязательства для каждого участника. Worker доставляет их независимо, повторяя сбой панели с задержкой до часа. Сохранённая абсолютная дата окончания и локальный резерв не позволяют таймауту или следующей покупке удвоить либо потерять начисление. Применённая часть не повторяется. До подтверждения панели платёж остаётся успешным, а уведомление о начислении отправляется после доставки. Миграция не повторяет исторические оплаты, для которых нельзя достоверно восстановить частичную выдачу. Очередь и её поля state, attempts, next_attempt_at, last_error позволяют диагностировать задержки доставки; штатный worker должен работать.

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

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

Перевыпуск доступа

Пользовательская кнопка доступна при SUBSCRIPTION_REISSUE_ENABLED=true; по умолчанию она выключена. Email не обязателен: новая ссылка отправляется по доступному каналу email или Telegram и остаётся в Mini App.

Mini App и админка используют одну сохранённую операцию перевыпуска. Одновременный запрос получает 409 и Retry-After; краткий повтор после завершения возвращает ту же ссылку. Старые публичные разрешения отзываются до обращения к панели. Если панель сменила идентификатор, но ответ потерялся, повтор сверяет текущий идентификатор и завершает сохранённую операцию без повторной смены. Отказ панели возвращает 502; прежние разрешения остаются отозванными, а операция допускает восстановление повтором.

Обновление на дневные периоды

До обновления сохраните БД и каталог тарифов. Обновляйте backend, worker и frontend согласованно, остановив создание новых оплат на время переключения. Миграция добавляет дневные поля, сохраняя старые месячные поля, даты доступа, суммы платежей и бонусы. Старые счета и внешние recurring-подписки сохраняют прежние календарные условия. Новая разовая покупка и локальное автопродление прибавляют точные сутки в UTC.

Порог промокода сравнивается с базовым оплаченным сроком, без бонусов: 360 дней не проходят порог 365. Дополнительные дни от множителя рассчитываются как bonus_days + ROUND_HALF_UP(duration_days * (multiplier - 1)); старый зафиксированный календарный заказ сохраняет прежний расчёт. Однодневная покупка не вызывает немедленное многодневное предупреждение об окончании; короткие часовые уведомления продолжают работать согласно настройкам.

После появления дневных оплат откат возможен только на сборку, поддерживающую дневные поля и новые снимки. Не запускайте старый worker и не восстанавливайте старую БД поверх новых финансовых операций. Подробности каталога и ограничений методов — в тарифах.