How the Billing Loop Works: Bot, Panel, API

I break down in plain terms how money turns into a working subscription without your involvement. This is loop theory — no commands — so you understand who's responsible for what before diving into the practice and configuring a specific bot.

This material is about engineering your own infrastructure and is educational in nature. The laws and taxes of your own jurisdiction are on you.

The three parts the loop is made of

I've stood up this loop dozens of times, and every time it rests on three things. No more.

• The bot — the storefront. It shows the plans, takes payment, talks to the customer. The customer sees only it.
• The panel — the warehouse of access. It's the brain that knows about each user: how much they have left, which servers they go to, how many devices. For me it's Remnawave, but the principle doesn't depend on the panel.
• The API — the wire between them. The bot doesn't reach into the panel's database by hand, it calls its REST API: "create a user," "extend to such-and-such date," "give me the subscription link."

That's it. The customer hits "buy," a payment arrives, the bot goes to the panel's API and grants access. Not a single manual action on your side. If you've understood these three roles, you've understood how any selling VPN bot on the market works, whether boxed or homemade.

Why it's one chain, not a set of buttons

A beginner looks at the bot and sees buttons: "pay," "renew," "my servers." And thinks the task is to throw together buttons. That's a trap. Buttons are cosmetics. The real work is that between payment and granting access there's a continuous chain of events, and each link can break.

Look at how it goes step by step:

1. The customer picked a plan → the bot created an invoice at the payment provider.
2. The customer paid → the provider sent the bot a payment signal (a webhook, or the bot polled the status itself).
3. The bot verified the payment is real, and that access hasn't already been granted for it.
4. The bot went to the panel's API: created a new user or extended an existing one.
5. The bot gave the customer the subscription link and QR.

Break any link — the customer paid but has no access. That's the worst thing that can happen in a service: a person gave money and is angry. So the loop is designed not as "buttons" but as a reliable relay of an event from money to access.

A plan isn't a line in a price list, it's a set of access

Here's the moment that breaks beginners' heads. In a proper panel a plan isn't "300 rubles a month," it's a set of servers that open up to the customer. In Remnawave such a set is called a squad — it's a group of entry points a user gets access to.

From this follows all the logic of sales:

• Buy a plan = the bot creates a user and puts them in the right squad.
• Upgrade to a pricier one = the bot adds the user to a richer squad (more servers, block circumvention, priority).
• Subscription term = the expireAt date on the user in the panel. The date passed — the panel stops letting them in on its own.
• Device limit = a separate field (hwidDeviceLimit). It's also your main lever against sharing.

So when people say "set up a plan," it really means: create a squad with the right servers and teach the bot to put payers into it. The price in the price list is a layer on top.

Where the loop breaks most often

Since it's a chain, it's useful to know its weak spots in advance — I've taken my lumps on them.

• Double grant. The provider sent the webhook twice (that's normal, they do retries), the bot renewed twice — the customer got an extra term free. Cured by idempotency: one payment = one grant, a repeat is silently ignored.
• Payment exists, access doesn't. The panel's API didn't respond at the moment of granting — the money went through, the user wasn't created. You need reconciliation: regularly compare payments against granted subscriptions.
• A fake "payment." Someone hit your webhook directly and pretended to be a payment. That's why the webhook signature is always verified.

These aren't abstract scare stories — they're exactly the three holes through which money leaks from a service. In theory it's enough to know they exist and why; they're closed procedurally, and that's a separate conversation about anti-fraud.

Boxed or homemade

The last thing worth understanding at the theory level: you almost never need to write a bot from scratch. There are mature ready-made bots for Remnawave — from very simple ones that install with one command and are configured via a web panel, to heavy combines with two dozen payment methods, promo codes, and a web account.

The fork is simple:

• Just starting, want to launch in an evening and without hassle — take a simple SQLite bot, configure it with the mouse.
• Need a full product with lots of payment methods, gifts, a referral system — take a heavy one, but prepare for Postgres, Redis, and a big config.

In both cases the mechanics are the same — that "money → panel API → access" chain I covered above. Only the wrapper and the number of features change.

Next — in the practice: there I show how to stand up a specific bot, tie it to the panel via API, and close the loop so the customer pays while the subscription is granted and renewed without you.