CN115456622A - 基于第三方支付渠道b2c电商订单合并支付的处理方法 - Google Patents

Abstract

本发明公开了基于第三方支付渠道B2C电商订单合并支付的处理方法，包括：上游应用系统请求支付系统创建交易支付订单，重定向跳转到支付收银台，支付收银台合并支付服务校验交易场景，支付收银台请求支付系统合并支付方法；支付系统生成一笔合并支付批次订单，将合并支付订单推送到消息队列中，接收子单处理结果；请求第三方支付渠道支付；支付系统组装第三方渠道返回的支付串信息，完成支付；第三方支付渠道异步通知合并支付订单结果，支付系统更新合并订单状态；支付系统将合并支付订单信息通过消息队列形式推送给上游应用系统。本发明解决了网上购物时用户需要为跨店铺订单支付多次的烦琐操作，大大节省了支付时间，提升了用户体验。

Description

基于第三方支付渠道B2C电商订单合并支付的处理方法

技术领域

本发明属于互联网信息技术领域，尤其涉及基于第三方支付渠道B2C电商订单合并支付的处理方法。

背景技术

随着计算机互联网技术的发展，网购成为了非常普遍的现象，因此对于电商公司来说，线上支付变得越来越重要。由于公司在没有支付牌照的情况下，用户在商城购物，一次只能对同一店铺的多个商品进行下单，用户在购买过程中，若选择不同店铺的多个商品下单，则需要逐一对不同店铺的商品提交订单。这种操作方式一次支付只能实现一个店铺订单的处理，操作烦琐，影响支付效率，且用户体验较差。

现有技术的不足：

1、用户下单只能对同一店铺的多个商品进行单笔订单支付，若需要跨店铺多商品提交订单，用户需要多次下单，操作烦琐。

2、支付方式比较单一，支付场景单一，不满足用户跨店铺下单。

发明内容

本发明所要解决的技术问题是在没有支付牌照背景下，提供一种跨店铺多商品订单合并支付的处理方法，旨在解决现有技术存在一次支付操作只能实现单个店铺订单处理而造成的网络支付操作复杂、支付效率低下的技术问题。

本发明具体提供了基于第三方支付渠道B2C电商订单合并支付的处理方法，包括如下步骤：

步骤1：上游应用系统以店铺维度，请求支付系统创建交易支付订单，支付系统持久化订单数据，同步返回交易支付订单流水号；

步骤2：上游应用系统组装合并支付请求参数，通过HTTP-POST(超文本传输协议，Hyper Text Transfer Protocol，HTTP)方式发送请求数据到支付开放平台，支付开放平台得到相关数据后，进行安全校验等验证，验证通过后，支付开放平台重定向跳转到支付收银台对应的功能页面；

步骤3：支付收银台合并支付服务校验交易场景，并且根据交易场景返回支持的可用支付方式展示在支付收银台页面；

所述交易场景用于区分交易的类型，如消费者在线上零售商城购买商品、消费者到线下门店购买商品、门店向供应商采购货物等。

步骤4：支付收银台请求支付系统合并支付方法，支付系统校验合并订单状态和订单幂等性校验；

步骤5：支付系统生成一笔合并支付批次订单，保存批次订单数据到数据库，并且将批次单单号与合并订单列表做关联，更新保存合并订单列表数据；

步骤6：将合并支付订单推送到消息队列中，消息队列为每个子单执行任务数据；

所述消息队列和消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息等问题。由于在高并发环境下，同步请求来不及处理，请求往往会发生阻塞。大量的请求到达访问数据库，导致行锁表锁，最后请求线程会堆积过多，从而触发too manyconnection错误，引发雪崩效应。本发明使用消息队列，通过异步处理请求，从而缓解支付系统的压力。

步骤7：支付系统监听消息队列数据，接收子单处理结果；

步骤8：支付系统获取到子单结果后，请求第三方支付渠道支付；

步骤9：支付系统组装第三方渠道返回的支付串信息，并且返回给前端。

步骤10：前端根据支付串信息唤起微信、支付宝，用户输入密码，完成支付；

所述预支付信息用于前端唤起微信、支付宝、银联APP支付，用户在APP输入密码，完成订单支付；

步骤11：第三方支付渠道异步通知合并支付订单结果，支付系统更新合并订单状态。

步骤12：支付系统将合并支付订单信息通过消息队列形式推送给上游应用系统。此时支付订单结果推送到消息队列中，让上游应用系统监听消息队列消费。

步骤1中，所述创建交易支付订单是用户在上游应用系统下单后，上游应用系统调用支付系统创建支付交易订单，订单参数包含：买家账户、卖家账户、清分类型、交易金额、商品信息列表、交易名称。

步骤1中，所述店铺维度是针对对于平台型的电商，有外部商家进行入驻，用户购买了不同店铺的商品，在购物车也是按照店铺的维度进行展示，此时用户多店整合下单支付，平台都是合单一次性支付，结算完成后就会进行拆分操作。按照店铺维度拆单：便于结算，一个订单包含多个商家的商品，平台要与不同商家进行结算。

步骤2中，所述支付开放平台负责对外暴露和提供支付交易、管理服务，以及对跳转页面重定向服务，具体包括：以https协议接收服务请求报文和发送结果报文给接入方；对服务的请求和返回报文进行处理，包括：报文的参数检查、认证、权限检查，动态协议序列化或者反序列化，脱敏安全处理，统一日志处理，统一错误处理，响应和通知发送；将通过执行层处理后的报文进行处理，根据业务场景合理调用下层系统，并将返回报文和通知交由执行层处理后，返回给请求方。

步骤3中，所述交易场景用于区分交易的类型，如消费者在线上零售商城购买商品、消费者到线下门店购买商品、门店向供应商采购货物等。

所述合并支付服务校验交易场景是指，支付系统通过后台管理系统配置场景类型，根据场景类型查询数据库配置信息，如果存在，则校验通过，如果不存在，则返回不支持该场景类型提示信息。

步骤4包括：

步骤4-1：校验合并支付交易订单状态，遍历订单列表是否包含支付成功、支付中状态的订单，如果包含则不允许发生合并支付；

步骤4-1中，所述订单状态，支付交易订单状态包含：初始状态、支付中、交易成功、交易失败、交易撤销、交易关闭、交易异常。

步骤4-2：进行支付系统订单幂等性校验，表示服务会根据商户订单号参数维持服务的一致性(注意不是相同的结果，是行为一致)。当用户多次传入相同的商户订单号请求交易时，服务会根据商户订单号对应的实际交易的状态按一致的处理行为进行处理，比如：该订单对应的交易已处理完成，后续所有相同订单的请求对直接返回成功并处理完成，如果该订单对应的交易正在处理中或挂起中，则用户再次请求会触发业务继续进行，并返回当前的状态。

所述订单幂等性校验具体步骤包括：根据商户订单号查询交易订单，对查询出来的订单记录添加数据库行级锁，再校验订单状态，如果当前订单关闭时间大于当前时间，则不能够再支付；如果交易订单状态关闭、撤销，则不能够再支付；如果订单状态支付成功，直接返回用户成功，无需重复提交；所述行级锁是指：数据库每次锁定的是一行数据的锁机制，是数据库中粒度最小的一种锁。

步骤4-1中，所述支付交易订单状态包含：初始状态、支付中、交易成功、交易失败、交易撤销、交易关闭、交易异常。

步骤5中，所述批次订单用于记录合并支付交易支付订单，合并支付交易支付订单信息包含：交易场景、付款类型、商户订单号、批次号、批次子订单数量、付款人账户信息、交易金额、订单状态。

步骤6包括：

步骤6-1：消息队列监听到新的订单信息生成后，确定合并支付子订单信息，立刻返回正确的回执；

步骤6-2：支付系统执行根据合并支付订单列表生成多笔对应业务订单的支付交易子订单，并遍历子订单列表向托管银行预下单，托管银行同步返回预下单流水号；

步骤6-3：此时所有支付子订单预下单完成后，把结果发送到消息队列中，让对应服务器消费；

步骤6-2中，所述托管银行是指，公司在没有支付牌照的情形下，店铺卖家在托管银行进行商户注册、开通结算账户，卖家账户资金托管在银行，依托托管银行进行订单对账、资金清结算、商家提现。

步骤6-2中，所述向托管银行预下单是指，合并支付子单在托管银行创建对应的订单，每笔子订单对应一笔托管银行订单，用于支付订单对账和资金分账结算。

步骤7包括：

步骤7-1：消息队列监听到新的订单信息生成后，确定合并支付子订单信息，立刻返回正确的回执；

步骤7-2：支付系统执行根据合并支付订单列表生成多笔对应业务订单的支付交易子订单，并遍历子订单列表向托管银行预下单，托管银行同步返回预下单流水号；

步骤7-3：此时所有支付子订单预下单完成后，把结果发送到消息队列中，让对应服务器消费。

本发明具有以下优点：

1.在没有支付牌照情况下，商城可以进行跨店铺多商品合并支付，丰富了支付系统支付场景和支付方式。

2.商城只需调用合并支付方法，就可以完成跨店铺多商品下单，减少商城与支付系统调用次数，减少网络开销。

3.解决了网上购物时用户需要为跨店铺订单支付多次的烦琐操作，大大节省了支付时间，提升了用户体验。

附图说明

下面结合附图和具体实施方式对本发明做更进一步的具体说明，本发明的上述或其他方面的优点将会变得更加清楚。

图1是支付系统创建交易订单方法的流程示意图。

图2是合并支付处理方法的具体流程示意图。

图3是消息队列执行支付和托管银行订单关联交互流程示意图。

图4是支付和第三方支付渠道支付方法交互流程示意图。

具体实施方式

下面结合附图及实施例对本发明做进一步说明。

如图1为支付系统创建交易订单方法的流程示意图：

步骤S101：支付开放平台接收上游应用系统提交的创建订单请求。上游应用系统通过HTTP-POST方式发送请求数据到支付开放平台。支付开放平台对参数进行验签，确保参数没有被篡改。验证通过后，同步请求支付系统对应的功能方法。

创建订单参数包含：交易名称、付款人账户信息、收款人账户信息、清分类型、交易金额、订单关闭时间、商品信息、请求号、签名方式、签名、异步通知地址。

步骤S102：支付系统接收订单数据和签名，并且对订单数据进行验签校验。

需要参与签名的参数：请求报文，响应报文和通知报文，都采用相同的规则：对发送或接收到的所有参数(包括公共报文部分)，除去sign参数外，都是需要参与计算待签名字符串的参数。

生成待签名字符串规则：以Java为例，报文的签名数据默认为全签，建议直接通过request.getParameters()获取全部的参数，对数组里的每一个成员按字符ASC码的顺序排序，若遇到相同首字符，则看第二个字符，以此类推。排序完成之后，再把所有数组值以“&”字符连接起来，这串字符串便是待签名字符串，例如：requestNo＝6741334835157966&partnerId＝20121015300000032621&returnUrl＝http://www.test.com/yiji/return_url.asp&service＝fastpay&tradeAmount＝100&tradeName＝xxx电视机生成签名串注意事项：1、没有值的参数无需传递，也无需包含到待签名数据中；2、签名时将字符转化成字节流时指定字符集全部采用UTF-8；3、待签字符串中的特殊字符无需编码，根据HTTP协议，传递参数的值中如果存在特殊字符(如：&、@等)和中文字符，那么该值需要做UTF-8编码的URL-Encoding，这样请求接收方才能接收到正确的参数值。

步骤S103：对上游应用系统创建的订单数据进行幂等性校验，并且校验卖家账户信息。

根据商户订单号查询交易订单，对查询出来的订单记录添加数据库行级锁，再校验订单状态，如果当前订单关闭时间大于当前时间，则不能够再支付；如果交易订单状态关闭、撤销，则不能够再支付；如果订单状态支付成功，直接返回用户成功，无需重复提交；以Java为例，tradeStatus＝＝CANCEL||tradeStatus＝＝CLOSE为true，只要满足其中一个条件，则不可再支付。如果tradeStatus＝＝SUCCESS为true，则返回此订单已支付成功，无需重复提交。

所述行级锁是数据库每次锁定的是一行数据的锁机制，防止其他事务对此行进行update和delete。是数据库中粒度最小的一种锁，发生锁冲突的概率最低，并发度最高，应用在InnoDB存储引擎中。

根据卖家用户Id查询卖家信息，若卖家用户处于禁用状态、未在托管银行开户则不允许创建支付订单发生交易。如果userStatus＝＝DISABLE||merchantStatus！＝OPEN_OK为true，则不允许创建订单。

组合成表达式时，可根据不同的编程语言做不同处理，以Java为例，>(大于)、>＝(大于等于)、<(小于)、<＝(小于等于)本身就是Java中的关系运算符。＝(等于)可以用Java中的＝＝或String类型的equals()方法表达，！＝(不等于)可以用Java中的！＝方法表达，||为逻辑运算符，||只要满足第一个条件，后面的条件就不再判断，返回true。∈(属于)、

(不属于)可用Java中String类型的contains()方法表达。

步骤S104：将交易订单信息持久化保存到数据库，订单信息包括金额、商品描述信息列表、卖家和买家账户信息。

步骤S105：支付系统生成订单流水号，并将结果同步返回给上游应用系统。

如图2为合并支付处理方法的具体流程示意图：

步骤S201：支付开放平台接收上游应用系统调用合并支付跳转支付收银台页面的请求。上游应用系统通过HTTP-POST方式发送请求数据到支付开放平台。支付开放平台得到相关数据后，会先进行安全校验等验证，验证通过后便会处理这次发送过来的数据请求。

支付开放平台主要负责对外暴露和提供支付交易、管理等服务，以及对跳转页面重定向服务。以https协议接收服务请求报文和发送结果报文给接入方。对服务的请求和返回报文进行处理，将报文的参数检查，认证，权限检查，动态协议序列化/反序列化，脱敏安全处理，统一日志处理，统一错误处理，响应和通知发送等。将通过执行层处理后的报文进行处理，根据其业务场景合理调用下层系统，并将返回报文和通知交由执行层处理后，返回给请求方。

步骤S202：开放平台对接收跳转到支付收银台的参数进行组装处理，参数包含：交易场景、付款人账户信息、合并支付商户订单信息列表、签名类型、签名串。合并支付商户订单列表信息包含：交易订单号、交易金额。

步骤S203：支付开放平台完成服务处理后，使用重定向跳转到支付收银台页面请求合并支付方法，校验交易场景并且根据交易场景返回支持的支付方式，校验合并订单状态和订单幂等性校验。

根据交易场景类型判断支付系统是否支持当前场景交易，若不支持，则不允许发生合并支付。遍历查询合并支付订单信息列表，判断列表中订单是否存在已支付或者支付中状态的订单，若存在，则不允许发生合并支付。若tradeType

当前场景支持的可用支付方式集合，则不允许发生合并支付。若列表中订单状态tradeStatus＝＝CANCEL||tradeStatus＝＝CLOSE||tradeStatus＝＝PROCESSING为true，只要满足其中一个条件，则不可再支付。若tradeStatus＝＝SUCCESS为true，则返回此订单已支付成功，不允许发生合并支付。

步骤S204：支付系统生成一笔合并支付批次订单，保存批次订单数据到数据库，并且将批次单单号与合并订单列表做关联，更新保存合并支付订单列表数据。

生成批次订单流水用于记录合并订单场景、状态、交易类型信息，批次订单信息包含：交易场景、付款类型、商户订单号、批次号、批次子订单数量、付款人账户信息、交易金额、订单状态。

批次订单号生成规则：1～8位采用系统时间，在系统时间上精确到毫秒级保证时间上的惟一性，9～16位采用当前对象的HashCode值，在一个内部对象上的惟一性，17～24位采用调用方法的一个随机数，在一个对象内的毫秒级的惟一性。例如：20220627+对象HashCode值+UUID，则编号为：20220627108852431eac2ed8

步骤S205：将合并支付订单推送到消息队列中，消息队列为每个子订单执行任务数据。

消息队列监听到新的订单信息生成后，确定合并支付子订单信息，立刻返回正确的回执，支付系统执行根据合并支付订单列表生成多笔对应业务订单的支付交易子订单，并遍历子订单列表向托管银行预下单，此时所有支付子订单预下单完成后，把结果发送到消息队列中，让对应服务器消费即可。

步骤S206：支付系统监听消息队列数据，接收子单处理结果。

步骤S207：支付系统获取到子单结果后，请求第三方支付渠道支付。

如图3为消息队列执行支付和托管银行订单关联交互流程示意图：

步骤S301：为合并支付订单信息创建对应的消息队列，所述消息队列用于存放订单信息。

消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息等问题。由于在高并发环境下，同步请求来不及处理，请求往往会发生阻塞。大量的请求到达访问数据库，导致行锁表锁，最后请求线程会堆积过多，从而触发too many connection错误，引发雪崩效应。本发明使用消息队列，通过异步处理请求，从而缓解支付系统的压力。例如：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户下单成功。订阅下单的消息采用发布/订阅的方式，获取下单信息。下单后订单系统写入消息队列就不再关心其它的后续操作，实现订单系统与其他系统的应用解耦。

步骤S302：当消息队列监听到新的订单信息生成后，确定合并支付子订单信息。

步骤S303：支付系统分别为每个子订单执行任务数据，生成支付系统请求订单流水，请求托管银行预下单，银行同步返回预下单流水号。

每笔子订单都会去托管银行创建订单，在托管银行生成对应的流水记录，利用托管银行为后续做订单对账、资金清结算解冻。

步骤S304：托管银行返回的订单状态和流水号更新保存到支付系统请求订单流水中。

如图4为支付和第三方支付渠道支付方法交互流程示意图：

步骤S401：支付系统请求第三方支付渠道支付。

步骤S402：支付系统组装第三方渠道返回的支付串信息，并且返回给前端。微信预支付信息包含：appId、时间戳、支付签名、签名类型。支付宝预支付信息包含：交易在支付宝系统中的tradeNo订单号、资金金额。

步骤S403：前端根据支付串信息唤起微信、支付宝支付。

步骤S404：第三方渠道将支付结果异步通知支付系统，支付变更合并订单状态。异步通知消息包含支付状态、交易金额、签名串、通知时间、请求号等。

步骤S405：支付系统将合并支付订单信息通过消息队列形式推送给上游应用系统，此时支付订单结果推送到消息队列中，让上游应用系统监听消息队列消费。

具体实现中，本申请提供计算机存储介质以及对应的数据处理单元，其中，该计算机存储介质能够存储计算机程序，所述计算机程序通过数据处理单元执行时可运行本发明提供的基于第三方支付渠道B2C电商订单合并支付的处理方法的发明内容以及各实施例中的部分或全部步骤。所述的存储介质可为磁碟、光盘、只读存储记忆体(read-only memory，ROM)或随机存储记忆体(random access memory，RAM)等。

本领域的技术人员可以清楚地了解到本发明实施例中的技术方案可借助计算机程序以及其对应的通用硬件平台的方式来实现。基于这样的理解，本发明实施例中的技术方案本质上或者说对现有技术做出贡献的部分可以以计算机程序即软件产品的形式体现出来，该计算机程序软件产品可以存储在存储介质中，包括若干指令用以使得一台包含数据处理单元的设备(可以是个人计算机，服务器，单片机。MUU或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。

本发明提供了基于第三方支付渠道B2C电商订单合并支付的处理方法，具体实现该技术方案的方法和途径很多，以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。本实施例中未明确的各组成部分均可用现有技术加以实现。

Claims (10)

1.基于第三方支付渠道B2C电商订单合并支付的处理方法，其特征在于，包括如下步骤：

步骤1：上游应用系统以店铺维度，请求支付系统创建交易支付订单，支付系统持久化订单数据，同步返回交易支付订单流水号；

步骤2：上游应用系统组装合并支付请求参数，通过HTTP-POST方式发送请求数据到支付开放平台，支付开放平台得到请求数据后，进行安全校验验证，验证通过后，支付开放平台重定向跳转到支付收银台对应的功能页面；

步骤3：支付收银台合并支付服务校验交易场景，并且根据交易场景返回支持的可用支付方式展示在支付收银台页面；

步骤4：支付收银台请求支付系统合并支付方法，支付系统校验合并订单状态和订单幂等性校验；

步骤5：支付系统生成一笔合并支付批次订单，保存批次订单数据到数据库，并且将批次单单号与合并订单列表做关联，更新保存合并订单列表数据；

步骤6：将合并支付订单推送到消息队列中，消息队列为每个子单执行任务数据；

步骤7：支付系统监听消息队列数据，接收子单处理结果；

步骤8：支付系统获取到子单结果后，请求第三方支付渠道支付；

步骤9：支付系统组装第三方渠道返回的支付串信息，并且返回给前端；

步骤10：前端根据支付串信息唤起微信、支付宝，用户输入密码，完成支付；

步骤11：第三方支付渠道异步通知合并支付订单结果，支付系统更新合并订单状态；

步骤12：支付系统将合并支付订单信息通过消息队列形式推送给上游应用系统，此时支付订单结果推送到消息队列中，让上游应用系统监听消息队列消费。

2.根据权利要求1所述的方法，其特征在于，步骤1中，所述创建交易支付订单是用户在上游应用系统下单后，上游应用系统调用支付系统创建支付交易订单，订单参数包含：买家账户、卖家账户、清分类型、交易金额、商品信息列表、交易名称。

3.根据权利要求2所述的方法，其特征在于，步骤2中，所述支付开放平台负责对外暴露和提供支付交易、管理服务，以及对跳转页面重定向服务，具体包括：以https协议接收服务请求报文和发送结果报文给接入方；对服务的请求和返回报文进行处理，包括：报文的参数检查、认证、权限检查，动态协议序列化或者反序列化，脱敏安全处理，统一日志处理，统一错误处理，响应和通知发送；将通过执行层处理后的报文进行处理，根据业务场景合理调用下层系统，并将返回报文和通知交由执行层处理后，返回给请求方。

4.根据权利要求3所述的方法，其特征在于，步骤3中，所述合并支付服务校验交易场景是指，支付系统通过后台管理系统配置场景类型，根据场景类型查询数据库配置信息，如果存在，则校验通过，如果不存在，则返回不支持该场景类型提示信息。

5.根据权利要求4所述的方法，其特征在于，步骤4包括：

步骤4-1：校验合并支付交易订单状态，遍历订单列表是否包含支付成功、支付中状态的订单，如果包含则不允许发生合并支付；

步骤4-1中，所述订单状态，支付交易订单状态包含：初始状态、支付中、交易成功、交易失败、交易撤销、交易关闭、交易异常；

步骤4-2：进行支付系统订单幂等性校验，表示服务会根据商户订单号参数维持服务的一致性；当用户多次传入相同的商户订单号请求交易时，服务会根据商户订单号对应的实际交易的状态按一致的处理行为进行处理；

所述订单幂等性校验具体步骤包括：根据商户订单号查询交易订单，对查询出来的订单记录添加数据库行级锁，再校验订单状态，如果当前订单关闭时间大于当前时间，则不能够再支付；如果交易订单状态关闭、撤销，则不能够再支付；如果订单状态支付成功，直接返回用户成功，无需重复提交。

6.根据权利要求5所述的方法，其特征在于，步骤4-1中，所述支付交易订单状态包含：初始状态、支付中、交易成功、交易失败、交易撤销、交易关闭、交易异常。

7.根据权利要求6所述的方法，其特征在于，步骤5中，所述批次订单用于记录合并支付交易支付订单，合并支付交易支付订单信息包含：交易场景、付款类型、商户订单号、批次号、批次子订单数量、付款人账户信息、交易金额、订单状态。

8.根据权利要求7所述的方法，其特征在于，步骤6包括：

步骤6-1：消息队列监听到新的订单信息生成后，确定合并支付子订单信息，立刻返回正确的回执；

步骤6-2：支付系统执行根据合并支付订单列表生成多笔对应业务订单的支付交易子订单，并遍历子订单列表向托管银行预下单，托管银行同步返回预下单流水号；

步骤6-3：此时所有支付子订单预下单完成后，把结果发送到消息队列中，让对应服务器消费；

步骤6-2中，所述托管银行是指，公司在没有支付牌照的情形下，店铺卖家在托管银行进行商户注册、开通结算账户，卖家账户资金托管在银行，依托托管银行进行订单对账、资金清结算、商家提现。

9.根据权利要求8所述的方法，其特征在于，步骤6-2中，所述向托管银行预下单是指，合并支付子单在托管银行创建对应的订单，每笔子订单对应一笔托管银行订单，用于支付订单对账和资金分账结算。

10.根据权利要求9所述的方法，其特征在于，步骤7包括：

步骤7-1：消息队列监听到新的订单信息生成后，确定合并支付子订单信息，立刻返回正确的回执；

步骤7-2：支付系统执行根据合并支付订单列表生成多笔对应业务订单的支付交易子订单，并遍历子订单列表向托管银行预下单，托管银行同步返回预下单流水号；

步骤7-3：此时所有支付子订单预下单完成后，把结果发送到消息队列中，让对应服务器消费。

Images