Автоматическое списание подписки: как не оставить клиента на бесплатном доступе

Клиент оплатил наш сервис после 22 дней переговоров, двух созвонов и 238 сообщений. Но перед закрытием сделки я обнаружил в собственном биллинге лазейку: из-за неё клиент мог продолжить пользоваться сервисом бесплатно без ограничения по времени.

1 октября с его карты впервые списались реальные 11 111 рублей по подписке. До этого были только тестовые списания по 1 рублю для проверки привязки карты. Оплата прошла автоматически, без ручного запуска.

Проблема была в одном поле базы данных.

Как ручной доступ превращается в бесплатный

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

Для такого доступа у подписки provider = NULL. Это сделано специально: ежедневный робот, который проверяет подписки перед продлением и списанием денег, игнорирует такие записи. Иначе автоматика могла бы попытаться списать деньги с карты, которой формально нет, или продлить доступ, который никто не собирался продлевать.

Пока это демо, схема работает как задумано. Проблема возникает, когда тот же клиент после переговоров соглашается платить.

Если просто забыть вернуть provider, для системы ничего не изменится. Клиент продолжит пользоваться кабинетом, агент — отвечать его покупателям, а подписка останется с NULL. При этом не появится ни ошибка, ни предупреждение: бесплатный доступ просто продолжится.

Что я проверил перед оплатой

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

Нашлась ровно одна такая запись — у того самого клиента.

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

После этого всё сработало штатно. В 06:00 UTC ежедневный робот увидел подписку, проверил дату, обратился к платёжному провайдеру и получил успешный ответ. Отдельно нажимать кнопку оплаты не пришлось: достаточно было вернуть подписку в состояние, при котором её снова видит биллинг.

Что стоит проверять при переходе с демо на оплату

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

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

• действительно ли у неё указан provider;
• видит ли её платёжная автоматика;
• не осталась ли она в состоянии ручного доступа.

Я добавил себе отдельное правило: при переводе клиента с ручного тарифа на платный всегда сверять provider, а не считать, что раз сервис работает, значит всё в порядке с биллингом.

Это разные вещи. Работает ещё не означает выставляет счёт.

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