Payment status updating method, device, electronic device and storage medium

Abstract

The present application provides a payment status update method, device, electronic device and computer-readable storage medium. The payment status update method includes: when a new payment order is detected on an order interface, the new payment order is loaded into a preset message queue, wherein the new payment order is based on a third-party payment platform payment; calling a preset processing thread to obtain the new payment order from the message queue; calling the processing thread to obtain the first payment status of the new payment order according to a preset payment status query interface; and updating the payment status of the new payment order on the order interface according to the first payment status. In the present application, there is no need to rely on a third-party payment platform to call back the payment status of the new payment order, thereby ensuring that the payment order on the order page can flow normally.

Description

Technical Field

[0001] The present application relates to the field of Internet payment technology, and in particular to a payment status updating method, device, electronic device and computer-readable storage medium. Background Art

[0002] With the development of Internet technology, third-party payment has become the mainstream payment mode. In this payment mode, the payment process and the successful payment process are often not in the same process. After the third-party payment platform processes the order, it will return the order payment status to the order page through a callback.

[0003] However, in actual usage scenarios, due to network or other reasons, the third-party payment platform may not call back in time or may not call back for a long time, resulting in the order payment status on the order page not being updated in time, which in turn causes the order document to be unable to circulate normally, thus affecting user use. Summary of the invention

[0004] The present application provides a payment status updating method, device, electronic device and computer-readable storage medium, aiming to solve the problem that the order payment status on the order page cannot be updated in time due to the untimely callback of the third-party payment platform, thereby causing the order document to fail to circulate normally.

[0005] In a first aspect, the present application provides a payment status updating method, the method comprising:

[0006] When a new payment order is detected on the order interface, the new payment order is loaded into a preset message queue, wherein the new payment order is based on payment via a third-party payment platform;

[0007] Calling a preset processing thread to obtain the new payment order from the message queue;

[0008] Calling the processing thread to obtain the first payment status of the new payment order according to a preset payment status query interface;

[0009] According to the first payment status, the payment status of the new payment order in the order interface is updated.

[0010] In a possible implementation of the present application, the calling of the processing thread to obtain the first payment status of the new payment order according to a preset payment status query interface includes:

[0011] Calling the processing thread to send a first query instruction of the new payment order to the payment status query interface, wherein the first query instruction carries the order number of the new payment order;

[0012] The first payment status fed back by the payment status query interface based on the first query instruction is obtained.

[0013] In a possible implementation of the present application, the method further includes:

[0014] Calling the order page, and sending a second query instruction of the new payment order to the payment status query interface, wherein the second query instruction carries the order number of the new payment order;

[0015] Acquire the second payment status fed back by the payment status query interface based on the second query instruction;

[0016] According to the second payment status, the payment status of the new payment order in the order interface is updated.

[0017] In a possible implementation of the present application, the method further includes:

[0018] Calling the third-party payment platform to call back the third payment status of the new payment order;

[0019] According to the third payment status, the payment status of the new payment order in the order interface is updated.

[0020] In a possible implementation of the present application, the processing thread is a distributed thread.

[0021] In a possible implementation of the present application, when a new payment order is detected on the order interface, loading the new payment order into a preset message queue includes:

[0022] When a new payment order is detected on the order interface, the new payment order is loaded into a preset payment pre-order table;

[0023] The new payment order in the payment pre-order table is loaded into a preset message queue.

[0024] In a possible implementation of the present application, the method further includes:

[0025] When the target payment status of the new payment order is successful payment, the new payment order is deleted from the payment pre-order table, wherein the target payment status includes any one of the first payment status, the second payment status and the third payment status.

[0026] In a second aspect, the present application provides a payment status updating device, the payment status updating device comprising:

[0027] A loading unit, configured to load a new payment order into a preset message queue when a new payment order is detected on the order interface, wherein the new payment order is based on payment via a third-party payment platform;

[0028] A first acquisition unit, configured to call a preset processing thread to acquire the new payment order from the message queue;

[0029] A second acquisition unit, configured to call the processing thread and acquire the first payment status of the new payment order according to a preset payment status query interface;

[0030] An updating unit, used for updating the payment status of the new payment order on the order interface according to the first payment status.

[0031] In a possible implementation of the present application, the second acquiring unit is specifically configured to:

[0032] Calling the processing thread to send a first query instruction of the new payment order to the payment status query interface, wherein the first query instruction carries the order number of the new payment order;

[0033] The first payment status fed back by the payment status query interface based on the first query instruction is obtained.

[0034] In a possible implementation of the present application, the updating unit is specifically used for:

[0035] Calling the order page, and sending a second query instruction of the new payment order to the payment status query interface, wherein the second query instruction carries the order number of the new payment order;

[0036] Acquire the second payment status fed back by the payment status query interface based on the second query instruction;

[0037] According to the second payment status, the payment status of the new payment order in the order interface is updated.

[0038] In a possible implementation of the present application, the updating unit is specifically used for:

[0039] Calling the third-party payment platform to call back the third payment status of the new payment order;

[0040] According to the third payment status, the payment status of the new payment order in the order interface is updated.

[0041] In a possible implementation of the present application, the processing thread is a distributed thread, and the first acquisition unit is specifically used to:

[0042] Calling the distributed thread to obtain the new payment order from the message queue;

[0043] The second acquisition unit is specifically used for:

[0044] The distributed thread is called to obtain the first payment status of the new payment order according to a preset payment status query interface.

[0045] In a possible implementation of the present application, the loading unit is specifically used for:

[0046] When a new payment order is detected on the order interface, the new payment order is loaded into a preset payment pre-order table;

[0047] The new payment order in the payment pre-order table is loaded into a preset message queue.

[0048] In a possible implementation of the present application, the payment status updating device further includes a deleting unit, and the deleting unit is specifically used to:

[0049] When the target payment status of the new payment order is successful payment, the new payment order is deleted from the payment pre-order table, wherein the target payment status includes any one of the first payment status, the second payment status and the third payment status.

[0050] In a third aspect, the present application further provides an electronic device, comprising a processor and a memory, wherein the memory stores a computer program, and when the processor calls the computer program in the memory, the processor executes the steps of any payment status update method provided in the present application.

[0051] In a fourth aspect, the present application also provides a computer-readable storage medium on which a computer program is stored, and the computer program is loaded by a processor to execute the steps in the payment status update method.

[0052] This application loads the new payment order on the order page into a preset message queue, calls the preset processing thread, obtains the new payment order from the message queue, queries the payment status according to the preset payment status query interface, and feeds back to the order page. On the one hand, it ensures that the payment status of the new payment order on the order page can be updated in time, thereby ensuring that the payment order on the order page can flow normally. On the other hand, it avoids the need to rely on a third-party payment platform to call back the payment status of the new payment order; thereby avoiding the problem that the order payment status on the order page cannot be updated in time due to network or other reasons, resulting in the third-party payment platform not calling back in time or not calling back for a long time. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0054] Figure 1 It is a scenario diagram of a payment status update system provided in an embodiment of the present application;

[0055] Figure 2 This is a flow chart of a payment status update method provided in an embodiment of the present application;

[0056] Figure 3 is a schematic flow chart of an embodiment of step S30 provided in an embodiment of the present application;

[0057] Figure 4 is a schematic flow chart of an embodiment of step S10 provided in an embodiment of the present application;

[0058] Figure 5 This is a schematic diagram of an embodiment of a payment pre-order table provided in an embodiment of the present application;

[0059] Figure 6 This is a schematic diagram of an embodiment of the payment status update process provided by the embodiment of the present application;

[0060] Figure 7 It is a schematic diagram of the structure of an embodiment of a payment status updating device provided in an embodiment of the present application;

[0061] Figure 8 It is a schematic diagram of the structure of an embodiment of an electronic device provided in the embodiments of the present application. DETAILED DESCRIPTION

[0062] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of this application.

[0063] In the description of the embodiments of the present application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and cannot be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of the embodiments of the present application, the meaning of "multiple" is two or more, unless otherwise clearly and specifically defined.

[0064] In order to enable any technician in the field to implement and use the application, the following description is given. In the following description, details are listed for the purpose of explanation. It should be understood that those of ordinary skill in the art can recognize that the application can also be implemented without using these specific details. In other examples, the known process will not be elaborated in detail to avoid unnecessary details that make the description of the embodiment of the application obscure. Therefore, the application is not intended to be limited to the embodiments shown, but is consistent with the widest range of principles and features disclosed in accordance with the embodiments of the application.

[0065] The embodiment of the present application provides a payment status update method, device, electronic device and computer readable storage medium. The payment status update device can be integrated in an electronic device, which can be a server or a terminal.

[0066] First of all, before introducing the embodiments of the present application, the relevant content about the application background of the embodiments of the present application is introduced.

[0067] With the rapid development of Internet technology, online shopping is becoming more and more common. Online shopping generally includes the purchase of virtual items or services (such as phone bill recharge, game recharge), the purchase of real items (such as daily necessities), the purchase of real services (such as express delivery payment, delivery service purchase), etc. Generally speaking, online shopping will provide a corresponding interactive interface, such as a shopping platform applet or a shopping platform APP. Based on the interactive interface, users can select items, place orders, and trigger payment.

[0068] In the embodiment of the present application, the order page refers to the interactive interface of online shopping. If the user chooses to pay the order by paying on a third-party platform, then it will be necessary to link to the third-party platform from the order page to realize the payment.

[0069] However, after the user has successfully paid, in some cases, such as poor network conditions or a large number of orders paid at the same time, the third-party payment platform may not be able to promptly call back the payment success status to the order page after processing the order. In this case, the order page cannot update the payment status of the order in a timely manner, resulting in the order being unable to flow further, affecting the user's further use.

[0070] The executor of the payment status update method of the embodiment of the present application may be the payment status update device provided in the embodiment of the present application, or different types of electronic devices such as a server device, a physical host or a user equipment (UE) that integrates the payment status update device, wherein the payment status update device may be implemented in hardware or software, and the UE may specifically be a terminal device such as a smart phone, a tablet computer, a laptop computer, a PDA, a desktop computer or a personal digital assistant (PDA).

[0071] The electronic device can adopt a working mode of independent operation or a working mode of a device cluster. By applying the payment status updating method provided in the embodiment of the present application, there is no need to rely on the third-party payment platform to call back the payment status of the payment order. The payment status of the payment order can be queried in time and fed back to the order page in time, thereby avoiding the problem that the order payment status on the order page cannot be updated in time due to the third-party payment platform's untimely callback or long-term non-callback due to network or other reasons, thereby ensuring the normal circulation of order documents.

[0072] See also Figure 1 , Figure 1 It is a scenario diagram of the payment status update system provided in the embodiment of the present application. Among them, the payment status update system may include an electronic device 100, in which a payment status update device is integrated. For example, when a new payment order is detected on the order interface, the electronic device may load the new payment order into a preset message queue, wherein the new payment order is based on a third-party payment platform payment; call a preset processing thread to obtain the new payment order from the message queue; call the processing thread to obtain the first payment status of the new payment order according to the preset payment status query interface; and update the payment status of the new payment order on the order interface according to the first payment status.

[0073] In addition, if Figure 1 As shown, the payment status update system may further include a memory 200 for storing data, such as payment order data.

[0074] It should be noted that Figure 1 The scenario diagram of the payment status update system shown is merely an example. The payment status update system and scenario described in the embodiment of the present application are intended to more clearly illustrate the technical solution of the embodiment of the present application, and do not constitute a limitation on the technical solution provided in the embodiment of the present application. A person of ordinary skill in the art can appreciate that with the evolution of the payment status update system and the emergence of new business scenarios, the technical solution provided in the embodiment of the present application is equally applicable to similar technical problems.

[0075] Next, the payment status update method provided in the embodiment of the present application is introduced. In the embodiment of the present application, an electronic device is used as the execution subject. For the sake of simplicity and ease of description, the execution subject will be omitted in the subsequent method embodiments.

[0076] Reference Figure 2 , Figure 2 1 is a flow chart of a payment status update method provided in an embodiment of the present application. It should be noted that although the logical order is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order than that here. The payment status update method includes steps S10 to S40, wherein:

[0077] S10. When a new payment order is detected on the order interface, the new payment order is loaded into a preset message queue.

[0078] The new payment order is based on the third-party payment platform payment. The new payment order refers to the payment order newly generated on the order page.

[0079] The third-party payment platform may be Alipay, WeChat Pay, etc. The third-party payment platform mentioned here is only an example, and other forms of third-party payment platforms and third-party payment platforms that will appear in the future may also be used, but are not limited to this.

[0080] Among them, the order interface can be a mini program interface, an APP interface, a web page interface, etc. In the embodiment of the present application, the order interface can be one or more.

[0081] A new payment order refers to an order that a user places and pays for based on the order interface. For example, based on the WeChat applet interface of a logistics company, a user purchases a shipment reservation service and uses WeChat Pay to complete the order payment for the shipment service. In this case, the shipment reservation service purchased by the user is a new payment order.

[0082] Message Queue (MQ) is a "first-in, first-out" data structure in the basic data structure. It is generally used to solve problems such as application decoupling, asynchronous messaging, and traffic cutting, and to achieve high performance, high availability, scalability, and eventual consistency architecture.

[0083] Specifically, in some embodiments, each time a newly generated payment order is detected on an order page, the newly generated payment order on the order page will be loaded into a preset message queue (so, multiple payment orders will be arranged in sequence in the message queue) so that each payment order in the message queue can be queried and fed back in a timely manner in sequence.

[0084] In an embodiment of the present application, the new payment order is loaded into a preset message queue so that each payment order can be subsequently obtained from the message queue in turn to query the payment status and feedback to the order page, thereby avoiding the need to rely on a third-party payment platform to call back the payment status of the new payment order.

[0085] S20. Call a preset processing thread to obtain the new payment order from the message queue.

[0086] A thread is the smallest unit that an operating system can schedule operations on. It is contained in a process and is the actual operating unit in the process. A thread refers to a single sequential control flow in a process. A process can have multiple threads running concurrently, and each thread executes different tasks in parallel.

[0087] The preset processing thread (also referred to as processing thread in this article) can be a single thread (such as a thread in a process) or multiple threads (such as threads in different processes).

[0088] The preset processing thread is specifically used to consume each payment order in the message queue. The process of the processing thread consuming each payment order is as follows: sending a status query instruction to the preset payment status query interface (wherein the status query instruction carries the order number of the payment order) to obtain the payment status of the payment order, and feedback the payment status to the order page, thereby ensuring that the payment status of the payment order on the order page can be updated in time, and then ensuring that the payment order on the order page can flow normally.

[0089] In some embodiments, a new thread can be added to the server corresponding to the order page as a preset processing thread for processing payment orders in the message queue. At this time, in step S20, the new thread added to the server corresponding to the order page can be directly used to obtain each payment order from the message queue in turn, so as to query the payment status of the payment order and feedback it in the subsequent steps.

[0090] In some embodiments, a new thread may be added to a server process other than the server corresponding to the order page as a preset processing thread for processing payment orders in the message queue. If the server corresponding to the order page is server 1, a new thread A may be added to the server 2 process for processing payment orders in the message queue. At this time, in step S20, a new thread A added to the server 2 process may be directly used to obtain each payment order from the message queue in sequence, so as to query and feedback the payment status of the payment order in subsequent steps.

[0091] Furthermore, in order to improve the processing capability of the preset processing thread and improve the processing efficiency of the payment order in the message queue, the preset processing thread may be a distributed processing thread. Specifically, it may be a thread provided by different nodes, such as the preset processing thread includes thread 1 of process A in server a, thread 2 of process B in server b, thread 3 of process C in server c, thread 4 of process D in server d, and thread 5 of process E in server e, a total of 5 threads.

[0092] At this time, threads 1, 2, 3, 4, and 5 can be used simultaneously to obtain each payment order from the message queue in sequence, so as to query and feedback the payment status of the payment order in subsequent steps. Among them, threads 1, 2, 3, 4, and 5 can process the payment orders in the message queue according to their actual consumption capabilities.

[0093] First, since each distributed thread can work independently and do not affect each other, it is possible to avoid using a single processing thread to consume the message queue. When an abnormal state occurs in a single thread, the status of the payment order in the message queue cannot be queried and fed back normally, resulting in the problem that the payment status of the payment order cannot be fed back in time.

[0094] Secondly, by processing the payment status of the payment orders in the message queue in parallel through distributed multiple threads, the consumption of the payment orders in the message queue can be accelerated, thereby improving the speed of determining the payment status of the payment orders.

[0095] It can be seen that through distributed processing threads, the timeliness of payment status updates of payment orders can be improved to a certain extent, thereby improving the circulation speed of payment orders.

[0096] S30: calling the processing thread and obtaining the first payment status of the new payment order according to a preset payment status query interface.

[0097] The payment status query interface (also referred to as the payment status query interface in this article) refers to the payment status query interface of the third-party payment platform. For example, the WeChat payment platform will provide an interface for querying payment, which is used to query the payment status of payment orders paid through the WeChat payment platform. The payment query interface provided by the WeChat payment platform is the payment status query interface.

[0098] The payment status includes the status of successful payment of the payment order, payment in progress, payment failure, etc. The payment status here is only an example, and can be adjusted according to the actual situation, and is not limited to this. The first payment status refers to the payment status of the new payment order obtained by querying the payment status query interface through a preset processing thread.

[0099] In some embodiments, step S30 is specifically implemented as follows: calling the processing thread to send the order number of the new payment order to the payment status query interface provided by the third-party payment platform; the payment status query interface will query the payment status based on the order number of the new payment order, and feedback the payment status of the new payment order, that is, obtain the first payment status of the new payment order.

[0100] S40. Update the payment status of the new payment order on the order interface according to the first payment status.

[0101] In some embodiments, after the first payment status is obtained, the payment status of the new payment order in the order interface is directly updated to the first payment status.

[0102] For example, the payment status of the new payment order in the order interface is originally "paying". If the first payment status is "payment successful", the payment status of the new payment order in the order interface is updated to "payment successful".

[0103] For another example, the payment status of the new payment order in the order interface is originally "paying". If the first payment status is "payment failed", the payment status of the new payment order in the order interface is updated to "payment failed".

[0104] In some embodiments, the first payment status includes payment success, payment failure, etc. After obtaining the first payment status, further detect whether the first payment status is "payment success" or "payment failure". When the first payment status is "payment success", the payment status of the new payment order on the order interface is updated to "payment success". When the first payment status is "payment failure", the payment status of the new payment order on the order interface is updated to "payment failure". When the first payment status is other than "payment success" and "payment failure", the payment status of the new payment order on the order interface is not updated, so as to reduce the number of updates while ensuring that the new payment order can flow normally, thereby reducing the amount of data processing.

[0105] From the above content, it can be seen that by loading the new payment order into the preset message queue, calling the preset processing thread, obtaining the new payment order from the message queue, querying the payment status according to the preset payment status query interface, and feeding back to the order page. On the one hand, it ensures that the payment status of the new payment order on the order page can be updated in time, thereby ensuring that the payment order on the order page can flow normally. On the other hand, it avoids the need to rely on a third-party payment platform to call back the payment status of the new payment order; thereby avoiding the problem that the order payment status on the order page cannot be updated in time due to network or other reasons, resulting in the third-party payment platform not calling back in time or not calling back for a long time.

[0106] It can be seen that through the method provided in the embodiment of the present application, there is no need to rely on the third-party payment platform to call back the payment status of the payment order. The payment status of the payment order can be queried in time and fed back to the order page. This avoids the problem that the order payment status on the order page cannot be updated in time due to the third-party payment platform's untimely callback or long-term non-callback due to network or other reasons, thereby ensuring the normal circulation of order documents.

[0107] Please refer to Figure 3 , Figure 3 1 is a flow chart of an embodiment of step S30 provided in the embodiments of the present application. In some embodiments, step S30 may specifically include the following steps S31 to S32, wherein:

[0108] S31, calling the processing thread, and sending a first query instruction of the new payment order to the payment status query interface.

[0109] The first query instruction refers to an instruction initiated by the processing thread to the payment status query interface for querying the payment status of the new payment order. The first query instruction carries the order number of the new payment order to ensure that the order status of the new payment order can be accurately obtained.

[0110] For example, the processing threads are distributed processing threads, including thread 1, thread 2, and thread 3. The preset message queue includes orders a, b, c, d, and e.

[0111] Then, thread 1 can be called to send the first query instruction of order a to the payment status query interface provided by the third party (at this time, the first query instruction includes the order number of order a), thread 2 can be called to send the first query instruction of order b to the payment status query interface (at this time, the first query instruction includes the order number of order b), thread 3 can be called to send the first query instruction of order c to the payment status query interface (at this time, the first query instruction includes the order number of order c), thread 1 can be called to send the first query instruction of order d to the payment status query interface (at this time, the first query instruction includes the order number of order d), and thread 2 can be called to send the first query instruction of order e to the payment status query interface (at this time, the first query instruction includes the order number of order e).

[0112] S32: Obtain the first payment status fed back by the payment status query interface based on the first query instruction.

[0113] Specifically, after receiving the first query instruction, the payment status query interface provided by the third party will query according to the order number of the new payment order and feedback the first payment status of the new payment order.

[0114] For ease of understanding, the example in step S31 above is continued. For example, the payment status query interface will query according to the order numbers of orders a, b, c, d, and e, and feedback the payment status of order a to thread 1 (such as "payment successful"), feedback the payment status of order b to thread 2 (such as "payment failed"), feedback the payment status of order c to thread 3 (such as "payment successful"), feedback the payment status of order d to thread 1 (such as "payment in progress"), and feedback the payment status of order e to thread 2 (such as "payment failed"), that is, the first payment status of order a, the first payment status of order b, the first payment status of order c, the first payment status of order d, and the first payment status of order e can be obtained.

[0115] From the above content, it can be seen that by calling the processing thread, the first query instruction carrying the order number of the new payment order is sent to the payment status query interface provided by the third-party payment platform, thereby ensuring that the payment status of the new payment order can be accurately queried and fed back.

[0116] In order to further improve the timeliness of payment status updates of new payment orders in the order interface, and thereby improve the circulation speed of new payment orders, in some embodiments of the present application, after the new payment order is paid, the order page can also be called to directly query the payment status of the new payment order.

[0117] That is, in some embodiments of the present application, the payment status update method further includes the following steps a1 to a3, wherein:

[0118] a1. Call the order page and send a second query instruction of the new payment order to the payment status query interface.

[0119] The second query instruction refers to an instruction initiated by the order page to the payment status query interface for querying the payment status of the new payment order. The second query instruction carries the order number of the new payment order to ensure that the order status of the new payment order can be accurately obtained.

[0120] For example, a user purchases a parcel collection service based on a logistics company's mini program and completes payment for the parcel collection service order based on a third-party payment platform (such as WeChat). After the user completes payment for the parcel collection service order, the logistics company's mini program will send a second query instruction for the parcel collection service order to the payment status query interface provided by the third-party payment platform (at this time, the corresponding second query instruction carries the order number of the parcel collection service order).

[0121] a2. Obtain the second payment status fed back by the payment status query interface based on the second query instruction.

[0122] The second payment status refers to the payment status of a new payment order obtained by querying the payment status query interface through a preset order page.

[0123] Specifically, after receiving the second query instruction, the payment status query interface provided by the third-party payment platform will query according to the order number of the new payment order and feedback the second payment status of the new payment order.

[0124] For ease of understanding, the example in step a1 above is continued. For example, the payment status query interface will query according to the order number of the receiving service order, and feedback the payment status of the receiving service order (such as "payment failed") to the order page.

[0125] a3. According to the second payment status, update the payment status of the new payment order on the order interface.

[0126] In some embodiments, after the second payment status is obtained, the payment status of the new payment order in the order interface is directly updated to the second payment status.

[0127] For ease of understanding, the example in step a2 above is continued. For example, if the second payment status of the collection service order is "payment failed", the payment status of the collection service order in the mini program of the logistics company can be updated to "payment failed".

[0128] In some embodiments, the second payment status includes payment success, payment failure, etc. After obtaining the second payment status, further detect whether the second payment status is "payment success" or "payment failure". When the second payment status is "payment success", the payment status of the new payment order on the order interface is updated to "payment success". When the second payment status is "payment failure", the payment status of the new payment order on the order interface is updated to "payment failure". When the second payment status is other than "payment success" and "payment failure", the payment status of the new payment order on the order interface is not updated, so as to reduce the number of updates while ensuring that the new payment order can flow normally, thereby reducing the amount of data processing.

[0129] From the above content, it can be seen that by combining the preset processing thread query and order page query with parallel processing, the payment status of the new payment order on the order interface can be updated, which can further improve the payment status update speed and ensure the high availability of the payment status update.

[0130] In order to further improve the timeliness of the payment status update of new payment orders in the order interface, and thereby improve the circulation speed of new payment orders, in some embodiments of the present application, after the new payment order is paid, the original third-party payment platform callback method can continue to be retained to update the payment status of the new payment order.

[0131] That is, in some embodiments of the present application, the payment status update method further includes the following steps b1 to b2, wherein:

[0132] b1. Call the third-party payment platform to call back the third payment status of the new payment order.

[0133] The third payment status refers to the payment status of a new payment order obtained through callback from a third-party payment platform.

[0134] For example, a user purchases a purchasing service on behalf of a delivery company through a purchasing service APP, and completes the payment of the purchasing service order through a third-party payment platform. After the user completes the payment of the purchasing service order, the third-party payment platform will automatically call back the payment status of the purchasing service order (i.e., the third payment status) to the purchasing service APP after completing the payment processing of the purchasing service order, so as to update the payment status of the purchasing service order in the purchasing service APP later.

[0135] b2. According to the third payment status, update the payment status of the new payment order on the order interface.

[0136] In some embodiments, after the third payment status is obtained, the payment status of the new payment order in the order interface is directly updated to the third payment status.

[0137] For ease of understanding, the above step b1 is continued. For example, if the third-party payment platform receives a callback to obtain that the payment status of the purchasing service order is "Payment Successful", the payment status of the purchasing service order in the purchasing service APP is updated to "Payment Successful".

[0138] In some embodiments, the third payment status includes payment success, payment failure, etc. After obtaining the third payment status, further detect whether the third payment status is "payment success" or "payment failure". When the third payment status is "payment success", the payment status of the new payment order on the order interface is updated to "payment success". When the third payment status is "payment failure", the payment status of the new payment order on the order interface is updated to "payment failure". When the third payment status is other than "payment success" and "payment failure", the payment status of the new payment order on the order interface is not updated, so as to reduce the number of updates while ensuring that the new payment order can flow normally, thereby reducing the amount of data processing.

[0139] From the above content, it can be seen that by combining the preset processing thread query, third-party payment platform callback and parallel processing to update the payment status of the new payment order on the order interface, the payment status update speed can be further improved and the high availability of the payment status update can be ensured.

[0140] As can be seen from the above content, updating the payment status of the new payment order in the order interface can be achieved through the preset processing thread query (see the above steps S10 to S40, and S31 to S32 for details). It can also be achieved in parallel through the preset processing thread query and order page query (see the above steps a1 to a3 for details). It can also be achieved in parallel through the preset processing thread query, order page query, and third-party payment platform callback (see the above steps b1 to b2 for details)

[0141] Furthermore, in addition to querying and updating the payment status of the new payment order on the order interface through the preset processing thread, the payment status of the new payment order on the order interface can also be updated in parallel through third-party callbacks, self-query on the order page, etc. While ensuring that the new payment order can be updated in time, in order to reduce the amount of data processing, when a new payment order is detected on the order interface in step S10, it can be first detected whether the payment status of the new payment order on the order interface is successful payment.

[0142] If the payment status of the new payment order on the order interface is not payment success, then the new payment order is loaded into the preset message queue for payment status update. If the payment status of the new payment order on the order interface is payment success, then there is no need to query and update the payment status of the new payment order on the order interface through the processing thread, so as to reduce the data processing volume of the processing thread and avoid repeated data processing.

[0143] It can be seen that when a new payment order is detected on the order interface, by further detecting whether the payment status of the new payment order on the order interface is successful payment, the data processing volume of the processing thread can be reduced while ensuring the circulation speed of the new payment order.

[0144] In order to avoid the loss of new payment orders, further, in the embodiment of the present application, it is considered to first load the new payment order into a preset payment pre-order table, and then pull the new payment order from the preset payment pre-order table and load it into the message queue.

[0145] Please refer to Figure 4 , Figure 4 is a flowchart of an embodiment of step S10 provided in the embodiments of the present application. That is, in some embodiments of the present application, step S10 may specifically include the following steps S11 to S12, wherein:

[0146] S11. When a new payment order is detected on the order interface, the new payment order is loaded into a preset payment pre-order table.

[0147] The preset payment pre-order table (hereinafter referred to as the payment pre-order table) refers to a data table used to record payment orders based on third-party payment platforms. The payment pre-order table may include information such as the order number and generation time of the payment order.

[0148] Please refer to Figure 5 , Figure 5 : is a schematic diagram of an embodiment of the payment pre-order table provided in the embodiments of the present application. For example, when a new payment order based on a third-party payment platform (such as order 1, 2, 3, 4, 5) is detected, orders 1, 2, 3, 4, 5 can be added to the preset payment pre-order table respectively. Figure 5 shown.

[0149] S12: Load the new payment order in the payment pre-order table into a preset message queue.

[0150] On the one hand, the payment order in the message queue will be lost after being obtained by the processing thread once. On the other hand, due to network and other reasons, there may be a situation where the payment order is in processing for a long time. In order to prevent the payment order from being lost before the status query is successful, in some embodiments, step S12 specifically includes the following steps 1 to 5, where:

[0151] 1. Pull new payment orders from the payment pre-order table and load them into the preset message queue;

[0152] 2. Call the preset processing thread to the preset payment status query interface to obtain the first payment status of the new payment order;

[0153] 3. Check whether the first payment status of the new payment order is payment success or payment failure;

[0154] 4. If the first payment status of the new payment order is not payment success or payment failure, the new payment order is pulled from the payment pre-order table and loaded into the preset message queue;

[0155] 5. Iterate the above 1 to 4 until the first payment status of the new payment order is payment success or payment failure.

[0156] For example, orders 1, 2, 3, 4, 5, 6, 7, 8, and 9 are all loaded into the preset payment pre-order table. First, orders 1, 2, 3, 4, 5, 6, 7, 8, and 9 are pulled from the payment pre-order table and loaded into the preset message queue. Then, the preset processing thread is called to query the preset payment status interface to obtain the payment status of orders 1, 2, 3, 4, 5, 6, 7, 8, and 9.

[0157] Among them, the payment status (i.e., the first payment status) of orders 1, 2, 3, 4, 5, 6, 7, 8, and 9 are respectively: payment successful, payment failed, processing, processing, payment failed, payment successful, payment failed, payment successful, and processing.

[0158] Orders 3, 4, and 9 are respectively pulled out from the payment pre-order table and loaded into the preset message queue, and the preset processing thread is called again to obtain the payment status of orders 3, 4, and 9 from the preset payment status query interface until the payment status of orders 3, 4, and 9 is also payment success or payment failure.

[0159] From the above content, it can be seen that by first loading the new payment order into the preset payment pre-order table, and then pulling the new payment order from the preset payment pre-order table and loading it into the message queue, the new payment order can be repeatedly pulled from the payment pre-order table and loaded into the message queue, thereby avoiding the loss of the new payment order before the payment status is updated, and thus ensuring the high availability of the payment status update of the new payment order.

[0160] In order to avoid repeatedly pulling the new payment order from the payment pre-order table and loading it into the preset message queue to query the payment status of the new payment order again after the payment status of the new payment order on the payment page has been updated (such as whether the payment has been determined to be successful or failed), in an embodiment of the present application, the new payment order is deleted from the payment pre-order table after the payment status of the new payment order on the payment page has been updated.

[0161] That is, in some embodiments of the present application, the payment status update method further includes: when the target payment status of the new payment order is payment success, deleting the new payment order from the payment pre-order table.

[0162] The target payment state includes any one of the first payment state, the second payment state and the third payment state.

[0163] For example, after determining the first payment status of the new payment order in step S30 (or step S32), further detect whether the first payment status is payment success or payment failure. If the first payment status is payment success or payment failure, the new payment order is deleted from the payment pre-order table to avoid the data processing process of re-querying, thereby reducing the amount of data processing.

[0164] For another example, after determining the second payment status of the new payment order in step a2, further detect whether the second payment status is payment success or payment failure. If the second payment status is payment success or payment failure, the new payment order is deleted from the payment pre-order table to avoid the data processing process of re-querying, thereby reducing the amount of data processing.

[0165] For another example, after determining the third payment status of the new payment order in step b1, further detect whether the third payment status is payment success or payment failure. If the third payment status is payment success or payment failure, the new payment order is deleted from the payment pre-order table to avoid the data processing process of re-querying, thereby reducing the amount of data processing.

[0166] From the above, it can be seen that when the target payment status of a new payment order is payment success or payment failure, by deleting the new payment order from the payment pre-order table, it is possible to avoid the problem of repeatedly pulling the new payment order from the payment pre-order table and loading it into the preset message queue after the payment status of the new payment order has been updated on the payment page, and then querying the payment status of the new payment order again. On the basis of ensuring that the payment status is updated in a timely manner, the amount of data processing is reduced.

[0167] Finally, in order to better understand the content of the embodiment of the present application, a specific example is used below for illustration. In this example, an express delivery service order is used as a specific application scenario. In this application scenario, the new payment order can specifically be an order to purchase a delivery service or an order to purchase a pickup service.

[0168] Please refer to Figure 6 , Figure 6 1 is a schematic diagram of an embodiment of the payment status update process provided by the embodiment of the present application. The payment status update process may specifically include the following:

[0169] (1) Check the new payment order on the order page.

[0170] For example, a user places an order based on the mini program purchased for the express delivery service, and pays for orders 1, 2, 3, 4, 5, 6, 7, 8, and 9 based on a third-party payment platform. At this time, a new payment order generated based on the order page will be detected: Order 1, 2, 3, 4, 5, 6, 7, 8, 9.

[0171] (2) Loading the new payment order into a preset payment pre-order table; pulling the payment order from the payment pre-order table and loading it into a preset message queue; calling a preset processing thread, obtaining the payment order from the message queue, and sending a first query instruction to a payment status query interface provided by a third-party payment platform; obtaining a first payment status of the new payment order fed back by the payment status query interface based on the first query instruction; and updating the payment status of the new payment order on the payment page to the first payment status.

[0172] In addition, if the first payment status is "Payment Successful", the new payment order will be deleted from the payment pre-order table. This is to avoid the situation where the payment status of the new payment order is updated to "Payment Successful" on the payment page, and the payment status of the new payment order is still queried and updated, resulting in repeated and unnecessary data processing. This is to reduce the data processing volume of the processing thread while timely updating the payment status (and thus improving the circulation speed of the new payment order).

[0173] For example, orders 1, 2, 3, 4, 5, 6, 7, 8, and 9 are all loaded into the preset payment pre-order table. The generation times of orders 1, 2, 3, 4, 5, 6, 7, 8, and 9 are 8:00, 8:30, 9:00, 9:30, 10:00, 10:30, 11:00, 11:30, and 12:00, respectively.

[0174] The processing threads are distributed processing threads, including: thread 1 in server a, thread 2 in server b, thread 3 in server c, thread 4 in server d, and thread 5 in server e.

[0175] Then, under the premise that the number of orders in the preset message queue is less than N (such as 6), the orders with the earliest generation time are pulled from the payment pre-order table and loaded into the preset message queue. For example, orders 1, 2, 3, 4, 5, and 6 can be loaded into the preset message queue in sequence.

[0176] According to the "first in, first out" rule of the message queue, the processing process of each order is as follows: Call thread 1 to obtain order 1 from the preset message queue, and send a first query instruction to the payment status query interface provided by the third-party payment platform (at this time, the first query instruction carries the order number of order 1), so as to obtain the payment status of order 1. If the payment status of order 1 is "paid successfully", the payment status of order 1 on the payment page is updated to "paid successfully", and order 1 is deleted from the payment pre-order table.

[0177] Similarly, when thread 1, thread 2, thread 3, thread 4 and thread 5 complete the previous processing task, any one of thread 1, thread 2, thread 3, thread 4 and thread 5 can be called to complete the payment status query and update of order 2, 3, 4, 5, 6, 7, 8, 9.

[0178] (3) After the user pays, the order page is called to send a second query instruction to the payment status query interface provided by the third-party payment platform; the second payment status of the new payment order fed back by the payment status query interface based on the second query instruction is obtained; and the payment status of the new payment order on the payment page is updated to the second payment status.

[0179] In addition, if the second payment status is "payment successful", the new payment order will be deleted from the payment pre-order table.

[0180] Among them, the process of calling the order page to update the payment status of the new payment order on the payment page is similar to the process of calling the preset processing thread to update the payment status of the new payment order on the payment page in (2) above. For details, please refer to the content in (2) above, which will not be repeated here.

[0181] The difference is that: in (2), each new payment order is first loaded into the preset payment pre-order table and message queue, and then each thread is called in turn to query the payment status query interface for each new payment order and update the payment status. In (3), after each new payment order is paid, the order page is immediately called to query the payment status query interface for the new payment order and update the payment status.

[0182] (4) After the user pays, the third-party payment platform is called to retrieve the third-party payment status of the new payment order.

[0183] For example, after the user completes the payment of Order 1, the third-party payment platform will immediately call back the payment status of Order 1. If the payment status of Order 1 is "Payment Successful", the payment status of Order 1 on the payment page will be updated to "Payment Successful", and Order 1 will be deleted from the payment pre-order table.

[0184] Among them, (2), (3), and (4) can be executed in parallel. The payment status determined by any of (2), (3), and (4) can be used to update the payment status of the new payment order on the order page, so as to further improve the timeliness of the payment status of the new payment order on the order page and increase the circulation speed of the new payment order.

[0185] In order to better implement the payment status update method in the embodiment of the present application, based on the payment status update method, a payment status update device is also provided in the embodiment of the present application, such as Figure 7 As shown in FIG. 1 , it is a schematic diagram of the structure of an embodiment of a payment status updating device in an embodiment of the present application. The payment status updating device 700 includes:

[0186] The loading unit 701 is used to load a new payment order into a preset message queue when a new payment order is detected on the order interface, wherein the new payment order is based on payment via a third-party payment platform;

[0187] A first acquisition unit 702 is used to call a preset processing thread to acquire the new payment order from the message queue;

[0188] The second acquisition unit 703 is used to call the processing thread and acquire the first payment status of the new payment order according to a preset payment status query interface;

[0189] The updating unit 704 is used to update the payment status of the new payment order on the order interface according to the first payment status.

[0190] In some embodiments of the present application, the second acquiring unit 703 is specifically configured to:

[0191] Calling the processing thread to send a first query instruction of the new payment order to the payment status query interface, wherein the first query instruction carries the order number of the new payment order;

[0192] The first payment status fed back by the payment status query interface based on the first query instruction is obtained.

[0193] In some embodiments of the present application, the updating unit 704 is specifically used to:

[0194] Calling the order page, and sending a second query instruction of the new payment order to the payment status query interface, wherein the second query instruction carries the order number of the new payment order;

[0195] Acquire the second payment status fed back by the payment status query interface based on the second query instruction;

[0196] According to the second payment status, the payment status of the new payment order in the order interface is updated.

[0197] In some embodiments of the present application, the updating unit 704 is specifically used to:

[0198] Calling the third-party payment platform to call back the third payment status of the new payment order;

[0199] According to the third payment status, the payment status of the new payment order in the order interface is updated.

[0200] In some embodiments of the present application, the processing thread is a distributed thread, and the first acquisition unit 702 is specifically used to:

[0201] Calling the distributed thread to obtain the new payment order from the message queue;

[0202] The second acquiring unit 703 is specifically used for:

[0203] The distributed thread is called to obtain the first payment status of the new payment order according to a preset payment status query interface.

[0204] In some embodiments of the present application, the loading unit 704 is specifically used for:

[0205] When a new payment order is detected on the order interface, the new payment order is loaded into a preset payment pre-order table;

[0206] The new payment order in the payment pre-order table is loaded into a preset message queue.

[0207] In some embodiments of the present application, the payment status updating device 700 further includes a deletion unit (not shown in the figure), and the deletion unit is specifically used to:

[0208] When the target payment status of the new payment order is successful payment, the new payment order is deleted from the payment pre-order table, wherein the target payment status includes any one of the first payment status, the second payment status and the third payment status.

[0209] In specific implementation, the above units can be implemented as independent entities, or can be arbitrarily combined to be implemented as the same or several entities. The specific implementation of the above units can refer to the previous method embodiments, which will not be repeated here.

[0210] Since the payment status updating device can execute the present application as follows Figures 1 to 6 Corresponding to the steps in the payment status update method in any embodiment, therefore, the present application can be implemented as follows Figures 1 to 6 For the beneficial effects that can be achieved by the payment status updating method in any embodiment, please refer to the previous description in detail and will not be repeated here.

[0211] In addition, in order to better implement the payment status update method in the embodiment of the present application, on the basis of the payment status update method, the embodiment of the present application also provides an electronic device, referring to Figure 8 , Figure 8 A schematic diagram of the structure of an electronic device according to an embodiment of the present application is shown. Specifically, the electronic device provided by the embodiment of the present application includes a processor 801, and the processor 801 is used to execute a computer program stored in a memory 802 to implement the following Figures 1 to 6 Corresponding to each step of the payment status update method in any embodiment; or, the processor 801 is used to execute the computer program stored in the memory 802 to implement the following Figure 7 The functions of each unit in the corresponding embodiment.

[0212] Exemplarily, the computer program may be divided into one or more modules / units, one or more modules / units are stored in the memory 802, and executed by the processor 801 to complete the embodiment of the present application. One or more modules / units may be a series of computer program instruction segments that can complete specific functions, and the instruction segments are used to describe the execution process of the computer program in the computer device.

[0213] The electronic device may include, but is not limited to, a processor 801 and a memory 802. Those skilled in the art will appreciate that the illustration is merely an example of an electronic device and does not constitute a limitation on the electronic device, and may include more or fewer components than those shown in the illustration, or may combine certain components, or different components, for example, the electronic device may also include input and output devices, network access devices, buses, etc., and the processor 801, memory 802, input and output devices, and network access devices, etc., are connected via a bus.

[0214] The processor 801 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc. The processor is the control center of the electronic device, and uses various interfaces and lines to connect various parts of the entire electronic device.

[0215] The memory 802 can be used to store computer programs and / or modules. The processor 801 implements various functions of the computer device by running or executing the computer programs and / or modules stored in the memory 802 and calling the data stored in the memory 802. The memory 802 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area can store data created according to the use of the electronic device (such as audio data, video data, etc.), etc. In addition, the memory can include a high-speed random access memory, and can also include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0216] Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working process of the payment status updating device, electronic device and its corresponding units described above can refer to the following. Figures 1 to 6 The description of the payment status updating method in any embodiment will not be repeated here.

[0217] A person of ordinary skill in the art will appreciate that all or part of the steps in the various methods of the above embodiments may be completed by instructions, or by controlling related hardware through instructions. The instructions may be stored in a computer-readable storage medium and loaded and executed by a processor.

[0218] To this end, an embodiment of the present application provides a computer-readable storage medium, in which a plurality of instructions are stored, and the instructions can be loaded by a processor to execute the present application as follows: Figures 1 to 6 For the steps in the payment status update method in any embodiment, the specific operations can be referred to as follows Figures 1 to 6 The description of the payment status updating method in any embodiment will not be repeated here.

[0219] The computer-readable storage medium may include: a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0220] Due to the instructions stored in the computer-readable storage medium, the present application can be executed. Figures 1 to 6 Corresponding to the steps in the payment status update method in any embodiment, therefore, the present application can be implemented as follows Figures 1 to 6For the beneficial effects that can be achieved by the payment status updating method in any embodiment, please refer to the previous description in detail and will not be repeated here.

[0221] The above is a detailed introduction to a payment status update method, device, electronic device and computer-readable storage medium provided in an embodiment of the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for technical personnel in this field, according to the idea of ​​the present application, there will be changes in the specific implementation method and scope of application. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A payment status updating method, characterized in that: The method comprises: When a new payment order is detected on the order interface, the new payment order is loaded into a preset message queue, wherein the new payment order is based on payment via a third-party payment platform; Calling a preset processing thread to obtain the new payment order from the message queue; Calling the processing thread to obtain the first payment status of the new payment order according to a preset payment status query interface; According to the first payment status, updating the payment status of the new payment order on the order interface; The calling of the processing thread to obtain the first payment status of the new payment order according to a preset payment status query interface includes: Calling the processing thread to send a first query instruction of the new payment order to the payment status query interface, wherein the first query instruction carries the order number of the new payment order; The first payment status fed back by the payment status query interface based on the first query instruction is obtained.

2. The payment status updating method according to claim 1, characterized in that: The method further comprises: Calling the order interface, sending a second query instruction of the new payment order to the payment status query interface, wherein the second query instruction carries the order number of the new payment order; Obtaining a second payment status fed back by the payment status query interface based on the second query instruction; According to the second payment status, the payment status of the new payment order in the order interface is updated.

3. The payment status updating method according to claim 1, characterized in that: The method further comprises: Calling the third-party payment platform to call back the third payment status of the new payment order; According to the third payment status, the payment status of the new payment order in the order interface is updated.

4. The payment status updating method according to claim 1, characterized in that: The processing thread is a distributed thread.

5. The payment status updating method according to any one of claims 1 to 4, characterized in that: When a new payment order is detected on the order interface, loading the new payment order into a preset message queue includes: When a new payment order is detected on the order interface, the new payment order is loaded into a preset payment pre-order table; The new payment order in the payment pre-order table is loaded into a preset message queue.

6. The payment status updating method according to claim 5, characterized in that: The method further comprises: When the target payment status of the new payment order is payment success, the new payment order is deleted from the payment pre-order table, wherein the target payment status includes any one of the first payment status, the second payment status and the third payment status.

7. A payment status updating device, characterized in that: The payment status updating device comprises: A loading unit, configured to load a new payment order into a preset message queue when a new payment order is detected on the order interface, wherein the new payment order is based on payment via a third-party payment platform; A first acquisition unit, configured to call a preset processing thread to acquire the new payment order from the message queue; a second acquisition unit, configured to call the processing thread, and acquire the first payment status of the new payment order according to a preset payment status query interface; wherein the second acquisition unit is specifically configured to: call the processing thread, and send a first query instruction of the new payment order to the payment status query interface, wherein the first query instruction carries the order number of the new payment order; and acquire the first payment status fed back by the payment status query interface based on the first query instruction; An updating unit, used for updating the payment status of the new payment order on the order interface according to the first payment status.

8. An electronic device, characterized in that: The method comprises a processor and a memory, wherein a computer program is stored in the memory, and when the processor calls the computer program in the memory, the payment status updating method according to any one of claims 1 to 6 is executed.

9. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and the computer program is loaded by a processor to execute the steps in the payment status updating method according to any one of claims 1 to 6.

Images