支付的业务架构和流程比较复杂，那么你知道支付的核心处理流程是什么样的吗？关于这个问题，我们不妨从这篇文章中寻找答案。在这篇文章中，笔者结合多张图进行了拆解，一起来看看吧。
前几天我们分析了支付核心的产品架构，整个产品架构可以抽象成如下的业务架构。
各个商户终端通过收银机或者开放API接入支付核心，发起支付服务请求，通过支付核心完成各自的支付服务。
支付核心主要由支付处理核心、支付风控、支付路由、支付网关四大核心部分组成。
当然整个支付业务的实现还需要依赖其他层的支持，比如交易核心、清算结算、账务核心，以及用户中心、产品中心、合约中心等。
在这个框架下，核心的支付处理流程是怎样的呢？我们可以通过三张图来分析一下这部分。
1. 全球支付流程分析
从整体上看支付流程，了解从用户选择产品到支付完成的过程中不同系统层是如何协调的。参见下面第一张图。
从横向来看，支付流程包括交易处理、收银处理、支付处理、支付响应，这四个环节分别解决了交易订单的生成、收银处打包展示、请求支付通道完成支付、支付之后各方的响应与反馈。
从纵向看，是支付在多个层面之间的协同交互，主要是客户端的业务处理、交易核心、支付核心、外部支付通道端，这里我们弱化了与其他如会计核心的交互。
1.交易处理完成，生成业务单据
用户支付的前提是购买东西，因此需要先选定自己需要的商品，并生成相应的订单，才可以进入支付阶段。
1）前往结算
用户在购物车中选择想要结账的商品并前往结账。
2）交易定价
此时您需要计算本次订单相关的费用，例如优惠券的使用情况，优惠券总金额，本次订单应付金额等信息。
3）提交订单
用户提交订单后，在交易核心生成交易单据，并进行卡券冻结、订单创建、账单创建，从而完成整个业务层的交易单据生成。
2. 从零开始的收银台
交易层业务处理完成后，接下来就进入支付阶段，而支付的起点就是收银机。
1）去收银台
业务单据信息齐全后，就可以请求支付核心获取本次交易的收银模板，然后反馈给客户端，跳转收银页面，进入支付流程。
如何获取客户端可用的收银员我们在收银员模板一文中已经详细介绍了，这里就不再赘述。
当到达结账页面，会展示此订单支持的支付方式，当用户选择对应的支付方式，例如微信支付后，支付处理阶段正式开始。
3. 支付处理：条条大路通罗马
不同的终端类型，如网站、H5、APP等，支付流程有所不同，比如你在网站上支付，是无法跳转到支付应用的，但是可以跳转到银行网银或者扫码支付。
但总体来说，整个支付流程应该分为三个部分：客户端流程、支付核心流程、与渠道的交互流程。
1）终端付费流程
不同的终端，终端支付流程不同，比如显示支付码还是跳转网银，支付成功后的登陆页面是什么。
2）支付核心流程
就是由“终端+支付方式”形成的支付业务处理，比如APP内的微信支付，网站内的快捷支付，H5内的快捷支付等，都有类似的“主流程”和“差异化的分支流程”。
但支付核心的主要流程如上图所示，无论何种支付方式，都包括参数交易、交易信息补全、风控与路由处理、支付订单生成、通道请求消息封装、通道提交等环节相同。
3）与渠道的互动流程
不同的支付方式决定了如何与渠道进行交互，有的渠道可能需要预约，有的则不需要。预约之后，渠道会返回不同的“支付标识”，如URL等，这些是下一步支付的关键参数。
如微信支付的交互流程。
第一次预购交互，调用预购接口，渠道返回预付的订单ID。
通过订单接口获取发起支付的必要参数，如上图，然后使用微信支付提供的前端JS方式调用公众号支付，在请求参数中使用，并封装到参数中。
4. 支付各方回应
发起支付后，等待支付渠道的结果通知，在发起支付请求时，我们预留一个“通知地址”，渠道会将支付结果通知到这个地址。
支付核心根据渠道的结果通知，响应各方。
1）客户端响应用户
付款成功后应通知用户。如果付款重定向到渠道的收银员，则用户已在渠道的支付应用中知道付款成功的结果。
但用户返回商户APP后，会到达商户APP的支付成功通知页面。
至此，客户的支付流程已经完成，但是整个支付过程还没有完成，支付系统仍需要通知各方。
2）通知交易支付结果
支付核心需要把支付结果告知交易系统，毕竟他们是业务方，支付成功之后还要进行订单履行等一系列的后续动作。
交易收到支付成功通知后，该交易订单、订单、账单等单据状态都会更新为成功。
然后处理卡券取消并且订单进入履行阶段。
卡券一般在下单成功后冻结，支付成功后取消，也就是如上图所示，卡券状态变成已使用或者已取消。
3）通知路由器并累积数据
因为有些渠道为了分流交易，需要计算累计交易，也就是每个渠道都提供交易，不能出现零交易的情况。
此时路由器需要记录各个渠道的累计交易情况，以便后续进行渠道筛选。
4）会计记录的通知
当然支付成功之后会计是必不可少的，这个我就不多说了。
2.支付核心流程，11个环节
上面我们从全局的角度介绍了支付流程，当然还可以进一步细化，比如第一张图就对每种支付方式的具体支付流程进行了扩展和细化。
了解了全局流程之后，就应该了解支付请求到达支付核心之后的处理流程。
这里需要明确的是，对于每一种支付方式，路由都会筛选出不同的渠道，会形成独特的支付处理流程，快捷支付、网银支付、支付机构A快捷支付、支付机构B快捷支付等形成的核心支付处理流程是有差异的。
当然，如果想要掌控各个渠道各个支付方式的处理流程，首先就要掌握“主要流程”。
主要流程不会因选择的付款方式或渠道不同而有所差异。
真正的区别是渠道的差异化造成的，所以我们把核心的支付流程抽象成11个环节，也就是第二张图。
您可以根据实际业务需求，增加或者删除该图中的链接，但基本是一样的。
上图中的11个环节，又可细分为四个阶段：客户端支付请求处理、支付核心请求消息处理、请求通道发起支付、支付响应处理。
1. 客户付款请求处理
客户端或者内部业务系统按照支付接入接口要求传入支付请求，需要进行一系列的验证和信息补全处理。
如上图所示，需要判断该请求是否具备当前支付服务的请求权限，并校验请求参数是否合法，比如必填参数是否正确，参数格式是否正确，枚举类参数的枚举是否正确。
然后完成交易信息，例如添加交易状态和其他交易信息，为后续的请求路由系统和支付订单生成做准备。
2.支付核心支付消息处理
交易信息齐全之后，接下来就是请求路由器获取可用的支付通道。
路由系统返回的渠道号用来补全渠道信息，比如商户号信息，通讯协议信息，以及其他一些渠道的差异化数据。
3. 请求渠道发起支付
支付订单生成，渠道所需的参数完成后，您就可以开始准备向渠道发起支付申请了。
根据通道的协议要求，封装协议参数，并进行加密签名，封装成通道所需的消息格式。
然后请求相应接口，发起支付。
另外，还会通知支付订单模块、路由系统、会计系统和其他内部系统，以更新状态并预处理下一步业务。
4. 付款响应
向渠道提交支付消息后，只需等待渠道返回支付结果即可。
收到支付结果后更新支付订单相关状态，并通知交易系统、业务请求系统、账务系统等内部系统进行支付成功后的业务处理。
至此，付款处理已完成。
上述主要流程可以针对每种付款方式进行不同的调整和细化。
3. 付款单据结构和2号模型
因为支付并不一定一次请求就能成功；
可能是用户第一次取消了支付，需要重新发起支付，或者第一次支付失败，系统需要重新发起支付；
因此，一次付款可能需要与渠道进行多次交互。
1. 渠道的多项请求要求
不同渠道对于重复请求的订单号要求不同，有的可能需要取消原订单，用新订单发起支付，避免重复支付或付款，有的可能没有这个要求，需要用原订单号发起支付。
这点要和重新发起退款区分开来，渠道重新发起退款的要求是使用原订单号进行退款，不需要更改退款订单号，这个和重新发起支付请求是不一样的。
2.支付核心的文档结构设计
考虑到再次发起支付的情况，我们可以将支付订单的结构设置为两层结构，由支付订单和支付流程组成，一个支付订单对应一个支付流程。
支付订单与业务请求是一一对应的，支付订单与支付流转是一对多对应的，支付流转与通道请求是一一对应的。
其结构如下图所示，这也是我们要重点关注的第三张图。
这样的组织至少会产生三个订单号，分别是业务订单号、支付订单号、支付请求号（支付流水号），表结构及对应关系如下图所示。
以上就是支付核心的整个支付流程分析，具体支付方式的差异化流程大家可以自行研究。
专栏作家
陈天宇洲，微信公众号：陈天宇洲，人人都是产品经理专栏作家，多个平台支付领域专栏作家，十年资深产品人，专注于为十万支付产品经理、支付机构、企业提供有深度的支付内容与服务！