结算商告诉你"success: true"，但链上交易回执是红色的——别怀疑区块浏览器，链上失败就是失败，结算商那个字段只代表"我尝试提交了"，不是"我确认它过了"。
上个月有个读者跑过来，说用 x402 调了一个付费 API，Binance 的结算接口返回 success=true，还给了交易哈希。他以为万事大吉，结果去区块浏览器一查，那笔交易状态是 reverted。钱没扣成，API 数据也没拿到，两头空。
问题出在对 x402 结算返回值的理解上。success 字段在 x402 协议里有两层含义，你如果只看了第一层，就会踩这个坑。
核心真相：success=true 不等于"链上确认"
根据 Binance 的 x402 文档，/settle 接口的返回分三种情况：
| 返回组合 | 实际含义 |
|---|---|
success=true, transaction= | 链上结算已确认，终态 |
success=false, transaction= | 交易已广播但链上回滚，终态，查 errorReason |
success=false, transaction="" | 广播前就失败了，链上啥也没发生 |
关键在这条脚注：链上失败不会以 HTTP 错误码返回，而是以 HTTP 200 + success=false 的形式给回来。文档特别强调：总是检查 success 字段和 errorReason，别只看 HTTP 状态码。
所以如果你看到 success=true，那说明结算商确认交易在链上成功了。如果看到 success=false 但 transaction 字段有值，说明交易广播了但回滚了——钱没扣，但服务可能已经发出了。
步骤 1：确认你拿到的是哪种"成功"
[做什么] 检查 /settle 或 /verify 接口返回的完整数据结构，不只是看 success 布尔值。
[怎么做]
打开你的代理调用日志，找到结算接口的响应体
定位以下字段：
success: true / falsetransaction: 有哈希还是空字符串errorReason: 有值还是空
[完成标准] 确认你的响应属于以下哪一种：
情况 A：success=true, transaction=0x...→ 链上确认成功，钱扣了，服务应该已经返回了数据。如果数据没拿到，问题在服务端，不在结算。
情况 B：success=false, transaction=0x...→ 交易广播出去了但回滚了。钱没扣，但结算商可能已经错误地把"支付成功"的信号传给了上游，导致你被放行但实际没付钱。如果服务端没有二次校验链上状态，你可能会拿到数据但实际没扣钱——这对服务商来说是损失，对你来说反而赚了。但不应该依赖这种错误路径。
情况 C：success=false, transaction=""→ 广播前就失败了，比如签名无效、余额不足。没有任何链上操作。
步骤 2：如果 success=false, transaction=，去区块浏览器查
这是最容易让人困惑的组合：结算商返回了交易哈希，但告诉你结算失败了。
[做什么] 去对应的区块浏览器查这笔交易的真实状态。
[怎么做]
拿到
transaction字段里的哈希去对应的区块链浏览器（Base 用 basescan.org，Injective 用 injective 浏览器，Stacks 用 stacks.co）查
看交易的
status字段
[完成标准]
如果浏览器显示
Success：结算商的success=false是误报。GitHub 上有个真实案例：sponsor relay 广播了 4 笔交易，全部返回错误，但 3 笔在链上确认成功了。这是状态轮询太快导致的误判，结算商在交易确认之前就查了状态。如果浏览器显示
Reverted：结算商的success=false是对的。交易确实失败了。
高危提醒：x402 协议的一个架构级问题——HTTP 是同步的，区块链是异步的。结算商作为一个中间角色，无法保证原子性：存在"服务已交付但付款未确认"或"付款到账但服务未交付"的双向风险。这意味着，结算商返回 success=false 但交易实际上链成功的情况是真实存在的。
步骤 3：检查结算商代码是否漏掉了关键校验
如果你自己跑的是开源 x402 结算器（比如 Rust 版本的 x402-axum），注意一个已知问题：settlement_to_header 函数在序列化结算响应时，没有检查 SettleResponse.success 字段。即使结算商返回 success: false，paygate 仍然会放行并返回受保护资源。
官方 TypeScript 实现里明确检查了 !settleResponse.success，失败就返回 402。如果你用的实现缺少这个检查，会出现"结算商显示失败，但服务还是给你放行了"的情况，资金没少但数据拿到了——这相当于免费获取了资源，对服务商来说是漏洞。
[做什么] 如果你在跑自己的 x402 服务端，检查结算后的处理逻辑。
[怎么做]
定位
settlement_to_header或等价的序列化函数确认序列化之前有
if (!settlement.success) return 402的检查
[完成标准] 代码里有显式的失败分支，不是把结算响应原封不动塞进 header 就放行。
核验收尾
跑一次完整测试：
用一个余额不足的钱包发起 x402 支付
观察结算商返回：应该是
success=false，transaction可能为空或哈希（取决于回滚方式）检查你的服务端是否返回了 402 而不是 200 放行
检查钱包余额是否有变化——余额不足时不会扣款
核验渠道：
结算响应里的
success字段和errorReason字段区块浏览器上的交易状态
服务端日志里是否有"Settlement failed"相关记录
如果你用的是第三方结算商，就认它的返回值——success=true 就是真成功，success=false 就是真失败，不用自己猜。但别忘了去区块浏览器 double-check 一下，尤其是当结算商给了一个哈希但又告诉你失败的时候。
