CN106779702A - 支付方法及支付*** - Google Patents

Abstract

本发明公开一种支付方法及支付***，所述方法包括：客户端接收用户输入的下单请求；所述收款方服务器将所述下单请求按照预设的签名规则进行签名以生成订单信息；所述客户端将所述订单信息按照预设的格式生成请求数据；所述支付平台解密所述请求数据，获取所述订单信息；验证所述订单信息的签名，并在验证成功后生成支付凭证；将所述支付凭证按照预设的加密方式进行加密；所述客户端解密所述支付凭证，并根据所述支付凭证中的支付信息调用支付工具进行支付操作。本发明的技术方案，通过对客户端、收款方服务器及支付平台之间的交互数据按照不同的方式进行加密，有效保证了交互数据的安全性，进而保证了提升了支付操作的安全性。

Description

支付方法及支付***

技术领域

本发明涉及通信技术领域，特别涉及一种支付方法及支付***。

背景技术

随着移动互联网技术的发展，移动终端的普及率越来越高，在电子交易平台的交易过程中，用户使用移动终端的频率也越来越高，并且在电子交易平台的交易环节中，越来越多的人通过移动终端进行支付。

在电子交易过程中，用户主要考虑的是支付操作的安全性，那么，如何提高在电子交易中支付操作的安全性，就成为一个亟待解决的技术问题。

发明内容

本发明的主要目的是提供一种支付方法及支付***，旨在有效提升支付操作的安全性。

为实现上述目的，本发明提出的支付方法，包括如下步骤：

客户端接收用户输入的下单请求，并将所述下单请求发送至收款方服务器；

所述收款方服务器将所述下单请求按照预设的签名规则进行签名以生成订单信息，并将所述订单信息发送至所述客户端；

所述客户端将所述订单信息按照预设的格式生成请求数据，并将所述请求数据发送至支付平台；

所述支付平台解密所述请求数据，获取所述订单信息；验证所述订单信息的签名，并在验证成功后生成支付凭证；将所述支付凭证按照预设的加密方式进行加密，并将加密后的支付凭证发送至所述客户端；

所述客户端解密所述支付凭证，并根据所述支付凭证中的支付信息调用支付工具进行支付操作。

可选的，所述客户端将所述订单信息按照预设的格式生成请求数据的步骤包括：

在所述订单信息中添加二进制协议头。

可选的，所述将所述支付凭证预设的加密方式进行加密的步骤包括：

在所述支付凭证中添加二进制协议头。

可选的，所述支付方法还包括：

支付成功后，所述支付平台向所述收款方服务器反馈支付成功信息。

可选的，所述向所述收款方服务器反馈支付成功信息的步骤包括：

所述支付平台接收所述支付工具反馈的支付成功信息，并将所述支付成功信息发送至所述收款方服务器；

判断所述支付成功信息是否发送成功；

如果否，则记录发送失败的原因，并在到达预设时间时，再次向发送所述支付成功信息；

当发送失败次数大于或等于预设次数时，保留最后一次发送失败的原因，并向所述收款方服务器发送预警邮件。

为实现上述目的，本发明提出一种支付***，包括客户端、收款方服务器、支付平台及支付工具；其中，

所述客户端，用于接收用户输入的下单请求，并将所述下单请求发送至所述收款方服务器；

所述收款方服务器，用于将所述下单请求按照预设的签名规则进行签名以生成订单信息，并将所述订单信息发送至所述客户端；

所述客户端，用于将所述订单信息按照预设的格式生成请求数据，并将所述请求数据发送至支付平台；

所述支付平台，用于解密所述请求数据，获取所述订单信息；验证所述订单信息的签名，并在验证成功后生成支付凭证；将所述支付凭证按照预设的加密方式进行加密，并将加密后的支付凭证发送至所述客户端；

所述客户端，用于解密所述支付凭证，并根据所述支付凭证中的支付信息调用支付工具；

所述支付工具，用于执行支付操作。

可选的，所述客户端用于在所述请求数据中添加二进制协议头。

可选的，所述支付平台用于在所述支付凭证中添加二进制协议头。

可选的，所述支付平台，还用于在支付成功后，向所述收款方服务器反馈支付成功信息。

可选的，所述支付平台包括：执行模块与判断模块；其中，

所述执行模块，用于接收所述支付工具反馈的支付成功信息，并将所述支付成功信息发送至所述收款方服务器；

所述判断模块，用于判断所述支付成功信息是否发送成功；

所述执行模块，还用于在所述支付成功信息发送失败后，记录发送失败的原因，并在到达预设时间时，再次向发送所述支付成功信息；

所述执行模块，还用于在发送失败次数大于或等于预设次数时，保留最后一次发送失败的原因，并向所述收款方服务器发送预警邮件。

本发明的技术方案，通过对客户端、收款方服务器及支付平台之间的交互数据按照不同的方式进行加密，有效保证了交互数据的安全性，进而保证了提升了支付操作的安全性。

附图说明

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

图1为本发明支付方法一实施例的流程图；

图2为本发明支付方法另一实施例的流程图；

图3为图2中向所述收款方服务器反馈支付成功信息的步骤的流程图；

图4为本发明支付***一实施例的模块示意图；

图5为实现本发明支付***一实施例的流程示意图；

图6为图4中支付平台一实施例的模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

现在将参考附图描述实现本发明各个实施例的移动终端。在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身并没有特定的意义。因此，“模块”与“部件”可以混合地使用。

本发明提出一种支付方法。本发明的支付方法应用于移动终端，但不限于移动终端。下面以移动终端为例进行说明：

如图1所示，图1为本发明支付方法一实施例的流程图。

本实施的支付方法，包括如下步骤：

步骤S100、客户端接收用户输入的下单请求，并将所述下单请求发送至收款方服务器。

具体的，所述客户端安装于移动终端内。所述客户端为对应所述收款方服务器的应用程序(比如，游戏客户端等)。用户在移动终端上下载与游戏商提供的服务器对应的客户端。

当用户需要对客户端进行充值等支付动作时，用户可以通过客户端上的充值模块触发充值界面，并选择或自行输入充值类型、充值数额等，并确定。客户端根据用户输入的充值类型与充值数额生成下单请求，并将所述下单请求发送至收款方服务器。

步骤S200、所述收款方服务器将所述下单请求按照预设的签名规则进行签名，以生成订单信息，并将所述订单信息发送至所述客户端。

具体的，所述收款方服务器需要向第三方支付平台进行注册，以获取相关信息：appId、appKey、appSecurity等，其中，appId用于表示不同的应用，而appSecurity用于对订单请求进行签名。

当所述收款方服务器接收到所述下单请求后，根据以下签名规则对订单请求进行签名，进而生成订单信息。

签名规则：

1，参数排序，将所有参数名按字母顺序进行排序，若遇到相同首字母，则看第二个字母，没有值的参数(如null和””情况)不要参与签名；

2，参与签名的数据不要做URL Encoding，一律以UTF-8编码参与签名；

3，参与签名的数据中，必须有字段data_timestamp；

4，参数拼接，将所有参数按k1＝v1&k2＝v2&k3＝v3…格式进行拼接；

5，将第4步所得字符串后面加上“:”、appId、appSecurity，得到一个新的字符串，用md5对新字符串进行摘要计算，得签名字符串(也即，具有签名的订单信息)。

步骤S300、所述客户端将所述订单信息按照预设的格式生成请求数据，并将所述请求数据发送至支付平台(也即上述的第三方支付平台)。

具体的，当所述客户端接收到所述收款方服务器发送的订单信息后，在所述订单信息中添加二进制协议头，以生成加密的请求数据，并将所述请求数据发送至所述第三方支付平台。

在本步骤中，所述二进制协议头包含有64个字节，其中，0-3字节表示appId；4-5字节表示接口编号；6-7字节表示版本号；8-39字节表示一个会话；40字节表示加密方式；41-42用于校验；其他字节数保留。也即，所述请求数据包括二进制协议头与具有签名的订单信息。

步骤S400、所述支付平台解密所述请求数据，获取所述订单信息；验证所述订单信息的签名，并在验证成功后生成支付凭证；将所述支付凭证按照预设的加密方式进行加密，并将加密后的支付凭证发送至所述客户端。

具体的，当所述支付平台接收到所述请求数据后，先对所述请求数据进行解密分析，以获得包含在所述请求数据中的具有签名的订单信息。然后对签名进行验证，当验证验证通过后，保存所述订单信息，并根据所述订单信息生成支付凭证。接着，在所述支付凭证中添加二进制协议头，以加密所述支付凭证。最后，将加密后的支付凭证发送至所述客户端。

在本步骤中，所述二进制协议头包含有32字节，其中，0-1字节表示接口编号；2字节表示加密方式；3-4字节用户校验；8-11字节表示错误码；其他字节保留。也即，锁住支付凭证包括二进制协议头与支付凭证的真实信息。

步骤S500、所述客户端解密所述支付凭证，并根据所述支付凭证中的支付信息调用支付工具进行支付操作。

具体的，当所述客户端接收到所述支付凭证后，解密所述支付凭证，以获取支付凭证中包含的真实信息，并根据该真实信息调用支付工具(安装于移动终端内的应用程序，比如，微信、支付宝、手机银行等)进行支付操作。

本实施例的支付方法，通过对客户端、收款方服务器及支付平台之间的交互数据按照不同的方式进行加密，有效保证了交互数据的安全性，进而保证了提升了支付操作的安全性。

进一步的，如图2及图3所示，图2为本发明支付方法另一实施例的流程图；图3为图2中向所述收款方服务器反馈支付成功信息的步骤的流程图。

基于上述实施例，在本实施例中，所述支付方法还包括：

步骤S600、支付成功后，所述支付平台向所述收款方服务器反馈支付成功信息。

在本实施例中，所述向所述收款方服务器反馈支付成功信息的步骤包括：

步骤S610、所述支付平台接收所述支付工具反馈的支付成功信息，并将所述支付成功信息发送至所述收款方服务器。

具体的，当支付成功后，所述支付工具向所述支付平台反馈支付成功信息，以通知所述支付平台对订单状态进行变更。所述支付平台将订单状态变更为已付款后，向所述收款方服务器发送支付成功信息，以通知所述收款方服务器对订单状态进行变更。

步骤S620、判断所述支付成功信息是否发送成功；

如果是，则流程结束。

如果否，则执行步骤S630。

步骤S630、记录发送失败的原因，并在到达预设时间时，再次向发送所述支付成功信息。

具体的，当所述支付平台向所述收款方服务器发送了支付成功信息后，判断是否接收到相应的反馈，如果否，则认定该次发送失败。当判定为发送失败后，记录该次发送失败的原因，并在预设的时间到达后，再次向所述收款方服务器发送该支付成功信息。如此循环，至发送成功，或发送失败次数大于或等于预设次数(比如8次)后停止发送。

步骤S640、当发送失败次数大于或等于预设次数时，保留最后一次发送失败的原因，并向所述收款方服务器发送预警邮件。

具体的，当发送失败次数大于或等于预设次数时，保留最后一次发送失败的原因，并向所述收款方服务器发送预警邮件

值得一提的是，在预警邮件中设置有回调机制，运营人员收到发送的预警邮件后，并更改了出错的问题，可以在邮件中点击“手动回调”按钮，再次执行上述通知收款方服务器支付成功信息的步骤。

本实施例的技术方案，通过多次送达及邮件预警机制，极大地提升了支付成功的几率，保证了用户的体验度。

本发明还提出一种支付***。本发明的支付***应用于移动终端，但不限于移动终端。下面以移动终端为例进行说明：

如图4所示，图4为本发明支付***一实施例的模块示意图。

本实施例的支付***包括客户端110、收款方服务器120、支付平台130及支付工具140；其中，所述客户端110，用于接收用户输入的下单请求，并将所述下单请求发送至所述收款方服务器120；所述收款方服务器120，用于将所述下单请求按照预设的签名规则进行签名以生成订单信息，并将所述订单信息发送至所述客户端110；所述客户端110，用于将所述订单信息按照预设的格式生成请求数据，并将所述请求数据发送至支付平台130；所述支付平台130，用于解密所述请求数据，获取所述订单信息；验证所述订单信息的签名，并在验证成功后生成支付凭证；将所述支付凭证按照预设的加密方式进行加密，并将加密后的支付凭证发送至所述客户端110；所述客户端110，用于解密所述支付凭证，并根据所述支付凭证中的支付信息调用支付工具140；所述支付工具140，用于执行支付操作。

具体的，所述客户端110安装于移动终端内。所述客户端110为对应所述收款方服务器120的应用程序(比如，游戏客户端110等)。用户在移动终端上下载与游戏商提供的服务器对应的客户端110。当用户需要对客户端110进行充值等支付动作时，用户可以通过客户端110上的充值模块触发充值界面，并选择或自行输入充值类型、充值数额等，并确定。客户端110根据用户输入的充值类型与充值数额生成下单请求，并将所述下单请求发送至收款方服务器120。

所述收款方服务器120需要向第三方支付平台130进行注册，以获取相关信息：appId、appKey、appSecurity等，其中，appId用于表示不同的应用，而appSecurity用于对订单请求进行签名。当所述收款方服务器120接收到所述下单请求后，根据以下签名规则对订单请求进行签名，进而生成订单信息。

签名规则：

1，参数排序，将所有参数名按字母顺序进行排序，若遇到相同首字母，则看第二个字母，没有值的参数(如null和””情况)不要参与签名；

2，参与签名的数据不要做URL Encoding，一律以UTF-8编码参与签名；

3，参与签名的数据中，必须有字段data_timestamp；

4，参数拼接，将所有参数按k1＝v1&k2＝v2&k3＝v3…格式进行拼接；

5，将第4步所得字符串后面加上“:”、appId、appSecurity，得到一个新的字符串，用md5对新字符串进行摘要计算，得签名字符串(也即，具有签名的订单信息)。

当所述客户端110接收到所述收款方服务器120发送的订单信息后，在所述订单信息中添加二进制协议头，以生成加密的请求数据，并将所述请求数据发送至所述第三方支付平台130。所述二进制协议头包含有64个字节，其中，0-3字节表示appId；4-5字节表示接口编号；6-7字节表示版本号；8-39字节表示一个会话；40字节表示加密方式；41-42用于校验；其他字节数保留。也即，所述请求数据包括二进制协议头与具有签名的订单信息。

当所述支付平台130接收到所述请求数据后，先对所述请求数据进行解密分析，以获得包含在所述请求数据中的具有签名的订单信息。然后对签名进行验证，当验证通过后，保存所述订单信息，并根据所述订单信息生成支付凭证。接着，在所述支付凭证中添加二进制协议头，以加密所述支付凭证。最后，将加密后的支付凭证发送至所述客户端110。所述二进制协议头包含有32字节，其中，0-1字节表示接口编号；2字节表示加密方式；3-4字节用户校验；8-11字节表示错误码；其他字节保留。也即，锁住支付凭证包括二进制协议头与支付凭证的真实信息。

当所述客户端110接收到所述支付凭证后，解密所述支付凭证，以获取支付凭证中包含的真实信息，并根据该真实信息调用支付工具140(安装于移动终端内的应用程序，比如，微信、支付宝、手机银行等)进行支付操作。

本实施例的支付***，通过对客户端110、收款方服务器120及支付平台130之间的交互数据按照不同的方式进行加密，有效保证了交互数据的安全性，进而保证了提升了支付操作的安全性。

进一步的，如图图5及6所示，图5为实现本发明支付***一实施例的流程示意图；图6为图4中支付平台一实施例的模块示意图。

基于上述实施例，在本实施例中，所述支付平台130，还用于在支付成功后，向所述收款方服务器120反馈支付成功信息。

所述支付平台130包括：执行模块132与判断模块134；其中，所述执行模块132，用于接收所述支付工具140反馈的支付成功信息，并将所述支付成功信息发送至所述收款方服务器120；所述判断模块134，用于判断所述支付成功信息是否发送成功；所述执行模块132，还用于在所述支付成功信息发送失败后，记录发送失败的原因，并在到达预设时间时，再次向发送所述支付成功信息；所述执行模块132，还用于在发送失败次数大于或等于预设次数时，保留最后一次发送失败的原因，并向所述收款方服务器120发送预警邮件。

具体的，当支付成功后，所述支付工具140向所述支付平台130反馈支付成功信息，以通知所述支付平台130对订单状态进行变更。所述支付平台130将订单状态变更为已付款后，向所述收款方服务器120发送支付成功信息，以通知所述收款方服务器120对订单状态进行变更。

当所述支付平台130向所述收款方服务器120发送了支付成功信息后，判断是否接收到相应的反馈，如果是，则结束，如果否，则认定该次发送失败。当判定为发送失败后，记录该次发送失败的原因，并在预设的时间到达后，再次向所述收款方服务器120发送该支付成功信息。如此循环，至发送成功，或发送失败次数大于或等于预设次数(比如8次)后停止发送。

当发送失败次数大于或等于预设次数时，保留最后一次发送失败的原因，并向所述收款方服务器120发送预警邮件

值得一提的是，在预警邮件中设置有回调机制，运营人员收到发送的预警邮件后，并更改了出错的问题，可以在邮件中点击“手动回调”按钮，再次执行上述通知收款方服务器120支付成功信息的步骤。

本实施例的技术方案，通过多次送达及邮件预警机制，极大地提升了支付成功的几率，保证了用户的体验度。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是移动终端，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

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

客户端接收用户输入的下单请求，并将所述下单请求发送至收款方服务器；

所述收款方服务器将所述下单请求按照预设的签名规则进行签名以生成订单信息，并将所述订单信息发送至所述客户端；

所述客户端将所述订单信息按照预设的格式生成请求数据，并将所述请求数据发送至支付平台；

所述支付平台解密所述请求数据，获取所述订单信息；验证所述订单信息的签名，并在验证成功后生成支付凭证；将所述支付凭证按照预设的加密方式进行加密，并将加密后的支付凭证发送至所述客户端；

所述客户端解密所述支付凭证，并根据所述支付凭证中的支付信息调用支付工具进行支付操作。

2.如权利要求1所述的支付方法，其特征在于，所述客户端将所述订单信息按照预设的格式生成请求数据的步骤包括：

在所述订单信息中添加二进制协议头。

3.如权利要求1所述的支付方法，其特征在于，所述将所述支付凭证预设的加密方式进行加密的步骤包括：

在所述支付凭证中添加二进制协议头。

4.如权利要求1至3中任意一项所述的支付方法，其特征在于，还包括：

支付成功后，所述支付平台向所述收款方服务器反馈支付成功信息。

5.如权利要求4所述的支付方法，其特征在于，所述向所述收款方服务器反馈支付成功信息的步骤包括：

所述支付平台接收所述支付工具反馈的支付成功信息，并将所述支付成功信息发送至所述收款方服务器；

判断所述支付成功信息是否发送成功；

如果否，则记录发送失败的原因，并在到达预设时间时，再次向发送所述支付成功信息；

当发送失败次数大于或等于预设次数时，保留最后一次发送失败的原因，并向所述收款方服务器发送预警邮件。

6.一种支付***，其特征在于，包括客户端、收款方服务器、支付平台及支付工具；其中，

所述客户端，用于接收用户输入的下单请求，并将所述下单请求发送至所述收款方服务器；

所述收款方服务器，用于将所述下单请求按照预设的签名规则进行签名以生成订单信息，并将所述订单信息发送至所述客户端；

所述客户端，用于将所述订单信息按照预设的格式生成请求数据，并将所述请求数据发送至支付平台；

所述支付平台，用于解密所述请求数据，获取所述订单信息；验证所述订单信息的签名，并在验证成功后生成支付凭证；将所述支付凭证按照预设的加密方式进行加密，并将加密后的支付凭证发送至所述客户端；

所述客户端，用于解密所述支付凭证，并根据所述支付凭证中的支付信息调用支付工具；

所述支付工具，用于执行支付操作。

7.如权利要求6所述的支付***，其特征在于，所述客户端用于在所述请求数据中添加二进制协议头。

8.如权利要求6所述的支付***，其特征在于，所述支付平台用于在所述支付凭证中添加二进制协议头。

9.如权利要求6至8中任意一项所述的支付***，其特征在于，

所述支付平台，还用于在支付成功后，向所述收款方服务器反馈支付成功信息。

10.如权利要求9所述的支付***，其特征在于，所述支付平台包括：执行模块与判断模块；其中，

所述执行模块，用于接收所述支付工具反馈的支付成功信息，并将所述支付成功信息发送至所述收款方服务器；

所述判断模块，用于判断所述支付成功信息是否发送成功；

所述执行模块，还用于在所述支付成功信息发送失败后，记录发送失败的原因，并在到达预设时间时，再次向发送所述支付成功信息；

所述执行模块，还用于在发送失败次数大于或等于预设次数时，保留最后一次发送失败的原因，并向所述收款方服务器发送预警邮件。