thirdweb x402：给 API 收费，先分清授权与结算

一个文档分析 API 在读完文件之前，不一定知道最终需要多少计算量。固定收费容易实现，但短文档可能多付，长文档又可能让服务商承担额外成本。理解 thirdweb x402，可以从这个具体计费问题开始。

核对范围： 2026 年 11 月 1 日查阅官方文档，没有连接钱包、执行支付或测量性能。下面讨论接入设计，不是产品实测。

先选计费方式，再接中间件

服务端文档区分 exact 与 upto：前者按指定金额收费，后者允许在授权上限内结算，且授权有效时可以多次结算。对用量不确定的任务，文档把事前验证和事后按实际用量收费分开。

对于文档 API，上限应该在处理前展示。用户同意一个最高金额，不等于每次都应扣满。服务端需要能够复核的计量记录，例如输入规模、完成工作量，以及用量如何换算成费用。付款后临时生成一段解释，不能代替账单依据。

这条流程有两道不同的关口

依据服务端文档绘制的 upto 概念流程，非真实支付。结算失败时如何交付，需要服务方另行定义。

验证让服务端判断能否开始昂贵的工作，结算才回答付款到了什么状态。任务记录要保留两者。如果分析完成但结算失败，应保存结果、核对付款，再决定用户如何取回结果。直接重跑分析，可能只是再次消耗算力，并没有解决原来的收费问题。

“成功”取决于等待到了哪一步

Facilitator 文档提供 simulated、submitted 和 confirmed 三种等待模式。模拟成功不是钱已到账，提交交易也不等于链上确认。文档默认等待确认，但接入方可以选择其他模式。

应用应把所选状态写进后端支付约定。对于昂贵且无法收回的结果，仅接受模拟，与对低成本缓存结果接受已提交交易，承担的风险不同。这是运营决策，不能一概以速度优先。出现争议时，客服应能查清该请求当时采用哪一种模式。

业务事件	建议保留的证据
买方接受上限	资源、网络、资产、最高金额与到期时间
服务执行工作	任务编号与可复核的计费用量
支付被处理	Facilitator 返回结果与相关链上交易
结果完成交付	关联同一任务的响应或取回记录

兼容性要落实到具体配置

产品概览介绍了围绕 x402 的客户端与服务端，以及满足相应授权机制的支付代币。不能据此认定所有宣传支持的网络上，每种代币都能互换使用。Facilitator 提供支付方式查询；接入时应核对具体网络和资产，而不是只看支持链数量。

我们建议同时确认协议版本、付款请求头、支付方案与买方签名能力。只理解固定金额 exact 的客户端，未必支持 API 期待的按量结算。遇到不支持的组合，应明确报错，避免不断返回一份买方无法完成的付款要求。

适合用来解决什么

thirdweb 是发布付费资源、或在应用中消费这些资源的一种实现选择，并不是与 x402并列的另一套独立协议。Facilitator 处理付款，也不能证明购买的结果正确。

上线前值得验证：长任务执行中授权到期、并发调用共同消耗额度、付款后响应丢失，以及客户端重复请求。这里列的是建议验收项，没有声称已经测过。可结合 thirdweb 资料页记录技术选择；比较供应商时，先对齐计费和交付语义，再比较快速入门需要多少代码。