CN117827916A

CN117827916A - 一种支付结果获取方法、装置、设备及存储介质

Info

Publication number: CN117827916A
Application number: CN202211185453.7A
Authority: CN
Inventors: 陈杰鹏; 吴剑锋; 李建新; 王晓东; 王增为
Original assignee: Shengdoushi Shanghai Technology Development Co Ltd
Current assignee: Shengdoushi Shanghai Science and Technology Development Co Ltd
Priority date: 2022-09-27
Filing date: 2022-09-27
Publication date: 2024-04-05

Abstract

本说明书实施例公开了一种支付结果获取方法、装置、设备和存储介质。所述方法包括：获取目标支付请求；循环执行以下步骤，直到满足预设循环停止条件：针对所述目标支付请求，查询本地是否存储对应的目标支付结果；在确定本地没有存储所述目标支付结果的情况下，向支付渠道方发送查询请求；所述查询请求用于查询所述支付渠道方是否存储所述目标支付结果；在确定所述支付渠道方存储所述目标支付结果的情况下，将所述目标支付结果存储到本地，结束循环。该方法可以通过循环查询获取支付结果和主动从支付渠道方查询获取支付结果，降低数据丢失或者延迟对支付流程的影响。

Description

一种支付结果获取方法、装置、设备及存储介质

技术领域

本说明书实施例涉及计算机应用技术领域，尤其涉及一种支付结果获取方法、装置、设备及存储介质。

背景技术

目前，在许多业务场景中，业务的支付相关数据都是较为重要的，通常需要重视支付相关数据的稳定性和安全性。

业务的支付流程通常可以包括：用户向业务方发起支付请求，然后用户通过支付渠道进行支付，支付渠道方可以将支付结果分别发送到用户和业务方，从而可以完成支付。

例如，用户针对餐厅订单发起支付请求，然后用户通过银行卡进行支付，支付成功后，银行方可以将支付成功的结果分别发送到用户和餐厅，从而完成支付。

但是，数据在传输过程中可能存在丢失或者延迟的现象，从而导致支付流程受到影响。

例如，支付渠道方如果将支付结果成功发送到用户，但是没有成功发送到业务方，那么业务方后续可能会错误地认为用户没有成功支付。

发明内容

为了解决上述技术问题，本说明书实施例提供了一种支付结果获取方法、装置、设备及存储介质。技术方案如下所示。

一种支付结果获取方法，包括：

获取目标支付请求；

循环执行以下步骤，直到满足预设循环停止条件：

针对所述目标支付请求，查询本地是否存储对应的目标支付结果；

在确定本地没有存储所述目标支付结果的情况下，向支付渠道方发送查询请求；所述查询请求用于查询所述支付渠道方是否存储所述目标支付结果；

在确定所述支付渠道方存储所述目标支付结果的情况下，将所述目标支付结果存储到本地，结束循环。

可选地，所述针对所述目标支付请求，查询本地是否存储对应的目标支付结果，包括：

等待第一预设时长之后，针对所述目标支付请求，查询本地是否存储对应的目标支付结果。

可选地，所述将所述目标支付结果存储到本地，包括：

在确定所述目标支付结果通过验证的情况下，将所述目标支付结果存储到本地。

可选地，所述确定所述目标支付结果通过验证，包括以下至少一项：

确定所述目标支付结果表征支付成功；

确定所述目标支付结果中的支付金额符合预设规则；

确定所述目标支付结果中的支付金额，与所述目标支付请求中的支付金额一致。

可选地，所述预设循环停止条件包括：循环次数大于预设次数；和/或循环耗时时长大于预设循环时长。

可选地，所述方法还包括：

在确定本地存储所述目标支付结果的情况下，结束循环；

所述本地存储的所述目标支付结果通过验证。

可选地，所述方法还包括：

循环结束后，针对未查询到对应的目标支付结果的目标支付请求，将所述目标支付请求确定为未完成支付，并将所述目标支付请求存储到本地。

可选地，所述将所述目标支付结果存储到本地，包括：

将所述目标支付结果添加到本地的待写库消息队列中，并响应于所述目标支付请求，返回所述目标支付结果；

所述待写库消息队列用于，将所述目标支付结果存储到数据库中。

可选地，所述待写库消息队列包括至少一个消息队列主题；不同消息队列主题对应于所述数据库中的不同数据表；

所述将所述目标支付结果添加到本地的待写库消息队列中，包括：针对所述目标支付结果，确定对应的消息队列主题；根据所确定的消息队列主题，将所述目标支付结果添加到本地待写库消息队列中；

所述待写库消息队列用于，针对所述目标支付结果对应的消息队列主题，确定对应的数据表；将所述目标支付结果存储到所确定的数据表中。

一种支付结果获取装置，包括：

获取单元，用于获取目标支付请求；

循环单元，用于循环执行以下步骤，直到满足预设循环停止条件：

可选地，所述循环单元，用于：

确定所述目标支付结果表征支付成功；

确定所述目标支付结果中的支付金额符合预设规则；

可选地，所述循环单元，还用于：

在确定本地存储所述目标支付结果的情况下，结束循环；

所述本地存储的所述目标支付结果通过验证。

可选地，所述循环单元，还用于：

可选地，所述循环单元，用于：

可选地，所述循环单元，用于：针对所述目标支付结果，确定对应的消息队列主题；根据所确定的消息队列主题，将所述目标支付结果添加到本地待写库消息队列中；

上述技术方案中，可以通过循环针对同一支付请求，查询获取对应的支付结果，并在业务方本地查询失败的情况下，主动向支付渠道方查询获取对应的支付结果，从而可以降低数据丢失或者延迟对支付流程的影响。

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

附图说明

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

图1是本说明书实施例提供的一种支付结果获取方法的流程示意图；

图2是本说明书实施例提供的另一种支付结果获取方法的流程示意图；

图3是本说明书实施例提供的一种异步写库的原理示意图；

图4是本说明书实施例提供的另一种支付结果获取方法的流程示意图；

图5是本说明书实施例提供的另一种支付结果获取方法的流程示意图；

图6是本说明书实施例提供的另一种支付结果获取方法的流程示意图；

图7是本说明书实施例提供的一种支付结果获取装置的结构示意图；

图8是用于配置本说明书实施例方法的一种设备的结构示意图。

具体实施方式

为了使本领域技术人员更好地理解本说明书实施例中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于公开的范围。

为了解决上述技术问题，本说明书实施例提供了一种支付结果获取方法。

在该方法中，针对支付渠道方的支付结果可能出现的延迟现象，可以通过循环流程，多次针对同一支付请求，查询业务方是否获取到对应的支付结果。

如果支付渠道方经过一定时长的延迟后，将支付结果发送到业务方，那么就可以通过循环流程，成功查询到支付请求对应的支付结果，降低数据延迟对支付流程的影响。

此外，针对支付渠道方的支付结果可能出现的丢失现象，可以通过业务方主动向支付渠道方查询获取支付请求对应的支付结果，从而主动获取到支付请求对应的支付结果。

如果支付渠道方由于网络波动或者其他原因，将支付结果在传输过程中丢失，那么就可以通过业务方的主动查询，成功查询获取到支付请求对应的支付结果，降低数据丢失对支付流程的影响。

因此，本方法可以通过循环多次针对同一支付请求，查询获取对应的支付结果，以及业务方主动向支付渠道方查询获取对应的支付结果，降低数据丢失或者延迟对支付流程的影响。

此外，为了提高查询获取效率，可以在每次循环过程中，查询业务方是否获取到对应的支付结果，并主动向支付渠道方查询支付请求对应的支付结果。

如图1所示，为本说明书实施例提供的一种支付结果获取方法的流程示意图。

本方法流程并不限定具体的执行主体。

可选地，执行主体可以是业务方的设备，例如，执行主体具体可以是业务方的服务器。

该方法可以包括以下步骤。

S101：获取目标支付请求。

S102：循环执行以下步骤，直到满足预设循环停止条件：针对目标支付请求，查询本地是否存储对应的目标支付结果；在确定本地没有存储目标支付结果的情况下，向支付渠道方发送查询请求；在确定支付渠道方存储目标支付结果的情况下，将目标支付结果存储到本地，结束循环。

可选地，查询请求可以用于查询支付渠道方是否存储目标支付结果。

本方法流程可以通过循环针对同一支付请求，查询获取对应的支付结果，并在业务方本地查询失败的情况下，主动向支付渠道方查询获取对应的支付结果，从而可以降低数据丢失或者延迟对支付流程的影响。

本方法流程中，目标支付请求具体可以是所获取的任一支付请求。为了方便描述，将本方法流程所针对的支付请求称为目标支付请求。

下面针对各个步骤进行详细的解释。

一、S101：获取目标支付请求。

本方法流程并不限定获取目标支付请求的方式。

可选地，可以是从客户端获取到目标支付请求，也可以是从业务***获取到目标支付请求。

例如，用户可以通过客户端实现线上支付，从而可以直接向业务方发送线上支付请求。用户也可以通过线下门店中刷银行卡的方式进行线下支付，从而可以由业务***向业务方发送线下支付请求。

本方法流程并不限定目标支付请求的形式和内容。

可选地，支付请求中可以包括需要支付的订单信息，例如，待支付的订单号；支付请求中也可以包括用户信息，例如，用户标识；支付请求中也可以包括需要支付的金额或者其他虚拟资源数量，例如，积分和优惠劵等。

二、S102：循环执行以下步骤，直到满足预设循环停止条件：针对目标支付请求，查询本地是否存储对应的目标支付结果；在确定本地没有存储目标支付结果的情况下，向支付渠道方发送查询请求；在确定支付渠道方存储目标支付结果的情况下，将目标支付结果存储到本地，结束循环。

1、针对预设循环停止条件，本方法流程并不具体限定。

可选地，预设循环停止条件具体可以包括以下至少一项：循环次数大于预设次数；循环耗时时长大于预设循环时长；查询到目标支付请求对应的目标支付结果；已获取目标支付请求对应的目标支付结果。

其中，由于支付渠道方可能没有生成目标支付请求对应的目标支付结果，例如，用户余额不足、用户账户冻结、支付渠道方出现故障等原因，导致支付渠道方本身没有生成目标支付结果。

因此，如果循环次数较多，或者循环耗时较长，就有可能是针对目标支付请求，暂时无法完成支付，从而可以直接结束循环。

而利用循环流程，可以实现对目标支付结果的多次获取，从而提高支付结果获取的稳定性。

因此，可选地，预设循环停止条件可以包括：循环次数大于预设次数；和/或循环耗时时长大于预设循环时长。

其中，由于查询到目标支付结果后还需要进行额外的操作，从而可以在S102中自行确定结束循环的时间。

在一种可选的实施例中，由于需要应对数据传输过程中的延迟，因此，为了节约计算资源，可以在不同次数的循环之间设置等待时长。

可选地，针对目标支付请求，查询本地是否存储对应的目标支付结果，可以包括：等待第一预设时长之后，针对目标支付请求，查询本地是否存储对应的目标支付结果。

本实施例并不限定第一预设时长。具体可以是2分钟或者10分钟，可以根据业务需求和实际情况确定。

可选地，第一预设时长可以与循环次数正相关，随着循环次数的增加，可以确定较长时间无法查询到目标支付结果，因此，可以等待更长的时间再继续查询，节约计算资源。

可选地，可以预先设置第一预设时长与循环次数的对应关系，第一预设时长可以与循环次数正相关，从而可以在等待循环次数对应的第一预设时长之后，针对目标支付请求，查询本地是否存储对应的目标支付结果。

本方法流程并不限定循环流程的具体实现方式。在一种可选的实施例中，可以利用消息队列的延迟队列机制，一方面能够通过延迟队列实现循环之间的延时，另一方面可以通过延迟队列机制中，将延迟队列中的消息重新添加到正常队列中的机制，实现循环流程。具体解释可以参见后文。

2、针对本地查询，本方法流程并不限定本地查询的方式。

需要说明的是，支付渠道方可能延迟一段时间后，将目标支付结果发送到执行主体本地，具体可以是因为支付渠道方的响应速度较慢，或者网络波动等因素影响，从而可以在每次循环中进行本地查询。如果本地能够查询到目标支付结果，就可以直接结束循环。

可选地，在确定本地存储有目标支付结果的情况下，可以结束循环。

在一种可选的实施例中，业务方设备本地可以包括本地缓存，也可以包括本地数据库。

相对应地，针对目标支付请求，查询本地是否存储对应的目标支付结果，可以包括：针对目标支付请求，查询本地缓存是否存储对应的目标支付结果；或者针对目标支付请求，查询本地数据库是否存储对应的目标支付结果；或者针对目标支付请求，查询本地缓存和本地数据库是否存储对应的目标支付结果。

在支付流程中，支付渠道方可以将支付结果发送到业务方。

可选地，业务方可以将接收到的支付结果存储到本地数据库中，也可以存储到本地缓存中。

可选地，业务方可以将接收到的支付结果分别存储到本地数据库和本地缓存中，本地缓存可以用于快速响应，本地数据库可以用于提高支付结果的稳定性。

可选地，业务方在接收到支付渠道方发送的支付结果的情况下，可以先针对支付结果进行验证，验证通过后可以存储到本地。

本实施例并不限定具体的验证方法。

可选地，针对支付结果的验证可以包括以下至少一项：验证支付结果是否表征支付成功；验证支付结果中的支付金额是否符合预设规则；验证支付结果中的支付金额，与对应的支付请求中的支付金额是否一致。

本实施例并不限定验证的具体预设规则，可选地，可以针对支付金额的来源设置预设规则，具体可以是限定从银行账户或支付应用获取的支付金额，也可以针对支付金额的支付渠道设置预设规则，具体可以是限定从指定的支付渠道支付的金额。

在本实施例中，通过针对支付结果进行验证，可以提高支付结果的安全性。

可选地，在业务方验证支付结果后才存储到本地的情况下，针对已经存储到本地的目标支付结果，可以确定目标支付结果已经通过验证。

当然，相对应地，在从支付渠道方查询到目标支付结果的情况下，也可以先针对目标支付结果进行验证，验证通过后可以将目标支付结果存储到本地。具体可以参见后文解释。

3、针对目标支付结果，本方法流程并不限定具体的形式。

可选地，目标支付结果可以包括所支付的订单信息，例如，所支付的订单号；目标支付结果可以包括所支付的金额或者虚拟资源数量，例如，积分数量；目标支付结果可以包括支付的用户信息，例如，用户标识。

本方法流程并不限定确定目标支付请求对应的目标支付结果的方法。

可选地，可以是根据所包含的订单信息进行确定。目标支付请求中所需要支付的订单信息，可以与目标支付结果中所支付的订单信息相同。订单信息具体可以是订单标识，例如，订单号。

可选地，可以根据目标支付请求本身的请求信息，确定对应的目标支付结果。

可选地，目标支付结果可以是目标支付请求所对应支付流程的结果。

可选地，支付结果可以包括支付成功、支付失败、支付未完成等多种情况。

在一种可选的实施例中，查询本地是否存储有对应的目标支付结果，可以存在两种查询结果。本地存储有目标支付结果，或者本地没有存储目标支付结果。

可选地，在确定本地没有存储目标支付结果的情况下，可以由业务方设备进一步主动向支付渠道方查询目标支付结果。

可选地，在确定本地存储有目标支付结果的情况下，说明可以直接从本地获取到目标支付结果，从而完成支付流程。

因此，可选地，可以在确定本地存储有目标支付结果的情况下，直接结束循环。

需要说明的是，通常本地存储有目标支付结果，可以表示目标支付结果已经通过验证，并且无需再次存储目标支付结果，因此，可以直接结束循环。

可选地，在确定本地存储目标支付结果的情况下，可以结束循环。

其中，可选地，本地存储的目标支付结果可以确定已经通过验证。

4、针对主动向支付渠道方的查询，本方法流程并不限定具体的主动查询方式。

在一种可选的实施例中，可以由业务方设备主动向支付渠道方发送查询请求，查询请求可以用于查询支付渠道方是否存储目标支付结果。

本实施例并不限定查询请求的形式。可选地，查询请求中可以包括目标支付请求，也可以包括目标支付请求所需要支付的订单信息等。

而针对主动查询，也存在两种查询结果。支付渠道方存储有目标支付结果，或者支付渠道方没有存储目标支付结果。

可选地，在确定支付渠道方存储目标支付结果的情况下，可以从支付渠道方获取目标支付结果，之后可以结束循环。

而针对获取的目标支付结果，可选地，可以将目标支付结果存储到本地，结束循环。

可选地，也可以先针对目标支付结果进行验证，在通过验证的情况下，再将目标支付结果存储到本地，结束循环。

因此，可选地，将目标支付结果存储到本地，可以包括：在确定目标支付结果通过验证的情况下，将目标支付结果存储到本地。

本实施例并不限定通过验证的具体情况。

可选地，确定目标支付结果通过验证，可以包括以下至少一项：确定目标支付结果表征支付成功；确定目标支付结果中的支付金额符合预设规则；确定目标支付结果中的支付金额，与目标支付请求中的支付金额一致。

可选地，如果目标支付结果没有通过验证，可以继续执行循环流程，也可以结束循环。

其中，如果目标支付结果没有通过验证，则可以说明目标支付请求支付未成功，具体可以是支付失败，或者支付金额不足等情况。

因此，可以继续执行循环流程，直到循环结束，也可以直接认定支付失败，结束循环。

此外，在一种可选的实施例中，循环结束后，针对已经查询到对应的目标支付结果的目标支付请求，可以将目标支付结果存储到本地，完成支付流程。

可选地，也可以将目标支付结果和目标支付请求一同存储到本地，提高安全性。

在循环结束后，针对未查询到对应的目标支付结果的目标支付请求，本方法流程并不限定具体的处理方式。

可选地，可以继续利用循环流程查询目标支付结果。

可选地，可以将目标支付请求直接确定为未完成支付，存储到本地，以便于后续的审计或者重新处理。

可选地，可以直接删除目标支付请求。

因此，可选地，为了提高目标支付请求的稳定性和安全性，可以在循环结束后，针对未查询到对应的目标支付结果的目标支付请求，将该目标支付请求确定为未完成支付，并将该目标支付请求存储到本地。

为了便于理解，如图2所示，为本说明书实施例提供的另一种支付结果获取方法的流程示意图。

该方法流程可以包括以下步骤。

S201：获取目标支付请求。

S202：判断是否满足预设循环停止条件，如果满足预设循环停止条件，则可以直接结束循环；如果不满足预设循环停止条件，则执行S203。

S203：针对目标支付请求，查询本地是否存储对应的目标支付结果；如果本地存储目标支付结果，则可以直接结束循环；如果本地没有存储目标支付结果，则执行S204。

S204：向支付渠道方发送查询请求，判断支付渠道方是否存储目标支付结果。查询请求可以用于查询支付渠道方是否存储目标支付结果。

如果支付渠道方存储目标支付结果，则可以执行S205；如果支付渠道方没有存储目标支付结果，则可以执行S202。

S205：将目标支付结果存储到本地，结束循环。

本方法流程的具体解释可以参见S101-S102的解释。

5、在一种可选的实施例中，将目标支付结果存储到本地，具体可以是将目标支付结果存储到本地数据库，也可以是将目标支付结果存储到本地的消息队列中。

可选地，为了提高目标支付结果的安全性，可以将目标支付结果存储到数据库中。数据库具体可以是业务方数据库，具体可以是业务方设备本地的数据库，也可以是业务方设备以外的数据库。

其中，为了提高支付请求的响应效率，由于数据库的写入可能受到多种因素的影响，因此，可以通过异步的方式，解耦支付请求的响应和数据库写入的过程。

可选地，可以在业务方设备本地设置本地消息队列，作为异步写库的容器，存储目标支付结果。消息队列例如，pulsar队列。

在将目标支付结果存储到业务方设备本地的消息队列后，可以认为目标支付结果已经存储到业务方设备本地，从而可以执行后续的支付流程，无需等待目标支付结果成功入库。

之后可以从消息队列中，将目标支付结果存储到数据库中，从而实现异步写库。

在本实施例中，可以通过异步写库，提高支付请求的响应效率，无需等待支付结果写库成功，从而可以降低数据库故障或写库繁忙等情况造成的延迟影响。

此外，通过异步写库，可以在数据库宕机或者故障的情况下，也能够将支付结果保存在消息队列中，从而可以在数据库恢复后，完成写库，提高写库操作的稳定性。

因此，可选地，将目标支付结果存储到本地，可以包括：将目标支付结果添加到本地的待写库消息队列中，并响应于目标支付请求，返回目标支付结果。

其中，可选地，待写库消息队列可以用于，将目标支付结果存储到数据库中。

本实施例并不限定响应支付请求返回支付结果的具体方式。

可选地，可以响应支付请求，向支付请求的发送方返回支付结果。具体可以是向发送支付请求的客户端返回支付结果，也可以是向发送支付请求的业务***返回支付结果，完成支付流程。

可选地，也可以响应支付请求，向相关业务***返回支付结果，从而可以将支付结果同步到业务方的其他业务***。例如，财务***、交易***等。

可选地，具体返回支付结果，可以是通过异步发送的方式进行返回。具体可以是将支付结果添加到异步队列中，再由异步队列发送到对应的***。

针对待写库消息队列，本方法流程并不限定具体的形式。只要利用待写库消息队列，实现支付结果的异步写库即可，可以提高支付请求的响应效率，降低数据库写入对支付请求响应的影响。

在一种可选的实施例中，业务方通常可以具有多种业务场景，也可以具有多种服务。因此，可选地，在数据库中可以设置多个数据表。

可选地，不同的数据表可以分别对应于不同的业务场景，或者不同的服务，从而可以方便数据管理。

当然，数据表具体对应的业务，可以根据实际需求确定。本实施例并不限定。

例如，餐厅1-4中订单的支付结果，可以分别对应于不同的数据表。餐饮服务和外卖服务可以分别对应于不同的数据表。

而对应于数据库中的不同数据表，可以在待写库消息队列中，设置对应的主题，从而可以通过主题，将需要写入不同数据表的不同支付结果区分开，也就可以提高写库的稳定性，不会因为某一数据表影响到其他数据表中数据的写库。

因此，可选地，待写库消息队列可以包括一个或多个消息队列主题；不同消息队列主题可以对应于数据库中的不同数据表。

可选地，将目标支付结果添加到本地的待写库消息队列中，包括：针对目标支付结果，确定对应的消息队列主题；根据所确定的消息队列主题，将目标支付结果添加到本地待写库消息队列中。

本实施例并不限定确定消息队列主题的方式，具体可以是根据支付结果中的业务相关信息确定，也可以是根据支付结果对应的支付请求所属业务信息确定。

可选地，待写库消息队列可以用于，针对目标支付结果对应的消息队列主题，确定对应的数据表；将目标支付结果存储到所确定的数据表中。

本实施例可以通过设置消息队列主题，将支付结果按照消息队列主题进行区分，从而可以将不同消息队列主题的支付结果，分别写入对应的数据表中，不同数据表的写入过程之间可以互不影响，从而可以提高写库的稳定性。

为了便于理解，如图3所示，为本说明书实施例提供的一种异步写库的原理示意图。

其中可以包括交易服务、支付核心服务、账务服务和其他服务，这些服务可以产生需要异步写库的数据，具体可以包括支付结果，也可以包括支付请求与支付结果的对应关系。

此外，各个服务可以为所产生的数据添加各自的消息队列主题，从而写入数据库中的不同数据表。

各个服务可以将所产生的数据写入pulsar队列，之后pulsar队列可以按照消息队列主题分别将其中的数据写入数据库中各个消息队列主题对应的数据表。具体可以是分别写入数据表1-4。

此外，在一种可选的实施例中，为了提高支付相关数据的稳定性和安全性，可以针对存储的支付数据，例如，支付请求和支付结果，以及账务数据和交易数据等进行比对检查。具体可以是周期性进行比对检查。

本实施例并不限定比对检查的方式。

可选地，比对检查可以是针对同一订单，确定支付数据中是否支付成功，账务数据中是否收到相应的支付金额，交易数据中是否完成该笔订单。

此外，针对比对检查出的数据区别，可以根据数据之间的关联进行自动补偿。

可选地，可以以支付数据为标准，在账务数据与支付数据不一致的情况下，补偿账务数据；在交易数据与支付数据不一致的情况下，补偿交易数据。

在一种具体的实施例中，可以在每天凌晨时，自动启动数据的比对程序，查询支付数据、账务数据和交易数据的不同，查询出不同后，如果数据符合预期范围，则进行自动的账务数据补偿操作。

补偿结束后，会将第一次比对的结果和补偿后再进行比对的结果通过邮件的方式发送给指定的业务人员，通过邮件可以确保每天的数据比对按照预期正在进行，并且可以了解哪一些数据发生了补偿。

综合上述步骤流程，为了便于理解，如图4所示，为本说明书实施例提供的另一种支付结果获取方法的流程示意图。

该方法可以包括以下步骤。

S301：获取目标支付请求。

S302：针对目标支付请求，查询本地是否存储对应的目标支付结果。

如果本地存储目标支付结果，就结束本方法流程。

如果本地没有存储目标支付结果，就执行步骤S303。

S303：向支付渠道方发送查询请求。

其中，查询请求可以用于查询支付渠道方是否存储目标支付结果。

S304：查询支付渠道方是否存储目标支付结果。

如果支付渠道方存储目标支付结果，可以执行步骤S305。

如果支付渠道方没有存储目标支付结果，可以执行步骤S307。

S305：从支付渠道方获取目标支付结果，并判断目标支付结果是否通过验证。

如果目标支付结果通过验证，则执行步骤S306。

如果目标支付结果没有通过验证，就执行S307。

S306：将目标支付结果存储到本地，结束本方法流程。

S307：将目标支付请求对应的循环次数增加1，并判断目标支付请求当前对应的循环次数是否超出预设循环次数。

如果目标支付请求当前对应的循环次数超出预设循环次数，则执行步骤S308。

如果目标支付请求当前对应的循环次数未超出预设循环次数，则执行步骤S309。

S308：确定目标支付请求支付未完成，并将目标支付请求存储到本地，结束本方法流程。

S309：等待第一预设时长之后，执行步骤S302。

此外，针对不同次数的循环之间的延时，本方法流程并不限定具体的延时方法。

在一种可选的实施例中，可以通过现有的延迟队列机制进行延时。

可选地，可以将目标支付请求添加到队列中，如果在本地和支付渠道方都没有查询到对应的目标支付结果，就可以将目标支付结果添加到延迟队列中。

延迟队列中的目标支付请求，可以在一定时长后，重新添加到原有队列中，重新查询对应的目标支付结果，从而可以实现不同次数循环之间的延时。

可选地，在目标支付请求添加多次延迟队列之后，可以将目标支付请求添加到死信队列，确定目标支付请求未完成支付。

可选地，可以将死信队列中的目标支付请求直接存储到本地，具体可以直接写库，也可以直接删除，也可以等待更长的时长后，继续查询目标支付结果。

如图5所示，为本说明书实施例提供的另一种支付结果获取方法的流程示意图。

该方法流程可以应用于业务方设备。

该方法流程可以包括以下步骤。

S401：获取支付请求，并将所获取的支付请求添加到待处理队列中。

S402：从待处理队列中获取支付请求，执行以下步骤：针对从待处理队列中获取的支付请求，查询本地是否存储对应的支付结果；在确定本地没有存储对应的支付结果的情况下，向支付渠道方发送查询请求；查询请求用于查询支付渠道方是否存储所针对的支付请求对应的支付结果；在确定支付渠道方存储所针对的支付请求对应的支付结果的情况下，将所确定的支付结果存储到本地；在确定支付渠道方没有存储所针对的支付请求对应的支付结果的情况下，将所针对的支付请求添加到延迟队列中。

S403：针对延迟队列中的支付请求，在添加到延迟队列的第二预设时长之后，将延迟队列中所针对的支付请求重新添加到待处理队列中。

在本方法流程中，并不限定步骤S401-S403之间的执行顺序，可以并行执行。具体可以实现流式处理，可以是由各个程序模块或者进程或者线程，分别执行S401-S403。

该方法流程的解释可以参见上述方法流程S101-S102的解释。

如图6所示，为本说明书实施例提供的另一种支付结果获取方法的流程示意图。

该方法流程可以应用于业务方设备。

该方法流程可以包括以下步骤。

S501：获取支付请求，并将所获取的支付请求添加到待处理队列中。

S502：从待处理队列中获取支付请求，执行以下步骤：针对从待处理队列中获取的支付请求，查询本地是否存储对应的支付结果；在确定本地没有存储对应的支付结果的情况下，向支付渠道方发送查询请求；查询请求用于查询支付渠道方是否存储所针对的支付请求对应的支付结果；在确定支付渠道方存储所针对的支付请求对应的支付结果的情况下，将所确定的支付结果存储到本地；在确定支付渠道方没有存储所针对的支付请求对应的支付结果，并且所针对的支付请求添加到延迟队列中的次数少于预设次数的情况下，将所针对的支付请求添加到延迟队列中；在确定支付渠道方没有存储所针对的支付请求对应的支付结果，并且所针对的支付请求添加到延迟队列中的次数不少于预设次数的情况下，将所针对的支付请求确定为未完成支付。

可选地，可以将未完成支付的支付请求存储到本地，也可以直接删除。本方法流程并不限定未完成支付的支付请求的处理方式。

S503：针对延迟队列中的支付请求，在添加到延迟队列的第二预设时长之后，将延迟队列中所针对的支付请求重新添加到待处理队列中。

其中，可选地，在确定支付渠道方没有存储该支付请求对应的支付结果，并且该支付请求添加到延迟队列中的次数不少于预设次数的情况下，可以将该支付请求添加到死信队列中。

可选地，针对死信队列中的支付请求，可以确定为未完成支付，并将该支付请求存储到本地；也可以重新循环针对死信队列中的支付请求，查询获取对应的支付结果。

在本方法流程中，并不限定步骤S501-S503之间的执行顺序，可以并行执行。具体可以实现流式处理，可以是由各个程序模块或者进程或者线程，分别执行S501-S503。

该方法流程的解释可以参见上述方法流程S101-S102的解释。

对应于上述方法实施例，本说明书实施例还提供了装置实施例。

如图7所示，为本说明书实施例提供的一种支付结果获取装置的结构示意图。该装置可以应用于业务方设备。

该装置可以包括以下单元。

获取单元601，用于获取目标支付请求；

循环单元602，用于循环执行以下步骤，直到满足预设循环停止条件：

针对目标支付请求，查询本地是否存储对应的目标支付结果；

在确定本地没有存储目标支付结果的情况下，向支付渠道方发送查询请求；查询请求用于查询支付渠道方是否存储目标支付结果；

在确定支付渠道方存储目标支付结果的情况下，将目标支付结果存储到本地，结束循环。

可选地，循环单元602，用于：

等待第一预设时长之后，针对目标支付请求，查询本地是否存储对应的目标支付结果。

可选地，循环单元602，用于：

在确定目标支付结果通过验证的情况下，将目标支付结果存储到本地。

可选地，确定目标支付结果通过验证，包括以下至少一项：

确定目标支付结果表征支付成功；

确定目标支付结果中的支付金额符合预设规则；

确定目标支付结果中的支付金额，与目标支付请求中的支付金额一致。

可选地，预设循环停止条件包括：循环次数大于预设次数；和/或循环耗时时长大于预设循环时长。

可选地，循环单元602，还用于：

在确定本地存储目标支付结果的情况下，结束循环；

本地存储的目标支付结果通过验证。

可选地，循环单元602，还用于：

循环结束后，针对未查询到对应的目标支付结果的目标支付请求，将目标支付请求确定为未完成支付，并将目标支付请求存储到本地。

可选地，循环单元602，用于：

将目标支付结果添加到本地的待写库消息队列中，并响应于目标支付请求，返回目标支付结果；

待写库消息队列用于，将目标支付结果存储到数据库中。

可选地，待写库消息队列包括一个或多个消息队列主题；不同消息队列主题对应于数据库中的不同数据表；

可选地，循环单元602，用于：针对目标支付结果，确定对应的消息队列主题；根据所确定的消息队列主题，将目标支付结果添加到本地待写库消息队列中；

待写库消息队列用于，针对目标支付结果对应的消息队列主题，确定对应的数据表；将目标支付结果存储到所确定的数据表中。

该装置实施例的解释可以参见上述方法实施例。

本说明书实施例还提供一种电子设备，包括：处理器；用于存储所述处理器可执行指令的存储器；其中，所述处理器被配置为执行所述指令，以实现上述任一方法实施例。

本说明书实施例还提供一种计算机可读存储介质，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够实现上述任一方法实施例。

本说明书实施例还提供一种计算机设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现一种支付结果获取方法。

图8示出了本说明书实施例所提供的一种更为具体的计算机设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。

处理器1010可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器1020可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作***和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。

输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现一种支付结果获取方法。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本说明书实施例可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本说明书实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本说明书实施例各个实施例或者实施例的某些部分所述的方法。

上述实施例阐明的***、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本说明书实施例方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅是本说明书实施例的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本说明书实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本说明书实施例的保护。

Claims

1.一种支付结果获取方法，其特征在于，包括：

获取目标支付请求；

循环执行以下步骤，直到满足预设循环停止条件：

2.根据权利要求1所述的方法，其特征在于，所述针对所述目标支付请求，查询本地是否存储对应的目标支付结果，包括：

3.根据权利要求1或2所述的方法，其特征在于，所述将所述目标支付结果存储到本地，包括：

4.根据权利要求3所述的方法，其特征在于，所述确定所述目标支付结果通过验证，包括以下至少一项：

确定所述目标支付结果表征支付成功；

确定所述目标支付结果中的支付金额符合预设规则；

5.根据权利要求1-2、4中任一项所述的方法，其特征在于，所述预设循环停止条件包括：循环次数大于预设次数；和/或

循环耗时时长大于预设循环时长。

6.根据权利要求1-2、4中任一项所述的方法，其特征在于，包括：

在确定本地存储所述目标支付结果的情况下，结束循环；

所述本地存储的所述目标支付结果通过验证。

7.根据权利要求1-2、4中任一项所述的方法，其特征在于，包括：

8.根据权利要求1-2、4中任一项所述的方法，其特征在于，所述将所述目标支付结果存储到本地，包括：

9.根据权利要求8所述的方法，其特征在于，所述待写库消息队列包括至少一个消息队列主题；不同消息队列主题对应于所述数据库中的不同数据表；

10.一种支付结果获取方法，其特征在于，包括：

获取支付请求，并将所获取的支付请求添加到待处理队列中；

从所述待处理队列中获取支付请求，执行以下步骤：

针对从所述待处理队列中获取的支付请求，查询本地是否存储对应的支付结果；

在确定本地没有存储对应的支付结果的情况下，向支付渠道方发送查询请求；所述查询请求用于查询所述支付渠道方是否存储所针对的支付请求对应的支付结果；

在确定所述支付渠道方存储所针对的支付请求对应的支付结果的情况下，将所确定的支付结果存储到本地；

在确定所述支付渠道方没有存储所针对的支付请求对应的支付结果的情况下，将所针对的支付请求添加到延迟队列中；

针对所述延迟队列中的支付请求，在添加到所述延迟队列的第二预设时长之后，将所述延迟队列中所针对的支付请求重新添加到所述待处理队列中。

11.一种支付结果获取方法，其特征在于，包括：

从所述待处理队列中获取支付请求，执行以下步骤：

在确定所述支付渠道方没有存储所针对的支付请求对应的支付结果，并且所针对的支付请求添加到延迟队列中的次数少于预设次数的情况下，将所针对的支付请求添加到所述延迟队列中；

在确定所述支付渠道方没有存储所针对的支付请求对应的支付结果，并且所针对的支付请求添加到延迟队列中的次数不少于预设次数的情况下，将所针对的支付请求确定为未完成支付；

12.一种支付结果获取装置，其特征在于，包括：

获取单元，用于获取目标支付请求；

13.根据权利要求12所述的装置，其特征在于，所述循环单元用于：

14.根据权利要求12或13所述的装置，其特征在于，所述循环单元用于：

15.根据权利要求12或13所述的装置，其特征在于，所述循环单元用于：

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

处理器；

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

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至11中任一项所述的方法。

17.一种计算机可读存储介质，其特征在于，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够实现如权利要求1至11中任一项所述的方法。