测试版开始 · 说明
Mobazha 交易主线
正确读取一笔交易，并判断哪种状态、证据、策略与角色允许执行下一步。
跟踪订单预计用时9 分钟
适用范围与来源Mobazha v0.3 候选版本
一笔交易，三个状态面
一笔 Mobazha 交易沿着一条稳定主线推进：确认条款、创建订单、建立并验证支付、履约、完成。在当前状态和策略允许时，恢复路径可以分支为取消、拒单、退款或争议。
界面可以把它呈现为一条时间线，但三个状态面必须保持分离：
| 状态面 | 它回答什么 | 权威来源 |
|---|---|---|
| 订单 | 买卖双方承诺了什么，下一步什么动作是合法的？ | 持有订单的 Core 后端及其状态机 |
| 支付会话 | 资金应去哪里、观察到了什么、验证了什么？ | 将订单、报价、支付轨道、观察与验证结果绑定的持久会话 |
| 保护与恢复 | 适用哪一种取消、退款、争议或结算路径？ | 已接受的产品条款、当前状态、角色与有效能力 |
任何一个状态面都不应暗中替代另一个。钱包事件是支付证据，不是订单状态迁移；订单完成本身不说明采用了哪种结算轨道；出现争议按钮，也不代表所有订单都具有相同的保护模型。
正常路径
- 确认条款。 买家检查单个卖家的商品、价格、配送、支付、退款与保护条款；易变值应绑定到报价或等价证据。
- 创建订单。 持有订单的后端分配稳定标识，保存已接受的快照，并准入第一个订单状态。
- 建立支付。 支付会话把订单绑定到收款目标或提供商会话、金额、资产或币种、有效期、确认策略与适用的结算语义。
- 观察并验证。 钱包、链或提供商事件刷新支付信息；Core 评估这些事实，并决定订单能否推进。
- 接受并履约。 卖家只执行当前订单状态和能力所暴露的动作，然后记录发货、交付或自提证据。
- 完成。 后端记录终态业务结果，同时保留对账和恢复所需的绑定关系。
事件用于提示刷新，后端状态才是权威
客户端可能先后收到消息、Webhook、提供商回调或钱包观察，而其他界面尚未同步。应把这些事件当作重新加载相关资源的提示，渲染后端最新的订单和支付会话状态，而不是在本地推断迁移。
这条规则能避免多种危险捷径：
- 不要仅凭交易标识就把订单标为已支付；
- 不要在后端尚未验证时仅凭通知开始履约；
- 不要把“已申请退款”推断成“退款已完成”；
- 不要从“订单完成”推断资金结算已经最终完成；
- 不要脱离当前幂等和状态规则重试受保护命令。
保护是具体产品条款，不是通用徽章
支付轨道和保护模型是两个独立选择。直接观察型支付、类似托管的流程、提供商托管会话可以暴露不同动作；产品条款还会决定谁能取消、资金何时可移动、争议接受什么证据，以及由哪个参与方或机制裁决。
在把一笔交易称为“受保护”之前，需要明确：
- 已接受的订单与支付条款；
- 生效的保护或结算模型；
- 各阶段由谁或什么机制控制资金；
- 可用恢复动作及其时限；
- 适用支付轨道的证据与最终性规则。
Mobazha 应说明这些具体属性，而不是暗示一个笼统的“买家保护”承诺覆盖所有发行版、卖家、支付轨道和订单。
恢复分支保留原始交易主线
取消、拒单、退款和争议不是可以互换的标签：
| 分支 | 通常含义 | 必须检查 |
|---|---|---|
| 取消 | 在适用的承诺或履约边界之前终止订单 | 操作方、当前状态、支付进度与取消策略 |
| 拒单 | 卖家在接受或履约之前拒绝订单 | 卖家权限、原因及所需的支付恢复 |
| 退款 | 已存在支付证据后返还全部或部分价值 | 退款目标、金额、轨道能力、授权与最终性 |
| 争议 | 在适用保护模型下保存并评估冲突主张 | 资格窗口、证据、裁决方、决定与结算影响 |
原始订单、支付绑定和证据仍属于审计轨迹。恢复动作不应制造一段与原交易脱节的新历史。
当前契约与演进方向
| 范围 | 当前公开含义 | 必须标注为方向的内容 |
|---|---|---|
| 订单状态 | Core 持有获准的业务迁移，客户端渲染当前状态 | 更丰富的跨客户端时间线与运营诊断 |
| 支付会话 | 稳定的订单绑定、收款目标或提供商状态、观察与验证相互分离 | 更多支付轨道适配器与恢复自动化 |
| 保护 | 可用动作取决于已接受条款、状态、角色与有效能力 | 更多产品模式、裁决方与证据工作流 |
| 履约 | 配送、自提或其他履约事实只能通过获准动作推进订单 | 更广泛的配送与供应链集成 |
| 自动化 | Webhook 与 Agent 可以观察、准备或请求有边界的动作 | 更多具备策略感知、明确批准和审计的自动化 |
连接后端、适用版本、已接受的交易证据与有效能力仍是可用性的权威。RFC、示意图、配置项或源码包都不会自动启用某种支付轨道或保护模式。