How to Accept Payments in a Telegram Bot

rule Two rails, and the rule that assigns them

Anything digital — access to a channel, a file, a subscription, an unlock inside a game — goes through the platform's own in-app currency, the Stars from Step 077. Anything physical, or a real-world service you perform, goes through a card processor you connect yourself.

The dividing line is not Telegram's invention. Mobile application stores require that digital goods sold inside an application go through their purchase mechanism, and the in-app currency is the arrangement that satisfies that. Routing a digital product through the card rail is not a clever way to avoid a fee. It is a rule breach, and the consequence lands on your bot rather than on your accountant.

The fourth row is worth taking seriously for a small operation. A bot that collects an order and a contact, and a human who sends an invoice, has none of the complexity below and works fine until it does not.

receipt_long Three steps, and everybody skips the middle one

The flow has a shape worth understanding regardless of language or library.

First, you send an invoice. A title, a description, a price, and — this is the part that matters later — a reference of your own attached to it, such as your order number. That reference comes back to you at the end, and it is how a payment finds the thing it paid for. Without it you get a confirmation with nothing to match it against.

Second, the buyer presses pay and you get a moment to object. This step exists because time has passed since the invoice: the last item may have sold, the discount code may have expired, the price may have changed. You are being asked "is this still valid?", and the window is short. Check quickly and say yes or no — and do not put slow work here, because a slow answer is a failed payment for a customer who was ready to buy.

Third, you are told the payment succeeded, and you deliver. Two disciplines apply, both from Step 093. Deliver on this event, not when the invoice was sent. And make delivery safe to run twice, keyed to your own reference, because being told twice is a normal occurrence and a customer who receives two subscriptions or an unlock that charged twice will remember it.

shopping_cart What the buyer sees, and why it converts

The payment sheet is drawn by Telegram, over your bot, and the buyer recognises it. They do not type a card number into your message thread, they are not sent to a browser, and they are not asked to create an account. That is the entire advantage, and it is a large one.

It also sets a rule you should be loud about with your own customers: a legitimate purchase in a bot happens in that sheet. Any bot asking for card details, a wallet phrase or a login code in the conversation itself is doing something else, and the same sentence from Step 088 applies without modification. Your users are being taught this by every scam they encounter, so a checkout that looks like the scam converts badly no matter how honest you are.

Two smaller things that decide whether people finish. Say the total before they press anything, including anything added later — a surprise at the sheet is where people stop. And state what happens after payment, in the invoice description, because a buyer who does not know whether to wait in the chat or check their email assumes something went wrong.

touch_app Try it now — five minutes

Four steps, and the third is the one that will happen to you in the first week.

1. Decide which rail your product is on Digital or physical. If you are trying to argue that a digital thing is a service, you already know the answer.
2. Buy something from your own bot Once, for a trivial amount, as a real customer. It is the only way to see what the sheet actually says.
3. Deliver the same confirmation twice on purpose If the customer ends up with two of something, your delivery is not keyed to your own order reference, and it should be.
4. Write the refund policy into the invoice description Two sentences. It resolves most disputes before they become messages.

balance Refunds, settlement, and the parts that are yours

Three things are frequently discovered after the first hundred sales rather than before.

Refunds are a decision, not a mechanism. Both rails can return money, and neither of them decides whether you should. Write the policy first, put it where a buyer reads it before paying, and make it generous enough that you can apply it without thinking — the time spent arbitrating individual cases is almost always worth more than the sums involved. Note that the in-app rail has narrower routes than a card, so a policy that promises more than the rail supports will make you the one issuing it manually.

The money arrives later than the sale. Card processors settle on their own schedule; the in-app balance has a process of its own before it becomes withdrawable. Neither is instant, both are predictable, and a plan that assumes same-day cash is a plan with a gap in it.

The paperwork is yours. The platform handles a transaction; it does not handle your invoicing, your tax position or your obligations to a customer. Whatever applies where you live applies to money that arrived this way, and finding that out in the first month is considerably cheaper than finding it out in the eleventh.

storefront What actually sells well in a conversation

The checkout is excellent and it is not the right container for everything. Two lists, and the second one is where people lose money.

It suits small, immediate, single decisions. A ticket, an unlock, one file, a top-up, a tip, access to something starting now. The buyer already knows what they want, the price fits in a sentence, and nothing has to be compared against anything.

It does not suit anything requiring a choice. A catalogue with sizes, colours and options is a website; reproducing it as a sequence of chat messages produces a shopping experience nobody enjoys and an abandonment rate to match. Nor does it suit anything with real delivery logistics, or anything expensive enough that the buyer wants a quotation, an invoice and a trail before committing.

And one honest caution about the frictionlessness itself. A purchase made in two taps is regretted in two taps. Impulse buying in a chat produces a noticeably higher rate of second thoughts than a checkout that made somebody stop and read, which shows up as refund requests rather than as revenue. The response is not to add friction — it is to describe precisely what is being bought, so that the thing arriving is the thing expected.

help Common questions at this stage