支付成功≠交易完成：分布式商务状态模型

支付 API 返回成功，界面变成绿色，所有人都松了一口气。

但究竟是什么成功了？

支付通道可能已接收或结算了款项，但商户从未收到回调。库存可能仍未提交。选中的规格可能已变更。履约可能尚未开始。买家或 Agent 可能正盯着一个超时画面，正在决定是否重试。

在分布式商业系统中，支付成功是一个事实。交易完成则是一条由不同系统和不同人各自掌控的事实链。

绿色对勾掩盖了多个时钟

一个有用的商业状态模型至少要分离以下阶段：

intent
  -> authorization
  -> payment attempt
  -> payment outcome
  -> merchant acknowledgement
  -> order acceptance
  -> fulfillment
  -> delivery / return / dispute

这些阶段并非在同一个时钟上推进。

支付通道知道资金是否已流动。

商户知道自己是否接受了商业义务。

库存系统知道具体的商品和规格是否已提交。

履约系统知道发货是否已开始。

买家知道收到的结果是否与已批准的内容相符。

将它们 Collapse 成 paid=true 会制造一种危险的歧义：没有人能说出谁拥有下一个操作的所有权。

超时是一种状态，而非重试的许可

假设一个 Agent 提交了支付，但连接超时了。至少存在三种可能：

支付在到达提供商之前就失败了。

支付成功了，但响应丢失了。

提供商接受了它，但最终结算仍在等待中。

盲目重试可能产生重复扣款。盲目宣告失败则可能使已付款的买家得不到确认的订单。

正确的响应通常是 outcome_unknown，随后进行确定性对账。系统应使用相同的幂等键查询权威支付记录，将其与已批准购买意图进行比较，然后精确一次地推进商业状态。

收据应将意图与责任连接起来

仅靠模型生成的句子是不够的。一次可恢复的交易需要一个紧凑的机器可读记录，例如：

{
  "intent_id": "intent_123",
  "idempotency_key": "checkout_123_attempt_1",
  "approved": {
    "seller": "seller_42",
    "item": "sku_7",
    "variant": "green-8-pack",
    "currency": "USDC",
    "maximum_total": "18.29",
    "destination": "SG",
    "terms_version": "terms_2026_08_29"
  },
  "payment": {
    "state": "confirmed",
    "authoritative_reference": "rail_ref_456"
  },
  "commerce": {
    "merchant_acknowledged": false,
    "inventory_committed": "unknown",
    "fulfillment": "not_started",
    "next_owner": "merchant_reconciliation"
  }
}

这是一个说明性的架构模式，而非 WebAZ API 响应。它的重要特性是支付与商业保持分离，同时记录标识了已批准的内容以及谁必须采取下一步行动。

Agent 使这个边界变得更加重要

人类已经会误读绿色对勾。Agent 则会增加重试、工具链和压缩摘要。

因此，一个对 Agent 安全的商业工作流应该：

将批准绑定到确切的卖家、商品、规格、货币、最高总金额、目的地方和条款版本；

在第一次外部写操作之前分配幂等键；

将超时表示为 unknown，而非 failed；

在重试之前与权威通道进行对账；

保持支付、订单和履约状态独立可见；

命名拥有下一个操作的系统或人员。

Agent 可以准备和解释。它不应该重新解释批准或虚构完成。

当前的一个 WebAZ 示例

WebAZ 目前暴露两个具有不同托管模式的实时结算通道。

使用 Direct Pay，支付在平台外从买家流向卖家。WebAZ 不持有本金。WebAZ 不验证收款人或支付方式，不保证支付，也不发出卖家的退款。它记录订单状态、确认、支付指令快照和证据，以便后续流程保持可追溯。

对于符合条件的 USDC 订单，真实资金被锁定在一个不可变的 Base-mainnet 托管合约中。合约受运行时限制，每笔订单有上限，尚未进行第三方安全审计。链上支付或释放仍然不能证明交付；结算和履约仍然是不同的状态。

公开 WebAZ 启动 pulse 报告了 2026 年 8 月 29 日 08:41 UTC 时完成了 37 笔订单和解决了 15 起争议。这些是有日期的协议计数，而非声称上述每种失败模式都发生在 WebAZ 上。

从你自己的系统中选取一个失败或模糊的结账流程，回答五个问题：

最后的权威事实是什么？

哪个状态仍然未知？

重试安全吗，如何证明？

谁拥有下一个操作？

什么证据能让买家、商户和运营者在事后重建这个决策？

如果答案只是"支付屏幕是绿色的"，那么这笔交易对于 Agent 来说还不够清晰。

支付成功很重要。但一个可信的商业系统也必须解释接下来发生了什么。

WebAZ 协议状态：https://webaz.xyz/.well-known/webaz-protocol.json