面向 B2B 的 Telegram Stars API：销售 Stars 与 Premium
如果您的产品已经拥有客户、结账流程或 Telegram 受众，就无需另行建设履约体系来销售 Telegram 数字产品。MyStars Fulfilment API 让您的后端能够为交付至 Telegram @username 的 Telegram Stars 和 Telegram Premium 创建并跟踪订单。
这使其非常适合经销商、Telegram 机器人和 Mini Apps、创作者平台、礼品服务、忠诚度计划、代理商、交易市场，以及希望在不让每位客户进入人工支持流程的情况下增加 Telegram 购买入口的产品。
谁适合使用 Telegram Stars API？
当 Stars 或 Premium 是您所售产品的一部分时，Telegram Stars API 才适合您；它并非供团队偶尔手动购买使用。
典型的 B2B 实现场景包括：
- 经销商店铺，可将 Stars 套餐或 Premium 时长与其他数字商品一同销售；
- Telegram 机器人和 Mini Apps，收集用户名、展示当前报价，并将订单提交给后端；
- 创作者与社区平台，帮助受众在付费帖子、机器人功能或 Premium 体验前完成充值；
- 礼品与忠诚度产品，将活动奖励转化为发给指定收件人的 Telegram Stars 或 Premium；
- 代理商与托管服务，需要可重复的履约流程，而非人工处理每一项客户请求；
- 交易市场，需要可审计的订单记录，并在交付完成时接收事件。
API 是一层履约能力，而不是前端小组件。您的产品负责客户体验、结账流程和商业规则；您的服务器则使用 MyStars 进行报价、验证、创建、支付和对账，以完成 Telegram 履约订单。
可以通过 MyStars API 销售什么？
当前产品目录支持两类产品：
- Telegram Stars — 订单使用 Stars 数量；
- Telegram Premium — 订单使用按月计算的 Premium 时长。
Stars 和 Premium 对应不同的购买需求，因此应在 UI 中分别展示。Stars 是可供创作者、频道、机器人和数字商品使用的 Telegram 消费余额；Premium 则是送给 Telegram 账户的订阅礼品。如果客户是在比较 Premium 方案而不是集成 API，请引导其前往 Telegram Premium 结账页面。
不要在客户端应用中硬编码套餐数量、方案时长、币种或价格。MyStars API 文档 提供实时的产品、币种和定价数据，帮助您的目录始终遵循当前 API 规则。
如何通过 API 销售 Telegram Stars：B2B 履约流程
一套可靠的集成流程并不长，但每一步都需明确设计。订单应在您的后端创建；客户不应看到 API 密钥，也不应处理本应由您的服务负责的链上支付指令。
- 加载当前目录和支付币种。 在集成启动时读取可用产品和币种，并按合理频率刷新。这可避免旧版应用仍展示不可用选项。
- 请求实时报价。 向定价端点传入所选产品、数量或时长以及支付币种。应以返回金额作为结算金额，不要根据缓存汇率自行推算价格。
- 在扣款或创建订单前检查收件人。 将收件人的 Telegram
@username和所选产品发送至收件人检查端点。Stars 收件人检查与 Premium 资格检查不可互换。 - 创建一笔幂等订单。 提交所选产品、收件人、支付币种、使用 Webhook 时的回调 URL，以及根据内部订单 ID 生成的稳定
Idempotency-Key。 - 严格执行返回的支付指令。 订单响应包含目标地址、金额、备注、链和有效期。您的支付服务必须原样使用这些值，而不是使用应用配置中保存的钱包地址或备注。
- 对最终交付状态完成对账。 将订单状态端点轮询作为兜底，或通过 Webhook 接收最终状态。只有在满足您的对账规则后，才将客户订单标记为完成。
这套流程正是 B2B Telegram Stars API 集成区别于普通购买链接之处：每一步都可被存储、安全重试、监控，并由产品团队提供支持。
后端应保存的数据
面对客户的订单应以您的数据库为唯一事实来源。保存足够的信息，才能向支持团队解释订单、重试安全操作并对账链上支付，同时不暴露任何密钥。
至少应保存：
- 您的内部订单 ID 和 MyStars 订单 ID；
- 创建该订单时使用的幂等键；
- 产品类型、Stars 数量或 Premium 时长，以及收件人用户名；
- 报价币种、金额、链、有效期和支付备注；
- 结算后的链上交易哈希；
- 您的支付状态、MyStars 订单状态、Webhook 载荷或轮询时间戳，以及最终履约结果。
Idempotency-Key 很重要，因为真实系统会重试。POST /v1/orders 之后发生网络超时，并不能证明什么都没有发生。使用同一稳定键重试，可让后端恢复处理，而不会为同一笔客户购买创建第二笔履约订单。
Webhook、轮询与订单生命周期
客户可能先向您的产品付款，随后您的服务才结算 MyStars 的支付指令。这会产生三个不应混淆的运营状态：
- 客户已支付您的产品；
- 您的服务已为 MyStars 订单发起链上支付；
- MyStars 已向 Telegram 收件人交付 Stars 或 Premium。
订单创建后可能以 awaiting_payment 状态返回，并附带支付信息和有效期。随着结算与履约推进，系统需要可靠地获取最终结果。
日常交付更新应使用 Webhook 回调，同时保留状态轮询作为恢复路径。确认传入的 Webhook 请求由后端接收并处理，将其与 MyStars 订单 ID 关联，并让 Webhook 处理本身也具备幂等性。重复回调不得发放重复奖励、开具第二张收据，或触发第二套退款流程。
支付结算：GRAM (TON) 与 TON 上的 USDT
MyStars API 订单可使用 GRAM (TON) 或 USDT (TON) 结算。这属于后端支付操作，不能不加判断地复制到客户端结账界面。
对于每笔订单，都应从 API 响应读取返回的币种、链、地址、金额、备注和有效期。不要复用上一笔订单的支付详情。金额、备注、网络错误，或支付指令过期，都可能导致对账失败。
钱包签名和 API 调用应始终留在服务器端。切勿将 X-Api-Key、钱包助记词或自动结算凭据放入浏览器包、Telegram Mini App、公开代码库或客户端日志。
无需买家 KYC：准确的 B2B 含义
“无需买家 KYC”是一个常见搜索词，但必须准确理解。在此流程中，MyStars 履约结账不要求买家上传身份证明文件，可降低产品体验中的摩擦。
Telegram Stars 经销商 API 集成上线清单
在向客户开放这一功能前，请确认以下事项：
- API 密钥仅存放在服务器端的密钥管理系统中，并可轮换；
- 产品和币种选项来自实时 API，而非硬编码值；
- 在创建订单和最终向客户扣款前，均已执行收件人检查；
- 每笔订单都有稳定的内部 ID 和幂等键；
- 支付使用该订单返回的准确地址、金额、备注、链和有效期；
- 所有出现 USDT 的位置均标注为仅限 TON；
- Webhook 处理会验证、关联、记录并安全去重事件；
- 轮询可覆盖漏收或延迟的 Webhook；
- 支持团队可通过您的 ID、MyStars 订单 ID、收件人和交易哈希定位订单；
- 在上线前已明确退款、欺诈、合规与客户沟通规则。
有关请求格式、响应字段、SDK 选项和实时 API 合约，请以 MyStars API 文档 作为实施时的权威来源。
常见问题
我能否通过自己的网站、机器人或 Mini App 销售 Telegram Stars？
可以。您的产品可以收集客户的选择和收件人用户名，后端再通过 MyStars Fulfilment API 创建并跟踪 Stars 订单。请将 API 密钥和结算操作保留在服务器端。
能否通过同一 API 销售 Telegram Premium？
可以。API 将 Telegram Premium 作为独立产品类型进行履约，Premium 时长按月计算。创建订单前应检查收件人资格，因为 Premium 礼品限制可能不同于 Stars 收件人检查。
API 是否提供 Stars 和 Premium 的固定价格表？
应使用定价端点获取实时报价，而不是依赖固定价目表。对于所选订单，API 响应才是当前金额和结算币种的恰当依据。
如何避免创建重复的 Telegram Stars 订单？
创建每笔订单时，都使用与内部订单 ID 绑定的稳定 Idempotency-Key。如果服务器工作进程因超时重试，请复用同一密钥，而不是生成新密钥。
支持哪个 USDT 网络？
仅支持 TON / The Open Network 上的 USDT。 不要发送或展示其他网络上的 USDT，将其作为兼容的结算方式。
无需买家 KYC 是否意味着企业没有合规义务？
不是。它描述的是 MyStars 买家结账体验，并不免除贵公司的法律、财务、反欺诈、税务、制裁、消费者保护或退款责任。
开始 B2B Telegram 履约集成
如果您的产品需要规模化销售 Telegram Stars 或 Premium，请围绕可验证的订单生命周期构建：实时报价、收件人检查、幂等订单创建、准确的链上结算，以及最终的 Webhook 或状态对账。
来源与依据
- MyStars FaaS — Fulfilment API 文档：产品目录、实时报价、收件人检查、订单创建、API 身份验证、结算指令、状态跟踪和 Webhook。