支付的业务架构和流程是相对复杂的，那么，你知道支付的核心处理流程是什么样的吗？关于这个问题，我们不妨从这篇文章里寻找答案。本篇文章里，作者就结合多张图做出拆解，一起来看看吧。

前几天我们解析了支付核心的产品架构，整个产品架构可以抽象出以下的业务架构。

各业务终端通过收银台或者开放API接入支付核心，发起支付业务请求，通过支付核心完成自己的支付业务.

支付核心主要由支付处理核心、支付风控、支付路由、支付网关等4个核心部分组成。

当然整个支付业务的实现也离不开其他层的支持，如交易核心、清结算、账务核心、以及用户中心、商品中心、合同中心等。

在这样的框架下，支付的核心处理流程是什么样的呢？我们通过3张图可以展开这部分的分析。

一、全局支付流程剖析

站在全局的视角看支付流程，了解清楚从用户挑选商品开始，到最后支付完成，不同系统层之间是如何协调完成的，看下面第1张图。

横向看，代表支付的进程，包含了交易处理环节、收银台处理环节、支付处理环节、支付应答环节；该4大环节分别解决了交易单的生成、收银台的封装和展示、请求支付渠道完成支付、支付后的各方应答反馈。

纵向看，是支付在多层之间的协同交互，主要是客户端、交易核心、支付核心以及外部支付渠道侧的业务处理，这里我们弱化了与其他如账务核心的交互。

1. 交易处理完成业务单据生成

用户支付的前提是要买东西，因此需要先选择自己需要的商品，并且生成对应的订单以后，才能进入到支付环节。

1）去结算

用户在购物车选择了自己要结算的商品，去结算。

2）交易计价

这时候需要计算出本单相关的费用，例如优惠券的使用、总优惠券金额、本单应付金额等信息。

3）提交订单

用户提交订单以后在交易核心生成交易单据，并完成卡券的冻结、订单的创建、账单的创建，如此完成了整个业务层交易类单据的生成。

2. 收银台从无到有

交易层业务处理完成以后，接下来就开始进入支付阶段的，支付的起点是收银台。

1）跳转到收银台

有了完整的业务单据信息以后就可以请求支付核心获得本笔交易的收银台的模版，然后反馈客户端，跳转到收银台页面，进入到支付流程中。

我们在收银台模版一文详细介绍了在客户端是如何获得可用收银台的，这里就不再详述了。

到了收银台页面，展示了本单支持的支付方式，用户选择对应的支付方式，例如微信支付，就正式进入了支付处理阶段。

3. 支付处理，条条大路通罗马

不同的终端类型、如网站、H5、APP等，就有不同的支付流程，比如在网站进行支付，就无法跳转到支付应用中，但可以跳转到银行网银或者扫码支付。

但整体来看整个支付流程应该分成三大部分的流程，客户端的流程、支付核心的流程、与渠道的交互流程。

1）终端支付流程

不同的终端形成了不同的终端支付流程，是展示收款码还是跳转到网上银行，支付成功后落地页是什么。

2）支付核心流程

是针对“终端+支付方式”所形成的支付业务处理，如APP里的微信支付、网站的快捷支付、H5内的快捷支付等，都有相似的“主流程”和“差异化的分支流程”。

但是支付核心的主流程如上图所示，不管什么支付方式都包含了参数的交易、交易信息补全、风控与路由处理、支付单的生成及渠道请求报文的封装、提交渠道等相同的环节。

3）与渠道的交互流程

不同的支付方式就决定了如何与渠道进行交互，有的渠道可能需要预下单、有的渠道可能就不需要、在预下单以后渠道就会返回不同的“支付标识”，如token、url等，这是支付下一步的关键参数。

如微信的JSAPI支付的交互流程。

第一次预下单交互，调用预下单接口，渠道返回了预付单标识。

通过JSAPI下单接口获取到发起支付的必要参数prepay_id，如上图，然后使用微信支付提供的前端JS方法调用公众号支付，在请求参数中使用prepay_id，封装到package参数中。

4. 支付各方应答

支付发起以后，等待支付渠道的结果通知，在发起支付请求时我们预留了“通知地址”，渠道会将支付结果告知该地址。

支付核心根据渠道的结果通知，对各方进行应答。

1）客户端向用户应答

支付成功了要告诉用户，如果支付是跳转到了渠道的收银台，那么用户在渠道的支付应用内已经知道了支付成功的结果。

只不过，用户调回商家应用以后会到达商户应用的支付成功通知页面。

至此，客户端的支付流程就全部结束了，但是整个支付还没有结束，支付系统还要进行各方通知。

2）通知交易支付结果

支付核心需要将支付结果告知交易系统，毕竟人家是业务方，支付成功后还要进行订单履约等一系列后续动作。

交易接收到支付成功的通知以后，会更新交易单、订单、账单等的单据状态为成功。

然后对卡券发起核销处理，订单进入到履约阶段。

卡券的处理一般是下单成功以后进行冻结，支付成功以后进行核销，也就是如上图中券状态变成已使用或者已核销。

3）通知路由，进行数据累加

因为有些渠道需要计算累加交易，以进行交易的分流，就是每个渠道都提供的交易，不能0交易。

此时路由就需要记录每个通道的累计交易情况，以便后续进行通道筛选时使用。

4）通知账务记账

当然，支付成功以后记账是少不了的，这一点就不过多描述了。

二、支付核心主流程、11个环节

上面我们介绍了全局视角的支付流程，当然还能进行细化，比如每一个支付方式的具体支付流程在第1张图中进行展开细化。

了解了全局流程以后，应该支付支付请求到了支付核心以后的处理流程是什么样的。

这里要清楚，每一个支付方式，路由筛选出了不同的通道，都会形成一个独特的支付处理流程，快捷支付、网银支付；A支付机构的快捷支付、B支付机构的快捷支付等所形成的支付核心的处理流程是存在差异的。

当然，要想把控好每一个支付方式在每一个通道的处理流程，首先要先把握“主线流程”。

主线流程不会因为支付方式的不同，选择的渠道不同而不同。

真正不同的是渠道的差异化造成的，所以我们把支付核心主流程抽象出11个环节，这就是第2张图。

可以根据实际的业务需要，对该图的环节进行增加或者删减，但大同小异。

上图的11个环节可以再次划分成客户端支付请求处理、支付核心请求报文处理、请求渠道发起支付、支付应答处理等4个阶段。

1. 客户端支付请求处理

客户端或者内部业务系统按照支付接入接口要求传入支付请求，需要进行一系列的校验和信息补全处理。

如上图所示，应该判断该请求是否有当前支付业务的请求权限，并校验请求参数是否合法，比如必填参数是否正确、参数格式是否正确、枚举类参数的枚举是否正确等。

然后对交易信息进行补全，比如增加交易状态、其他一些交易信息补充，为后续的请求路由系统以及生成支付单做准备。

2. 支付核心支付报文处理

交易信息完整以后，接下来就是请求路由获取可用支付通道。

通过路由系统返回的通道编号，补全渠道信息，例如该渠道的商户号信息、通讯协议信息、以及一些其他差异化数据。

3. 请求渠道发起支付

支付单生成以后，并且补全了渠道需要的参数以后，就开始准备向渠道发起支付申请了。

按照渠道的协议要求，封装协议参数，进行加密、签名，封装成渠道要求的报文格式。

然后，请求相应接口发起支付。

并且，通知支付单模块、路由系统、记账系统等内部系统更新状态以及下一步业务的预处理。

4. 支付应答

将支付报文提交给渠道以后，就等着渠道返回支付结果了。

接收到支付结果以后，更新支付单相关状态，并通知交易系统、业务请求系统、账务系统等内部系统进行支付成功后的业务处理。

至此，一笔支付的处理就结束了。

以上的主流程，可以在每一个支付方式上进行差异化调整，细化。

三、支付单据结构、2单号模型

因为支付不一定请求一次就成功了；

可能第一次用户取消了，要重新发起支付，或者第一次失败了，系统要再次发起支付；

从而，一笔支付可能需要与渠道交互多次。

1. 渠道的多次请求要求

而不同渠道对于重复请求，对单号有不同的要求，有的可能需要取消原单，以新单发起支付，以避免重复支付或者付款，有的可能没有这个要求，需要使用原单号发起支付。

这一点要跟退款重新发起区别开，渠道对重新发起退款的要求是使用原单号进行退款，不需要更换退款单号，这一点与重新发起支付请求有区别。

2. 支付核心的单据结构设计

考虑到支付的重新发起情况，我们可以将支付单的结构设置成两层结构，由支付单和支付流水组成，一笔支付单对应对比支付流水。

支付单与业务请求一一对应，支付单与支付流水一对多，支付流水与渠道请求一一对应。

该结构如下图所示，这是我们要关注的第3张图。

这样的机构下会产生至少3个单号，业务订单号、支付单号、支付请求号（支付流水号），形成的表结构和对应关系如下图所示。

以上就是支付核心的全部支付流程分析，具体的支付方式的差异化流程，大家可以自主研究。