CN111105224A - 支付反馈信息的处理方法、装置、电子设备和存储介质 - Google Patents

Abstract

本发明公开一种支付反馈信息的处理方法、装置、电子设备和存储介质。该处理方法包括接收支付反馈信息，所述支付反馈信息至少包括订单号、支付金额、支付状态和签名信息；对支付反馈信息进行签名验证；当通过签名验证时，根据支付状态信息判断是否支付成功；当支付成功时，查询订单号所对应的订单的处理状态并验明该订单及该支付反馈信息的真伪；当该订单为未被锁定的待处理订单且该订单和该支付反馈信息均未被伪造时，兑现该订单。采用本发明中的方法，能够避免不法人员非法篡改支付反馈信息或订单来实现少支付或者不支付费用所造成的损失，同时，还能避免重复兑现订单所造成的损失。

Description

支付反馈信息的处理方法、装置、电子设备和存储介质

技术领域

本发明总体来说涉及一种信息安全技术，具体而言，涉及一种支付反馈信息的处理方法。

背景技术

网上支付通常涉及客户、商户和银行三方。商户是商品或服务的提供方，也是网上支付中的收款方。客户在商户网站选定商品或服务以及支付银行后生成一个订单，该订单具有支付银行、订单号和金额等信息。将该订单的订单号和金额信息通过互联网发送到的网上银行，然后转跳到该网上银行的支付界面。客户在该支付界面完成支付后，网上银行将具有支付结果的支付反馈信息发送到商户网站。商户网站根据该支付反馈信息来决定是否提供订单中的服务或商品。

在互联网保险中，网上支付是一个重要环节。网上支付不但用于投保流程，也用于续期交费环节。保持流程的安全性非常重要。

在互联网保险的网上支付具有以下特点：

1、保险商户网站和网上银行是两个相互独立的系统，两者之间通过互联网公网连接；

2、网上银行向商户网站返回支付反馈信息的环节对保险商户最重要，该支付反馈信息是保险商户调用承保程序自动承保的依据之一，而该支付反馈信息通过互联网进入商户网站。

有如下情况可能引起安全问题或者用户歧义：

1.不法之徒模拟银行的支付反馈信息，模拟一个银行返回的伪支付反馈信息，这个伪支付反馈信息拼接了支付成功的参数，实际上未支付或者少支付，保险商户网站未校验或校验不严密则有可能在接收到伪支付反馈信息后对该保单进行承保而造成损失。

2.用户不熟悉网上银行操作，在网上银行支付成功后，双击了“返回商户”按钮，造成了两次调用保险公司承保接口，如果承保端校验不严密，会造成重复出单。

如果对该风险没有充分分析和预防，则会给保险商户带来较大安全风险，现有技术往往考虑不够全面。

在所述背景技术部分公开的上述信息仅用于加强对本发明的背景的理解，因此它可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

在发明内容部分中引入了一系列简化形式的概念，这将在具体实施方式部分中进一步详细说明。本发明内容部分并不意味着要试图限定出所要求保护的技术方案的关键特征和必要技术特征，更不意味着试图确定所要求保护的技术方案的保护范围。

本发明的一个主要目的在于克服上述现有技术的至少一种缺陷，提供一种支付反馈信息的处理方法，其包括：

接收支付反馈信息，所述支付反馈信息至少包括订单号、支付金额、支付状态和签名信息；

对支付反馈信息进行签名验证；

当通过签名验证时，根据支付状态信息判断是否支付成功；

当支付成功时，查询订单号所对应的订单的处理状态并验明该订单及该支付反馈信息的真伪；

当该订单为未被锁定的待处理订单且该订单和该支付反馈信息均未被伪造时，兑现该订单。

在一个具体的实施例中，查询订单号所对应的订单的处理状态的步骤包括：

在预先建立的订单号锁定表中查询是否具有所述订单号，所述订单号锁定表被配置为不能记录同样的两个订单号；

若具有支付反馈信息中的订单号，则确认该订单被锁定；

若不具有支付反馈信息中的订单号，则确认该订单未被锁定并将订单号写入到订单号锁定表中。

在一个具体的实施例中，查询订单号所对应的订单的处理状态的步骤还包括：

查询该订单是否已具备处理结果；

若具备处理结果，则确认该订单不是待处理订单；

若不具备处理结果，则确认该订单时待处理订单。

在一个具体的实施例中，验明该订单及该支付反馈信息的真伪的步骤包括：

判断该订单号对应的订单是否实际存在，若不存在则认定该支付反馈信息为伪造。

在一个具体的实施例中，验明该订单及该支付反馈信息的真伪的步骤包括：

判断该订单的内容是否完整，若不完整则认定该订单为伪造订单。

在一个具体的实施例中，验明该订单及该支付反馈信息的真伪的步骤还包括：

判断支付反馈信息的支付金额是否与订单的订单金额相符，若该订单金额与支付金额不相符则认定支付反馈信息为伪造。

在一个具体的实施例中，验明该订单及该支付反馈信息的真伪的步骤还包括：

在判断出支付成功后，立即将支付反馈信息所包含的订单号和支付金额作为支付记录存储下来；

判断所述支付金额是否与订单的订单金额相符之前，验证支付反馈信息的支付金额与支付记录中的支付金额是否一致，若不一致则认定支付反馈信息为伪造。

本发明还提出了一种支付反馈信息的处理装置，其包括：

接收模块，用于接收支付反馈信息，所述支付反馈信息至少包括订单号、支付金额、支付状态和签名信息；

签名验证模块，用于对支付反馈信息进行签名验证；

支付状态查询模块，用于在通过签名验证后根据支付状态信息判断是否支付成功；

真伪验证模块，用于当支付成功时查询订单号所对应的订单的处理状态并验明该订单及该支付反馈信息的真伪；

订单处理模块，当该订单为未被锁定的待处理订单且该订单和该支付反馈信息均未被伪造，则兑现该订单。

本发明还包括一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现上述的处理方法。

本发明还包括一种电子设备，其包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行上述的处理方法。

由上述技术方案可知，本发明的支付反馈信息的处理方法的优点和积极效果在于：

采用本发明中的方法，能够避免不法人员非法篡改支付反馈信息或订单来实现少支付或者不支付费用所造成的损失，同时，还能避免重复兑现订单所造成的损失。

附图说明

通过结合附图考虑以下对本发明的优选实施例的详细说明，本发明的各种目标、特征和优点将变得更加显而易见。附图仅为本发明的示范性图解，并非一定是按比例绘制。在附图中，同样的附图标记始终表示相同或类似的部件。其中：

图1是根据一示例性实施方式示出的一种支付反馈信息的处理方法的流程图；

图2是根据一示例性实施方式示出的一种支付反馈信息的处理装置的示意图；

图3是根据一示例性实施方式示出的一种电子设备的示意图；

图4是根据一示例性实施方式示出的一种存储介质的示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的实施方式；相反，提供这些实施方式使得本发明将全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。图中相同的附图标记表示相同或类似的结构，因而将省略它们的详细描述。

参照图1，图1显示了一种支付反馈信息的处理方法，该处理方法包括以下步骤：

S1：接收支付反馈信息；

客户通过浏览器在商户网站选购服务，生成一订单后发起支付请求。该商户网站可以是保险商户网站，客户可以在保险商户网站选购保险服务。客户在发起支付请求时，商户网站将流量器页面转跳至选择网银支付以及确定银行的界面。在客户选择网银支付并指定一个银行后，浏览器将该订单的订单号和支付金额以及商户号发送至该银行的网上银行，并将浏览器转跳至网上银行的支付页面。客户在该支付页面完成支付后，网上银行将浏览器从支付页面跳转至处理结果页面，处理结果页面显示客户是否支付成功。客户可以在处理结果页面通过浏览器跳转返回支付反馈信息给商户网站，例如，客户点击处理结果页面中的“返回商户”按钮而使得网上银行将支付反馈信息发送给商户。

该支付反馈信息中包括商户号、订单号、支付金额、支付状态信息、签名信息等信息。该支付反馈信息可以是URL格式。

网上银行与商户网站之间通常采用HTTPS(Hyper Text Transfer Protocol overSecure Socket Layer，超文本传输安全协议)进行通讯。商户与银行预先签订合约，银行分配给商户唯一的商户号，商户和银行互相交换各自的接口地址，商户将接收地址预留给银行，银行将银行网关的接口地址预留给商户。商户网站与银行网关之间通过报文和数据文件的形式交互业务信息。

当然，除了通过客户的浏览器将支付反馈信息发送给商户网站，在银行与商户预先约定的前提下银行网关还可以主动向商户网站发送支付反馈信息。另外，在商户网站还可以主动向银行网关发送查询交易的指令，银行网关可以根据该指令将支付反馈信息发送给商户网站。

S2：对支付反馈信息进行签名验证；

支付反馈信息的原文包括商户号、订单号、支付金额、支付状态等信息，但不包含签名信息。在银行发送支付反馈信息之前，支付反馈信息的原文经数字签名算法和秘钥的运算，生成唯一的签名信息被附加到支付反馈信息中。该数字签名算法可以是RSA签名、MD5签名、DSS签名、Rabin签名等算法。数字签名结果具有唯一性，即如果原文被改动，则算法生成的结果必然会发生变化，即难以自行模拟原文而碰撞出相同的签名信息。

商户网站接收到包含商户号、订单号、支付金额、是否支付成功和签名信息的支付反馈信息后，商户网站可以使用验签算法对该支付反馈信息中的原文进行验证来判断支付反馈信息是否被篡改以及该支付反馈信息的来源是否为银行。

当签名验证通过则表明该支付反馈信息没被篡改且该支付反馈信息的来源为银行，当签名验证没通过则表明该支付反馈信息被篡改或者该支付反馈信息的来源不为银行。

在保险商户网站，不法人员有可能投保高额理财险，进入支付环节，但不实际支付。从其他渠道获得银行返回数据格式，自行拼接数据，调用保险商户网站的服务器，如果保险商户网站没有对数字签名进行严格判断，则可能对此理财险承保并出保单。

S3a：若未通过签名验证，则结束且提示错误；

在该步骤中，可以通过返回错误提示信息来提示错误，错误信息可以是：签名验证失败，不是银行的格式。

S3b：若通过签名验证，则根据支付反馈信息中支付状态信息判断是否支付成功；

在支付反馈信息包含能判断支付是否成功的支付状态信息。该支付状态信息可以通过标识表达，例如在特定字段下的字符“A”表达支付成功，字符“B”表达支付失败，字符“K”表达支付结果未知。因此，可以通过识别该特定字段下的字符来判断支付是否成功。

在大多数网上银行支付过程中，如果遇到客户的银行存款不够或者密码输入错误等情况，仅将该错误信息在网上银行提示，不将支付反馈信息返回到商户网站。但有一部分网上银行为了商户的需求，可以配置为将错误支付的支付反馈信息返回商户网站，这种情况下若没有判断是否支付成功则可能导致客户在未支付价款的情况下而顺利承保、造成损失。

S4a：若未支付成功，则结束并提示错误。

在该步骤中，可以通过返回错误提示信息来提示错误，错误信息可以是：支付未成功。在客户未成功支付价款的情况下，停止承保则能避免造成损失。

S4b：若支付成功，则将支付银行信息和支付反馈信息中的订单号、支付金额作为支付记录存储下来，该支付记录包含支付银行、订单号、支付金额；进入到步骤S5；

执行一步写入支付记录操作，将支付银行、订单号、支付金额写入数据库中，写入支付记录表明客户确实支付成功，并且和接收银行返回指令的程序在同一模块，属于有力的“证据”，后面经过若干跳转环节，过程数据有伪造可能性，后续通过判断过程数据与该支付记录是否相符来验证过程数据是否遭受篡改。

S5：根据支付反馈信息中的订单号，判断是否具有正在处理该订单号对应订单的任务；步骤S5包括步骤S51～S53。

S51：在预先建立的订单号锁定表中查询是否具有支付反馈信息中的订单号；

订单号锁定表是一个仅能记录不同订单号的表格，订单号锁定表中不能记录同样的两个订单号。在调用商户网站内部处理订单的程序时，首先访问该订单号锁定表。例如，保险商户网站在得到客户支付成功的信息后，就立即调用承保程序准备承保，而在开始调用承保程序时首先查询该订单号锁定表中是否具备该支付反馈信息中的订单号。

S52：若订单号锁定表具有支付反馈信息中的订单号，确认该订单被锁定，进入到步骤S6a；

当该订单号锁定表中具有该订单号则表明已经有其他承保任务被调用来处理该订单号对应的订单了，该订单处于正在被处理状态。因此可以确认存在其他正在处理该订单的任务，不可以调用程序继续处理该订单。为了避免重复处理该订单，结束本次处理订单的任务，同时提示错误。提示错误的内容可以是订单正在处理中。

S53：若订单号锁定表中不具有支付反馈信息中的订单号，确认该订单未被锁定并写入该订单号，然后进入到步骤S6b。

当该订单号锁定表中不具有该订单号则表明没有其他承保任务被调用来处理该订单号对应的订单，该订单还未被处理。因此可以确认不存在其他正在处理该订单的任务，可以调用程序继续处理该订单。

在该步骤中，在订单号锁定表中记录正在处理的订单号可以形成一个订单锁，在订单被订单锁锁定之后，能防止后续步骤重复处理该订单。例如，在保险商户网站调用承保程序后，发现该订单被锁定则停止继续承保，防止客户交一份钱而生成多张保单。

等承保结束后，删除该订单号对应的数据，锁定解除。

S6a：若具有正在处理该订单的任务，则结束并提示错误。

S6b：若不具有正在处理该订单的任务，则判断该支付反馈信息中的订单号对应的订单是否实际存在；

客户只有先进行订单填写，才会调用网上银行进行支付，网上银行支付后才会返回支付反馈信息。如果支付反馈信息中的订单号在商户网站中查询不到对应的订单则该支付反馈信息可能是伪造的或经篡改的信息。

在商户网站的数据库中检索是否具有支付反馈信息中的订单号，如果没有订单号，自然不会获得订单内容，也就无从处理该订单。

获取支付反馈信息的指令暴露在公网上，黑客不时在扫描，黑客可能以此模拟银行的支付反馈信息进行试探。

S7a：若订单不存在，则结束并提示错误。

在该步骤中，提示错误的内容可以是：无此订单。

S7b：若订单是否实际存在，则判断该订单是否是待处理订单。

在保险商户网站中，已处理完的订单会生成一个保单。当根据该订单号查询到该订单号对应的保单时则证明该订单不是待处理订单，而是已经被处理完的订单。

有的网上银行除了客户点击返回浏览器发送支付反馈信息到商户网站之外，银行网关还会主动发送支付反馈信息到商户网站，如果两次收到支付反馈信息都触发处理同一个订单则会造成订单的重复处理。

客户双击网上银行“返回商户”按钮，则可能通过浏览器发送两次支付反馈信息。如果两次收到支付反馈信息都触发处理同一个订单则会造成订单的重复处理。

上述两种情况如果是在保险商户网站的场景下，则会导致重复对一个保单承保两次，最后会生成多张保单。对订单是否是待处理订单的判断，能避免重复出单，重复承保。

S8a：若订单不是待处理订单，则结束并提示订单已完成处理。

S8b：若订单是待处理订单，则检查该订单号对应的订单的内容是否完整。

订单号可以查到订单数据，但应该校验订单的内容是否完整，如果订单内容不完整，则该订单涉嫌伪造，不能承保。

S9a：如果判断订单有误，结束并提示错误。

提示错误内容：订单信息错误。

S9b：若订单的内容完整，判断数据库中是否存在支付记录；

正常情况下，在步骤S4b中，已经将支付记录存储在数据库中。本步骤是对应支付返回流程中，步骤S4b的后续判断。如果仅有订单号和支付金额等信息，存在传输信息环节别篡改的可能性，但是如果加上了支付记录的判断，这种篡改可能性大大下降。因为支付记录生成，是银行返回流程直接写入的，前面有了对银行签名的判断，并且写入程序和银行返回在一个模块，黑客想更改信息无从下手。现在判断数据库有没有这条数据，除非黑客把数据库攻破了添加一条这样的数据，这个难度非常非常大。

S10a：若没有支付记录，则结束并提示没有支付记录。

S10b：若具有支付记录，则判断支付记录的支付金额与当前支付反馈信息中的支付金额是否一致；

当前系统中的支付反馈信息中支付金额是由上面多个步骤一步步传递下来的，在传递的过程中可能会遭受恶意篡改，如果将该支付金额与支付记录的支付金额进行比对则能判断出当前所记录的支付金额是否被篡改。

在保险商户网站进行这一步，能防止银行返回程序调用承保程序，中间有人篡改支付金额。支付记录的金额是准确的、客户实际支付的金额，传递过来的金额不一致，必然有问题，不能进行承保。

S11a：若支付记录的支付金额与当前支付反馈信息中的支付金额不一致，则结束并提示错误。

提示错误的内容可以是：支付金额不一致。

S11b：若支付记录的支付金额与当前支付反馈信息中的支付金额一致，则判断当前支付反馈信息中的支付金额和订单金额是否一致；

如果没有这个判断，黑客可能进行如下操作：在网站买一个10万元的保险，选择银行，跳出网银，把银行的URL截取下来，将金额修改为1分，很多银行对这个是没有校验的，后面继续支付1分钱，银行正常返回支付反馈信息，调用商户网站处理订单，如果缺少了订单金额和实际金额的校验，则将发生1分钱购买10万元商品的情况。

S12a：若当前支付反馈信息中的支付金额和订单金额不一致，则结束并提示错误。

提示错误的内容为：支付金额不够。

S12b：兑现该订单。

对于保险商户网站来说，在承保业务情景下兑现订单可以是对订单进行承保，在续期缴费的情景下兑现该订单可以确认其完成缴费。

以承保业务为例，前面经过重重判断，到这一步确定支付没问题了，才可以调用承保模块。这样能够避免不法人员非法篡改支付反馈信息或订单来实现少支付或者不支付费用所造成的损失，同时，还能避免重复兑现订单所造成的损失。

参照图2，本实施例还提出了一种支付反馈信息的处理装置1。该处理装置1包括：接收模块11、签名验证模块12、支付状态查询模块13、真伪验证模块14和订单处理模块15。

接收模块11，用于接收支付反馈信息，所述支付反馈信息至少包括订单号、支付金额、支付状态和签名信息；

签名验证模块12，用于对支付反馈信息进行签名验证；

支付状态查询模块13，用于在通过签名验证后根据支付状态信息判断是否支付成功；

真伪验证模块14，用于当支付成功时查询订单号所对应的订单的处理状态并验明该订单及该支付反馈信息的真伪；

订单处理模块15，当该订单为未被锁定的待处理订单且该订单和该支付反馈信息均未被伪造，则兑现该订单。

进一步地，真伪验证模块14还包括订单锁模块、锁定确认模块和未锁定确认模块。

订单锁模块，用于在预先建立的订单号锁定表中查询是否具有所述订单号，所述订单号锁定表被配置为不能记录同样的两个订单号；

锁定确认模块，用于在具有支付反馈信息中的订单号时，确认该订单被锁定；

未锁定确认模块，用于在不具有支付反馈信息中的订单号时，确认该订单未被锁定并将订单号写入到订单号锁定表中。

进一步地，真伪验证模块14还包括：

结果查询模块，用于查询该订单是否已具备处理结果；

非待处理订单确认模块，用于在具备处理结果时确认该订单不是待处理订单；

待处理订单确认模块，用于在不具备处理结果时确认该订单时待处理订单。

进一步地，真伪验证模块14还包括订单查询模块。

订单查询模块用于判断该订单号对应的订单是否实际存在，若不存在则认定该支付反馈信息为伪造。

进一步地，真伪验证模块14还包括订单内容核查模块。

订单内容核查模块用于判断该订单的内容是否完整，若不完整则认定该订单为伪造订单。

进一步地，真伪验证模块14还包括金额验证模块和记录复核模块。

金额验证模块用于判断支付反馈信息的支付金额是否与订单的订单金额相符若该订单金额与支付金额不相符则认定支付反馈信息为伪造。

进一步地，真伪验证模块14还包括记录存储模块和：

记录存储模块，用于在判断出支付成功后，立即将支付反馈信息所包含的订单号和支付金额作为支付记录存储下来；

记录复核模块，用于判断所述支付金额是否与订单的订单金额相符之前，验证支付反馈信息的支付金额与支付记录中的支付金额是否一致，若不一致则认定支付反馈信息为伪造。

下面参照图3来描述根据本发明的这种实施方式的电子设备800。图3显示的电子设备800仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图3所示，电子设备800以通用计算设备的形式表现。电子设备800的组件可以包括但不限于：上述至少一个处理单元810、上述至少一个存储单元820、连接不同系统组件(包括存储单元820和处理单元810)的总线830。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元810执行，使得所述处理单元810执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的步骤。

存储单元820可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)8201和/或高速缓存存储单元8202，还可以进一步包括只读存储单元(ROM)8203。

存储单元820还可以包括具有一组(至少一个)程序模块8205的程序/实用工具8204，这样的程序模块8205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线830可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备800也可以与一个或多个外部设备700(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得保险客户能与该电子设备800交互的设备通信，和/或与使得该电子设备800能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口850进行。并且，电子设备800还可以通过网络适配器860与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器860通过总线830与电子设备800的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备800使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施方式的支付反馈信息的处理方法。

在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书支付反馈信息的处理方法的程序产品。在一些可能的实施方式中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的步骤。

参考图4所示，描述了根据本发明的实施方式的用于实现上述支付反馈信息的处理方法的程序产品900，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程序程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在保险客户计算设备上执行、部分地在保险客户设备上执行、作为一个独立的软件包执行、部分在保险客户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到保险客户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。

尽管已经参照某些实施例公开了本发明，但是在不背离本发明的范围和范畴的前提下，可以对所述的实施例进行多种变型和修改。因此，应该理解本发明并不局限于所阐述的实施例，其保护范围应当由所附权利要求的内容及其等价的结构和方案限定。

Claims (10)

1.一种支付反馈信息的处理方法，其特征在于，包括：

接收支付反馈信息，所述支付反馈信息至少包括订单号、支付金额、支付状态和签名信息；

对支付反馈信息进行签名验证；

当通过签名验证时，根据支付状态信息判断是否支付成功；

当支付成功时，查询订单号所对应的订单的处理状态并验明该订单及该支付反馈信息的真伪；

当该订单为未被锁定的待处理订单且该订单和该支付反馈信息均未被伪造时，兑现该订单。

2.根据权利要求1所述的处理方法，其特征在于，查询订单号所对应的订单的处理状态的步骤包括：

在预先建立的订单号锁定表中查询是否具有所述订单号，所述订单号锁定表被配置为不能记录同样的两个订单号；

若具有支付反馈信息中的订单号，则确认该订单被锁定；

若不具有支付反馈信息中的订单号，则确认该订单未被锁定并将订单号写入到订单号锁定表中。

3.根据权利要求2所述的处理方法，其特征在于，查询订单号所对应的订单的处理状态的步骤还包括：

查询该订单是否已具备处理结果；

若具备处理结果，则确认该订单不是待处理订单；

若不具备处理结果，则确认该订单时待处理订单。

4.根据权利要求1所述的处理方法，其特征在于，验明该订单及该支付反馈信息的真伪的步骤包括：

判断该订单号对应的订单是否实际存在，若不存在则认定该支付反馈信息为伪造。

5.根据权利要求4所述的处理方法，其特征在于，验明该订单及该支付反馈信息的真伪的步骤包括：

判断该订单的内容是否完整，若不完整则认定该订单为伪造订单。

6.根据权利要求5所述的处理方法，其特征在于，验明该订单及该支付反馈信息的真伪的步骤还包括：

判断支付反馈信息的支付金额是否与订单的订单金额相符，若该订单金额与支付金额不相符则认定支付反馈信息为伪造。

7.根据权利要求6所述的处理方法，其特征在于，验明该订单及该支付反馈信息的真伪的步骤还包括：

在判断出支付成功后，立即将支付反馈信息所包含的订单号和支付金额作为支付记录存储下来；

判断所述支付金额是否与订单的订单金额相符之前，验证支付反馈信息的支付金额与支付记录中的支付金额是否一致，若不一致则认定支付反馈信息为伪造。

8.一种支付反馈信息的处理装置，其特征在于，包括：

接收模块，用于接收支付反馈信息，所述支付反馈信息至少包括订单号、支付金额、支付状态和签名信息；

签名验证模块，用于对支付反馈信息进行签名验证；

支付状态查询模块，用于在通过签名验证后根据支付状态信息判断是否支付成功；

真伪验证模块，用于当支付成功时查询订单号所对应的订单的处理状态并验明该订单及该支付反馈信息的真伪；

订单处理模块，当该订单为未被锁定的待处理订单且该订单和该支付反馈信息均未被伪造，则兑现该订单。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任意一项所述的处理方法。

10.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1至7中任意一项所述的处理方法。

Images