支付处理服务器、客户端及支付处理方法技术领域
本发明涉及通信技术领域，尤其涉及支付处理服务器、客户端及支付处理方法。
背景技术
随着移动互联网的发展，移动终端已经成为人们生活中不可缺少使用设备，同时，
用户对于移动支付的使用也越来越频繁，而支持移动支付的移动应用也越来越多。目前移
动支付方式很多，比如银联支付、微信支付、支付宝支付等。
然而，对于可进行移动支付的移动应用来说，若要实现可进行多种支付渠道的移
动支付方式，则需要了解各大移动支付商的支付接入规则，并分别使用不同的支付处理代
码模块来接入不同的支付渠道，不仅实现方式复杂，同时移动应用方也需要进行针对多种
支付渠道的大量开发与维护工作量，不便于移动应用主营功能业务的发展。
发明内容
本发明的主要目的在于提供一种支付处理服务器、客户端及支付处理方法，旨在
解决现有具有移动支付的移动应用需要面对多种支付渠道，进而影响到移动应用主要功能
业务发展的技术问题。
为实现上述目的，本发明提供一种支付处理服务器，所述支付处理服务器包括：
支付渠道处理模块，用于接收支付处理客户端所发起的订单的支付渠道获取请
求，并向所述支付处理客户端返回支付渠道选项；
支付凭证处理模块，用于接收所述支付处理客户端发起的目标支付渠道的支付处
理凭证获取请求，将所述支付处理凭证获取请求转发至与所述目标支付渠道相对应的第三
方支付平台，接收所述第三方支付平台生成的支付处理凭证，并将所述支付处理凭证发送
给所述支付处理客户端；
支付结果转发模块，用于接收所述第三方支付平台生成的支付结果，并将所述支
付结果转发至目标服务器，其中，所述支付处理客户端通过所述支付处理凭证向所述第三
方支付平台发起支付请求，所述第三方支付平台对所述订单进行支付处理并生成支付结
果。
可选的，所述订单由目标服务器根据目标客户端的购买请求所生成并由所述目标
客户端转发给所述支付处理客户端，所述目标服务器根据支付处理侧所提供的签名规则，
对所述订单进行签名处理，得到签名字符串；所述支付渠道获取请求与所述支付处理凭证
获取请求中分别包括所述签名字符串；
其中，所述签名字符串至少包括所述订单的参数及对应参数值、签名时间戳、签名
关键字，所述签名关键字由所述支付处理侧提供给在所述支付处理侧注册的所述目标客户
端。
可选的，所述支付渠道处理模块包括：
接收单元，用于接收所述支付渠道获取请求，并获得所述签名字符串；
签名校验单元，用于根据预置校验规则，对所述签名字符串进行签名校验；
注册校验单元，用于在签名校验通过时，根据所述签名关键字，确定所述目标客户
端是否已在所述支付处理侧注册，若已注册，则确定对所述支付渠道获取请求所进行的校
验通过，其中，若确定对所述支付渠道获取请求所进行的校验通过，则向所述支付处理客户
端返回支付渠道选项。
可选的，所述支付结果转发模块还用于：
若将所述支付结果转发至所述目标服务器的累积失败次数达到预置数值，则启动
支付预警处理，并记录转发失败原因与所述订单的相关信息。
进一步地，为实现上述目的，本发明还提供一种支付处理客户端，所述支付处理客
户端包括：
订单接收模块，用于接收目标客户端所发送的由目标服务器根据所述目标客户端
的购买请求所生成的订单；
支付渠道请求模块，用于向支付处理服务器发起所述订单的支付渠道获取请求，
并接收所述支付处理服务器对所述支付渠道获取请求进行校验且校验通过后所返回的支
付渠道选项，以及将所述支付渠道选项转发至所述目标客户端以获取所述目标客户端所选
择的支付渠道；
支付凭证请求模块，用于向所述支付处理服务器发起所述支付渠道的支付处理凭
证获取请求，并接收所述支付处理服务器对所述支付处理凭证获取请求进行校验且校验通
过后所转发的支付处理凭证，其中，在校验通过后，所述支付处理服务器将所述支付处理凭
证获取请求转发至与所述支付渠道相对应的第三方支付平台进行处理以获取所述第三方
支付平台所生成的所述支付处理凭证；
支付请求模块，用于通过所述支付处理凭证向所述第三方支付平台发起支付请
求，以通过所述第三方支付平台对所述订单进行支付处理，并将支付处理完成后所接收到
的由所述第三方支付平台所生成的支付结果转发至所述目标客户端。
为实现上述目的，本发明还提供一种支付处理方法，所述支付处理方法包括：
接收支付处理客户端所发起的订单的支付渠道获取请求，并向所述支付处理客户
端返回支付渠道选项；
接收所述支付处理客户端发起的目标支付处理凭证获取请求，将所述支付处理凭
证获取请求转发至与所述目标支付渠道相对应的第三方支付平台，接收所述第三方支付平
台生成的支付处理凭证，并将所述支付处理凭证发送给所述支付处理客户端；
接收所述第三方支付平台生成的支付结果，并将所述支付结果转发至目标服务
器，其中，所述支付处理客户端通过所述支付处理凭证向所述第三方支付平台发起支付请
求，所述第三方支付平台对所述订单进行支付处理并生成支付结果。
可选的，所述订单由目标服务器根据目标客户端的购买请求所生成并由所述目标
客户端转发给所述支付处理客户端，其中，所述目标服务器生成所述订单时，所述支付处理
方法还包括：
所述目标服务器根据支付处理侧所提供的签名规则，对所述订单进行签名处理，
得到签名字符串；所述支付渠道获取请求与所述支付处理凭证获取请求中分别包括所述签
名字符串；
其中，所述签名字符串至少包括所述订单的参数及对应参数值、签名时间戳、签名
关键字，所述签名关键字由所述支付处理侧提供给在所述支付处理侧注册的所述目标客户
端。
可选的，所述接收支付处理客户端所发起的订单的支付渠道获取请求并进行校
验，并向所述支付处理客户端返回支付渠道选项包括：
接收所述支付渠道获取请求，并获得所述签名字符串；
根据预置校验规则，对所述签名字符串进行签名校验；
在签名校验通过时，根据所述签名关键字，确定所述目标客户端是否已在所述支
付处理侧注册，若已注册，则确定对所述支付渠道获取请求所进行的校验通过；
若确定对所述支付渠道获取请求所进行的校验通过，则向所述支付处理客户端返
回支付渠道选项。
可选的，所述支付处理方法还包括：
若将所述支付结果转发至所述目标服务器的累积失败次数达到预置数值，则启动
支付预警处理，并记录转发失败原因与所述订单的相关信息。
进一步地，为实现上述目的，本发明还提供一种支付处理方法，所述支付处理方法
包括：
接收目标客户端所发送的由目标服务器根据所述目标客户端的购买请求所生成
的订单；
向支付处理服务器发起所述订单的支付渠道获取请求，并接收所述支付处理服务
器对所述支付渠道获取请求进行校验且校验通过后所返回的支付渠道选项，以及将所述支
付渠道选项转发至所述目标客户端以获取所述目标客户端所选择的支付渠道；
向所述支付处理服务器发起所述支付渠道的支付处理凭证获取请求，并接收所述
支付处理服务器对所述支付处理凭证获取请求进行校验且校验通过后所转发的支付处理
凭证，其中，在校验通过后，所述支付处理服务器将所述支付处理凭证获取请求转发至与所
述支付渠道相对应的第三方支付平台进行处理以获取所述第三方支付平台所生成的所述
支付处理凭证；
通过所述支付处理凭证向所述第三方支付平台发起支付请求，以通过所述第三方
支付平台对所述订单进行支付处理，并将支付处理完成后所接收到的由所述第三方支付平
台所生成的支付结果转发至所述目标客户端。
本发明中，移动应用客户端(也即目标客户端)在对网购订单进行支付时，移动应
用客户端只需将该网购订单发送给支付处理客户端，支付处理客户端即可自动完成对该购
物订单的支付渠道、支付处理凭证以及第三方平台的支付处理。同时，支付处理客户端可向
移动应用客户端反馈一种或多种支付渠道，进而移动应用无需进行针对多种支付渠道的大
量开发与维护工作量，进而可实现对多种支付渠道的统一集成处理，提升移动应用支付的
便捷性。
附图说明
图1为本发明进行支付处理一实施例的场景架构示意图；
图2为本发明支付处理客户端一实施例的模块示意图；
图3为本发明支付处理服务器一实施例的模块示意图；
图4为图3中支付渠道处理模块一实施例的模块示意图；
图5为本发明支付处理系统一实施例的模块示意图；
图6为本发明支付处理方法第一实施例的流程示意图；
图7为本发明支付处理方法第二实施例的流程示意图。
本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。
参照图1，图1为本发明进行支付处理一实施例的场景架构示意图。
如图1所示，本实施例中，支付处理客户端10具体应用于具有目标客户端30的移动
终端，支付处理客户端10通过移动终端与支付处理服务器20进行数据通信，目标客户端30
通过移动终端与目标服务器40进行数据通信，支付处理客户端10、支付处理服务器20分别
与第三方支付平台50进行数据通信。
如图2所示的本发明支付处理客户端一实施例的模块示意图。
当用户使用目标客户端30在目标服务器40所对应的网站上进行购物时，目标服务
器40将根据目标客户端30的购买请求生成对应的订单，并将订单信息返回给目标客户端
30，进而通过目标客户端30将该订单发送给支付处理客户端10进行支付处理。
为实现对目标客户端30所发送的订单的支付处理，如图1所示，本实施例中支付处
理客户端包括：
订单接收模块110，用于接收目标客户端所发送的由目标服务器根据目标客户端
的购买请求所生成的订单；
本实施例中，对于订单的生成方式及处理规则不限。
可选的，为保证资金支付的安全性，同时也使得目标客户端30能够使用支付处理
客户端10进行订单支付，因此，目标服务器40需要采用支出处理侧所提供的签名规则对订
单进行签名(一种特殊加密方式)，得到对应的签名字符串，从而便于支付处理侧的支付处
理服务器20可以通过对签名字符串进行校验，进而实现对订单的真实性与可靠性的验证，
其中，签名规则的设置不限，具体根据实际需要进行设置。
支付渠道请求模块120，用于向支付处理服务器发起订单的支付渠道获取请求，并
接收支付处理服务器对支付渠道获取请求进行校验且校验通过后所返回的支付渠道选项，
以及将支付渠道选项转发至目标客户端以获取目标客户端所选择的支付渠道；
本实施例中，当订单接收模块110接收到待支付的订单时，支付渠道请求模块120
将向支付处理服务器20发起订单的支付渠道获取请求，比如获取支付宝支付渠道或微信支
付渠道或银联支付渠道等。其中，支付渠道具体是指进入对订单进行支付处理的入口，可以
看作是一种接口程序。此外，需要说明的是，该支付渠道获取请求中包含有订单或订单的相
关信息，进而以便于得到该订单所对应的支付渠道。
本实施例中，为保证订单的支付渠道获取请求的真实可靠性，支付处理服务器20
需要对支付渠道获取请求进行校验，具体校验内容及方式不限。可选的，支付处理服务器20
通过对目标服务器40对订单进行签名处理后所生成的签名字符串进行签名校验。
当支付处理服务器20对订单的支付渠道获取请求的校验通过时，支付处理服务器
20将返回支付渠道选项给支付处理客户端10，而后再由支付处理客户端10转发给目标客户
端30而在移动终端上进行显示，进而以供买家用户选择需要使用的支付渠道。例如，支付处
理服务器20所返回的支付渠道选项包括支付宝支付、微信支付、银联支付三种支付渠道以
供用户选择，若用户选择支付宝支付这一支付渠道，则目标客户端30将用户的支付渠道选
择结果反馈给支付处理客户端10。
可选的，支付处理服务器20将根据支付处理客户端10的版本，确定对应的支付渠
道选项。例如，支付处理客户端10的版本为第一版本，则对应的字符渠道选项只有一种支付
渠道；支付处理客户端10的版本为第三版本，则对应的字符渠道选项只有五种支付渠道等。
用户可通过升级支付处理客户端10的发布版本来确定对应返回的支付渠道选项。
支付凭证请求模块130，用于向支付处理服务器发起支付渠道的支付处理凭证获
取请求，并接收支付处理服务器对支付处理凭证获取请求进行校验且校验通过后所转发的
支付处理凭证，其中，在校验通过后，支付处理服务器将支付处理凭证获取请求转发至与支
付渠道相对应的第三方支付平台进行处理以获取第三方支付平台所生成的支付处理凭证；
本实施例中，当支付处理客户端10获取到用户所选择的支付渠道时，将通过支付
凭证请求模块130向支付处理服务器20发起支付渠道的支付处理凭证获取请求，以获取第
三方支付平台50所生成的支付处理凭证。此外，需要说明的是，该支付处理凭证获取请求中
包含有订单或订单的相关信息，进而以便于得到该订单所对应的支付处理凭证，比如订单
支付金额、收付款双方账户等。
为保证支付处理凭证获取请求的真实安全性，本实施例中，支付处理服务器20需
要对支付处理凭证获取请求进行校验，且在校验通过后才可转发支付处理凭证，具体为：支
付处理服务器20在对支付处理凭证获取请求进行校验且校验通过后，支付处理服务器20将
支付处理凭证获取请求转发至与支付渠道相对应的第三方支付平台50进行处理以获取第
三方支付平台50所生成的支付处理凭证，并再将该支付处理凭证转发给支付处理客户端
10。
例如，目标客户端30所选择支付渠道为支付宝支付渠道，则支付处理客户端10以
支付宝支付渠道向支付处理服务器20发起支付宝支付渠道的支付处理凭证获取请求，支付
处理服务器20相对该请求进行校验且通过后，再转发给支付宝支付平台50进行处理，并由
支付宝支付平台50生成相应的支付处理凭证，同时，支付处理服务器20再将该支付处理凭
证转发给支付处理客户端10。
支付请求模块140，用于通过支付处理凭证向第三方支付平台发起支付请求，以通
过第三方支付平台对订单进行支付处理，并将支付处理完成后由第三方支付平台所生成的
支付结果转发至目标客户端。
支付凭证请求模块130获取到目标客户端30所需支付的订单的支付处理凭证后，
支付请求模块140将通过支付处理凭证向对应第三方支付平台发起支付请求，进而通过第
三方支付平台对订单进行支付处理，从而完成订单的费用结算，同时，第三方支付平台将支
付处理完成后所生成的支付结果返回给支出处理客户端10，并由支出处理客户端10转发给
目标客户端30，从而告知买家用户支付结果，比如订单支付成功或者失败等。
本实施例中，目标客户端在对网购订单进行支付时，目标客户端只需将该网购订
单发送给支付处理客户端，支付处理客户端即可自动完成对该购物订单的支付渠道、支付
处理凭证以及第三方平台的支付处理。同时，支付处理客户端可向目标客户端反馈一种或
多种支付渠道，进而目标客户端及目标服务器无需进行针对多种支付渠道的大量开发与维
护工作量，进而可实现对多种支付渠道的统一集成处理，提升移动应用支付的便捷性。
参照图3，图3为本发明支付处理服务器一实施例的模块示意图。
如图1所示，本实施例中，支付处理客户端10具体应用于具有目标客户端30的移动
终端，支付处理客户端10通过移动终端与支付处理服务器20进行数据通信，目标客户端30
通过移动终端与目标服务器40进行数据通信，支付处理客户端10、支付处理服务器20分别
与第三方支付平台50进行数据通信。
当用户使用目标客户端30在目标服务器40所对应的网站上进行购物时，目标服务
器40将根据目标客户端30的购买请求生成对应的订单，并将订单信息返回给目标客户端
30，进而通过目标客户端30将该订单发送给支付处理客户端10进行支付处理。
为实现对目标客户端30所发送的订单的支付处理，如图3所示，本实施例中支付处
理服务器包括：
支付渠道处理模块210，用于接收支付处理客户端所发起的订单的支付渠道获取
请求，并向所述支付处理客户端返回支付渠道选项；
本实施例中，当支付渠道处理模块210接收支付处理客户端10所发起的订单的支
付渠道获取请求时，支付渠道处理模块210向支付处理客户端10返回支付渠道选项，进而再
由支付处理客户端10转发给目标客户端30以便于买家用户进行选择，同时，目标客户端30
将支付渠道选择结果反馈给支付处理客户端10。
例如，支付处理服务器20所返回的支付渠道选项包括支付宝支付、微信支付、银联
支付三种支付渠道以供用户选择，若用户选择支付宝支付这一支付渠道，则目标客户端30
将用户的支付渠道选择结果反馈给支付处理客户端10。
可选的，支付处理服务器20将根据支付处理客户端10的版本，确定对应的支付渠
道选项。例如，支付处理客户端10的版本为第一版本，则对应的字符渠道选项只有一种支付
渠道；支付处理客户端10的版本为第三版本，则对应的字符渠道选项只有五种支付渠道等。
用户可通过升级支付处理客户端10的发布版本来确定对应返回的支付渠道选项。
本实施例中，订单由目标服务器40根据目标客户端30的购买请求所生成并由目标
客户端30转发给支付处理客户端10。
支付凭证处理模块220，用于接收所述支付处理客户端发起的目标支付渠道的支
付处理凭证获取请求，将所述支付处理凭证获取请求转发至与所述目标支付渠道相对应的
第三方支付平台，接收所述第三方支付平台生成的支付处理凭证，并将所述支付处理凭证
发送给所述支付处理客户端；
本实施例中，支付凭证处理模块220在接收到支付处理客户端10发起的支付渠道
的支付处理凭证获取请求时，将支付处理凭证获取请求转发至对应第三方支付平台50进行
处理以生成支付处理凭证，第三方支付平台50在生成该支付处理凭证后，将该支付处理凭
证反馈给支付凭证处理模块220，进而再由支付凭证处理模块220将该支付处理凭证转发给
支付处理客户端10进行处理。
可选的，为避免后续可能存在经济纠纷等问题，支付凭证处理模块220在转发支付
处理凭证前，备份并保留目标客户端10所发送的订单数据，以便后续可查验订单的支付记
录。
支付结果转发模块230，用于接收所述第三方支付平台生成的支付结果，并将所述
支付结果转发至目标服务器，其中，所述支付处理客户端通过所述支付处理凭证向所述第
三方支付平台发起支付请求，所述第三方支付平台对所述订单进行支付处理并生成支付结
果。
本实施例中，第三方支付平台50根据支付处理凭证完成订单的支付处理时，将支
付处理完成后所生成的支付结果发送给支付结果转发模块230，并由支付结果转发模块230
转发给目标服务器40，进而实现通知目标服务器40向目标客户端30发货。
本实施例中，目标客户端30在对网购订单进行支付时，目标客户端30只需将该网
购订单发送给支付处理客户端10，支付处理客户端10即可通过支付处理服务器20之间的交
互，自动完成对该购物订单的支付渠道、支付处理凭证以及第三方平台50的支付处理。同
时，支付处理客户端10可向目标客户端30反馈一种或多种支付渠道，进而目标客户端30及
目标服务器40无需进行针对多种支付渠道的大量开发与维护工作量，进而可实现对多种支
付渠道的统一集成处理，提升移动应用支付的便捷性。
进一步地，在本发明支付处理服务器一实施例中，为保证资金支付的安全性，同时
也使得目标客户端30能够使用支付处理客户端10进行订单支付，因此，目标服务器40需要
采用支出处理侧所提供的签名规则对订单进行签名(一种特殊加密方式)，得到对应的签名
字符串，从而便于支付处理侧的支付处理服务器20可以通过对签名字符串进行校验，进而
实现对订单的真实性与可靠性的验证。其中，支付处理侧泛指对订单进行支付处理的一方，
其中，支付处理客户端10与支付处理服务器20都属于支付处理侧。
可选的，目标服务器40具体根据如下签名规则对订单进行签名：
规则1：将订单中所有参数按照参数名称所对应的字母顺序进行排序,若遇到相同
首字母，则根据第二(三、四….)个字母进行排序，而对于没有参数值的参数(包括null和“”
情况)则不参与签名；
规则2：参与签名的数据不做URL Encoding，而一律统一采用UTF-8编码方式参与
签名；
规则3：参与签名的数据中，必须还要包含有data_timestamp签名时间戳字段，该
字段对应为接口发起的时间戳，也即目标服务器40进行签名处理的时间，该签名时间戳用
于支付处理服务器20对支付处理客户端10所发起的各种请求进行时间验证，比如，如果签
名时间戳的时间与支付处理服务器20接收处理的时间相差5分钟以上，则支付处理服务器
20将拒绝该请求；
规则4：对订单中参与签名的参数及其对应参数值进行如下拼接处理：按照k1＝
v1&k2＝v2&k3＝v3…格式进行拼接，得到拼接字符串，其中，Kn表示第n个参数，Vn表示第n
个参数所对应的参数值；
规则5：将拼接字符串+“:”+appId+“:”+secret_key用MD5信息摘要算法计算摘要，
得签名字符串，其中，appId、secret_key为签名关键字，具体事先由支付处理侧提供给在支
付处理侧注册的目标客户端，当然，为提高订单支付的安全性，支付处理侧提供给目标客户
端的签名关键字还可以进一步包括用于在支付处理侧唯一标识目标客户端的签名关键字
app_key。
此外，为便于支付处理服务器20对支付处理客户端10所发起的各种请求进行验
证，因此，相应地，支付处理客户端10所发起支付渠道获取请求与支付处理凭证获取请求中
分别都包括采用如上签名规则所生成的签名字符串，从而保证订单信息传输过程中的完整
性与安全性。
参照图4，图4为图3中支付渠道处理模块一实施例的模块示意图。
基于上述支付处理服务器实施例，本实施例中，为实现对支付渠道获取请求进行
验证，进而避免订单被非法篡改，因此，支付渠道处理模块210包括：
接收单元2101，用于接收支付渠道获取请求，并获得签名字符串；
签名校验单元2102，用于根据预置校验规则，对签名字符串进行签名校验；
本实施例中，为避免订单被非法篡改，因此，签名校验单元2102采用预置校验规
则，对签名字符串进行签名校验。
可选的，签名校验单元2102先对签名字符串进行解密，从而获得订单的对应数据；
而后，签名校验单元2102再采用相同的签名规则，对解密的订单的对应数据进行签名处理，
得到待验证签名字符串；最后再将待验证签名字符串与接收获取到的签名字符串进行一一
比对，若比对完全一致，则说明订单传输过程中未被篡改，签名校验通过。
注册校验单元2103，用于在签名校验通过时，根据签名关键字，确定目标客户端是
否已在支付处理侧注册，若已注册，则确定对支付渠道获取请求所进行的校验通过，其中，
若确定对所述支付渠道获取请求所进行的校验通过，则向所述支付处理客户端返回支付渠
道选项。
本实施例中，为进一步保证订单处理的安全性，还将进一步对使用支付处理服务
的目标客户端30进行验证。具体为：目标客户端30需要预先在支付处理侧，比如支付处理开
发平台，进行注册，注册成功后将获得支付处理侧所分配的签名关键字，比如appId、app_
key、secret_key，同时，支付处理侧也将相应保留该目标客户端30的应用信息；而后，注册
校验单元2103在签名校验通过时，根据签名字符串中的签名关键字，获得支付处理侧所保
存的对应目标客户端30的应用信息，也即该目标客户端30已经注册，因而注册校验单元
2103可最终确定对支付渠道获取请求所进行的校验通过。
本实施例中，采用双重校验方式，即通过对传递的订单完整性进行校验，同时也对
发送该订单的目标客户端进行验证，进而避免订单被篡改，同时也保证发送订单可目标客
户端的合法性，从而最终保证订单支付的安全性。
进一步可选的，在本发明支付处理服务器另一实施例中，为避免支付处理服务器
20向目标服务器40转发支付结果不成功而产生经济损失，因此，本实施例中，支付结果转发
模块230还用于：若将支付结果转发至目标服务器的累积失败次数达到预置数值，则启动支
付预警处理，并记录转发失败原因与订单的相关信息。
本实施例中，支付处理服务器20接收到支付结果后，将主动通知目标服务器40，但
在发送通知过程中可能存在网络不通等问题而造成通知失败，因此，本实施例中设置支付
结果通知的最大次数，例如通知累积失败次数超过8次就会发送邮件对支付处理服务器20
的运营人员进行预警，进而通过运营人员手动进行通知，而若手动通知仍然未成功则还会
继续进行邮件预警，或者交由开发人员进行排查处理，直至该支付结果成功通知到目标服
务器40。
本实施例中，通过支付预警处理，进而确保订单的支付结果成功送达至目标服务
器，从而保证订单支付状态的准确性，防止不必要的经济损失。
参照图5，图5为本发明支付处理系统一实施例的模块示意图。本实施例中，支付处
理系统包括支付处理客户端10与支付处理服务器20。
本实施例中，目标客户端30在对网购订单进行支付时，目标客户端30只需将该网
购订单发送给支付处理客户端10，支付处理客户端10即可通过与支付处理服务器20之间的
数据交互而自动完成对该购物订单的支付渠道、支付处理凭证以及第三方平台50的支付处
理。同时，支付处理客户端10可向目标客户端30反馈一种或多种支付渠道，进而目标客户端
30及目标服务器40无需进行针对多种支付渠道的大量开发与维护工作量，进而可实现对多
种支付渠道的统一集成处理，提升移动应用支付的便捷性。
参照图6，图6为本发明支付处理方法第一实施例的流程示意图。
如图1所示，本实施例中，支付处理客户端10具体应用于具有目标客户端30的移动
终端，支付处理客户端10通过移动终端与支付处理服务器20进行数据通信，目标客户端30
通过移动终端与目标服务器40进行数据通信，支付处理客户端10、支付处理服务器20分别
与第三方支付平台50进行数据通信。
本实施例中，支付处理方法包括：
步骤S110，接收目标客户端所发送的由目标服务器根据目标客户端的购买请求所
生成的订单；
本实施例中，对于订单的生成方式及处理规则不限。
可选的，为保证资金支付的安全性，同时也使得目标客户端30能够使用支付处理
客户端10进行订单支付，因此，目标服务器40需要采用支出处理侧所提供的签名规则对订
单进行签名(一种特殊加密方式)，得到对应的签名字符串，从而便于支付处理侧的支付处
理服务器20可以通过对签名字符串进行校验，进而实现对订单的真实性与可靠性的验证，
其中，签名规则的设置不限，具体根据实际需要进行设置。
步骤S120，向支付处理服务器发起订单的支付渠道获取请求，并接收支付处理服
务器对支付渠道获取请求进行校验且校验通过后所返回的支付渠道选项，以及将支付渠道
选项转发至目标客户端以获取目标客户端所选择的支付渠道；
本实施例中，当支付处理客户端10接收到待支付的订单时，支付处理客户端10将
向支付处理服务器20发起订单的支付渠道获取请求，比如获取支付宝支付渠道或微信支付
渠道或银联支付渠道等。其中，支付渠道具体是指进入对订单进行支付处理的入口，可以看
作是一种接口程序。此外，需要说明的是，该支付渠道获取请求中包含有订单或订单的相关
信息，进而以便于得到该订单所对应的支付渠道。
本实施例中，为保证订单的支付渠道获取请求的真实可靠性，支付处理服务器20
需要对支付渠道获取请求进行校验，具体校验内容及方式不限。可选的，支付处理服务器20
通过对目标服务器40对订单进行签名处理后所生成的签名字符串进行签名校验。
当支付处理服务器20对订单的支付渠道获取请求的校验通过时，支付处理服务器
20将返回支付渠道选项给支付处理客户端10，而后再由支付处理客户端10转发给目标客户
端30而在移动终端上进行显示，进而以供买家用户选择需要使用的支付渠道。例如，支付处
理服务器20所返回的支付渠道选项包括支付宝支付、微信支付、银联支付三种支付渠道以
供用户选择，若用户选择支付宝支付这一支付渠道，则目标客户端30将用户的支付渠道选
择结果反馈给支付处理客户端10。
可选的，支付处理服务器20将根据支付处理客户端10的版本，确定对应的支付渠
道选项。例如，支付处理客户端10的版本为第一版本，则对应的字符渠道选项只有一种支付
渠道；支付处理客户端10的版本为第三版本，则对应的字符渠道选项只有五种支付渠道等。
用户可通过升级支付处理客户端10的发布版本来确定对应返回的支付渠道选项。
步骤S130，向支付处理服务器发起支付渠道的支付处理凭证获取请求，并接收支
付处理服务器对支付处理凭证获取请求进行校验且校验通过后所转发的支付处理凭证，其
中，在校验通过后，支付处理服务器将支付处理凭证获取请求转发至与支付渠道相对应的
第三方支付平台进行处理以获取第三方支付平台所生成的支付处理凭证；
本实施例中，当支付处理客户端10获取到用户所选择的支付渠道时，将通过支付
凭证请求模块130向支付处理服务器20发起支付渠道的支付处理凭证获取请求，以获取第
三方支付平台50所生成的支付处理凭证。此外，需要说明的是，该支付处理凭证获取请求中
包含有订单或订单的相关信息，进而以便于得到该订单所对应的支付处理凭证，比如订单
支付金额、收付款双方账户等。
为保证支付处理凭证获取请求的真实安全性，本实施例中，支付处理服务器20需
要对支付处理凭证获取请求进行校验，且在校验通过后才可转发支付处理凭证，具体为：支
付处理服务器20在对支付处理凭证获取请求进行校验且校验通过后，支付处理服务器20将
支付处理凭证获取请求转发至与支付渠道相对应的第三方支付平台50进行处理以获取第
三方支付平台50所生成的支付处理凭证，并再将该支付处理凭证转发给支付处理客户端
10。
例如，目标客户端30所选择支付渠道为支付宝支付渠道，则支付处理客户端10以
支付宝支付渠道向支付处理服务器20发起支付宝支付渠道的支付处理凭证获取请求，支付
处理服务器20相对该请求进行校验且通过后，再转发给支付宝支付平台50进行处理，并由
支付宝支付平台50生成相应的支付处理凭证，同时，支付处理服务器20再将该支付处理凭
证转发给支付处理客户端10。
步骤S140，通过支付处理凭证向第三方支付平台发起支付请求，以通过第三方支
付平台对订单进行支付处理，并将支付处理完成后由第三方支付平台所生成的支付结果转
发至目标客户端。
支付处理客户端10获取到目标客户端30所需支付的订单的支付处理凭证后，支付
处理客户端10将通过支付处理凭证向对应第三方支付平台发起支付请求，进而通过第三方
支付平台对订单进行支付处理，从而完成订单的费用结算，同时，第三方支付平台将支付处
理完成后所生成的支付结果返回给支出处理客户端10，并由支出处理客户端10转发给目标
客户端30，从而告知买家用户支付结果，比如订单支付成功或者失败等。
本实施例中，目标客户端在对网购订单进行支付时，目标客户端只需将该网购订
单发送给支付处理客户端，支付处理客户端即可自动完成对该购物订单的支付渠道、支付
处理凭证以及第三方平台的支付处理。同时，支付处理客户端可向目标客户端反馈一种或
多种支付渠道，进而目标客户端及目标服务器无需进行针对多种支付渠道的大量开发与维
护工作量，进而可实现对多种支付渠道的统一集成处理，提升移动应用支付的便捷性。
进一步地，在本发明支付处理方法另一实施例中，为保证资金支付的安全性，同时
也使得目标客户端30能够使用支付处理客户端10进行订单支付，因此，目标服务器40需要
采用支出处理侧所提供的签名规则对订单进行签名(一种特殊加密方式)，得到对应的签名
字符串，从而便于支付处理侧的支付处理服务器20可以通过对签名字符串进行校验，进而
实现对订单的真实性与可靠性的验证。其中，支付处理侧泛指对订单进行支付处理的一方，
其中，支付处理客户端10与支付处理服务器20都属于支付处理侧。
可选的，目标服务器40具体根据如下签名规则对订单进行签名：
规则1：将订单中所有参数按照参数名称所对应的字母顺序进行排序,若遇到相同
首字母，则根据第二(三、四….)个字母进行排序，而对于没有参数值的参数(包括null和“”
情况)则不参与签名；
规则2：参与签名的数据不做URL Encoding，而一律统一采用UTF-8编码方式参与
签名；
规则3：参与签名的数据中，必须还要包含有data_timestamp签名时间戳字段，该
字段对应为接口发起的时间戳，也即目标服务器40进行签名处理的时间，该签名时间戳用
于支付处理服务器20对支付处理客户端10所发起的各种请求进行时间验证，比如，如果签
名时间戳的时间与支付处理服务器20接收处理的时间相差5分钟以上，则支付处理服务器
20将拒绝该请求；
规则4：对订单中参与签名的参数及其对应参数值进行如下拼接处理：按照k1＝
v1&k2＝v2&k3＝v3…格式进行拼接，得到拼接字符串，其中，Kn表示第n个参数，Vn表示第n
个参数所对应的参数值；
规则5：将拼接字符串+“:”+appId+“:”+secret_key用MD5信息摘要算法计算摘要，
得签名字符串，其中，appId、secret_key为签名关键字，具体事先由支付处理侧提供给在支
付处理侧注册的目标客户端，当然，为提高订单支付的安全性，支付处理侧提供给目标客户
端的签名关键字还可以进一步包括用于在支付处理侧唯一标识目标客户端的签名关键字
app_key。
此外，为便于支付处理服务器20对支付处理客户端10所发起的各种请求进行验
证，因此，相应地，支付处理客户端10所发起支付渠道获取请求与支付处理凭证获取请求中
分别都包括采用如上签名规则所生成的签名字符串，从而保证订单信息传输过程中的完整
性与安全性。
参照图7，图7为本发明支付处理方法第二实施例的流程示意图。
如图1所示，本实施例中，支付处理客户端10具体应用于具有目标客户端30的移动
终端，支付处理客户端10通过移动终端与支付处理服务器20进行数据通信，目标客户端30
通过移动终端与目标服务器40进行数据通信，支付处理客户端10、支付处理服务器20分别
与第三方支付平台50进行数据通信。
本实施例中，支付处理方法包括：
步骤S210，接收支付处理客户端所发起的订单的支付渠道获取请求，并向所述支
付处理客户端返回支付渠道选项；
本实施例中，当支付处理服务器20接收支付处理客户端10所发起的订单的支付渠
道获取请求时，为保证资金支付的安全性，因此，需要对支付渠道获取请求进行校验，具体
校验方式不限。当校验通过时，支付处理服务器20向支付处理客户端10返回支付渠道选项，
进而再由支付处理客户端10转发给目标客户端30以便于买家用户进行选择，同时，目标客
户端30将支付渠道选择结果反馈给支付处理客户端10。
例如，支付处理服务器20所返回的支付渠道选项包括支付宝支付、微信支付、银联
支付三种支付渠道以供用户选择，若用户选择支付宝支付这一支付渠道，则目标客户端30
将用户的支付渠道选择结果反馈给支付处理客户端10。
可选的，支付处理服务器20将根据支付处理客户端10的版本，确定对应的支付渠
道选项。例如，支付处理客户端10的版本为第一版本，则对应的字符渠道选项只有一种支付
渠道；支付处理客户端10的版本为第三版本，则对应的字符渠道选项只有五种支付渠道等。
用户可通过升级支付处理客户端10的发布版本来确定对应返回的支付渠道选项。
本实施例中，订单由目标服务器40根据目标客户端30的购买请求所生成并由目标
客户端30转发给支付处理客户端10。
步骤S220，接收所述支付处理客户端发起的目标支付处理凭证获取请求，将所述
支付处理凭证获取请求转发至与所述目标支付渠道相对应的第三方支付平台，接收所述第
三方支付平台生成的支付处理凭证，并将所述支付处理凭证发送给所述支付处理客户端；
本实施例中，支付处理服务器20在接收到支付处理客户端10发起的支付渠道的支
付处理凭证获取请求时，将支付处理凭证获取请求转发至对应第三方支付平台50进行处理
以生成支付处理凭证，第三方支付平台50在生成该支付处理凭证后，将该支付处理凭证反
馈给支付处理服务器20，进而再由支付处理服务器20将该支付处理凭证转发给支付处理客
户端10进行处理。
可选的，为避免后续可能存在经济纠纷等问题，支付处理服务器20在转发支付处
理凭证前，备份并保留目标客户端10所发送的订单数据，以便后续可查验订单的支付记录。
步骤S230，接收所述第三方支付平台生成的支付结果，并将所述支付结果转发至
目标服务器，其中，所述支付处理客户端通过所述支付处理凭证向所述第三方支付平台发
起支付请求，所述第三方支付平台对所述订单进行支付处理并生成支付结果。
本实施例中，第三方支付平台50根据支付处理凭证完成订单的支付处理时，将支
付处理完成后所生成的支付结果发送给支付处理服务器20，并由支付处理服务器20转发给
目标服务器40，进而实现通知目标服务器40向目标客户端30发货。
本实施例中，目标客户端30在对网购订单进行支付时，目标客户端30只需将该网
购订单发送给支付处理客户端10，支付处理客户端10即可通过支付处理服务器20之间的交
互，自动完成对该购物订单的支付渠道、支付处理凭证以及第三方平台50的支付处理。同
时，支付处理客户端10可向目标客户端30反馈一种或多种支付渠道，进而目标客户端30及
目标服务器40无需进行针对多种支付渠道的大量开发与维护工作量，进而可实现对多种支
付渠道的统一集成处理，提升移动应用支付的便捷性。
进一步可选地，在本发明支付处理方法另一实施例中，为避免支付处理服务器20
向目标服务器40转发支付结果不成功而产生经济损失，因此，本实施例中，支付处理方法还
包括：
若将支付结果转发至目标服务器的累积失败次数达到预置数值，则支付处理服务
器20启动支付预警处理，并记录转发失败原因与订单的相关信息。
本实施例中，支付处理服务器20接收到支付结果后，将主动通知目标服务器40，但
在发送通知过程中可能存在网络不通等问题而造成通知失败，因此，本实施例中设置支付
结果通知的最大次数，例如通知累积失败次数超过8次就会发送邮件对支付处理服务器20
的运营人员进行预警，进而通过运营人员手动进行通知，而若手动通知仍然未成功则还会
继续进行邮件预警，或者交由开发人员进行排查处理，直至该支付结果成功通知到目标服
务器40。
本实施例中，通过支付预警处理，进而确保订单的支付结果成功送达至目标服务
器，从而保证订单支付状态的准确性，防止不必要的经济损失。
以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发
明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技
术领域，均同理包括在本发明的专利保护范围内。