CN116720857A - 付款分离方法、装置、设备、介质和程序产品 - Google Patents

Abstract

本公开提供了一种付款分离方法，涉及互联网技术领域，可以应用于金融科技领域或其他领域。该付款分离方法包括：响应于付款操作，将待付款资金暂存在虚拟子账户中；获取与虚拟子账户相匹配的多个预设收款对象和预设拆分比例；根据多个预设收款对象和预设拆分比例，对虚拟子账户中的待付款资金进行拆分，以得到多笔拆分款项；每笔拆分款项对应一个预设收款对象；将多笔拆分款项分别转至与其相应的预设收款对象的第二虚拟保证金账户中；对于每个第二虚拟保证金账户，将其中的拆分款项转至与该第二虚拟保证金账户挂接的结算账户。本公开还提供了一种付款分离装置、设备、存储介质和程序产品。

Description

付款分离方法、装置、设备、介质和程序产品

技术领域

本公开涉及互联网技术领域，具体地涉及一种付款分离方法、装置、电子设备、存储介质和程序产品。

背景技术

随着近年来互联网技术的快速发展，企业在进行资金结算时逐步呈现出线上化、平台化、场景化的发展趋势。

但基于已固化的线下资金结算模式，目前企业之间的结算仍以预付模式居多。在预付模式中：经销商预先付款(包含货款和运费)给供应商，进而，在供应商的下单平台根据可用额度进行下单。供应商在收到经销商支付的货款和运费后，再自行与物流公司进行费用结算。

但是，在该预付模式下，供应商实际上代收了运费(或者材料费等)，对于经销商而言，只能获知一笔总款付给了供应商，但资金的具体流向并不清楚。而对于物流公司而言，其只能获知由供应商支付了一笔运费，该笔运费的真实来源并不清楚。这些情况导致对于这些企业而言，资金流与信息流并不匹配。

发明内容

鉴于上述问题，本公开提供了一种付款分离方法、装置、电子设备、存储介质和程序产品。

根据本公开的第一个方面，提供了一种付款分离方法，其中，包括：

响应于付款操作，将待付款资金暂存在第一商户的第一虚拟保证金账户下与所述付款操作相匹配的虚拟子账户中；

获取与所述虚拟子账户相匹配的多个预设收款对象和预设拆分比例；

根据所述多个预设收款对象和所述预设拆分比例，对暂存在所述虚拟子账户中的所述待付款资金进行拆分，以得到多笔拆分款项；其中，每笔所述拆分款项对应一个所述预设收款对象，不同的所述拆分款项对应不同的所述预设收款对象；

将所述多笔拆分款项分别转至与其相应的所述预设收款对象的第二虚拟保证金账户中；

对于每个所述第二虚拟保证金账户，将其中的所述拆分款项转至与该第二虚拟保证金账户挂接的结算账户。

根据本公开的实施例，所述付款分离方法还包括：

响应于回单生成请求，获取与所述回单生成请求相匹配的所述虚拟子账户的交易明细，所述交易明细包括：在一次所述付款操作中，所述虚拟子账户与至少一个所述第二虚拟保证金账户的交易记录；

根据所述虚拟子账户与至少一个所述第二虚拟保证金账户的交易记录，生成第一回单，所述第一回单中的付款账号包括所述第一商户的实际付款账户。

根据本公开的实施例，所述根据所述虚拟子账户与至少一个所述第二虚拟保证金账户的交易记录，生成第一回单，包括：

根据所述虚拟子账户中的账号和交易流水号，获取所述第一商户的付款渠道以及与至少一个所述第二虚拟保证金账户挂接的所述结算账户中的结算明细；

根据所述结算明细，生成第二回单，所述第二回单中的所述付款账号包括所述虚拟子账户；

根据所述付款渠道，确定所述第一商户的实际付款账户；

将所述第二回单中的所述付款账号由所述虚拟子账户更改为所述第一商户的实际付款账户，以生成所述第一回单。

根据本公开的实施例，所述获取与所述虚拟子账户相匹配的多个预设收款对象和预设拆分比例，包括：

当满足支付条件时，获取与所述虚拟子账户相匹配的多个预设收款对象和预设拆分比例；其中，所述支付条件包括：

检测到所述第一商户执行货物确收操作；或者，

检测到所述第一商户与所述多个预设收款对象中的主收款对象签订的直接支付协议，所述主收款对象包括：在当前的所述付款操作中，所述第一商户的上游商户。

根据本公开的实施例，所述多个预设收款对象包括主收款对象和次收款对象，所述付款分离方法还包括所述第一虚拟保证金账户的创建步骤，所述第一虚拟保证金账户的创建步骤，包括：

验证发起所述创建步骤的所述第一商户的身份合法性；

当所述身份合法性通过验证时，为所述第一商户创建所述第一虚拟保证金账户；

根据所述第一商户指定的至少一个所述主收款对象，在所述第一虚拟保证金账户下创建至少一个虚拟子账户；

获取所述主收款对象上送的所述预设拆分比例，并将所述预设拆分比例与所述虚拟子账户进行匹配。

根据本公开的实施例，在所述第一虚拟保证金账户下，至少一个虚拟子账户对应匹配有至少一个所述预设拆分比例，至少两个所述虚拟子账户所匹配的所述预设拆分比例不同。

本公开的第二方面提供了一种付款分离装置，其中，包括：

第一处理模块，用于响应于付款操作，将待付款资金暂存在第一商户的第一虚拟保证金账户下与所述付款操作相匹配的虚拟子账户中；

第一获取模块，用于获取与所述虚拟子账户相匹配的多个预设收款对象和预设拆分比例；

拆分模块，用于根据所述多个预设收款对象和所述预设拆分比例，对暂存在所述虚拟子账户中的所述待付款资金进行拆分，以得到多笔拆分款项；其中，每笔所述拆分款项对应一个所述预设收款对象，不同的所述拆分款项对应不同的所述预设收款对象；

第一流转模块，用于将所述多笔拆分款项分别转至与其相应的所述预设收款对象的第二虚拟保证金账户中；

第二流转模块，用于对于每个所述第二虚拟保证金账户，将其中的所述拆分款项转至与该第二虚拟保证金账户挂接的结算账户。。

本公开的第三方面提供了一种电子设备，包括：一个或多个处理器；存储器，用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得一个或多个处理器执行上述的付款分离方法。

本公开的第四方面还提供了一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时使处理器执行上述的付款分离方法。

本公开的第五方面还提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述的付款分离方法。

上述一个或多个实施例具有如下优点或益效果：

本公开的实施例可以实现一笔待付款资金的自动分拆和支付，拆分和流转受到虚拟保证金账户的监管，对付款人而言(也即第一商户)，其可以通过查看资金虚拟保证金账户之间的流转明细，看到资金的分拆详情以及分拆后具体转给了哪个收款对象，对于收款人而言(也即收款对象)，其可以通过查看资金虚拟保证金账户之间的流转明细，查看该笔收款具体来自哪个付款人。对于经销商-供应商-物流公司这一场景而言，经销商向物流公司的支付款不再由供应商代收，经销商-供应商-物流公司三者中任意者均可以通过虚拟保证金账户查询完整的资金流流转过程，从而确保资金流和信息流相一致。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述内容以及其他目的、特征和优点将更为清楚，在附图中：

图1示意性示出了根据本公开实施例的付款分离方法、装置、电子设备、存储介质和程序产品的应用场景图；

图2示意性示出了根据本公开实施例的付款分离方法的流程图；

图3示意性示出了根据本公开实施例的生成第一回单的流程图；

图4示意性示出了根据本公开实施例的修改付款账号的流程图；

图5示意性示出了根据本公开实施例的获取预设收款对象和预设拆分比例的流程图；

图6示意性示出了根据本公开实施例的创建第一虚拟保证金账户的流程图；

图7示意性示出了根据本公开实施例的付款分离装置的结构框图；

图8示意性示出了根据本公开实施例的适于实现付款分离方法的电子设备的方框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。

需要说明的是，本公开的实施例提供的一种付款分离方法、装置、电子设备、存储介质和程序产品涉及互联网技术领域。本公开的实施例提供的付款分离方法、装置、电子设备、存储介质和程序产品可应用于金融科技领域或者除金融科技领域之外的任意领域。本公开的实施例对付款分离方法、装置、电子设备、存储介质和程序产品的应用领域不做限定。

在本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供、公开和应用等处理，均符合相关法律法规的规定，采取了必要保密措施，且不违背公序良俗。

本公开的实施例提供了一种付款分离方法，其中，包括：响应于付款操作，将待付款资金暂存在第一商户的第一虚拟保证金账户下与付款操作相匹配的虚拟子账户中；获取与虚拟子账户相匹配的多个预设收款对象和预设拆分比例；根据多个预设收款对象和预设拆分比例，对暂存在虚拟子账户中的待付款资金进行拆分，以得到多笔拆分款项；其中，每笔拆分款项对应一个预设收款对象，不同的拆分款项对应不同的预设收款对象；将多笔拆分款项分别转至与其相应的预设收款对象的第二虚拟保证金账户中；对于每个第二虚拟保证金账户，将其中的拆分款项转至与该第二虚拟保证金账户挂接的结算账户。

本公开的实施例可以实现一笔待付款资金的自动分拆和支付，拆分和流转受到虚拟保证金账户的监管，对付款人而言(也即第一商户)，其可以通过查看资金虚拟保证金账户之间的流转明细，看到资金的分拆详情以及分拆后具体转给了哪个收款对象，对于收款人而言(也即收款对象)，其可以通过查看资金虚拟保证金账户之间的流转明细，查看该笔收款具体来自哪个付款人。对于经销商-供应商-物流公司这一场景而言，经销商向物流公司的支付款不再由供应商代收，经销商-供应商-物流公司三者中任意者均可以通过虚拟保证金账户查询完整的资金流流转过程，从而确保资金流和信息流相一致。

图1示意性示出了根据本公开实施例的付款分离方法、装置、电子设备、存储介质和程序产品的应用场景图。

如图1所示，根据该实施例的应用场景100可以包括终端设备101、102、103、网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对用户利用终端设备101、102、103所浏览的网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的用户请求等数据进行分析等处理，并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备。

需要说明的是，本公开实施例所提供的付款分离方法一般可以由服务器105执行。相应地，本公开实施例所提供的付款分离装置一般可以设置于服务器105中。本公开实施例所提供的付款分离方法也可以由不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群执行。相应地，本公开实施例所提供的付款分离装置也可以设置于不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

以下将基于图1描述的场景，通过图2～图6对公开实施例的付款分离方法进行详细描述。

图2示意性示出了根据本公开实施例的付款分离方法的流程图。

如图2所示，该实施例的付款分离方法包括步骤S210～步骤S250。

需要说明的是，虽然图2中的各步骤按照箭头的指示依次显示，但是，这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，图中的至少部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替的执行。

在步骤S210，响应于付款操作，将待付款资金暂存在第一商户的第一虚拟保证金账户下与付款操作相匹配的虚拟子账户中。

本公开实施例付款分离方法的应用场景可以包括经销商向供应商进行货款的支付结算，在这一过程中，经销商在支付货款时，可以自动拆分货款并向供应商以及除供应商之外的其他待支付对象(例如物流公司)等一并进行付款。在这一场景中，经销商即为第一商户，供应商和物流公司为多个预设收款对象。

在本公开实施例中，可以根据第一商户的请求，为第一商户创建第一虚拟保证金账户。第一虚拟保证金账户下可以创建一个或多个虚拟子账户，一个或多个虚拟子账户的数量可以由第一商户进行设置，例如，第一商户为每个供应商对应设置一个虚拟子账户，或者，第一商户为每笔付款操作对应设置一个虚拟子账户。

在本公开的实施例中，获取与付款操作相匹配的虚拟子账户，可以是指获取与付款操作中的收款人(例如供应商A)，确定与之对应设置的虚拟子账户；或者，直接根据付款操作的交易流水号等，确定出与该付款操作对应设置的虚拟子账户。

在步骤S220，获取与虚拟子账户相匹配的多个预设收款对象和预设拆分比例。

在本公开的实施例中，每个虚拟子账户可以对应匹配有一组预设收款对象和一个预设拆分比例，一组收款对象可以包括在第一商户的一笔付款操作中，涉及的全部收款人。

例如，经销商B在一笔付款操作中，涉及的收款人包括供货商A和物流公司C，那么，在创建第一虚拟保证金账户时，可以为供货商A创建一个虚拟子账户D，同时，为虚拟子账户D匹配两个预设收款对象，分别为供货商A和物流公司C。预设拆分比例根据需要向供货商A和物流公司C支付的实际金额确定，例如，预设拆分比例为：供货商A：物流公司C＝99∶1，那么，对于100元的待付款资金，将被拆分成99元和1元，其中，99元支付给供货商A，而1元支付给物流公司C。

在本公开的实施例中，不同的虚拟子账户可以匹配不同组预设收款对象和不同的预设拆分比例，具体可以根据实际需要确定，在此不作限制。

在步骤S230，根据多个预设收款对象和预设拆分比例，对暂存在虚拟子账户中的待付款资金进行拆分，以得到多笔拆分款项。其中，每笔拆分款项对应一个预设收款对象，不同的拆分款项对应不同的预设收款对象。

在步骤S240，将多笔拆分款项分别转至与其相应的预设收款对象的第二虚拟保证金账户中。

在本公开实施例中，经销商向供应商的转账将暂存在第一虚拟保证金账户的虚拟子账户中。在虚拟子账户中，可以对暂存的资金进行拆分，并根据预设收款对象，实现对拆分后的拆分款项的转发。具体则是在保证金交易体系下，在互信的多个虚拟保证金账户之间进行资金流转，也即在第一虚拟保证金账户和第二虚拟保证金账户之间进行资金流转。

例如，一笔100元的待付款资金，在第一虚拟保证金账户的虚拟子账户D下，按照预设拆分比例拆分成99元和1元这两个拆分款项，其中，99元将由虚拟子账户D转至供应商A的第二虚拟保证金账户，1元将由虚拟子账户D转至物流公司C的第二虚拟保证金账户，这样，资金的拆分和流转在保证金交易体系框架下实现，从而能够确保资金流转的安全可靠，同时还能实现资金的自动拆分功能。

在步骤S250，对于每个第二虚拟保证金账户，将其中的拆分款项转至与该第二虚拟保证金账户挂接的结算账户。

在本公开的实施例中，可以为上述的供应商和物流公司创建第二虚拟保证金账户，其中，供应商的第二虚拟保证金账户可以绑定供应商的结算账户，例如供应商的实际收款账户；物流公司的第二虚拟保证金账户可以绑定物流公司的结算账户，例如物流公司的实际收款账户。这样，在将拆分后的拆分款项转至第二虚拟保证金账户中后，第二虚拟保证金账户可以将该笔拆分款项转至相应的结算账户中，以完成整个付款操作。

在本公开的实施例中，第一商户在执行一次付款操作时，一笔待付款资金将自动拆分为与预设收款对象的数量相应的多笔拆分款项，进而，再将每笔拆分款项转给相应的预设收款对象。在这一过程中，资金的分拆和流转在虚拟保证金账户之间进行，从而保证资金流转安全可靠。拆分后的拆分款项在进入预设收款对象的第二虚拟保证金账户后，将自动提现到相应的结算账户中，以完成整个付款操作。

由此，本公开的实施例可以实现一笔待付款资金的自动分拆和支付，拆分和流转受到虚拟保证金账户的监管，对付款人而言(也即第一商户)，其可以通过查看资金虚拟保证金账户之间的流转明细，看到资金的分拆详情以及分拆后具体转给了哪个收款对象，对于收款人而言(也即收款对象)，其可以通过查看资金虚拟保证金账户之间的流转明细，查看该笔收款具体来自哪个付款人。对于经销商-供应商-物流公司这一场景而言，经销商向物流公司的支付款不再由供应商代收，经销商-供应商-物流公司三者中任意者均可以通过虚拟保证金账户查询完整的资金流流转过程，从而确保资金流和信息流相一致。

下面结合图2至图6对本公开实施例的付款分离方法进行进一步的说明。

图3示意性示出了根据本公开实施例的生成第一回单的流程图。

参照图3，在一些具体实施例中，付款分离方法还包括步骤S310和步骤S320。

在步骤S310，响应于回单生成请求，获取与回单生成请求相匹配的虚拟子账户的交易明细，交易明细包括：在一次付款操作中，虚拟子账户与至少一个第二虚拟保证金账户的交易记录。

在步骤S320，根据虚拟子账户与至少一个第二虚拟保证金账户的交易记录，生成第一回单，第一回单中的付款账号包括第一商户的实际付款账户。

在本公开的实施例中，通过虚拟保证金账户，可以实现资金分拆和流转的完整记录，但是，在生成回单时，回单生成系统会以当前账户的上游账户作为付款人生成回单，例如，在供应商或者物流公司选择生成回单时，回单中的付款人可能是第一商户的虚拟子账户。有鉴于此，本公开的实施例对生成回单的过程进行改进，以使生成的回单能够体现出真实付款人。具体而言，在生成回单时，回单生成系统不再仅以当前账户的上游账户作为付款人生成回单，而是追溯待付款资金在分拆过程中的全部流转明细，并进行分析，以确定出该笔待付款资金的支付源，也即，第一商户的实际付款账户。进而，由第一商户的实际付款账户，代替回单中原有付款账户的信息。这样，在供应商或者物流公司选择生成回单时，回单能够体现出真实付款人，而不再是某个虚拟保证金账户。

图4示意性示出了根据本公开实施例的修改付款账号的流程图。

参照图4，在一些具体实施例中，步骤S320包括步骤S321至步骤S324。

在步骤S321，根据虚拟子账户中的账号和交易流水号，获取第一商户的付款渠道以及与至少一个第二虚拟保证金账户挂接的结算账户中的结算明细。

在步骤S322，根据结算明细，生成第二回单，第二回单中的付款账号包括虚拟子账户。

在步骤S323，根据付款渠道，确定第一商户的实际付款账户。

在步骤S324，将第二回单中的付款账号由虚拟子账户更改为第一商户的实际付款账户，以生成第一回单。

在本公开的实施例中，根据虚拟子账户的账号和交易流水号，可以确定一笔待付款资金的来源路径，进而，根据该来源路径，可以确定出该笔待付款资金的付款渠道，例如来自某个支付工具和实际付款账户。除此之外，根据虚拟子账户的账号和交易流水号，还可以确定一笔在拆分后的流转路径，进而，根据该流转路径，可以确定拆分后的拆分款项转入哪个第二虚拟保证金账户。在确定出第二虚拟保证金账户后，通过找到与该第二虚拟保证金账户绑定的结算账户，即可找到所需的结算账户，进而，从该结算账户中提取出需要的结算明细。

在本公开的实施例中，根据提取出的结算明细生成的第二回单中，付款账号为当前账户的上游账户，例如，第一虚拟保证金账户中的虚拟子账户，或者，对于结算账户而言，付款账号也可能是将拆分款项转入该结算账户的第二虚拟保证金账户，具体可以根据实际需要确定，在此不作限制。在本公开的实施例中，通过追溯待付款资金的来源路径，可以获取该笔待付款资金的付款渠道，进而，确定出第一商户的实际付款账户。在实际付款账户确定之后，可以替换掉第二回单中原有的付款账号，以得到第一回单。这样，第一回单可以还原该笔收款的真实付款人，例如，对于供应商A或者物流公司C而言，生成的第一回单中的付款账号为经销商B，而不再是某个虚拟保证金账户。

图5示意性示出了根据本公开实施例的获取预设收款对象和预设拆分比例的流程图。

参照图5，在一些具体实施例中，步骤S220包括步骤S221。

在步骤S221，当满足支付条件时，获取与虚拟子账户相匹配的多个预设收款对象和预设拆分比例。否则，可以进入等待状态，直至满足支付条件或等待超时。

其中，支付条件包括：检测到第一商户执行货物确收操作。或者，检测到第一商户与多个预设收款对象中的主收款对象签订的直接支付协议，主收款对象包括：在当前的付款操作中，第一商户的上游商户。

在本公开的实施例中，第一商户可以是指上述的经销商B，经销商B在收到供应商A提供的货物之后，可以通过客户端发出确收指令，以执行货物确收操作，这样，在本公开的实施例中，可以响应于确收指令，确认第一商户B执行了货物确收操作，进而获取与虚拟子账户D相匹配的多个预设收款对象(例如供应商A和物流公司C)和预设拆分比例(例如供货商A：物流公司C＝99：1)，并执行后续步骤，以完成资金的分拆和支付。

在本公开的另一些实施例中，经销商B还可以与供应商A签订直接支付协议，鉴定后的支付协议将与虚拟子账户进行关联存储。这样，待支付资金在转入虚拟子账户后，可以首先检测是否存在，经销商B与供应商A签订的直接支付协议，若存在，则可以直接获取与虚拟子账户D相匹配的多个预设收款对象(例如供应商A和物流公司C)和预设拆分比例(例如供货商A：物流公司C＝99：1)，并执行后续步骤，以完成资金的分拆和支付。否则，则等待经销商B执行货物确收操作。

图6示意性示出了根据本公开实施例的创建第一虚拟保证金账户的流程图。

参照图6，在一些具体实施例中，多个预设收款对象包括主收款对象和次收款对象，付款分离方法还包括第一虚拟保证金账户的创建步骤，第一虚拟保证金账户的创建步骤包括步骤S410至步骤S440。

在步骤S410，验证发起创建步骤的第一商户的身份合法性。

在步骤S420，当身份合法性通过验证时，为第一商户创建第一虚拟保证金账户。否则，返回验证失败。

在步骤S430，根据第一商户指定的至少一个主收款对象，在第一虚拟保证金账户下创建至少一个虚拟子账户。

在步骤S440，获取主收款对象上送的预设拆分比例，并将预设拆分比例与虚拟子账户进行匹配。

在本公开的实施例中，可以根据第一商户的证件类型、证件号码、姓名或公司名称等参数，调用尽调系统检查客户身份合法性，尽调检查通过则为第一商户创建第一虚拟保证金账户，否则，拒绝为第一商户创建第一虚拟保证金账户。

相应的，本公开的实施例也可以为供应商和物流公司等用户创建第二虚拟保证金账户，在为供应商和物流公司等用户创建第二虚拟保证金账户，也可以据供应商和物流公司的证件类型、证件号码、姓名或公司名称等参数，调用尽调系统检查客户身份合法性，尽调检查通过则为供应商和物流公司创建第二虚拟保证金账户，否则，拒绝为供应商和物流公司创建第二虚拟保证金账户。

在本公开的实施例中，在创建第一虚拟保证金账户后，第一商户可以进一步创建虚拟子账户，具体可以是根据第一商户指定的主收款账户创建虚拟子账户。例如，在经销商B的一笔付款操作中，收款方可以包括供应商A和物流公司C，其中，供应商A为主收款账户，物流公司C则为次要收款账户。可选地，经销商可以为与其存在贸易关系的全部供应商创建虚拟子账户，每个供应商可以对应创建一个虚拟子账户，不同的供应商创建不同的虚拟子账户。

在创建虚拟子账户后，可以由主收款账户上送预设拆分比例，也即，由主收款账户和次要收款账户自行协商各自的收款比例，在确定预设拆分比例后，将预设拆分比例与虚拟子账户进行关联存储。相应的，主收款账户和次要收款账户则一并作为预设收款对象，与虚拟子账户进行关联存储。这样，在待付款资金转入虚拟子账户时，通过查询与虚拟子账户关联存储的预设拆分比例和预设收款对象，即可找到与之匹配的预设拆分比例和预设收款对象。

可选地，虚拟子账户关联经销商在供应商的唯一客户编号，便于供应商的识别。

在一些具体实施例中，在第一虚拟保证金账户下，至少一个虚拟子账户对应匹配有至少一个预设拆分比例，至少两个虚拟子账户所匹配的预设拆分比例不同。

可选地，预设拆分比例支持按供应商进行设置，例如，无论对于哪个经销商，同一个供应商上送的预设拆分比例均相同。当然，也可以支持按供应商+经销商的双重维度进行设置，也即，同一个供应商上送给不同的经销商的预设拆分比例可以不同。

可选地，预设拆分比例可以按单笔交易进行设置，也即，在一笔交易中，预设拆分比例相同。或者，预设拆分比例也可以按交易金额进行设置，也即，无论多少笔交易，只要交易金额相同，则可以采用相同的预设拆分比例。

综上，本公开的实施例将保证金支付方式与线下异步支付方式(例如刷卡支付)相结合，提供了一种付款自动分离的方法，通过本公开的实施例，不仅可以实现经销商一笔支付给供应商并按照供应商的要求自动分离为货款和运费，同时还支持为供应商出具还原真实付款人的第一回单，满足企业做账需求。

基于上述的付款分离方法，本公开还提供了一种付款分离装置。以下将结合图7对该装置进行详细描述。

图7示意性示出了根据本公开实施例的付款分离装置的结构框图。

如图7所示，该实施例的付款分离装置700包括第一处理模块710、第一获取模块720、拆分模块730、第一流转模块740和第二流转模块750。

第一处理模块710用于响应于付款操作，将待付款资金暂存在第一商户的第一虚拟保证金账户下与付款操作相匹配的虚拟子账户中。在一实施例中，第一处理模块710可以用于执行前文描述的步骤S210，在此不再赘述。

第一获取模块720用于获取与虚拟子账户相匹配的多个预设收款对象和预设拆分比例。在一实施例中，第一获取模块720可以用于执行前文描述的步骤S220，在此不再赘述。

拆分模块730用于根据多个预设收款对象和预设拆分比例，对暂存在虚拟子账户中的待付款资金进行拆分，以得到多笔拆分款项。其中，每笔拆分款项对应一个预设收款对象，不同的拆分款项对应不同的预设收款对象。在一实施例中，拆分模块730可以用于执行前文描述的步骤S230，在此不再赘述。

第一流转模块740用于将多笔拆分款项分别转至与其相应的预设收款对象的第二虚拟保证金账户中。在一实施例中，第一流转模块740可以用于执行前文描述的步骤S240，在此不再赘述。

第二流转模块750用于对于每个第二虚拟保证金账户，将其中的拆分款项转至与该第二虚拟保证金账户挂接的结算账户。在一实施例中，第二流转模块750可以用于执行前文描述的步骤S250，在此不再赘述。

本公开的实施例可以实现一笔待付款资金的自动分拆和支付，拆分和流转受到虚拟保证金账户的监管，对付款人而言(也即第一商户)，其可以通过查看资金虚拟保证金账户之间的流转明细，看到资金的分拆详情以及分拆后具体转给了哪个收款对象，对于收款人而言(也即收款对象)，其可以通过查看资金虚拟保证金账户之间的流转明细，查看该笔收款具体来自哪个付款人。对于经销商-供应商-物流公司这一场景而言，经销商向物流公司的支付款不再由供应商代收，经销商-供应商-物流公司三者中任意者均可以通过虚拟保证金账户查询完整的资金流流转过程，从而确保资金流和信息流相一致。

根据本公开的实施例，第一处理模块710、第一获取模块720、拆分模块730、第一流转模块740和第二流转模块750中的任意多个模块可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，第一处理模块710、第一获取模块720、拆分模块730、第一流转模块740和第二流转模块750中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，第一处理模块710、第一获取模块720、拆分模块730、第一流转模块740和第二流转模块750中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

图8示意性示出了根据本公开实施例的适于实现付款分离方法的电子设备的方框图。

如图8所示，根据本公开实施例的电子设备800包括处理器801，其可以根据存储在只读存储器(ROM)802中的程序或者从存储部分808加载到随机访问存储器(RAM)803中的程序而执行各种适当的动作和处理。处理器801例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))等等。处理器801还可以包括用于缓存用途的板载存储器。处理器801可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在RAM 803中，存储有电子设备800操作所需的各种程序和数据。处理器801、ROM802以及RAM 803通过总线804彼此相连。处理器801通过执行ROM 802和/或RAM 803中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除ROM 802和RAM 803以外的一个或多个存储器中。处理器801也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，电子设备800还可以包括输入/输出(I/O)接口805，输入/输出(I/O)接口805也连接至总线804。电子设备800还可以包括连接至I/O接口805的以下部件中的一项或多项：包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分807；包括硬盘等的存储部分808；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至I/O接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分808。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的付款分离方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的ROM 802和/或RAM 803和/或ROM 802和RAM 803以外的一个或多个存储器。

本公开的实施例还包括一种计算机程序产品，其包括计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。当计算机程序产品在计算机系统中运行时，该程序代码用于使计算机系统实现本公开实施例所提供的付款分离方法。

在该计算机程序被处理器801执行时执行本公开实施例的系统/装置中限定的上述功能。根据本公开的实施例，上文描述的系统、装置、模块、单元等可以通过计算机程序模块来实现。

在一种实施例中，该计算机程序可以依托于光存储器件、磁存储器件等有形存储介质。在另一种实施例中，该计算机程序也可以在网络介质上以信号的形式进行传输、分发，并通过通信部分809被下载和安装，和/或从可拆卸介质811被安装。该计算机程序包含的程序代码可以用任何适当的网络介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。在该计算机程序被处理器801执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

根据本公开的实施例，可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例提供的计算机程序的程序代码，具体地，可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。程序设计语言包括但不限于诸如Java，C++，python，“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合或/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。

Claims (10)

1.一种付款分离方法，其特征在于，包括：

响应于付款操作，将待付款资金暂存在第一商户的第一虚拟保证金账户下与所述付款操作相匹配的虚拟子账户中；

获取与所述虚拟子账户相匹配的多个预设收款对象和预设拆分比例；

根据所述多个预设收款对象和所述预设拆分比例，对暂存在所述虚拟子账户中的所述待付款资金进行拆分，以得到多笔拆分款项；其中，每笔所述拆分款项对应一个所述预设收款对象，不同的所述拆分款项对应不同的所述预设收款对象；

将所述多笔拆分款项分别转至与其相应的所述预设收款对象的第二虚拟保证金账户中；

对于每个所述第二虚拟保证金账户，将其中的所述拆分款项转至与该第二虚拟保证金账户挂接的结算账户。

2.根据权利要求1所述的付款分离方法，其特征在于，所述付款分离方法还包括：

响应于回单生成请求，获取与所述回单生成请求相匹配的所述虚拟子账户的交易明细，所述交易明细包括：在一次所述付款操作中，所述虚拟子账户与至少一个所述第二虚拟保证金账户的交易记录；

根据所述虚拟子账户与至少一个所述第二虚拟保证金账户的交易记录，生成第一回单，所述第一回单中的付款账号包括所述第一商户的实际付款账户。

3.根据权利要求2所述的付款分离方法，其特征在于，所述根据所述虚拟子账户与至少一个所述第二虚拟保证金账户的交易记录，生成第一回单，包括：

根据所述虚拟子账户中的账号和交易流水号，获取所述第一商户的付款渠道以及与至少一个所述第二虚拟保证金账户挂接的所述结算账户中的结算明细；

根据所述结算明细，生成第二回单，所述第二回单中的所述付款账号包括所述虚拟子账户；

根据所述付款渠道，确定所述第一商户的实际付款账户；

将所述第二回单中的所述付款账号由所述虚拟子账户更改为所述第一商户的实际付款账户，以生成所述第一回单。

4.根据权利要求1所述的付款分离方法，其特征在于，所述获取与所述虚拟子账户相匹配的多个预设收款对象和预设拆分比例，包括：

当满足支付条件时，获取与所述虚拟子账户相匹配的多个预设收款对象和预设拆分比例；其中，所述支付条件包括：

检测到所述第一商户执行货物确收操作；或者，

检测到所述第一商户与所述多个预设收款对象中的主收款对象签订的直接支付协议，所述主收款对象包括：在当前的所述付款操作中，所述第一商户的上游商户。

5.根据权利要求4所述的付款分离方法，其特征在于，所述多个预设收款对象包括主收款对象和次收款对象，所述付款分离方法还包括所述第一虚拟保证金账户的创建步骤，所述第一虚拟保证金账户的创建步骤，包括：

验证发起所述创建步骤的所述第一商户的身份合法性；

当所述身份合法性通过验证时，为所述第一商户创建所述第一虚拟保证金账户；

根据所述第一商户指定的至少一个所述主收款对象，在所述第一虚拟保证金账户下创建至少一个虚拟子账户；

获取所述主收款对象上送的所述预设拆分比例，并将所述预设拆分比例与所述虚拟子账户进行匹配。

6.根据权利要求1所述的付款分离方法，其特征在于，在所述第一虚拟保证金账户下，至少一个虚拟子账户对应匹配有至少一个所述预设拆分比例，至少两个所述虚拟子账户所匹配的所述预设拆分比例不同。

7.一种付款分离装置，其特征在于，包括：

第一处理模块，用于响应于付款操作，将待付款资金暂存在第一商户的第一虚拟保证金账户下与所述付款操作相匹配的虚拟子账户中；

第一获取模块，用于获取与所述虚拟子账户相匹配的多个预设收款对象和预设拆分比例；

拆分模块，用于根据所述多个预设收款对象和所述预设拆分比例，对暂存在所述虚拟子账户中的所述待付款资金进行拆分，以得到多笔拆分款项；其中，每笔所述拆分款项对应一个所述预设收款对象，不同的所述拆分款项对应不同的所述预设收款对象；

第一流转模块，用于将所述多笔拆分款项分别转至与其相应的所述预设收款对象的第二虚拟保证金账户中；

第二流转模块，用于对于每个所述第二虚拟保证金账户，将其中的所述拆分款项转至与该第二虚拟保证金账户挂接的结算账户。

8.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器执行根据权利要求1～6中任一项所述的付款分离方法。

9.一种计算机可读存储介质，其特征在于，其上存储有可执行指令，该指令被处理器执行时使处理器执行根据权利要求1～6中任一项所述的付款分离方法。

10.一种计算机程序产品，其特征在于，包括计算机程序，所述计算机程序被处理器执行时实现根据权利要求1～6中任一项所述的付款分离方法。