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

Abstract

本申请提供了一种支付方法、系统、计算机设备及存储介质，涉及移动支付技术领域。该方法中交易平台的服务端接收交易平台的客户端发起的由交易平台进行资金支付的支付请求；交易平台的服务端审核支付请求是否满足资金支付的条件；若支付请求满足资金支付的条件，则交易平台的服务端向支付中台发起打款请求，由支付中台根据打款请求进行资金支付，并向交易平台的服务端返回支付结果；交易平台的服务端接收支付中台返回的支付结果，根据支付结果更新支付状态，并将更新的支付状态提供给客户端。本申请实施例能够解决第三方支付平台门槛限制的问题，且不会出现打款金额截留到第三方支付平台，实现便捷安全支付的目的。

Description

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

技术领域

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

背景技术

随着互联网和通信技术的发展，人们越来越习惯通过线上交易平台进行产品或服务的交易，以二手车交易为例，二手车交易平台的业务可以分自营售卖和电商平台，自营售卖可以通过第三方支付平台进行支付，买方或卖方通过第三方支付平台打款到二手车交易平台的平台商户账号，二手车交易平台可以提取资金自由支配。电商平台需要买卖双方通过监管平台开户，支付的金额会通过监管平台监管，二手车交易平台提供担保服务，撮合双方交易。

还有一些业务场景，比如保证金退款，当用户不想享受担保服务，可以通过应用程序或小程序申请退款，由于用户因为违约扣除保证金会继续补缴保证金，因此退款的保证金无法对应某一笔原始支付记录退款；再如卖方的违约金需要通过打款给买方赔偿等。第三方支付平台通过企业账户对私打款有较高的门槛要求，比如商户入驻90天以上，连续30天有交易，单日限额5万，同一个实名用户单笔200元，且不保证第三方支付平台上的账号与本人一致。因此，如何对上述保证金退款或赔偿打款等业务场景进行便捷安全的资金支付成为亟需解决的技术问题。

发明内容

本申请提供一种支付方法、系统、计算机设备及存储介质，以解决对于保证金退款或赔偿打款等业务场景进行便捷安全的资金支付的技术问题。

第一方面，提供了一种支付方法，包括：

交易平台的服务端接收所述交易平台的客户端发起的由所述交易平台进行资金支付的支付请求；

所述交易平台的服务端审核所述支付请求是否满足资金支付的条件；

若所述支付请求满足资金支付的条件，则所述交易平台的服务端向支付中台发起打款请求，由所述支付中台根据所述打款请求进行资金支付，并向所述交易平台的服务端返回支付结果；

所述交易平台的服务端接收所述支付中台返回的支付结果，根据支付结果更新支付状态，并将更新的支付状态提供给所述客户端。

第二方面，提供了一种支付方法，包括：

交易平台的客户端响应于由所述交易平台进行资金支付的支付操作，向所述交易平台的服务端发起由所述交易平台进行资金支付的支付请求，以使所述交易平台的服务端审核所述支付请求是否满足资金支付的条件，若所述支付请求满足资金支付的条件，则向支付中台发起打款请求，由所述支付中台根据所述打款请求进行资金支付，并向所述交易平台的服务端返回支付结果；所述交易平台的服务端接收所述支付中台返回的支付结果，根据支付结果更新支付状态，并将更新的支付状态提供给所述客户端；

所述客户端接收所述交易平台的服务端返回的更新的支付状态。

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

所述客户端响应于由所述交易平台进行资金支付的支付操作，向所述交易平台的服务端发起由所述交易平台进行资金支付的支付请求；

所述交易平台的服务端审核所述支付请求是否满足资金支付的条件，若所述支付请求满足资金支付的条件，则向所述支付中台发起打款请求；

所述支付中台根据所述打款请求进行资金支付，并向所述交易平台的服务端返回支付结果；

所述交易平台的服务端接收所述支付中台返回的支付结果，根据支付结果更新支付状态，并将更新的支付状态提供给所述客户端；

所述客户端接收所述交易平台的服务端返回的更新的支付状态。

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

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

上述支付方法、系统、计算机设备及存储介质所实现的方案中，交易平台的服务端接收交易平台的客户端发起的由交易平台进行资金支付的支付请求；审核支付请求是否满足资金支付的条件；若支付请求满足资金支付的条件，则向支付中台发起打款请求，由支付中台根据打款请求进行资金支付，并向交易平台的服务端返回支付结果；接收支付中台返回的支付结果，根据支付结果更新支付状态，并将更新的支付状态提供给客户端。本申请实施例在审核支付请求满足资金支付的条件时，则向支付中台发起打款请求，由支付中台根据打款请求进行资金支付，支付中台通过银联支付，财资管理系统支付通道直接打款给客户端对应用户的账户，解决第三方支付平台门槛限制的问题，且不会出现打款金额截留到第三方支付平台，实现便捷安全支付的目的。

附图说明

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

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

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

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

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

图5是本申请一实施例中在二手车交易平台保证金退款的流程示意图；

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

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

具体实施方式

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

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

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

在具体应用中，交易平台上的用户可以通过客户端与交易平台的服务端、支付中台、监管平台进行交互，可以在监管平台进行实名开户、银行卡绑定等，可以申请保证金退款或者理赔打款。支付中台具备与监管平台、银联平台直接对接的能力。

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

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

步骤S101，交易平台的服务端接收交易平台的客户端发起的由交易平台进行资金支付的支付请求。

如前面介绍，交易平台上的用户可以通过客户端与交易平台的服务端、支付中台、监管平台进行交互，可以申请保证金退款或者理赔打款等资金支付。具体地，用户可以在交易平台触发进行资金支付的支付操作，向交易平台的服务端发起由交易平台进行资金支付的支付请求。

步骤S102，交易平台的服务端审核支付请求是否满足资金支付的条件。

该步骤中，可以预先设置不同支付请求对应的资金支付的条件。例如，以保证金退款的支付请求为例，可以审核用户不想享受担保服务的原因，具体可以根据保证金退款的支付请求中携带的退款申请原因得到；还可以审核用户当前是否可以申请退款，具体可以判断用户担保金账户是否有足额可以退款，还需要判断是否会影响其他业务流程，比如有买方发起了购物意向、卖方有其他理赔申诉还未结案等。需要说明的是，此处例举仅是示意性的，并不对本申请实施例进行限制。

步骤S103，若支付请求满足资金支付的条件，则交易平台的服务端向支付中台发起打款请求，由支付中台根据打款请求进行资金支付，并向交易平台的服务端返回支付结果。

该步骤中，由支付中台根据打款请求进行资金支付，支付中台可以通过银联支付，财资管理系统支付通道直接打款给客户端对应用户的账户，这里的用户的账户可以是用户的银行卡账户。

步骤S104，交易平台的服务端接收支付中台返回的支付结果，根据支付结果更新支付状态，并将更新的支付状态提供给客户端。

该步骤中，用户触发的状态可以是待支付和支付中，以保证金退款为例，当用户发起退款申请，就会有一笔待支付的打款记录；当审核通过就会变成支付中；支付中台返回支付结果，然后根据支付结果的状态匹配，可以包括支付成功和支付失败两种支付状态。

本申请实施例中交易平台的服务端接收交易平台的客户端发起的由交易平台进行资金支付的支付请求；审核支付请求是否满足资金支付的条件；若支付请求满足资金支付的条件，则向支付中台发起打款请求，由支付中台根据打款请求进行资金支付，并向交易平台的服务端返回支付结果；接收支付中台返回的支付结果，根据支付结果更新支付状态，并将更新的支付状态提供给客户端。本申请实施例在审核支付请求满足资金支付的条件时，则向支付中台发起打款请求，由支付中台根据打款请求进行资金支付，支付中台通过银联支付，财资管理系统支付通道直接打款给客户端对应用户的账户，解决第三方支付平台门槛限制的问题，且不会出现打款金额截留到第三方支付平台，实现便捷安全支付的目的。

本申请实施例中提供了一种可能的实现方式，上面步骤S101中提及的支付请求可以包括保证金退款请求或者理赔打款请求，则步骤S102审核支付请求是否满足资金支付的条件，具体可以是审核保证金退款请求是否满足保证金退款资金支付的条件；或者审核理赔打款请求是否满足理赔资金支付的条件。

以保证金退款的支付请求为例，可以审核用户不想享受担保服务的原因，具体可以根据保证金退款的支付请求中携带的退款申请原因得到；还可以审核用户当前是否可以申请退款，具体可以判断用户担保金账户是否有足额可以退款，还需要判断是否会影响其他业务流程，比如有买方发起了购物意向、卖方有其他理赔申诉还未结案等。

以理赔打款的支付请求为例，可以审核用户申请理赔打款的原因，具体可以根据理赔打款的支付请求中携带的申请原因得到；还可以审核理赔方的保证金是否有足额可以理赔等，本申请实施例对此不作限制。

本申请实施例中提供了一种可能的实现方式，用户入驻交易平台会做实名认证，保证资金支付的安全和服务的质量。具体地，在上文步骤S101接收交易平台的客户端发起的由交易平台进行资金支付的支付请求之前，可以包括以下步骤A1至A4：

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

该步骤中，监管平台可以为第三方资金监管机构，由于安全合规等要求，交易平台暂时没有直接对接监管平台的能力，因而通过具备与监管平台直接对接的支付中台，将名开户信息推送给支付中台，由支付中台记录实名开户信息。

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

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

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

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

本申请实施例中提供了一种可能的实现方式，在上文步骤S101接收交易平台的客户端发起的由交易平台进行资金支付的支付请求之前，还可以包括以下步骤B1至B6：

步骤B1，交易平台的服务端接收客户端提交的用于提取交易平台的支付资金的银行卡信息，并记录。

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

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

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

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

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

本申请实施例中，因为用户入驻交易平台会做实名认证，用户添加的银行卡信息，会先到监管平台校验，通过手机号验证码加上姓名、银行卡号、银行支行、总行信息等，校验通过后，银行卡才算添加成功，保证金退款或者理赔打款选择银行卡的时候只能选择验证通过的银行卡。这样保证了资金支付的安全性，同时解决了企业对公账户打款给第三方支付平台上账号可能与本人信息不一致的问题。

本申请实施例中提供了一种可能的实现方式，上文步骤S102交易平台的服务端审核支付请求是否满足资金支付的条件之后，若支付请求满足资金支付的条件，则交易平台的服务端可以生成表示支付中的支付状态，进而将生成的表示支付中的支付状态提交给客户端。这样可以及时准确地将支付信息同步给客户端，提高信息共享的效率。

本申请实施例中提供了一种可能的实现方式，上文步骤S102交易平台的服务端审核支付请求是否满足资金支付的条件之后，若支付请求不满足资金支付的条件，则交易平台的服务端可以生成表示支付请求不满足资金支付的条件的提示信息，进而将生成的表示支付请求不满足资金支付的条件的提示信息提交给客户端。

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

步骤S301，交易平台的客户端响应于由交易平台进行资金支付的支付操作，向交易平台的服务端发起由交易平台进行资金支付的支付请求，以使交易平台的服务端审核支付请求是否满足资金支付的条件，若支付请求满足资金支付的条件，则向支付中台发起打款请求，由支付中台根据打款请求进行资金支付，并向交易平台的服务端返回支付结果；交易平台的服务端接收支付中台返回的支付结果，根据支付结果更新支付状态，并将更新的支付状态提供给客户端。

如前面介绍，交易平台上的用户可以通过客户端与交易平台的服务端、支付中台、监管平台进行交互，可以申请保证金退款或者理赔打款等资金支付。具体地，用户可以在交易平台触发进行资金支付的支付操作，向交易平台的服务端发起由交易平台进行资金支付的支付请求。

步骤S302，交易平台的客户端接收交易平台的服务端返回的更新的支付状态。

该步骤中，用户触发的状态可以是待支付和支付中，以保证金退款为例，当用户发起退款申请，就会有一笔待支付的打款记录；当审核通过就会变成支付中；支付中台返回支付结果，然后根据支付结果的状态匹配，可以包括支付成功和支付失败两种支付状态。

待支付的订单可以重新发起打款支付；支付中的只能通过对账更新为支付成功或者支付失败，不允许重复支付；支付失败的允许重新发起支付；已取消的支付订单不再发起支付，会创建新的支付流水发起支付。

本申请实施例在审核支付请求满足资金支付的条件时，则向支付中台发起打款请求，由支付中台根据打款请求进行资金支付，支付中台通过银联支付，财资管理系统支付通道直接打款给客户端对应用户的账户，解决第三方支付平台门槛限制的问题，且不会出现打款金额截留到第三方支付平台，实现便捷安全支付的目的。

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

在具体应用中，交易平台上的用户可以通过客户端410与交易平台的服务端420、支付中台430、监管平台440进行交互，可以在监管平台440进行实名开户、银行卡绑定等，可以申请保证金退款或者理赔打款。支付中台430具备与监管平台440、银联平台直接对接的能力。

客户端410响应于由交易平台进行资金支付的支付操作，向交易平台的服务端420发起由交易平台进行资金支付的支付请求；

交易平台的服务端420审核支付请求是否满足资金支付的条件，若支付请求满足资金支付的条件，则向支付中台430发起打款请求；

支付中台430根据打款请求进行资金支付，并向交易平台的服务端420返回支付结果；

交易平台的服务端420接收支付中台430返回的支付结果，根据支付结果更新支付状态，并将更新的支付状态提供给客户端410；

客户端410接收交易平台的服务端420返回的更新的支付状态。

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

(1)银联支付，平安财资管理系统TMS支付通道涉及的业务场景如下：

保证金退款、理赔打款等。用户需要先绑定银行卡，再通过银联支付和TMS支付通道企业对公账户打款给对私账户。

(2)打款支付对应的状态如下：

待支付的订单可以重新发起打款支付。支付中的只能通过对账更新为支付成功或者支付失败，不允许重复支付。支付失败的允许重新发起支付。已取消的支付订单不再发起支付，会创建新的支付流水发起支付。

用户触发的状态可以有待支付和支付中，可以进行状态匹配。当用户发起退款申请，就会有一笔待支付的打款记录；当财务审核通过就会变成支付中；支付中台返回支付结果，然后根据支付结果的状态匹配，可以包括支付成功和支付失败两种状态。

(3)保证金退款发起银联支付，TMS支付通道全流程参见图5，交易平台的客户端可以是小程序，支付中台可以是汽融支付中台，监管平台可以是见证宝服务，详细说明如下：

第一步，用户通过小程序在保证金账户页面发起退款申请。

第二步，未实名开户的，先跳转到实名开户，签订相关协议。已实名开户的，判断是否有提现银行卡，没有则需要添加银行卡。

该步骤中，用户入驻交易平台会做实名认证，保证资金支付的安全和服务的质量，具体可以参见前文步骤A1至A4的详细介绍，此处不再赘述。

因为用户入驻交易平台会做实名认证，用户添加的银行卡信息，会先到监管平台校验，通过手机号验证码加上姓名、银行卡号、银行支行、总行信息等，校验通过后，银行卡才算添加成功，保证金退款或者理赔打款选择银行卡的时候只能选择验证通过的银行卡。这样保证了资金支付的安全性，同时解决了企业对公账户打款给第三方支付平台上账号可能与本人信息不一致的问题。具体的实现方案可以参见前文步骤B1至B6的详细介绍，此处不再赘述。

第三步，选择提现的银行卡。

第四步，运营审核退款申请记录，拒绝则结束；同意则进入财务审核。

第五步，财务审核拒绝，则退回运营审核重新提交；财务审核通过，则发起打款。

第六步，打款调用支付中台服务，通过TMS通道打款给用户。

在第四步和第五步中，可以预先设置资金支付的条件，可以分运营侧审核和财务审核，例如，在运营侧可以审核用户不想享受担保服务的原因，具体可以根据保证金退款的支付请求中携带的退款申请原因得到；还可以审核用户当前是否可以申请退款，具体可以判断是否会影响其他业务流程，比如有买方发起了购物意向、卖方有其他理赔申诉还未结案等。在财务侧可以审核提交的信息是否正确、用户担保金账户是否有足额可以退款等，审核意见可以有同意和拒绝的选项，可以加上备注信息。

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

1)由支付中台根据打款请求进行资金支付，支付中台通过银联支付，财资管理系统TMS支付通道直接打款给客户端对应用户的账户，解决第三方支付平台门槛限制的问题。

2)因为用户入驻交易平台会做实名认证，用户添加的银行卡信息，会先到监管平台校验，通过手机号验证码加上姓名、银行卡号、银行支行、总行信息等，校验通过后，银行卡才算添加成功，保证金退款或者理赔打款选择银行卡的时候只能选择验证通过的银行卡。这样保证了资金支付的安全性，同时解决了企业对公账户打款给第三方支付平台上账号可能与本人信息不一致的问题。

3)解决了用户发起理赔后，需要将理赔款打款给用户银行卡的问题。银联支付打款比其他方式更快捷，直接到账用户银行卡，不会出现打款金额截留到第三方支付平台，需要提现并且收取提现手续费。

4)打通了交易平台与用户直接支付的通道，无需通过第三方支付平台，并且第三方支付平台提供服务也需要收取手续费。

5)弥补了第三方支付平台和平安见证宝的不足，为用户提供了第三种支付渠道。

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

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

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

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

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

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

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

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

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

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

Claims (10)

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

交易平台的服务端接收所述交易平台的客户端发起的由所述交易平台进行资金支付的支付请求；

所述交易平台的服务端审核所述支付请求是否满足资金支付的条件；

若所述支付请求满足资金支付的条件，则所述交易平台的服务端向支付中台发起打款请求，由所述支付中台根据所述打款请求进行资金支付，并向所述交易平台的服务端返回支付结果；

所述交易平台的服务端接收所述支付中台返回的支付结果，根据支付结果更新支付状态，并将更新的支付状态提供给所述客户端。

2.根据权利要求1所述的方法，其特征在于，所述支付请求包括保证金退款请求或者理赔打款请求；

所述交易平台的服务端审核所述支付请求是否满足资金支付的条件，包括：

所述交易平台的服务端审核所述保证金退款请求是否满足保证金退款资金支付的条件；或者

所述交易平台的服务端审核所述理赔打款请求是否满足理赔资金支付的条件。

3.根据权利要求1或2所述的方法，其特征在于，在交易平台的服务端接收所述交易平台的客户端发起的由所述交易平台进行资金支付的支付请求之前，所述方法还包括：

所述交易平台的服务端接收所述客户端提交的用于在监管平台开户的实名开户信息，记录所述实名开户信息，并将所述实名开户信息推送给所述支付中台，由所述支付中台记录所述实名开户信息；

所述交易平台的服务端接收所述支付中台返回的实名开户信息记录结果，并根据所述实名开户信息记录结果更新记录；

所述交易平台的服务端向所述支付中台发起实名开户请求，以使所述支付中台根据所述实名开户请求向所述监管平台发起实名开户，由所述监管平台开通所述客户端对应用户的付款户和收款户；

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

4.根据权利要求1或2所述的方法，其特征在于，在交易平台的服务端接收所述交易平台的客户端发起的由所述交易平台进行资金支付的支付请求之前，所述方法还包括：

所述交易平台的服务端接收所述客户端提交的用于提取所述交易平台的支付资金的银行卡信息，并记录；

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

所述交易平台的服务端接收所述支付中台返回的银行卡信息记录结果，根据所述银行卡信息记录结果更新记录；

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

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

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

5.根据权利要求1或2所述的方法，其特征在于，若所述支付请求满足资金支付的条件，所述方法还包括：

所述交易平台的服务端生成表示支付中的支付状态；

所述交易平台的服务端将生成的表示支付中的支付状态提交给所述客户端。

6.根据权利要求1或2所述的方法，其特征在于，在所述交易平台的服务端审核所述支付请求是否满足资金支付的条件之后，所述方法还包括：

若所述支付请求不满足资金支付的条件，则所述交易平台的服务端生成表示所述支付请求不满足资金支付的条件的提示信息；

所述交易平台的服务端将生成的表示所述支付请求不满足资金支付的条件的提示信息提交给所述客户端。

7.一种支付方法，其特征在于，包括：

交易平台的客户端响应于由所述交易平台进行资金支付的支付操作，向所述交易平台的服务端发起由所述交易平台进行资金支付的支付请求，以使所述交易平台的服务端审核所述支付请求是否满足资金支付的条件，若所述支付请求满足资金支付的条件，则向支付中台发起打款请求，由所述支付中台根据所述打款请求进行资金支付，并向所述交易平台的服务端返回支付结果；所述交易平台的服务端接收所述支付中台返回的支付结果，根据支付结果更新支付状态，并将更新的支付状态提供给所述客户端；

所述客户端接收所述交易平台的服务端返回的更新的支付状态。

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

所述客户端响应于由所述交易平台进行资金支付的支付操作，向所述交易平台的服务端发起由所述交易平台进行资金支付的支付请求；

所述交易平台的服务端审核所述支付请求是否满足资金支付的条件，若所述支付请求满足资金支付的条件，则向所述支付中台发起打款请求；

所述支付中台根据所述打款请求进行资金支付，并向所述交易平台的服务端返回支付结果；

所述交易平台的服务端接收所述支付中台返回的支付结果，根据支付结果更新支付状态，并将更新的支付状态提供给所述客户端；

所述客户端接收所述交易平台的服务端返回的更新的支付状态。

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

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

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

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

Images