The bot walks someone to a Buy button — then sends them to a website, a form or, at worst, asks for a screenshot of the transfer. Every hop costs buyers: in our projects an external checkout page converts 15–30% worse than a native one, and on small amounts the gap is wider still. Below are the three viable ways to take money inside the chat, what each costs in fees and development, how subscriptions and receipts really work, and where people abandon a purchase.

Three ways to take money in a bot

There are exactly three viable schemes plus one stopgap, and the choice is not a matter of taste. It is decided by what you sell: physical goods and digital access sit under different rules, and confusing them is expensive.

How Telegram Payments actually works

Telegram never holds your money and never takes a cut: it renders the form, collects the card data and hands it to your payment provider. Funds land in your acquiring account and the bot only receives status events. Hence the one architectural rule that matters — the source of truth is a specific update, not a button press.

1. 1

   Connect a provider

   In BotFather → /mybots → Payments you pick a provider available in your country. Take the test token too: without it you cannot rehearse failure paths without burning real money.

2. 2

   Issue the invoice

   sendInvoice takes a title, a description, a payload carrying your order id and a price in minor units. The classic first-week bug is passing 149 instead of 14900.

3. 3

   Pre-checkout

   The bot gets a pre-checkout query and has exactly 10 seconds to answer: verify stock, price and limits. Miss the window and Telegram cancels the payment for you.

4. 4

   Confirm and fulfil

   Success arrives as a message carrying successful_payment and a telegram_payment_charge_id. Build idempotency on that id: one charge id, one fulfilment, however often the update is redelivered.

// Prices are always in minor units: $149.00 → 14900.
await api('sendInvoice', {
  chat_id: chatId,
  title: 'Foundations course',
  description: '12 months of access to all materials',
  payload: orderId,               // your id — it comes back to you
  provider_token: PROVIDER_TOKEN, // empty string when charging in Stars
  currency: 'USD',
  prices: [{ label: 'Course', amount: 14900 }],
});

// Exactly 10 seconds to answer, or the payment is cancelled.
onUpdate('pre_checkout_query', async (q) => {
  const ok = await isStillAvailable(q.invoice_payload);
  await api('answerPreCheckoutQuery', {
    pre_checkout_query_id: q.id,
    ok,
    error_message: ok ? undefined : 'That item just sold out',
  });
});

// The only event after which the money is genuinely yours.
onUpdate('message', async (msg) => {
  const p = msg.successful_payment;
  if (!p) return;
  await fulfilOnce(p.invoice_payload, p.telegram_payment_charge_id);
});

Stars, digital goods and recurring charges

Stars are Telegram’s internal currency, bought in advance by the user. From your side it is the same sendInvoice call with the XTR currency, an empty provider token and one line in the price array. The differences start after that, and they matter before you build a business model on top.

• Payouts are not immediate. Earned Stars are withdrawn through Fragment after a hold of roughly 21 days — the first money from launch reaches you three weeks later at best.
• The payout rate is below the purchase price. At the time of writing it works out near $0.013 per Star, so the effective haircut lands closer to 30%. That is the number your model needs.
• Refunds are mandatory. refundStarPayment has to be implemented and reachable by the user, otherwise you get a support queue and a policy problem.
• Star subscriptions work out of the box. An invoice link with a 30-day renewal period, and Telegram charges monthly while the user cancels in their own interface.
• Card subscriptions do not exist. Recurring fiat charges need tokenisation on the acquirer’s side, and that flow launches from a Mini App or a web page.

Where purchases actually fall apart

A technically correct integration still loses money when the script around it is careless. Ordered by cost, from the logs of bots we run for retail and service businesses.

1. 1The price appears for the first time at the payment step. The biggest single drop: the person came for a consultation and got an invoice. Show the amount above the button.
2. 2The return from 3-D Secure. When checkout opens in an external browser, a share of users never come back after confirming with their bank. The native form removes this entirely.
3. 3No processing state. Two to six seconds pass between the tap and the confirmation, and without a message the user taps again. What follows is a duplicate order and a refund.
4. 4Invoices with no expiry. One can be paid a week later, when the price has changed and the item is gone. Tie the payload to an order with a deadline and check it at pre-checkout.
5. 5No fallback channel. For high-hundreds amounts and company buyers, keep a request-an-invoice button — otherwise you cut off your largest orders for the sake of a tidy interface.

What it costs to build, and what to do about receipts

Now the part everyone postpones. If you sell to consumers by card, a fiscal receipt is required exactly as in a physical shop — a bot is not an exemption, and the rules differ by country rather than disappearing. In practice that means a cloud receipt service with an open API and another $200–400 in the quote. The receipt is generated after successful payment and arrives with the order confirmation.

Budgeting rule of thumb: the integration is about 20% of the work, and the rest goes on failure paths, refunds, receipts and pushing orders into your accounting stack. If a vendor quotes only for connecting payments, ask them to price the other 80% — we broke that down in our guide to what a Telegram bot costs.

Frequently asked questions about bot payments

In short

• Physical goods and services go by card through Telegram Payments; digital access inside Telegram must go through Stars or you risk the bot.
• The source of truth is the successful_payment event and its charge id, never a button press. Idempotency is non-negotiable.
• The largest conversion losses come from a price revealed too late and from returns via an external checkout page, not from fees.
• The integration is roughly 20% of the work; the rest of the budget is failure paths, refunds, receipts and order handover.
• Receipts apply to bot sales exactly as they do in a shop: budget $200–400 and a separate week of work.