一种第三方支付处理系统及方法与流程

本发明涉及通信技术领域，尤其涉及一种第三方支付处理系统及方法。

背景技术：

近年来，随着数字化科技不断革新，支付作为经济活动的基础性服务，不仅改变着人们的消费行为,并且在线下线上消费场景中发挥着越来越重要的作用。现有很多大中型第三方支付平台向商户只提供一个软件开发工具包(简称sdk)，让开发者在项目接入sdk调用里面应用程序接口(简称api)，其中有发起支付，退款，支付查询，退款查询等api，发起支付api因结合多个支付渠道，称作聚合支付，这种支付让商户在任何平台和场景接入多个支付渠道。

但是，sdk的更新迭代较慢，如果出现性能问题，第三方支付平台一般不会轻易修改，除非是严重漏洞。而且sdk的接入有可能和其他扩展sdk发生兼容性问题。

技术实现要素：

本发明实施例的目的是提供一种第三方支付处理系统及方法，通过在后台配置支付渠道，实现不用接入sdk，也能满足在不同平台和场景的接入支付功能，解决了sdk的更新慢和兼容问题。

为实现上述目的，本发明一实施例提供了一种第三方支付处理系统，所述系统包括客户端、支付模块、公司平台、第三方支付平台和后台；其中，

所述客户端，用于获取所述后台的支付渠道并进行选择，根据选择的所述支付渠道向所述支付模块发起支付请求；

所述支付模块，用于接收所述支付请求并向所述公司平台发送验证请求，当验证不通过时，将验证不通过的结果返回所述客户端；当验证通过时，向第三方支付平台发送请求并接收所述第三方支付平台返回的响应参数，同时对所述响应参数进行处理，并将处理结果返回所述客户端；

所述公司平台，用于接收所述验证请求，并根据所述验证请求中的订单数据验证所述验证请求的有效性，同时将验证结果返回所述支付模块；其中，所述验证结果包括验证不通过和验证通过两种；

所述第三方支付平台，用于接收所述支付模块发送的请求，并对所述请求进行处理，和将所述响应参数返回所述支付模块；

所述后台，用于配置所述支付渠道；其中，所述支付渠道包括分期支付渠道和不分期支付渠道两种。

优选地，所述后台包括分期支付模块和不分期支付模块；其中

所述分期支付模块，用于创建一个第一父级支付渠道，再在所述第一父级支付渠道下创建第一基础配置、子支付方式和第一订单配置；其中，所述子支付方式与所述第一父级支付渠道进行绑定；

所述不分期支付模块，用于创建一个第二父级支付渠道，再在所述第二父级支付渠道下创建第二基础配置和第二订单配置。

优选地，所述分期支付模块还用于在所述子支付方式下创建一个子级支付渠道，再在所述子级支付渠道下创建第三基础配置、分期配置和第三订单配置。

优选地，所述客户端还用于展示支付结果；其中，所述支付结果包括支付金额和选择的所述支付渠道。

本发明另一实施例提供了一种第三方支付处理方法，所述方法包括以下步骤：

后台预先配置多种支付渠道；

客户端选择一种支付渠道，并向支付模块发起支付请求；

支付模块根据接收到的所述支付请求向公司平台发送验证请求；

公司平台验证所述验证请求的有效性，并将验证结果返回所述支付模块；其中，所述验证结果包括验证不通过和验证通过两种；

当所述验证结果为验证不通过时，所述支付模块将验证不通过对应的验证结果返回所述客户端；当所述验证结果为验证通过时，所述支付模块向第三方支付平台发送请求，请求所述第三方支付平台响应所述支付请求；

所述第三方支付平台对所述请求进行处理，并将响应参数返回所述支付模块；

所述支付模块对接收到的所述响应参数进行处理，并将处理结果返回所述客户端；

所述客户端根据所述处理结果完成支付，并展示支付结果。

优选地，所述后台预先配置多种支付渠道，具体包括：

所述后台预先配置分期支付渠道和不分期支付渠道两种支付渠道。

优选地，所述后台预先配置分期支付渠道和不分期支付渠道两种支付渠道，具体包括：

所述后台预先创建一个第一父级支付渠道，再在所述第一父级支付渠道下创建第一基础配置、子支付方式和第一订单配置；其中，所述子支付方式与所述第一父级支付渠道进行绑定；

所述后台预先创建一个第二父级支付渠道，再在所述第二父级支付渠道下创建第二基础配置和第二订单配置。

优选地，所述在所述第一父级支付渠道下第一基础配置、子支付方式和第一订单配置之后，还包括：

在所述子支付方式下创建一个子级支付渠道，再在所述子级支付渠道下创建第三基础配置、分期配置和第三订单配置。

优选地，所述公司平台验证所述验证请求的有效性，并将验证结果返回所述支付模块，具体包括：

所述公司平台接收到所述验证请求后，获取所述验证请求中的订单数据；

根据所述订单数据验证所述验证请求的有效性，并将验证结果返回所述支付模块。

与现有技术相比，本发明实施例所提供的一种第三方支付处理系统及方法，通过在系统后台配置支付渠道，不需要接入sdk，不会出现不同软件开发工具包之间的冲突，从而实现快速迭代的功能，而且在不同平台和场景都能接入支付功能，极大方便了人们的支付需求。

附图说明

图1是本发明一实施例提供的一种第三方支付处理系统的示意图；

图2是本发明一实施例提供的一种后台配置支付渠道的结构示意图；

图3是本发明一实施例提供的一种客户端展示支付结果的示意图；

图4是本发明一实施例提供的一种第三方支付处理方法的流程示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

参见图1，是本发明实施例1提供的一种第三方支付处理系统的示意图，所述系统包括客户端、支付模块、公司平台、第三方支付平台和后台；其中，

所述客户端，用于获取所述后台的支付渠道并进行选择，根据选择的所述支付渠道向所述支付模块发起支付请求；

所述支付模块，用于接收所述支付请求并向所述公司平台发送验证请求，当验证不通过时，将验证不通过的结果返回所述客户端；当验证通过时，向第三方支付平台发送请求并接收所述第三方支付平台返回的响应参数，同时对所述响应参数进行处理，并将处理结果返回所述客户端；

所述公司平台，用于接收所述验证请求，并根据所述验证请求中的订单数据验证所述验证请求的有效性，同时将验证结果返回所述支付模块；其中，所述验证结果包括验证不通过和验证通过两种；

所述第三方支付平台，用于接收所述支付模块发送的请求，并对所述请求进行处理，和将所述响应参数返回所述支付模块；

所述后台，用于配置所述支付渠道；其中，所述支付渠道包括分期支付渠道和不分期支付渠道两种。

具体地，系统包括客户端、支付模块、公司平台、第三方支付平台和后台；其中，

客户端，用于获取后台的支付渠道并进行选择，根据选择的支付渠道向支付模块发起支付请求。客户端不需要接入sdk，而是直接与系统的后台建立连接，获取预先在后台配置好的支付渠道，从中选择一种支付渠道，并向支付模块发起支付请求，整个过程都是采用发起支付应用程序接口(简称发起支付api)进行连接的。优选地，本发明的发起支付api采用http协议，相比于传统的第三方支付方式利用sdk，采用socket与服务器连接，本发明的灵活性更强。

支付模块，用于接收客户端发送过来的支付请求并向公司平台发送验证请求，并接收公司平台返回的验证结果。验证请求包括支付通道编码和支付类型编码，其中，支付通道编码是整型数字，支付类型编码是字符串。支付通道编码和支付类型编码存在父子关系。当验证不通过时，将验证不通过的结果返回客户端；当验证通过时，会根据验证请求中的支付通道编码和支付类型编码向对应的第三方支付平台发送请求并接收该第三方支付平台返回的响应参数，同时对响应参数进行处理，并将处理结果返回客户端。向第三方支付平台发送请求，主要是调起第三方支付平台对支付请求的响应。当请求成功后，会记录请求结果和请求参数，增加支付流水，并将请求结果和请求参数进行封装处理，然后返回客户端。

为了更好地说明验证请求中的支付通道编码和支付类型编码，以下利用一个例子进行说明，例如微信支付，分别有app支付，jsapi支付，native支付。为了做一个区分。支付类型编码会定义为wxpay作为父级；app支付支付通道编码为1，jsapi支付通道编码为2，native支付通道编码为3，作为子级。

公司平台，用于接收支付模块发送的验证请求，并根据验证请求中的订单数据验证验证请求的有效性，同时将验证结果返回支付模块；其中，验证结果包括验证不通过和验证通过两种。订单数据包括订单单号和订单类型，公司平台可以为多个，订单类型可以为第一公司平台的预售订单、第一公司平台的正常订单、第二公司平台的买家保证金、第三公司平台的商品租赁等等。在验证时利用rpc(远程调用服务)方式调用其他应用提供接口，验证结果通过接口返回布尔值(boolen)：true或false，其中，true代表验证通过，false代表验证不通过。

第三方支付平台，用于接收支付模块发送的请求，并对请求进行处理，和将响应参数返回支付模块。一般地，第三方支付平台有多个，例如：支付宝支付，微信支付，银联，京东支付，花呗分期，汇聚支付等等。

后台，用于配置支付渠道，采用接口与客户端快速建立连接，方便客户端发起支付请求。其中，支付渠道包括分期支付渠道和不分期支付渠道两种。一般地，后台还配置有查看相关流水记录，手动添加流水，导出流水，帐号权限等等功能。正因为本发明是利用后台进行支付渠道的配置，不需要接入sdk，不会出现不同软件开发工具包之间的冲突，从而实现快速迭代的功能。

本发明实施例1通过提供一种第三方支付处理系统，通过在系统后台配置支付渠道，不需要接入sdk，不会出现不同软件开发工具包之间的冲突，从而实现快速迭代的功能，而且在不同平台和场景都能接入支付功能，极大方便了人们的支付需求。

作为上述方案的改进，所述后台包括分期支付模块和不分期支付模块；其中

所述分期支付模块，用于创建一个第一父级支付渠道，再在所述第一父级支付渠道下创建第一基础配置、子支付方式和第一订单配置；其中，所述子支付方式与所述第一父级支付渠道进行绑定；

所述不分期支付模块，用于创建一个第二父级支付渠道，再在所述第二父级支付渠道下创建第二基础配置和第二订单配置。

具体地，参见图2，是本发明该实施例提供的一种后台配置支付渠道的结构示意图。由图2可知，后台包括分期支付模块和不分期支付模块；其中，

分期支付模块，用于创建一个第一父级支付渠道，再在第一父级支付渠道下创建第一基础配置、子支付方式和第一订单配置；其中，子支付方式与第一父级支付渠道进行绑定，建立关系。其中，第一基础配置包括支付方式icon、支付方式名称、展示客户端、是否展示和支付描述，展示客户端包括app、h5、微信浏览器和微信小程序等。第一订单配置包括选择支付限定，主要用于定义支付渠道可用于何种订单类型。

不分期支付模块，用于创建一个第二父级支付渠道，再在第二父级支付渠道下创建第二基础配置和第二订单配置。同样地，第二基础配置也包括支付方式icon、支付方式名称、展示客户端、是否展示和支付描述，展示客户端包括app、h5、微信浏览器和微信小程序等。第二订单配置包括选择支付限定。

正因为后台设置了是否展示功能，所以有权限决定每个支付渠道是否进行展示，支付渠道也会根据订单类型进行过滤展示，所以当发现支付渠道异常时可以马上进行隐藏，达到闭关，以提高支付安全性能。

作为上述方案的改进，所述分期支付模块还用于在所述子支付方式下创建一个子级支付渠道，再在所述子级支付渠道下创建第三基础配置、分期配置和第三订单配置。

具体地，分期支付模块还用于在子支付方式下创建一个子级支付渠道，再在子级支付渠道下创建第三基础配置、分期配置和第三订单配置。子级支付渠道与第一父级支付渠道是类似的，所以两者的配置也是类似的，相同之处在于，第三基础配置也包括支付方式icon、支付方式名称、展示客户端、是否展示和支付描述，展示客户端包括app、h5、微信浏览器和微信小程序等。第三订单配置包括选择支付限定。不同之处在于，分期配置包括添加期数和设置每期费率。

作为上述方案的改进，所述客户端还用于展示支付结果；其中，所述支付结果包括支付金额和选择的所述支付渠道。

具体地，客户端还用于展示支付结果；其中，支付结果包括支付金额和选择的支付渠道，具体可参见图3，是本发明该实施例提供的一种客户端展示支付结果的示意图。当然，客户端也可以选择不展示支付结果，可根据个人需求进行调整。

参见图4，是本发明实施例2提供的一种第三方支付处理方法的流程示意图。所述方法包括步骤s1至步骤s8：

s1、后台预先配置多种支付渠道；

s2、客户端选择一种支付渠道，并向支付模块发起支付请求；

s3、支付模块根据接收到的所述支付请求向公司平台发送验证请求；

s4、公司平台验证所述验证请求的有效性，并将验证结果返回所述支付模块；其中，所述验证结果包括验证不通过和验证通过两种；

s5、当所述验证结果为验证不通过时，所述支付模块将验证不通过对应的验证结果返回所述客户端；当所述验证结果为验证通过时，所述支付模块向第三方支付平台发送请求，请求所述第三方支付平台响应所述支付请求；

s6、所述第三方支付平台对所述请求进行处理，并将响应参数返回所述支付模块；

s7、所述支付模块对接收到的所述响应参数进行处理，并将处理结果返回所述客户端；

s8、所述客户端根据所述处理结果完成支付，并展示支付结果。

具体地，后台预先配置多种支付渠道，通过接入一个api与所有主流的支付渠道建立连接，以便客户端发起支付请求。

客户端与后台建立连接后，可以获取后台提供的多种支付渠道，根据个人需求选择一种支付渠道，然后根据选择的支付渠道向支付模块发起支付请求。

支付模块根据接收到的支付请求向公司平台发送验证请求；其中，验证请求包括支付通道编码和支付类型编码，支付通道编码是整型数字，支付类型编码是字符串。

公司平台验证验证请求的有效性，具体是根据验证请求中订单数据进行验证，订单数据包括订单单号和订单类型。验证结束后，公司平台将验证结果返回支付模块；其中，验证结果包括验证不通过和验证通过两种。

当验证结果为验证不通过时，支付模块将验证不通过对应的验证结果返回客户端；当验证结果为验证通过时，支付模块向第三方支付平台发送请求，请求第三方支付平台响应支付请求。

第三方支付平台对请求进行处理，并相应产生响应参数，同时将响应参数返回支付模块。

支付模块对接收到的响应参数进行处理，并将处理结果返回客户端。一般地，当请求成功，系统会利用mysql和阿里云日志服务记录请求结果和请求参数，以增加支付流水，主要是为了方便日后出现异常时进行排查。同时还会将请求结果和请求参数进行封装处理，以返回给客户端，这是为了解决每接入一个新的第三方支付平台，前端都要对应开发、发布和审核的繁琐问题。所以前后端订好一个规则：前端会根据后端返回类型做出对应操作。返回类型有：后端返回form表单，前端直接提交，前端构建form表单，前端get后端返回连接，前端跳转app；后端返回连接，前端生成二维码(pc)，前端跳转小程序。例如微信支付jsapi支付，后端会把前端需要调起微信支付的参数封装成转义后json字符串。

客户端根据处理结果完成支付，并展示支付结果，具体可参见图3。

本发明实施例2通过提供一种第三方支付处理方法，通过在系统后台预先配置支付渠道，不需要接入sdk，不会出现不同软件开发工具包之间的冲突，从而实现快速迭代的功能，而且在不同平台和场景都能接入支付功能，极大方便了人们的支付需求。

作为上述方案的改进，所述后台预先配置多种支付渠道，具体包括：

所述后台预先配置分期支付渠道和不分期支付渠道两种支付渠道。

具体地，后台预先配置分期支付渠道和不分期支付渠道两种支付渠道，主要为了满足人们不同的支付需求，对于支付金额小的，可以选择不分期支付渠道，对于支付金额大的，可以选择分期支付渠道。

作为上述方案的改进，所述后台预先配置分期支付渠道和不分期支付渠道两种支付渠道，具体包括：

所述后台预先创建一个第一父级支付渠道，再在所述第一父级支付渠道下创建第一基础配置、子支付方式和第一订单配置；其中，所述子支付方式与所述第一父级支付渠道进行绑定；

所述后台预先创建一个第二父级支付渠道，再在所述第二父级支付渠道下创建第二基础配置和第二订单配置。

具体地，参见图2，针对分期支付渠道，后台预先创建一个第一父级支付渠道，再在第一父级支付渠道下创建第一基础配置、子支付方式和第一订单配置；其中，子支付方式与第一父级支付渠道进行绑定，建立关系。其中，第一基础配置包括支付方式icon、支付方式名称、展示客户端、是否展示和支付描述，展示客户端包括app、h5、微信浏览器和微信小程序等。第一订单配置包括选择支付限定，主要用于定义支付渠道可用于何种订单类型。

针对不分期支付渠道，后台预先创建一个第二父级支付渠道，再在第二父级支付渠道下创建第二基础配置和第二订单配置。同样地，第二基础配置也包括支付方式icon、支付方式名称、展示客户端、是否展示和支付描述，展示客户端包括app、h5、微信浏览器和微信小程序等。第二订单配置包括选择支付限定。

作为上述方案的改进，所述在所述第一父级支付渠道下第一基础配置、子支付方式和第一订单配置之后，还包括：

在所述子支付方式下创建一个子级支付渠道，再在所述子级支付渠道下创建第三基础配置、分期配置和第三订单配置。

具体地，在子支付方式下创建一个子级支付渠道，再在子级支付渠道下创建第三基础配置、分期配置和第三订单配置。子级支付渠道与第一父级支付渠道是类似的，所以两者的配置也是类似的，相同之处在于，第三基础配置也包括支付方式icon、支付方式名称、展示客户端、是否展示和支付描述，展示客户端包括app、h5、微信浏览器和微信小程序等。第三订单配置包括选择支付限定。不同之处在于，分期配置包括添加期数和设置每期费率。

作为上述方案的改进，所述公司平台验证所述验证请求的有效性，并将验证结果返回所述支付模块，具体包括：

所述公司平台接收到所述验证请求后，获取所述验证请求中的订单数据；

根据所述订单数据验证所述验证请求的有效性，并将验证结果返回所述支付模块。

具体地，公司平台接收到验证请求后，获取验证请求中的订单数据；其中，订单数据包括订单单号和订单类型，订单类型可以为第一公司平台的预售订单、第一公司平台的正常订单、第二公司平台的买家保证金、第三公司平台的商品租赁等等。所以验证请求只会发送给对应的公司平台。

对应的公司平台就可以根据订单数据，结合公司平台内部存储的数据对验证请求的有效性进行验证，从而得到验证结果，再将验证结果返回支付模块。

综上，本发明实施例所提供的一种第三方支付处理系统及方法，通过在系统后台配置支付渠道，接口采用https协议，不需要接入sdk，不会出现不同软件开发工具包之间的冲突，从而实现快速迭代的功能，而且在不同平台和场景都能接入支付功能，实现聚合支付目的，极大方便了人们的支付需求。同时因为客户端的支付渠道列表是在后台配置的，无需开发干预，可以降低人工成本，提高效率，支付渠道配置功能丰富，并且支付渠道遵循开闭原则、接口隔离原则。当发现支付渠道出现异常时可以马上隐藏，到达闭关。进一步地，每个支付渠道还可以设置显示终端，根据不同终端展示不同支付渠道，这样可满足很多不同应用场景和需求。

以上所述是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本发明的保护范围。