一文看懂支付前链路流程

前序

首先支付流程讲究的就是快，还有就是订单的冲入，我们不能说一笔交易订单进来都加一个分布式锁去解决，所以我们目前常用的做法就是一个订单进来，首先落库，如果落库失败，并且是主键重复的话，那么调用查询接口，查询订单，进行原单比对，比对无误的话，可以接着走后续的流程。这样做是比较常见的做法。

收单到支付流程

国内常用的支付方式基本上分为三大类。

绑卡支付，也就是我们先通过银行卡签约，下次在进行支付的时候就直接进行签约协议支付了
快捷支付，快捷支付有一个共性，就是一定会拉起对应的第三方支付软件的app，比如拉起微信，拉起支付宝拉起工商银行app等，这算是快捷支付。
免密支付，这是一种特殊形式的支付方式，类似于银行卡签约支付，也是通过发起签约流程，之后使用签约协议进行支付，常见有微信签约支付，支付宝签约支付。

1和3，在具体的业务场景下会有响应的拓展，比如我们购买vip会员的时候签订的代扣协议，每个月定期的从我们的银行卡或支付宝中代扣一部分现金，自动为vip续费。这会衍生出另外一种支付方式，代扣，循环代扣，循环代扣是代扣的一种拓展方式，简单理解就是把我们在改支付公司的所有可用的支付方式都扣除一遍，知道支付成功为止。

在这里插入图片描述

绑卡支付流程

主动查询和被动回调流程推动订单状态

推这两层订单的状态分别有三种形式。

通道回调，我们就一步一步的进行各层逻辑的处理，知道通知到最上层的交易层，都处理成功之后在给回调返回成功，这个时候两层订单的状态是一致的。
接收消息，触发主动查询，这个时候呢我们只是更新支付层订单的状态，如果上层订单的状态想要推动，需要上层发起查询。
外部系统主动查询，如果外部系统主动查询交易层，发现是初始态，那么就去查一下支付层。如果支付层也是初始态，那么去查一下通道，顺带更新支付层订单的状态，这样也还可以服用2 的逻辑代码。

关闭订单

首先我们先明确一下分为三层交易层，支付层，渠道层，基本上业内的做法是交易层和支付层在同一个事务里面，即一个应用程序，交易层和支付层分别为这两张表 tradeorder,payorder，渠道层一张表channelorder。

关单分为两种方式，一种是先关闭支付层订单（支付层去调用渠道层，渠道层调用通道的关单接口请求支付宝或微信，依次关单），等待支付层订单都关闭后，在关闭交易层订单。如果任意一笔支付层订单关单失败，都不能关闭交易层订单。

第二中关单方式是先关闭交易层订单，然后依次关闭支付层订单。这个时候就会有一个问题，就是如果我们关闭了交易层订单，这时候支付层订单支付成功了怎么办。这就是payorder存在的意义，由于跨系统调用，还要想tradeorder 和channelorder订单状态一致，只能添加冗余表，故而设计tradeorder对应多个payorder(支付订单表)，这时tradeorder的订单状态是已关闭，等渠道层通知到支付层支付成功之后，由于payorder和 channelorder是一一对应的，这时的payorder已然是支付成功，那通知到交易层之后，我们只需要判断tradeorder的状态是否是关单，如果是关单的话，那么在更新payorder的订单状态为待退款，这样是不是就能解决我们遇到的问题了。

彩蛋

前面的梳理只局限于支付的前链路，忽略掉的模块还有商户模块，算费模块，清结算模块，账户模块，以及一些衍生的产品，比如个人或企业钱包,商户平台，商户入驻平台等，随着后续支付工作的展开，本人由于工作局限性，目前还未接触过清算结算及账户模块。后期可以出一般商户模块和算费模块，有机会在学习一下清结算及账户相关模块的工作流程。