电商在线支付场景下的订单取消与自动取消业务细节

订单取消与订单支付的数据一致性问题探讨

业务引发的流程缺陷

电商项目中对接三方在线支付有支付宝、微信支付。业务是
越做越深入，越做越复杂。相信我，这是必然的规律。所有的业务没有
一上来就羽翼丰满，通常随着时间慢慢发展，逐渐增加这样那样的需
求，而作为开发出身的人，深知每一次需求变更都将是对技术和业务分
析的一次大考。一般牵一发而动全身。

一开始在线支付业务不是先天需求，而是由订单业务模块催生出来的场
景。尤其是在B2B业务中，订单支付一般走对公，要么是走线下，当然
如果有在线支付自然是锦上添花，但不是雪中送炭。因为增加一种需求
必须完整的考虑所有可能出现的业务缺陷，尽可能使所有业务分支形成
闭环。

在线支付，往细节分析，不仅要实现“统一下单”、支付发起、支付超时、支付取
消、重新支付、支付查询、支付回调、这些常规操作，还需要将这些操作融合到订
单业务的各个状态中，可以说围绕订单的生命周期，在线支付是穿插和环绕展开
的。

订单状态与支付的关系

订单状态粗略按照：提交订单（待支付）、取消（未支付取消、已支付取消）、
订单已支付、订单捡货、订单发货、订单已签收、订单完成、
订单退款（部分退款、全部退款）、订单退货（整单退货，部分退货）、
订单换货（整单换货、部分换货）

当然各家做电商系统订单状态基本类似，自然也存在着不同之处。这里拆开每一种
状态都有非常多的业务细节在里面。
我们本文要分析的是订单取消状态与在线支付业务的关联性，和普遍的可见业务场
景。
支付状态简单来讲介于待支付和已支付两种，如果要问支付中算不算一种独立的状
态，从技术角度分析是这样的，也是存在的。
不过我们将支付状态与订单状态设计到同一张数据库表order表中需要多个字段来描
述业务中出现的各种数据状态。

支付宝与微信在线支付过程分析

参见第下图中的支付过程拆解。用户在页面中点击支付按钮的直接感官是一步完
成的。实际开发过程中与支付宝、微信对接需要两步，并且第二步支付动作是不与
后台系统发生请求与响应的，因为第二部操作是用户在客户端直接拉起支付宝支付
或者拉起微信支付的，是直接向三方支付平台发送支付请求的。
这里再复述一下正常的在线支付过程：
第一步：用户完成订单提交，并选择支付方式（微信/支付宝），点击按钮“立即
支付”
第二步：在点击立即支付按钮的一刻，客户端向后台发送请求“统一下单”，后台
将根据支付方式选择向微信或者支付宝发起“统一下单”API调用，让支付宝或者
微信后台记录将要交易的订单数据，等到微信或支付宝成功记录交易订单后会返
回预支付ID或预支付凭据给业务系统后台，后台将支付凭证返回给客户端，下一
步发起支付。
统一下单API的调用过程，要告知支付平台notify_rul(支付完成后的通知回调接口
地址，用来更新订单状态等)，还要告知支付平台支付的超时等待时间。
微信统一下单接口：https://api.mch.weixin.qq.com/pay/unifiedorder
文档地址：https://pay.weixin.qq.com/wiki/doc/api/index.html
支付宝统一下单接口：https://opendocs.alipay.com/apis/api_1/alipay.trade.page.pay

文档地址：https://opendocs.alipay.com/apis
第三步：客户端获取支付凭证后，拉起支付宝支付或拉起微信支付，这时会看到
熟悉的支付页面（微信或支付宝），页面展示用户需要支付的订单金额，输入密
码后点击确认向微信或者支付宝发起支付，微信货支付宝根据支付凭证等参数校
验无误后完成记账，交易&