Payment query system, method and computer program product

Abstract

The invention provides a payment query system and method and a computer program product, and relates to the technical field of communication. The payment query system can comprise a storage unit used for storing multiple levels of query queues arranged in sequence, and each level of query queue corresponds to a queue sequence number; the receiving unit is used for receiving a payment response request from a third-party payment server, obtaining payment order data to be queried according to the payment response request, and placing the payment order data to be queried in a first-level query queue of the multi-level query queues; the query task distribution unit is used for determining a query range of the query queue and generating a query task corresponding to the query queue according to the query range; and the query task processing unit is used for traversing payment order data in a query range corresponding to the query task so as to query a payment condition corresponding to the payment order data: when the payment condition is that payment is not completed, placing the payment order data into a next-level query queue of the current query queue.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a payment query system, method and computer program product. Background Art

[0002] With the rise and continuous development of mobile payment, the application scenarios supporting third-party payment are becoming more and more diversified. Third-party payment refers to an online payment model in which an independent institution with certain strength and credibility facilitates transactions between the two parties by connecting with UnionPay or China National Network Payment Corporation. Under the third-party payment model, after purchasing goods or services, the buyer can use the account provided by the third-party platform to make payments, that is, pay the money to the third party, and then the third party will notify the seller to ship or provide services; after the buyer completes the shipment or service, the third party can transfer the money to the seller's account regularly or in real time, thereby facilitating transactions between buyers and sellers.

[0003] In some special third-party payment scenarios, users may have difficulty in obtaining payment result notifications from third-party payments due to network environment limitations, resulting in a long transaction arrival time or failure to arrive. To this end, some embodiments of this specification provide a payment query system, method, and computer program product that can query the payment status of payment order data in a timely and efficient manner, and can simultaneously notify users of the payment status. Summary of the invention

[0004] One or more embodiments of the present specification provide a payment query system, the system comprising: a storage unit, used to store multi-level query queues arranged in sequence, each level of query queue corresponds to a queue number, wherein the multi-level query queue includes at least one query queue; a receiving unit, used to receive a payment response request from a third-party payment server, obtain payment order data to be queried according to the payment response request, and place the payment order data to be queried in a first-level query queue of the multi-level query queue; a query task allocation unit, used to determine the query range of the query queue for any query queue in the multi-level query queue, and generate a query task corresponding to the query queue according to the query range; a query task processing unit, used to traverse the payment order data within the query range corresponding to the query task to query the payment status corresponding to the payment order data: when the payment status is an unfinished payment, the payment order data is placed in the next-level query queue of the current query queue.

[0005] According to the system provided by one or more embodiments of the present specification, the payment order data includes a payment order code and a weight value corresponding to the payment order code; the weight value of the payment order code is calculated based on the queue number of the query queue in which the payment order data is currently located and the timestamp when the payment order data is placed in the current query queue.

[0006] According to the system provided by one or more embodiments of the present specification, any query queue in the multi-level query queue corresponds to a query time interval; the query time interval corresponding to the first-level query queue of the multi-level query queue is greater than the query time interval corresponding to the second-level query queue of the multi-level query queue; starting from the third-level query queue of the multi-level query queue, the query time interval corresponding to the previous-level query queue is less than the query time interval corresponding to the next-level query queue.

[0007] According to the system provided by one or more embodiments of the present specification, the query task allocation unit includes: for any query queue in the multi-level query queue, determining the query time range corresponding to the current query task according to the time cursor corresponding to the current query task, and the difference between the current timestamp and the query time interval corresponding to the query queue; determining the query range of the current query task based on the query time range corresponding to the current query task and the queue number.

[0008] According to the system provided by one or more embodiments of the present specification, for any query queue in the multi-level query queue, the initial value of the time cursor is 0; the value of the time cursor corresponding to the current query task is the maximum value of the query time range corresponding to the previous query task plus 1.

[0009] According to the system provided by one or more embodiments of the present specification, the query task allocation unit also includes: for any query queue in the multi-level query queue, determining whether the number of payment order data contained in the query range of the query queue is greater than a first preset threshold: if so, generating a query task corresponding to the query queue according to the query range.

[0010] According to the system provided by one or more embodiments of the present specification, the query task allocation unit also includes: for any query queue in the multi-level query queue, determining whether the query waiting time of the payment order data included in the query range of the query queue is greater than a second preset threshold: if so, providing the payment order data with a query waiting time greater than the second preset threshold to the query task corresponding to the query queue.

[0011] According to the system provided by one or more embodiments of the present specification, the query task processing unit includes a query process, and any query queue in the multi-level query queue corresponds to one or more query processes; the query process is used to obtain payment order data within the query range corresponding to the query task from the query queue stored in the storage unit according to the query task; and according to the order code in the payment order data, query the payment status corresponding to the payment order data from the third-party payment server.

[0012] According to the system provided by one or more embodiments of the present specification, the query task allocation unit further includes: determining whether the number of query processes used to execute the query task reaches a preset number; if not, additionally starting a query process used to execute the query task.

[0013] According to the system provided by one or more embodiments of the present specification, the query task processing unit includes: when the payment status is an unfinished payment and the payment order data is in the last level query queue in the multi-level query queue, closing the payment order corresponding to the payment order data and deleting the payment order data from the query queue.

[0014] According to the system provided by one or more embodiments of the present specification, the query task processing unit includes: when the payment status is payment completed, deleting the payment order data from the query queue and sending the payment status to the user terminal.

[0015] One or more embodiments of the present specification also provide a payment query method, which includes: receiving a payment response request from a third-party payment server, obtaining payment order data to be queried according to the payment response request, and placing the payment order data to be queried in a first-level query queue of a multi-level query queue, wherein the multi-level query queue includes at least one query queue, and each level of query queue corresponds to a queue sequence number; for any query queue in the multi-level query queue, determining the query range of the query queue, and generating a query task corresponding to the query queue according to the query range; traversing the payment order data within the query range corresponding to the query task to query the payment status corresponding to the payment order data: when the payment status is an unfinished payment, placing the payment order data in the next-level query queue of the current query queue.

[0016] One or more embodiments of the present specification also provide a computer program product, which includes computer instructions or a computer program. When at least part of the computer instructions or the computer program is executed by a processor, any of the aforementioned payment query methods can be implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] This specification will be further explained by way of exemplary embodiments, which will be described in detail by way of the accompanying drawings. The same numbers in the drawings represent the same structures or steps.

[0018] Figure 1 It is a schematic diagram of an application scenario of a third-party payment system including a local server according to some embodiments of this specification.

[0019] Figure 2 It is an exemplary structural diagram of a payment inquiry system shown in some embodiments of this specification.

[0020] Figure 3 It is a schematic diagram of changes in a multi-level query queue according to some embodiments of this specification.

[0021] Figure 4 It is an exemplary flow chart of a payment query method shown in some embodiments of this specification. DETAILED DESCRIPTION

[0022] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the embodiments will be described in detail below with reference to the accompanying drawings. Obviously, the contents described below are some examples or embodiments of this specification. For ordinary technicians in this field, without paying creative work, the technical solutions or means disclosed in this specification can also be applied to other scenarios based on these technical contents.

[0023] It should be understood that the "system", "device", "unit" and / or "module" used in this specification is a method for distinguishing different components, elements, parts, portions or assemblies at different levels. However, if other words can achieve the same purpose, the words can be replaced by other expressions.

[0024] Unless otherwise specified, technical terms used in this specification to describe components, elements, etc. do not refer to the singular, but may also include the plural. Generally speaking, terms such as "include", "comprise", etc. only indicate that the steps, elements, or components that have been clearly identified are included, and these steps, elements, and components do not constitute an exclusive list, such as the method or device described may also include other steps or components.

[0025] Flowcharts are used in this specification to illustrate the operation steps performed by the device or system of the relevant embodiments, but unless otherwise specified, the order used to describe these steps should not be understood as a limitation on the order in which the steps are performed. A person of ordinary skill in the art can adjust the order in which these steps are performed based on the knowledge and information conveyed by the embodiments of this specification, including but not limited to swapping the order, merging multiple steps, and splitting a certain step.

[0026] Figure 1 1 is a schematic diagram of an application scenario of a third-party payment system including a local server according to some embodiments of this specification. Figure 1As shown, in some embodiments, the third-party payment system 100 may include a client 110, a local server 120, and a third-party payment server 130. In the process of making a payment, the user may initiate a first payment request to the local server 120 through the client 110. After receiving the first payment request and completing the payment verification, the local server 120 may initiate a second payment request to the third-party payment server 130, and upon receiving the payment response fed back by the third-party payment server 130, the payment order number corresponding to the payment response is added to its own timed query queue, and then the third-party payment is called to the client 110, and the user completes the payment through the client 110.

[0027] In some embodiments, in some special third-party payment scenarios, users may have difficulty obtaining payment result notifications from third-party payment due to limited network environment and other reasons, resulting in a long transaction time or failure to receive transactions. For example, in the network service recharge system in the campus scenario, the payment system is deployed using a local server and external network access is prohibited. At this time, users who choose to use third-party payment cannot receive payment result notifications from third-party payment such as WeChat and Alipay, resulting in users not clicking to complete or return to the original page in time, and then the problem of being unable to trigger the active query order mechanism of the page occurs, making the payment unable to be received. In order to solve the above problem, in some embodiments, the local server 120 can select the payment order number with the payment status of unfinished payment from its own timed query queue according to the preset query frequency, and perform regular polling to the third-party payment server 130 to query the query payment status corresponding to the payment order number.

[0028] Based on the relevant description of the above embodiments, the acquisition of the query payment status corresponding to the payment order number is related to the preset query frequency of the local server 120: if the query frequency is too high, a large amount of query resources of the local server 120 may be consumed unnecessarily; if the query frequency is too low, the arrival time corresponding to the payment order number may be too long, and the query timeliness is difficult to guarantee. To this end, a payment query system is provided in some embodiments of this specification, which can realize timely and efficient query of the payment status of payment order data. Figure 2 is an exemplary structural diagram of an order payment query system according to some embodiments of this specification. Figure 2 The order payment query system 200 shown can be Figure 1 The local server 120 shown is implemented. In some embodiments, Figure 2 As shown, the order payment query system 200 may include the following functional unit modules.

[0029] The storage unit 210 is used to store the multi-level query queues arranged in sequence. Each level of the query queue corresponds to a queue sequence number, and the multi-level query queue includes at least one query queue. In some embodiments, the storage unit 210 can be stored as follows: Figure 1 The local server 120 implementation is shown.

[0030] In some embodiments, by setting up a multi-level query queue, the payment order data can be placed in these multi-level query queues according to different query payment situations, and by setting different query frequencies for each level of query queue, a step-by-step query of the payment order data can be achieved, which makes full use of the query resources of the local server and improves the query efficiency of the payment situation in a targeted manner. The specific setting of the payment order data in the multi-level query queue will be described in detail later, and will not be repeated here.

[0031] The receiving unit 220 is used to receive a payment response request from a third-party payment server, obtain the payment order data to be queried according to the payment response request, and place the payment order data to be queried in the first-level query queue of the multi-level query queue. In some embodiments, the receiving unit 220 can be configured as follows: Figure 1 The local server 120 implementation is shown.

[0032] In some embodiments of the present specification, the payment order data may include a payment order code and a weight value corresponding to the payment order code, wherein the order code may be used as a query basis for querying the payment status, and the weight value of the payment order code may be used as a basis for orderly storage of the payment order data in the storage unit 210 in sequence. In some embodiments, the weight value of the order code is calculated based on the queue number of the query queue where the payment order data is currently located and the timestamp when the payment order data is placed in the query queue where it is currently located. In some embodiments, the weight value of the order code may be represented as the queue number* The sum of the values ​​corresponding to the timestamp when the payment order data was placed into the current query queue.

[0033] The query task allocation unit 230 is used to determine the query range of any query queue in the multi-level query queues, and generate a query task corresponding to the query queue according to the query range.

[0034] In some embodiments of the present specification, the query task allocation unit 230 can divide the query range in turn according to the queue number of each level of the multi-level query queue and determine the corresponding query task according to the query range. In some embodiments, in the process of determining the query range of the current time, for any query queue in the multi-level query queue, the query time range corresponding to the current query task can be determined according to the time cursor corresponding to the current query task, and the difference between the current timestamp and the query time interval corresponding to the query queue, and then the query range of the current query task can be determined based on the query time range corresponding to the current query task and the queue number. The specific determination of the query time range will be further described below in conjunction with the embodiments.

[0035] In some embodiments, the time cursor refers to the starting time in the query time range corresponding to the current query task. In some embodiments, for any query queue in the multi-level query queue, the initial value of the time cursor is 0; the value of the time cursor corresponding to the current query task is the maximum value of the query time range corresponding to the previous query task plus 1, thereby ensuring that all payment order data placed in the query queue can be covered by the above-mentioned query range division method.

[0036] In some embodiments, the timestamp corresponding to the difference between the current timestamp and the query time interval corresponding to the query queue is used to determine the end time in the query time range, wherein the query time interval refers to the payment order data queried in the current query task is the payment order data in the query time interval before the current time. This is because the query frequency corresponding to each level of query queue is different. In the process of the query task allocation unit 230 continuously distributing tasks in a circular manner according to the order of the queue sequence number, the query frequency of each query queue can be distinguished by setting different query time intervals. In some embodiments, any query queue in the multi-level query queue corresponds to a query time interval, and considering the time consumption of the user performing payment operations in the first-level query queue in the multi-level query queue, the query time interval corresponding to the first-level query queue of the multi-level query queue can be set to be greater than the query time interval corresponding to the second-level query queue of the multi-level query queue. For example, the query time interval corresponding to the first-level query queue can be 25 seconds or 20 seconds, and the corresponding query time interval corresponding to the second-level query queue can be 15 seconds or 10 seconds.

[0037] In some embodiments, starting from the third level query queue of the multi-level query queue, the query time interval corresponding to the previous level query queue is less than the query time interval corresponding to the next level query queue. For example, taking the 7-level query queue as an example, the query time interval corresponding to the first level query queue can be set to 25 seconds or 20 seconds, the query time interval corresponding to the second level query queue can be set to 15 seconds or 10 seconds, the query time interval corresponding to the third level query queue can be set to 30 seconds or 20 seconds, the query time interval corresponding to the fourth level query queue can be set to 60 seconds or 50 seconds, the query time interval corresponding to the fifth level query queue can be set to 150 seconds or 100 seconds, the query time interval corresponding to the sixth level query queue can be set to 500 seconds or 400 seconds, and the query time interval corresponding to the seventh level query queue can be set to 900 seconds or 800 seconds. Through the above settings, for the query task allocation unit 230, in the process of continuously distributing tasks according to the order of queue sequence numbers, the generation time interval between two adjacent query tasks in each level query queue is at least the above query time interval, and the generation frequency of query tasks corresponding to query queues at all levels can be dynamically adjusted by setting the query time interval.

[0038] In some embodiments, based on the relevant description of the above embodiments, since the start time and end time of the query time range correspond to timestamp information, the same calculation method as the weight value of the payment order code can be used to obtain the query start value and query end value of the current query task based on the query time range and queue sequence number corresponding to the current query task, and select the payment order data corresponding to the weight value falling into the query range in the corresponding query queue according to the query range determined by the query start value and query end value as the payment order data within the query range. In some embodiments, the weight value of the order code can be represented as the queue sequence number* The sum of the values ​​corresponding to the timestamp when the payment order data is placed in the current query queue. Correspondingly, the query start value can be represented as the queue number* The sum of the values ​​of the time cursors corresponding to the current query task. The query termination value can be represented as the queue number* The sum of the differences between the current timestamp and the query time interval corresponding to the query queue.

[0039] The query task processing unit 240 is used to traverse the payment order data within the query range corresponding to the query task to query the payment status corresponding to the payment order data. In some embodiments, the query task processing unit 240 can be performed by Figure 1 The local server 120 implementation is shown.

[0040] In some embodiments, the query task processing unit 240 may be configured to place the payment order data into the next level query queue of the current query queue when the payment status is an unfinished payment. Based on the relevant description of the aforementioned embodiment, the payment order data obtained by the receiving unit 220 is uniformly placed in the first level query queue of the multi-level query queue before the initial query of the payment status. If the payment status queried in the first level query queue is an unfinished payment, the corresponding payment order data may be placed in the second level query queue of the next level, and the payment status of the payment order data may be queried again through the second level query queue. If the payment status queried in the second level query queue is still an unfinished payment, the payment order data may be placed in the third level query queue of the next level, and so on, thereby realizing a multi-level query of the payment status of the payment order data. In some embodiments, the query task processing unit 240 may also be configured to delete the payment order data from the current query queue when the payment status is a completed payment.

[0041] Figure 3 FIG. 1 is a schematic diagram of a multi-level query queue according to some embodiments of this specification. Figure 3 As shown, 310a and 320a correspond to the first-level query queue and the second-level query queue before the first query task corresponding to the first-level query queue, respectively. Taking the payment order data to be queried at this time as an example, all the payment order data to be queried are placed in the first-level query queue 310a, that is, the first-level query queue 310a contains payment order data 311 to 315, and the second-level query queue 320a does not contain any payment order data. 310b and 320b correspond to the first-level query queue and the second-level query queue after the first query task corresponding to the first-level query queue, respectively, wherein the query range corresponding to the first query task is payment order data 311 to 314. By comparing 310a and 310b, it can be seen that after the first query task is executed, the payment order data 315 that does not fall within the query scope still exists in the first-level query queue 310b, the payment order data 311 to 313 whose payment status is completed are deleted from the first-level query queue 310b, and the payment order data 314 whose payment status is unfinished payment is transferred from the first-level query queue 310a to the second-level query queue 320b.

[0042] The specific functional implementation of the query task processing unit 240 will be further explained and illustrated in conjunction with the embodiments below. In some embodiments of the present specification, the query task processing unit 240 includes a query process, wherein the query process can be used to query the payment order data.

[0043] In some embodiments, a process, as a basic concept in a computer, refers to an instance of a running program and is the basic unit for resource allocation in the system, while a query process is a query resource configured by the query task processing unit 240 for each level of the query queue in the multi-level query queue. In some embodiments, the query process can be used to obtain payment order data within the query range corresponding to the query task from the query queue stored in the storage unit 210 according to the query task, thereby obtaining the query object. In some embodiments, the query process can be used to parse the obtained payment order data to obtain the order code therein, and query the payment status corresponding to the payment order data from the third-party payment server according to the order code, thereby obtaining the query target of the payment status. In some embodiments, the query process can be started or terminated as needed. In order to reduce the query resource consumption of the local server, a single query process can be set to terminate the query process when the query task is not obtained, or it can be set to terminate the query process after a preset period of time when the query task is not obtained. In some embodiments, for a single query task, it can be executed independently by a query process, or it can be executed concurrently by multiple query processes to improve the query efficiency of whether the payment order data has been paid. A single query process can also independently execute one or more query tasks.

[0044] In some embodiments, any query queue in the multi-level query queue corresponds to one or more query processes. In some instances, for the query queues with the front queue numbers in the multi-level query queue, multiple query processes can be set for these query queues. Taking the first-level query queue in the multi-level query queue as an example, since all the payment order data received from the third-party payment server need to be placed in the first-level query queue first, that is, all the payment order data need to be queried through the first-level query queue for payment status, multiple query processes, such as 3 or 5, can be set for the first-level query queue. In other instances, for the query queues with the back queue numbers in the multi-level query queue, since the payment order data received therein are all payment order data with unfinished payment status in the upper query queue, the number of payment order data included is relatively small, and the processing load is relatively low, and only one query process can be set for these query queues. In other embodiments, the same query process can also correspond to two or more query queues, for example, the sixth-level query queue and the seventh-level query queue in the multi-level query queue can share a query process, and the query process can process the query tasks corresponding to the sixth-level query queue and the seventh-level query queue.

[0045] In order to further improve the efficiency of querying the payment status of payment order data, in some embodiments of the present specification, the query task allocation unit 230 can also be configured to determine whether the number of query processes used to execute the query task has reached a preset number: if not, an additional query process for executing the query task is started.

[0046] In some embodiments, based on the relevant description of the aforementioned embodiments, the query process can be terminated when the query task is not executed to reduce the overall query resource consumption. In order to ensure that there are a sufficient number of query processes to efficiently execute the query task during the execution of the query task, in some embodiments, the query task allocation unit 230 can check whether the number of query processes started corresponding to the query queue at this level reaches the preset maximum number threshold each time the query task corresponding to the query queue is generated according to the query range: if the maximum number threshold is not reached, it means that the number of query processes used to execute the current query task does not reach the maximum number of query processes that can execute the query task at the same time. At this time, a new query process can be started additionally through the query task allocation unit 230 to execute the query task, so that multiple query processes execute the current query task at the same time, which improves the query efficiency of querying the payment status of the payment order data. Taking the first-level query queue in the multi-level query queue as an example, the maximum value of the number of query processes corresponding to the first-level query queue is set to 5. Then, when the number of query processes corresponding to the first query queue is 3, it means that the maximum number threshold has not been reached. At this time, when the query task allocation unit 230 generates a query task corresponding to the query queue according to the query range, a new query process can be additionally started to execute the current query task together with the three query processes that have been started, so as to improve the query efficiency of the payment status of the payment order data. In some embodiments, the query task allocation unit 230 can also be configured to start one or more query processes for executing the query task when the number of query processes for executing the query task does not reach the preset number, so that the number of query processes for executing the query task after startup is less than or equal to the preset number.

[0047] Based on the relevant description of the aforementioned embodiment, the query resource consumption of the local server can be reduced by terminating the query process when the query task is not executed. In order to further reduce the query resource consumption of the local server, in some embodiments of the present specification, the query task allocation unit 230 can also be configured to determine whether the number of payment order data included in the query range of any query queue in the multi-level query queue is greater than the first preset threshold: if so, generate a query task corresponding to the query queue according to the query range.

[0048] In some embodiments, when the amount of payment order data included in the query range of the query queue is greater than the first preset threshold, it means that the amount of payment order data included in the query range is sufficient, and the amount of payment order data included in the query task generated at this time can fully call the query resources of the query task processing unit 240, such as the query process, etc., and there will be no situation where a single query process lacks sufficient payment order data for query after it is started. In some embodiments, when the amount of payment order data included in the query range of the query queue does not reach the first preset threshold, the query task corresponding to the query queue may not be generated temporarily according to the query range, and the amount of payment order data included in the query range may be re-determined when the query task of the query queue is polled next time, thereby avoiding the frequent opening of new query processes to execute query tasks and reducing the overall query resource consumption.

[0049] In some embodiments, for query queues with relatively early queue numbers in a multi-level query queue, since the payment order data contained in the query queue is often just generated or generated not long ago, before generating a query task corresponding to the query queue according to the query range, it is first determined whether the number of payment order data contained in the query range is greater than a preset threshold, which can avoid frequently generating query tasks and starting new query processes when the generated payment order data is small, thereby reducing the query resource consumption of the local server; but for query queues with relatively late queue numbers in a multi-level query queue, the payment order data contained in these query queues are all payment order data whose payment status in the upper-level query queue is unfinished payment. In the process of users normally initiating payment orders and making payments, the number of payment order data contained in query queues with late queue numbers is usually maintained in a smaller range relative to the number of payment order data contained in query queues with early queue numbers. It may happen that after multiple rounds of queries, the number of payment order data contained in the query range of the query queue is still at a smaller number, resulting in the inability to generate query tasks corresponding to the query queue according to the query range. To this end, in some embodiments, for each level of query queue in a multi-level query queue, its corresponding first preset threshold can be dynamically configured. For example, the first preset threshold set for the query queue with a later queue number in the multi-level query queue can be configured to be smaller than the first preset threshold set for the query queue with an earlier queue number in the multi-level query queue. This reduces the overall query resource consumption while ensuring that the payment order data in each level of query queue can generate a query task corresponding to the query queue according to the query range within an appropriate query round, thereby ensuring the query timeliness of the payment order data in each level of query queue in the multi-level query queue.

[0050] Based on the relevant description of the aforementioned embodiment, in order to reduce the overall query resource consumption, a quantity threshold of the payment order data can be set when generating a query task corresponding to the query queue according to the query range, and the corresponding query task can be generated again when the number of payment order data reaches the set quantity threshold. However, in some time periods or scenarios with less payment order data, the above settings will cause some payment order data to not be provided to the query task for query for a long time. In order to ensure the timeliness of the query of payment order data, in some embodiments of the present specification, the query task allocation unit 230 can also be configured to determine whether the query waiting time of the payment order data included in the query range of the query queue is greater than the second preset threshold for any query queue in the multi-level query queue: if so, the payment order data with a query waiting time greater than the second preset threshold is provided to the query task corresponding to the query queue.

[0051] In some embodiments, the query waiting time of the payment order data may refer to the time from when the payment order data is placed in the current query queue to when the query range is determined in the current query round. The query task allocation unit 230 can obtain the query waiting time through the current timestamp and the weight value of the payment order code in the payment order data, and compare it with the preset second preset threshold. In some embodiments, when the query waiting time is greater than the second preset threshold, it means that the payment order data has been waiting for too long to query the payment situation, and it is necessary to query the payment situation of the payment order data in a timely manner. For this purpose, the query task allocation unit 230 can provide the payment order data to the query task corresponding to the query queue, and then the query task processing unit 240 queries the payment order data that has not been queried for a long time. In some embodiments, the second preset threshold can be set to 5 seconds or 4 seconds, so for the payment order data with a query waiting time greater than 5 seconds or 4 seconds, regardless of whether the quantity meets the preset quantity threshold, it will be provided to the query task corresponding to the query queue, thereby ensuring the query timeliness of the payment order data, and effectively avoiding abnormal scenarios such as some payment order data not being queried for a long time, resulting in a long arrival time.

[0052] In some embodiments of the present specification, the query task processing unit 240 may also be configured to close the payment order corresponding to the payment order data and delete the payment order data from the query queue when the payment status is an unfinished payment and the payment order data is in the last level query queue in the multi-level query queue.

[0053] In some embodiments, based on the description of the aforementioned embodiments, since the query task processing unit 240 will place the payment order data into the next-level query queue of the current query queue when the payment status corresponding to the payment order data is an unfinished payment, when the payment order data is in the last-level query queue in the multi-level query queue, it means that the payment status of the payment order data in the query tasks corresponding to each previous level of the query queue is an unfinished payment; and for the payment order data in the last-level query queue in the multi-level query queue, if the payment status obtained by the query task processing unit 240 is still an unfinished payment, it means that the multiple payment situations previously experienced are all unfinished payments, and it can be determined that the user has no payment intention for the payment order corresponding to the payment order data or the payment order has expired. At this time, the query task processing unit 240 can be set to close the corresponding payment order for the payment order data in the last-level query queue whose payment status is an unfinished payment, and remove the payment order data from the query queue, so as to avoid repeated polling queries on the payment order status for a long time for the payment order that the user has no payment intention, thereby saving the overall resource overhead of the payment query system 200.

[0054] In some embodiments of the present specification, the query task processing unit 240 may also be configured to delete the payment order data from the query queue and send the payment status to the user terminal when the payment status is payment completed.

[0055] In some embodiments, the query process in the query task processing unit 240 can be used to query the payment status. For details, please refer to the relevant description of the aforementioned embodiment, which will not be repeated here. In some embodiments, when the query process in the query task processing unit 240 finds that the payment status corresponding to the payment order data is completed through the query, it means that the user has completed the payment of the order to the third-party payment system through the terminal device including the user terminal, and the third-party payment system has successfully received the payment corresponding to the order. At this time, it means that the entire payment process of the payment order has been completed, that is, there is no subsequent payment query demand for "whether the order has been completed". In this case, the payment order data corresponding to the payment order can be deleted from the query queue, so as to avoid the payment order data corresponding to the payment order from being repeatedly queried in the subsequent order query process, causing unnecessary performance loss.

[0056] In some embodiments, when the payment status is completed, the payment status of "completed payment" can also be sent to the user end through the query task processing unit 240 to inform the corresponding user of the user end that the order has completed the payment to the third-party payment system, so that the corresponding user of the user end can also know the status of the order completion payment in the first time, thereby improving the payment experience of the corresponding user of the user end.

[0057] In some embodiments of the present specification, a payment query method is also provided. Figure 4 is an exemplary flow chart of a payment query method according to some embodiments of this specification. Figure 4 The process 400 shown may be executed by a processing device, for example, Figure 1 The local server 120 shown in the figure is implemented, and specifically can be implemented by the order payment query system 200 deployed on the processing device. In some embodiments, Figure 4 As shown, process 400 may include the following steps.

[0058] Step 410: Receive a payment response request from a third-party payment server, obtain the payment order data to be queried according to the payment response request, and place the payment order data to be queried in the first-level query queue of the multi-level query queue. Based on the relevant description of the aforementioned embodiment, the multi-level query queue may include at least one query queue, and each level of the query queue corresponds to a queue number, which will not be described in detail here. In some embodiments, step 410 may be implemented by the receiving unit 220 and the storage unit 210. In some embodiments, the receiving unit 220 and the storage unit 210 may also be the same unit.

[0059] Step 420: For any query queue in the multi-level query queue, determine the query range of the query queue, and generate a query task corresponding to the query queue according to the query range. In some embodiments, the specific implementation of step 420 can refer to the relevant description of the query task allocation unit 230 in the aforementioned embodiment, which is not repeated here. In some embodiments, step 420 can be implemented by the query task allocation unit 230.

[0060] Step 430: traverse the payment order data within the query range corresponding to the query task to query the payment status corresponding to the payment order data: when the payment status is an unfinished payment, place the payment order data into the next level query queue of the current query queue. In some embodiments, the specific implementation of step 430 can refer to the relevant description of the query task processing unit 240 in the aforementioned embodiment, which will not be repeated here. In some embodiments, step 430 can be implemented by the query task processing unit 240.

[0061] Some embodiments of the present specification also provide a computer program product, including computer instructions or computer codes, which, when at least part of the computer instructions or the computer codes are executed by a processor, can implement the payment query method described in some embodiments of the present specification.

[0062] Specifically, in some embodiments of the present specification, a computer program product may only involve computer instructions or computer codes, which may be carried by a storage medium or a processing device; while in other embodiments of the present specification, a computer program product may also be a storage medium or a processing device containing the aforementioned computer instructions or computer codes, wherein the processing device may include one or more processors, and a storage medium.

[0063] In some embodiments of the present specification, the processor may be a combination of one or more of the following processors: a central processing unit (CPU), an application specific integrated circuit (ASIC), an application specific instruction set processor (ASIP), a graphics processing unit (GPU), a physical processing unit (PPU), a digital signal processor (DSP), a field programmable gate array (FPGA), a programmable logic device (PLD), a programmable logic controller (PLC), a reduced instruction set computer (RISC), and a microprocessor.

[0064] In some embodiments of the present specification, the above-mentioned storage medium may include one or more combinations of the following: mass storage, removable storage, volatile read-write memory, read-only memory (ROM). Exemplary mass storage may include magnetic disks, optical disks, solid-state hard disks, etc. Exemplary removable storage may include flash disks, floppy disks, optical disks, memory cards, compressed hard disks, magnetic tapes, etc. Exemplary volatile read-write memory may include random access memory (RAM). Exemplary random access memory may include dynamic random access memory (DRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), static random access memory (SRAM), thyristor random access memory (T-RAM) and zero capacitance memory (Z-RAM), etc. Exemplary read-only memory may include masked read-only memory (MROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), compact disk read-only memory (CD-ROM) and digital multifunction hard disk read-only memory, etc.

[0065] The beneficial effects that may be brought about by the embodiments of this specification include but are not limited to: (1) By setting a multi-level query queue, configuring different query times for each level of query queue, and delegating the payment order data whose payment status is not completed in the multi-level query queue step by step, thereby reducing the query resource consumption and realizing timely and efficient query of the payment status of the payment order data. (2) When the query task is not executed, the query process can be terminated to reduce the query resource consumption. At the same time, when the query task is generated, one or more new query processes are started to concurrently process the query task to improve the query efficiency. (3) When generating the query task corresponding to the query queue according to the query range, a threshold value of the number of payment order data is set, and when the number of payment order data reaches the set threshold value, the corresponding query task is generated again to reduce the query resource consumption. (4) The query is performed for the payment order data whose query waiting time is greater than the preset threshold, thereby ensuring the query timeliness of the payment order data. It should be noted that different embodiments may produce different beneficial effects. In different embodiments, the beneficial effects that may be produced may be any one or a combination of the above, or any other beneficial effects that may be obtained.

[0066] The basic concepts have been described above. Obviously, for those skilled in the art, the above detailed disclosure is only for example and does not constitute a limitation of this specification. Although not explicitly stated here, those skilled in the art may make various modifications, improvements and corrections to this specification. Such modifications, improvements and corrections are taught in this specification, so such modifications, improvements and corrections still belong to the spirit and scope of the exemplary embodiments of this specification.

Claims

1. A payment inquiry system, characterized in that: The system comprises: A storage unit, used to store multi-level query queues arranged in sequence, each level of query queue corresponds to a queue sequence number, wherein the multi-level query queues include at least one query queue; a receiving unit, configured to receive a payment response request from a third-party payment server, obtain payment order data to be queried according to the payment response request, and place the payment order data to be queried in a first-level query queue of the multi-level query queue; A query task allocation unit, configured to determine a query range of any query queue in the multi-level query queues, and generate a query task corresponding to the query queue according to the query range; The query task processing unit is used to traverse the payment order data within the query range corresponding to the query task to query the payment status corresponding to the payment order data; when the payment status is an unfinished payment, the payment order data is placed in the next level query queue of the current query queue.

2. The payment inquiry system according to claim 1, characterized in that: The payment order data includes a payment order code and a weight value corresponding to the payment order code; The weight value of the payment order code is calculated based on the queue number of the query queue where the payment order data is currently located, and the timestamp when the payment order data is placed in the current query queue.

3. The payment inquiry system according to claim 1 or 2, characterized in that: Any query queue in the multi-level query queue corresponds to a query time interval; The query time interval corresponding to the first level query queue of the multi-level query queue is greater than the query time interval corresponding to the second level query queue of the multi-level query queue; Starting from the third level query queue of the multi-level query queue, the query time interval corresponding to the previous level query queue is smaller than the query time interval corresponding to the next level query queue.

4. The payment inquiry system according to claim 3, characterized in that: The query task allocation unit comprises: For any query queue in the multi-level query queue, determine the query time range corresponding to the current query task according to the time cursor corresponding to the current query task and the difference between the current timestamp and the query time interval corresponding to the query queue; The query range of the current query task is determined based on the query time range corresponding to the current query task and the queue sequence number.

5. The payment inquiry system according to claim 4, characterized in that: For any query queue in the multi-level query queue, the initial value of the time cursor is 0; The value of the time cursor corresponding to the current query task is the maximum value of the query time range corresponding to the previous query task plus 1.

6. The payment inquiry system according to claim 1, characterized in that: The query task allocation unit also includes: For any query queue in the multi-level query queue, determine whether the number of payment order data contained in the query range of the query queue is greater than a first preset threshold: if so, generate a query task corresponding to the query queue according to the query range.

7. The payment inquiry system according to claim 6, characterized in that: The query task allocation unit also includes: For any query queue in the multi-level query queue, determine whether the query waiting time of the payment order data included in the query range of the query queue is greater than a second preset threshold: If so, the payment order data whose query waiting time is greater than the second preset threshold is provided to the query task corresponding to the query queue.

8. The payment inquiry system according to claim 1, characterized in that: The query task processing unit includes a query process, and any query queue in the multi-level query queue corresponds to one or more query processes; The query process is used to obtain payment order data within the query range corresponding to the query task from the query queue stored in the storage unit according to the query task; as well as According to the order code in the payment order data, the payment status corresponding to the payment order data is queried from the third-party payment server.

9. The payment inquiry system according to claim 8, characterized in that: The query task allocation unit also includes: Determine whether the number of the query processes used to execute the query task reaches the preset number: If not, an additional query process for executing the query task is started.

10. The payment inquiry system according to claim 1, characterized in that: The query task processing unit comprises: When the payment status is an unfinished payment and the payment order data is in the last level query queue in the multi-level query queue, the payment order corresponding to the payment order data is closed, and the payment order data is deleted from the query queue.

11. The payment inquiry system according to claim 1, characterized in that: The query task processing unit comprises: When the payment status is payment completion, the payment order data is deleted from the query queue, and the payment status is sent to the user terminal.

12. A payment inquiry method, characterized in that: include: receiving a payment response request from a third-party payment server, obtaining payment order data to be queried according to the payment response request, and placing the payment order data to be queried in a first-level query queue of a multi-level query queue, wherein the multi-level query queue includes at least one query queue, and each level of the query queue corresponds to a queue sequence number; For any query queue in the multi-level query queues, determining a query range of the query queue, and generating a query task corresponding to the query queue according to the query range; The payment order data within the query range corresponding to the query task is traversed to query the payment status corresponding to the payment order data; when the payment status is an unfinished payment, the payment order data is placed in a next-level query queue of the current query queue.

13. A computer program product, characterized in that It comprises computer instructions or a computer program, and when at least part of the computer instructions or the computer program is executed by a processor, the payment query method as claimed in claim 12 can be implemented.

Images