How to accept crypto payments in a Telegram bot

Why "accept payments in a Telegram bot" isn't one integration

A Telegram bot that needs to get paid in crypto isn't a single, well-defined feature — it's a handful of genuinely different setups that all happen to run inside the same chat window. A bot selling one-off digital goods needs something different from a bot topping up an internal balance, which needs something different again from a bot doing real order volume with no human watching. Before picking one, it's worth being precise about what's actually available to build with.

So, upfront: Zyrvix does not have a Telegram-specific integration. There's no bot SDK, no Mini App tooling, and no TON Connect wiring shipped for this. What exists is the same generic REST API covered in how to accept TON payments — create an invoice, get back a payment link, get told when it's paid. Everything below is that API, called from inside a bot's own message-handling code, in whatever language the bot is already written in. None of it is a plugin you install; all of it is a handful of lines you write yourself.

Three ways to do it, in increasing order of automation

Strip away the Telegram framing and every "how do I get paid through my bot" question reduces to one of three shapes:

• A static wallet, watched by hand. Publish one address, ask people to send TON to it, and reconcile who paid what yourself.
• A payment link per request. The bot asks Zyrvix for an invoice and hands the customer a link — no server process needed beyond making that one call.
• Fully automated invoicing. The bot creates the invoice, and a webhook tells it the moment payment lands, so the chat itself confirms the order with no one checking anything by hand.

Only the last two actually involve Zyrvix. The first is worth covering anyway, because it's genuinely where a lot of small Telegram sellers start, and knowing why it breaks down is what motivates the other two.

Pattern one: a static wallet address, watched by hand

This is the version that needs no integration at all: a bot (or its operator, manually) posts a single TON wallet address in the chat and asks people to send payment there. It's common for small balance-top-up bots — game credits, ad spend, a running tab — where the operator just checks the wallet's transaction history periodically and credits whoever sent what.

It works precisely as long as volume stays low enough for a human to eyeball the chain. Past that, it runs into the exact four problems how to accept TON payments lays out for doing this yourself: nothing ties a specific transfer to a specific user without a memo, two people sending the same round amount around the same time are indistinguishable, and there's no way for the bot itself to know a payment happened — only the operator, reading the chain by hand, does. There's no failure mode here beyond "it doesn't scale" — it's a legitimate starting point, just not one Zyrvix has any part in. The fix isn't a smarter static wallet; it's moving to a pattern that assigns each request its own identity, which is exactly what patterns two and three do.

Pattern two: a payment link per request

This is the smallest change that fixes pattern one's problems, and it's the "payment link" pattern Zyrvix already provides with zero extra building. When a customer wants to pay, the bot's backend makes one authenticated call to POST /invoices, and the response includes a hosted_payment_url — a link the bot sends straight into the chat, as a message or an inline button.

The customer taps it, and it opens Zyrvix's hosted pay page — inside Telegram's own in-app browser if that's where they tapped it from — showing the QR code, the wallet address, and the memo, all generated for that one invoice. They pay from whatever TON wallet they already use; the memo is attached automatically, the same mechanism covered in the general integration guide.

This pattern is deliberately the low-effort one: a bot that only ever fires this single API call — say, in response to a /pay command — doesn't need a persistent server watching for anything. It can check the invoice's status the next time the customer messages it, or on a slash command like /status, using the same API key. That makes it a good fit for manual or low-volume selling: a solo operator running a storefront out of a Telegram channel, taking orders one at a time, without running infrastructure beyond the bot process itself.

Pattern three: fully automated invoicing

Past a certain volume, checking invoice status by hand — or asking the customer to confirm they paid — stops working. Pattern three is pattern two plus one more piece: a webhook receiver. The bot's backend still calls POST /invoices exactly as above, but it also runs a small endpoint that Zyrvix's invoice.paid webhook hits the moment payment is matched on-chain. That handler is what lets the bot reply in the chat — "payment received, here's your order" — without a human or a polling loop involved anywhere.

The invoice-creation call itself is identical to any other Zyrvix integration:

# replace with the full sk_ key you saved at creation
curl -X POST https://api.zyrvix.com/invoices \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "amount": "5.5",
    "pay_to_address": "EQD_YOUR_TON_WALLET_ADDRESS",
    "expires_in_seconds": 1200
  }'

The bot-specific part is entirely on the Telegram side, and it's a separate API from Zyrvix's: whatever library the bot already uses to talk to the Telegram Bot API (long polling or its own webhook, in whichever language the bot is written in) is what sends the confirmation message once your invoice.paid handler fires — Zyrvix has no part in that half of the wiring, and doesn't need to. Getting the webhook side right — verifying the signature, handling retries safely so a customer isn't told "paid" twice — is its own topic, covered in full in webhook idempotency and signature verification.

This is also the natural home for the balance-top-up case from pattern one, once it outgrows manual reconciliation: instead of one shared static address, the bot creates a fresh invoice — and therefore a fresh memo — for each top-up request, the same call shown above. It's not a fourth pattern; it's pattern two or three applied repeatedly, with each top-up getting its own identity instead of all of them landing in one undifferentiated address.

What this doesn't include

Worth restating plainly, since it's easy to read "works well inside Telegram" as more than it is: none of the above is a Telegram-specific feature of Zyrvix. There's no bot SDK to install, no Mini App scaffolding, and no TON Connect integration — the hosted pay page happens to render correctly inside Telegram's in-app browser, and the API happens to be generic enough to call from any bot framework, but that's the whole extent of the "Telegram support." Every pattern above is the developer's own bot code calling the same REST API described in the general integration guide, not a purpose-built Telegram product.

Which pattern fits your bot

Most bots that start on pattern one move to pattern two the first time a payment gets missed or double-counted, and from two to three the first time order volume makes checking status by hand tedious. There's no penalty for starting simple — the underlying call is the same one call either way.