Как устроен биллинг-контур: бот, панель, API

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

Три детали, из которых собран контур

Я поднимал этот контур десятки раз, и каждый раз он держится на трёх штуках. Не больше.

• Бот — витрина. Он показывает тарифы, принимает оплату, разговаривает с клиентом. Клиент видит только его.
• Панель — склад доступов. Это мозг, который знает про каждого пользователя: сколько ему осталось, на какие серверы он ходит, сколько устройств. У меня это Remnawave, но принцип от панели не зависит.
• API — провод между ними. Бот не лезет руками в базу панели, он дёргает её REST API: «создай юзера», «продли до такой-то даты», «отдай ссылку на подписку».

Всё. Клиент нажал «купить», прилетела оплата, бот сходил в API панели и выдал доступ. Ни одного ручного действия с твоей стороны. Если ты понял эти три роли — ты понял, как работает любой продающий VPN-бот на рынке, хоть коробочный, хоть самописный.

Почему это одна цепочка, а не набор кнопок

Новичок смотрит на бота и видит кнопки: «оплатить», «продлить», «мои серверы». И думает, что задача — накидать кнопок. Это ловушка. Кнопки — это косметика. Настоящая работа в том, что между оплатой и выдачей доступа идёт непрерывная цепочка событий, и каждое звено может порваться.

Смотри, как это выглядит по шагам:

1. Клиент выбрал тариф → бот создал счёт у платёжного провайдера.
2. Клиент заплатил → провайдер прислал боту сигнал об оплате (вебхук или бот сам опросил статус).
3. Бот проверил, что оплата настоящая, и что по ней ещё не выдавали доступ.
4. Бот сходил в API панели: создал нового юзера или продлил существующего.
5. Бот отдал клиенту ссылку на подписку и QR.

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

Тариф — это не строчка в прайсе, это набор доступов

Вот момент, который ломает голову новичкам. В нормальной панели тариф — это не «300 рублей за месяц», а набор серверов, которые открываются клиенту. В Remnawave такой набор называется сквадом (squad) — это группа входных точек, к которым получает доступ юзер.

Из этого следует вся логика продаж:

• Купить тариф = бот создаёт юзера и кладёт его в нужный сквад.
• Апгрейд на дороже = бот добавляет юзера в сквад побогаче (там больше серверов, обход блокировок, приоритет).
• Срок подписки = дата expireAt у юзера в панели. Прошла дата — панель сама перестаёт пускать.
• Лимит устройств = отдельное поле (hwidDeviceLimit). Это же твой главный рычаг против шеринга.

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

Где контур рвётся чаще всего

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

• Двойная выдача. Провайдер прислал вебхук дважды (это норма, они делают ретраи), бот дважды продлил — клиент получил лишний срок бесплатно. Лечится идемпотентностью: один платёж = одна выдача, повтор молча игнорируется.
• Оплата есть, доступа нет. API панели не ответил в момент выдачи — деньги прошли, юзер не создан. Нужна сверка: регулярно сравнивать платежи с выданными подписками.
• Поддельная «оплата». Кто-то дёрнул твой вебхук напрямую и притворился платежом. Поэтому подпись вебхука проверяют всегда.

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

Коробка или самопис

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

Развилка простая:

• Начинаешь, хочешь запуститься за вечер и без возни — берёшь простой бот на SQLite, настраиваешь мышкой.
• Нужен полноценный продукт с кучей способов оплаты, подарками, реферальной системой — берёшь тяжёлый, но готовься к Postgres, Redis и большому конфигу.

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

Дальше — в практике: там я показываю, как поднять конкретного бота, связать его с панелью по API и замкнуть контур так, чтобы клиент платил, а подписка выдавалась и продлевалась без тебя.