一种缴费业务的控制方法及装置与流程

1.本发明涉及数据处理技术领域，尤其涉及一种缴费业务的控制方法及装置。


背景技术：

2.随着互联网技术的发展，传统的线下交易逐渐转移至线上交易。其中，线上交易指的是依托第三方支付平台，在网络上进行的虚拟交易。如线上缴费、购物等交易。
3.针对任一第三方支付平台，设置有业务类型对应的销账接口；其中，业务类型指的是交易的缴费业务的类型，如个人所得税缴费、交通罚款缴费、社保缴费、公积金缴费等业务类型。销账接口用于第三方支付平台对接行业方，以实现在行业方中进行销账操作。销账操作表示在行业方中销账交易，如在交通局销账交通罚款等操作。
4.然而，行业方的类型繁多，使得对应的销账接口数量大，对应设置在各第三方支付平台中的对接接口数量大。导致第三方支付平台设置的销账接口维护复杂，销账接口的维护成本高。且行业方对接第三方支付平台的销账接口流程复杂，对接难度高。


技术实现要素：

5.本发明实施例提供一种缴费业务的控制方法及装置，用于通过缴费业务系统设置行业方之间的销账接口聚合各行业方，通过缴费二维码聚合各第三方支付平台的缴费账单，以此实现聚合第三方支付平台和行业方之间的销账操作，减少第三方支付平台中设置的销账接口，降低第三方支付平台中销账接口的建立难度和成本，以及减少第三方支付平台中销账接口的维护难度和成本。
6.第一方面，本发明实施例提供一种缴费业务的控制方法，该方法应用于缴费业务系统；包括：
7.所述缴费业务系统获取客户端发送的账单获取请求；所述账单获取请求包括账单数据、业务类型和地区码；
8.所述缴费业务系统调用预设的销账接口，根据所述地区码和所述业务类型从映射表中查询出行业方，根据所述账单数据生成缴费账单；所述映射表预设有地区码、业务类型与行业方的映射关系；所述销账接口与多个行业方对接；
9.所述缴费业务系统在确定所述缴费账单支付成功时，通过所述销账接口向所述行业方发送销账指示，以使所述行业方执行销账操作。
10.上述技术方案中，缴费业务系统与各行业方之间预设有对应的销账接口，用户在进行缴费交易时，可以通过销账接口从预设的映射表中查询出需要进行销账操作的行业方。也就是说，各行业方与缴费业务系统对接，以此实现缴费业务系统聚合各行业方，第三方支付平台中不再需要设置销账接口，降低第三方支付平台中销账接口的建立难度和成本，以及减少第三方支付平台中销账接口的维护难度和成本。
11.另外，各行业方均通过一个或多个销账接口与缴费业务系统对接，实现对各行业方的聚合对接。因此行业方在查询缴费交易的缴费状态时，直接与缴费业务系统对接，而不
是与各第三方支付平台对接，以此降低各行业方的对接流程，简化各行业方的对接难度。
12.可选的，所述账单获取请求是所述客户端基于缴费二维码生成的；所述缴费二维码包括业务类型、加密算法类型、加密密钥索引、加密数据、地区码、签名算法和签名；
13.所述缴费二维码是所述第三方支付平台按照预设规范将所述业务类型、所述加密算法类型、所述加密密钥索引、所述加密数据、所述地区码、所述签名算法和所述签名拼接后生成的。
14.上述技术方案中，通过缴费二维码聚合各第三方支付平台创建的交易。例如，用户可以使用不同的客户端，通过扫描缴费二维码来创建缴费交易。以此用户在进行缴费交易时，可以根据用户所使用的缴费二维码从预设的映射表中查询出需要进行销账操作的行业方。也就是说，缴费二维码与行业方是一一对应的关系，以此实现聚合第三方支付平台和各行业方之间的销账操作。
15.可选的，所述缴费业务系统获取客户端发送的账单获取请求之后，还包括：
16.所述缴费业务系统解析所述账单获取请求中的缴费二维码，得到缴费信息；所述缴费信息包括账单数据、业务类型和地区码。
17.可选的，所述缴费业务系统解析所述缴费二维码，得到缴费信息，包括：
18.所述缴费业务系统根据所述缴费二维码中的签名算法对所述缴费二维码中的签名进行验证；
19.所述缴费业务系统在确定所述签名验证通过之后，根据所述缴费二维码中的加密算法类型和加密密钥索引确定出解密密钥；
20.所述缴费业务系统根据所述解密密钥对所述缴费二维码中的加密数据进行解密，得到账单数据；
21.所述缴费业务系统将所述账单数据和所述缴费二维码中的业务类型、地区码作为缴费信息。
22.上述技术方案中，缴费二维码的业务类型和地区码用于索引销账接口，以此实现缴费业务系统与销账接口对应的行业方实现对接。业务类型和地区码还表示缴费交易的所缴费地区和业务类型(如交通罚款缴费、个人所得税缴费等)。账单数据一般包括交易金额、交易单号等信息，用于完成缴费交易的支付操作。综上，缴费业务系统将账单数据、业务类型、地区码作为缴费信息，可以实现缴费账单的支付操作和销账操作，不再由第三方支付平台执行销账操作，进而减少第三方支付平台中设置的销账接口，降低第三方支付平台中销账接口的建立难度和成本，以及减少第三方支付平台中销账接口的维护难度和成本。
23.可选的，根据所述地区码和所述业务类型从映射表中查询出行业方之前，还包括：
24.所述缴费业务系统根据所述地区码和所述业务类型确定预设有处理逻辑时，基于所述处理逻辑修改所述账单数据；
25.根据所述账单数据生成缴费账单，包括：
26.所述缴费业务系统若根据所述业务类型确定所述缴费账单的类型为直缴类型，则根据修改后的账单数据生成缴费账单；
27.所述缴费业务系统若根据所述业务类型确定所述缴费账单的类型为查缴类型，则向所述行业方发送查询请求，接收所述行业方基于所述查询请求反馈的缴费账单；所述查询请求包括修改后的账单数据。
28.上述技术方案中，针对不同地区、或不同类型的行业方，销账操作的具体流程存在一定的差异。例如，新疆地区包括自治区和生产建设兵团，因此，在地区码表示新疆地区时，需要对账单数据进行修改，以索引到对应地区的行业方，保证销账的准确性。也就是说，销账接口可能对接的是新疆自治区的行业方，也有可能对接的是生产建设兵团的行业方，因此预设处理逻辑，对账单数据进行预处理，以此提升销账操作的灵活性和准确性。
29.可选的，所述缴费业务系统在确定所述缴费账单支付成功之前，还包括：
30.所述缴费业务系统将所述缴费账单发送至所述客户端，接收所述客户端基于所述缴费账单发送的支付指令；
31.所述缴费业务系统响应于所述支付指令，基于所述缴费账单执行支付操作。
32.可选的，所述方法还包括：
33.所述缴费业务系统接收第三方支付平台发送的结果请求；所述结果请求包括账单标识；
34.所述缴费业务系统根据所述账单标识查询所述账单标识对应缴费账单的缴费结果；所述缴费结果包括支付结果和销账结果；
35.所述缴费业务系统将所述支付结果和所述销账结果反馈至所述第三方支付平台。
36.目前，支付结果和销账接口均是发送至客户端，而不会在第三方支付平台中进行记录，因此第三方支付平台不具备查询某一缴费账单的支付结果和销账结果。
37.在上述技术方案中，缴费业务系统会记录支付结果和销账结果，以实现第三方支付平台可以从缴费业务系统中查询某一缴费账单的支付结果和销账结果。
38.第二方面，本发明实施例提供一种缴费业务的控制装置，包括：
39.获取模块，用于获取客户端发送的账单获取请求；所述账单获取请求包括账单数据、业务类型和地区码；
40.处理模块，用于调用预设的销账接口，根据所述地区码和所述业务类型从映射表中查询出行业方，根据所述账单数据生成缴费账单；所述映射表预设有地区码、业务类型与行业方的映射关系；所述销账接口与多个行业方对接；
41.在确定所述缴费账单支付成功时，通过所述销账接口向所述行业方发送销账指示，以使所述行业方执行销账操作。
42.可选的，所述账单获取请求是所述客户端基于缴费二维码生成的；所述缴费二维码包括业务类型、加密算法类型、加密密钥索引、加密数据、地区码、签名算法和签名；
43.所述缴费二维码是所述第三方支付平台按照预设规范将所述业务类型、所述加密算法类型、所述加密密钥索引、所述加密数据、所述地区码、所述签名算法和所述签名拼接后生成的。
44.可选的，所述处理模块还用于：
45.获取客户端发送的账单获取请求之后，解析所述账单获取请求中的缴费二维码，得到缴费信息；所述缴费信息包括账单数据、业务类型和地区码。
46.可选的，所述处理模块具体用于：
47.根据所述缴费二维码中的签名算法对所述缴费二维码中的签名进行验证；
48.在确定所述签名验证通过之后，根据所述缴费二维码中的加密算法类型和加密密钥索引确定出解密密钥；
49.根据所述解密密钥对所述缴费二维码中的加密数据进行解密，得到账单数据；
50.将所述账单数据和所述缴费二维码中的业务类型、地区码作为缴费信息。
51.可选的，所述处理模块还用于：
52.根据所述地区码和所述业务类型从映射表中查询出行业方之前，根据所述地区码和所述业务类型确定预设有处理逻辑时，基于所述处理逻辑修改所述账单数据；
53.所述处理模块具体用于：
54.若根据所述业务类型确定所述缴费账单的类型为直缴类型，则根据修改后的账单数据生成缴费账单；
55.若根据所述业务类型确定所述缴费账单的类型为查缴类型，则向所述行业方发送查询请求，接收所述行业方基于所述查询请求反馈的缴费账单；所述查询请求包括修改后的账单数据。
56.可选的，所述处理模块还用于：
57.在确定所述缴费账单支付成功之前，将所述缴费账单发送至所述客户端，接收所述客户端基于所述缴费账单发送的支付指令；
58.响应于所述支付指令，基于所述缴费账单执行支付操作。
59.可选的，所述处理模块还用于：
60.接收第三方支付平台发送的结果请求；所述结果请求包括账单标识；
61.根据所述账单标识查询所述账单标识对应缴费账单的缴费结果；所述缴费结果包括支付结果和销账结果；
62.将所述支付结果和所述销账结果反馈至所述第三方支付平台。
63.第三方面，本发明实施例还提供一种计算机设备，包括：
64.存储器，用于存储程序指令；
65.处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行上述缴费业务的控制方法。
66.第四方面，本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行上述缴费业务的控制方法。
附图说明
67.为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
68.图1为本发明实施例提供的一种系统架构示意图；
69.图2为本发明实施例提供的一种缴费业务的控制方法的流程示意图；
70.图3为本发明实施例提供的一种缴费业务的控制方法的流程示意图；
71.图4为本发明实施例提供的一种缴费业务的控制装置的结构示意图。
具体实施方式
72.为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
73.为了更好的阐述本发明技术方案，下面对一些名词进行解释。
74.行业方：指的是用于处理政务业务的一方，如交通局、社保局等。
75.线上交易：指的是在网络上就行的虚拟交易。例如，线上购买火车票、飞机票等；线上缴纳电费、水费、燃气费、电话费等；线上缴纳交通罚款、个人所得税；线上点餐、购物等交易。
76.销账操作：指的是在确定用户针对缴费账单支付成功之后，行业方获取用户支付的交易金额，进而将用户的销账状态由未销账修改为销账成功。例如，缴费账单为用户的个人所得税账单，在用户针对该账单支付成功之后，缴纳个人所得税的行业方获取该用户支付个人所得税的金额。在获取成功之后，将该用户的个人所得税缴费状态由未销账修改为销账成功。
77.支付操作：指的是将用户的网银账号扣除交易金额，并将交易金额发送至对应的收款方(如线商家、行业方等)。
78.聚合二维码：是指支持多个第三方支付平台(如**付、*信、**宝等)进行支付的二维码。
79.在一些可实施的方式中，缴费业务包括行业方销账的业务。包括但不限于以下缴费业务：社保缴费、税费缴纳、财政缴纳、水、电、煤行业账单缴纳等。
80.缴费业务对应的行业方包括但不限于以下行业方：税务局、财政局、海关总署等机构。
81.目前，用户在线上实现缴费业务时，一般是通过使用终端设备上的客户端扫描聚合二维码，然后建立缴费交易。用户针对该缴费交易，在第三方支付平台进行支付交易金额。其中，该第三方支付平台与该客户端是对应的。
82.在确定支付通过之后，由第三方支付平台调用销账接口，完成该缴费交易的销账操作。其中，销账接口是第三方支付平台基于行业方的类型建立的。例如，针对税务局建立的销账接口为s1，针对财务局建立的销账接口为s2，针对交通局建立的销账接口为s3等。
83.在一些可实施的方式中，针对不同地区，同一类型的税务局的销账接口也不同。例如，上海地区的税务局的销账接口为s11，北京地区的税务局的销账接口为s12等。
84.也就是说，针对地区的不同，业务类型的不同，设置在第三方支付平台对应的销账接口数量巨大，导致第三方支付平台设置的销账接口维护复杂，销账接口的维护成本高。且行业方对接第三方支付平台的销账接口流程复杂，对接难度高。
85.因此，现亟需一种缴费业务的控制方法，用于减少设置的销账接口，聚合各行业方的销账操作，减少第三方支付平台中设置的销账接口，降低第三方支付平台中销账接口的建立难度和成本，以及减少第三方支付平台中销账接口的维护难度和成本。降低各行业方与第三方支付平台的对接流程，简化各行业方的对接难度。
86.图1示例性的示出了本发明实施例所适用的一种系统架构，该系统架构包括服务
器100，该服务器100可以包括处理器110、通信接口120和存储器130。
87.其中，通信接口120用于与第三方支付平台建立通信连接。
88.处理器110是服务器100的控制中心，利用各种接口和路线连接整个服务器100的各个部分，通过运行或执行存储在存储器130内的软件程序/或模块，以及调用存储在存储器130内的数据，执行服务器100的各种功能和处理数据。可选地，处理器110可以包括一个或多个处理单元。
89.存储器130可用于存储软件程序以及模块，处理器110通过运行存储在存储器130的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器130可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据业务处理所创建的数据等。此外，存储器130可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
90.需要说明的是，上述图1所示的结构仅是一种示例，本发明实施例对此不做限定。
91.基于上述描述，图2示例性的示出了本发明实施例提供的一种缴费业务的控制方法的流程示意图，该流程可由缴费业务的控制装置执行。
92.如图2所示，该流程具体包括：
93.步骤210，所述缴费业务系统获取客户端发送的账单获取请求。
94.其中，账单获取请求是所述客户端基于缴费二维码生成的；缴费二维码是第三方支付平台创建的。第三方支付平台作为服务端，客户端指的是安装于移动终端上的app(application，应用软件)。
95.在一种可实施的方式中，缴费二维码是聚合二维码的一种。缴费二维码包括以下信息：业务类型、加密算法类型、加密密钥索引、加密数据、地区码、签名算法和签名。因此，账单获取请求包括账单数据、业务类型和地区码。用户可以使用客户端扫面缴费二维码触发账单获取请求，进而得到缴费账单。
96.步骤220，所述缴费业务系统调用预设的销账接口，根据所述地区码和所述业务类型从映射表中查询出行业方，根据所述账单数据生成缴费账单。
97.其中，映射表预设有地区码、业务类型与行业方的映射关系；销账接口与多个行业方对接。
98.也就是说，任一缴费二维码与行业方是对应的关系。针对任一缴费二维码，通过该缴费二维码生成的账单获取请求均可以索引到该缴费二维码对应的行业方。因此，通过账单获取请求生成的缴费账单用于在该行业方中执行销账操作。
99.步骤230，所述缴费业务系统在确定所述缴费账单支付成功时，通过所述销账接口向所述行业方发送销账指示，以使所述行业方执行销账操作。
100.在步骤210中，缴费二维码是第三方支付平台按照预设规范将业务类型、加密算法类型、加密密钥索引、加密数据、地区码、签名算法和签名拼接后生成的。
101.其中，预设规范可以是字段顺序、拼接方式等规范，在此不作具体限定。例如，按照业务类型、加密算法类型、加密密钥索引、加密数据、地区码、签名算法和签名的顺序进行拼接，进而得到缴费二维码。
102.业务类型、加密算法类型、加密密钥索引、加密数据、地区码、签名算法和签名指的
是字段，对应的说明如下述表1所示。
103.表1
[0104][0105][0106]
其中，序号表示在拼接缴费二维码时各字段的顺序；key表示各字段的键，并且描述了拼接缴费二维码时各字段的顺序。
[0107]
在一些可实施的方式中，基于key值的字母顺序对各字段进行拼接；如下述格式的缴费二维码：
[0108]
tips://bt＝bussinesstype&ea＝encryptalgorithm&ek＝encryptkey&ed＝encrypt data&ck＝citykey&sa＝signalgorithm&sn＝signature。
[0109]
其中，tips表示缴费二维码；bussinesstype表示业务类型；encryptalgorithm表示加密算法类型；encryptkey表示加密密钥索引；encryptdata表示加密数据；citykey表示地区码；signalgorithm表示签名算法；signature表示签名。
[0110]
业务类型包括但不限于：个人所得税缴费业务、交通罚款缴费业务、社保缴费业务等。
[0111]
加密算法类型包括但不限于：对称加密、非对称加密、同态加密等。
[0112]
加密密钥索引用于是缴费业务系统索引到用于解密加密数据的私钥。
[0113]
加密数据是第三方支付平台使用预设的加密算法(加密算法类型的一种或多种结合)对账单数据进行加密后得到的。
[0114]
地区码表示实现缴费业务的所在地区。例如地区码001表示上海，002表示北京等。
[0115]
签名算法包括但不限于：rsa算法、dsa算法、ecdsa算法等。
[0116]
签名是通过签名算法对“业务类型、加密算法类型、加密密钥索引、加密数据、地区码和签名算法”进行计算后得到的。例如，签名为下述格式：signature://bt＝bussinesstype&ck＝citykey&ea＝encryptalgorithm&ed＝encryptda ta&ek＝encryptkey&sa＝signalgorithm。
[0117]
在一些可实施的方式中，客户端可以根据自身提供的schema方式生成账单获取请求。在另一些可实施的方式中，客户端扫描缴费二维码之后，生成账单获取请求。
[0118]
其中，账单获取请求中包括缴费二维码。例如，将预设请求报文和缴费二维码进行拼接后得到账单获取请求。客户端在生成账单获取请求之后，将账单获取请求发送至缴费业务系统。
[0119]
基于上述描述，缴费业务系统在得到账单获取请求之后，得到账单获取请求中的缴费二维码。然后对缴费二维码进行解析。
[0120]
缴费业务系统在解析缴费二维码时，首先对缴费二维码进行验签。具体的，根据缴费二维码中的签名算法对缴费二维码中的签名进行验证。
[0121]
缴费业务系统在确定缴费二维码的签名验证通过时，表示缴费二维码为合法二维码，保证缴费二维码的合法性和准确性。然后根据缴费二维码中的加密算法类型确定对账单数据进行加密时所使用的加密算法，再根据加密密钥索引从该加密算法中查询出解密密钥。
[0122]
最后，缴费业务系统根据解密秘钥对缴费二维码中的加密数据进行解密，得到账单数据。由此将缴费二维码中的业务类型、地区码以及解密出的账单数据作为缴费信息。
[0123]
在步骤220中，缴费业务系统解析出缴费信息之后，根据缴费信息中的业务类型、地区码从预设的映射表中查询出针对该缴费二维码需要执行销账操作的行业方。
[0124]
例如，预设的映射表如下述表2所示。
[0125]
表2
[0126]
业务类型地区码行业方y1001h11y2001h12y1002h21y2002h22
[0127]
其中，y1表示社保缴费业务，y2表示交通罚款缴费业务；001表示上海，002表示北京；h11表示上海的社保局，h12表示上海的交通局，h21表示北京的社保局，h22表示北京的交通局。
[0128]
在一些可实施的方式中，同一地区内可能包括两个相同类型的行业方。例如，新疆地区中包括自治区的社保局和生产建设兵团的社保局。
[0129]
在另一些可实施的方式中，某类型业务类型的缴费业务可能对接不同的行业方。例如，广东地区的社保缴费业务对接广东a行业方、或者对接广东b行业方。
[0130]
因此，在查询出行业方之前，缴费业务系统会根据地区码和业务类型确定预设有处理逻辑时，基于处理逻辑修改账单数据。
[0131]
其中，处理逻辑用于在一些特殊的地区中，找到对应执行销账操作的行业方。具体的，通过预设的处理逻辑，删除、添加和或修改账单数据中的参数，以此在根据修改后的账单数据生成缴费交易之后，索引到对应的行业方，提升销账操作的准确性。
[0132]
在一些实施例中，缴费交易包括以下两种类型：直缴类型和查缴类型。其中，直缴类型表示交易金额已知，是固定的，因此可以根据账单数据直接生成缴费账单。查缴类型表示交易金额未知，需要从执行销账操作的行业方中查询出待交易金额。因此缴费业务系统
需要根据账单数据生成查询请求，然后将查询请求发送至上述技术方案中查询出的行业方。
[0133]
该行业方在收到查询请求之后，根据查询请求的账单数据查询出需要支付的交易金额，然后结合账单数据拼接生成缴费账单，最后将生成的缴费账单发送至缴费业务系统。
[0134]
在步骤230中，缴费业务系统会将接收到的缴费账单发送至客户端，由用户进行支付，进而确定缴费账单是否支付成功。
[0135]
具体的，缴费业务系统将缴费账单发送至所述客户端，接收客户端基于缴费账单发送的支付指令；缴费业务系统响应于支付指令，基于缴费账单执行支付操作。
[0136]
例如，客户端界面上显示有缴费账单，用户基于缴费账单选择支付方式，然后输入支付密码，点击“确认支付”控件，进而触发支付指令。缴费业务系统在接收支付指令之后，根据用户选择的支付方式，从该支付方式的用户账号中扣除缴费账单中的交易金额，进而完成支付操作，实现支付成功。并在完成支付操作之后，缴费业务系统向客户端返回支付结果(如支付成功或支付失败)。
[0137]
缴费业务系统在确认该笔击飞账单的支付操作完成且成功之后，开始执行销账操作。例如，将从用户账号中扣除的交易金额发送至对应的行业方，然后向行业方发送缴费指令。行业方在收到缴费指令之后，将用户的该笔缴费账单的缴费状态修改为已缴费，表示该笔缴费账单销账成功。缴费业务系统在执行销账操作之后，向客户端返回销账结果(如销账成功或销账失败)。
[0138]
在一种可实施的方式中，缴费账单的支付结果和销账结果均会发送至客户端，而不会发送至第三方支付平台。而客户端在得到支付结果和销账结果之后，根据用户的指令确定是否将支付结果和销账结果回调至第三方支付平台。例如，用户在得到支付结果和销账结果之后，客户端提供两个选择控件，包括“完成”和“关闭”；若用户点击“完成”，则将支付结果和销账结果回调至第三方支付平台；若用户点击“关闭”，则将支付结果和销账结果不会回调至第三方支付平台。
[0139]
在发明实施例中，缴费业务系统会存储缴费交易的支付结果和销账结果，因此可以实现第三方支付平台在缴费业务系统中查询缴费交易的支付结果和销账结果。
[0140]
具体的，缴费业务系统接收第三方支付平台发送的结果请求。其中，结果请求包括账单标识，且账单标识是唯一的；例如，账单标识为345***765。
[0141]
然后缴费业务系统根据账单标识查询账单标识对应缴费账单的支付结果和销账结果。
[0142]
最后缴费业务系统将支付结果和销账结果反馈至第三方支付平台。以此实现第三方支付平台在缴费业务系统中查询缴费交易的支付结果和销账结果。
[0143]
为了更好的阐述上述技术方案，图3示例性示出了一种缴费业务的控制方法的流程示意图，如图3所示，流程如下：
[0144]
步骤301，生成缴费二维码。
[0145]
第三方支付平台根据预设规范，按顺序的将业务类型y1、对称加密算法、加密密钥索引r1、加密数据m、地区码001、rsa签名算法和签名q拼接，得到缴费二维码。表示需要针对上海地区的社保缴费业务进行缴费操作。
[0146]
步骤302，接收缴费二维码。
[0147]
用户使用客户端扫描缴费二维码，根据用户的标识信息(如用户的身份证号码、电话号等)拼接缴费二维码生成账单获取请求，并将账单获取请求发送至缴费业务系统。
[0148]
步骤303，解析缴费二维码。
[0149]
缴费业务系统接收账单获取请求，并解析出账单获取请求中缴费二维码的业务类型、地区码和账单数据。
[0150]
步骤304，判断是否需要逻辑处理；若是则执行步骤305；否则执行步骤306。
[0151]
缴费业务系统根据解析出的业务类型、地区码确定是否需要修改账单数据。
[0152]
步骤305，进行逻辑处理。
[0153]
增加、删除和/修改账单数据中的参数；以保证查询出执行销账操作的行业方的准确性。
[0154]
步骤306，根据账单数据生成缴费账单。
[0155]
其中，缴费交易包括以下两种类型：直缴交易和查缴交易。
[0156]
因为业务类型为社保缴费业务，因此确定当前的缴费交易为查缴交易，需要有行业方查询出需要缴纳的交易金额。因此缴费业务系统将账单数据发送至执行销账操作的行业方，由行业方生成缴费账单。
[0157]
步骤307，存储账单信息。
[0158]
缴费业务系统接收行业方发送的缴费账单，然后将该缴费账单进行存储，并给予缴费账单生成交易账单。
[0159]
在一些可实施的方式中，交易账单用于用户进行支付操作，因此可以不包括缴费账单中的所有参数，以此提升流程通信效率。
[0160]
步骤308，接收交易账单。
[0161]
步骤309，用户缴费。
[0162]
客户端在接收交易账单之后，用户基于该交易账单，选择**宝的方式进行缴费。用户在输入缴费密码，并触发支付指令之后，将支付指令发送至缴费业务系统。
[0163]
步骤310，关联账单信息。
[0164]
缴费业务系统在接收支付指令之后，关联缴费账单的参数，补全交易账单的参数。
[0165]
步骤311，判断是否需要逻辑处理；若是则执行步骤312；否则执行步骤313。
[0166]
缴费业务系统根据交易账单的参数判断是否触发了预设的处理逻辑。
[0167]
步骤312，进行逻辑处理。
[0168]
增加、删除和/修改交易账单的参数；以保证执行缴费流程的准确性。
[0169]
步骤313，发起缴费流程。
[0170]
缴费业务系统在确定支付密码正确之后，从用户在**宝的账号中扣除交易金额，完成支付操作。将扣除的交易金额发送至行业方完成销账操作。
[0171]
步骤314，确定缴费结果。
[0172]
缴费业务系统该笔缴费交易的确定支付结果和销账结果，将该笔缴费交易的确定支付结果和销账结果发送至客户端。
[0173]
步骤315，接收缴费结果。
[0174]
在一些实施例中，基于上述图3所示，还包括以下流程：
[0175]
步骤320，发起查询请求。
[0176]
第三方支付平台向缴费业务系统发送查询请求，查询请求是根据交易账单的账单号0465***781生成的。
[0177]
步骤321，查询并反馈缴费结果。
[0178]
缴费业务系统根据账单号0465***781查询出对应的缴费交易，以及该笔缴费交易的支付结果和销账结果，然后将该笔缴费交易的确定支付结果和销账结果发送至第三方支付平台。
[0179]
由以上技术方案可知，通过缴费二维码聚合各第三方支付平台创建的交易。通过缴费业务系统与各行业方之间预设有对应的销账接口对各行业方进行聚合，实现各行业方对接销账接口的统一化。因为销账接口设置在缴费业务系统中，因此不需要在第三方支付平台中设置销账接口，进而降低第三方支付平台中销账接口的建立难度和成本，以及减少第三方支付平台中销账接口的维护难度和成本。
[0180]
另外，通过实现缴费二维码与行业方是一一对应的关系，不需要设置与行业方一一对应的销账接口，可以通过一个销账接口对接多个行业方，以此实现对各行业方的聚合对接降低各行业方的对接流程，简化各行业方的对接难度。
[0181]
基于相同的技术构思，图4示例性的示出了本发明实施例提供的一种缴费业务的控制装置的结构示意图，该装置可以执行缴费业务的控制方法的流程。
[0182]
如图4所示，该装置具体包括：
[0183]
获取模块410，用于获取客户端发送的账单获取请求；所述账单获取请求包括账单数据、业务类型和地区码；
[0184]
处理模块420，用于调用预设的销账接口，根据所述地区码和所述业务类型从映射表中查询出行业方，根据所述账单数据生成缴费账单；所述映射表预设有地区码、业务类型与行业方的映射关系；所述销账接口与多个行业方对接；
[0185]
在确定所述缴费账单支付成功时，通过所述销账接口向所述行业方发送销账指示，以使所述行业方执行销账操作。
[0186]
可选的，所述账单获取请求是所述客户端基于缴费二维码生成的；所述缴费二维码包括业务类型、加密算法类型、加密密钥索引、加密数据、地区码、签名算法和签名；
[0187]
所述缴费二维码是所述第三方支付平台按照预设规范将所述业务类型、所述加密算法类型、所述加密密钥索引、所述加密数据、所述地区码、所述签名算法和所述签名拼接后生成的。
[0188]
可选的，所述处理模块420还用于：
[0189]
获取客户端发送的账单获取请求之后，解析所述账单获取请求中的缴费二维码，得到缴费信息；所述缴费信息包括账单数据、业务类型和地区码。
[0190]
可选的，所述处理模块420具体用于：
[0191]
根据所述缴费二维码中的签名算法对所述缴费二维码中的签名进行验证；
[0192]
在确定所述签名验证通过之后，根据所述缴费二维码中的加密算法类型和加密密钥索引确定出解密密钥；
[0193]
根据所述解密密钥对所述缴费二维码中的加密数据进行解密，得到账单数据；
[0194]
将所述账单数据和所述缴费二维码中的业务类型、地区码作为缴费信息。
[0195]
可选的，所述处理模块420还用于：
[0196]
根据所述地区码和所述业务类型从映射表中查询出行业方之前，根据所述地区码和所述业务类型确定预设有处理逻辑时，基于所述处理逻辑修改所述账单数据；
[0197]
所述处理模块420具体用于：
[0198]
若根据所述业务类型确定所述缴费账单的类型为直缴类型，则根据修改后的账单数据生成缴费账单；
[0199]
若根据所述业务类型确定所述缴费账单的类型为查缴类型，则向所述行业方发送查询请求，接收所述行业方基于所述查询请求反馈的缴费账单；所述查询请求包括修改后的账单数据。
[0200]
可选的，所述处理模块420还用于：
[0201]
在确定所述缴费账单支付成功之前，将所述缴费账单发送至所述客户端，接收所述客户端基于所述缴费账单发送的支付指令；
[0202]
响应于所述支付指令，基于所述缴费账单执行支付操作。
[0203]
可选的，所述处理模块420还用于：
[0204]
接收第三方支付平台发送的结果请求；所述结果请求包括账单标识；
[0205]
根据所述账单标识查询所述账单标识对应缴费账单的缴费结果；所述缴费结果包括支付结果和销账结果；
[0206]
将所述支付结果和所述销账结果反馈至所述第三方支付平台。
[0207]
基于相同的技术构思，本发明实施例还提供一种计算机设备，包括：
[0208]
存储器，用于存储程序指令；
[0209]
处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行上述缴费业务的控制方法。
[0210]
基于相同的技术构思，本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行上述缴费业务的控制方法。
[0211]
本领域内的技术人员应明白，本技术的实施例可提供为方法、系统、或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
[0212]
本技术是参照根据本技术的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0213]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0214]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0215]
显然，本领域的技术人员可以对本技术进行各种改动和变型而不脱离本技术的精神和范围。这样，倘若本技术的这些修改和变型属于本技术权利要求及其等同技术的范围之内，则本技术也意图包含这些改动和变型在内。