支付“通用架构”与广义“支付通道”

我们知道支付是付款人向收款人的资金转移，而支付系统就是实现这一目标的处理系统。

“转移”可以是用户要在平台下单购买商品向平台支付资金，也可以是平台要向商家结算经营款而发起了付款。

一、支付的通用架构

因为要转移的资金存储在外部非金融或者金融机构的结算账户或者支付账户中，因此如果想实现资金转移的目标，就需要接入能与这类机构进行通讯的通道，通过通道发起支付指令和接收资金的处理结果。

从图中可以看出来，支付通道要解决2个核心问题，一个是发起支付指令，另一个是接收支付结果；收款业务发起收款指令接收收款结果，通过收款通道实现；付款业务发起付款指令接收付款结果，通过付款通道实现。

以上是我们知道的常规通道，三方支付机构的收付通道，网联银联的各类通道，银行的各类通道，都是支付正规军，标准化的支付业务。

二、支付核心架构及通道广义化

可以看如下的支付架构图，在通道层的常见通道位置，以此实现上述的收付业务。

图中有一个标红的通道种类，也就是有没有非正规军或者非常规的支付通道呢？

为了完成“支付业务”，能不能跳出三界之外，不拘泥于传统，在保持上述框架的基础上，而更加灵活多变。

这就是接下来要谈的“广义通道”，即只要能实现“广义收付指令发起”“广义收付结果接收”二者中的任何之一的职能，我们都称之为“通道”。

我们举例：

• 能查账户流水通过系统匹配实现支付确认，其中的“查询流水的接口”，可以认为是一种通道；
• 可以人工导入线下凭证以确认待收付单据，其中“线下凭证的导入”，可以认为是一种通道；
• 可以人工确认支付结果、其中“确认按钮”的结果确认，可以认为是一种通道；
• 接入账户系统发起余额增减并接收增减结果、可以认为“账户系统提供的接口”是一种支付通道；
• 接入仓储，可以通过变更寄存商品的归属权，进行债权转移以完成价值交换或者应收应付的核销，其中的接入仓储可以认为是一种通道；

因此，支付是资金的转移，交易是价值的交换，而支付其实就是资金与价值的交换，因此广义支付就是构建价值交换的通路，而广义的通道就是价值交换通路的交换信息发起和交换最终结果的接收。

那么回到上面的支付架构图，将红色带“？”地通道模块展开。

高维支付思维架构图

如此架构，可以将更多的支付“相关类似业务”兼容到支付系统的架构中，让支付系统架构更具灵活性，并为支付业务的拓展提供了在架构上的指导和设计规范。

图中的某些处理在常规情况下，我们一般不会放到通道层，比如调用内部账户系统的余额支付，很多时候我们会直接由支付核心去调用，而不是通道层去调用，这时，支付核心将会在主流程之外构建一个特殊的分支，就像在人的体外插了一个输液的管子一样，这样做，看似没什么，但总归是对“整体架构的损害”。

下面通过1个例子来强化上面的5类或者更多特殊支付通道构建支付业务的思维。

三、线下汇入，模拟支付通知

有些场景用户会直接汇款至对公户，即线下支付，最大的弊端就是资金处理和线上的业务单据割裂。

这部分款项的核对以及领取相比全流程线上交易来说，比较繁琐，一方面是核对困难，另一方面就是款项和业务单据对应上比较麻烦。

当线下汇入体量较大时，该部分工作成本更高；如果线下进行汇款，而需要线上履约时，这部分匹配工作如何提升效率，能否自动化实现。

而依托“广义通道和支付架构”的引导，我们将对账能力认为是一种支付能力，通过支付核心构建出来，因此就形成了这样一种结构。

即业务系统请求支付核心，支付方式为“线下汇入”，支付核心创建线下汇入待支付单。

通过银企直联获取银行账户流水作为支付结果信息，在线下汇入支付的处理中进行结果的匹配，从而获得线下汇入支付单的最终支付结果，并将该结果告知业务系统，业务系统收到结果后进行后续的业务处理。

那么，我们怎么将线下汇入业务融入到整个支付核心的架构中呢？如下图：

在支付接入层增加线下汇入支付方式，业务系统可以进行调用，在支付核心创建“线下汇入支付方式的支付单”，最初的单据状态为待支付。

线下汇入的支付处理关键处理是“线下汇入结果匹配”。

而通道层的“广义特殊通道”为“查询银行流水”；是建设在银行通道的“银企直联”之上。

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！