上一期把 Agent 支付的协议地图铺开了。这一期只盯一个点：x402。
不是因为它的数字最大，而是因为它把一个很老的 HTTP 状态码，变成了机器可以消费的支付入口：服务先返回 402，客户端带着支付授权再次请求，服务端再决定是否交付资源。
但这里有一个容易被忽略的边界：x402 先解决"钱怎么发出去"，没有替你解决"这笔钱在业务上怎么算清楚"。
一、先别把交易笔数当成商业规模#
x402.org 页面曾显示近 30 天约 7541 万笔交易、约 2424 万美元结算额。按这个口径平均下来，每笔约 0.32 美元。
另一个公开口径里，XRPL 上累计 1349 万笔交易，对应的 XRP 和 RLUSD 金额却只有约 1.9 万美元等值。两个数字放在一起，第一反应通常是：账对不上。
其实它们未必在说同一件事。
第一，x402 的典型价格就是微支付。API 调用、内容片段和计算任务，单次金额可能远低于传统订单，笔数天然会比金额增长得快。
第二，不同统计把不同链、不同资产和不同时间窗口放在了一起。官网统计更接近协议层面的汇总，单链数据更接近某条链上的实际结算。
第三，公开分析还会区分测试、自成交和协议探测流量。它们能说明协议被调用过，却不能直接等同于真实买家向真实服务商支付的商业收入。
所以这组数字更适合这样读：x402 的协议活跃度已经很高；真实商业结算仍然需要单独核算。
这也是看支付数据时最基本的习惯：先问统计口径，再问金额代表什么。
二、一笔请求到底经过了什么#
x402 的核心不是另造一个收银台，而是利用 HTTP 402 Payment Required，把支付要求放进一次普通的资源请求里。
V2 的请求可以压缩成下面七步：
- 客户端请求资源，例如
GET /weather。 - 资源服务返回 402，并在
PAYMENT-REQUIRED中声明价格、网络、资产、收款地址、scheme 和有效期。 - 客户端选择一个可接受的支付项，用钱包私钥生成支付授权。
- 客户端把授权放进
PAYMENT-SIGNATURE，重发同一个资源请求。 - 资源服务把支付要求和授权交给 facilitator 的
/verify。 - 验证通过后，服务可以交付资源；随后由服务或 facilitator 调用
/settle完成链上结算。 - 结算结果通过
PAYMENT-RESPONSE返回，通常包含支付回执或交易标识。
这里最关键的不是头部字段，而是 verify 和 settle 被拆成了两个动作。
/verify 负责检查授权是否有效、支付条件是否满足、时间窗和 nonce 是否可用。它不等于链上扣款，所以速度更快。
/settle 才是把授权提交到链上。它会受到网络确认、余额变化、nonce 冲突和 gas 等因素影响。
这给了服务方一个工程选择：验证通过就先交付资源，结算异步完成。代价也很清楚：资源已经交付，但结算可能失败。
这不是协议文档里一句"重试"能自动解决的问题。你需要自己定义订单状态、补偿动作、重试上限和人工介入条件。
还有一个常见误解：facilitator 能不能改收款地址、偷偷多扣钱？
在使用带有明确授权字段的支付方案时，授权通常会把金额、资产、收款方、时间窗和 nonce 绑定在签名里。facilitator 负责验证和提交，不能随意改写这份授权。它更现实的风险是不可用、延迟或拒绝服务，而不是凭空改变授权金额。
三、V2 的变化，都是对工程现实的让步#
x402 的早期叙事很干净：无账户、无会话、按请求支付。
但只要真的跑高频服务，这套叙事就会遇到现实。
- 多链：服务和客户端不一定在同一条链上，网络和资产需要明确表达。
- Session：高频请求不可能每次都从钱包签名到链上确认，复用会话是降低延迟和成本的办法。
- Discovery：Agent 需要在运行时找到服务、理解价格和支付条件，不能把所有服务地址硬编码进提示词。
exact/upto：固定价格和上限授权，分别对应一次性计费与按用量结算。
这些能力的共同方向是：把一个"单次转账协议"往可用的服务调用层推进。
但也要留一个边界：协议支持某个支付动作，不代表它替你完成业务计量。
例如 upto 允许服务方在上限内按实际用量结算，但"实际用了多少"怎么证明，仍要靠服务方的计量、日志和双方约定。协议保证的是授权范围，不自动保证计量结果真实。
四、接入 x402 后，哪些模块仍然是你的#
把它放进传统支付系统的模块图里，边界会更直观。
x402 已经覆盖的部分包括：
- 支付触发：HTTP 402 和支付要求。
- 金额表达：价格、资产、网络和 scheme。
- 用户授权：钱包签名替代传统密码或短信确认。
- 清结算：由链上交易完成资金转移。
- 回执：支付响应和链上交易标识。
它部分覆盖的是实时验证。facilitator 可以验证支付授权和可执行条件，但业务风控、用户额度、异常行为和服务权限仍要由接入方判断。
它没有替你完成的，至少有三块：
- 幂等：客户端超时重试时，如何保证同一授权不会被重复处理。
- 对账：怎样把链上交易标识准确映射到你的业务订单、服务调用和收入记录。
- 退款与争议：资源交付失败、计量不一致或用户买错后，谁负责退款，依据是什么。
这三块恰好是传统支付系统里最费时间、也最容易出事故的地方。x402 把支付动作变得更轻，但没有把支付系统的责任一起删掉。
五、微信的做法：复用信封，不替换资金体系#
国内的微信支付 x402 接入，适合用来理解另一种思路：把 x402 当作机器可读的支付入口，资金仍然走原有的法币支付体系。
按照微信支付商户开发文档的接入路径，商户先完成传统的 Native、JSAPI 或 H5 下单，获得预支付标识；再通过 x402 相关接口登记，把预支付结果转换成 Agent 可以消费的支付凭证。凭证通过约定的响应头返回，用户仍然在微信侧完成确认和支付。
这和"把微信支付改成稳定币结算"是两件事：前者是接入格式和调用方式的变化，后者是资金体系的变化。理解这一点，才不会把不同协议的职责混在一起。
六、我会怎样判断它是否适合生产#
如果只是做一个 demo，先跑通服务端中间件、/verify 和 /settle 就够了。
如果要开放真实收费接口，我会先补下面五件事：
- 给每次资源交付建立业务订单和状态机。
- 用授权字段和业务订单共同做幂等判断。
- 把链上交易标识写回订单，并做定时对账。
- 对异步结算失败设置重试、补偿和人工处理路径。
- 在上线前写清楚计量、退款和争议处理规则。
顺序很重要。因为"支付成功"至少有三个不同含义：客户端签名了、链上结算了、业务资源交付了。它们不一定同时发生。
x402 最有价值的地方，是把机器支付的入口标准化了；它最容易被误读的地方，是让人以为支付入口标准化之后，支付系统就完成了。