CN103561115A - 实时获取电子码的方法、开放平台及系统 - Google Patents

Abstract

本发明涉及一种实时获取电子码的方法、开放平台及系统，该方法包括：开放平台接收到第三方应用服务器发送的前端支付请求后，通过第一接口向第三方应用服务器发送通知消息；通过第二接口接收第三方应用服务器根据通知消息返回的订单核实请求；当确定订单核实请求合法时，向第三方应用服务器返回验证成功消息；接收第三方应用服务器收到验证成功消息后返回的与订单核实请求对应的电子码，并将电子码提供给预设的用户终端。由此解决了现有技术中，第三方应用服务器必须以手动方式预先向开放平台内导入一定批量的电子码所导致的操作繁琐等问题。

Description

实时获取电子码的方法、开放平台及系统

技术领域

本发明涉及网络通信技术领域，具体涉及一种实时获取电子码的方法、开放平台及系统。

背景技术

开放平台能够将其提供的各类服务封装成一系列计算机易识别的数据接口，第三方开发者直接调用这些开放的数据接口就可以享用开放平台的相应服务，这些开放的数据接口也叫做Open API，提供这些Open API的平台本身就被称为开放平台。

利用第三方应用服务器提供的电子码向用户提供电子码的推送服务是目前开放平台的一个典型应用。在这种应用场景中，第三方应用服务器需要提供可以流通的电子码，并将提供的电子码通过开放平台推送给需要该电子码的用户终端。图1示出了上述应用场景的示意图。如图1所示，为了实现电子码在开放平台上的流通，第三方应用开发者（即操作上述第三方应用服务器的操作人员）需要事先将欲在该开放平台上流通的电子码以手动方式导入该开放平台内。具体的导入流程如图2所示，首先，第三方应用开发者需要生成一个用于存储电子码的序列号文件；然后登录到开放平台提供的导入后台，在该导入后台上提交该第三方应用开发者的信息，并上传之前生成的序列号文件；最后，确认上传结果，以实现电子码的最终导入。在导入电子码之后，开放平台就可以基于导入的电子码向用户提供电子码的推送服务。图1中还示出了电子码的找回功能，该功能与本发明关系不大，此处暂不介绍。

由此可见，利用现有的开放平台实现电子码的流通之前，必须先将电子码导入到该平台内。但是，上述手动导入电子码的操作方式非常繁琐，需要耗费大量的人力成本。而且，在手动导入电子码时，通常是一次性向开放平台内导入一定批量的电子码以供流通。这样，开放平台还需要为这些预先导入的电子码预付一定的费用，因此，开放平台还将承担预付成本的损失风险。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的实时获取电子码的方法、开放平台及系统。

依据本发明的一个方面，提供了一种实时获取电子码的方法，包括：开放平台接收到第三方应用服务器发送的前端支付请求后，通过第一接口向第三方应用服务器发送通知消息；通过第二接口接收第三方应用服务器根据通知消息返回的订单核实请求；当确定订单核实请求合法时，向第三方应用服务器返回验证成功消息；接收第三方应用服务器收到验证成功消息后返回的与订单核实请求对应的电子码，并将电子码提供给预设的用户终端。

依据本发明的另一方面，提供了一种实时获取电子码的开放平台，包括：第一通信模块，适于接收第三方应用服务器发送的前端支付请求；第一接口模块，适于向第三方应用服务器发送通知消息；第二接口模块，适于接收第三方应用服务器根据通知消息返回的订单核实请求；验证模块，适于确定订单核实请求是否合法；第二通信模块，适于在订单核实请求合法时向第三方应用服务器返回验证成功消息，并接收第三方应用服务器收到验证成功消息后返回的与订单核实请求对应的电子码，将电子码提供给预设的用户终端。

依据本发明的另一方面，提供了一种实时获取电子码的系统，包括上述的开放平台，一个或多个用户终端及一个或多个第三方应用服务器。

在本发明提供的实时获取电子码的方法、开放平台及系统中，为第三方应用服务器提供了两个开放的接口（第一接口和第二接口），通过这两个接口，能够实现开放平台与第三方应用服务器之间的实时数据交互，从而使开放平台能够在每次接收到第三方应用服务器发送的前端支付请求后，向第三方应用服务器发送通知消息，接收及验证第三方应用服务器返回的订单核实请求，并在验证通过后向第三方应用服务器返回验证成功消息，最后接收第三方应用服务器据此返回的电子码。通过上述方式能够实现开放平台与第三方应用服务器之间的双向验证机制，能够提高开放平台与第三方应用服务器之间的数据传输的安全性。在安全性得到保障的前提下，第三方应用服务器可以在每次接收到用户发送的与电子码相关的前端支付请求之后，实时地向开放平台发送所需的电子码。由此解决了现有技术中，第三方应用服务器必须以手动方式预先向开放平台内导入一定批量的电子码所导致的操作繁琐等问题。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了现有技术中的第三方应用开发者向开放平台导入电子码时的场景示意图；

图2示出了现有技术中的第三方应用开发者向开放平台导入电子码时的方法流程图；

图3示出了本发明一个实施例提供的实时获取电子码的方法的流程图；

图4示出了本发明另一实施例提供的实时获取电子码的方法的流程图；

图5示出了本发明实施例提供的实时获取电子码的开放平台的结构图；

图6示出了本发明实施例提供的实时获取电子码的系统的结构图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本发明实施例提供了一种实时获取电子码的方法、开放平台及系统，用以解决现有技术中第三方应用服务器必须以手动方式预先向开放平台内导入一定批量的电子码所导致的操作繁琐等问题。

图3示出了本发明实施例提供的实时获取电子码的方法的流程图。如图3所示，该方法起始于步骤S101，在步骤S101中，开放平台接收到第三方应用服务器发送的前端支付请求后，通过第一接口向第三方应用服务器发送通知消息。其中，第一接口可以通过预设的第一回调函数、第一函数指针或第一URL地址来实现。

接下来，在步骤S102中，开放平台通过第二接口接收第三方应用服务器根据通知消息返回的订单核实请求。其中，第二接口同样可以通过预设的第二回调函数、第二函数指针或第二URL地址来实现。

然后，在步骤S103中，开放平台确定上述的订单核实请求是否合法，并在确定其合法时向第三方应用服务器返回验证成功消息。

最后，在步骤S104中，开放平台接收第三方应用服务器收到验证成功消息后返回的与订单核实请求对应的电子码，并将该电子码提供给预设的用户终端。

可选地，为了提高数据传输的安全性，上述步骤S101中发送的通知消息中进一步包含前端支付请求的相关信息，且这些相关信息通过预设的数字签名算法进行签名。相应地，第三方应用服务器收到该通知消息后，先通过预设的签名验证算法对该通知消息进行验证，再根据验证通过后得到的相关信息返回订单核实请求。其中，第三方应用服务器根据验证通过后得到的相关信息返回订单核实请求的步骤进一步包括：首先获取相关信息中包含的待验证参数，然后通过预设的数字签名算法对待验证参数进行签名，最后将签名后的待验证参数封装在订单核实请求中即可。相应地，在步骤S103中，开放平台通过下述方式验证订单核实请求是否合法：首先，开放平台通过预设的签名验证算法对订单核实请求进行验证，得到其中的待验证参数；然后，如果得到的待验证参数合法，则可以确定该订单核实请求合法。

通过上面的方式就可以实现开放平台与第三方应用服务器之间的双向验证，从而既可以防止有人冒充开放平台来欺骗第三方应用服务器向其发送电子码，也可以防止有人冒充第三方应用服务器向开放平台传输恶意数据。另外，为了进一步确保电子码在向开放平台发送的过程中不被篡改或截获，还可以由第三方应用服务器进一步对电子码进行加密。为此，本实施例中的方法还可以包括如下细节：当开放平台与第三方应用服务器之间通过第一类数据传输协议（例如安全性较高的HTTPS协议等）进行通信时，第三方应用服务器返回的电子码是没有加密的电子码，则开放平台直接将电子码提供给预设的用户终端即可，这样可以在网络安全性高的情况下简化传输环节的操作；当开放平台与第三方应用服务器之间通过第二类数据传输协议（例如安全性较低的HTTP协议等）进行通信时，第三方应用服务器返回的电子码是经过加密的电子码，则开放平台对电子码进行解密之后再将电子码提供给预设的用户终端，这样可以在网络安全性低的情况下提高传输安全性，并防止数据在网络应用层以下的层级被盗取。

通过上述方式能够实现开放平台与第三方应用服务器之间的双向验证机制，能够提高开放平台与第三方应用服务器之间的数据传输的安全性。在安全性得到保障的前提下，第三方应用服务器可以在每次接收到用户发送的与电子码相关的前端支付请求之后，实时地向开放平台发送所需的电子码。由此解决了现有技术中，第三方应用服务器必须以手动方式预先向开放平台内导入一定批量的电子码所导致的操作繁琐等问题。

在本发明的另一实施例中，以用户阅读付费小说的应用场景为例，对本发明提供的实时获取电子码的方法进行详细介绍。其中，本实施例中的第三方应用服务器是向用户提供付费小说的服务器，该服务器提供的电子码用于激活小说的特定章节，以便使用户能够对这些章节进行阅读。图4示出了本实施例提供的实时获取电子码的方法流程图。如图4所示，该方法包括以下步骤：

步骤S201：用户终端向第三方应用服务器发送激活请求。

通常情况下，本步骤在用户希望阅读电子小说的付费章节时被触发。例如，当用户通过电脑等用户终端浏览完小说的概要性提示内容后，希望进一步阅读该小说的剩余章节时，需要用户先通过电子码对这些章节进行激活。为此，用户可以通过点击用户终端浏览器上显示的“立即激活”等字样的按钮来发送上述的激活请求。

通常情况下，该激活请求中会包含例如用户帐号、小说名称以及章节号等信息。为此，当用户点击“立即激活”的按钮之后，浏览器页面可以先跳转到购买激活码的相应页面，在该页面上显示有“快速购买”和“登录购买”两个选项，如果用户点击“快速购买”的选项，则需要用户填写订单信息，包括：应用名称（如电子小说）、产品单价（如阅读一节小说的阅读费用）、产品数量（如小说的章节数）、用户联系方式（如手机号码和/或电子邮箱等）等；如果用户点击“登录购买”的选项，则需要用户先输入用户帐号和密码等登录信息之后再填写相应的订单信息。由此可见，在上述过程中，浏览器可以获取到该激活请求的相关信息，并将这些相关信息写入该激活请求中。另外，在上述过程中，还可以进一步包括用户通过支付宝等支付方式为电子码支付费用的环节，该环节可通过现有的各种支付方式实现。

步骤S202：第三方应用服务器收到用户终端发来的激活请求后，向开放平台发送前端支付请求。

第三方应用服务器首先解析该激活请求，获取到激活请求中包含的用户帐号、小说名称以及章节号等信息；然后，根据这些信息构造前端支付请求，并将该前端支付请求发送给开放平台。

步骤S203：开放平台接收到第三方应用服务器发送的前端支付请求后，通过第一接口向第三方应用服务器发送通知消息。

具体地，开放平台对前端支付请求进行解析，得到其中包含的用户帐号、小说名称以及章节号等信息，然后，根据这些信息构造通知消息，并通过第一接口将通知消息发送给第三方应用服务器。其中，第一接口可以通过预设的回调函数、函数指针或URL地址等多种方式来实现。例如，该第一接口可以是开放平台预先设置好的Open API，第三方应用服务器在最初接入开放平台时，通过加载包含第一接口在内的Open API来实现与开放平台的对接。因此，在本步骤中，开放平台直接调用该第一接口就可以向第三方应用服务器发送通知消息。

在通知消息中需要包含一些需要第三方应用服务器确认的参数信息。表1示出了通知消息中所包含的参数信息：

表1

回调参数	必选	参数说明
			app_key	true	应用App key（加入签名）
order_id	true	开放平台订单流水id（加入签名）
			order_amount	true	产品单价（单位为分）（加入签名）
order_count	true	购买数量（加入签名）
			product_id	true	充值产品id（加入签名）
sign_type	true	签名算法（不加入签名）
			sign_return	true	应用回传给订单核实接口的参数（不加入签名）
sign	true	提取的签名（签名方法如3.1）

上述各个参数的属性均为true，也就是说，在本实施例中，上述各个参数都是必选参数。其中，参数app_key表示应用的名称或键值，用于唯一地标识一个应用，在本实施例中，该应用即为电子小说阅读器之类的应用，该参数的具体取值是根据发送前端支付请求的第三方应用服务器的类型确定的。参数order_id表示开放平台的订单流水号，用于唯一地标识开放平台目前正在处理的订单，该参数的具体取值是根据开放平台当前处理的订单数量自动确定的。参数order_amount表示产品的单价，在本实施例中，即为对应小说的阅读费用，该参数的具体取值可以是开放平台与第三方应用服务器之间预先约定好的，也可以是开放平台从前端支付请求中获取的。参数order_count表示购买数量，在本实施例中，该参数的具体取值可以根据前端支付请求中包含的章节号的数量确定。参数product_id表示待充值的产品的标号，用于唯一地标识待充值的产品，在本实施例中，该参数的具体取值可以根据前端支付请求中包含的小说名称确定。参数sign_type表示签名算法的类型，例如，可以是3DES算法或者AES算法等各类签名算法，通过sign_type所表示的签名算法对上述的各个参数进行签名，以便实现安全性验证。参数sign_return表示第三方应用服务器在构造订单核实请求时所需的相关信息，该参数可以不进行签名处理。参数sign表示第三方应用服务器从通知消息中提取出的正确签名。

步骤S204：开放平台通过第二接口接收第三方应用服务器根据通知消息返回的订单核实请求。

第三方应用服务器收到上述的通知消息后，先要解析该通知消息，并获取其中包含的参数sign_type，以便确定该通知消息中的各个参数所采用的签名算法，然后根据该签名算法相应的签名验证算法对该通知消息中加入了签名的参数（例如参数app_key、order_id、order_amount、order_count以及product_id等）进行验证，得到这些参数的签名。然后，将得到的上述参数的签名与通知消息中的参数sign所标识的签名进行比较，如果相同，则确认通知消息中的各个参数是真实合法的，第三方应用服务器则会基于通知消息中的各个参数构造订单核实请求。

具体构造订单核实请求时，可以通过多种方式来构造，例如，可以将上述参数中的sign_return参数所包含的内容通过sign_type参数所标明的签名算法进行签名，并将签名后得到的数据封装为订单核实请求。该订单核实请求通过第二接口发送给开放平台。其中，第二接口同样可以通过预设的回调函数、函数指针或URL地址等多种方式来实现。而且，第二接口与上述的第一接口既可以是不同的接口，也可以是相同的接口。

步骤S205：开放平台确定上述的订单核实请求是否合法，并在其合法时，向第三方应用服务器返回验证成功消息。

具体地，开放平台根据sign_type参数所对应的签名验证算法对订单核实请求中的参数进行验证，获取其中的签名，根据签名来判断订单核实请求是否合法。另外，开放平台还可以通过判断订单核实请求中所包含的参数与之前发送的通知消息中的sign_return参数是否一致来判断订单核实请求的合法性。

可选地，在本发明其他的实施例中，开放平台还可以基于其他信息来确定订单核实请求的合法性。例如，第三方应用服务器可以在订单核实请求中包含产品单价信息（即小说章节的阅读费用），开放平台判断该产品单价信息是否超出预设的阈值，如果超出，则确认该订单核实请求非法。例如，假设实际情况中，一篇小说的阅读费用不会超过100元，因此，如果订单核实请求中包含的产品单价信息明显超出正常值，则可以确定该订单核实请求非法。总之，开放平台可以结合实际情况确定订单核实请求的合法性，本发明对具体的确定方式不做限定。

步骤S206：开放平台接收第三方应用服务器收到验证成功消息后返回的与订单核实请求对应的电子码，并将该电子码提供给预设的用户终端。

其中，与订单核实请求对应的电子码是指用于激活该小说的相应章节的电子码。开放平台在将电子码提供给预设的用户终端时，可以根据前端支付请求中所包含的用户帐号来确定接收电子码的用户终端地址。该用户终端地址既可以是步骤S201中发送激活请求的用户终端的地址，也可以是其他用户终端的地址。例如，假设在步骤S201中，用户通过自家的计算机终端向第三方应用服务器发送了上述的激活请求，经过上述各个步骤的处理之后，在步骤S206中，开放平台首先获取到第三方应用服务器发来的前端支付请求中所包含的用户帐号信息，然后，根据该用户帐号在注册时提供的相关信息，例如手机号码或电子邮箱地址等，向对应号码的手机终端或对应地址的电子邮箱发送电子码，然后，用户通过手机终端或电子邮箱即可获得该电子码，进而利用该电子码激活付费小说的指定章节。

由此可见，通过上述方式，开放平台可以在每次接收到第三方应用服务器发送的前端支付请求之后，通过第一接口和第二接口完成与第三方应用服务器之间的双向验证，并在验证通过后实时接收第三方应用服务器提供的电子码。这样既可以防止有人冒充开放平台来欺骗第三方应用服务器向其发送电子码，也可以防止有人冒充第三方应用服务器向开放平台传输恶意数据。因此，使开放平台与第三方应用服务器之间可以安全地实时传输数据。由此避免了现有技术中由于预先向开放平台手动导入一定批量的电子码所导致的操作繁琐问题，并且避免了开放平台预付电子码费用所导致的预付成本的损失风险。

另外，为了进一步确保电子码在向开放平台发送的过程中不被篡改或截获，在上述的步骤S206中，还可以由第三方应用服务器进一步对电子码进行加密，并将加密后的电子码提供给开放平台。具体加密时，可以选用3DES加密算法或AES加密算法，此时，开放平台接收到的电子码的格式如表2所示。

表2

通过表2可以看出，加密后的电子码中包含如下参数：操作参数config；用于表示加密方式的参数encryption，当该参数值为空或NONE时表示不加密，当该参数值为TRIPLEDES时表示3DES加密方式；用于表示初始化向量的参数iv，该参数的默认值为加密字符串的后8位；用于表示签名方法的参数signature，该参数用于验证消息的完整性，其默认值为MD5；用于表示完整性验证串的参数mac；以及用于表示数据内容（即电子码的内容）的参数ret，该参数可以通过加密或不加密两种方式传输。

下面给出上述参数的代码表示方法：

在上述代码段中，加密方式为TRIPLEDES，初始化向量为随机数，且包含用于表示“完整性验证串”的参数completion，以及用于表示签名方法的参数signature。

根据上述代码段对接收到的电子码进行解析，得到其中包含的数据内容“ret”，对“ret”进行解密后，视实际情况可能得到如下两种结果中的任意一种：

在第一种结果中，得到的电子码为单个电子码，也就是说，第三方应用服务器一次只返回了一个电子码，此时，“ret”的解密结果如下：

在第二种结果中，得到的电子码为多个电子码，也就是说，第三方应用服务器一次返回了多个电子码，此时，“ret”的解密结果如下：

通过上述加密传输方式能够确保电子码在向开放平台发送的过程中不被篡改或截获，从而进一步提高安全性。

图5示出了本发明实施例提供的实时获取电子码的开放平台的结构图。如图5所示，该开放平台50包括第一通信模块51、第一接口模块52、第二接口模块53、验证模块54以及第二通信模块55。

第一通信模块51接收第三方应用服务器发送的前端支付请求。

第一接口模块52向第三方应用服务器发送通知消息。其中，第一接口模块52通过预设的第一回调函数、第一函数指针或第一URL地址发送该通知消息。

第二接口模块53接收第三方应用服务器根据通知消息返回的订单核实请求。其中，第二接口模块53通过预设的第二回调函数、第二函数指针或第二URL地址接收该订单核实请求。

验证模块54确定订单核实请求是否合法。第二通信模块55在订单核实请求合法时向第三方应用服务器返回验证成功消息，并接收第三方应用服务器收到验证成功消息后返回的与订单核实请求对应的电子码，将电子码提供给预设的用户终端。其中，当第三方应用服务器返回的电子码是经过加密的电子码时，第二通信模块55进一步对该电子码进行解密。

可选地，第一接口模块52发送的通知消息中包含前端支付请求的相关信息，且这些相关信息通过预设的数字签名算法进行签名；则第三方应用服务器收到该通知消息后，先通过预设的签名验证算法对该通知消息进行验证，再根据验证通过后得到的相关信息返回订单核实请求。其中，订单核实请求中包含第三方应用服务器从相关信息中获取的待验证参数，且这些待验证参数通过预设的数字签名算法进行签名；则验证模块适于通过预设的签名验证算法对该订单核实请求进行验证，得到其中的待验证参数，如果待验证参数合法，则确定该订单核实请求合法。

图6示出了本发明实施例提供的实时获取电子码的系统的结构图。如图6所示，该系统包括：上述的开放平台50以及第三方应用服务器60，所述系统还包括一个或多个用户终端（图上未示出），所述第三方应用服务器的数量还可以为多个。关于开放平台的具体结构可参照上述实施例的描述，此处不再赘述。

在本发明提供的实时获取电子码的方法及开放平台中，为第三方应用服务器提供了两个开放的接口（第一接口和第二接口），通过这两个接口，能够实现开放平台与第三方应用服务器之间的实时数据交互，从而使开放平台能够在每次接收到第三方应用服务器发送的前端支付请求后，向第三方应用服务器发送通知消息，接收及验证第三方应用服务器返回的订单核实请求，并在验证通过后向第三方应用服务器返回验证成功消息，最后接收第三方应用服务器据此返回的电子码。通过上述方式能够实现开放平台与第三方应用服务器之间的双向验证机制，能够提高开放平台与第三方应用服务器之间的数据传输的安全性。在安全性得到保障的前提下，第三方应用服务器可以在每次接收到用户发送的与电子码相关的前端支付请求之后，实时地向开放平台发送所需的电子码。由此解决了现有技术中，第三方应用服务器必须以手动方式预先向开放平台内导入一定批量的电子码所导致的操作繁琐等问题。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书（包括伴随的权利要求、摘要和附图）中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书（包括伴随的权利要求、摘要和附图）中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器（DSP）来实现根据本发明实施例的装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序（例如，计算机程序和计算机程序产品）。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (10)

1.一种实时获取电子码的方法，包括：

开放平台接收到第三方应用服务器发送的前端支付请求后，通过第一接口向所述第三方应用服务器发送通知消息；

通过第二接口接收所述第三方应用服务器根据所述通知消息返回的订单核实请求；

当确定所述订单核实请求合法时，向所述第三方应用服务器返回验证成功消息；

接收所述第三方应用服务器收到所述验证成功消息后返回的与所述订单核实请求对应的电子码，并将所述电子码提供给预设的用户终端。

2.如权利要求1所述的方法，其中，所述第一接口通过预设的第一回调函数、第一函数指针或第一URL地址实现，所述第二接口通过预设的第二回调函数、第二函数指针或第二URL地址实现。

3.如权利要求1所述的方法，其中，所述通知消息中包含所述前端支付请求的相关信息，且所述相关信息通过预设的数字签名算法进行签名；

所述第三方应用服务器收到所述通知消息后，先通过预设的签名验证算法对所述通知消息进行验证，再根据验证通过后得到的所述相关信息返回所述订单核实请求。

4.如权利要求3所述的方法，其中，所述第三方应用服务器根据验证通过后得到的所述相关信息返回所述订单核实请求的步骤包括：获取所述相关信息中包含的待验证参数，通过所述预设的数字签名算法对所述待验证参数进行签名，将签名后的待验证参数封装在所述订单核实请求中；

所述开放平台确定所述订单核实请求合法的步骤包括：通过预设的签名验证算法对所述订单核实请求进行验证，得到其中的待验证参数，如果所述待验证参数合法，则确定所述订单核实请求合法。

5.如权利要求1-4任一所述的方法，其中，当所述开放平台与所述第三方应用服务器之间通过第一类数据传输协议进行通信时，所述第三方应用服务器返回的电子码是没有加密的电子码，则所述开放平台直接将所述电子码提供给预设的用户终端；其中，所述第一类数据传输协议包括HTTPS协议；

当所述开放平台与所述第三方应用服务器之间通过第二类数据传输协议进行通信时，所述第三方应用服务器返回的电子码是经过加密的电子码，则所述开放平台对所述电子码进行解密之后再将所述电子码提供给预设的用户终端；其中，所述第二类数据传输协议包括HTTP协议。

6.一种实时获取电子码的开放平台，包括：

第一通信模块，适于接收第三方应用服务器发送的前端支付请求；

第一接口模块，适于向所述第三方应用服务器发送通知消息；

第二接口模块，适于接收所述第三方应用服务器根据所述通知消息返回的订单核实请求；

验证模块，适于确定所述订单核实请求是否合法；

第二通信模块，适于在所述订单核实请求合法时向所述第三方应用服务器返回验证成功消息，并接收所述第三方应用服务器收到所述验证成功消息后返回的与所述订单核实请求对应的电子码，将所述电子码提供给预设的用户终端。

7.如权利要求6所述的开放平台，其中，所述第一接口模块通过预设的第一回调函数、第一函数指针或第一URL地址发送所述通知消息；

所述第二接口模块通过预设的第二回调函数、第二函数指针或第二URL地址接收所述订单核实请求。

8.如权利要求6所述的开放平台，其中，所述第一接口模块发送的通知消息中包含所述前端支付请求的相关信息，且所述相关信息通过预设的数字签名算法进行签名；

所述第三方应用服务器收到所述通知消息后，先通过预设的签名验证算法对所述通知消息进行验证，再根据验证通过后得到的所述相关信息返回所述订单核实请求。

9.如权利要求8所述的开放平台，其中，所述订单核实请求中包含所述第三方应用服务器从所述相关信息中获取的待验证参数，且所述待验证参数通过预设的数字签名算法进行签名；

所述验证模块适于通过预设的签名验证算法对所述订单核实请求进行验证，得到其中的待验证参数，如果所述待验证参数合法，则确定所述订单核实请求合法。

10.一种实时获取电子码的系统，包括：如权利要求6-9任一所述的开放平台，一个或多个用户终端以及一个或多个第三方应用服务器。

Images