Method and apparatus for monitoring quick repossessing transaction, electronic device and storage medium
By proactively polling and differentiating quick redemption orders that have not yet received their final status in internet finance transactions, the problem of low fund arrival success rate has been solved, achieving high efficiency and accuracy in fund arrival and improving user experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINA ASSET MANAGEMENT CO LTD
- Filing Date
- 2026-02-09
- Publication Date
- 2026-06-19
AI Technical Summary
In internet finance, the success rate of quick redemption transactions is low. It is affected by network anomalies, bank processing delays, or incorrect card numbers, resulting in a poor user experience and fund management risks.
By actively setting monitoring time limits, pending payment orders that have not received a final status are marked as pending polling orders, and a differentiated polling mechanism is executed. Priority is determined based on the order's time identifier and retention time, and the status is queried at different intervals until the order status is confirmed as the final status. Finally, a final verification is performed in conjunction with the reconciliation file, and a pending task is generated.
It improved the success rate of fund arrival, reduced transaction delays caused by temporary technical glitches, enhanced the efficiency and accuracy of fund arrival, and reduced user risk.
Smart Images
Figure CN122243497A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of internet finance, and in particular to a method, apparatus, electronic device, and storage medium for monitoring quick redemption transactions. Background Technology
[0002] Currently, in the internet finance sector, money market funds have become the mainstream due to their high liquidity and fast redemption service.
[0003] However, in the existing fast redemption process, due to network anomalies, bank processing delays, or incorrect card numbers, the success rate of user funds arriving is low. This not only affects user experience but may also cause risks in fund management. Summary of the Invention
[0004] Therefore, it is necessary to provide a monitoring method, device, electronic device, and storage medium for fast redemption transactions to address the aforementioned technical issues and improve the success rate of user funds arriving in their accounts.
[0005] In a first aspect, embodiments of this application provide a method for monitoring quick redemption transactions, including: In response to the quick redemption instruction sent by the client, a payment request is initiated to the payment institution, generating a pending payment order. For a pending payment order, if no final status instruction is received from the payment institution, the pending payment order without a final status instruction is marked as a pending polling order. At least one round of polling is performed on the pending polling order until the payment status of the pending polling order is confirmed as the final status, which includes payment success and payment failure.
[0006] In one embodiment, at least one round of polling is performed on the orders to be polled until the payment status of the orders to be polled is confirmed as the final status. This includes: integrating all orders to be polled into a polling task list; determining the polling priority of the orders to be polled based on their time identifiers; the polling priority includes a first priority and a second priority; the first priority takes precedence over the second priority; for orders to be polled in the first priority queue, a status query is performed at a first query time interval; for orders to be polled in the second priority queue, a status query is performed at a second query time interval, where the first query time is less than the second query time; and updating the status of the orders to be polled in response to the query results of each order from the payment institution, until the payment status of the orders to be paid is confirmed as the final status.
[0007] In one embodiment, determining the polling priority of an order to be polled based on its time identifier includes: if the cumulative dwell time of an order to be polled is greater than a first time threshold and less than or equal to a second time threshold, then the order to be polled is assigned to a first priority queue; if the cumulative dwell time of an order to be polled is less than or equal to the first time threshold, then the order to be polled is assigned to a second priority queue.
[0008] In one embodiment, the method further includes: when the cumulative dwell time of any pending order exceeds a second duration threshold, an alarm is triggered and a first pending task is generated.
[0009] In one embodiment, updating the status of the order to be polled includes: if the received status of the order to be polled is "processing", then keeping the order to be polled in the current polling task list; if the received status of the order to be polled is "payment successful" or "payment failed", then removing the order to be polled from the current polling task list and recording the final status of the order to be polled as "payment successful" or "payment failed"; if the received status of the order to be polled is "order does not exist", then removing the order to be polled from the current polling task list and recording the final status of the order to be polled as "payment failed".
[0010] In one embodiment, after updating the status of the order to be polled, the method further includes: obtaining a reconciliation file within a preset time period, the reconciliation file including a payment transaction number and the payment result corresponding to the payment transaction number; searching for the corresponding quick redemption order based on the payment transaction number; if the corresponding quick redemption order is found, comparing whether the payment result is consistent with the final status of the quick redemption order; if the comparison result shows that the two statuses are inconsistent, triggering a system alarm; when the comparison result shows that both statuses are payment failures, generating a second pending task.
[0011] In one embodiment, before generating the order to be transferred, the process includes: querying the system history based on the order number of the current quick redemption instruction; if a record with the same order number and a payment status of successful transfer is found, the request operation of the quick redemption instruction is terminated.
[0012] Secondly, embodiments of this application provide a quick redemption order monitoring device, including: The payment request module is used to respond to the quick redemption instruction sent by the client, initiate a payment request to the payment institution, and generate a payment order to be paid; the polling and marking module is used to mark the payment order to be paid as a pending polling order if no payment success instruction is received from the payment institution; the order polling module is used to perform at least one round of polling on the pending polling order until the payment status of the payment order is confirmed as the final status, which includes payment success and payment failure.
[0013] In one embodiment, the order polling module is used to integrate all pending orders into a polling task list; and to determine the polling priority of pending orders based on their time identifiers; the polling priority includes a first priority and a second priority; the first priority takes precedence over the second priority; for pending orders in the first priority queue, a status query is performed at a first query interval; for pending orders in the second priority queue, a status query is performed at a second query interval, where the first query interval is shorter than the second query interval; in response to the payment institution's query results for each pending order, the status of the pending orders is updated until the payment status of the pending orders is confirmed as the final status.
[0014] In one embodiment, the order polling module is configured to assign the orders to be polled to a first priority queue if the cumulative dwell time of the orders to be polled is greater than a first duration threshold and less than or equal to a second duration threshold; and to assign the orders to be polled to a second priority queue if the cumulative dwell time of the orders to be polled is less than or equal to the first duration threshold.
[0015] In one embodiment, the order polling module is used to trigger an alarm and generate a first pending task when the cumulative dwell time of any pending order exceeds a second duration threshold.
[0016] In one embodiment, the order polling module is configured to keep the order in the current polling task list if the received status of the order to be polled is "processing"; if the received status of the order to be polled is "payment successful" or "payment failed", remove the order from the current polling task list and record the final status of the order as "payment successful" or "payment failed"; if the received status of the order to be polled is "order does not exist", remove the order from the current polling task list and record the final status of the order as "payment failed".
[0017] In one embodiment, the quick redemption order monitoring device further includes a reconciliation module, used to obtain reconciliation files within a preset time period. The reconciliation files include payment transaction numbers and the corresponding payment results. Based on the payment transaction number, the corresponding quick redemption order is searched. If the corresponding quick redemption order is found, the payment result is compared with the final status of the quick redemption order. If the comparison result shows that the two statuses are inconsistent, a system alarm is triggered. When the comparison result shows that both statuses are "payment failure", a second pending task is generated.
[0018] In one embodiment, the payment request module is used to query the system history based on the order number of the current quick redemption instruction; if a record with the same order number and a payment status of successful payment is found, the quick redemption instruction request operation is terminated.
[0019] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the first aspect and any possible implementation method.
[0020] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the method of the first aspect and any possible implementation.
[0021] The beneficial effects of this application are as follows: In fast redemption transactions, if the final status of an order awaiting payment is not received due to communication uncertainties, the system no longer passively waits for the final response from the payment institution. Instead, it proactively sets a monitoring period. Once the final status is not received, the order is deemed to have an unresolved status risk and is immediately marked as an order awaiting polling. At least one round of polling is performed on these orders until their payment status is confirmed as final. By proactively adopting an order polling mechanism to confirm the final status of orders awaiting payment, transactions on the verge of failure due to temporary technical glitches can be effectively identified and salvaged, thereby improving the success rate of fund arrival. Attached Figure Description
[0022] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0023] Figure 1 This is a flowchart illustrating a method for monitoring quick redemption transactions in one embodiment; Figure 2 This is a structural block diagram of a monitoring device for quick redemption transactions in one embodiment; Figure 3 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation
[0024] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.
[0025] The terms "first" and "second" in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising" and any variations thereof are intended to cover non-exclusive protection. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. The term "multiple" in this application can mean at least two, for example, two, three, or more, and the embodiments of this application do not impose limitations.
[0026] To facilitate understanding of the technical solutions provided in the embodiments of this application, the design concept of the embodiments of this application will be introduced first below: In the internet finance sector, the fast redemption service of money market funds has become an industry standard due to its "T+0" settlement experience. This service is achieved through a "funding-clearing" model: when a user initiates redemption, the funding party first advances the funds, and the funds are subsequently repaid through the fund clearing process.
[0027] However, this business, which relies heavily on a distributed architecture and real-time payment network, faces frequent order anomalies due to network failures and other reasons in actual operation, making it difficult to guarantee the success rate of payment.
[0028] For example, due to real-time interaction with the gateway, network jitter, interface timeout, instantaneous congestion of the other party's system, or even bank card malfunction, the payment instruction may be "lost" or the response may be lost, leaving the transaction status unknown.
[0029] Furthermore, the traditional initiation-wait processing model cannot distinguish between "true failure" and "false failure". For "false failure" caused by temporary problems such as network latency, the system often simply marks it as a final failure, lacking proactive query and intelligent retry mechanisms, resulting in a large number of recoverable transactions being delayed and reducing the efficiency of fund arrival.
[0030] Therefore, this application proposes a monitoring method, device, electronic device, and storage medium for fast redemption transactions. It constructs a status assurance system embedded within the process that proactively detects anomalies, makes intelligent decisions, and performs real-time risk control. Instead of passively waiting for the final response from the payment institution, it proactively sets a monitoring time limit. Once the final status is not received, it determines that the order has an unresolved status risk and immediately marks it as a pending query order. At least one round of querying is performed on the pending query order until the payment status of the pending query order is confirmed as the final status. This effectively identifies and recovers transactions that are on the verge of failure due to temporary technical failures, thereby improving the success rate of fund arrival.
[0031] The following section provides a detailed description of the fast redemption transaction monitoring method proposed in this application: In one embodiment, such as Figure 1 As shown, a method for monitoring fast redemption transactions is provided, including the following steps: Step S101: In response to the quick redemption instruction sent by the client, initiate a transfer request to the payment institution and generate a transfer order.
[0032] In some possible embodiments, before generating the order to be transferred, the process further includes: querying the system history based on the order number of the current quick redemption instruction; if a record with the same order number and a payment status of successful transfer is found, the request operation of the quick redemption instruction is terminated.
[0033] Step S102: For pending payment orders, if no final status instruction is received from the payment institution, the pending payment orders for which no final status instruction has been received are marked as pending polling orders.
[0034] The following description uses a specific embodiment as an example: In response to a user's quick redemption instruction initiated on the client, a pending payment order is generated, and a payment request is sent to a payment institution (such as a bank). Based on the real-time response from the payment institution, the payment status of the order is updated: if a clear success instruction is received, it is updated to "Payment Successful"; if a failure instruction is received, it is updated to "Payment Failed"; if no final status instruction is received from the payment institution (e.g., if an instruction indicating receipt and processing is received), it is updated to "Payment Processing"; if no response instruction is received due to network anomalies or other reasons, it is updated to "Network Anomaly." The pending payment orders corresponding to these two types of response results are then marked as pending polling orders.
[0035] In one embodiment, the failure to receive a final status instruction from the payment institution may be due to reasons such as network anomalies, incorrect customer card numbers, or abnormal account status.
[0036] Step S103: Perform at least one round of polling on the order to be polled until the payment status of the order to be polled is confirmed as the final status, which includes payment success and payment failure.
[0037] In some possible embodiments, at least one round of polling is performed on the orders to be polled until the payment status of the orders to be polled is confirmed as the final state. This includes: consolidating all orders to be polled into a polling task list; determining the polling priority of the orders to be polled based on their timestamps; the polling priority includes a first priority and a second priority; the first priority takes precedence over the second priority; for orders to be polled in the first priority queue, a status query is performed at a first query interval; for orders to be polled in the second priority queue, a status query is performed at a second query interval, where the first query interval is shorter than the second query interval; in response to the payment institution's query results for each order to be polled, the status of the orders to be polled is updated until the payment status of the orders to be paid is confirmed as the final state. This differentiated scheduling strategy can utilize system resources more efficiently, prioritizing the tracking of transactions most likely to produce results quickly.
[0038] As a concrete example, orders pending inquiry for the same day with a status of "processing payment" are assigned to the first priority queue, and their status is checked at the first query interval (e.g., every 2 minutes); orders with a status of "abnormal" or not for the current day are assigned to the second priority queue, and their status is checked at the second query interval (e.g., every 10 minutes). It can be seen that this differentiated scheduling strategy can utilize system resources more efficiently, prioritizing the tracking of transactions most likely to produce results quickly.
[0039] In addition to prioritizing polling based on order status, priority queues can also be distinguished based on dwell time: In some possible embodiments, determining the polling priority of the orders to be polled based on their time identifiers includes: if the cumulative dwell time of the orders to be polled is greater than a first time threshold and less than or equal to a second time threshold, then the orders to be polled are assigned to a first priority queue; if the cumulative dwell time of the orders to be polled is less than or equal to the first time threshold, then the orders to be polled are assigned to a second priority queue.
[0040] It should be noted that the priority of pending orders is not fixed. As time goes on, when the pending order in the second priority queue has been in the queue for a period of time that exceeds the first time threshold but is less than or equal to the second time threshold, it will be automatically moved to the first priority queue and a higher frequency polling strategy will be applied immediately.
[0041] In some possible embodiments, the method further includes: triggering an alarm and generating a first pending task when the cumulative dwell time of any pending order exceeds a second duration threshold.
[0042] Specifically, if the cumulative dwell time of pending orders is too long, a key alert should be issued, and a first pending task should be generated for manual verification.
[0043] In summary, polling priority can be determined based on latency, enabling focused monitoring and high-frequency probing of long-latent orders, while new orders are monitored at a standard frequency. This concentrates limited computing resources and network bandwidth on the most critical transactions. This avoids the invalid query load caused by a large number of pending orders that are about to complete naturally, thus improving the overall processing efficiency of the polling system.
[0044] In some possible embodiments, updating the status of the order to be polled includes: if the received status of the order to be polled is "processing", then keeping the order to be polled in the current polling task list; if the received status of the order to be polled is "payment successful" or "payment failed", then removing the order to be polled from the current polling task list, and recording the final status of the order to be polled as "payment successful" or "payment failed"; if the received status of the order to be polled is "order does not exist", then removing the order to be polled from the current polling task list, and recording the final status of the order to be polled as "payment failed".
[0045] By continuously polling, each pending order is proactively and forcibly determined to have a final state (success or failure). This reduces the number of quick redemption orders that will remain indefinitely in the intermediate state, effectively identifies and recovers transactions that are on the verge of failure due to temporary technical glitches, thereby improving the success rate of funds arriving in the account.
[0046] To further ensure the accuracy of fund transfers, in some possible embodiments, after updating the status of the orders to be polled, the process further includes: obtaining a reconciliation file within a preset time period, the reconciliation file including a payment transaction number and the corresponding payment result; searching for the corresponding quick redemption order based on the payment transaction number; if the corresponding quick redemption order is found, comparing whether the payment result is consistent with the final status of the quick redemption order; if the comparison result shows that the two statuses are inconsistent, triggering a system alarm; when the comparison result shows that both statuses are fund transfer failures, generating a second pending task.
[0047] As a concrete example, at a fixed time on each transaction day (T day) (e.g., 10:00 AM on T+1), the reconciliation file for the previous clearing cycle (e.g., from 10:00 PM the previous day to 10:00 PM on the current day) is downloaded from the payment institution's (bank's) server via a secure channel (e.g., SFTP). The reconciliation file is then decrypted, parsed, and standardized into structured data containing key fields such as payment serial number, transaction amount, transaction time, and transaction status.
[0048] Iterate through each record in the reconciliation file, using its payment transaction number as a unique identifier, and query the redemption order table in the system database: For each successfully linked record pair (reconciliation file - redemption order), the system performs rigorous status comparison logic: Scenario 1: If both parties mark the transaction as "transfer successful" or both mark it as "transfer failed," then the order status is confirmed to be accurate.
[0049] Scenario 2: If the two parties are inconsistent, for example, the reconciliation file corresponding to the same payment transaction number shows that the payment was successful, but the redemption order shows that the payment failed, it means that the funds have been successfully transferred from the advance payment account and arrived in the user's account, but the system failed to detect it due to communication or other reasons, resulting in the system under-recording and the advance payment amount being calculated incorrectly.
[0050] If the reconciliation file for the same payment transaction number shows a failed transfer, while the redemption order shows a successful transfer, it means the system mistakenly judged the transaction as successful, but the funds were not actually transferred. This results in users seeing funds arrive in their accounts but not actually receiving them, which can easily lead to major customer complaints and financial loopholes.
[0051] Therefore, for any orders with inconsistent statuses, a second pending task is immediately generated for manual verification, and an accounting anomaly alarm is issued, notifying risk control and operations personnel to intervene urgently for verification and adjustment. By making a final decision through reconciliation documents, a verification layer that transcends system limitations is constructed, further improving the accuracy of fund arrivals and thus enhancing the user experience.
[0052] It should be understood that, although Figure 2 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 2 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.
[0053] Based on the same inventive concept, embodiments of this application provide a monitoring device for quick redemption transactions, including: a payment request module 201, a polling tag module 202, and an order polling module 203, wherein: The payment request module is used to respond to the quick redemption instruction sent by the client, initiate a payment request to the payment institution, and generate a payment order to be transferred. The polling and marking module is used to mark pending payment orders as pending polling orders if no payment success instruction is received from the payment institution. The order polling module is used to perform at least one round of polling on the orders to be polled until the payment status of the orders to be paid is confirmed as the final status, which includes payment success and payment failure.
[0054] In one embodiment, the order polling module is used to integrate all pending orders into a polling task list; and to determine the polling priority of pending orders based on their time identifiers; the polling priority includes a first priority and a second priority; the first priority takes precedence over the second priority; for pending orders in the first priority queue, a status query is performed at a first query interval; for pending orders in the second priority queue, a status query is performed at a second query interval, where the first query interval is shorter than the second query interval; in response to the payment institution's query results for each pending order, the status of the pending orders is updated until the payment status of the pending orders is confirmed as the final status.
[0055] In one embodiment, the order polling module is configured to assign the orders to be polled to a first priority queue if the cumulative dwell time of the orders to be polled is greater than a first duration threshold and less than or equal to a second duration threshold; and to assign the orders to be polled to a second priority queue if the cumulative dwell time of the orders to be polled is less than or equal to the first duration threshold.
[0056] In one embodiment, the order polling module is used to trigger an alarm and generate a first pending task when the cumulative dwell time of any pending order exceeds a second duration threshold.
[0057] In one embodiment, the order polling module is configured to keep the order in the current polling task list if the received status of the order to be polled is "processing"; if the received status of the order to be polled is "payment successful" or "payment failed", remove the order from the current polling task list and record the final status of the order as "payment successful" or "payment failed"; if the received status of the order to be polled is "order does not exist", remove the order from the current polling task list and record the final status of the order as "payment failed".
[0058] In one embodiment, the quick redemption order monitoring device further includes a reconciliation module, used to obtain reconciliation files within a preset time period. The reconciliation files include payment transaction numbers and the corresponding payment results. Based on the payment transaction number, the corresponding quick redemption order is searched. If the corresponding quick redemption order is found, the payment result is compared with the final status of the quick redemption order. If the comparison result shows that the two statuses are inconsistent, a system alarm is triggered. When the comparison result shows that both statuses are "payment failure", a second pending task is generated.
[0059] In one embodiment, the payment request module is used to query the system history based on the order number of the current quick redemption instruction; if a record with the same order number and a payment status of successful payment is found, the quick redemption instruction request operation is terminated.
[0060] Specific limitations regarding the monitoring device for quick redemption transactions can be found in the limitations on the voice recognition method described above, and will not be repeated here. Each module in the aforementioned monitoring device for quick redemption transactions can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.
[0061] Based on the same inventive concept, embodiments of this application provide a computer device, which may be a server, and its internal structure diagram may be as follows: Figure 3 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a method for monitoring fast redemption transactions.
[0062] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0063] Based on the same inventive concept, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it performs the following steps: in response to a quick redemption instruction sent by a client, it initiates a payment request to a payment institution and generates a payment order; for the payment order, if no final status instruction is received from the payment institution, the payment order for which no final status instruction has been received is marked as a pending polling order; and performs at least one round of polling on the pending polling order until the payment status of the pending polling order is confirmed as a final status, the final status including payment success and payment failure.
[0064] In one embodiment, the processor further performs the following steps when executing the computer program: Based on the order number of the current quick redemption instruction, query the system history; if a record with the same order number and a payment status of successful payment is found, terminate the quick redemption instruction request operation.
[0065] In one embodiment, the processor further performs the following steps when executing the computer program: All pending orders are consolidated into a polling task list; and the polling priority of pending orders is determined based on their time identifiers; the polling priority includes a first priority and a second priority, with the first priority taking precedence over the second priority; for pending orders in the first priority queue, a status query is performed at a first query interval; for pending orders in the second priority queue, a status query is performed at a second query interval, with the first query interval being shorter than the second query interval; in response to the payment institution's query results for each pending order, the status of the pending orders is updated until the payment status of the pending orders is confirmed as the final status.
[0066] In one embodiment, the processor further performs the following steps when executing the computer program: If the cumulative dwell time of the pending orders is greater than the first dwell time threshold and less than or equal to the second dwell time threshold, the pending orders will be assigned to the first priority queue; if the cumulative dwell time of the pending orders is less than or equal to the first dwell time threshold, the pending orders will be assigned to the second priority queue.
[0067] In one embodiment, the processor further performs the following steps when executing the computer program: If the cumulative dwell time of any pending order exceeds the second duration threshold, an alarm is triggered and the first pending task is generated.
[0068] In one embodiment, the processor further performs the following steps when executing the computer program: If the received order status is "processing", keep the order in the current polling task list; if the received order status is "payment successful" or "payment failed", remove the order from the current polling task list and record the final status of the order as "payment successful" or "payment failed"; if the received order status is "order does not exist", remove the order from the current polling task list and record the final status of the order as "payment failed".
[0069] In one embodiment, the processor further performs the following steps when executing the computer program: Retrieve reconciliation files for a preset time period. The reconciliation files include payment transaction numbers and the corresponding payment results. Based on the payment transaction number, locate the corresponding quick redemption order. If the corresponding quick redemption order is found, compare the final status of the payment result with that of the quick redemption order. If the comparison result shows that the two statuses are inconsistent, trigger a system alarm. When the comparison result shows that both statuses are "payment failure", generate a second pending task.
[0070] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it performs the following steps: in response to a quick redemption instruction sent by a client, it initiates a payment request to a payment institution and generates a pending payment order; for the pending payment order, if no final status instruction is received from the payment institution, the pending payment order without receiving a final status instruction is marked as a pending polling order; and it performs at least one round of polling on the pending polling order until the payment status of the pending polling order is confirmed as the final status, the final status including payment success and payment failure.
[0071] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: querying the system history based on the order number of the current quick redemption instruction; if a record with the same order number and a payment status of successful payment is found, the request operation of the quick redemption instruction is terminated.
[0072] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: integrating all pending orders into a polling task list; and determining the polling priority of the pending orders based on their timestamps; the polling priority includes a first priority and a second priority; the first priority takes precedence over the second priority; for pending orders in the first priority queue, performing a status query at a first query interval; for pending orders in the second priority queue, performing a status query at a second query interval, where the first query interval is shorter than the second query interval; and updating the status of the pending orders in response to the payment institution's query results for each pending order, until the payment status of the pending orders is confirmed as the final status.
[0073] In one embodiment, when the computer program is executed by the processor, it further implements the following steps: if the cumulative dwell time of the orders to be polled is greater than a first duration threshold and less than or equal to a second duration threshold, then the orders to be polled are assigned to a first priority queue; if the cumulative dwell time of the orders to be polled is less than or equal to the first duration threshold, then the orders to be polled are assigned to a second priority queue.
[0074] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: when the cumulative dwell time of any pending order exceeds a second duration threshold, an alarm is triggered and a first pending task is generated.
[0075] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: if the status of the pending order is "processing", then the pending order is kept in the current polling task list; if the status of the pending order is "payment successful" or "payment failed", then the pending order is removed from the current polling task list, and the final status of the pending order is recorded as "payment successful" or "payment failed"; if the status of the pending order is "order does not exist", then the pending order is removed from the current polling task list, and the final status of the pending order is recorded as "payment failed".
[0076] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: obtaining a reconciliation file within a preset time period, the reconciliation file including a payment transaction number and the payment result corresponding to the payment transaction number; searching for the corresponding quick redemption order based on the payment transaction number; if the corresponding quick redemption order is found, comparing whether the payment result is consistent with the final status of the quick redemption order; if the comparison result shows that the two statuses are inconsistent, triggering a system alarm; when the comparison result shows that both statuses are payment failures, generating a second pending task.
[0077] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.
[0078] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0079] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.
Claims
1. A method for monitoring fast redemption transactions, characterized in that, include: In response to the quick redemption instruction sent by the client, a transfer request is initiated to the payment institution, generating a transfer order; For the pending payment orders, if no final status instruction is received from the payment institution, the pending payment orders for which no final status instruction has been received are marked as pending polling orders; At least one round of polling is performed on the pending orders until the payment status of the pending orders is confirmed as the final status, which includes payment success and payment failure.
2. The method according to claim 1, characterized in that, Perform at least one round of polling on the pending orders until the payment status of the pending orders is confirmed as the final status, including: All pending orders are consolidated into a polling task list; and the polling priority of each pending order is determined based on its time identifier; the polling priority includes a first priority and a second priority; the first priority takes precedence over the second priority. For orders awaiting polling in the first priority queue, a status query is performed at a first query interval; for orders awaiting polling in the second priority queue, a status query is performed at a second query interval, where the first query interval is shorter than the second query interval. In response to the payment institution's query results for each of the pending orders, the status of the pending orders is updated until the payment status of the pending orders is confirmed as the final status.
3. The method according to claim 2, characterized in that, Determining the polling priority of the orders to be polled based on their timestamps includes: If the cumulative dwell time of the pending orders is greater than the first duration threshold and less than or equal to the second duration threshold, then the pending orders will be assigned to the first priority queue. If the cumulative dwell time of the pending orders is less than or equal to the first duration threshold, then the pending orders will be assigned to the second priority queue.
4. The method according to claim 2 or 3, characterized in that, The method further includes: If the cumulative dwell time of any pending order exceeds the second duration threshold, an alarm is triggered and a first pending task is generated.
5. The method according to claim 2, characterized in that, Updating the status of the pending orders includes: If the status of a pending order is "processing", then keep the pending order in the current polling task list; If the status of the pending order is "payment successful" or "payment failed", then the pending order is removed from the current polling task list, and the final status of the pending order is recorded as "payment successful" or "payment failed". If the status of the pending order is "order does not exist", then the pending order is removed from the current polling task list, and the final status of the pending order is recorded as "payment failure".
6. The method according to claim 5, characterized in that, After updating the status of the orders to be polled, the process also includes: Obtain reconciliation files within a preset time period, wherein the reconciliation files include payment transaction numbers and the payment results corresponding to the payment transaction numbers; Based on the payment transaction number, locate the corresponding quick redemption order; If a corresponding quick redemption order is found, compare whether the payment result is consistent with the final status of the quick redemption order; If the comparison results show that the two states are inconsistent, a system alarm will be triggered. When the comparison result shows that both are in the state of payment failure, a second pending task is generated.
7. The method according to claim 1, characterized in that, Before generating the order to be transferred, the following is included: Query the system history based on the order number of the current quick redemption instruction; If a record with the same order number and a payment status of successful payment is found, the request operation for the quick redemption instruction will be terminated.
8. A quick redemption order monitoring device, characterized in that, include: The payment request module is used to respond to the quick redemption instruction sent by the client, initiate a payment request to the payment institution, and generate a payment order to be transferred. The polling and marking module is used to mark the pending payment orders as pending polling orders if no payment success instruction is received from the payment institution. The order polling module is used to perform at least one round of polling on the orders to be polled until the payment status of the orders to be paid is confirmed as the final status, which includes payment success and payment failure.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the quick redemption order monitoring method according to any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor and implementing the quick redemption order monitoring method as described in any one of claims 1 to 7.