CN115187231A - 订单支付方法、系统、计算机设备及存储介质 - Google Patents

Abstract

本申请提供了一种订单支付方法、系统、计算机设备及存储介质，涉及移动支付技术领域。该方法由交易平台的服务端接收第一客户端针对订单向第二客户端预支付资金的预支付请求，根据预支付请求执行预支付操作生成付款记录；根据付款记录向第一支付中台发送在途充值请求；接收第一客户端的确认支付请求，根据确认支付请求执行分账操作，向第一支付中台发起分账请求，以使得第一支付中台根据分账请求向监管平台发起打款请求，由监管平台根据打款请求将第一客户端对应用户的付款户的预支付资金金额划拨至第二客户端对应用户的收款户。本申请实施例在交易平台引入监管平台作为第三方资金监管机构，解决了资金存管安全问题，减少用户对资金流向的担心。

Description

订单支付方法、系统、计算机设备及存储介质

技术领域

本申请涉及移动支付技术领域，尤其涉及一种订单支付方法、系统、计算机设备及存储介质。

背景技术

在线下实体店交易，人们习惯于一手交钱，一手交货。客户通常只有看到实物后，才会签订交易合同，支付款项，并完成交付手续，这是消费者普遍形成的认知，否则都会被认为是陷阱。

从另外一个角度看，大家都更相信银行。现在的银行业也开始将业务流程尽可能搬到线上，这种线上化、数据化的趋势已经不可逆转。随着科技金融的快速发展，银行从获客方式、线上业务申请、贷款审批、贷款合同签署、在线放款、在线数据归档等全流程都已经实现了线上化，极大地提高了客户获取金融资源的体验感，这也为今后真实的C2C(Customer to Customer，即消费者到消费者)交易提供了金融基础支撑。

随着国家对房地产、教培、医疗、互联网等行业监管力度的加强，银行对公、对私账户的监管力度也随之增强，过去大多是C2B(Customer to Business，即消费者到企业)的账户监管模式，例如新房交易、教育培训等都是这种场景。随着时代的发展，针对大金额交易时间长的C2C银行监管模式也孕育而生，例如二手房交易、二手车交易等需要银行提供监管交易账户来保护买卖双方的资金安全，并按照交易双方所达成协议的要求来执行资金监管和支付时点，这种模式非常适合未来的个体经济的发展。随着区块链技术深入各种场景，个体经济也能实现业务流、资金流、发票流三流合一的业务监管要求。因此需要银行出面做资金监管才是个体买卖双方都需要的资金安全需求，而如何接入银行资金监管成为亟需解决的技术问题。

发明内容

本申请提供一种订单支付方法、系统、计算机设备及存储介质，以解决交易平台的资金存管安全问题。

第一方面，提供了一种订单支付方法，应用于交易平台的服务端，包括：

接收所述交易平台的第一客户端针对订单向第二客户端预支付资金的预支付请求，根据所述预支付请求执行预支付操作生成付款记录；

根据所述付款记录向第一支付中台发送在途充值请求，以使得所述第一支付中台根据所述在途充值请求向监管平台进行在途充值，并发起在途充值记账请求，由所述监管平台在所述第一客户端对应用户的付款户记录包含预支付资金金额的支付账单用于分账；

接收所述第一客户端的确认支付请求，根据所述确认支付请求执行分账操作，向所述第一支付中台发起分账请求，以使得所述第一支付中台根据所述分账请求向所述监管平台发起打款请求，由所述监管平台根据所述打款请求将所述第一客户端对应用户的付款户的预支付资金金额划拨至所述第二客户端对应用户的收款户。

第二方面，提供了一种订单支付方法，应用于交易平台的第一客户端，包括：

响应于针对订单的向第二客户端预支付资金的预支付操作，向所述交易平台的服务端发送针对订单的向所述第二客户端预支付资金的预支付请求，以使所述交易平台的服务端根据所述预支付请求执行预支付操作生成付款记录，并根据所述付款记录向第一支付中台发送在途充值请求，以使得所述第一支付中台根据所述在途充值请求向监管平台进行在途充值，并发起在途充值记账请求，由所述监管平台在所述第一客户端对应用户的付款户记录包含预支付资金金额的支付账单用于分账；

响应于针对订单的确认收货操作，向所述交易平台的服务端发送确认支付请求，以使所述交易平台的服务端根据所述确认支付请求执行分账操作，向所述第一支付中台发起分账请求，以使得所述第一支付中台根据所述分账请求向所述监管平台发起打款请求，由所述监管平台根据所述打款请求将所述第一客户端对应用户的付款户的预支付资金金额划拨至所述第二客户端对应用户的收款户。

第三方面，提供了一种订单支付系统，所述系统包括：交易平台的第一客户端、第二客户端和服务端，第一支付中台，监管平台；

所述第一客户端响应于针对订单的向所述第二客户端预支付资金的预支付操作，向所述交易平台的服务端发送针对订单的向所述第二客户端预支付资金的预支付请求；

所述交易平台的服务端根据所述预支付请求执行预支付操作生成付款记录，并根据所述付款记录向所述第一支付中台发送在途充值请求；

所述第一支付中台根据所述在途充值请求向所述监管平台进行在途充值，并发起在途充值记账请求；

所述监管平台在所述第一客户端对应用户的付款户记录包含预支付资金金额的支付账单用于分账；

所述第一客户端响应于针对订单的确认收货操作，向所述交易平台的服务端发送确认支付请求；

所述交易平台的服务端根据所述确认支付请求执行分账操作，向所述第一支付中台发起分账请求；

所述第一支付中台根据所述分账请求向所述监管平台发起打款请求；

所述监管平台根据所述打款请求将所述第一客户端对应用户的付款户的预支付资金金额划拨至所述第二客户端对应用户的收款户。

第四方面，提供了一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述应用于交易平台的服务端的订单支付方法的步骤或者应用于交易平台的客户端的订单支付方法的步骤。

第五方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述应用于交易平台的服务端的订单支付方法的步骤或者应用于交易平台的客户端的订单支付方法的步骤。

上述订单支付方法、系统、计算机设备及存储介质所实现的方案中，交易平台的服务端接收交易平台的第一客户端针对订单向第二客户端预支付资金的预支付请求，根据预支付请求执行预支付操作生成付款记录；交易平台的服务端根据付款记录向第一支付中台发送在途充值请求，以使得第一支付中台根据在途充值请求向监管平台进行在途充值，并发起在途充值记账请求，由监管平台在第一客户端对应用户的付款户记录包含预支付资金金额的支付账单用于分账；交易平台的服务端接收第一客户端的确认支付请求，根据确认支付请求执行分账操作，向第一支付中台发起分账请求，以使得第一支付中台根据分账请求向监管平台发起打款请求，由监管平台根据打款请求将第一客户端对应用户的付款户的预支付资金金额划拨至第二客户端对应用户的收款户。本申请实施例在交易平台引入监管平台作为第三方资金监管机构，解决了资金存管安全问题，减少用户对资金流向的担心，避免交易平台挪用用户支付的资金。并且，基于安全合规等要求，交易平台没有资质直接对接监管平台，本申请实施例通过具备与监管平台直接对接的能力的第一支付中台暴露服务接口，对接监管平台，有效地解决了交易平台系统调用互联网服务支付的问题。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请一实施例中订单支付方法的一应用环境示意图；

图2是本申请一实施例中应用于交易平台的服务端的订单支付方法的流程示意图；

图3是本申请一实施例中应用于交易平台的第一客户端的订单支付方法的流程示意图；

图4是本申请一实施例中订单支付系统的结构示意图；

图5是本申请另一实施例中订单支付系统的结构示意图；

图6是本申请一实施例中应用于二手车交易时立即订车担保支付的流程示意图；

图7是本申请一实施例中计算机设备的一结构示意图；

图8是本申请一实施例中计算机设备的另一结构示意图。

具体实施方式

下面将参照附图更详细地描述本申请的示例性实施例。虽然附图中显示了本申请的示例性实施例，然而应当理解，可以以各种形式实现本申请而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本申请，并且能够将本申请的范围完整的传达给本领域的技术人员。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”及其变体要被解读为意味着“包括但不限于”的开放式术语。

本申请实施例提供的订单支付方法，可以应用在如图1所示的应用环境中，具体可以包括交易平台的第一客户端、第二客户端和服务端，第一支付中台，第二支付中台，监管平台，第三方支付平台，各个设备之间通过网络进行通信。

在具体应用中，交易平台上的买方可以使用第一客户端与交易平台进行交互，交易平台上的卖方可以使用第二客户端与交易平台进行交互，第一客户端和第二客户端可以分别对接买方和卖方，也可以将功能聚合或融合，作为总的客户端对接买方和卖方，与交易平台进行交互。

第一支付中台具备与监管平台直接对接的能力，第二支付中台具备与第三方支付平台直接对接的能力，第一支付中台和第二支付中台也可以将能力聚合或融合，作为总的支付中台，可以直接对接监管平台和第三方支付平台。

第一客户端和第二客户端可以但不限于各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备等。服务端可以用独立的服务器或者是多个服务器组成的服务器集群来实现。下面通过具体的实施例对本申请进行详细地描述。

请参阅图2所示，图2是本申请一实施例中应用于交易平台的服务端的订单支付方法的流程示意图，可以包括如下步骤S101至S103：

步骤S101，交易平台的服务端接收交易平台的第一客户端针对订单向第二客户端预支付资金的预支付请求，根据预支付请求执行预支付操作生成付款记录。

如前文介绍，交易平台上的买方可以使用第一客户端与交易平台进行交互，买方可以触发第一客户端针对订单提供的预支付页面上的预支付按键，第一客户端响应于针对订单的向第二客户端预支付资金的预支付操作，向交易平台的服务端发送针对订单的向第二客户端预支付资金的预支付请求。这里的预支付请求中可以包括订单号、商户号、业务类型、预支付资金金额、买方用户信息等，本申请实施例对此不作限制。

步骤S102，交易平台的服务端根据付款记录向第一支付中台发送在途充值请求，以使得第一支付中台根据在途充值请求向监管平台进行在途充值，并发起在途充值记账请求，由监管平台在第一客户端对应用户的付款户记录包含预支付资金金额的支付账单用于分账。

如前面介绍，第一支付中台具备与监管平台直接对接的能力，交易平台的服务端根据付款记录向第一支付中台发送在途充值请求，由第一支付中台与监管平台直接对接，由监管平台在第一客户端对应用户的付款户记录包含预支付资金金额的支付账单用于分账。

步骤S103，交易平台的服务端接收第一客户端的确认支付请求，根据确认支付请求执行分账操作，向第一支付中台发起分账请求，以使得第一支付中台根据分账请求向监管平台发起打款请求，由监管平台根据打款请求将第一客户端对应用户的付款户的预支付资金金额划拨至第二客户端对应用户的收款户。

该步骤中，买方收到产品或服务后，可以触发第一客户端针对订单提供的确认页面上的确认支付按键，第一客户端响应于针对订单的确认收货操作，向交易平台的服务端发送确认支付请求。

本申请实施例在交易平台引入监管平台作为第三方资金监管机构，解决了资金存管安全问题，减少用户对资金流向的担心，避免交易平台挪用用户支付的资金。并且，基于安全合规等要求，交易平台没有资质直接对接监管平台，本申请实施例通过具备与监管平台直接对接的能力的第一支付中台暴露服务接口，对接监管平台，有效地解决了交易平台系统调用互联网服务支付的问题。

本申请实施例中提供了一种可能的实现方式，在上文步骤S101交易平台的服务端接收交易平台的第一客户端针对订单向第二客户端预支付资金的预支付请求之前，买方和卖方可以通过交易平台提交实名信息，在监管平台开户，即开设收款户和付款户，具体可以包括以下步骤A1至A4：

步骤A1，交易平台的服务端接收第一客户端和/或第二客户端各自提交的用于在监管平台开户的实名开户信息，记录实名开户信息，并将实名开户信息推送给第一支付中台，由第一支付中台记录实名开户信息。

这里，买方可以通过第一客户端向交易平台的服务端提交用于在监管平台开户的实名开户信息，卖方可以通过第二客户端向交易平台的服务端提交用于在监管平台开户的实名开户信息。

如前面介绍，第一客户端和第二客户端可以分别对接买方和卖方，也可以将功能聚合或融合，作为总的客户端对接买方和卖方，与交易平台进行交互。因此，买方和卖方也可以通过总的客户端向交易平台的服务端提交用于在监管平台开户的实名开户信息。

步骤A2，交易平台的服务端接收第一支付中台返回的实名开户信息记录结果，并根据实名开户信息记录结果更新记录。

步骤A3，交易平台的服务端向第一支付中台发起实名开户请求，以使第一支付中台根据实名开户请求向监管平台发起实名开户，由监管平台开通第一客户端和/或第二客户端对应用户的付款户和收款户。

这里，交易平台的服务端向第一支付中台发起实名开户请求，如果实名开户请求中携带第一客户端对应买方用户的实名开户信息，则监管平台开通第一客户端对应买方用户的付款户和收款户；如果实名开户请求中携带第二客户端对应卖方用户的实名开户信息，则监管平台开通第二客户端对应卖方用户的付款户和收款户。

步骤A4，交易平台的服务端接收第一支付中台基于监管平台提供的开户结果返回的实名开户结果并更新。

本实施例中，可以在作为第三方资金监管机构的监管平台给买卖双方开通收款户和付款户，不属于交易平台的资金账户，与交易平台的资金账户完全独立，交易的资金可以由监管平台监管，买方用户可以放心支付，买卖双方不用担心平台把交易支付的资金挪作他用。

本申请实施例中提供了一种可能的实现方式，上文步骤S101交易平台的服务端根据预支付请求执行预支付操作生成付款记录，可以接入第三方支付平台的能力进行支付，并且基于安全合规等要求，交易平台没有资质直接对接第三方支付平台，本实施例通过具备与第三方支付平台直接对接的能力的第二支付中台暴露服务接口，对接第三方支付平台，解决了交易平台系统调用互联网服务支付的问题。具体实现方案可以包括以下步骤B1至B4：

步骤B1，交易平台的服务端根据预支付请求向第二支付中台发送支付授权令牌token的申请请求，以使第二支付中台根据申请请求生成支付授权token。

该步骤中，申请请求中可以携带交易流水号及第二支付中台预先给交易平台的服务端分配的应用标识appId和密钥secret，以使第二支付中台根据申请请求中的交易流水号及第二支付中台预先给交易平台的服务端分配的应用标识appId和密钥secret生成支付授权token，这样支付授权token中可以包括交易平台信息、交易流水号、支付金额、交易双方信息等内容。

步骤B2，交易平台的服务端接收第二支付中台返回的支付授权token，并生成交易信息。

这里的交易信息可以包括交易流水号、支付金额等信息，本申请实施例对此不作限制。

步骤B3，交易平台的服务端将支付授权token和交易信息返回给第一客户端，由第一客户端通过支付授权token和交易信息调用第二支付中台的指定SDK向第二支付中台获取第三方支付平台的预创建订单号，以使第二支付中台验证支付授权token和交易信息，并在验证通过后向第三方支付平台发起获取预创建订单号的请求，进而接收第三方支付平台返回的预创建订单号；第二支付中台记录预创建订单号并返回给第一客户端；第一客户端根据预创建订单号调用第三方支付平台的指定SDK进行订单支付；第二支付中台接收第三方支付平台返回的订单支付结果。

该步骤中，第二支付中台的指定SDK(Software Development Kit，软件开发工具包)封装了功能和参数，第一客户端可以通过支付授权token和交易信息调用第二支付中台的指定SDK向第二支付中台获取第三方支付平台的预创建订单号。

步骤B4，交易平台的服务端接收第二支付中台通过消息队列MQ通知的订单支付结果，将订单支付结果作为付款记录，根据订单支付结果更新支付状态，并将支付状态返回给第一客户端。

本实施例接入第三方支付平台的能力进行支付，降低了用户付款难度，提高了交易支付效率。

本申请实施例中提供了一种可能的实现方式，交易平台系统还增加对账机制，监管平台可以通过授权查询第三方支付平台的商户后台收款金额与监管平台资金监管账户是否匹配，用户支付记录的金额与分账金额是否一致。监管平台处理的结果没有及时收到时，交易平台系统主动查询更新一致。用户账户的金额通过实时查询展示，避免出现资金不一致的问题。

本申请实施例中提供了一种可能的实现方式，卖方在监管平台的收款户收到资金后，通过第二客户端绑定银行卡可以提现收款账户余额，具体地，通过第二客户端绑定银行卡可以包括以下步骤C1至C6：

步骤C1，交易平台的服务端接收第二客户端提交的用于从监管平台的第二客户端对应用户的收款户提取资金的银行卡信息，并记录。

步骤C2，交易平台的服务端将第二客户端提交的银行卡信息提交给第一支付中台，以使第一支付中台记录第二客户端提交的银行卡信息，并将第二客户端提交的银行卡信息提交给监管平台。

步骤C3，交易平台的服务端接收第一支付中台返回的银行卡信息记录结果，根据银行卡信息记录结果更新记录。

步骤C4，交易平台的服务端向第一支付中台发送获取通信验证码请求，以使第一支付中台根据通信验证码请求向监管平台发起获取通信验证码请求，由监管平台生成合法通信验证码，并向第二客户端对应用户的通信账户发送合法通信验证码，向第一支付中台通知发送结果，由第一支付中台缓存合法通信验证码。

步骤C5，交易平台的服务端接收第二客户端提交的待校验通信验证码，将待校验通信验证码提交给第一支付中台，由第一支付中台根据缓存的合法通信验证码对待校验通信验证码进行校验，在校验通过后，通知监管平台进行银行卡绑定，并更新记录绑卡结果。

步骤C6，交易平台的服务端接收第一支付中台返回的绑卡结果，根据绑卡结果更新银行卡绑定状态。

接下来，通过第二客户端绑定的银行卡提现收款账户余额，可以包括以下步骤D1和D2：

步骤D1，在由监管平台根据打款请求将第一客户端对应用户的付款户的预支付资金金额划拨至第二客户端对应用户的收款户之后，交易平台的服务端接收第二客户端提交的用于从监管平台的第二客户端对应用户的收款户提取资金的请求。

步骤D2，交易平台的服务端将提取资金的请求通过第一支付中台提交给监管平台进行提现操作。

该步骤中，监管平台根据第一支付中台的请求进行提现，将第二客户端对应用户的收款户的资金打款到第二客户端绑定的银行卡账户。

本申请实施例中提供了一种可能的实现方式，交易平台的服务端在用户发起监管平台的账户余额提现的时候，对并发做了校验，指定时长(如10秒等)内同一个交易流水号的请求只能发起一笔交易，若交易记录的状态不符合会进行拦截。具体可以包括以下步骤D11至D15：

步骤D11，交易平台的服务端获取第二客户端提交的提取资金的请求中第二客户端对应用户的标识和业务类型。

步骤D12，交易平台的服务端通过用户的标识和业务类型获取并发锁，并设置并发锁指定时长后自动失效并清除。

步骤D13，当下一次接收第二客户端提交的提取资金的请求后，交易平台的服务端查询是否存在与下一次的第二客户端提交的提取资金的请求中的用户的标识和业务类型对应的并发锁。

步骤D14，若查询到存在与下一次的第二客户端提交的提取资金的请求中的用户的标识和业务类型对应的并发锁，则向第二客户端返回表示不能发起提现的提示信息，且不执行上面步骤D2将提取资金的请求通过第一支付中台提交给监管平台进行提现的操作。

步骤D15，若查询到不存在与下一次的第二客户端提交的提取资金的请求的用户的标识和业务类型对应的并发锁，则通过下一次的第二客户端提交的提取资金的请求的用户的标识和业务类型获取新的并发锁，并设置新的并发锁指定时长后自动失效并清除，且执行上面步骤D2将提取资金的请求通过第一支付中台提交给监管平台进行提现的操作。

本实施例中，交易平台的服务端在用户发起监管平台的账户余额提现的时候，对并发做了校验，指定时长(如10秒等)内同一个交易流水号的请求只能发起一笔交易，若交易记录的状态不符合会进行拦截，可以保证提现的准确性。

本申请实施例中提供了一种可能的实现方式，交易平台的服务端对监管平台支付回调消息做了严格校验，通过交易流水号、用户信息、支付金额等信息匹配，订单状态判断，避免返回的报文被篡改。具体实现方案可以包括以下步骤D21和D22：

步骤D21，在上面步骤D2交易平台的服务端将提取资金的请求通过第一支付中台提交给监管平台进行提现操作，由监管平台将提现结果返回给第一支付中台后，交易平台的服务端接收第一支付中台通过消息队列MQ通知的提现结果，通过提现结果中的交易流水号获取提取资金的请求。

步骤D22，交易平台的服务端比对提现结果和提取资金的请求中的内容，若存在比对不一致的内容，则丢弃提现结果，不执行根据提现结果更新提现状态的操作；若不存在比对不一致的内容，则执行根据提现结果更新提现状态的操作。

该步骤中，比对提现结果和提取资金的请求中的内容可以包括用户信息、支付金额等内容，本实施例对此不作限制。

本实施例交易平台的服务端对监管平台支付回调消息做了严格校验，通过交易流水号、用户信息、支付金额等信息匹配，订单状态判断，避免返回的报文被篡改，保证提现的准确性。

本申请实施例中提供了一种可能的实现方式，上文步骤S103提及的确认支付请求中还携带尾款支付请求信息，可以根据尾款支付请求信息执行尾款支付操作，具体还可以接入第三方支付平台的能力进行支付，交易平台的服务端可以根据尾款支付请求信息向第二支付中台发送支付授权token的申请请求，以使第二支付中台根据申请请求生成支付授权token；交易平台的服务端接收第二支付中台返回的支付授权token，并生成包含交易流水号和尾款支付金额的交易信息；交易平台的服务端将支付授权token和交易信息返回给第一客户端，由第一客户端通过支付授权token和交易信息调用第二支付中台的指定SDK向第二支付中台获取第三方支付平台的预创建订单号，以使第二支付中台验证支付授权token和交易信息，并在验证通过后向第三方支付平台发起获取预创建订单号的请求，进而接收第三方支付平台返回的预创建订单号；第二支付中台记录预创建订单号并返回给第一客户端；第一客户端根据预创建订单号调用第三方支付平台的指定SDK进行尾款支付；第二支付中台接收第三方支付平台返回的尾款支付结果；交易平台的服务端接收第二支付中台通过消息队列MQ通知的尾款支付结果，根据尾款支付结果更新支付状态，并将支付状态返回给第一客户端。

本申请实施例中提供了一种可能的实现方式，如果买方取消交易，则买方可以通过触发第一客户端针对订单提供的确认页面上的取消交易按键，第一客户端响应于针对订单的取消交易操作，向交易平台的服务端发送取消支付请求。交易平台的服务端根据取消支付请求执行退款操作，向第一支付中台发起预支付资金退款请求，以使得第一支付中台根据预支付资金退款请求向监管平台发起退款请求，由监管平台根据退款请求将第一客户端对应用户的付款户的预支付资金金额退回至第一客户端对应用户的收款户。

相应的，图3是本申请一实施例中应用于交易平台的第一客户端的订单支付方法的流程示意图，可以包括如下步骤S301和S302：

步骤S301，第一客户端响应于针对订单的向第二客户端预支付资金的预支付操作，向交易平台的服务端发送针对订单的向第二客户端预支付资金的预支付请求，以使交易平台的服务端根据预支付请求执行预支付操作生成付款记录，并根据付款记录向第一支付中台发送在途充值请求，以使得第一支付中台根据在途充值请求向监管平台进行在途充值，并发起在途充值记账请求，由监管平台在第一客户端对应用户的付款户记录包含预支付资金金额的支付账单用于分账。

如前文介绍，交易平台上的买方可以使用第一客户端与交易平台进行交互，交易平台上的卖方可以使用第二客户端与交易平台进行交互，第一客户端和第二客户端可以分别对接买方和卖方，也可以将功能聚合或融合，作为总的客户端对接买方和卖方，与交易平台进行交互。

买方可以触发第一客户端针对订单提供的预支付页面上的预支付按键，第一客户端响应于针对订单的向第二客户端预支付资金的预支付操作，向交易平台的服务端发送针对订单的向第二客户端预支付资金的预支付请求。这里的预支付请求中可以包括订单号、商户号、业务类型、预支付资金金额、买方用户信息等，本申请实施例对此不作限制。

步骤S302，第一客户端响应于针对订单的确认收货操作，向交易平台的服务端发送确认支付请求，以使交易平台的服务端根据确认支付请求执行分账操作，向第一支付中台发起分账请求，以使得第一支付中台根据分账请求向监管平台发起打款请求，由监管平台根据打款请求将第一客户端对应用户的付款户的预支付资金金额划拨至第二客户端对应用户的收款户。

买方收到产品或服务后，可以触发第一客户端针对订单提供的确认页面上的确认支付按键，第一客户端响应于针对订单的确认收货操作，向交易平台的服务端发送确认支付请求。

本实施例，买卖双方可以通过交易平台实现产品或服务的交易，买方可以使用第一客户端与交易平台进行交互，卖方可以使用第二客户端与交易平台进行交互，第一客户端和第二客户端可以分别对接买方和卖方，也可以将功能聚合或融合，作为总的客户端对接买方和卖方，与交易平台进行交互。在交易平台引入监管平台作为第三方资金监管机构，解决了资金存管安全问题，减少买卖双方用户对资金流向的担心，避免交易平台挪用用户支付的资金。并且，基于安全合规等要求，交易平台没有资质直接对接监管平台，本实施例通过具备与监管平台直接对接的能力的第一支付中台暴露服务接口，对接监管平台，有效地解决了交易平台系统调用互联网服务支付的问题。

相应的，图4是本申请一实施例中订单支付系统的结构示意图，该订单支付系统可以包括交易平台的第一客户端410、第二客户端420和服务端430，第一支付中台440，监管平台450。

在具体应用中，交易平台上的买方可以使用第一客户端410与交易平台的服务端430进行交互，交易平台上的卖方可以使用第二客户端420与交易平台的服务端430进行交互，第一客户端410和第二客户端420可以分别对接买方和卖方，也可以将功能聚合或融合，作为总的客户端对接买方和卖方，与交易平台的服务端430进行交互。第一支付中台440具备与监管平台450 直接对接的能力。

第一客户端410响应于针对订单的向第二客户端420预支付资金的预支付操作，向交易平台的服务端430发送针对订单的向第二客户端420预支付资金的预支付请求；

交易平台的服务端430根据预支付请求执行预支付操作生成付款记录，并根据付款记录向第一支付中台440发送在途充值请求；

第一支付中台440根据在途充值请求向监管平台450进行在途充值，并发起在途充值记账请求；

监管平台450在第一客户端410对应用户的付款户记录包含预支付资金金额的支付账单用于分账；

第一客户端410响应于针对订单的确认收货操作，向交易平台的服务端 430发送确认支付请求；

交易平台的服务端430根据确认支付请求执行分账操作，向第一支付中台440发起分账请求；

第一支付中台440根据分账请求向监管平台450发起打款请求；

监管平台450根据打款请求将第一客户端410对应用户的付款户的预支付资金金额划拨至第二客户端420对应用户的收款户。

图5是本申请另一实施例中订单支付系统的结构示意图，该订单支付系统除了包括图4所示的交易平台的第一客户端410、第二客户端420和服务端430，第一支付中台440，监管平台450，还可以包括第二支付中台510和第三方支付平台520。

第二支付中台510具备与第三方支付平台520直接对接的能力，第一支付中台440和第二支付中台510也可以将能力聚合或融合，作为总的支付中台，可以直接对接监管平台450和第三方支付平台520。

交易平台的服务端430根据预支付请求向第二支付中台发送支付授权令牌token的申请请求；

第二支付中台510根据申请请求生成支付授权token；

交易平台的服务端430接收第二支付中台510返回的支付授权token，并生成交易信息；

交易平台的服务端430将支付授权token和交易信息返回给第一客户端 410，由第一客户端410通过支付授权token和交易信息调用第二支付中台 510的指定SDK向第二支付中台510获取第三方支付平台520的预创建订单号，以使第二支付中台510验证支付授权token和交易信息，并在验证通过后向第三方支付平台520发起获取预创建订单号的请求，进而接收第三方支付平台520返回的预创建订单号；第二支付中台510记录预创建订单号并返回给第一客户端410；第一客户端410根据预创建订单号调用第三方支付平台520的指定SDK进行订单支付；第二支付中台510接收第三方支付平台 520返回的订单支付结果；

交易平台的服务端430接收第二支付中台510通过消息队列MQ通知的订单支付结果，将订单支付结果作为付款记录，根据订单支付结果更新支付状态，并将支付状态返回给第一客户端410。

交易平台可以为买卖双方提供产品或服务的交易，下面以二手车交易为例进行详细介绍，监管平台为平安见证宝。

(1)平安见证宝涉及的业务场景如下：

电商平台的服务场景：买方和卖方通过二手车交易平台提交实名信息，在平安见证宝开户，开通收款户和付款户。再通过绑定银行卡可以提现账户余额。买方用户支付的购车定金可以存放在平安见证宝监管，用户可以放心支付，不用担心二手车交易平台把支付的资金挪作他用。

(2)平安见证宝涉及对接的接口清单如下：

实名开户，给买卖双方开通收款户和付款户，资金由平安见证宝监管，不属于二手车交易平台资金账户。

银行卡绑定，用户收款户的资金是可以提现到银行卡的，需要支持绑定银行卡。

二手车交易平台有用户的钱包账户，通过余额及交易状态查询，可以了解用户自己的账户资金情况。

(3)发起平安见证宝在途充值及分账的全流程参见图6，说明如下：

第一步，买方用户通过第一客户端在订车页面发起订车，先判断第一客户端对应买方用户是否已实名开户。

该步骤中，可以先判断第一客户端对应买方用户是否已在平安见证宝实名开户，这里的第一客户端可以是应用程序或小程序等，本实施例对此不作限制。

第二步，如果未实名开户，先跳转到实名开户，签订相关协议；如果已实名开户，则订车订单会进入待完善车况。

该步骤中，可以参考前文步骤A1至A4的开户方法，此处不再赘述。

第三步，卖方通过第二客户端完善车况，订单变成待买方确认车况。

第四步，买方确认车况后，订单进入待支付。

该步骤中，买方可以付费查询车辆维保报告，具体付费方法可以参考前文步骤B1至B4调用第三方支付平台进行付费，此处不再赘述。

第五步，买方触发第一客户端针对订单提供的预支付页面上的预支付按键，支付购车定金，二手车交易平台生成付款记录，订单变成待发货。二手车交易平台发起在途充值到平安见证宝，买家的付款户会有一笔支付记录用于分账。

该步骤中，二手车交易平台生成付款记录可以参见前文步骤B1至B4调用第三方支付平台支付购车定金，此处不再赘述。二手车交易平台发起在途充值到平安见证宝，买家的付款户会有一笔支付记录用于分账，具体可以参见前文步骤S102介绍，此处不再详细赘述。

第六步，卖家通过二手车交易平台物流代发发货。

第七步，买家通过第一客户端确认收货支付尾款，二手车交易平台向第一支付中台发起分账，以使得第一支付中台根据分账请求向平安见证宝发起打款请求，由平安见证宝根据打款请求将第一客户端对应用户的付款户的预支付资金金额划拨至第二客户端对应用户的收款户，即通过买家的付款户打款给卖家的收款户。这里的第一支付中台可以是汽融支付中台，可以直接对接平安见证宝。

本实施例可以取得下面的技术效果：

1)二手车交易平台引入平安见证宝作为第三方资金监管机构，解决了资金存管安全问题，减少用户对资金流向的担心，避免二手车交易平台挪用用户支付的资金。

2)二手车交易平台属于租赁创新项目，基于安全合规等要求，没有资质直接对接平安见证宝，因此通过汽融支付中台暴露服务，对接平安见证宝，解决了系统调用互联网服务支付的问题。

3)二手车交易平台在用户发起平安见证宝账户余额提现的时候，对并发做了校验，指定时长(如10秒)内同一个交易流水号的只能发起一笔交易，若交易记录的状态不符合也会拦截。

4)二手车交易平台对平安见证宝支付回调消息做了严格校验，通过交易流水号、用户信息、支付金额等信息匹配，订单状态判断，避免返回的报文被篡改。

5)二手车交易平台系统增加了对账机制，平安见证宝可以通过授权查询第三方支付平台的商户后台收款金额与平安见证宝资金监管账户是否匹配，用户支付记录的金额与分账金额是否一致。平安见证宝处理的结果没有及时收到时，二手车交易平台系统主动查询更新一致。用户账户的金额通过实时查询展示，避免出现资金不一致问题。

6)平安见证宝开设的付款户和收款户属于独立账户，与二手车交易平台账户完全独立，实现资金流与信息流分离。

7)系统保障，托管账户系统通过支付企业与金融理财企业双重监管机构严格审查。

8)风险保障，一键关停程序保障，控制账户资金不被盗用。

9)隐私保障，采用金融级账户安全加密技术，最大程度保证用户的账户信息安全。

10)结算保障，交易日当天或第二天快速结算，快速响应用户需求。

11)资金保障，平安见证宝全程监管，所有账户资金进出均由平安见证宝监督完成。

需要说明的是，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。实际应用中，上述所有可能的实施方式可以采用结合的方式任意组合，形成本申请的可能的实施例，在此不再一一赘述。

基于同一发明构思，本申请实施例还提供了一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述订单支付方法的步骤。

在示例性的实施例中，提供了一种计算机设备，该计算机设备可以是服务端，其内部结构图可以如图7所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性和/或易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的客户端通过网络连接通信。该计算机程序被处理器执行时以实现一种订单支付方法的交易平台的服务端侧的功能或步骤。

在示例性的实施例中，提供了一种计算机设备，该计算机设备可以是客户端，其内部结构图可以如图8所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部服务器通过网络连接通信。该计算机程序被处理器执行时以实现一种订单支付方法的交易平台的客户端侧的功能或者步骤。

基于同一发明构思，本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，其中，计算机程序被设置为运行时执行上述任意一个实施例的应用于交易平台的服务端的订单支付方法的步骤或者应用于交易平台的客户端的订单支付方法的步骤。

需要说明的是，上述关于计算机设备或计算机可读存储介质所能实现的功能或步骤，可对应参阅前述方法实施例中，服务端侧以及客户端侧的相关描述，为避免重复，这里不再一一描述。

所属领域的技术人员可以清楚地了解到，上述描述的系统、装置、模块的具体工作过程，可以参考前述方法实施例中的对应过程，为简洁起见，在此不另赘述。

本领域普通技术人员可以理解：本申请的技术方案本质上或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，其包括若干程序指令，用以使得一电子设备(例如个人计算机，服务器，或者网络设备等)在运行所述程序指令时执行本申请各实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM)、随机存取存储器(RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，实现前述方法实施例的全部或部分步骤可以通过程序指令相关的硬件(诸如个人计算机，服务器，或者网络设备等的电子设备)来完成，所述程序指令可以存储于一计算机可读取存储介质中，当所述程序指令被电子设备的处理器执行时，所述电子设备执行本申请各实施例所述方法的全部或部分步骤。

以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：在本申请的精神和原则之内，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案脱离本申请的保护范围。

Claims (10)

1.一种订单支付方法，其特征在于，应用于交易平台的服务端，包括：

接收所述交易平台的第一客户端针对订单向第二客户端预支付资金的预支付请求，根据所述预支付请求执行预支付操作生成付款记录；

根据所述付款记录向第一支付中台发送在途充值请求，以使得所述第一支付中台根据所述在途充值请求向监管平台进行在途充值，并发起在途充值记账请求，由所述监管平台在所述第一客户端对应用户的付款户记录包含预支付资金金额的支付账单用于分账；

接收所述第一客户端的确认支付请求，根据所述确认支付请求执行分账操作，向所述第一支付中台发起分账请求，以使得所述第一支付中台根据所述分账请求向所述监管平台发起打款请求，由所述监管平台根据所述打款请求将所述第一客户端对应用户的付款户的预支付资金金额划拨至所述第二客户端对应用户的收款户。

2.根据权利要求1所述的方法，其特征在于，在接收所述交易平台的第一客户端针对订单向第二客户端预支付资金的预支付请求之前，所述方法还包括：

接收所述第一客户端和/或所述第二客户端各自提交的用于在所述监管平台开户的实名开户信息，记录所述实名开户信息，并将所述实名开户信息推送给所述第一支付中台，由所述第一支付中台记录所述实名开户信息；

接收所述第一支付中台返回的实名开户信息记录结果，并根据所述实名开户信息记录结果更新记录；

向所述第一支付中台发起实名开户请求，以使所述第一支付中台根据所述实名开户请求向所述监管平台发起实名开户，由所述监管平台开通所述第一客户端和/或所述第二客户端对应用户的付款户和收款户；

接收所述第一支付中台基于所述监管平台提供的开户结果返回的实名开户结果并更新。

3.根据权利要求1或2所述的方法，其特征在于，所述确认支付请求中还携带尾款支付请求信息，所述方法还包括：

根据所述尾款支付请求信息执行尾款支付操作。

4.根据权利要求1或2所述的方法，其特征在于，根据所述预支付请求执行预支付操作生成付款记录，包括：

根据所述预支付请求向第二支付中台发送支付授权令牌token的申请请求，以使所述第二支付中台根据所述申请请求生成支付授权token；

接收所述第二支付中台返回的支付授权token，并生成交易信息；

将所述支付授权token和所述交易信息返回给所述第一客户端，由所述第一客户端通过所述支付授权token和所述交易信息调用所述第二支付中台的指定SDK向所述第二支付中台获取第三方支付平台的预创建订单号，以使所述第二支付中台验证所述支付授权token和所述交易信息，并在验证通过后向所述第三方支付平台发起获取预创建订单号的请求，进而接收所述第三方支付平台返回的预创建订单号；所述第二支付中台记录所述预创建订单号并返回给所述第一客户端；所述第一客户端根据所述预创建订单号调用所述第三方支付平台的指定SDK进行订单支付；所述第二支付中台接收所述第三方支付平台返回的订单支付结果；

接收所述第二支付中台通过消息队列MQ通知的所述订单支付结果，将所述订单支付结果作为付款记录，根据所述订单支付结果更新支付状态，并将所述支付状态返回给所述第一客户端。

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

接收所述第二客户端提交的用于从所述监管平台的所述第二客户端对应用户的收款户提取资金的银行卡信息，并记录；

将所述第二客户端提交的银行卡信息提交给所述第一支付中台，以使所述第一支付中台记录所述第二客户端提交的银行卡信息，并将所述第二客户端提交的银行卡信息提交给所述监管平台；

接收所述第一支付中台返回的银行卡信息记录结果，根据所述银行卡信息记录结果更新记录；

向所述第一支付中台发送获取通信验证码请求，以使所述第一支付中台根据所述通信验证码请求向所述监管平台发起获取通信验证码请求，由所述监管平台生成合法通信验证码，并向所述第二客户端对应用户的通信账户发送所述合法通信验证码，向所述第一支付中台通知发送结果，由所述第一支付中台缓存所述合法通信验证码；

接收所述第二客户端提交的待校验通信验证码，将所述待校验通信验证码提交给所述第一支付中台，由所述第一支付中台根据缓存的所述合法通信验证码对所述待校验通信验证码进行校验，在校验通过后，通知所述监管平台进行银行卡绑定，并更新记录绑卡结果；

接收所述第一支付中台返回的绑卡结果，根据所述绑卡结果更新银行卡绑定状态。

6.根据权利要求5所述的方法，其特征在于，在由所述监管平台根据所述打款请求将所述第一客户端对应用户的付款户的预支付资金金额划拨至所述第二客户端对应用户的收款户之后，所述方法还包括：

接收所述第二客户端提交的用于从所述监管平台的所述第二客户端对应用户的收款户提取资金的请求；

将所述提取资金的请求通过所述第一支付中台提交给所述监管平台进行提现操作。

7.一种订单支付方法，其特征在于，应用于交易平台的第一客户端，包括：

响应于针对订单的向第二客户端预支付资金的预支付操作，向所述交易平台的服务端发送针对订单的向所述第二客户端预支付资金的预支付请求，以使所述交易平台的服务端根据所述预支付请求执行预支付操作生成付款记录，并根据所述付款记录向第一支付中台发送在途充值请求，以使得所述第一支付中台根据所述在途充值请求向监管平台进行在途充值，并发起在途充值记账请求，由所述监管平台在所述第一客户端对应用户的付款户记录包含预支付资金金额的支付账单用于分账；

响应于针对订单的确认收货操作，向所述交易平台的服务端发送确认支付请求，以使所述交易平台的服务端根据所述确认支付请求执行分账操作，向所述第一支付中台发起分账请求，以使得所述第一支付中台根据所述分账请求向所述监管平台发起打款请求，由所述监管平台根据所述打款请求将所述第一客户端对应用户的付款户的预支付资金金额划拨至所述第二客户端对应用户的收款户。

8.一种订单支付系统，其特征在于，所述系统包括：交易平台的第一客户端、第二客户端和服务端，第一支付中台，监管平台；

所述第一客户端响应于针对订单的向所述第二客户端预支付资金的预支付操作，向所述交易平台的服务端发送针对订单的向所述第二客户端预支付资金的预支付请求；

所述交易平台的服务端根据所述预支付请求执行预支付操作生成付款记录，并根据所述付款记录向所述第一支付中台发送在途充值请求；

所述第一支付中台根据所述在途充值请求向所述监管平台进行在途充值，并发起在途充值记账请求；

所述监管平台在所述第一客户端对应用户的付款户记录包含预支付资金金额的支付账单用于分账；

所述第一客户端响应于针对订单的确认收货操作，向所述交易平台的服务端发送确认支付请求；

所述交易平台的服务端根据所述确认支付请求执行分账操作，向所述第一支付中台发起分账请求；

所述第一支付中台根据所述分账请求向所述监管平台发起打款请求；

所述监管平台根据所述打款请求将所述第一客户端对应用户的付款户的预支付资金金额划拨至所述第二客户端对应用户的收款户。

9.一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至6中任一项所述订单支付方法的步骤；或者

所述处理器执行所述计算机程序时实现如权利要求7所述订单支付方法的步骤。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至6中任一项所述订单支付方法的步骤；或者

所述计算机程序被处理器执行时实现如权利要求7所述订单支付方法的步骤。

Images