Comparison
Stars or Stripe, decided by price point and what you sell
Telegram Stars require no merchant account and convert better at low price points because checkout is one tap. Stripe settles to your bank, supports any product category, and wins as amounts rise. Stars may not be used for physical goods, which decides it outright for many businesses.
Stars or Stripe, decided by price point and what you sell: the decision in facts
- Compared against
- Stripe
- Dimensions compared
- 8, including merchant account and checkout friction
- Where we lose: Category breadth
- Stars cannot touch physical goods
As of 2025-10-01, Telegram Bot API 13.4
What is actually being compared
The instinct is to compare rates, and rates are the least useful input here. Telegram retains a share of Stars revenue and Stripe charges a percentage plus a fixed fee, and comparing those two numbers ignores the variable that dominates the outcome at small amounts, which is completion.
At two or three dollars, a card checkout is brutal. The customer has to find a card, type it, possibly complete a 3-D Secure challenge, and they are doing all of that for an amount smaller than the effort feels worth. A meaningful share abandon. A Stars purchase is one tap against a balance they already hold, and the difference in completion at that price point swamps any rate difference.
As the amount rises the arithmetic inverts. At a hundred dollars the customer is willing to find their card, so the completion advantage shrinks, while the take rate applies to a much larger number. Somewhere between those two the lines cross, and where exactly depends on your audience and your product. The one thing that is not a judgement call is category: Stars are limited to digital goods and services, and selling anything physical through them is a policy breach that risks the bot.
Side by side
| Dimension | Stripe | A custom build |
|---|---|---|
| Merchant account | Required, with entity and category review that can decline you. | None. Telegram is the merchant of record. |
| Checkout friction | Card entry, possibly a 3-D Secure challenge. | One tap against an existing balance. |
| Product categories | Broad, with a published prohibited list that excludes crypto. | Digital goods and services only. Physical goods are not permitted. |
| Settlement | To your bank account on a predictable schedule. | Telegram payout, with its own thresholds and timing. |
| Effective cost | Percentage plus fixed fee. The fixed fee dominates at small amounts. | Telegram's share. Usually better at small amounts, worse at large ones. |
| Refunds | Full control, any time, through the API. | Through the Bot API within a limited window. |
| Disputes | Chargebacks exist, with evidence submission and real exposure. | No chargeback mechanism. Refunds are the only remedy. |
| Reach | Anyone with a card. | Telegram users with a Stars balance or willing to top up. |
Which one fits your situation
Choose Stripe when
- You are selling anything physical. Stars are not permitted and this decides it before anything else.
- Your price point is high enough that the take rate dominates the conversion advantage.
- You need funds in an operating account on a predictable schedule.
- You are selling outside Telegram as well and want one payment rail across both.
- Chargeback exposure is something you would rather manage than avoid, because the customers are worth it.
Choose a custom build when
- You are selling digital goods, access or subscriptions inside Telegram.
- Your price point is low enough that checkout friction is the binding constraint on revenue.
- You cannot get a merchant account, or the underwriting timeline would kill the project.
- Your buyers are already in Telegram and already hold or will top up a balance.
- You want to launch this month rather than after an underwriting process.
Where we lose
- Category breadth. Stars cannot touch physical goods, and no amount of framing changes that.
- Settlement predictability. Stripe pays into your bank on a schedule your accountant recognises; Stars payout has thresholds and timing that suit a creator better than a business paying suppliers weekly.
- Reach. A card works for anyone; Stars require a Telegram account and a balance, which is a wall rather than a step for a general audience.
- Cost at scale. Above a certain price point the take rate makes Stars straightforwardly more expensive, and pretending otherwise would be dishonest arithmetic.
If you are already on it, how the move works
Split the catalogue by category first
Digital goods can use Stars; anything physical cannot. That line is not negotiable and it usually determines that the answer is both rather than either.
commandsModel completion, not just rate
Take your current card checkout completion at your actual price point. The Stars case rests on that number improving, and if you do not have it the comparison is a guess.
payments-apiModel entitlement independently of the rail
What the buyer gets and for how long, expressed once. Both rails then grant the same entitlement, so a customer's access is correct regardless of how they paid.
starsOffer both at the boundary and measure
For products where either could apply, present both and watch what people choose. Buyers reveal the crossover point faster than modelling does.
payments-apiKeep refund handling consistent across both
Different windows and mechanisms, one customer-facing policy that is true for both. A policy that only holds on one rail is a complaint waiting to happen.
stars
Questions people ask when deciding
Which is actually cheaper?
At low price points Stars usually win once completion is included, because a one-tap checkout converts far better than card entry for a two-dollar purchase. At higher amounts Stripe wins because the take rate applies to a bigger number. The crossover depends on your audience and is worth measuring rather than assuming.
Can we sell a physical product through Stars if we call it something else?
No, and framing it as a digital voucher is worse than doing it openly because it demonstrates awareness. The policy is about what the buyer receives, and the consequence lands on the bot rather than on the transaction.
Do we have to choose one?
No, and most catalogues with both digital and physical elements must not. Model the entitlement independently of the payment rail and both can grant the same access, which is also what keeps refunds coherent.
What about chargebacks?
Stripe has them, with evidence submission and real exposure. Stars have no chargeback mechanism, so refunds are the only remedy — simpler for you and less protective for the buyer, which is worth being straightforward about in your terms.
How quickly do Stars funds reach us?
On Telegram's payout schedule and subject to its thresholds, which suits a creator better than a business paying suppliers weekly. If cash flow timing matters, that is a genuine argument for a conventional processor.
What if Stripe declines our category?
Then the comparison is already over for anything Stripe would have covered, and the question becomes Stars for the digital part and a regional gateway for the rest. Confirming category acceptance before committing is worth doing first.
Related reading
The policy limits and the pre-checkout latency budget are covered in the Telegram Stars integration.
Category acceptance and webhook handling are covered in the Stripe integration.
Entitlement modelling across both rails is described in the Stars payments build.
Where the third option is a chain rail, see the TON comparison.