数据模型 - 状态

交易状态概述

交易状态数据模型定义了交易生命周期状态信息的结构。此模型封装了支付交易的状态跟踪、监控和状态管理。

状态代码定义

状态代码	描述
INIT	交易请求已注册但尚未指定支付方式 用途：订单创建但客户尚未选择支付方式时的初始状态 下一状态：PROCESSING（支付方式选择后）
PROCESSING	交易正在积极处理中 用途：客户支付待处理或订单正在由支付提供商处理 下一状态：SUCCESS、FAILED、EXPIRED
SUCCESS	交易已成功完成 用途：支付已收到或发放已完成 下一状态：最终状态 - 无进一步转换
FAILED	交易已失败并达到终止状态 用途：由于各种原因支付处理失败（资金不足、技术问题等） 下一状态：最终状态 - 无进一步转换
EXPIRED	交易由于超时或不活动而过期 用途：在指定时间限制内未完成支付或互联网连接超时 下一状态：最终状态 - 无进一步转换

交易生命周期流程

初始化阶段

INIT → PROCESSING

• 触发: 客户选择支付方式
• 持续时间: 立即转换
• 操作: 支付方式验证和处理启动

处理阶段

PROCESSING → SUCCESS/FAILED/EXPIRED

• 持续时间: 根据支付方式和处理时间而变化
• 操作: 支付处理、客户交互、提供商通信

最终状态

• SUCCESS: 交易完成，资金已转移
• FAILED: 由于失败而终止交易
• EXPIRED: 由于超时而终止交易

实现示例

{
  "tradeNo": "122200312406111311517153",
  "orderNo": "200110edbb466abb04682968b40",
  "status": "SUCCESS",
  "transactionTime": "2020-12-17T10:55:00-05:00"
}

状态监控和处理

实时状态更新

• Webhook通知: 通过回调URL自动状态更新
• API轮询: 使用查询API定期状态检查
• 状态同步: 所有系统组件的一致状态

错误处理

• FAILED状态: 实施重试机制和错误日志记录
• EXPIRED状态: 处理超时场景和用户通知
• PROCESSING状态: 监控卡住的交易并实施超时

业务逻辑

• 订单管理: 根据交易状态更新订单状态
• 库存管理: 在FAILED/EXPIRED时释放保留的库存
• 客户通信: 为每个状态发送适当的通知

地区考虑

处理时间

• 数字钱包: 通常1-5分钟完成SUCCESS
• 银行转账: 1-3个工作日完成
• 现金支付: 支付确认后立即
• 加密货币: 根据网络10-60分钟

状态可靠性

• 高可靠性: SUCCESS和FAILED状态是确定的
• 中间状态: PROCESSING可能需要额外验证
• 超时处理: 放弃交易的EXPIRED状态

安全和合规

状态验证

• 防篡改: 状态变更必须经过加密签名
• 审计跟踪: 所有状态转换的完整日志
• 验证: 与支付提供商确认交叉引用状态

监管要求

• 交易报告: 监管合规的准确状态报告
• 争议解决: 退单处理的清晰状态文档
• 结算对账: 基于状态的结算处理