CN103581106A - 交互式处理方法和交互式处理系统 - Google Patents

Abstract

一种交互式处理方法及系统，该方法包括步骤：请求端向处理端发送处理请求信息，接收所述处理端根据所述处理请求信息返回的通知ID；请求端根据所述通知ID向所述处理端发送通知查询请求信息，接收所述处理端根据所述通知查询请求信息返回的与所述通知ID对应的处理结果。根据本发明方案，在请求端向处理端发送处理请求信息、处理端根据该处理请求信息进行处理后，向请求端返回的是基于该处理请求信息的通知ID，请求端再根据该通知ID从处理端获得与该通知ID对应的处理结果，恶意获得请求端的密钥key的人也无法冒充为处理端，无法接收到请求端的通知查询请求信息，因而也无法伪造出假的与通知ID对应的处理结果，极大地增强了交互式处理的安全性。

Description

交互式处理方法和交互式处理系统

技术领域

本发明涉及交互安全领域，特别涉及一种交互式处理方法以及一种交互式处理系统。

背景技术

随着科技进步的日益发展，不同的计算机、不同的应用系统之间的交互应用也越来越普遍。以网络购物为例，基于无需出门即可浏览并购买玲琅满目的众多实体及虚拟商品等特点，网络购物的应用日益普遍。在网络购物的应用中，其中一个关键环节涉及到订单支付的问题，即在线支付。在目前的在线支付的技术中，都是由商户网站向支付平台网站发起支付请求，支付平台网站根据该支付请求提供相关页面供用户进行在线支付，在用户支付完成后，由支付平台将订单的相关信息以及支付结果告知商户网站，商户网站接收后，验证支付平台返回的信息的真实性，在验证通过之后，完成后续的更新订单状态、发货等动作。

在目前的这种在线支付方式中，商户网站与支付平台网站之间进行交互时，一般是基于RSA(一种非对称密码算法)以及MD5(Message Digest AlgorithmMD5，消息摘要算法第五版，用于确保信息传输完整一致)来进行，即在需发送的信息后附上MD5后再采用商户的密钥key进行加密，然后将加密后的信息发送出去，或者是对需要发送的信息用商户密钥key加密后再附上MD5发送出去，其中，MD5的计算方式一般是将商户的密钥key连接到参数串后算出MD5，这是一种静态方式，也就是说，商户的密钥key的应用决定了商户网站与支付平台网站交互的安全性，一旦商户的密钥key被泄露，获得商户的密钥key的恶意人员就有可能假装支付平台网站造出假的通知信息，严重影响在线支付的安全性。类似地，针对其他类型的需要在系统或者网站之间进行的交互式操作而言，也有可能存在密钥泄露而导致影响交互安全性的风险。

发明内容

基于此，针对上述交互式操作时的安全性问题，本发明的目的在于提供一种交互式处理方法以及一种交互式处理系统，其可以提供交互式处理时的安全性。

为达到上述目的，本发明采用以下技术方案：

一种交互式处理方法，包括步骤：

请求端向处理端发送处理请求信息，接收所述处理端根据所述处理请求信息返回的通知ID；

请求端根据所述通知ID向所述处理端发送通知查询请求信息，接收所述处理端根据所述通知查询请求信息返回的与所述通知ID对应的处理结果。

一种交互式处理方法，包括步骤：

处理端接收请求端发送的处理请求信息，根据所述处理请求信息进行处理，根据处理结果生成通知ID，并将该通知ID向所述请求端发送；

处理端接收所述请求端根据所述通知ID发送的通知查询请求信息，根据所述通知查询请求信息将与所述通知ID对应的处理结果发送给所述请求端。

一种交互式处理系统，包括请求端：

所述请求端用于向处理端发送处理请求信息，接收所述处理端根据所述处理请求信息返回的通知ID，根据所述通知ID向所述处理端发送通知查询请求信息，并接收所述处理端根据所述通知查询请求信息返回的与所述通知ID对应的处理结果。

一种交互式处理系统，包括处理端：

所述处理端，用于接收请求端发送的处理请求信息，根据所述处理请求信息进行处理，根据处理结果生成通知ID，将该通知ID向所述请求端发送，并接收请求端根据所述通知ID发送的通知查询请求信息，根据所述通知查询请求信息将与所述通知ID对应的处理结果发送给所述请求端。

根据本发明方案，其在请求端向处理端发送处理请求信息、处理端根据该处理请求信息进行处理后，向请求端返回的是基于该处理请求信息的通知ID，请求端再根据该通知ID从处理端获得与该通知ID对应的处理结果。基于这种方案，即便是请求端的密钥key被他人恶意获得，而一般请求端端保存有处理端的域名或者地址等信息，并基于保存的处理端的域名或者地址等信息向处理端发送信息，而他人很难对请求端保存的处理端的域名或者地址等信息进行修改，因此，恶意获得请求端的密钥key的人也无法冒充为处理端，无法接收到请求端的通知查询请求信息，因而也无法伪造出假的与通知ID对应的处理结果，从而极大地增强了交互式处理的安全性。

附图说明

图1是本发明的交互式处理方法实施例一的流程示意图；

图2是本发明的交互式处理方法实施例二的流程示意图；

图3是本发明的交互式处理方法实施例三的流程示意图；

图4是一个具体示例中请求端为商户网站、处理端为支付平台网站时的交互示意图；

图5是本发明的交互式处理方法实施例四的流程示意图；

图6是本发明的交互式处理系统实施例的结构示意图。

具体实施方式

以下结合其中的较佳实施例对本发明方案进行详细阐述。在下述说明中，首先针对本发明的交互式处理方法的各实施例进行说明，再针对本发明的交互式处理系统的各实施例进行说明。

图1中示出了本发明的交互式处理方法实施例一的流程示意图。在该实施例一中，是以请求端的处理过程为例进行说明。

如图1所示，本实施例一中的交互式处理方法包括步骤：

步骤S101：请求端向处理端发送处理请求信息；

步骤S102：请求端接收处理端根据上述处理请求信息返回的通知ID(Identity，通知的标识信息)；

步骤S 103：请求端根据上述通知ID向处理端发送通知查询请求信息；

步骤S104：请求端接收处理端根据上述通知查询请求信息返回的与上述通知ID对应的处理结果。

根据本实施例中的方案，其在请求端向处理端发送处理请求信息、处理端根据该处理请求信息进行处理后，向请求端返回的是基于该处理请求信息的通知ID，请求端再根据该通知ID从处理端获得与该通知ID对应的处理结果。基于这种方案，即便是请求端的密钥key被他人恶意获得，而一般请求端端保存有处理端的域名或者地址等信息，并基于保存的处理端的域名或者地址等信息向处理端发送信息，而他人很难对请求端保存的处理端的域名或者地址等信息进行修改，因此，恶意获得请求端的密钥key的人也无法冒充为处理端，无法接收到请求端的通知查询请求信息，因而也无法伪造出假的与通知ID对应的处理结果，从而极大地增强了交互式处理的安全性。

其中，处理端在根据上述处理请求信息向请求端返回通知ID时，可同时返回根据该处理请求信息进行处理的处理结果，即，请求端还接收处理端根据上述处理请求信息返回的处理结果。

此时，请求端在接收到通知ID的同时，还同时接收到了针对上述处理请求信息的处理结果。那么，请求端可以根据需要来确定是否需要向处理端发送通知查询请求信息、重新获取处理结果来进行进一步的验证或者确认，具体可以与请求端的配置、或者是请求端的操作用户的需求有关，在需要发送通知查询请求信息时，可通过发出通知查询指令，请求端接收到通知查询指令时，再向处理端发送上述通知查询请求信息。确定是否需要发送通知查询请求的方式，可以根据实际需要、采用各种可能的方式进行设定，也可以是设定为针对收到的任何一个通知ID都需要发送通知查询请求信息。

在其中一个具体示例中，上述请求端可以是商户网站，相应地，上述处理端可以是支付平台网站或者是银行网站。对于商户网站来说，其需要支付平台网站或者银行网站进行处理的是对订单的付费动作，因此，在商户网站接收到支付平台网站或者银行网站返回的与上述通知ID对应的处理结果后，还可以根据该处理结果更新订单状态。

图2中示出了本发明的交互式处理方法实施例二的流程示意图。在本实施例二中，是以处理端的处理过程为例进行说明。

如图2所示，本实施例二中的交互式处理方法包括步骤：

步骤S201：处理端接收请求端发送的处理请求信息，根据该处理请求信息进行处理，获得处理结果；

步骤S202：处理端根据上述处理结果生成通知ID，并将该通知ID向上述请求端发送；

步骤S203：处理端接收请求端根据上述通知ID发送的通知查询请求信息，根据上述通知查询请求信息将与上述通知ID对应的处理结果发送给请求端。

根据本实施例中的方案，处理端在接收到处理请求信息、根据该处理请求信息进行处理获得处理结果后，向请求端返回的是基于该处理请求信息的通知ID，在接收到请求端根据该通知ID发送的通知查询请求信息后，再将与该通知ID对应的处理结果发送给请求端。基于这种方案，即便是请求端的密钥key被他人恶意获得，而一般请求端端保存有处理端的域名或者地址等信息，并基于保存的处理端的域名或者地址等信息向处理端发送信息，而他人很难对请求端保存的处理端的域名或者地址等信息进行修改，因此，恶意获得请求端的密钥key的人也无法冒充为处理端，无法接收到请求端的通知查询请求信息，因而也无法伪造出假的与通知ID对应的处理结果，从而极大地增强了交互式处理的安全性。

在其中一种处理方式中，处理端在根据上述处理请求信息向请求端返回通知ID时，可同时返回根据该处理请求信息进行处理的处理结果，由请求端决定是否需要重新获取与通知ID对应的处理结果来验证所获得的处理结果的安全性。

在其中一个具体示例中，上述请求端可以是商户网站，相应地，上述处理端可以是支付平台网站或者是银行网站。对于商户网站来说，其需要支付平台网站或者银行网站进行处理的是对订单的付费动作，因此，在商户网站接收到支付平台网站或者银行网站返回的与上述通知ID对应的处理结果后，还可以根据该处理结果更新订单状态。

图3中示出了本发明的交互式处理方法实施例三的流程示意图。在本实施例三中，是以请求端与处理端之间的交互过程、处理端在接收到处理请求信息后总是只返回通知ID为例进行说明。

如图3所述，本实施例三中的交互式处理方法包括步骤：

步骤S301：请求端向处理端发送处理请求信息；

步骤S302：处理端接收请求端发送的处理请求信息，根据该处理请求信息进行处理获得处理结果；

步骤S303：处理端根据处理结果生成通知ID，并将该通知ID向上述请求端发送；

步骤S304：请求端接收处理端根据上述处理请求信息返回的通知ID，根据该通知ID向处理端发送通知查询请求信息；

步骤S305：处理端接收请求端根据上述通知ID发送的通知查询请求信息，根据上述通知查询请求信息将与上述通知ID对应的处理结果发送给请求端；

步骤S306：请求端接收处理端根据上述通知查询请求信息返回的与上述通知ID对应的处理结果。

以上述请求端为商户网站、处理端为支付平台网站为例，图4中示出了一个具体示例中的支付流程示意图。

基于本实施例三中的交互式处理方法，图4所示的支付过程可以是如下所述：

商户网站在用户完成了相关订单信息、并确定对订单进行支付时，向相应的支付平台网站发起支付请求，即向支付平台网站发送上述处理请求信息；

支付平台网站接收到商户网站发送过来的支付请求后，完成对订单费用的支付，具体的对订单费用进行支付的过程可以采用任何可能的方式进行，在支付完成后，支付平台网站生成该订单的通知ID，用以标识该订单以及与该订单相关的支付情况，生成通知ID后，支付平台网站将该通知ID发送给商户网站；

商户网站接收到支付平台网站返回的通知ID后，根据该通知ID向支付平台网站发送通知查询请求信息，该通知查询请求信息中包括有上述通知ID；

支付平台网站接收到商户网站发送的通知查询请求信息，根据通知查询请求信息中的通知ID查询对应的处理结果，这里的处理结果可以包括订单信息以及针对订单的处理结果信息，当然，也可以根据实际需要对该处理结果进行配置，例如处理结果中也可以只包括订单号以及支付是否成功的信息等等；

商户网站接收到商户网站返回的处理结果后，根据该处理结果更新订单的状态，并可以据此完成后续的状态，例如虚拟商品的发货、实体商品的发货提醒等等。

在上述针对本发明的交互式处理方法实施例三的说明中，是以处理端只向请求端发送通知ID、请求端总是要根据通知ID向处理端查询处理结果为例进行说明，在另外一种实现方式中，也可以是由处理端来确定是否需要生成通知ID以及将该通知ID发送给请求端。即在上述步骤S302与步骤S303之间还可以包括步骤：

S3023：处理端判断是否需要生成通知ID，若是，进入步骤S303。

也就是说，由处理端判断是否需要生成通知ID，在需要生成通知ID的情况下，进入后续的生成通知ID等过程，在不需要生成通知ID的情况下，可直接将处理结果发送给请求端。

其中，处理端判断是否需要生成通知ID的方式，可以采用各种可能的方式进行，例如处理请求信息的类型、请求端的类别与性能等等，甚至可以是对任何一个处理请求信息都设置为需要生成通知ID，具体的判断是否需要生成通知ID的方式在此不予赘述。

在此情况下，结合上述图4中的支付流程为例，具体的处理过程可以是如下所述：

商户网站在用户完成了相关订单信息、并确定对订单进行支付时，向相应的支付平台网站发起支付请求，即向支付平台网站发送上述处理请求信息；

支付平台网站接收到商户网站发送过来的支付请求后，完成对订单费用的支付，具体的对订单费用进行支付的过程可以采用任何可能的方式进行；

在支付完成后，支付平台网站判断是否需要生成该订单的通知ID，具体的判定条件可以根据需要进行设置，对于支付平台网站来说，可以根据商户网站的类型与规模、订单中商品的性质等因素来判定是否需要生成通知ID，例如，可在支付平台网站设置针对特定的商户网站的支付请求需要生成通知ID，或者是在商户网站的规模小于某个设定阈值时需要对该商户网站的支付请求生成通知ID，或者是在订单中的商品是虚拟商品时需要对该支付请求生成通知ID，或者是综合商户网站的类型与规模、订单中商品的性质以及其他相关因素来综合判定是否需要生成通知ID，当然，根据实际需要，也可以采用其他任何可能的方式来判定是否需要生成通知ID，具体的判定方式在此不予赘述；

在判定需要生成通知ID的情况下，支付平台网站生成该订单的通知ID，用以标识该订单以及与该订单相关的支付情况，生成通知ID后，支付平台网站将该通知ID发送给商户网站；

商户网站接收到支付平台网站返回的通知ID后，根据该通知ID向支付平台网站发送通知查询请求信息，该通知查询请求信息中包括有上述通知ID；

支付平台网站接收到商户网站发送的通知查询请求信息，根据通知查询请求信息中的通知ID查询对应的处理结果，这里的处理结果可以包括订单信息以及针对订单的处理结果信息，当然，也可以根据实际需要对该处理结果进行配置，例如处理结果中也可以只包括订单号以及支付是否成功的信息等等；

商户网站接收到商户网站返回的处理结果后，根据该处理结果更新订单的状态，并可以据此完成后续的状态，例如虚拟商品的发货、实体商品的发货提醒等等。

图5中示出了本发明的交互式处理方法实施例四的流程示意图。在本实施例四中，是以请求端与处理端之间的交互过程、处理端在接收到处理请求信息后，可以同时将通知ID与处理结果返回给请求端为例进行说明。

如图5所述，本实施例四中的交互式处理方法包括步骤：

步骤S501：请求端向处理端发送处理请求信息；

步骤S502：处理端接收请求端发送的处理请求信息，根据该处理请求信息进行处理；

步骤S503：处理端根据处理结果生成通知ID，并将该通知ID与处理结果向上述请求端发送；

步骤S504：请求端接收处理端根据上述处理请求信息返回的通知ID以及处理结果；

步骤S505：请求端接收到通知查询指令，根据该通知查询指令向处理端发送通知查询请求信息，该通知查询请求信息中包括上述通知ID；

步骤S506：处理端接收请求端根据上述通知ID发送的通知查询请求信息，根据上述通知查询请求信息将与上述通知ID对应的处理结果发送给请求端；

步骤S507：请求端接收处理端根据上述通知查询请求信息返回的与上述通知ID对应的处理结果。

基于本实施例中的方案，处理端可以同时将通知ID以及对应的处理结果发送给请求端，由请求端来确定是否需要依据通知ID再查询一次处理结果，以确保处理结果的安全性。

以上述请求端为商户网站、处理端为支付平台为例，基于本实施例四中的交互式处理方法，结合图4中的支付流程示意图，具体的支付过程可以是如下所述：

商户网站在用户完成了相关订单信息、并确定对订单进行支付时，向相应的支付平台网站发起支付请求，即向支付平台网站发送上述处理请求信息；

支付平台网站接收到商户网站发送过来的支付请求后，完成对订单费用的支付，具体的对订单费用进行支付的过程可以采用任何可能的方式进行，在支付完成后，支付平台网站生成该订单的通知ID，用以标识该订单以及与该订单相关的支付情况，生成通知ID后，支付平台网站将处理结果以及该通知ID发送给商户网站；

商户网站接收到支付平台网站返回的处理结果以及通知ID后，判定是否需要基于该通知ID向支付平台网站重新查询对应的处理结果，以对处理结果进行确认或者验证，具体的判定机制，可以根据应用需要进行设置，例如在是订单对应的商品是虚拟商品的情况下需要查询，或者是在订单对应的商品是实体商品的情况下需要查询，或者是订单的金额大于某个阈值时需要查询，或者是在任何条件下都需要进行查询等等，具体的设定条件在此不予赘述；

在需要向支付平台网站进行查询的情况下，商户网站根据该通知ID向支付平台网站发送通知查询请求信息，该通知查询请求信息中包括有上述通知ID；

支付平台网站接收到商户网站发送的通知查询请求信息，根据通知查询请求信息中的通知ID查询对应的处理结果，这里的处理结果可以包括订单信息以及针对订单的处理结果信息，当然，也可以根据实际需要对该处理结果进行配置，例如处理结果中也可以只包括订单号以及支付是否成功的信息等等；

商户网站接收到商户网站返回的处理结果后，根据该处理结果更新订单的状态，并可以据此完成后续的状态，例如虚拟商品的发货、实体商品的发货提醒等等。

在上述本发明的交互式处理方法实施例四的说明中，是以处理端向请求端发送处理结果与通知ID、由请求端确定是否需要根据通知ID向处理端查询处理结果为例进行说明，在另外一种实现方式中，也可以是由处理端来确定是否需要生成通知ID以及将该通知ID发送给请求端，并在判定需要生成通知ID时再生成对应的通知ID，并将该通知ID以及处理结果发送给请求端，即在上述步骤S502与步骤S503之间还可以包括步骤：

S5023：处理端判断是否需要生成通知ID，若是，进入步骤S503。

也就是说，由处理端判断是否需要生成通知ID，在需要生成通知ID的情况下，进入后续的生成通知ID等过程，在不需要生成通知ID的情况下，可直接将处理结果发送给请求端。

其中，处理端判断是否需要生成通知ID的方式，可以采用各种可能的方式进行，例如处理请求信息的类型、请求端的类别与性能等等，甚至可以是对任何一个处理请求信息都设置为需要生成通知ID，具体的判断是否需要生成通知ID的方式在此不予赘述。

本实施例四中的其他技术特征可与上述实施例三中的相同，在此不予赘述。

在上述针对本发明的交互式处理方法的说明中，为便于清楚说明，在具体示例的说明中，是以请求端为商户网站、处理端为支付平台为例进行说明。可以预见的是，上述本发明方法可以应用于任何一种需要发送至另一端的处理端进行协助处理，需要通过系统互行进行处理的领域，因此，上述针对商户网站、支付平台网站的举例说明并不用以对本发明方案构成限制，基于上述本发明方案的思想，上述本发明方案可以应用于任何一种需要通过系统互行进行处理的领域。

根据上述本发明的交互式处理方法，本发明还提供一种交互式处理系统。

本发明的交互式处理系统，可以只包括请求端，也可以只包括处理端，也可以同时包括请求端与处理端。

图6中是出了本发明的交互式处理系统实施例的结构示意图。为便于说明，图6中是以同时包括请求端与处理端为例进行说明。

如图6所示，该示例中的交互式处理系统包括请求端601与处理端602，其中：

请求端601，用于向处理端602发送处理请求信息，接收处理端602根据该述处理请求信息返回的通知ID，根据该通知ID向处理端602发送通知查询请求信息，并接收处理端602根据该通知查询请求信息返回的与上述通知ID对应的处理结果；

处理端602，用于接收请求端601发送的处理请求信息，根据该处理请求信息进行处理，根据处理结果生成通知ID，将该通知ID向请求端601发送，并接收请求端601根据上述通知ID发送的通知查询请求信息，根据该通知查询请求信息将与上述通知ID对应的处理结果发送给请求端601。

在其中一个具体示例中，请求端601具体可以包括：

请求信息生成单元6011，用于生成上述处理请求信息、以及上述通知查询请求信息；

请求端信息收发模块6012，用于将上述处理请求信息、上述通知查询请求信息向处理端602发送，接收处理端602返回的上述通知ID以及与上述通知ID对应的处理结果。

上述处理端602具体可以包括：

处理端信息收发模块6021，用于接收请求端601发送的上述处理请求信息、以及上述通知查询请求信息，并将处理模块6022获得的通知ID、查询模块6023查询得到的处理结果向请求端601发送；

处理模块6022，用于根据上述处理请求信息进行处理，获得上述处理结果，并根据该处理结果生成上述通知ID；

查询模块6023，用于根据上述通知查询请求信息获得与上述通知ID对应的处理结果。

在另外一个具体示例中，上述处理端信息收发模块6021，还用于在将上述通知ID向请求端601发送的同时，将处理模块6022获得的上述处理结果向请求端601发送。

相应地，上述请求端信息收发模块6012，还用于接收处理端602根据上述处理请求信息返回的处理结果，即处理端信息收发模块6021发送的处理模块6022获得的处理结果。

在另一个具体示例中，请求端601还可以包括有指令接收单元6013，用于接收通知查询指令；

相应地，上述请求信息生成单元6011，用于根据指令接收单元6013接收的通知查询指令生成上述通知查询请求信息。

在另一个具体示例中，上述处理端还可以包括分析判断单元6024，用于判断是否需要生成通知ID。

此时，上述处理模块6022，是在分析判断单元6024判定需要生成通知ID时，根据上述处理结果生成上述通知ID。

在其中一个具体应用中，上述请求端601可以是商户网站，相应地，上述处理端602可以是支付平台网站或者是银行网站。

对于商户网站来说，其需要支付平台网站或者银行网站进行处理的是对订单的付费动作，因此，在商户网站接收到支付平台网站或者银行网站返回的与上述通知ID对应的处理结果后，还可以根据该处理结果更新订单状态。在此情况下，上述请求端601还可以包括有更新模块6014，用于根据支付平台网站返回的与所述通知ID对应的处理结果更新订单状态。

本发明的交互式处理系统的其他技术特征可以与上述本发明的交互式处理方法中的相同，在此不予赘述。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (18)

1.一种交互式处理方法，其特征在于，包括步骤：

请求端向处理端发送处理请求信息，接收所述处理端根据所述处理请求信息返回的通知ID；

请求端根据所述通知ID向所述处理端发送通知查询请求信息，接收所述处理端根据所述通知查询请求信息返回的与所述通知ID对应的处理结果。

2.根据权利要求1所述的交互式处理方法，其特征在于，还包括步骤：请求端接收所述处理端根据所述处理请求信息返回的处理结果。

3.根据权利要求2所述的交互式处理方法，其特征在于，请求端在接收到通知查询指令时，向所述处理端发送所述通知查询请求信息。

4.根据权利要求1至3任意一项所述的交互式处理方法，其特征在于，所述请求端为商户网站，所述处理端为支付平台网站或者银行网站。

5.根据权利要求4所述的交互式处理方法，其特征在于，还包括步骤：所述商户网站根据所述支付平台网站返回的与所述通知ID对应的处理结果更新订单状态。

6.一种交互式处理方法，其特征在于，包括步骤：

处理端接收请求端发送的处理请求信息，根据所述处理请求信息进行处理，根据处理结果生成通知ID，并将该通知ID向所述请求端发送；

处理端接收所述请求端根据所述通知ID发送的通知查询请求信息，根据所述通知查询请求信息将与所述通知ID对应的处理结果发送给所述请求端。

7.根据权利要求6所述的交互式处理方法，其特征在于，所述处理端在将所述通知ID向所述请求端发送时，还将所述处理结果向所述请求端发送。

8.根据权利要求6或7所述的交互式处理方法，其特征在于：

还包括步骤：处理端判断是否需要生成通知ID，并在判定需要生成通知ID时，根据所述处理结果生成所述通知ID；

和/或

所述请求端为商户网站，所述处理端为支付平台网站或者银行网站。

9.一种交互式处理系统，其特征在于，包括请求端，

所述请求端用于向处理端发送处理请求信息，接收所述处理端根据所述处理请求信息返回的通知ID，根据所述通知ID向所述处理端发送通知查询请求信息，并接收所述处理端根据所述通知查询请求信息返回的与所述通知ID对应的处理结果。

10.根据权利要求9所述的交互式处理系统，其特征在于，所述请求端包括：

请求信息生成单元，用于生成所述处理请求信息、所述通知查询请求信息；

请求端信息收发模块，用于将所述处理请求信息、所述通知查询请求信息向所述处理端发送，接收所述通知ID以及与所述通知ID对应的处理结果。

11.根据权利要求10所述的交互式处理系统，其特征在于，所述请求端信息收发模块，还用于接收所述处理端根据所述处理请求信息返回的处理结果。

12.根据权利要求11所述的交互式处理系统，其特征在于：

所述请求端还包括指令接收单元，用于接收通知查询指令；

所述请求信息生成单元，用于根据所述通知查询指令生成所述通知查询请求信息。

13.根据权利要求9至12任意一项所述的交互式处理系统，其特征在于，所述请求端为商户网站，所述处理端为支付平台网站。

14.根据权利要求13所述的交互式处理系统，其特征在于，所述请求端还包括：更新模块，用于根据所述支付平台网站返回的与所述通知ID对应的处理结果更新订单状态。

15.一种交互式处理系统，其特征在于，包括处理端：

所述处理端，用于接收请求端发送的处理请求信息，根据所述处理请求信息进行处理，根据处理结果生成通知ID，将该通知ID向所述请求端发送，并接收请求端根据所述通知ID发送的通知查询请求信息，根据所述通知查询请求信息将与所述通知ID对应的处理结果发送给所述请求端。

16.根据权利要求15所述的交互式处理系统，其特征在于，所述处理端包括：

处理端信息收发模块，用于接收请求端发送的所述处理请求信息、所述通知查询请求信息，并将处理模块获得的通知ID、查询模块查询得到的处理结果向所述请求端发送；

处理模块，用于根据所述处理请求信息进行处理，获得所述处理结果，根据所述处理结果生成所述通知ID；

查询模块，用于根据所述通知查询请求信息获得与所述通知ID对应的处理结果。

17.根据权利要求16所述的交互式处理系统，其特征在于，所述处理端信息收发模块，还用于将所述处理模块获得的所述处理结果向所述请求端发送。

18.根据权利要求15至17任意一项所述的交互式处理系统，其特征在于：

所述处理端还包括分析判断单元，用于判断是否需要生成通知ID；

所述处理模块，用于在所述分析判断单元判定需要生成通知ID时，根据所述处理结果生成所述通知ID；

和/或

所述请求端为商户网站，所述处理端为支付平台网站或者银行网站。

Images