应用内支付的双向认证方法和系统与流程

本发明涉及移动支付技术领域，尤其是一种应用内支付的双向认证方法和系统。

背景技术：

在智能手机或智能机顶盒的应用内支付场景中，一个完整的客户端支付流程包括支付触发、订单传递、支付界面呈现、交易信息传递、扣款等过程。在支付过程中，订单和银行卡的敏感信息会在应用系统与支付系统间传递。

但是，应用系统内的应用客户端和支付系统内的支付客户端有可能会被仿冒、传输的数据有可能被截取或篡改，从而无法保证支付过程的安全性。例如，若支付客户端被仿冒，会导致用户银行卡、第三方账户、密码、身份等敏感信息被窃取，用户资金丢失等安全问题；若应用客户端被仿冒，会导致第三方账户资金付款至危险账户，用户银行卡、密码等敏感信息被泄露，用户资金丢失等安全问题。

现有技术中多是客户端与服务端之间进行身份认证，但这无法解决应用客户端与支付客户端不被仿冒的问题，从而引发应用内支付的安全问题。

技术实现要素：

本发明实施例所要解决的技术问题是：解决应用内支付的不安全性问题。

本发明实施例提供的一种应用内支付的双向认证方法，包括：应用系统对生成的订单进行签名，并将签名后的订单传给支付系统；支付系统对收到的订单进行验签，并在验签通过后进行支付操作，产生支付结 果；支付系统对支付结果进行签名，并将签名后的支付结果传给应用系统；应用系统对收到的支付结果进行验签，并将验签通过后的支付结果通知用户。

在一个实施例中，应用系统对生成的订单进行签名前，对订单进行加密，并将加密和签名后的订单传给支付系统；支付系统对收到的订单进行验签后，对订单进行解密，并在验签通过和解密后进行支付操作，产生支付结果。

在一个实施例中，支付系统对支付结果进行签名后，对支付结果进行加密，并将签名和加密后的支付结果传给应用系统；应用系统对收到的支付结果进行验签后，对支付结果进行解密，并将验签通过和解密后的支付结果通知用户。

在一个实施例中，所述应用系统包括应用客户端；和/或所述支付系统包括支付客户端。

在一个实施例中，所述应用系统包括应用客户端和应用服务器；所述支付系统包括支付客户端和支付服务器；所述应用客户端利用内置的支付公钥对生成的订单进行加密；所述应用服务器利用应用私钥对加密后的订单进行签名；所述支付客户端利用内置的应用公钥对收到的订单进行验签；所述支付服务器利用支付私钥对验签通过后的订单进行解密。

在一个实施例中，所述应用系统包括应用客户端和应用服务器；所述支付系统包括支付客户端和支付服务器；所述支付服务器利用支付私钥对支付结果进行签名；所述支付客户端利用内置的应用公钥对签名后的支付结果进行加密；所述应用客户端利用内置的支付公钥对收到的订单进行验签；所述应用服务器利用应用私钥对验签通过后的支付结果进行解密。

本发明实施例提供的一种应用内支付的双向认证系统，包括：应用系统，用于对生成的订单进行签名，并将签名后的订单传给支付系统；对收到的支付结果进行验签，并将验签通过后的支付结果通知用户；支付系统，用于对收到的订单进行验签，并在验签通过后进行支付操作，产生支付结果；对支付结果进行签名，并将签名后的支付结果传给应用 系统。

在一个实施例中，所述应用系统，还用于在对生成的订单进行签名前，对订单进行加密，并将加密和签名后的订单传给支付系统；所述支付系统，还用于对收到的订单进行验签后，对订单进行解密，并在验签通过和解密后进行支付操作，产生支付结果。

在一个实施例中，所述支付系统，还用于在对支付结果进行签名后，对支付结果进行加密，并将签名和加密后的支付结果传给应用系统；所述应用系统，还用于对收到的支付结果进行验签后，对支付结果进行解密，并将验签通过和解密后的支付结果通知用户。

在一个实施例中，所述应用系统包括应用客户端；和/或所述支付系统包括支付客户端。

在一个实施例中，所述应用系统包括应用客户端和应用服务器；所述支付系统包括支付客户端和支付服务器；所述应用客户端，用于利用内置的支付公钥对生成的订单进行加密；所述应用服务器，用于利用应用私钥对加密后的订单进行签名；所述支付客户端，用于利用内置的应用公钥对收到的订单进行验签；所述支付服务器，用于利用支付私钥对验签通过后的订单进行解密。

在一个实施例中，所述应用系统包括应用客户端和应用服务器；所述支付系统包括支付客户端和支付服务器；所述支付服务器，用于利用支付私钥对支付结果进行签名；所述支付客户端，用于利用内置的应用公钥对签名后的支付结果进行加密；所述应用客户端，用于利用内置的支付公钥对收到的订单进行验签；所述应用服务器，用于利用应用私钥对验签通过后的支付结果进行解密。

本发明在应用系统和支付系统之间增加了对订单和支付结果进行签名和解签的操作，实现了应用系统和支付系统之间的双向认证，从而保证只有经过认证的应用系统和支付系统才能够获取相关信息。与现有技术中订单和支付结果直接在两个系统之间传递相比，提升了应用内支付的安全性。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

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

图1是本发明应用内支付的双向认证方法一个实施例的示意图；

图2是本发明应用内支付的双向认证方法另一个实施例的示意图；

图3是本发明应用内支付的双向认证方法又一个实施例的示意图；

图4是本发明应用内支付的双向认证方法再一个实施例的示意图；

图5是本发明应用内支付的双向认证方法还一个实施例的示意图；

图6是本发明应用内支付的双向认证方法一个应用实施例的示意图；

图7是本发明应用内支付的双向认证系统一个实施例的结构示意图。

具体实施方式

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

除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本发明的范围。

同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。

对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为授权说明书的一部分。

在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具 有不同的值。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

本发明针对现有技术中应用内支付时存在的安全隐患问题，提出了在应用系统和支付系统进行双向认证的方法，该方法不需要对现有网络进行大幅改动，适用于在应用内支付场景下的客户端交易，例如适于但不限于基于智能手机或智能机顶盒的应用内支付场景。

图1是本发明应用内支付的双向认证方法一个实施例的流程示意图。如图1所示，本实施例的方法包括如下步骤：

步骤102，应用系统对生成的订单进行签名，并将签名后的订单传给支付系统。

步骤104，支付系统对收到的订单进行验签，并在验签通过后进行支付操作，产生支付结果。

步骤106，支付系统对支付结果进行签名，并将签名后的支付结果传给应用系统；

步骤108，应用系统对收到的支付结果进行验签，并将验签通过后的支付结果通知用户。

下面以订单为例，对本发明实施例中的签名和验签的过程进行说明。后续提到的签名和验签均可以参照下面的方法进行。然而，应理解，本发明并不限于下述具体的签名和验签方法。

一、签名过程

应用系统可以采用如下方式对生成的订单进行签名：首先，采用散列算法，例如安全散列算法SHA1、SHA2(包括SHA256、SHA512等)、哈希算法MD5等，对订单进行散列运算，生成相应长度的散列值；然后，采用非对称加密算法，例如RSA算法和支付私钥对散列值进行加密，生成数字签名文件。

二、验签过程

支付系统采用与签名相同的散列算法和非对称加密算法对收到的订 单进行验签。例如，签名时采用SHA512散列算法生成512位的散列值md.txt，采用RSA算法和支付私钥对散列值md.txt进行加密，则支付系统可以采用如下方式对订单进行验签：采用SHA512散列算法对订单进行散列运算，生成512位的散列值md.txt；利用RSA算法和支付公钥解密数字签名文件，还原散列值md_ver.txt；比较散列值md.txt和散列值md_ver.txt是否一致，若一致，则验签通过。

应理解，支付系统对支付结果的签名、以及应用系统对支付结果的和验签过程可以参照上述签名和验签过程。在此不再赘述。

本实施例在应用系统和支付系统之间增加了对订单和支付结果进行签名和解签的操作，实现了应用系统和支付系统之间的双向认证，从而保证只有经过认证的应用系统和支付系统才能够获取相关信息。与现有技术中订单和支付结果直接在两个系统之间传递相比，提升了应用内支付的安全性。

为了保证订单不会被截取和篡改，进一步提升支付的安全性，除了对订单进行签名之外，还可以对订单进行加密。图2是本发明应用内支付的双向认证方法另一个实施例的流程示意图。如图2所示，本实施例的双向认证方法包括如下步骤：

步骤202，应用系统对生成的订单进行签名前，对订单进行加密，并将加密和签名后的订单传给支付系统；

步骤204，支付系统对收到的订单进行验签后，对订单进行解密，并在验签通过和解密后进行支付操作，产生支付结果；

步骤206，支付系统对支付结果进行签名，并将签名后的支付结果传给应用系统；

步骤208，应用系统对收到的支付结果进行验签，并将验签通过后的支付结果通知用户。

其中，步骤206与步骤208与图1所示实施例的步骤106与步骤108相同。本实施例进一步提升了支付的安全性。

类似地，为了保证支付结果不会被截取和篡改，进一步提升支付的安全性，除了对支付结果进行签名之外，还对支付结果进行加密。图3 是本发明应用内支付的双向认证方法又一个实施例的流程示意图。如图3所示，本实施例的双向认证方法包括如下步骤：

步骤302，应用系统对生成的订单进行签名，并将签名后的订单传给支付系统。

步骤304，支付系统对收到的订单进行验签，并在验签通过后进行支付操作，产生支付结果。

步骤306，支付系统对支付结果进行签名后，对支付结果进行加密，并将签名和加密后的支付结果传给应用系统；

步骤308，应用系统对收到的支付结果进行验签后，对支付结果进行解密，并将验签通过和解密后的支付结果通知用户。

其中，步骤302与步骤304与图1所示实施例的步骤102与步骤104相同。本实施例进一步提升了支付的安全性。

需要说明的是，图2中的步骤202和步骤204以及图3所示实施例的步骤306和步骤308可以组合，从而在双向认证的过程中可以对订单和认证结果都进行签名，同时也对订单和认证结果都进行加密，从而进一步提高支付的安全性。

图1至图3所示的实施例中，应用系统也可以仅包括应用服务器，支付系统也可以仅包括支付服务器。

图4是本发明应用内支付的双向认证方法还一个实施例的流程示意图。本实施例，应用系统包括应用客户端，支付系统包括支付客户端，与图1所示实施例相比，本实施例由应用客户端和支付客户端实现签名和验签的操作。如图4所示，本实施例的方法包括如下步骤：

步骤402，应用客户端对生成的订单进行签名，并将签名后的订单传给支付客户端；

步骤404，支付客户端对收到的订单进行验签，并在验签通过后进行支付操作，产生支付结果；

步骤406，支付客户端对支付结果进行签名，并将签名后的支付结果传给应用客户端；

步骤408，应用客户端对收到的支付结果进行验签，并将验签通过 后的支付结果通知用户。

本实施例双向认证方法中，可以将签名和验签的操作通过应用客户端和支付客户端来实现。

图5是本发明应用内支付的双向认证方法再一个实施例的流程示意图。本实施例中，应用系统可以包括应用客户端和应用服务器；支付系统可以包括支付客户端和支付服务器。如图5所示，本实施例的方法包括如下步骤：

步骤502，应用客户端利用内置的支付公钥对生成的订单进行加密，之后将订单传给应用服务器；

步骤504，应用服务器利用CA(证书授权)中心分发的应用私钥对加密后的订单进行签名，之后回传给应用客户端，由应用客户端将加密和签名后的订单传给支付客户端。

步骤506，支付客户端利用内置的应用公钥对收到的订单进行验签，验签通过后将订单传给支付服务器；

步骤508，支付服务器利用CA中心分发的支付私钥对验签通过后的订单进行解密，之后回传给支付客户端。支付客户端收集用户支付要素，执行支付操作，向支付服务器传递扣款请求；支付服务器扣款成功后，产生支付结果。

步骤510，支付服务器利用CA中心分发的支付私钥对支付结果进行签名，之后传给支付客户端，并将支付结果通知应用服务器；

步骤512，支付客户端利用内置的应用公钥对签名后的支付结果进行加密，之后传给应用客户端。

步骤514，应用客户端利用内置的支付公钥对收到的订单进行验签，之后传给应用服务器申请解密；

步骤516，应用服务器利用CA中心分发的应用私钥对验签通过后的支付结果进行解密，之后将支付结果通过应用客户端通知给用户。

本实施例中，应用客户端预制支付私钥，同时在应用服务器存储应用私钥；支付客户端预制应用私钥，同时在支付服务器存储支付私钥。一方面，可以保证数据来源的合法性，保证只有经过认证的客户端能够 读取数据信息，保证应用客户端和支付客户端不被仿冒；另一方面，也可以保证数据在传输过程中不会被截取和篡改。

图6为本发明应用内支付的双向认证方法一个应用实施例的流程示意图。下面参照图6对一个完整的支付过程进行说明。如图6所示，本实施例的方法包括如下步骤：

步骤601，用户通过应用客户端选择商品；

步骤602，应用客户端向应用服务器请求生成订单；

步骤603，应用服务器生成订单并传给应用客户端；

步骤604，应用客户端使用支付公钥加密订单；

步骤605，应用客户端在加密订单之后向应用服务器申请订单签名；

步骤606，应用服务器使用应用私钥签名订单；

步骤607，应用服务器返回签名订单给应用客户端；

步骤608，应用客户端将订单传递给支付客户端，发起支付请求；

步骤609，支付客户端使用公钥验证签名；

步骤610，支付客户端在验证通过后向支付服务器申请解密订单；

步骤611，支付服务器使用支付私钥解密订单；

步骤612，支付服务器返回已解密订单给支付客户端；

步骤613，支付客户端将支付页面展示给用户；

步骤614，支付客户端收集用户支付要素，例如卡号、密码等，然后向支付服务器发起扣款请求；

步骤615，支付服务器处理扣款，使用支付私钥对支付结果签名；

步骤616，支付服务器返回签名的支付结果给支付客户端，并将支付结果通知应用服务器；

步骤617，支付客户端使用应用公钥对支付结果加密；

步骤618，支付客户端将加密后的支付结果传给应用客户端；

步骤619，应用客户端使用支付公钥对支付结果验证签名；

步骤620，应用客户端在验证通过后向应用服务器申请解密；

步骤621，应用服务器使用应用私钥对支付结果进行解密；

步骤622，应用服务器返回解密的支付结果给应用客户端；

步骤623，应用客户端将支付结果通知用户。

本实施例在应用系统内预制支付系统的支付公钥并存储本系统的应用私钥，在支付系统内预制应用系统的应用公钥并存储本系统的支付私钥，实现了应用系统与支付系统之间的双向认证，提升了应用内支付的安全性。具体来说，应用客户端预制支付私钥，同时在应用服务器存储应用私钥；支付客户端预制应用私钥，同时在支付服务器存储支付私钥。一方面，可以保证数据来源的合法性，保证只有经过认证的客户端能够读取数据信息，保证应用客户端和支付客户端不被仿冒；另一方面，也可以保证数据在传输过程中不会被截取和篡改。

本说明书中各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似的部分相互参见即可。对于系统实施例而言，由于其与方法实施例基本对应，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

图7是本发明应用内支付的双向认证系统一个实施例的结构示意图。如图7所示，本实施例的系统包括：

应用系统701，用于对生成的订单进行签名，并将签名后的订单传给支付系统702；对收到的支付结果进行验签，并将验签通过后的支付结果通知用户；

支付系统702，用于对收到的订单进行验签，并在验签通过后进行支付操作，产生支付结果；对支付结果进行签名，并将签名后的支付结果传给应用系统701。

为了保证订单不会被截取和篡改，进一步提升支付的安全性，除了对订单进行签名之外，还可以对订单进行加密。在一个实施例中，应用系统701，还用于在对生成的订单进行签名前，对订单进行加密，并将加密和签名后的订单传给支付系统702。相应地，该实施例中的支付系统702，还用于对收到的订单进行验签后，对订单进行解密，并在验签通过和解密后进行支付操作，产生支付结果。

为了保证支付结果不会被截取和篡改，进一步提升支付的安全性，除了对支付结果进行签名之外，还可以对支付结果进行加密。在一个实 施例中，支付系统702，还用于在对支付结果进行签名后，对支付结果进行加密，并将签名和加密后的支付结果传给应用系统701。相应地，该实施例中的应用系统701，还用于对收到的支付结果进行验签后，对支付结果进行解密，并将验签通过和解密后的支付结果通知用户。

上述各实施例中的应用系统和支付系统可以有不同的实现方式。

一种示例性的实现方式中，应用系统701可以包括应用客户端7011；和/或支付系统702可以包括支付客户端7021。通过应用客户端和支付客户端实现加密/签名，以及解密/验签的操作。

另一种示例性的实现方式中，参加图7，应用系统701可以包括应用客户端7011和应用服务器7012，支付系统702包括支付客户端7021和支付服务器7022。

一种情况下，应用客户端7011，用于利用内置的支付公钥对生成的订单进行加密；应用服务器7012，用于利用应用私钥对加密后的订单进行签名；支付客户端7021，用于利用内置的应用公钥对收到的订单进行验签；支付服务器7022，用于利用支付私钥对验签通过后的订单进行解密。

另一种情况下，支付服务器7022，用于利用支付私钥对支付结果进行签名；支付客户端7021，用于利用内置的应用公钥对签名后的支付结果进行加密；应用客户端7011，用于利用内置的支付公钥对收到的订单进行验签；应用服务器7012，用于利用应用私钥对验签通过后的支付结果进行解密。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

本发明的描述是为了示例和描述起见而给出的，而并不是无遗漏的或者将本发明限于所公开的形式。很多修改和变化对于本领域的普通技术人员而言是显然的。选择和描述实施例是为了更好说明本发明的原理 和实际应用，并且使本领域的普通技术人员能够理解本发明从而设计适于特定用途的带有各种修改的各种实施例。