Accept crypto payments in Telegram without a website

A Paymos project on the Telegram channel takes payments inside a chat. The invoice's payment URL is a deep link into the Paymos bot: the payer opens it in Telegram, picks an asset and a network, gets a deposit address and a QR code, and follows the status without leaving the conversation.

No website appears anywhere in that sale. The payer needs no Paymos account, and the channel is not a per-invoice option either: it is settled on the project, and every invoice it issues answers the same way.

A Telegram-bot project has no hosted payment page at all. There is none behind the bot and none beside it as a fallback, and its return URLs, when they are set, are Telegram links — so the sale stays inside the app the customer was already in.

That reads like a removal until you ask what a hosted page was doing in a chat sale. On the Telegram channel the payment is presented in the app the customer was already using, so the page is not swapped for a substitute — it is not part of the route.

Picking between the methods available when a website exists belongs to that guide. This one covers the case underneath it: what the Telegram channel is, what it takes off the table, and what it leaves exactly where it was.

What does it mean to accept crypto payments in Telegram?

Accepting crypto payments in Telegram means the payment happens in a chat with a bot, not on a web page. Telegram describes a bot as a small application that runs entirely within the Telegram app, so there is nothing for the payer to install and no second product to learn.

The shape of a Paymos payment inside that chat is short. The merchant sends the invoice link, the payer opens it in Telegram, and the bot carries the rest: the asset and the network first, then the deposit address and a QR code, then the status.

What the payer brings to it is Telegram and a wallet holding the asset. Nothing else is required of them — no Paymos account, no website anywhere in the path, and nothing new to install to complete the payment.

Where is the checkout channel decided?

The checkout channel is a property of the Paymos project. It is picked once, every invoice created under it inherits that setting, and a project sits on one channel — never partly on a second.

A Paymos invoice therefore carries no channel of its own. Creating one does not choose between a page and a bot, and no field in the request offers the choice, because the project it belongs to settled the question before the invoice existed.

For anything calling the Paymos API, that is worth knowing before the first invoice rather than after. The request body and the response shape are the documented ones, and the payment_url inside that response points at a different kind of destination depending on which project issued it.

An order confirmation written on the assumption that the customer will see a web page therefore describes the wrong thing on a Telegram-bot project. The copy around the link is the merchant's, and it has to match the channel the project is on.

What replaces the hosted payment page?

On a Telegram-bot project the invoice's payment_url is a deep link into the Paymos bot. It is a link like any other link — it is sent, tapped, and forwarded the same way — and Telegram is what opens.

Telegram documents the format behind that behaviour. A bot link is https://t.me/<bot_username>, a ?start= parameter of up to 64 characters can ride along with it, and the bot receives that parameter the moment the chat opens, "without any user input".

Underneath it there is no page. A Telegram-bot project has no hosted payment page at all, so the bot is not a shell around a checkout that also exists on the web — for that project, the web version was never created.

What does the payer do inside the bot?

The payer chooses an asset and a network first. The Paymos bot answers with a deposit address and a QR code, and those two choices come first because together they are what a payment route is made of — neither one is complete without the other.

An asset on its own does not identify a destination, which is why the Paymos bot asks for both. USDT on Tron and USDT on Ethereum are separate transfers to separate addresses, and the difference between those transfer standards is what the two-step selection protects the payer from.

The Paymos bot shows a QR code beside that address because the wallet is usually a second application on the same phone. Scanning removes the step where a payment address is carried by hand between two apps and then checked character by character.

Then the payer sends the transfer from their wallet, and the invoice state moves on. Where that state is read on a Telegram-bot project, and how long a Paymos invoice takes to reach a confirmed one, is what the next section covers.

Where does the payer follow the payment status?

On a Telegram-bot project the payer follows the status inside Telegram. It is the same surface that asked for the asset and the network and returned the deposit address, so nothing about the payment is somewhere else while it is being confirmed.

Paying means leaving the payment screen on any channel. The payer switches to a wallet, sends the transfer, and returns — and on a Telegram-bot project, returning means opening the conversation with the Paymos bot again and reading the current state there.

The wait in between is not the merchant's to shorten. Confirmation depth follows the network and the payment amount, so how long a Paymos invoice takes to confirm belongs to the chain; what the project's channel decides is only where the payer spends it.

Does the payer need a Paymos account?

No. The payer does not need a Paymos account to pay a Paymos invoice in Telegram, and nothing in the flow quietly creates one for them. Whoever opens the link is a customer for the length of one payment.

The same holds on the Paymos checkout side: the payer is not asked for an email address and is not put through payer KYC to complete a payment. The Paymos account belongs to the merchant, and the payer stays a payer.

This weighs more on the Telegram channel than on a website. A conversation sale is usually a short decision, and a registration in the middle of it is a second decision the customer never came to make — one taken while a wallet app sits open and waiting.

Where does the payer end up after paying?

Return URLs on a Telegram-bot project are Telegram links, when they are set at all. The payer who arrived through a chat is sent back into Telegram rather than out of the app the payment happened in.

The kind of destination is fixed; which destination it is, is not. On a Telegram-bot project a return URL is a Telegram link, and the particular link is set on the project, exactly as the success and failure return URLs are set on any other channel.

For a business that sells inside Telegram, that closes the loop. The customer came from a chat, paid in a chat, and returned to one, and no browser was opened at any point in the sale.

What the merchant's own systems read is still the webhook, not the payer's arrival in Telegram. The eight Paymos invoice events, each signed with HMAC-SHA256, are what report a state change; a return URL reports only that a person went somewhere.

How is this different from sending a payment link into a chat?

Pasting a Payment Link into Telegram is distribution. The Telegram channel is where the payment itself happens, and the two get confused constantly, because in both cases a Paymos invoice reaches the customer as a link in a chat.

A hosted-page link travels through anything — email, SMS, a support thread, a Telegram message, an invoice PDF. When the customer taps it, Hosted Checkout opens in a browser, because that is what payment_url points at on every other channel.

A Telegram-bot project's link opens the bot instead. The message carrying it can look identical, in the same chat window and from the same sender, and everything that happens after the tap belongs to a different part of the product.

The test is what happens after that tap, not what the message looked like. If a browser opens, the invoice came from another channel, whatever app the link arrived in; if the payment continues in the chat, the project is on the Telegram channel.

What does the Telegram channel leave unchanged?

The Telegram channel decides where a payment is presented, not how it is processed. Under the bot sits the same machinery every other channel runs on, and it is worth naming, because "no hosted page" reads broader than it is.

A Paymos invoice is the same object on every channel. It carries an amount, an expiry, and a state; overpayment credits in full, and underpayment tolerance stays whatever the project configured — how an invoice moves between those states does not change in Telegram.

Money behaves the same way behind the bot. The Paymos balance credits in the asset the payer sent, held per asset across the networks it arrived on, and the processing fee is the one in the price list — 1.0% per settled invoice on Standard pricing.

So does everything a developer touches on a Telegram-bot project. The webhook contract is the same signed delivery carrying the same event names, and confirmation depth is still read from the network and the payment amount rather than from the channel.

Which channel should a project be on?

The fork is where the customer already is when they decide to pay. A Telegram-bot project fits a storefront that is a conversation; a customer standing on a page, or at a counter, is not in one. Telegram Checkout covers where the chat version fits.

Four questions settle it, and none of them needs a Paymos invoice to answer.

1. Where is the customer standing when they decide to pay — a Telegram chat, a channel, or a page on your own site?
2. Does the sale need a checkout page carrying your logo and colors? That page comes with the hosted checkout, which a Telegram-bot project does not have.
3. Which project carries this traffic? The channel is the project's property, so the answer is a project, not a campaign.
4. What reads the outcome? The same webhook endpoint as everywhere else, running before the first live link.

Answered honestly, the Telegram channel stops looking like a smaller hosted checkout. It is one project setting that moves the whole payment into the app the customer was already in — and the path any crypto payment takes underneath it does not change.