Ошибки контроля биллинга: как исправить проверки планов и проблемы с вебхуками

Как выглядят ошибки контроля биллинга в реальной жизни

Ошибки контроля биллинга появляются, когда страница цен говорит одно, а продукт ведёт себя по‑другому. Пользователь на бесплатном плане кликает кнопку и внезапно может экспортировать, пригласить коллег или тратить платные AI‑кредиты без оплаты.

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

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

Контроль — это ответ на четыре вопроса при каждом запросе на ценное действие:

• Кто пользователь и к какому аккаунту/воркспейсу он принадлежит?
• Какой план и допы активны прямо сейчас?
• Какое конкретно действие он пытается выполнить?
• Должен ли сервер это разрешить (а не только UI)?

Когда эти ответы неясны или разбросаны по разным местам, появляются баги. Классический пример: кто‑то добавил новый endpoint только для Pro, но забыл применить ту же проверку в фоновой задаче, которая его вызывает. UI по‑прежнему прячет фичу, но endpoint доступен прямо или косвенно.

Если вы унаследовали прототип SaaS, сгенерированный ИИ (Lovable, Bolt, v0, Cursor, Replit), такие пробелы встречаются часто. FixMyMess часто находит пропущенные проверки планов в одном‑двух критических путях и по крайней мере одно место, где состояние биллинга предполагается, а не проверяется. Этого достаточно, чтобы платные функции тихо стали бесплатными.

Картируйте места, где должен применяться контроль доступа

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

Начните с платных действий на языке пользователя: «экспорт CSV», «пригласить коллегу», «запустить отчёт», «убрать водяной знак». Затем переведите каждое в реальные пути исполнения: API‑endpoint, любая фоновая задача, которую он ставит в очередь, и любые UI‑пути (включая скрытые кнопки), которые всё ещё могут вызвать API.

Ставьте проверки на сервере в первую очередь. UI может прятать кнопки, но ему нельзя доверять. Если endpoint можно вызвать, он должен валидировать права каждый раз.

Системы, которые стоит включить в карту

Запишите все системы, которые трогают права, даже если код грязный:

• База приложения (пользователь, организация/воркспейс, таблицы подписок или прав)
• Слой аутентификации (сессии, JWT claims, роли)
• Провайдер биллинга (планы, подписки, инвойсы)
• Вебхуки и обработка событий (включая ретраи и задержки)
• Кэши/очереди (всё, что может отдать устаревший доступ)

Когда картина ясна, выберите один источник правды для прав доступа и придерживайтесь его. Для большинства SaaS‑приложений это запись прав (entitlements) в вашей собственной базе, которая отражает «что этот воркспейс может делать прямо сейчас», обновляется вебхуками и проверяется при ключевых действиях.

Типичная ошибка прототипа: проверки планов разбросаны по фронтенду, нескольким API‑маршрутам и одному обработчику вебхуков. В результате доступ неконсистентен и сложно воспроизводимы утечки. Одна модель прав и один общий серверный защитник закрывают большинство пробелов быстро.

Пошагово: исправьте проверки планов, чтобы платные функции оставались заблокированными

Ошибки контроля возникают, когда правила разбросаны. Один endpoint проверяет план, другой доверяет флагу в UI, а третий совсем ничего не проверяет. Ремонт прост: централизуйте решение и переиспользуйте его везде.

1) Найдите все места, которые могут инициировать платное действие

Сделайте инвентаризацию серверных маршрутов и фоновых задач, которые делают что‑то ценное: экспорт данных, приглашение коллег, снятие лимитов, генерация отчётов, использование платных AI‑вызовов и админские действия. Если действие меняет данные или стоит вам денег — ему нужен гейт.

Затем добавьте один защитник в одном месте, который используют все платные маршруты. Не переписывайте проверки внутри каждого хендлера.

2) Перенесите все решения о доступе на сервер

Считайте всё, что приходит от клиента, подсказкой, а не источником правды. UI‑флаги вроде isPro, значения в localStorage и скрытые кнопки легко подделать. Сервер должен решать по сохранённым у вас записям о правах.

Практичный шаблон — вычислять «что разрешено» в одной функции, используя одну запись прав. Free может просматривать дашборды, но не экспортировать. Pro может экспортировать. Главное — чтобы каждый endpoint использовал одно и то же решение.

Небольшой чеклист для защитника:

• Загрузить пользователя и его текущую запись entitlement из базы.
• Вычислять allowedFeatures в одной функции (никаких раскиданных ad‑hoc проверок по файлам).
• По умолчанию блокировать, когда данные отсутствуют или неясны.
• Возвращать понятную ошибку: что было заблокировано и почему.
• Логировать решение с ID пользователя и версией записи прав.

Понятные ошибки помогают поддержке («Экспорт требует Pro. У вас план Free.»). Они также делают логи удобными для поиска, когда кто‑то говорит «я заплатил, но всё ещё заблокирован».

3) Добавьте парочку тестов, которые ловят утечки на раннем этапе

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

Если вы унаследовали AI‑сгенерированный прототип SaaS, команды вроде FixMyMess часто начинают с централизации таких защит, потому что это останавливает утечки без полной переработки.

Вебхуки: обрабатывайте отсутствующие, дублирующиеся и поздние события

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

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

Сделайте обработку вебхуков безопасной и надёжной

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

Сделайте обработчики идемпотентными. Если одно и то же событие обработано дважды, результат должен быть одинаковым.

Короткий чеклист, предотвращающий большинство утечек дохода:

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

Обрабатывайте события вне порядка и пропавшие события

Обычная ситуация — события вне порядка вокруг апгрейдов, возвратов и отмен подписок. Используйте таймстемпы (или sequence‑номера, если провайдер их даёт) и сравнивайте с сохранённым состоянием. Если пришёл более старый «trial started» после «paid canceled», не переписывайте новое состояние старым.

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

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

Гонки состояний при апгрейдах и даунгрейдах

Гонки состояний — простой способ, как в систему просачиваются баги контроля биллинга. Они происходят, когда две части приложения одновременно обновляют или читают план клиента, и одна из них видит устаревшие данные. Результат обычно — бесплатный доступ (или случайные блокировки) в момент смены плана.

Распространённый паттерн: пользователь нажимает Upgrade, UI сразу переключается на «Pro», но серверная проверка всё ещё читает старый план из базы (или кэша). Если API доверяет состоянию UI, пользователь получает платные функции до подтверждения. Если API читает старое состояние, пользователь платит, но всё ещё видит «locked», а после обновления страницы всё внезапно работает.

Один фикс — пропускать все изменения плана через единый backend‑путь. Не позволяйте UI, обработчику вебхуков и nightly‑cron писать в одни и те же поля прав разными способами. Выберите одного владельца прав и заставьте всё остальное идти через него.

Полезно разделять состояния, чтобы приложение могло честно сообщать, что происходит:

• Payment started (создан чек‑аут)
• Payment confirmed (провайдер подтвердил оплату)
• Entitlement granted (ваша система обновила доступ)
• Entitlement revoked (даунгрейд вступил в силу)

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

Конкретный пример: пользователь апгрейдится, и в тот же момент ваш cron «ловит» подписки и ресинхронизирует план вчерашнего дня. Без блокировки или проверки версии cron‑запись может прилететь последней и отменить апгрейд. UI покажет Pro, а API прогейтит как Free, или наоборот.

Если вы унаследовали AI‑сгенерированный прототип, частая находка аудита — множественные записи плана, отсутствие единого источника прав и проверки доступа, зависящие от того, кто выиграл гонку.

Сделайте модель прав чистой и согласованной

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

Исправьте это, создав единую запись entitlements, которую приложение будет считать источником правды. Храните её в одной таблице (или одном документе) и обновляйте вебхуками и подтверждёнными результатами чек­аута. Включите таймстемпы, чтобы можно было понять, что и когда поменялось.

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

• Текущий план (free, pro, team)
• Статус подписки (active, trialing, past_due, canceled)
• period_start и period_end (даты следующего выставления/продления)
• Entitlement version и updated_at (для отладки и реплея)
• Политику grace и grace_until (если вы разрешаете льготный период)

Определяйте правила грейса простым языком и кодируйте их в модель. Например: позволять только чтение в течение 3 дней после неудачной оплаты, но блокировать экспорт и платные API‑вызовы сразу. Смысл в том, чтобы «что разрешено» было правилом, завязанным на статус и время, а не набором разрозненных условий.

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

Наконец, трактуйте админские оверрайды как полноценные данные. Они часто становятся скрытой причиной утечек, потому что никто не видит, почему пользователь разблокирован. Фиксируйте, кто сделал оверрайд, когда и почему. Добавьте время истечения для временных разблокировок. Сделайте состояние оверрайдов видимым в админке. Логируйте решения entitlements (по крайней мере в debug‑режиме), чтобы можно было объяснить allow/deny без догадок.

Если вы наследуете AI‑сгенерированный прототип, часто встречаются 3–5 конкурирующих источников правды. Консолидация их обычно самый быстрый путь остановить утечки без переписывания всего приложения.

Краевые случаи, где чаще всего утекает доход

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

Правила trial vs paid могут конфликтовать неожиданно. Частая ошибка — сначала проверять isTrialActive и возвращать результат раньше, даже после апгрейда. Это может применить лимиты trial к платным пользователям или, хуже, применить более мягкие trial‑правила к платным.

Даунгрейды — ещё одна тихая утечка. Если вы блокируете функции только при логине, пользователь может оставить открытую вкладку и продолжать использовать платные функции после даунгрейда. То же случается при слишком длительном кэше прав. Если план меняется, приложению нужен быстрый способ перепроверить доступ (или инвалидировать кеш) перед чувствительными действиями.

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

Пара «грязных» кейсов, которые стоит протестировать:

• Две активные подписки (пользователь подписался дважды или переключил планы без отмены старой)
• Несоответствие биллинга воркспейса и пользователя (участник случайно наследует план владельца)
• Обход ролей (админы получают полный доступ даже на Free)
• Старые «grandfathered» флаги, переопределяющие текущие проверки планов
• Ручной инвойс, отмеченный как оплаченный без обновления прав

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

Частые ошибки и ловушки, которых стоит избегать

Ошибки контроля биллинга чаще всего происходят из‑за того, что правила живут в слишком многих местах и не согласованы. В прототипе UI может выглядеть нормально, в то время как бэкенд по‑прежнему разрешает платные endpoint'ы.

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

Типичные ошибки, за которыми стоит следить:

• Гейтинг только в UI: фича скрыта, но план на сервере не проверяется.
• Разбросанные проверки планов: в разных файлах используются разные правила (имя плана здесь, price ID там, логика trial где‑то ещё).
• Слепая вера полям вебхука: принять статус плана из события без сверки с собственными записями.
• Нет безопасности вебхуков: игнорирование ретраев, дубликатов или внепорядковых событий, из‑за чего случайно включается доступ.
• Смешанные окружения: dev‑ключи в проде (или наоборот), из‑за чего вы «чините» не те данные и баг возвращается.

Классика: пользователь апгрейдится, UI показывает Pro, но бэкенд читает старый закешированный план в течение 10 минут. Это окно достаточно, чтобы совершить много экспортов или других платных действий.

Если вы унаследовали AI‑сгенерированный код, эти проблемы часто закодированы как копипаст‑проверки. Консолидация логики в одну серверную проверку и усиление обработки вебхуков уменьшают шанс возврата бага после следующего рефактора.

Перед релизом выполните два sanity‑теста:

1. Вызовите платный API‑endpoint напрямую с аккаунта Free.

2. Реплейте один и тот же вебхук апгрейда дважды, затем отправьте позднее событие даунгрейда и подтвердите, что доступ в итоге корректно закрывается.

Быстрая проверка перед релизом или перезапуском

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

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

• Попробуйте платные действия с бесплатного аккаунта, вызывая API напрямую (не через UI). Если какой‑то платный endpoint возвращает успех — у вас утечка.
• Апгрейдните тестовый аккаунт и обновите страницу с нового устройства или в режиме инкогнито. Доступ должен открыться быстро и оставаться открытым через 10 минут.
• Даунгрейдните или сделайте неуспешный платёж, затем попробуйте те же платные действия. Они должны надёжно остановиться, даже если UI пока ещё показывает старые кнопки.
• Реплейте вебхуки биллинга. Обработчики должны быть безопасны при повторном запуске, а результат — понятен в логах.
• Откройте внутренний экран, который показывает текущие права пользователя, их источник (план, доп, trial) и когда они обновлялись в последний раз.

Полезный реальный тест: апгрейдните пользователя, затем сразу запустите тяжёлую платную задачу (экспорт, запуск AI, массовое действие). Если задача стартует до обновления прав — вы нашли гонку. Обычно починка — проверка прав на сервере в момент действия и ожидание подтверждения нового состояния при потоке апгрейда.

Также проверьте логи. Когда что‑то идёт не так, вы должны уметь ответить «почему этот запрос разрешён/отклонён?» без догадок:

• Запрос разрешён/отклонён потому что entitlement X было true/false.
• ID события вебхука, статус (processed/skipped) и причина.
• Старое vs новое состояние entitlements с таймстемпами.

Пример: апгрейд, который разблокирует функции бесплатно

Типичная утечка выглядит безобидно: пользователь нажимает Upgrade, видит «Pro» в UI и сразу начинает пользоваться платными фичами. Позже вы замечаете, что он так и не заплатил или платёж провалился, но доступ остался.

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

Где прячется баг

UI переключается на Pro по локальному флагу (или закешированной записи). Но бэкенд всё ещё видит пользователя как Free, потому что реальное право обновляется только при приходе вебхука.

Если проверки фич зависят от состояния клиента, кэшированной сессии или медленного чтения из БД, пользователь может просочиться через гейт.

Как его воспроизвести (надёжно)

Обычно воспроизводится без сложных инструментов:

• Откройте две вкладки в одном аккаунте.
• В Вкладке A нажмите Upgrade и завершите чек‑аут.
• В Вкладке B обновите страницу и быстро нажмите платную фичу (или спамьте кнопку).
• Добавьте задержку в обработке вебхуков (или тестируйте в медленном окружении) и посмотрите результат.

Если платное действие проходит до того, как вебхук обновит права, у вас есть пробел.

Практичный фикс, который закрывает дыру

Обращайтесь с апгрейдами как с машиной состояний на сервере, а не как с переключателем UI:

• Серверный защитник: каждое платное действие проверяет серверные права, а не метку плана в клиенте.
• Pending‑состояние: при старте чек‑аута ставьте статус вроде pending_upgrade и держите платные функции заблокированными (или разрешайте только ограничённый просмотр).
• Идемпотентная обработка вебхуков: безопасно обрабатывать одно и то же событие дважды и игнорировать внепорядковые события с помощью ID события и таймстемпов.

Чтобы подтвердить исправление, повторите тест с двумя вкладками и убедитесь по логам, что платные действия отклоняются до тех пор, пока запись прав действительно не станет активной, а затем разрешаются только после обновления серверного состояния (вебхуком или подтверждённой оплатой).

Если вы унаследовали AI‑сгенерированный прототип (Lovable, Bolt, v0, Cursor, Replit), этот баг встречается часто: план хранится в нескольких местах. FixMyMess обычно решает его, прослеживая все проверки плана, переводя в единый серверный источник правды и укрепляя логику вебхуков, чтобы «Pro» значил реально оплачено.

Следующие шаги: закройте утечки дохода без полного переписывания

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

Выберите одно место на сервере, которое будет гейткипером, и заставьте всё проходить через него. Если приложение проверяет планы в пяти разных файлах (или только в UI), вы обязательно пропустите один.

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

• Перечислите платные действия и добавьте один серверный защитник, используемый всеми платными endpoint'ами.
• Ужесточите обработку вебхуков: проверяйте подписи, сохраняйте события и делайте обработку идемпотентной.
• Добавьте ретраи для неудачной обработки вебхуков и обрабатывайте поздние события так, чтобы доступ не ломался.
• Протестируйте апгрейды под нагрузкой: симулируйте медленные сети, двойные клики и апгрейд с двух устройств одновременно.
• Перепроверьте даунгрейды и возвраты, чтобы доступ менялся правильно и вовремя.

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

Если вы работаете с AI‑сгенерированным прототипом, проблемы биллинга часто идут в комплекте с другими проблемами: запутанная аутентификация, открытые секреты или запутанная архитектура. Если хотите второе мнение, FixMyMess (fixmymess.ai) фокусируется на диагностике и починке AI‑сгенерированных кодовых баз, включая логику entitlements, обработку вебхуков, укрепление безопасности и подготовку к деплою.

FixMyMess также предлагает бесплатный аудит кода, чтобы указать, где утечки доступа, и затем ремонтирует проверки планов и крайние случаи вебхуков с человеческой верификацией, часто в течение 48–72 часов.