支付状态翻转方法、装置、电子设备及存储介质与流程

1.本发明涉及金融数据处理技术领域，尤其涉及一种支付状态翻转方法、装置、电子设备及存储介质。


背景技术：

2.支付状态代表了支付金额的去向，订单的后续操作都依赖这一前置操作，例如：支付状态为支付成功了才会安排发货及物流运输。在实际的支付系统里，支付都是设计成异步的，从支付到状态确认存在一定的时长，支付状态的及时翻转显得特别重要。
3.支付状态翻转是指的支付状态的确认，将支付状态由处理中翻转为支付成功或者支付失败，现有技术中支付状态翻转的方法包括：
4.方案一，业务系统起定时任务，每间隔一段时间主动查询支付系统支付状态，业务系统根据查询结果翻转支付状态。由于定时任务需要扫描出未确认支付状态的订单，并发送支付查询接口，为了不影响数据库性能，定时任务的频率往往都不会很高，因此订单状态确认的会比较慢，用户体验不好。而且由于支付表数据很多，定时任务找出处理中的支付单会比较慢，当任务较频繁时，数据库压力大。
5.方案二，支付系统确认支付状态后主动回调业务系统通知支付状态，业务根据通知结果翻转支付状态。但是支付系统的回调往往只有一次，在只依赖支付系统回调的情况下，若回调失败则会导致无法翻转支付状态。


技术实现要素：

6.本发明的目的在于提供一种支付状态翻转方法、装置、电子设备及存储介质，以解决现有技术中业务系统定时主动查询导致的支付状态翻转慢的技术问题及支付系统回调业务系统失败导致的支付状态无法翻转的技术问题。
7.本发明的技术方案如下：提供一种支付状态翻转方法，应用于第一服务器，包括：
8.获取第二服务器的订单支付信息，根据所述订单支付信息获取每个订单的查询信息；
9.将所述订单的查询信息发送至第三服务器以查询每个所述订单的支付状态，并接收所述第三服务器发送的所述订单的支付状态查询结果；若所述支付状态查询结果为处理中，则重新将所述订单的查询信息发送至所述第三服务器以查询对应的支付状态，直至所述订单的所述支付状态查询结果为支付成功/支付失败；若所述支付状态查询结果为支付成功/支付失败，则调用所述第二服务器的支付通知接口地址向所述第二服务器发送所述订单的支付状态查询结果；
10.接收所述第二服务器发送的支付状态通知反馈；若所述支付状态通知反馈为通知失败，则重新向所述第二服务器发送所述订单的支付状态查询结果，直至所述支付状态通知反馈为通知成功；若所述支付状态通知反馈为通知成功，则结束所述订单的翻转流程。
11.作为一个可选的实施方式，所述第一服务器包括支付状态查询生产者模块和支付
状态查询消费者模块；
12.相应地，将所述订单的查询信息发送至第三服务器以查询每个所述订单的支付状态，并接收所述第三服务器发送的所述订单的支付状态查询结果；若所述支付状态查询结果为处理中，则重新将所述订单的查询信息发送至所述第三服务器以查询对应的支付状态，直至所述订单的所述支付状态查询结果为支付成功/支付失败；若所述支付状态查询结果为支付成功/支付失败，则调用所述第二服务器的支付通知接口地址向所述第二服务器发送所述订单的支付状态查询结果，包括：
13.所述支付状态查询生产者模块根据所述订单的查询信息生成并发送订单的查询消息；所述支付状态查询消费者模块获取并解析所述支付状态查询生产者模块发送的所述订单的查询消息，得到所述订单的查询信息，将所述订单的查询信息发送至第三服务器查询所述订单的支付状态，并接收所述第三服务器发送的所述订单的支付状态查询结果；
14.若所述支付状态查询结果为处理中，则所述支付状态查询消费者模块调用所述支付状态查询生产者模块并将所述订单的查询信息发送给支付状态查询生产者模块；所述支付状态查询生产者模块根据所述支付状态查询消费者模块发送的所述订单的查询信息重新生成并发送订单的查询消息；所述支付状态查询消费者模块获取并解析所述支付状态查询生产者模块重新生成的所述订单的查询消息，得到所述订单的查询信息，重新将所述订单的查询信息发送至所述第三服务器查询所述订单的支付状态，直至所述支付状态查询结果为支付成功/支付失败；
15.若所述支付状态查询结果为支付成功/支付失败，则所述支付状态查询消费者模块调用所述第二服务器的支付通知接口地址向所述第二服务器发送所述订单的支付状态查询结果。
16.作为一个可选的实施方式，所述支付状态查询生产者模块根据所述订单的查询信息生成并发送订单的查询消息；所述支付状态查询消费者模块获取并解析所述支付状态查询生产者模块发送的所述订单的查询消息，得到所述订单的查询信息，将所述订单的查询信息发送至第三服务器查询所述订单的支付状态，并接收所述第三服务器发送的所述订单的支付状态查询结果，包括：
17.所述支付状态查询生产者模块将所述订单的查询消息发送至rocketmq；所述支付状态查询消费者模块从rocketmq获取并解析所述支付状态查询生产者模块发送的所述订单的查询消息，得到所述订单的查询信息，将所述订单的查询信息发送至第三服务器查询所述订单的支付状态，并接收所述第三服务器发送的所述订单的支付状态查询结果；
18.相应地，若所述支付状态查询结果为处理中，则所述支付状态查询消费者模块调用所述支付状态查询生产者模块并将所述订单的查询信息发送给支付状态查询生产者模块；所述支付状态查询生产者模块根据所述支付状态查询消费者模块发送的所述订单的查询信息重新生成并发送订单的查询消息；所述支付状态查询消费者模块获取并解析所述支付状态查询生产者模块重新生成的所述订单的查询消息，得到所述订单的查询信息，重新将所述订单的查询信息发送至所述第三服务器查询所述订单的支付状态，直至所述支付状态查询结果为支付成功/支付失败，包括：
19.若所述支付状态查询结果为处理中，则所述支付状态查询消费者模块直接调用所述支付状态查询生产者模块并将所述订单的查询信息发送给支付状态查询生产者模块；所
述支付状态查询生产者模块根据所述支付状态查询消费者模块发送的所述订单的查询信息重新生成订单的查询消息，并将重新生成的所述订单的查询消息发送至rocketmq；所述支付状态查询消费者模块从rocketmq获取并解析所述支付状态查询生产者模块重新生成的所述订单的查询消息，得到所述订单的查询信息，重新将所述订单的查询信息发送至第三服务器查询所述订单的支付状态，直至所述支付状态查询结果为支付成功/支付失败。
20.作为一个可选的实施方式，所述支付状态查询消费者模块从rocketmq获取并解析所述支付状态查询生产者模块发送的所述订单的查询消息，包括：
21.当rocketmq接收到所述支付状态查询生产者模块发送的所述订单的查询消息后，所述支付状态查询消费者模块延时1～5s从rocketmq获取并解析所述支付状态查询生产者模块发送的所述订单的查询消息；
22.相应地，所述支付状态查询消费者模块从rocketmq获取并解析所述支付状态查询生产者模块重新生成的所述订单的查询消息，包括：
23.当rocketmq接收到所述支付状态查询生产者模块重新生成的所述订单的查询消息后，所述支付状态查询消费者模块延时1～5s从rocketmq获取并解析所述支付状态查询生产者模块重新生成的所述订单的查询消息。
24.作为一个可选的实施方式，所述第一服务器还包括支付状态通知生产者模块和支付状态通知消费者模块；
25.相应地，所述接收所述第二服务器发送的支付状态通知反馈；若所述支付状态通知反馈为通知失败，则重新向所述第二服务器发送所述订单的支付状态查询结果，直至所述支付状态通知反馈为通知成功；若所述支付状态通知反馈为通知成功，则结束所述订单的翻转流程，包括：
26.所述支付状态查询消费者接收所述第二服务器发送的支付状态通知反馈；
27.若所述支付状态通知反馈为通知失败，则所述支付状态查询消费者模块调用所述支付状态通知生产者模块并将所述订单的查询信息和支付状态查询结果发送给所述支付状态通知生产者模块，所述支付状态通知生产者模块根据所述支付状态查询消费者模块发送的所述订单的查询信息和支付状态查询结果生成并发送支付状态通知消息，所述支付状态通知消费者模块获取并解析所述支付状态通知生产者模块发送的所述支付状态通知消息，得到所述订单的查询信息和支付状态查询结果，向所述第二服务器发送所述订单的支付状态查询结果，并接收所述第二服务器发送的支付状态通知反馈；若所述支付状态通知反馈为通知失败，则所述支付状态通知消费者模块调用所述支付状态通知生产者模块并将所述订单的查询信息和支付状态查询结果发送给所述支付状态通知生产者模块，所述支付状态通知生产者模块根据所述支付状态通知消费者模块发送的所述订单的查询信息和支付状态查询结果重新生成并发送支付状态通知消息，所述支付状态通知消费者模块获取并解析所述支付状态通知生产者模块重新生成的所述支付状态通知消息，得到所述订单的查询信息和支付状态查询结果，重新向所述第二服务器发送所述订单的支付状态查询结果，直至所述支付状态通知反馈为通知成功；
28.若所述支付状态通知反馈为通知成功，则结束所述订单的翻转流程。
29.作为一个可选的实施方式，所述支付状态查询消费者模块调用所述支付状态通知生产者模块并将所述订单的查询信息和支付状态查询结果发送给所述支付状态通知生产
者模块，所述支付状态通知生产者模块根据所述支付状态查询消费者模块发送的所述订单的查询信息和支付状态查询结果生成并发送支付状态通知消息，所述支付状态通知消费者模块获取并解析所述支付状态通知生产者模块发送的所述支付状态通知消息，得到所述订单的查询信息和支付状态查询结果，向所述第二服务器发送所述订单的支付状态查询结果，并接收所述第二服务器发送的支付状态通知反馈；若所述支付状态通知反馈为通知失败，则所述支付状态通知消费者模块调用所述支付状态通知生产者模块并将所述订单的查询信息和支付状态查询结果发送给所述支付状态通知生产者模块，所述支付状态通知生产者模块根据所述支付状态通知消费者模块发送的所述订单的查询信息和支付状态查询结果重新生成并发送支付状态通知消息，所述支付状态通知消费者模块获取并解析所述支付状态通知生产者模块重新生成的所述支付状态通知消息，得到所述订单的查询信息和支付状态查询结果，重新向所述第二服务器发送所述订单的支付状态查询结果，直至所述支付状态通知反馈为通知成功，包括：
30.所述支付状态查询消费者模块直接调用所述支付状态通知生产者模块并将所述订单的查询信息和支付状态查询结果发送给所述支付状态通知生产者模块，所述支付状态通知生产者模块根据所述支付状态查询消费者模块发送的所述订单的查询信息和支付状态查询结果生成支付状态通知消息，并将所述支付状态通知消息发送至rocketmq，所述支付状态通知消费者模块从rocketmq获取并解析所述支付状态通知生产者模块发送的所述支付状态通知消息，得到所述订单的查询信息和支付状态查询结果，向所述第二服务器发送所述订单的支付状态查询结果，并接收所述第二服务器发送的支付状态通知反馈；若所述支付状态通知反馈为通知失败，则所述支付状态通知消费者模块直接调用所述支付状态通知生产者模块并将所述订单的查询信息和支付状态查询结果发送给所述支付状态通知生产者模块，所述支付状态通知生产者模块根据所述支付状态通知消费者模块发送的所述订单的查询信息和支付状态查询结果重新生成支付状态通知消息，并将重新生成的所述支付状态通知消息发送至rocketmq，所述支付状态通知消费者模块从rocketmq获取并解析所述支付状态通知生产者模块重新生成的所述支付状态通知消息，得到所述订单的查询信息和支付状态查询结果，并重新向所述第二服务器发送所述订单的支付状态查询结果，直至所述支付状态通知反馈为通知成功。
31.作为一个可选的实施方式，所述支付状态通知消费者模块从rocketmq获取并解析所述支付状态通知生产者模块发送的所述支付状态通知消息，包括：
32.当rocketmq接收到所述支付状态通知生产者模块发送的所述支付状态通知消息后，所述支付状态通知消费者模块延时1～5s从rocketmq获取并解析所述支付状态通知生产者模块发送的所述支付状态通知消息；
33.相应地，所述支付状态通知消费者模块从rocketmq获取并解析所述支付状态通知生产者模块重新生成的所述支付状态通知消息，包括：
34.当rocketmq接收到所述支付状态通知生产者模块重新生成的所述支付状态通知消息后，所述支付状态通知消费者模块延时1～5s从rocketmq获取并解析所述支付状态通知生产者模块重新生成的所述支付状态通知消息。
35.本发明的另一技术方案如下：提供一种支付状态翻转装置，应用于第一服务器，包括：
36.查询消息获取模块，用于获取第二服务器的订单支付信息，根据所述订单支付信息获取每个订单的查询信息；
37.支付状态查询模块，用于将所述订单的查询信息发送至第三服务器以查询每个所述订单的支付状态，并接收所述第三服务器发送的所述订单的支付状态查询结果；若所述支付状态查询结果为处理中，则重新将所述订单的查询信息发送至所述第三服务器以查询对应的支付状态，直至所述订单的所述支付状态查询结果为支付成功/支付失败；若所述支付状态查询结果为支付成功/支付失败，则调用所述第二服务器的支付通知接口地址向所述第二服务器发送所述订单的支付状态查询结果；
38.支付状态通知模块，用于接收所述第二服务器发送的支付状态通知反馈；若所述支付状态通知反馈为通知失败，则重新向所述第二服务器发送所述订单的支付状态查询结果，直至所述支付状态通知反馈为通知成功；若所述支付状态通知反馈为通知成功，则结束所述订单的翻转流程。
39.本发明的另一技术方案如下：提供一种电子设备，包括处理器、以及与所述处理器耦接的存储器，所述存储器存储有可被所述处理器执行的程序指令；所述处理器执行所述存储器存储的所述程序指令时实现上述的支付状态翻转方法。
40.本发明的另一技术方案如下：提供一种存储介质，所述存储介质内存储有程序指令，所述程序指令被处理器执行时实现上述的支付状态翻转方法。
41.本发明的支付状态翻转方法、装置、电子设备及存储介质，获取第二服务器的订单支付信息，根据所述订单支付信息获取每个订单的查询信息；将所述订单的查询信息发送至第三服务器以查询每个所述订单的支付状态，并接收所述第三服务器发送的所述订单的支付状态查询结果；若所述支付状态查询结果为处理中，则重新将所述订单的查询信息发送至所述第三服务器以查询对应的支付状态，直至所述订单的所述支付状态查询结果为支付成功/支付失败；若所述支付状态查询结果为支付成功/支付失败，则调用所述第二服务器的支付通知接口地址向所述第二服务器发送所述订单的支付状态查询结果；接收所述第二服务器发送的支付状态通知反馈；若所述支付状态通知反馈为通知失败，则重新向所述第二服务器发送所述订单的支付状态查询结果，直至所述支付状态通知反馈为通知成功；若所述支付状态通知反馈为通知成功，则结束所述订单的翻转流程；通过上述方式，可以多次查询订单支付状态，直至订单的支付状态由处理中变成支付成功或者支付失败，能及时有效地获知订单支付状态的改变，并且可以多次通知订单支付状态，直至支付状态通知反馈为通知成功，保证业务系统能及时、有效地根据通知翻转支付状态，解决了现有技术中业务系统定时主动查询导致的支付状态翻转慢的技术问题及支付系统回调业务系统失败导致的支付状态无法翻转的技术问题。
附图说明
42.图1为本发明第一实施例的支付状态翻转方法的应用场景图；
43.图2为本发明第一实施例的支付状态翻转方法的流程示意图；
44.图3为本发明第二实施例的支付状态翻转装置的结构示意图；
45.图4为本发明第三实施例的电子设备的结构示意图；
46.图5为本发明第四实施例的存储介质的结构示意图。
具体实施方式
47.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
48.本发明中的术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”、“第三”的特征可以明示或者隐含地包括至少一个该特征。本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。本发明实施例中所有方向性指示(诸如上、下、左、右、前、后
……
)仅用于解释在某一特定姿态(如附图所示)下各部件之间的相对位置关系、运动情况等，如果该特定姿态发生改变时，则该方向性指示也相应地随之改变。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
49.在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本发明的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。
50.本发明提供的支付状态翻转方法，可以应用在如图1的应用环境中，其中，第一服务器100为钱包系统，第二服务器200为业务系统，第三服务器300为支付系统。用户在第二服务器200完成付款操作后，例如输入密码并点击确定后，第一服务器100收到第二服务器200的支付请求，并获取第二服务器200的订单支付信息以及订单的支付通知接口地址，第一服务器100根据所述订单支付信息生成订单的查询信息，然后第一服务器100调用第三服务器300查询相应订单的支付状态，第三服务器300将查询结果返回给第一服务器100。如果订单的支付状态查询结果为处理中，第一服务器100则继续调用第三服务器300查询相应订单的支付状态，直至订单的支付状态查询结果为支付成功或者支付失败。如果订单的支付状态查询结果为支付成功或者支付失败，则第一服务器100调用第二服务器200的支付通知接口地址向第二服务器200通知相应订单的支付状态查询结果。通知完成后，第二服务器200向第一服务器100发送支付状态通知反馈，告知第一服务器100通知成功或者通知失败。如果支付状态通知反馈为通知失败，第一服务器100则重新向所述第二服务器200发送订单的支付状态查询结果，直至支付状态通知反馈为通知成功。如果支付状态通知反馈为通知成功，则结束所述订单的翻转流程。
51.以下以第一服务器为执行主体，对本技术实施例提供的支付状态翻转方法进行解释。
52.图2是本发明第一实施例的支付状态翻转方法的流程示意图。需注意的是，若有实质上相同的结果，本发明的支付状态翻转方法并不以图2所示的流程顺序为限。如图2所示，提供一种支付状态翻转方法，以该方法应用在图1中的第一服务器为例进行说明，包括步骤s101至s103：
53.s101，获取第二服务器的订单支付信息，根据所述订单支付信息获取每个订单的查询信息。
54.本实施例中，第二服务器完成支付操作后，第一服务器收到第二服务器的支付请求，并获取第二服务器的订单支付信息以及订单的支付通知接口地址，然后第一服务器根据订单支付信息获取订单的查询信息，其中订单支付信息包括订单的支付流水号，订单的查询信息为订单的支付流水号。
55.s102，将所述订单的查询信息发送至第三服务器以查询每个所述订单的支付状态，并接收所述第三服务器发送的所述订单的支付状态查询结果；若所述支付状态查询结果为处理中，则重新将所述订单的查询信息发送至所述第三服务器以查询对应的支付状态，直至所述订单的所述支付状态查询结果为支付成功/支付失败；若所述支付状态查询结果为支付成功/支付失败，则调用所述第二服务器的支付通知接口地址向所述第二服务器发送所述订单的支付状态查询结果。
56.在一些优选的实施方式中，所述第一服务器包括支付状态查询生产者模块和支付状态查询消费者模块。
57.相应地，步骤s102具体包括步骤s201至s203：
58.s201，所述支付状态查询生产者模块根据所述订单的查询信息生成订单的查询消息并发送所述订单的查询消息；所述支付状态查询消费者模块获取并解析所述支付状态查询生产者模块发送的所述订单的查询消息，得到所述订单的查询信息，将所述订单的查询信息发送至第三服务器查询所述订单的支付状态，并接收所述第三服务器发送的所述订单的支付状态查询结果。
59.在一些具体的实施方式中，订单的查询消息至少包括topic(主题)和订单的查询信息，其中订单的查询信息为订单的支付流水号。在一个更具体的实施例中，订单查询消息中的topic为：“topic_pap_wallet_pay_status”。
60.在一些具体的实施方式中，步骤s201具体包括：所述支付状态查询生产者模块将所述订单的查询消息发送至rocketmq；所述支付状态查询消费者模块从rocketmq获取并解析所述支付状态查询生产者模块发送的所述订单的查询消息，得到所述订单的查询信息，将所述订单的查询信息发送至第三服务器查询所述订单的支付状态，并接收所述第三服务器发送的所述订单的支付状态查询结果。
61.现有技术中，由于支付表数据很大，高频率扫描会致使系统和数据库压力大、影像数据库性能，因此定时任务最快只能每30秒扫描一次支付表，扫描出未确认支付状态的订单，导致订单支付状态翻转慢、用户体验感差。在一些更优选的实施方式中，为了避免太频繁地发送消息导致系统压力大，同时为了保证能及时翻转订单的支付状态，优化用户体验感，所述支付状态查询消费者模块从rocketmq获取并解析所述支付状态查询生产者模块发送的所述订单的查询消息，包括：
62.当rocketmq接收到所述支付状态查询生产者模块发送的所述订单的查询消息后，所述支付状态查询消费者模块延时1～5s从rocketmq获取并解析所述支付状态查询生产者模块发送的所述订单的查询消息。
63.在一个最优选的实施例中，当rocketmq接收到所述支付状态查询生产者模块发送的所述订单的查询消息后，所述支付状态查询消费者模块延时2s从rocketmq获取并解析所
述支付状态查询生产者模块发送的所述订单的查询消息。
64.s202，若所述支付状态查询结果为处理中，则所述支付状态查询消费者模块调用所述支付状态查询生产者模块并将所述订单的查询信息发送给支付状态查询生产者模块；所述支付状态查询生产者模块根据所述支付状态查询消费者模块发送的所述订单的查询信息重新生成并发送订单的查询消息；所述支付状态查询消费者模块获取并解析所述支付状态查询生产者模块重新生成的所述订单的查询消息，得到所述订单的查询信息，重新将所述订单的查询信息发送至所述第三服务器查询所述订单的支付状态，直至所述支付状态查询结果为支付成功/支付失败。
65.在一些具体的实施方式中，步骤s202具体包括：若所述支付状态查询结果为处理中，则所述支付状态查询消费者模块结束当前订单支付状态的查询流程，支付状态查询消费者模块直接调用所述支付状态查询生产者模块并将该订单的查询信息发送给支付状态查询生产者模块，开始新的针对该订单支付状态的查询流程。所述支付状态查询生产者模块根据所述支付状态查询消费者模块发送的所述订单的查询信息重新生成订单的查询消息，并将重新生成的所述订单的查询消息发送至rocketmq，所述支付状态查询消费者模块从rocketmq获取并解析所述支付状态查询生产者模块重新生成的所述订单的查询消息，得到所述订单的查询信息，支付状态查询消费者模块重新将所述订单的查询信息发送至第三服务器查询所述订单的支付状态，直至所述支付状态查询结果为支付成功/支付失败。例如，若订单a的支付状态查询结果为处理中，则支付状态查询消费者模块结束当前查询订单a支付状态的查询流程，并且，支付状态查询消费者模块直接调用支付状态查询生产者模块并将订单a的支付流水号发送给支付状态查询生产者模块，开始新的查询订单a支付状态的查询流程。新的查询订单a支付状态的查询流程为：支付状态查询生产者模块根据支付状态查询消费者模块发送的订单a的支付流水号重新生成订单的查询消息，并将重新生成的订单的查询消息发送至rocketmq，支付状态查询消费者模块从rocketmq获取并解析支付状态查询生产者模块重新生成的订单的查询消息，得到订单a的支付流水号，支付状态查询消费者模块重新将订单a的支付流水号发送至第三服务器查询订单a的支付状态。如此循环，直至订单a的支付状态查询结果为支付成功或者支付失败。每次循环都开启新的查询流程，发送重新生成的查询消息，避免了特殊情况下超过mq重试上限后的消息丢失情况。
66.在一些更优选的实施方式中，为了避免太频繁地发送消息导致系统压力大，同时为了保证能及时翻转订单的支付状态，优化用户体验感，所述支付状态查询消费者模块从rocketmq获取并解析所述支付状态查询生产者模块重新生成的所述订单的查询消息，包括：
67.当rocketmq接收到所述支付状态查询生产者模块重新生成的所述订单的查询消息后，所述支付状态查询消费者模块延时1～5s从rocketmq获取并解析所述支付状态查询生产者模块重新生成的所述订单的查询消息。
68.在一个最优选的实施例中，当rocketmq接收到所述支付状态查询生产者模块重新生成的所述订单的查询消息后，所述支付状态查询消费者模块延时2s从rocketmq获取并解析所述支付状态查询生产者模块重新生成的所述订单的查询消息。
69.s203，若所述支付状态查询结果为支付成功/支付失败，则所述支付状态查询消费者模块调用所述第二服务器的支付通知接口地址向所述第二服务器发送所述订单的支付
状态查询结果。
70.s103，接收所述第二服务器发送的支付状态通知反馈；若所述支付状态通知反馈为通知失败，则重新向所述第二服务器发送所述订单的支付状态查询结果，直至所述支付状态通知反馈为通知成功；若所述支付状态通知反馈为通知成功，则结束所述订单的翻转流程。
71.在一些优选的实施方式中，所述第一服务器还包括支付状态通知生产者模块和支付状态通知消费者模块。
72.相应地，步骤s103具体包括步骤s301至s303：
73.s301，所述支付状态查询消费者接收所述第二服务器发送的支付状态通知反馈。
74.在一些更具体的实施方式中，第二服务器发送的支付状态通知反馈为响应码。例如，通知成功的响应码为100，通知失败的响应码为200。
75.s302，若所述支付状态通知反馈为通知失败，则所述支付状态查询消费者模块调用所述支付状态通知生产者模块并将所述订单的查询信息和支付状态查询结果发送给所述支付状态通知生产者模块，所述支付状态通知生产者模块根据所述支付状态查询消费者模块发送的所述订单的查询信息和支付状态查询结果生成并发送支付状态通知消息，所述支付状态通知消费者模块获取并解析所述支付状态通知生产者模块发送的所述支付状态通知消息，得到所述订单的查询信息和支付状态查询结果，向所述第二服务器发送所述订单的支付状态查询结果，并接收所述第二服务器发送的支付状态通知反馈；若所述支付状态通知反馈为通知失败，则所述支付状态通知消费者模块调用所述支付状态通知生产者模块并将所述订单的查询信息和支付状态查询结果发送给所述支付状态通知生产者模块，所述支付状态通知生产者模块根据所述支付状态通知消费者模块发送的所述订单的查询信息和支付状态查询结果重新生成并发送支付状态通知消息，所述支付状态通知消费者模块获取并解析所述支付状态通知生产者模块重新生成的所述支付状态通知消息，得到所述订单的查询信息和支付状态查询结果，重新向所述第二服务器发送所述订单的支付状态查询结果，直至所述支付状态通知反馈为通知成功。
76.在一些具体的实施方式中，支付状态通知消息至少包括topic(主题)、订单的查询信息和支付状态查询结果，其中订单的查询信息为订单的支付流水号。在一个更具体的实施例中，订单查询消息中的topic为：“topic_pap_wallet_pay_notify”。
77.在一些具体的实施方式中，步骤s302中，所述支付状态查询消费者模块调用所述支付状态通知生产者模块并将所述订单的查询信息和支付状态查询结果发送给所述支付状态通知生产者模块，所述支付状态通知生产者模块根据所述支付状态查询消费者模块发送的所述订单的查询信息和支付状态查询结果生成并发送支付状态通知消息，所述支付状态通知消费者模块获取并解析所述支付状态通知生产者模块发送的所述支付状态通知消息，得到所述订单的查询信息和支付状态查询结果，向所述第二服务器发送所述订单的支付状态查询结果，并接收所述第二服务器发送的支付状态通知反馈；若所述支付状态通知反馈为通知失败，则所述支付状态通知消费者模块调用所述支付状态通知生产者模块并将所述订单的查询信息和支付状态查询结果发送给所述支付状态通知生产者模块，所述支付状态通知生产者模块根据所述支付状态通知消费者模块发送的所述订单的查询信息和支付状态查询结果重新生成并发送支付状态通知消息，所述支付状态通知消费者模块获取并
解析所述支付状态通知生产者模块重新生成的所述支付状态通知消息，得到所述订单的查询信息和支付状态查询结果，重新向所述第二服务器发送所述订单的支付状态查询结果，直至所述支付状态通知反馈为通知成功，包括：
78.所述支付状态查询消费者模块直接调用所述支付状态通知生产者模块并将所述订单的查询信息和支付状态查询结果发送给所述支付状态通知生产者模块，所述支付状态通知生产者模块根据所述支付状态查询消费者模块发送的所述订单的查询信息和支付状态查询结果生成支付状态通知消息，并将所述支付状态通知消息发送至rocketmq。所述支付状态通知消费者模块从rocketmq获取并解析所述支付状态通知生产者模块发送的所述支付状态通知消息，得到所述订单的查询信息和支付状态查询结果，向所述第二服务器发送所述订单的支付状态查询结果，并接收所述第二服务器发送的支付状态通知反馈。若所述支付状态通知反馈为通知失败，则所述支付状态通知消费者模块结束当前订单支付状态的通知流程，支付状态通知消费者模块直接调用所述支付状态通知生产者模块并将所述订单的查询信息和支付状态查询结果发送给所述支付状态通知生产者模块，开始新的针对该订单支付状态的通知流程。所述支付状态通知生产者模块根据所述支付状态通知消费者模块发送的所述订单的查询信息和支付状态查询结果重新生成支付状态通知消息，并将重新生成的所述支付状态通知消息发送至rocketmq，所述支付状态通知消费者模块从rocketmq获取并解析所述支付状态通知生产者模块重新生成的所述支付状态通知消息，得到所述订单的查询信息和支付状态查询结果，并重新向所述第二服务器发送所述订单的支付状态查询结果，直至所述支付状态通知反馈为通知成功。例如，支付状态通知消费者模块向第二服务器发送订单a的支付状态查询结果后，第二服务器发送的支付状态通知反馈为响应码200，则说明通知失败。支付状态通知消费者模块结束当前通知订单a支付状态的通知流程，并且，支付状态通知消费者模块直接调用所述支付状态通知生产者模块并将订单a的支付流水号和订单a的支付状态查询结果发送给支付状态通知生产者模块，开始新的通知订单a支付状态的通知流程。新的通知订单a支付状态的通知流程为：支付状态通知生产者模块根据支付状态通知消费者模块发送的订单a的支付流水号和订单a的支付状态查询结果重新生成支付状态通知消息，并将重新生成的支付状态通知消息发送至rocketmq，支付状态通知消费者模块从rocketmq获取并解析支付状态通知生产者模块重新生成的支付状态通知消息，得到订单a的支付流水号和订单a的支付状态查询结果，并重新向所述第二服务器发送订单a的支付状态查询结果。如此循环，直至第二服务器发送的支付状态通知反馈为响应码100，即订单a的支付状态通知成功。每次循环都开启新的通知流程，发送重新生成的通知消息，确保了通知异常情况下的重试机制，避免了特殊情况下超过mq重试上限后的消息丢失情况。
79.在一些更优选的实施方式中，为了避免太频繁地发送消息导致系统压力大，同时为了保证能及时翻转订单的支付状态，优化用户体验感，所述支付状态通知消费者模块从rocketmq获取并解析所述支付状态通知生产者模块发送的所述支付状态通知消息，包括：
80.当rocketmq接收到所述支付状态通知生产者模块发送的所述支付状态通知消息后，所述支付状态通知消费者模块延时1～5s从rocketmq获取并解析所述支付状态通知生产者模块发送的所述支付状态通知消息。
81.在一个最优选的实施例中，当rocketmq接收到所述支付状态通知生产者模块发送
的所述支付状态通知消息后，所述支付状态通知消费者模块延时2s从rocketmq获取并解析所述支付状态通知生产者模块发送的所述支付状态通知消息。
82.相应地，在一些更优选的实施方式中，为了避免太频繁地发送消息导致系统压力大，同时为了保证能及时翻转订单的支付状态，优化用户体验感，所述支付状态通知消费者模块从rocketmq获取并解析所述支付状态通知生产者模块重新生成的所述支付状态通知消息，包括：
83.当rocketmq接收到所述支付状态通知生产者模块重新生成的所述支付状态通知消息后，所述支付状态通知消费者模块延时1～5s从rocketmq获取并解析所述支付状态通知生产者模块重新生成的所述支付状态通知消息。
84.在一个最优选的实施例中，当rocketmq接收到所述支付状态通知生产者模块重新生成的所述支付状态通知消息后，所述支付状态通知消费者模块延时2s从rocketmq获取并解析所述支付状态通知生产者模块重新生成的所述支付状态通知消息。
85.s303，若所述支付状态通知反馈为通知成功，则结束所述订单的翻转流程。
86.本实施例中，若所述支付状态通知反馈为通知成功，则说明第二服务器已成功收到支付状态查询结果，第二服务器根据收到的支付状态查询结果翻转相应订单的支付状态，即第二服务器根据收到的支付状态查询结果将订单的支付状态由处理中翻转为支付成功或者支付失败，该订单翻转流程结束。
87.本实施例中，可以多次查询订单支付状态，直至订单的支付状态由处理中变成支付成功或者支付失败，能及时有效地获知订单支付状态的改变，并且可以多次通知订单支付状态，直至支付状态通知反馈为通知成功，不仅稳定性高，而且时效快，能确保通知异常情况下的重试机制，避免了特殊情况下超过mq重试上限后的消息丢失情况，保证业务系统能及时、有效地根据通知翻转支付状态，解决了现有技术中业务系统定时主动查询导致的支付状态翻转慢的技术问题及支付系统回调业务系统失败导致的支付状态无法翻转的技术问题。
88.图3是本发明第二实施例的支付状态翻转装置的结构示意图。该支付状态翻转装置20与上述实施例中支付状态翻转方法一一对应。如图3所示，该支付状态翻转装置20包括查询消息获取模块21、支付状态查询模块22以及支付状态通知模块23，其中，查询消息获取模块21用于获取第二服务器的订单支付信息，根据所述订单支付信息获取每个订单的查询信息。支付状态查询模块22用于将所述订单的查询信息发送至第三服务器以查询每个所述订单的支付状态，并接收所述第三服务器发送的所述订单的支付状态查询结果；若所述支付状态查询结果为处理中，则重新将所述订单的查询信息发送至所述第三服务器以查询对应的支付状态，直至所述订单的所述支付状态查询结果为支付成功/支付失败；若所述支付状态查询结果为支付成功/支付失败，则调用所述第二服务器的支付通知接口地址向所述第二服务器发送所述订单的支付状态查询结果。支付状态通知模块23用于接收所述第二服务器发送的支付状态通知反馈；若所述支付状态通知反馈为通知失败，则重新向所述第二服务器发送所述订单的支付状态查询结果，直至所述支付状态通知反馈为通知成功；若所述支付状态通知反馈为通知成功，则结束所述订单的翻转流程。
89.图4是本发明第三实施例的电子设备的结构示意图。如图4所示，该电子设备30包括处理器31及和处理器31耦接的存储器32。存储器32存储有用于实现上述任一实施例的所
述支付状态翻转方法的程序指令。处理器31执行存储器32存储的程序指令时实现上述实施例中支付状态翻转方法的步骤。例如图2所示的步骤s101至步骤s103，及该方法的其它扩展和相关步骤的延伸。或者，处理器31执行存储器32存储的程序指令时实现上述实施例中支付状态翻转装置的各模块/单元的功能，例如图3所示查询消息获取模块21、支付状态查询模块22以及支付状态通知模块23的功能。为避免重复，这里不再赘述。
90.所述处理器可以是中央处理单元(central processing unit，cpu)，还可以是其他通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现成可编程门阵列(field-programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，所述处理器是所述计算机装置的控制中心，利用各种接口和线路连接整个计算机装置的各个部分。
91.所述存储器可用于存储所述计算机程序和/或模块，所述处理器通过运行或执行存储在所述存储器内的计算机程序和/或模块，以及调用存储在存储器内的数据，实现所述计算机装置的各种功能。所述存储器可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、视频数据等)等。
92.所述存储器可以集成在所述处理器中，也可以与所述处理器分开设置。
93.参阅图5，图5为本发明第四实施例的存储介质的结构示意图。本发明实施例的存储介质40存储有能够实现上述所有方法的程序指令41，程序指令41被处理器执行时实现上述实施例中支付状态翻转方法的步骤。例如图2所示的步骤s101至步骤s103，及该方法的其它扩展和相关步骤的延伸。或者，程序指令41被处理器执行时实现上述实施例中支付状态翻转装置的各模块/单元的功能，例如图3所示查询消息获取模块21、支付状态查询模块22以及支付状态通知模块23的功能。为避免重复，这里不再赘述。
94.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。
95.在本发明所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或
通信连接，可以是电性，机械或其它的形式。
96.另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。以上仅为本发明的实施方式，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围。
97.以上所述的仅是本发明的实施方式，在此应当指出，对于本领域的普通技术人员来说，在不脱离本发明创造构思的前提下，还可以做出改进，但这些均属于本发明的保护范围。

技术特征：
1.一种支付状态翻转方法，应用于第一服务器，其特征在于，包括：获取第二服务器的订单支付信息，根据所述订单支付信息获取每个订单的查询信息；将所述订单的查询信息发送至第三服务器以查询每个所述订单的支付状态，并接收所述第三服务器发送的所述订单的支付状态查询结果；若所述支付状态查询结果为处理中，则重新将所述订单的查询信息发送至所述第三服务器以查询对应的支付状态，直至所述订单的所述支付状态查询结果为支付成功/支付失败；若所述支付状态查询结果为支付成功/支付失败，则调用所述第二服务器的支付通知接口地址向所述第二服务器发送所述订单的支付状态查询结果；接收所述第二服务器发送的支付状态通知反馈；若所述支付状态通知反馈为通知失败，则重新向所述第二服务器发送所述订单的支付状态查询结果，直至所述支付状态通知反馈为通知成功；若所述支付状态通知反馈为通知成功，则结束所述订单的翻转流程。2.根据权利要求1所述的支付状态翻转方法，其特征在于，所述第一服务器包括支付状态查询生产者模块和支付状态查询消费者模块；相应地，将所述订单的查询信息发送至第三服务器以查询每个所述订单的支付状态，并接收所述第三服务器发送的所述订单的支付状态查询结果；若所述支付状态查询结果为处理中，则重新将所述订单的查询信息发送至所述第三服务器以查询对应的支付状态，直至所述订单的所述支付状态查询结果为支付成功/支付失败；若所述支付状态查询结果为支付成功/支付失败，则调用所述第二服务器的支付通知接口地址向所述第二服务器发送所述订单的支付状态查询结果，包括：所述支付状态查询生产者模块根据所述订单的查询信息生成并发送订单的查询消息；所述支付状态查询消费者模块获取并解析所述支付状态查询生产者模块发送的所述订单的查询消息，得到所述订单的查询信息，将所述订单的查询信息发送至第三服务器查询所述订单的支付状态，并接收所述第三服务器发送的所述订单的支付状态查询结果；若所述支付状态查询结果为处理中，则所述支付状态查询消费者模块调用所述支付状态查询生产者模块并将所述订单的查询信息发送给支付状态查询生产者模块；所述支付状态查询生产者模块根据所述支付状态查询消费者模块发送的所述订单的查询信息重新生成并发送订单的查询消息；所述支付状态查询消费者模块获取并解析所述支付状态查询生产者模块重新生成的所述订单的查询消息，得到所述订单的查询信息，重新将所述订单的查询信息发送至所述第三服务器查询所述订单的支付状态，直至所述支付状态查询结果为支付成功/支付失败；若所述支付状态查询结果为支付成功/支付失败，则所述支付状态查询消费者模块调用所述第二服务器的支付通知接口地址向所述第二服务器发送所述订单的支付状态查询结果。3.根据权利要求2所述的支付状态翻转方法，其特征在于，所述支付状态查询生产者模块根据所述订单的查询信息生成并发送订单的查询消息；所述支付状态查询消费者模块获取并解析所述支付状态查询生产者模块发送的所述订单的查询消息，得到所述订单的查询信息，将所述订单的查询信息发送至第三服务器查询所述订单的支付状态，并接收所述第三服务器发送的所述订单的支付状态查询结果，包括：所述支付状态查询生产者模块将所述订单的查询消息发送至rocketmq；所述支付状态
查询消费者模块从rocketmq获取并解析所述支付状态查询生产者模块发送的所述订单的查询消息，得到所述订单的查询信息，将所述订单的查询信息发送至第三服务器查询所述订单的支付状态，并接收所述第三服务器发送的所述订单的支付状态查询结果；相应地，若所述支付状态查询结果为处理中，则所述支付状态查询消费者模块调用所述支付状态查询生产者模块并将所述订单的查询信息发送给支付状态查询生产者模块；所述支付状态查询生产者模块根据所述支付状态查询消费者模块发送的所述订单的查询信息重新生成并发送订单的查询消息；所述支付状态查询消费者模块获取并解析所述支付状态查询生产者模块重新生成的所述订单的查询消息，得到所述订单的查询信息，重新将所述订单的查询信息发送至所述第三服务器查询所述订单的支付状态，直至所述支付状态查询结果为支付成功/支付失败，包括：若所述支付状态查询结果为处理中，则所述支付状态查询消费者模块直接调用所述支付状态查询生产者模块并将所述订单的查询信息发送给支付状态查询生产者模块；所述支付状态查询生产者模块根据所述支付状态查询消费者模块发送的所述订单的查询信息重新生成订单的查询消息，并将重新生成的所述订单的查询消息发送至rocketmq；所述支付状态查询消费者模块从rocketmq获取并解析所述支付状态查询生产者模块重新生成的所述订单的查询消息，得到所述订单的查询信息，重新将所述订单的查询信息发送至第三服务器查询所述订单的支付状态，直至所述支付状态查询结果为支付成功/支付失败。4.根据权利要求3所述的支付状态翻转方法，其特征在于，所述支付状态查询消费者模块从rocketmq获取并解析所述支付状态查询生产者模块发送的所述订单的查询消息，包括：当rocketmq接收到所述支付状态查询生产者模块发送的所述订单的查询消息后，所述支付状态查询消费者模块延时1～5s从rocketmq获取并解析所述支付状态查询生产者模块发送的所述订单的查询消息；相应地，所述支付状态查询消费者模块从rocketmq获取并解析所述支付状态查询生产者模块重新生成的所述订单的查询消息，包括：当rocketmq接收到所述支付状态查询生产者模块重新生成的所述订单的查询消息后，所述支付状态查询消费者模块延时1～5s从rocketmq获取并解析所述支付状态查询生产者模块重新生成的所述订单的查询消息。5.根据权利要求2所述的支付状态翻转方法，其特征在于，所述第一服务器还包括支付状态通知生产者模块和支付状态通知消费者模块；相应地，所述接收所述第二服务器发送的支付状态通知反馈；若所述支付状态通知反馈为通知失败，则重新向所述第二服务器发送所述订单的支付状态查询结果，直至所述支付状态通知反馈为通知成功；若所述支付状态通知反馈为通知成功，则结束所述订单的翻转流程，包括：所述支付状态查询消费者接收所述第二服务器发送的支付状态通知反馈；若所述支付状态通知反馈为通知失败，则所述支付状态查询消费者模块调用所述支付状态通知生产者模块并将所述订单的查询信息和支付状态查询结果发送给所述支付状态通知生产者模块，所述支付状态通知生产者模块根据所述支付状态查询消费者模块发送的所述订单的查询信息和支付状态查询结果生成并发送支付状态通知消息，所述支付状态通
知消费者模块获取并解析所述支付状态通知生产者模块发送的所述支付状态通知消息，得到所述订单的查询信息和支付状态查询结果，向所述第二服务器发送所述订单的支付状态查询结果，并接收所述第二服务器发送的支付状态通知反馈；若所述支付状态通知反馈为通知失败，则所述支付状态通知消费者模块调用所述支付状态通知生产者模块并将所述订单的查询信息和支付状态查询结果发送给所述支付状态通知生产者模块，所述支付状态通知生产者模块根据所述支付状态通知消费者模块发送的所述订单的查询信息和支付状态查询结果重新生成并发送支付状态通知消息，所述支付状态通知消费者模块获取并解析所述支付状态通知生产者模块重新生成的所述支付状态通知消息，得到所述订单的查询信息和支付状态查询结果，重新向所述第二服务器发送所述订单的支付状态查询结果，直至所述支付状态通知反馈为通知成功；若所述支付状态通知反馈为通知成功，则结束所述订单的翻转流程。6.根据权利要求5所述的支付状态翻转方法，其特征在于，所述支付状态查询消费者模块调用所述支付状态通知生产者模块并将所述订单的查询信息和支付状态查询结果发送给所述支付状态通知生产者模块，所述支付状态通知生产者模块根据所述支付状态查询消费者模块发送的所述订单的查询信息和支付状态查询结果生成并发送支付状态通知消息，所述支付状态通知消费者模块获取并解析所述支付状态通知生产者模块发送的所述支付状态通知消息，得到所述订单的查询信息和支付状态查询结果，向所述第二服务器发送所述订单的支付状态查询结果，并接收所述第二服务器发送的支付状态通知反馈；若所述支付状态通知反馈为通知失败，则所述支付状态通知消费者模块调用所述支付状态通知生产者模块并将所述订单的查询信息和支付状态查询结果发送给所述支付状态通知生产者模块，所述支付状态通知生产者模块根据所述支付状态通知消费者模块发送的所述订单的查询信息和支付状态查询结果重新生成并发送支付状态通知消息，所述支付状态通知消费者模块获取并解析所述支付状态通知生产者模块重新生成的所述支付状态通知消息，得到所述订单的查询信息和支付状态查询结果，重新向所述第二服务器发送所述订单的支付状态查询结果，直至所述支付状态通知反馈为通知成功，包括：所述支付状态查询消费者模块直接调用所述支付状态通知生产者模块并将所述订单的查询信息和支付状态查询结果发送给所述支付状态通知生产者模块，所述支付状态通知生产者模块根据所述支付状态查询消费者模块发送的所述订单的查询信息和支付状态查询结果生成支付状态通知消息，并将所述支付状态通知消息发送至rocketmq，所述支付状态通知消费者模块从rocketmq获取并解析所述支付状态通知生产者模块发送的所述支付状态通知消息，得到所述订单的查询信息和支付状态查询结果，向所述第二服务器发送所述订单的支付状态查询结果，并接收所述第二服务器发送的支付状态通知反馈；若所述支付状态通知反馈为通知失败，则所述支付状态通知消费者模块直接调用所述支付状态通知生产者模块并将所述订单的查询信息和支付状态查询结果发送给所述支付状态通知生产者模块，所述支付状态通知生产者模块根据所述支付状态通知消费者模块发送的所述订单的查询信息和支付状态查询结果重新生成支付状态通知消息，并将重新生成的所述支付状态通知消息发送至rocketmq，所述支付状态通知消费者模块从rocketmq获取并解析所述支付状态通知生产者模块重新生成的所述支付状态通知消息，得到所述订单的查询信息和支付状态查询结果，并重新向所述第二服务器发送所述订单的支付状态查询结果，直至所述
支付状态通知反馈为通知成功。7.根据权利要求6所述的支付状态翻转方法，其特征在于，所述支付状态通知消费者模块从rocketmq获取并解析所述支付状态通知生产者模块发送的所述支付状态通知消息，包括：当rocketmq接收到所述支付状态通知生产者模块发送的所述支付状态通知消息后，所述支付状态通知消费者模块延时1～5s从rocketmq获取并解析所述支付状态通知生产者模块发送的所述支付状态通知消息；相应地，所述支付状态通知消费者模块从rocketmq获取并解析所述支付状态通知生产者模块重新生成的所述支付状态通知消息，包括：当rocketmq接收到所述支付状态通知生产者模块重新生成的所述支付状态通知消息后，所述支付状态通知消费者模块延时1～5s从rocketmq获取并解析所述支付状态通知生产者模块重新生成的所述支付状态通知消息。8.一种支付状态翻转装置，应用于第一服务器，其特征在于，包括：查询消息获取模块，用于获取第二服务器的订单支付信息，根据所述订单支付信息获取每个订单的查询信息；支付状态查询模块，用于将所述订单的查询信息发送至第三服务器以查询每个所述订单的支付状态，并接收所述第三服务器发送的所述订单的支付状态查询结果；若所述支付状态查询结果为处理中，则重新将所述订单的查询信息发送至所述第三服务器以查询对应的支付状态，直至所述订单的所述支付状态查询结果为支付成功/支付失败；若所述支付状态查询结果为支付成功/支付失败，则调用所述第二服务器的支付通知接口地址向所述第二服务器发送所述订单的支付状态查询结果；支付状态通知模块，用于接收所述第二服务器发送的支付状态通知反馈；若所述支付状态通知反馈为通知失败，则重新向所述第二服务器发送所述订单的支付状态查询结果，直至所述支付状态通知反馈为通知成功；若所述支付状态通知反馈为通知成功，则结束所述订单的翻转流程。9.一种电子设备，其特征在于，包括处理器、以及与所述处理器耦接的存储器，所述存储器存储有可被所述处理器执行的程序指令；所述处理器执行所述存储器存储的所述程序指令时实现如权利要求1～7中任一项所述的支付状态翻转方法。10.一种存储介质，其特征在于，所述存储介质内存储有程序指令，所述程序指令被处理器执行时实现如权利要求1～7中任一项所述的支付状态翻转方法。

技术总结
本发明涉及金融数据处理技术领域，尤其涉及一种支付状态翻转方法、装置、电子设备及存储介质，接收第三服务器发送的订单的支付状态查询结果；若支付状态查询结果为处理中，则重新将订单的查询信息发送至第三服务器以查询对应的支付状态；若支付状态查询结果为支付成功/支付失败，则调用第二服务器的支付通知接口地址向第二服务器发送订单的支付状态查询结果；若支付状态通知反馈为通知失败，则重新向第二服务器发送订单的支付状态查询结果，直至支付状态通知反馈为通知成功；通过上述方式，解决了业务系统定时主动查询导致的支付状态翻转慢的技术问题及支付系统回调业务系统失败导致的支付状态无法翻转的技术问题。失败导致的支付状态无法翻转的技术问题。失败导致的支付状态无法翻转的技术问题。


技术研发人员：张伟
受保护的技术使用者：平安科技（深圳）有限公司
技术研发日：2023.05.19
技术公布日：2023/8/2