目前在负责一个聚合支付系统,该系统初期通过项目方式开发,由于前期沟通,开发等原因遗留较多问题,近期将通过一系列反思对项目进行梳理重构,首先梳理支付订单的状态变换,

一笔订单的生命

• 一笔订单生成后首先需要记录在案,这个时候需要记录该订单状态为刚刚创建,还未发起支付
• 订单创建后就要让客户发起支付了,对于聚合支付系统来说,存在多种方式发起支付

对于银行卡支付交易,必须在发起支付前记录为支付中状态
对于微信支付宝被扫交易,必须在发起支付前记录为支付中状态
对于微信支付宝下单交易,由于纯粹的下单交易并无法让客户发起支付,在调用下单接口前后记录为支付中状态均可
总的来说,对支付结果有影响的接口调用必须在调用前将订单状态置为支付中,如果无影响则均可

• 接下来就是支付结果了,成功,失败,但还有一个状态未知,其实状态未知可以归到支付中状态,例如银行卡扣款超时
• 对于通过先下单后支付的订单还存在关闭的可能

订单状态归纳

• 初始化
• 处理中
• 成功
• 失败
• 关闭

针对订单有哪些操作

• 创建一笔订单
• 对一笔订单发起支付
• 关闭订单
• 修改订单状态为支付成功
• 修改订单状态为支付失败

• 创建一笔退款订单
• 发起退款
• 修改退款订单状态为退款成功
• 修改退款订单状态为退款失败

• 创建一笔撤销订单
• 发起撤销
• 修改撤销订单状态为撤销成功
• 修改撤销订单状态为撤销失败

• 订单查询

订单子系统如何与外围子系统交互

事实上我们发现在聚合支付系统中,除了创建订单以及发起支付外,订单最终状态并不由聚合支付系统决定,而是由第三方支付系统等决定,不能因为支付系统发生其他错误时导致订单状态不正确,所以分布式服务的情况下,可以用最终一致性来解决事务不一致产生的问题;因此我们将支付成功,支付失败,退款成功,退款失败,撤销成功,撤销失败等第三方返回的状态从交易中解耦,通过事件来通知订单子系统

对于正向订单其操作及状态转移图如下:

image.png

正向订单操作业务逻辑

• 创建一笔订单
  1. 检查输入参数
  2. 将订单状态设置为初始化并持久化订单数据
  3. 可能的业务异常:订单号重复(ERROR)
• 对一笔订单发起支付
  1. 检查输入参数
  2. 查询订单将订单状态设置为处理中
  3. 补充订单相关数据并持久化
  4. 可能的业务异常:订单已发起支付,不能重复支付(ERROR)
• 关闭订单(幂等)
  1. 检查输入参数
  2. 查询订单并校验订单状态是否可关闭
  3. 将订单状态设置为已关闭
  4. 可能的业务错误:订单已发起支付不能关闭(INFO)
• 修改订单状态为支付成功(幂等)
  1. 检查输入参数
  2. 查询订单并校验订单状态
  3. 可能的业务错误:订单未发起支付不能(ERROR)
• 修改订单状态为支付失败(幂等)
  1. 检查输入参数
  2. 查询订单并校验订单状态
  3. 可能的业务错误:订单已成功或未发起支付(ERROR)
• 修改订单状态为已关闭(幂等)
  1. 检查输入参数
  2. 查询订单并校验订单状态
  3. 可能的业务错误:订单已成功或失败不能关闭(ERROR)