Which payment rules apply to what you sell?
Telegram’s official guidance requires Telegram Stars for digital goods and services sold inside Telegram apps. Physical goods and services follow a different payment framework, with its own providers and requirements. That is why the product category comes first: choosing a payment provider before you know which rules apply can mean redoing the work later. If you sell both kinds of product, plan two separate routes from the start; forcing them into one checkout tends to cause problems later. We plan both routes at the start of every Telegram ecommerce bot project.
Describe the offer in plain terms. What does the buyer actually receive: access to material, a subscription, a physical item, a booked service? Who delivers it, and how: automatically in the bot, by a member of your team, or through a delivery service? Then check the current documentation for that exact offer and for the environments where you plan to sell.
The rules change over time, so treat the official pages as the source of truth, not older articles or advice carried over from other projects. Note the date you last checked them, so your team knows when it is time to look again.
How should an order move from payment to delivery?
Keep an explicit order record with clear statuses: created, awaiting payment, paid, fulfilled and, where needed, refund requested or refunded. Each status should have a precise meaning that the whole team, from developers to support staff, understands in the same way. Write the statuses and transitions down in one place, for example in a simple table showing which event moves an order from one status to the next and what triggers it. That table becomes the reference for developers, testers and support alike, and it makes gaps easy to spot, such as a status that nothing ever leaves.
Grant access or start fulfilment only after verified payment confirmation, not because the customer has returned from the payment screen. Test what happens when the same payment notification arrives twice, and when a customer closes the payment window and comes back later. The order should still end up in the right state, with exactly one entitlement or one shipment.
Decide how the system handles uncertain situations, for example a payment that has been confirmed but not yet matched to an order. Support staff should be able to see the order’s history and status without access to payment details they do not need.
What should you test before taking real payments?
Before launch, give customers a clear way to contact support and make sure they receive the purchase information they need. Then test every route: a successful payment, a cancelled payment, a failed payment and the most awkward case of all, where the payment went through but delivery was interrupted.
Decide who handles refunds and who talks to the customer, following the platform’s current process for your type of product. Keep payment records and order records consistent, so that any transaction can be traced to the order it paid for and back again.
A screen that says “Paid” is not enough to show that the customer actually received what they paid for. Testing is complete only when you can follow one purchase from payment to granted access or a dispatched parcel, and you know what to do if any step in between fails.
Checklist: payments and orders
- Decide whether you sell digital or physical goods and check the current rules for that case.
- Define the order statuses and what each one means.
- Grant access or start fulfilment only after verified payment confirmation.
- Test duplicate notifications, cancellations and interrupted delivery.
- Settle refunds, support and the reconciliation of payments with orders.
Example: paid access to learning material
A buyer pays for access to learning material inside Telegram. The verified payment event moves the order to “paid” and activates access exactly once, even if the notification is delivered again. If access is not granted because of a technical failure, support can open the order, see what happened and either restore access or start the refund process.
