摘要

  • RFC 3538 把 20、40、60、80、100 分别配置给一连串 SET 消息的生成或处理节点；这些数字衡量的是 IOTP 桥内的接口进展，不是商业交易已经完成的百分比。
  • 进度到 100 时，PRes 可能只表示授权获批，也可能表示扣款成功；CompletedOK 之后还可因取消转成 Failed，而结算与实体交付从未进入这只仪表的证明范围。

设想值班人员看见支付面板亮起满格。他可以确定什么？请求得到授权了吗，资金已经扣取了吗，银行间已经结算了吗，仓库已经发货了吗，状态再也不能撤销了吗？在现代产品语言里，这些事实常被一个“完成”吞并。2003 年 6 月以 Informational 身份发布的 RFC 3538，却给出更克制的答案：SET 与 IOTP 之间的桥已经处理到最后一个被映射的消息。

IOTP 试图为网络贸易提供共同结构，同时允许具体支付方案经由 Payment API 运行。RFC 3538 的任务，是把 Secure Electronic Transaction 的消息、状态和错误嵌入 IOTP 1.0。冻结的来源没有证明它获得了多大部署，也没有一笔具名交易可供复盘。因此，文章不能把接口设计写成商业胜利。它真正留下的历史价值，是让局部状态只对局部机制负责。

第 8.12 节列出的进度表十分具体。第一个 SET Initiation Response 被生成或处理后，PercentComplete 设为 20；PinitReq 对应 40，PinitRes 对应 60，PReq 对应 80，PRes 对应 100。Consumer 与 Payment Handler 从相反方向观察生成和处理。初始阶段的消息数量还可能变化，但第一次响应仍被记为 20。由此可见，这些比例不是等量劳动，也不是剩余时间估计，而是设计者选择的五个接口路标。

最末一个路标甚至具有两种业务含义。桥处理 PRes 时，一条成功路径是 authorizationPerformed 加批准的授权码；另一条是 capturePerformed 加成功的扣款码。授权允许交易继续，扣款则是另一商业阶段。两者可以共享同一种消息外壳和同一个 100，却不能被写成同一事实。满格证明桥走到了 PRes，而不是证明每次都发生了同一种资金动作。

状态机继续拆穿“终态”这个词的诱惑。在 Payment Handler 一侧，运行中的 SET 交易可以进入 CompletedOK。但 RFC 3538 也明确允许取消支付时，通过变更状态或 CancelPayment 将 CompletedOK 转为 Failed。状态是在某个时刻、某个组件内成立的记录；如果系统只保存最后的漂亮标签而丢掉转换边，就会把可逆检查点伪造成不可逆终局。

收据接口把边界说得更尖锐。CheckPayReceipt 并不会特别核验 Payment Receipt Information；只要请求消息有效，它就发送一般响应。这可以完全符合 API 分工，却不能被产品界面改名为“商业事实已核验”。请求结构有效、收据容器可识别、底层主张经独立证实，是三张不同的凭证。

交付也没有被支付桥吞并。对于实体商品，文档建议省略 IOTP Delivery Exchanges；系统可以留下交付查询位置，而 Payment Handler 与 Delivery Handler 之间的信用授权查询可在 IOTP 之外处理。对于数字商品，文档建议实时授权。前者不是说交付不重要，恰恰是承认交付有自己的所有者和证据。支付消息走完，既不会搬动包裹，也不能证明数字内容已抵达读者。

查询与错误同样保持分层。SET Inquiry Initiation 被省略，请求和响应则嵌入 IOTP 的 payment-scheme data。桥接技术错误使用 HardError；业务失败通过另一条路径表达，包括 PRes 中的状态。若监控系统丢掉错误来源，正常传输的拒绝会被误报为桥损坏，技术上顺畅的消息又可能被误判为交易成功。

这一主轴不重复既有的 RFC 3354 文章，后者拥有 IOTP v2 需求与协议组合/商业授权边界；也不重复 RFC 3504 文章对语法修正、交易身份、查询以及支付/结算/交付总体分离的讨论。RFC 3538 的独占材料是更具体的仪表盘：五段比例、末消息的双重含义、收据检查的有限范围，以及“完成”后的取消边。

设计规则由此非常朴素：任何进度数字都必须公开自己的分母。保存具体消息、生成或处理它的主体、消息内的 completion code，以及之后每一条状态转换。做到这些，100 才是一份有用证据；否则它只是一个能从未测量事件那里借来确定感的符号。

来源