业务补偿方法及装置与流程

本发明涉及计算机技术领域，尤其涉及一种业务补偿方法及装置。

背景技术：

当前，终端常常需要向服务器发送业务处理请求以使服务器对该业务请求进行处理。例如，用户需要将一个银行账户的余额转入另一个银行账户中，则用户可以利用自己的手机向银行的服务器发送转账请求。

然而，在终端向服务器发送业务处理请求的同时如果终端与服务器之间的用于传输业务处理请求的网络突然出现故障，导致该业务处理请求在传输过程中丢失，这样服务器接收不到终端发送的该业务处理请求，也就无法对该业务处理请求进行处理，这就达不到终端使得服务器对该业务处理请求处理成功的目的。

或者，在终端向服务器发送业务处理请求的同时如果终端与服务器之间的用于传输业务处理请求的网络未出现故障，服务器接收到了终端发送的该业务处理请求，但是服务器在对该业务处理请求进行处理时处理失败了，同样也达不到终端使得服务器对该业务处理请求处理成功的目的。例如，当业务处理请求为转账请求时，转账请求携带了付款账户的账户标识、收款账户的账户标识以及转账金额，正常情况下，服务器需要从付款账户的余额中提取出该转账金额，并将提取出的转账金额与收款账户的余额进行合并，从而实现转账。但是，如果服务器根据付款账户的账户标识从数据库中读取付账账户中的余额时读取失败，则就无法将提取出的转账金额与收款账户的余额进行合并，这就无法实现转账，导致转账失败，达不到终端转账的目的。

技术实现要素：

为克服相关技术中存在的问题，本发明提供一种业务补偿方法及装置。

根据本发明实施例的第一方面，提供一种业务补偿方法，所述方法还包括：

判断业务发起方是否向业务受理方发送业务处理请求；

当业务发起方向业务受理方发送业务处理请求时，检测业务受理方是否对所述业务处理请求处理成功；

当确定出业务受理方未对所述业务处理请求处理成功时，根据所述业务处理请求向业务发起方发送补偿请求，以使业务发起方在接收到所述补偿请求之后，再次向业务受理方发送所述业务处理请求，并使业务受理方对所述再次发送的业务处理请求进行处理。

进一步地，所述方法还包括：

当确定出业务受理方未对所述业务处理请求处理成功时，判断在历史过程中根据所述业务处理请求向业务发起方发送补偿请求的总发送次数是否小于预设次数阈值；

当在历史过程中根据所述业务处理请求向业务发起方发送补偿请求的总发送次数小于预设次数阈值时，执行所述根据所述业务处理请求向业务发起方发送补偿请求的步骤。

进一步地，所述方法还包括：

当确定出业务受理方未对所述业务处理请求处理成功时，获取本地的当前时刻；

获取业务发起方第一次向业务受理方发送所述业务处理请求时的发送时刻；

判断所述当前时刻与所述发送时刻之间的时间差值是否小于预设时间差阈值；

当所述当前时刻与所述发送时刻之间的时间差值小于预设时间差阈值时，执行所述根据所述业务处理请求向业务发起方发送补偿请求的步骤。

其中，所述检测业务受理方是否对所述业务处理请求处理成功，包括：

检测是否接收到业务受理方对所述业务处理请求进行处理后得到的处理结果；

当接收到业务受理方对所述业务处理请求进行处理后得到的处理结果时，如果所述处理结果用于表示业务受理方对所述业务处理请求处理失败，确定业务受理方未对所述业务处理请求处理成功。

进一步地，所述方法还包括：获取业务发起方向业务受理方发送所述业务处理请求时的发送时刻；

所述检测业务受理方是否对所述业务处理请求处理成功，包括：

检测在以所述发送时刻为起点且时长为预设时长的时间段内是否接收到业务受理方对所述业务处理请求进行处理后得到的处理结果；

当在所述时间段内未接收到业务受理方对所述业务处理请求进行处理后得到的处理结果时，确定业务受理方未对所述业务处理请求处理成功。

根据本发明实施例的第二方面，提供一种业务补偿装置，所述装置还包括：

第一判断模块，用于判断业务发起方是否向业务受理方发送业务处理请求；

检测模块，用于当业务发起方向业务受理方发送业务处理请求时，检测业务受理方是 否对所述业务处理请求处理成功；

发送模块，用于当确定出业务受理方未对所述业务处理请求处理成功时，根据所述业务处理请求向业务发起方发送补偿请求，以使业务发起方在接收到所述补偿请求之后，再次向业务受理方发送所述业务处理请求，并使业务受理方对所述再次发送的业务处理请求进行处理。

进一步地，所述装置还包括：

第二判断模块，用于当确定出业务受理方未对所述业务处理请求处理成功时，判断在历史过程中根据所述业务处理请求向业务发起方发送补偿请求的总发送次数是否小于预设次数阈值；

所述发送模块还用于当在历史过程中根据所述业务处理请求向业务发起方发送补偿请求的总发送次数小于预设次数阈值时，根据所述业务处理请求向业务发起方发送补偿请求。

进一步地，所述装置还包括：

第一获取模块，用于当确定出业务受理方未对所述业务处理请求处理成功时，获取本地的当前时刻；

第二获取模块，用于获取业务发起方第一次向业务受理方发送所述业务处理请求时的发送时刻；

第三判断模块，用于判断所述当前时刻与所述发送时刻之间的时间差值是否小于预设时间差阈值；

所述发送模块还用于当所述当前时刻与所述发送时刻之间的时间差值小于预设时间差阈值时，根据所述业务处理请求向业务发起方发送补偿请求。

其中，所述检测模块包括：

第一检测单元，用于检测是否接收到业务受理方对所述业务处理请求进行处理后得到的处理结果；

第一确定单元，用于当接收到业务受理方对所述业务处理请求进行处理后得到的处理结果时，如果所述处理结果用于表示业务受理方对所述业务处理请求处理失败，确定业务受理方未对所述业务处理请求处理成功。

进一步地，所述装置还包括：

第三获取模块，用于获取业务发起方向业务受理方发送所述业务处理请求时的发送时刻；

所述检测模块包括：

第二检测单元，用于检测在以所述发送时刻为起点且时长为预设时长的时间段内是否接收到业务受理方对所述业务处理请求进行处理后得到的处理结果；

第二确定单元，用于当在所述时间段内未接收到业务受理方对所述业务处理请求进行处理后得到的处理结果时，确定业务受理方未对所述业务处理请求处理成功。

本发明的实施例提供的技术方案可以包括以下有益效果：

在本发明实施例中，业务发起方向业务受理方发送该业务处理请求的目的是：使得业务受理方对该业务处理请求处理成功，而有时候业务受理方有可能会未对该业务处理请求处理成功，例如，由于业务发起方与业务受理方之间的用于传输该业务处理请求的网络出现故障等原因导致业务受理方未接收到业务发起方发送的该业务处理请求，进而业务受理方就无法对该业务处理请求进行处理，结果就是业务受理方未对业务处理请求处理成功；再例如，业务发起方与业务受理方之间的用于传输该业务处理请求的网络正常，业务受理方接收到了业务发起方发送的该业务处理请求，但是在对该业务处理请求进行处理时处理失败了，结果也是业务受理方未对业务处理请求处理成功。当业务受理方未对该业务处理请求处理成功时，这就没有达到业务发起方“使得业务受理方对该业务处理请求处理成功”的目的。

如果是业务受理方一直未接收到该业务处理请求，则就一直不无法对该业务处理请求进行处理，如果一直等待业务受理方接收该业务处理请求，则当等待时间较长时会降低对该业务处理请求的处理效率，且很可能业务受理方一直接收不到该业务处理请求，进而无法对该业务处理请求进行处理，因此就无法实现对该业务处理请求处理成功的目的。

如果是业务受理方对该业务处理请求处理失败，由于业务受理方不会重新对已经处理过的该业务处理请求进行处理，因此就无法实现对该业务处理请求处理成功的目的。

因此，当确定出业务受理方未对该业务处理请求处理成功时，为了能够使得业务受理方尽快对该业务处理请求处理成功，可以根据该业务处理请求向业务发起方发送补偿请求；补偿请求至少携带该业务处理请求的请求标识；当业务发起方接收到该补偿请求并从该补偿请求中提取出该业务处理请求的请求标识之后，就确定出业务受理方对该业务处理请求未处理成功，为了使得业务受理方能够尽快对该业务处理请求处理成功，业务发起方可以再次向业务受理方发送该业务处理请求，并使业务受理方对再次发送的业务处理请求进行处理。本发明实施例可以增加业务受理方对该业务处理请求的处理次数，进而提高业务受理方对该业务处理请求处理成功的几率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限 制本发明。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

图1是根据一示例性实施例示出的一种业务补偿方法的流程图；

图2是根据一示例性实施例示出的一种业务补偿方法的流程图；

图3是根据一示例性实施例示出的一种业务补偿方法的流程图；

图4是根据一示例性实施例示出的一种业务补偿装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

图1是根据一示例性实施例示出的一种业务补偿方法的流程图，如图1所示，该方法包括以下步骤。

在步骤s101中，判断业务发起方是否向业务受理方发送业务处理请求；

本发明实施例的执行主体可以为业务服务器。在本发明实施例中还包括一个网关服务器，网关服务器为业务发起方与业务受理方之间的桥梁。

当业务发起方需要向业务受理方发送业务处理请求时，业务发起方需要通过网关服务器将该业务处理请求发送至业务受理方。例如，业务发起方需要首先将该业务处理请求发送至网关服务器；当网关服务器接收到该业务处理请求时，再将该业务处理请求转发至业务受理方。

当业务受理方接收到该业务处理请求之后，就会对该业务处理请求进行处理并得到处理结果，然后业务受理方需要将对该业务处理请求进行处理后得到的处理结果返回给业务发起方。当业务受理方需要向业务发起方发送对该业务处理请求进行处理后得到的处理结果时，业务受理方需要通过网关服务器将该处理结果发送至业务发起方。例如，业务受理方需要首先将该处理结果发送至网关服务器；当网关服务器接收到该处理结果时，再将该 处理结果转发至业务发起方。

这样，当网关服务器接收到业务发起方发送的业务处理请求，再将业务发起方发送的该业务处理请求转发至业务受理方时，网关服务器就确定业务发起方向业务受理方发送业务处理请求，此时网关服务器可以向业务服务器通知业务发起方向业务受理方发送业务处理请求；当业务服务器接收到网关服务器发送的、业务发起方向业务受理方发送业务处理请求的通知时，业务服务器确定业务发起方向业务受理方发送业务处理请求。

当业务发起方向业务受理方发送该业务处理请求时，在步骤s102中，检测业务受理方是否对该业务处理请求处理成功；

在本发明一个实施例中，业务发起方向业务受理方发送业务处理请求之后，如果业务发起方与业务受理方之间的用于传输该业务处理请求的网络正常，业务受理方就可以接收到该业务处理请求，之后业务受理方就可以对该业务处理请求进行处理时，业务受理方有可能对该业务处理请求处理成功，也有可能出该业务处理请求处理失败；例如，该业务处理请求用于将该业务处理请求携带的待处理数据与业务受理方本地数据库中存储的某一基准数据进行运算，如果业务受理方从本地数据库中成功的获取到该基准数据，并将该业务处理请求携带的待处理数据与该基准数据成功进行运算后得到结果数据，则业务受理方对该业务处理请求处理成功；如果业务受理方从本地数据库中未获取到该基准数据，或者，业务受理方从本地数据库中成功的获取到该基准数据但是将该业务处理请求携带的待处理数据与该基准数据进行运算时出错，则业务受理方对该业务处理请求处理失败；无论业务受理方对该业务处理请求处理成功还是处理失败，都会得到一个处理结果，当业务受理方对该业务处理请求处理成功时，得到的该处理结果用于表示业务受理方对该业务处理请求处理成功，当业务受理方对该业务处理请求处理失败时，得到的该处理结果用于表示业务受理方对该业务处理请求处理失败。

当业务受理方对该业务处理请求进行处理并得到处理结果之后，会将该处理结果返回至业务发起方。其中，业务受理方需要通过网关服务器将该处理结果返回至业务发起方。当业务受理方需要向业务发起方发送对该业务处理请求进行处理后得到的处理结果时，业务受理方需要通过网关服务器将该处理结果发送至业务发起方。例如，业务受理方需要首先将该处理结果发送至网关服务器；当网关服务器接收到该处理结果时，再将该处理结果转发至业务发起方。

这样，当网关服务器接收到业务受理方发送的该处理结果，再将业务受理方发送的该处理结果转发至业务发起方时，网关服务器就确定业务受理方向业务发起方发送对该业务处理请求进行处理后得到的该处理结果，此时网关服务器可以向业务服务器通知业务受理方向业务发起方发送的该处理结果；当业务服务器接收到网关服务器发送的、业务受理方 向业务发起方发送该处理结果的通知时，业务服务器就可以确定业务受理方向业务发起方发送对该业务处理请求进行处理后得到的该处理结果。进而根据该处理结果检测业务受理方是否对该业务处理请求处理成功。

因此，本步骤具体可以为：检测是否接收到业务受理方对该业务处理请求进行处理后得到的处理结果；

当接收到业务受理方对该业务处理请求进行处理后得到的处理结果时，判断该处理结果用于表示业务受理方对该业务处理请求处理失败还是用于表示业务受理方对该业务处理请求处理成功，如果该处理结果用于表示业务受理方对该业务处理请求处理失败，则确定业务受理方未对该业务处理请求处理成功，如果该处理结果用于表示业务受理方对该业务处理请求处理成功，则确定业务受理方对该业务处理请求处理成功。

在本发明另一个实施例中，业务发起方向业务受理方发送业务处理请求之后，如果业务发起方与业务受理方之间的用于传输该业务处理请求的网络出现故障，业务受理方就可能接收不到该业务处理请求，业务受理方接收不到该业务处理请求就无法对该业务处理请求进行处理，进而也就得不到对该业务处理请求进行处理后得到的处理结果。也即，业务受理方未对该业务处理请求处理成功。

对于业务发起方而言，就会接收不到业务受理方对该业务处理请求进行处理后得到的处理结果，因此，就可以根据是否能够接收到业务受理方对该业务处理请求进行处理后得到的处理结果来检测业务受理方是否对该业务处理请求处理成功。

这样，当确定出业务发起方向业务受理方发送业务处理请求时，业务服务器可以获取业务发起方向业务受理方发送该业务处理请求时的发送时刻。

也即，当业务服务器接收到网关服务器发送的、业务发起方向业务受理方发送该业务处理请求的通知时，业务服务器获取本地的当前时刻并作为业务发起方向业务受理方发送该业务处理请求时的发送时刻。

本步骤具体可以为：检测在以该发送时刻为起点且时长为预设时长的时间段内是否接收到业务受理方对该业务处理请求进行处理后得到的处理结果；当在时间段内未接收到业务受理方对该业务处理请求进行处理后得到的处理结果时，确定业务受理方未对该业务处理请求处理成功。

当确定出业务受理方未对该业务处理请求处理成功时，在步骤s103中，根据该业务处理请求向业务发起方发送补偿请求；以使业务发起方在接收到该补偿请求之后，再次向业务受理方发送该业务处理请求，并使业务受理方对业务发起方再次发送的该业务处理请求进行处理。

在本发明实施例中，业务发起方向业务受理方发送该业务处理请求的目的是：使得业务受理方对该业务处理请求处理成功，而有时候业务受理方有可能会未对该业务处理请求处理成功，例如，由于业务发起方与业务受理方之间的用于传输该业务处理请求的网络出现故障等原因导致业务受理方未接收到业务发起方发送的该业务处理请求，进而业务受理方就无法对该业务处理请求进行处理，结果就是业务受理方未对业务处理请求处理成功；再例如，业务发起方与业务受理方之间的用于传输该业务处理请求的网络正常，业务受理方接收到了业务发起方发送的该业务处理请求，但是在对该业务处理请求进行处理时处理失败了，结果也是业务受理方未对业务处理请求处理成功。当业务受理方未对该业务处理请求处理成功时，这就没有达到业务发起方“使得业务受理方对该业务处理请求处理成功”的目的。

如果是业务受理方一直未接收到该业务处理请求，则就一直不无法对该业务处理请求进行处理，如果一直等待业务受理方接收该业务处理请求，则当等待时间较长时会降低对该业务处理请求的处理效率，且很可能业务受理方一直接收不到该业务处理请求，进而无法对该业务处理请求进行处理，因此就无法实现对该业务处理请求处理成功的目的。

如果是业务受理方对该业务处理请求处理失败，由于业务受理方不会重新对已经处理过的该业务处理请求进行处理，因此就无法实现对该业务处理请求处理成功的目的。

因此，当确定出业务受理方未对该业务处理请求处理成功时，为了能够使得业务受理方尽快对该业务处理请求处理成功，可以根据该业务处理请求向业务发起方发送补偿请求；补偿请求至少携带该业务处理请求的请求标识；当业务发起方接收到该补偿请求并从该补偿请求中提取出该业务处理请求的请求标识之后，就确定出业务受理方对该业务处理请求未处理成功，为了使得业务受理方能够尽快对该业务处理请求处理成功，业务发起方可以再次向业务受理方发送该业务处理请求，并使业务受理方对再次发送的业务处理请求进行处理。本发明实施例可以增加业务受理方对该业务处理请求的处理次数，进而提高业务受理方对该业务处理请求处理成功的几率。

其中，当业务发起方向业务受理方发送多次该业务处理请求后，如果业务受理方都未对该业务处理请求成功，则通常情况下是由于该业务处理请求本身有问题，例如，该业务处理请求的数据格式不是业务受理方能够识别的数据格式，业务受理方无法识别该业务处理请求的数据格式就无法对该业务处理请求进行处理。

在本发明图1所示的实施例中，每间隔固定时长就会检测业务受理方是否对该业务处理请求处理成功；并当确定出业务受理方未对该业务处理请求处理成功时，就会根据该业务处理请求向业务发起方发送补偿请求；这样，在一段时间内业务发起方可能会就向业务 受理方发送多次该业务处理请求，很可能导致过多的业务处理请求堆积在业务受理方中。因此，为了避免业务发起方一直向业务受理发送该业务处理请求导致过多的业务处理请求堆积在业务受理方中，在本发明又一实施例中，参见图2，该方法还包括：

当确定出业务受理方未对该业务处理请求处理成功时，在步骤s201中，判断在历史过程中根据该业务处理请求向业务发起方发送补偿请求的总发送次数是否小于预设次数阈值；

在本发明实施例中，当第一次根据该业务处理请求向业务发起方发送补偿请求时，会设置次数初值，然后将该业务处理请求的请求标识与该次数初值组成一条记录存储在本地存储的请求标识与总发送次数之间的对应关系中；当之后根据该业务处理请求向业务发起方发送补偿请求时，会在该对应关系中增加该记录中的总发送次数。

因此，在本步骤中，可以获取本地存储的请求标识与总发送次数之间的对应关系，然后在该对应关系中查找与该业务处理请求的请求标识相对应的总发送次数，然后将查找到的总发送次数与预设次数阈值进行比较，当查找到的总发送次数小于预设次数阈值时，执行步骤s101。

其中，预设次数阈值为用户事先在业务服务器中设置，可以为20、30或40等，本发明对此不加以限定。

当在历史过程中根据该业务处理请求向业务发起方发送补偿请求的总发送次数小于预设次数阈值时，执行步骤s103：根据该业务处理请求向业务发起方发送补偿请求。

其中，当根据该业务处理请求向业务发起方发送补偿请求的总发送次数等于预设次数阈值时，此时就不再根据该业务处理请求向业务发起方发送补偿请求，而是提示用户来检查该业务处理请求是否正确。

当用户确定该业务处理请求正确时，为了使得业务受理方对该业务处理请求处理成功，用户可以主动控制业务发起方又一次向业务受理方发送该业务处理请求。

其中，当业务发起方向业务受理方发送多次该业务处理请求后，如果业务受理方都未对该业务处理请求成功，则通常情况下是由于该业务处理请求本身有问题，例如，该业务处理请求的数据格式不是业务受理方能够识别的数据格式，业务受理方无法识别该业务处理请求的数据格式就无法对该业务处理请求进行处理。

在本发明图1所示的实施例中，每间隔固定时长就会检测业务受理方是否对该业务处理请求处理成功；并当确定出业务受理方未对该业务处理请求处理成功时，就会根据该业务处理请求向业务发起方发送补偿请求；这样，在一段时间内业务发起方可能会就向业务 受理方发送多次该业务处理请求，很可能导致过多的业务处理请求堆积在业务受理方中。因此，为了避免业务发起方一直向业务受理发送该业务处理请求导致过多的业务处理请求堆积在业务受理方中，在本发明又一实施例中，参见图3，该方法还包括：

当确定出业务受理方未对该业务处理请求处理成功时，在步骤s301中，获取本地的当前时刻；

在步骤s302中，获取业务发起方第一次向业务受理方发送该业务处理请求时的发送时刻。

也即，当业务服务器接收到网关服务器发送的、业务发起方第一次向业务受理方发送该业务处理请求的通知时，业务服务器获取本地的当前时刻并作为业务发起方第一次向业务受理方发送该业务处理请求时的发送时刻，然后将业务发起方第一次向业务受理方发送该业务处理请求时的发送时刻存储在本地。这样，在本步骤中，可以直接从本地获取业务发起方第一次向业务受理方发送该业务处理请求时的发送时刻。

在步骤s303中，判断当前时刻与该发送时刻之间的时间差值是否小于预设时间差阈值；

其中，可以计算当前时刻与该发送时间之间的时间差值，然后将该时间差值与预设时间差阈值进行比较，当该时间差值小于预设时间差阈值时，执行步骤s101。

其中，预设时间差阈值为用户事先在业务服务器中设置，可以为24小时、48小时或72小时等，本发明对此不加以限定。

在当前时刻与该发送时刻之间的时间差值小于预设时间差阈值时，执行步骤s101：根据该业务处理请求向业务发起方发送补偿请求。

其中，在当前时刻与该发送时刻之间的时间差值大于或等于预设时间差阈值时，此时就不再根据该业务处理请求向业务发起方发送补偿请求，而是提示用户来检查该业务处理请求是否正确。

当用户确定该业务处理请求正确时，为了使得业务受理方对该业务处理请求处理成功，用户可以主动控制业务发起方又一次向业务受理方发送该业务处理请求。

图4是根据一示例性实施例示出的一种业务补偿装置的框图。参照图4，该装置包括：

第一判断模块11，用于判断业务发起方是否向业务受理方发送业务处理请求；

检测模块12，用于当业务发起方向业务受理方发送业务处理请求时，检测业务受理方是否对所述业务处理请求处理成功；

发送模块13，用于当确定出业务受理方未对所述业务处理请求处理成功时，根据所述 业务处理请求向业务发起方发送补偿请求，以使业务发起方在接收到所述补偿请求之后，再次向业务受理方发送所述业务处理请求，并使业务受理方对所述再次发送的业务处理请求进行处理。

进一步地，所述装置还包括：

第二判断模块，用于当确定出业务受理方未对所述业务处理请求处理成功时，判断在历史过程中根据所述业务处理请求向业务发起方发送补偿请求的总发送次数是否小于预设次数阈值；

所述发送模块还用于当在历史过程中根据所述业务处理请求向业务发起方发送补偿请求的总发送次数小于预设次数阈值时，根据所述业务处理请求向业务发起方发送补偿请求。

进一步地，所述装置还包括：

第一获取模块，用于当确定出业务受理方未对所述业务处理请求处理成功时，获取本地的当前时刻；

第二获取模块，用于获取业务发起方第一次向业务受理方发送所述业务处理请求时的发送时刻；

第三判断模块，用于判断所述当前时刻与所述发送时刻之间的时间差值是否小于预设时间差阈值；

所述发送模块还用于当所述当前时刻与所述发送时刻之间的时间差值小于预设时间差阈值时，根据所述业务处理请求向业务发起方发送补偿请求。

其中，所述检测模块12包括：

第一检测单元，用于检测是否接收到业务受理方对所述业务处理请求进行处理后得到的处理结果；

第一确定单元，用于当接收到业务受理方对所述业务处理请求进行处理后得到的处理结果时，如果所述处理结果用于表示业务受理方对所述业务处理请求处理失败，确定业务受理方未对所述业务处理请求处理成功。

进一步地，所述装置还包括：

第三获取模块，用于获取业务发起方向业务受理方发送所述业务处理请求时的发送时刻；

所述检测模块12包括：

第二检测单元，用于检测在以所述发送时刻为起点且时长为预设时长的时间段内是否 接收到业务受理方对所述业务处理请求进行处理后得到的处理结果；

第二确定单元，用于当在所述时间段内未接收到业务受理方对所述业务处理请求进行处理后得到的处理结果时，确定业务受理方未对所述业务处理请求处理成功。

在本发明实施例中，业务发起方向业务受理方发送该业务处理请求的目的是：使得业务受理方对该业务处理请求处理成功，而有时候业务受理方有可能会未对该业务处理请求处理成功，例如，由于业务发起方与业务受理方之间的用于传输该业务处理请求的网络出现故障等原因导致业务受理方未接收到业务发起方发送的该业务处理请求，进而业务受理方就无法对该业务处理请求进行处理，结果就是业务受理方未对业务处理请求处理成功；再例如，业务发起方与业务受理方之间的用于传输该业务处理请求的网络正常，业务受理方接收到了业务发起方发送的该业务处理请求，但是在对该业务处理请求进行处理时处理失败了，结果也是业务受理方未对业务处理请求处理成功。当业务受理方未对该业务处理请求处理成功时，这就没有达到业务发起方“使得业务受理方对该业务处理请求处理成功”的目的。

如果是业务受理方一直未接收到该业务处理请求，则就一直不无法对该业务处理请求进行处理，如果一直等待业务受理方接收该业务处理请求，则当等待时间较长时会降低对该业务处理请求的处理效率，且很可能业务受理方一直接收不到该业务处理请求，进而无法对该业务处理请求进行处理，因此就无法实现对该业务处理请求处理成功的目的。

如果是业务受理方对该业务处理请求处理失败，由于业务受理方不会重新对已经处理过的该业务处理请求进行处理，因此就无法实现对该业务处理请求处理成功的目的。

因此，当确定出业务受理方未对该业务处理请求处理成功时，为了能够使得业务受理方尽快对该业务处理请求处理成功，可以根据该业务处理请求向业务发起方发送补偿请求；补偿请求至少携带该业务处理请求的请求标识；当业务发起方接收到该补偿请求并从该补偿请求中提取出该业务处理请求的请求标识之后，就确定出业务受理方对该业务处理请求未处理成功，为了使得业务受理方能够尽快对该业务处理请求处理成功，业务发起方可以再次向业务受理方发送该业务处理请求，并使业务受理方对再次发送的业务处理请求进行处理。本发明实施例可以增加业务受理方对该业务处理请求的处理次数，进而提高业务受理方对该业务处理请求处理成功的几率。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

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

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。