TL;DR: Yes: a bot can take money and hand over the goods without you. Telegram's Payments API lets it send an invoice (sendInvoice with a provider's token), charge a card (or crypto through a provider like CryptoBot), and grant channel access or drop a file the instant the payment clears. For digital goods you charge in Telegram Stars; for services and bigger tickets you invoice on a payment system you connect yourself. Telegram takes no cut of that; only your provider does. So the checkout is a solved commodity. What no gateway sells you is the part that actually loses the sale: the conversation before the button: answering the real question, picking the right package, handling the "not sure it's for me." This guide separates the two halves, gives you a 5-link check for where your own chat drops the sale, and shows which rail matches which kind of good.
- Who this is for: creators, experts, and small operators who already sell in DMs and are shopping for "a bot that takes payment."
- What you'll get: how the checkout half actually works, a reusable 5-link checklist, the rail-to-good-type rule most guides blur, and a clear line where a plain payment-gateway bot is the better buy.
- Last updated: 2026-07-05.
The checkout half, correctly (so you don't overpay for it)
Search "chatbot that takes payment" and every result teaches the same 20%: wire a provider into your bot and let it charge. It genuinely works, and it's worth knowing exactly how so you don't overpay a middleman for it:
- Invoices and cards. Your bot calls
sendInvoicewith aprovider_tokenyou get from BotFather after linking a provider. The customer pays in the thread; the bot receives a confirmation event and can immediately grant access, send a file, or drop an invite link. Telegram charges no commission on this; only your payment provider does (a Robokassa runs ~3.5% on cards, ~0.4%+ on SBP, with no setup or subscription fee; Stripe runs ~2.9% + $0.30). (Provider rates research-dated 2026.) - Digital goods run on Stars. For a file, a paid post, or premium access, you charge in Telegram Stars, not a card. This isn't a preference. Telegram bots can't take card payments for digital goods from iOS users at all, an Apple-store rule, which is exactly why the Stars rail exists.
- Auto-delivery is a solved pattern. "Grant access the moment payment lands" (the «автоматическая выдача доступа» every vendor advertises) is a webhook that fires on the payment event. Constructor bots and payment plugins (Prodamus, ManyChat-to-Shopify, a dozen others) all do it.
If that is all you need (a button plus auto-delivery), you can stop reading and go wire one. It's an evening's work or a cheap plugin. Keep that in mind while you read the rest.
The full in-chat loop: the assistant answers, drops the invoice in the thread, and unlocks access the moment payment clears.
The two halves of getting paid in chat
Here's what none of those tutorials show you, because it isn't a product they sell. Getting paid in a chat is two different jobs, and most creators run them in two different tools:
- The checkout half: the button, the gateway, the auto-delivery. A Gumroad or Whop link, a Stripe integration, a native Telegram checkout. A commodity: solved, cheap, interchangeable.
- The conversation half: answering the buyer's actual question, working out which package fits them, and getting past "I'm not sure this is for me." This is where the sale is actually won, and a checkout link does none of it.
So the usual setup is a storefront bolted to a separate chatbot: one tool talks, another tool charges, and they don't share a thread or a memory. A scripted flow (ManyChat, Chatfuel) fakes the conversation for the branches you pre-wrote, and the newer AI-constructor bots genuinely answer some questions on their own. But the answer lives in one tool and the checkout in another, so the buyer feels the seam. The sale doesn't die at the button. It dies three steps earlier, in the gap between the tool that talks and the tool that charges.
Where does your chat drop the sale? A 5-link check
Every completed in-chat sale is a chain of five links. Break any one and the money stops there. Run your current setup against it and mark what your chat actually covers today:
| # | Link | What it means | Who covers it |
|---|---|---|---|
| ☐ 1 | Answer | Reply to the real question from your own information ("does this cover X? will it work if I'm Y?") | Checkout link / storefront: no. Scripted flow: only the branches you pre-wrote. AI-constructor or an assistant grounded in your docs: yes. |
| ☐ 2 | Qualify | Work out which package, tier, or price fits this buyer | Checkout: no. Scripted flow: a menu. AI assistant: yes. |
| ☐ 3 | Handle the objection | Get past "too expensive / not sure it's for me" | Checkout: no. Scripted flow: rarely. AI assistant: yes. |
| ☐ 4 | Invoice | Put the charge in the thread on the rail that fits the good | Anything with a payment integration. The commodity. |
| ☐ 5 | Deliver & log | Grant access / send the file on payment, record the sale | Same — auto-delivery on the payment event. |
Most checkout-first tools are strongest at links 4 and 5, and a dedicated one does them more cheaply and with fewer ways to break than any general assistant. Where a stack leaks is links 1–3: the storefront can't answer, the scripted greeter dead-ends, and even a capable AI bot in a second tool can't invoice on the rail its own answer implies. An assistant that holds all five in one thread passes links 1–3 to 4–5 without a seam, and the invoice becomes the last line of a conversation it actually held.
Match the rail to the good (the part guides get wrong)
If you take one correctness point from this page, take this one. It's where the checkout and the conversation meet:
| The good | The rail | Why |
|---|---|---|
| A service / consultation / bigger ticket | Invoice on your own payment system (cards, crypto, your rails) | Money lands where you already bank; no store fee; the assistant issues it after it has advised. |
| A digital file / paid post / premium access | Telegram Stars | The iOS rule blocks card payments for digital goods in bots; Stars is the compliant rail, and withdrawals cash out to USDT via Fragment. |
Get this backwards (trying to sell a downloadable file via a card invoice, or run a €400 consult through Stars) and you either hit the iOS wall or push your buyer into an app-store-taxed Stars top-up where a plain invoice would have kept more. The rail follows the good, not your preference.
A worked example: the coach whose checkout link answers nothing
Say you coach runners and sell two things: a downloadable 8-week training plan and a live 1:1 video session. Your setup is a Gumroad link for the plan and a scripted greeter in your DMs. A message comes in: "will the plan still work if I'm coming back from a knee injury?" (your buyer, your niche — swap in yours).
The greeter has no branch for that, and the Gumroad link just charges. So the buyer waits for you, the question lands in a pile you clear after your own training, and by then some of that day's buyers have booked with a coach who replied first. Your checkout was perfect and the sale still stalled, on link 1.
Now put an assistant in the same thread. It answers from your own training notes, works out that the return-to-run plan is the fit, and, because a live session is a service, issues that invoice on your own rail (your Stripe, your card processor). The 8-week plan, a digital file, goes out via Stars, the correct rail for a digital good. Same thread, both rails, the conversation carried the whole way to paid. That is the difference between a checkout that charges and an assistant that sells and then charges, and it's why iSales frames the payment step as the close of the answer→qualify→book loop, not a bolt-on: one assistant that answers and qualifies and invoices on your own systems and sells your content for Stars, in one chat.
About the Stars "30%"
You'll read that Stars cost you 30%. That number is Apple's and Google's fee on the buyer's in-app Star purchase on a phone, not a cut Telegram or the tool takes from your payout. Buyers who top up on desktop or the web avoid the store fee entirely, which is why bigger tickets are best routed through your own invoice rail, with Stars kept for impulse digital buys. The full withdrawal math (Fragment, the minimum, the hold, the conversion to USDT) is its own topic, and we walk through it in selling content for Stars and cashing out to USDT. For here, the one line that matters: the payment method is plumbing, never the reason to choose a tool.
When a payment-gateway bot is the right call (and this isn't)
Skip the assistant if your situation looks like this: everyone who reaches your bot already knows the exact product and the exact price, and all they need is a way to pay. A fixed catalog, a known SKU, high volume, no questions. In that world a dedicated gateway bot wins outright: it does links 4–5 at ~3.5% with one job to get wrong, and paying for a conversation layer no one uses is waste. If you're selling one $9 file to people who already decided, wire a Gumroad link or a Stripe checkout and move on.
The assistant earns its place only when buyers arrive undecided, when links 1–3 are where your money leaks. If your inbox is full of "which one is right for me?" and "does it cover my case?", those are the sales a faster answer wins, not a faster checkout.
Two more limits, so you buy with open eyes. An assistant will get an edge case wrong on its first days, so skim its early conversations before you trust it to quote prices unattended. And invoice mode runs on the payment systems you connect yourself: your rails, your fees, your compliance (receipts, local rules). The assistant puts the invoice inside the conversation; it doesn't take over your relationship with the gateway.
FAQ
Which payment systems can it invoice on? Your own — the ones you already use (cards, crypto, your rails). Telegram doesn't process the money or take a commission; your provider does, at its own rate.
Can I sell a digital file for a card payment inside a bot? Inside Telegram, digital goods run on Stars — that's the rail Telegram gives them, and card payments for digital goods are blocked outright for iOS buyers. Sell files and paid access via Stars; keep card or crypto invoices for services and consultations.
Do I need a separate store or website? No. The conversation is the checkout. Access and files are delivered in the same chat on payment.
What happens if the assistant answers wrong or quotes the wrong price? It escalates hard cases to you (a human on exception, not by default), and you can review its early conversations. Treat its first days as supervised, the way you would a new hire quoting prices.
Is this different from a monetization storefront like Whop or Gumroad? Yes: a storefront sells but doesn't converse. For the full picture of the four ways to monetize an assistant and where a storefront actually wins, see how to monetize your AI assistant.
Next step
If your sale keeps dying on links 1–3, watch it hold the whole chain in your own niche. Answer four questions and start free with 30 messages; the assistant replies in a test chat, and you'll see where the conversation would have carried to paid. No card to try it.
For the wider assistant this is one part of (reply, book, take payment, one voice across channels), start from the complete guide to an AI assistant for business in Telegram.
Sources & last updated
- Telegram, Bot Payments API: no Telegram commission;
sendInvoice/provider_token/payment event; digital goods use Stars; iOS card restriction for digital goods. core.telegram.org/bots/payments (Tier-1). - Telegram, Bot Payments for Digital Goods (Stars). core.telegram.org/bots/payments-stars (Tier-1).
- Provider rates (Robokassa ~3.5% card / ~0.4%+ SBP, no setup/subscription; Stripe ~2.9% + $0.30), research-dated 2026, verify current before relying on them.
- Stars app-store fee framing (~30% is Apple/Google's buyer-side in-app fee; desktop/web avoids it), research-dated 2026.
Provider rates checked July 2026 — list prices, subject to change.
