CN110111112A - 数据处理方法及装置 - Google Patents

Abstract

本申请公开了一种数据处理方法及装置，其中方法包括：监听局域网内业务端的TCP端口；接收业务端发起的支付请求以及所述业务端的业务类型；根据所述支付请求以及业务类型筛选可用的支付渠道，并将所述可用的支付渠道转发至所述业务端；接收业务端反馈的选定的支付渠道以及支付金额，并根据所述支付金额向所述选定的支付渠道发起支付请求；接收所述选定的支付渠道在完成所述支付请求后的支付信息。达到了通过监听局域网内TCP端口而实现解除支付系统对于业务的耦合的目的；进而实现了支付系统的独立性，增强了支付系统的可维护性、可扩展性等优点。

Description

数据处理方法及装置

技术领域

本申请涉及电子支付技术领域，具体而言，涉及一种数据处理方法及装置。

背景技术

当前市面上第三方支付方式种类繁多，对接繁琐，且产品质量参差不齐,对公司产品的支付业务有较大的风险。且随着公司业务的发展，对支付的要求越来越高。由于各业务的支付渠道不同、支付方式多样、且各渠道各类支付订单、退款、支付数据统计等数据量极大，不易于统一管理。

当前市面上的支付系统，通过php-fpm搭配外部webserver，系统的响应比较弱，并且对服务器的性能损耗较大。同时对于服务化的设计不支持，无法通过http以外的协议进行调用，影响系统的响应速度以及安全性。

针对相关技术中存在的诸多的诸多问题，目前尚未提出有效的解决方案。

发明内容

本申请的主要目的在于提供一种数据处理方法及装置，以解决相关技术中存在的至少一个技术问题。

为了实现上述目的，根据本申请的一个方面，提供了一种数据处理方法。

根据本申请的数据处理方法包括：

监听局域网内业务端的TCP端口；

接收业务端发起的支付请求以及所述业务端的业务类型；

根据所述支付请求以及业务类型筛选可用的支付渠道，并将所述可用的支付渠道转发至所述业务端；

接收业务端反馈的选定的支付渠道以及支付金额，并根据所述支付金额向所述选定的支付渠道发起支付请求；

接收所述选定的支付渠道在完成所述支付请求后的支付信息。

进一步的，如前述的数据处理方法，还包括：

预先确定不同业务类型对应的支付渠道，并建立第一对应关系；

将所述第一对应关系进行存储。

进一步的，如前述的数据处理方法，还包括：

根据所述支付信息以及业务类型生成对应的支付业务数据，并将所述支付业务数据存储于数据库中。

进一步的，如前述的数据处理方法，还包括：

接收查询指令，其中，所述查询指令是用于查询支付信息的指令；

从所述数据库中查询与所述查询指令对应的支付业务数据，得到查询结果信息，其中，在查询成功时，所述查询结果信息中包含所述支付业务数据，所述数据库中存储的支付业务数据的格式统一；

反馈所述查询结果信息。

进一步的，如前述的数据处理方法，还包括：

将所述支付信息下发至所述业务端；使所述业务端根据所述支付信息生成相应的业务办理结果，并将所述业务办理结果发送给用户。

为了实现上述目的，根据本申请的另一方面，提供了一种数据处理装置。

根据本申请的数据处理装置包括：

监听单元，用于监听局域网内业务端的TCP端口；

第一接收单元，用于接收业务端发起的支付请求以及所述业务端的业务类型；

渠道筛选单元，用于根据所述支付请求以及业务类型筛选可用的支付渠道，并将所述可用的支付渠道转发至所述业务端；

请求发起单元，用于接收业务端反馈的选定的支付渠道以及支付金额，并根据所述支付金额向所述选定的支付渠道发起支付请求；

第二接收单元，用于接收所述选定的支付渠道在完成所述支付请求后的支付信息。

进一步的，如前述的数据处理装置，还包括：注册单元；所述注册单元包括：

第一对应模块，用于预先确定不同业务类型对应的支付渠道，并建立第一对应关系；

存储模块，用于将所述第一对应关系进行存储。

进一步的，如前述的数据处理装置，还包括支付业务数据单元，用于：

根据所述支付信息以及业务类型生成对应的支付业务数据，并将所述支付业务数据存储于数据库中。

进一步的，如前述的数据处理装置，还包括：查询单元；所述查询单元包括：

查询接收模块，用于接收查询指令，其中，所述查询指令是用于查询支付信息的指令；

查询模块，用于从所述数据库中查询与所述查询指令对应的支付业务数据，得到查询结果信息，其中，在查询成功时，所述查询结果信息中包含所述支付业务数据，所述数据库中存储的支付业务数据的格式统一；

反馈模块，用于反馈所述查询结果信息。

进一步的，如前述的数据处理装置，还包括支付信息下发单元，用于：

将所述支付信息下发至所述业务端；使所述业务端根据所述支付信息生成相应的业务办理结果，并将所述业务办理结果发送给用户。

在本申请实施例中，采用一种数据处理方法及装置，其中方法包括：监听局域网内业务端的TCP端口；接收业务端发起的支付请求以及所述业务端的业务类型；根据所述支付请求以及业务类型筛选可用的支付渠道，并将所述可用的支付渠道转发至所述业务端；接收业务端反馈的选定的支付渠道以及支付金额，并根据所述支付金额向所述选定的支付渠道发起支付请求；接收所述选定的支付渠道在完成所述支付请求后的支付信息。达到了通过监听局域网内TCP端口而实现解除支付系统对于业务的耦合的目的；进而实现了支付系统的独立性，增强了支付系统的可维护性、可扩展性等优点。

附图说明

构成本申请的一部分的附图用来提供对本申请的进一步理解，使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请一种实施例的数据处理方法的流程示意图；

图2是根据本申请一种实施例的数据处理装置的功能模块结构示意图；以及

图3是根据本申请一种实施例的支付流程示意图。

具体实施方式

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本申请中，术语“上”、“下”、“左”、“右”、“前”、“后”、“顶”、“底”、“内”、“外”、“中”、“竖直”、“水平”、“横向”、“纵向”等指示的方位或位置关系为基于附图所示的方位或位置关系。这些术语主要是为了更好地描述本申请及其实施例，并非用于限定所指示的装置、元件或组成部分必须具有特定方位，或以特定方位进行构造和操作。

并且，上述部分术语除了可以用于表示方位或位置关系以外，还可能用于表示其他含义，例如术语“上”在某些情况下也可能用于表示某种依附关系或连接关系。对于本领域普通技术人员而言，可以根据具体情况理解这些术语在本申请中的具体含义。

此外，术语“安装”、“设置”、“设有”、“连接”、“相连”、“套接”应做广义理解。例如，可以是固定连接，可拆卸连接，或整体式构造；可以是机械连接，或电连接；可以是直接相连，或者是通过中间媒介间接相连，又或者是两个装置、元件或组成部分之间内部的连通。对于本领域普通技术人员而言，可以根据具体情况理解上述术语在本申请中的具体含义。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

根据本申请的一个实施例，提供了一种数据处理方法。如图1及图3所示，该方法包括如下的步骤S1至步骤S5：

S1.监听局域网内业务端的TCP端口；

具体的，可以通过使用基于c/c++编写的php扩展程序实现监听局域网内业务端的TCP端口的目的；使用内网tcp连接调用，提升服务的安全性以及响应性，因为可以独立维护的特性，达到了支持服务的横向扩容、分布式部署，提升系统的可用性；

S2.接收业务端发起的支付请求以及所述业务端的业务类型；

也就是说，在通过所述TCP端口进行与业务端耦合的时候，可以预先配置每个端口与业务端的对应关系，且各个业务端对应的业务类型也都是固定的；

S3.根据所述支付请求以及业务类型筛选可用的支付渠道，并将所述可用的支付渠道转发至所述业务端；

也就是说，系统根据所述支付请求判定需要开始进行支付行为，进而调取出所有支付渠道，由于不同的业务类型对应有不同的支付渠道，因此根据所述业务类型筛选出与其对应的所述可用的支付渠道；一般的，所述支付渠道包括：支付宝、微信支付和银联等等；

S4.接收业务端反馈的选定的支付渠道以及支付金额，并根据所述支付金额向所述选定的支付渠道发起支付请求；

具体的，当所述业务端收到用户选定的支付渠道以及支付金额(所述支付金额可以是用户自己输入或者业务端根据用户选定的业务自动生成的)之后，将所述支付金额传输到对应的支付渠道，发起支付请求；

S5.接收所述选定的支付渠道在完成所述支付请求后的支付信息；

也就是说，此时会将用户端的操作页面直接引导至所述选定的支付渠道，以供用户进行支付，然后在支付完成(支付成功、支付失败)后，所述支付渠道将所述支付信息主动下发至实施本方法的系统。

在一些实施例中，如前述的数据处理方法，还包括：

预先确定不同业务类型对应的支付渠道，并建立第一对应关系；

具体的，也就是说，不同的业务对应的支付渠道是各不相同的；举例的：当包含业务A、业务B时；业务A对应的支付渠道包括支付宝、微信支付；业务B对应的支付渠道包含支付宝、银联；则将业务A与支付宝、微信支付进行对应；将业务B与支付宝、银联进行对应；

将所述第一对应关系进行存储；

优选的，所述第一对应关系以数据表的形式存储于对应的数据库中。

在一些实施例中，如前述的数据处理方法，还包括：

根据所述支付信息以及业务类型生成对应的支付业务数据，并将所述支付业务数据存储于数据库中。具体的，所述支付信息包括：支付用户、支付金额、时间、是否支付成功等等信息；所述支付业务数据

也就是说，当接收到所述支付信息之后，将支付信息与对应的业务类型进行绑定打包，生成所述支付业务数据。

在一些实施例中，如前述的数据处理方法，还包括：

接收查询指令，其中，所述查询指令是用于查询支付信息的指令；

从所述数据库中查询与所述查询指令对应的支付业务数据，得到查询结果信息，其中，在查询成功时，所述查询结果信息中包含所述支付业务数据，所述数据库中存储的支付业务数据的格式统一；

反馈所述查询结果信息。

具体的，通过该方法可以满足了各个公司对于支付数据的查询、支付订单的核对等需求的实现，提高了对于支付业务的监控、管理支付渠道的效率、支付的稳定性，降低了支付失败的风险。

如图图3所示，在一些实施例中，如前述的数据处理方法，还包括：

将所述支付信息下发至所述业务端；使所述业务端根据所述支付信息生成相应的业务办理结果，并将所述业务办理结果发送给用户。

具体的，由于支付成功不一定马上业务就能够成功办理，通过将业务办理结果发送给用户，能够使其了解业务端的处理情况和结果，整个流程更加清晰透明，使用户有一个更好的体验。

进一步的，本方法的系统还使用php7编写。舍弃传统的以nginx和apache为主的web服务器，通过使用基于c/c++编写的php扩展程序，实现了网页端进程常驻，大幅提升系统的响应性，减少了服务器性能的损耗。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

根据本发明实施例，还提供了一种用于实施上述数据处理装方法的数据处理装置，如图2所示，该装置包括：

监听单元1，用于监听局域网内业务端的TCP端口；

第一接收单元2，用于接收业务端发起的支付请求以及所述业务端的业务类型；

渠道筛选单元3，用于根据所述支付请求以及业务类型筛选可用的支付渠道，并将所述可用的支付渠道转发至所述业务端；

请求发起单元4，用于接收业务端反馈的选定的支付渠道以及支付金额，并根据所述支付金额向所述选定的支付渠道发起支付请求；

第二接收单元5，用于接收所述选定的支付渠道在完成所述支付请求后的支付信息。

具体的，本发明实施例的装置中各模块实现其功能的具体过程可参见方法实施例中的相关描述，此处不再赘述。

在一些实施例中，如前述的数据处理装置，还包括：注册单元；所述注册单元包括：

第一对应模块，用于预先确定不同业务类型对应的支付渠道，并建立第一对应关系；

存储模块，用于将所述第一对应关系进行存储。

具体的，本发明实施例的装置中各模块实现其功能的具体过程可参见方法实施例中的相关描述，此处不再赘述。

在一些实施例中，如前述的数据处理装置，还包括支付业务数据单元，用于：

根据所述支付信息以及业务类型生成对应的支付业务数据，并将所述支付业务数据存储于数据库中。

具体的，本发明实施例的装置中各模块实现其功能的具体过程可参见方法实施例中的相关描述，此处不再赘述。

在一些实施例中，如前述的数据处理装置，还包括：查询单元；所述查询单元包括：

查询接收模块，用于接收查询指令，其中，所述查询指令是用于查询支付信息的指令；

查询模块，用于从所述数据库中查询与所述查询指令对应的支付业务数据，得到查询结果信息，其中，在查询成功时，所述查询结果信息中包含所述支付业务数据，所述数据库中存储的支付业务数据的格式统一；

反馈模块，用于反馈所述查询结果信息。

具体的，本发明实施例的装置中各模块实现其功能的具体过程可参见方法实施例中的相关描述，此处不再赘述。

在一些实施例中，如前述的数据处理装置，还包括支付信息下发单元，用于：

将所述支付信息下发至所述业务端；使所述业务端根据所述支付信息生成相应的业务办理结果，并将所述业务办理结果发送给用户。

具体的，本发明实施例的装置中各模块实现其功能的具体过程可参见方法实施例中的相关描述，此处不再赘述。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种数据处理方法，其特征在于，包括：

监听局域网内业务端的TCP端口；

接收业务端发起的支付请求以及所述业务端的业务类型；

根据所述支付请求以及业务类型筛选可用的支付渠道，并将所述可用的支付渠道转发至所述业务端；

接收业务端反馈的选定的支付渠道以及支付金额，并根据所述支付金额向所述选定的支付渠道发起支付请求；

接收所述选定的支付渠道在完成所述支付请求后的支付信息。

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

预先确定不同业务类型对应的支付渠道，并建立第一对应关系；

将所述第一对应关系进行存储。

3.根据权利要求1所述的数据处理方法，其特征在于，还包括：

根据所述支付信息以及业务类型生成对应的支付业务数据，并将所述支付业务数据存储于数据库中。

4.根据权利要求3所述的数据处理方法，其特征在于，还包括：

接收查询指令，其中，所述查询指令是用于查询支付信息的指令；

从所述数据库中查询与所述查询指令对应的支付业务数据，得到查询结果信息，其中，在查询成功时，所述查询结果信息中包含所述支付业务数据，所述数据库中存储的支付业务数据的格式统一；

反馈所述查询结果信息。

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

将所述支付信息下发至所述业务端；使所述业务端根据所述支付信息生成相应的业务办理结果，并将所述业务办理结果发送给用户。

6.一种数据处理装置，其特征在于，包括：

监听单元，用于监听局域网内业务端的TCP端口；

第一接收单元，用于接收业务端发起的支付请求以及所述业务端的业务类型；

渠道筛选单元，用于根据所述支付请求以及业务类型筛选可用的支付渠道，并将所述可用的支付渠道转发至所述业务端；

请求发起单元，用于接收业务端反馈的选定的支付渠道以及支付金额，并根据所述支付金额向所述选定的支付渠道发起支付请求；

第二接收单元，用于接收所述选定的支付渠道在完成所述支付请求后的支付信息。

7.根据权利要求6所述的数据处理装置，其特征在于，还包括：注册单元；所述注册单元包括：

第一对应模块，用于预先确定不同业务类型对应的支付渠道，并建立第一对应关系；

存储模块，用于将所述第一对应关系进行存储。

8.根据权利要求6所述的数据处理装置，其特征在于，还包括支付业务数据单元，用于：

根据所述支付信息以及业务类型生成对应的支付业务数据，并将所述支付业务数据存储于数据库中。

9.根据权利要求8所述的数据处理装置，其特征在于，还包括：查询单元；所述查询单元包括：

查询接收模块，用于接收查询指令，其中，所述查询指令是用于查询支付信息的指令；

查询模块，用于从所述数据库中查询与所述查询指令对应的支付业务数据，得到查询结果信息，其中，在查询成功时，所述查询结果信息中包含所述支付业务数据，所述数据库中存储的支付业务数据的格式统一；

反馈模块，用于反馈所述查询结果信息。

10.根据权利要求6所述的数据处理装置，其特征在于，还包括支付信息下发单元，用于：

将所述支付信息下发至所述业务端；使所述业务端根据所述支付信息生成相应的业务办理结果，并将所述业务办理结果发送给用户。