交易与证据

一笔付款，应该由什么证据确认

浏览器返回、成功通知和原单查询可能以不同顺序到达。Transact 把它们放回固定的订单与渠道关系中，让一笔付款只形成一份可核对的收据。

先固定原订单，再处理外部结果

一笔付款先由应用身份和商户订单键定位，再固定账户、应付币种与金额等声明。相同键与相同声明可以找回同一记录；使用相同键却改变这些字段，会得到冲突。创建回复丢失时，原应用键仍是恢复入口，不需要猜造新的交易身份。

渠道选择随后固定这笔付款使用的提供方、商户与外部原单。结果核对始终沿用这一绑定。订单金额是整数最小货币单位，展示用的原价只影响呈现；两者不会在收到回调时临时互换。本文依据交易设计讨论处理规则，不陈述实际收款或结算业绩。

成功通知先验证提供方输入，再依据提供方、商户和外部原单的唯一关联找到记录。随后核对原账户、币种与确切金额。商户订单文字或相同金额都不能单独定位一笔跨应用交易；浏览器提供的公开交易标识也不是付款页面的访问凭据。

业务应用读取收据时，还应以自己已经保存的订单声明构造比较上下文。若把待检查收据中的金额和账户复制为“预期”，比较将失去意义。Transact SDK 的原单比较负责字段匹配，应用仍负责据此进行一次履约或记账。

付款后浏览器回到页面，并不证明交易已经完成。用户可以先返回，通知随后到达；也可能通知已完成，而浏览器根本没有返回。二维码或链接到期、未付款查询、未知查询和网络超时，同样不能直接生成成功或确定失败。

页面应展示当前权威查询的结果及其未确认含义。查询不可用时保留未确认，而不是把“没有取得结果”写成“未付款”。终态一旦由规范允许的证据确认，就保留在原订单中，后续页面刷新不再开启它。

设想通知和原单查询几乎同时确认成功。两者进入同一条件事务：第一次完成把原记录设为 PAID，固定确认时间，并更新关联的未完成工作。随后到达的重复完成保留原字段和原时间，不再增加成功金额。收据是这份不可变已付款记录的投影。

把账户标为已付费是另一项需确认的后续责任。Account 暂时不可用，不会撤销已经存在的付款收据。类似地，应用履约也不是浏览器页面的副作用；应用在自己的持久状态中核对原收据并处理重复交付。

创建或查询回复丢失后，先回到原交易服务、原应用身份和原商户键。更换为另一个交易权威，哪怕它信任同一个账户发行者，也不能恢复旧订单。一次查询未找到记录，也不能证明先前或并发的请求从未提交。

付款与出款的后续动作不同。对付款，只有核验通过的收据支持履约；对出款，应用先持有自己的资金预留，再根据匹配原声明的终态结算或释放。PENDING、证据不匹配、缺失和查询不可用，都不能被当成可释放资金的确定失败。

设计中的验证需要让不同账户、币种、金额和商户原单产生可区分的结果，并实际统计渠道提交和条件完成。单独验证一个成功示例无法排除错误订单被完成。