我做了个付费 Telegram bot。Telegram Stars 实际给开发者多少钱，我算了一笔账。

几个月前我上线了一个付费 Telegram bot。没有 Stripe，没有 checkout 页面，没有任何 app store 账号。整个订阅完全跑在 Telegram Stars 上——Telegram 自己的内置虚拟货币。后来收到了挺多问题，最有意思的答案其实是那笔数学账，但没人公开写过。所以我来写。

背景

PolySignal 是一个 Telegram bot，当 Polymarket 上的高水平钱包有新成交时，它会给关注者发提醒。有免费版，也有两个付费档（Signal 150⭐/月，Pro 750⭐/月）。订阅按 30 天循环计费，在 Telegram 里两下就能取消。没有支付服务商，没有收银台流程，连收货地址都不需要填。

如果你从来没在 Telegram 里卖过东西：你错过的是互联网上最干净的支付界面之一。但同时，账本里也藏着一处不太方便的地方。这两件事都值得知道。

用户怎么付钱

Telegram 用户先去买"Stars"——Telegram 内置虚拟货币——通过 Apple 内购、Google 内购，或 Telegram 网页内购。零售价大致是每颗 0.02 美元（比如 75⭐ 卖 1.49 美元，具体看 bundle）。然后用户拿这些 Stars 在付费 bot 里消费。在用户视角里：点一下、确认、用手机上已经绑定好的 Apple/Google 账户付款。没有摩擦。没有"我得去翻卡片"。零字段。

这就是迄今我做过的产品里，全球范围内摩擦最低的订阅支付界面。有些用户能为 PolySignal 付费，但如果让他们走 Stripe checkout，我根本接触不到这些人——同一个 Telegram，从来没输入过卡号，整个流程跟买高级表情包是同一种感觉。

开发者拿到多少

这里才是具体的数学。用户通过 Apple/Google 付款 → Apple/Google 抽 30% → Telegram 再抽一刀 → 剩下的进到你 Telegram bot 的 Stars 余额。之后你用 Fragment（Telegram 自己的市场）把 Stars 提到 TON（TON 是 Telegram 关联的网络代币），再从 TON 换成法币。

业内常引用的开发者端汇率是：约每颗 Star 0.013 美元——这是 Apple/Google 和 Telegram 各自抽完之后，一颗 Star 在开发者手里值多少。

也就是说：

Signal 150⭐/月 → 我大约净拿到 1.95 美元。
Pro 750⭐/月 → 我大约净拿到 9.75 美元。

数字看着小，因为它就是这么小。两点说明：

150 / 750 这两个定价是故意定低的。产品还没被验证，我现在收集的是转化数据；在优化每用户收入之前，我更想先看看到底有没有人愿意转化。Stars 的折算率是固定的，但我自己的零售定价是个旋钮，等我手里有了留存/流失数据再去拧它。
开发者侧的毛利是真实的：约 95%。没有什么值得提的人均基础设施成本，没有客服团队，没有广告预算。问题在量，不在单位经济模型。

提现这一边：Stars 收款不那么方便的部分

下面这部分是给 Telegram Stars 站台的人通常不会说的：真正把钱提出来的过程，本身就是一个故事。

Fragment 是从你 Telegram bot Stars 余额到真实货币之间的桥。能用，但是：

最低提现 1,000 Stars（约 13 美元）。
首次提现要延迟 21 天 — 今天赚到的 Stars，要等三周后才有资格被提出来。
结算用的是 TON，不是美元。 Fragment 把你的 Stars 卖成 TON；接下来你自己把 TON 通过有 KYC 和手续费的交易所换成法币。
Fragment 要求 Telegram 登录 + 一个绑定的 TON 钱包。交易金额到某个阈值之后还会需要身份验证——这块"没有公开文档"，意思就是：你跨过门槛那天就会发现。

如果你之前用惯了 Stripe——每日打款、直接进银行账户、链路里没有任何加密资产——这套东西会让你觉得过于古旧。但如果你本来就在做加密原生业务——TON 完全 OK，就是又一条通道而已。

最诚实的总结是：用户端方便，开发者端不方便。 用户拿到的是一个低到几乎感受不到的支付流程；开发者拿到的是一条加密 off-ramp，第一轮要走三周。

那我为什么还是这么做了

三个原因：

1. 全球触达 + 零合规负担。 我没有公司主体。我没和任何支付服务商打过交道。我没填过一张"请告诉我们你的业务模式"的表。Telegram（连同 Apple/Google）在用户买 Stars 的那个节点上就把消费 VAT 收掉了。我看不到卡数据。我看不到银行账户信息。我也无法对从来没经过我手的东西承担责任。

2. 产品本来就活在 Telegram 里。 PolySignal 的全部用户界面都是 Telegram 消息。让用户跳出 app、去某个第三方页面填信用卡，会是一笔相当重的转化税——而且我的目标用户里有相当一部分在 Stripe 根本进不去的国家。

3. "一个独立开发者能不能做出来"这条门槛异常低。 Telegram 的 Bot API 把 createInvoiceLink 写得很清楚。循环订阅有 subscription_period 参数。自动续费固定按 30 天一档（这点烦人——没有周付、没有年付的循环订阅）。successful_payment 这条 update 会在首次扣款和每个月的续费时各触发一次，并带一个 is_first_recurring 标记。整个计费层加起来大约 200 行 Python。Stripe 会更多。

给同样在考虑这条路的独立开发者一些话

如果你的产品本来就活在 Telegram 里，Stars 是正确的通道。 内嵌支付带来的转化收益，多半能盖过比较麻烦的提现机制。
如果你的产品在 web app 或独立移动 app 里，Stars 多半不值得为它绕个支付弯子。
提现链路（Fragment → TON → 法币）请在没钱进来之前就先打通。等钱已经在账上时才发现要等三周，体验非常糟。
"只能 30 天循环"是一个真实的产品约束。年付计划必须做成一次性扣款，到期后手动延期。提前为这件事在产品上做好设计。
留意用户那边实际被扣了多少。Apple/Google 可以在不改变开发者侧每 Star 折算率的前提下，单方面调整 Stars 的用户零售定价。你在 Telegram 后台看到的数字才是关键。