Order payment method and related equipment

Abstract

The invention provides an order payment method and related equipment, and the method comprises the steps: creating a corresponding order table in a database in response to an order creation request received from a user side for a target order, and setting the payment state of the order table as a to-be-paid state, creating a delay message about the target order in a delay queue; in response to the detected order payment operation for the target order, updating the state of the target order to be in payment, and creating a first time container with a first priority; creating a second time container with a second priority in response to the fact that the detected time reaches a preset moment before the delay message expires; and in response to received payment success information of the target order, updating the payment state of the order table based on the first time container, the second time container and the distributed lock.

Description

Technical Field

[0001] This disclosure relates to the field of order payment, and more particularly to an order payment method and related equipment. Background Technology

[0002] In e-commerce platform order processing systems, scheduled tasks and payment callbacks are typically used to update order status. Scheduled tasks automatically cancel unpaid orders after a timeout, while payment callbacks update the order status to "paid" after the user completes payment. However, this technical solution has significant drawbacks when facing concurrent operations. When a user completes payment just before an order is about to be canceled, the payment callback and scheduled task may trigger simultaneously or almost simultaneously, leading to a race condition. In this situation, the system may be unable to accurately determine the final status of the order, resulting in problems such as successful user payment but incorrect order cancellation, inconsistencies in system accounting, and chaotic inventory management. This not only affects user experience and increases customer complaints but also leads to a significant increase in manual processing costs, severely impacting the platform's operational efficiency. Summary of the Invention

[0003] In view of this, the purpose of this disclosure is to provide an order payment method and related equipment.

[0004] In a first aspect, this disclosure provides an order payment method, including: In response to receiving an order creation request for a target order from a user, a corresponding order table is created in the database, the payment status of the order table is set to pending payment, and a delay message for the target order is created in the delay queue. In response to detecting an order payment operation for the target order, the status of the target order is updated to "paying" and a first time container with a first priority is created; the first time container is used to update the payment status of the order table to "paid" within a first valid time period; the first valid time period is determined based on the payment time corresponding to the order payment operation and a first preset duration; In response to the detection that the time has reached a preset time before the expiration of the delayed message, a second time container with a second priority is created; the second time container is used to update the payment status of the order table to canceled within a second valid time period; the second valid time period is determined based on the cancellation time corresponding to the order cancellation operation and a second preset duration; In response to receiving payment success information for the target order, the payment status of the order table is updated based on the first time container, the second time container, and the distributed lock.

[0005] A second aspect of this disclosure provides an order payment device, comprising: The order creation module is used to respond to receiving an order creation request for a target order from the user terminal, create a corresponding order table in the database, set the payment status of the order table to pending payment, and create a delay message for the target order in the delay queue. A first container module is configured to, in response to detecting an order payment operation for the target order, update the status of the target order to "paying" and create a first time container with a first priority; the first time container is configured to update the payment status of the order table to "paid" within a first valid time period; the first valid time period is determined based on the payment time corresponding to the order payment operation and a first preset duration; The second container module is used to create a second time container with a second priority in response to detecting that the time has reached a preset time before the expiration of the delayed message; the second time container is used to update the payment status of the order table to canceled within a second effective time period; the second effective time period is determined based on the cancellation time corresponding to the order cancellation operation and a second preset duration; The status update module, in response to receiving payment success information for the target order, updates the payment status of the order table based on the first time container, the second time container, and the distributed lock.

[0006] A third aspect of this disclosure provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method as described in the first aspect.

[0007] In a fourth aspect, this disclosure provides a non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform the method described in the first aspect.

[0008] A fifth aspect of this disclosure provides a computer program product including computer program instructions that, when executed on a computer, cause the computer to perform the method described in the first aspect.

[0009] As described above, this disclosure provides an order payment method and related equipment. When a user client requests the creation of a target order, an order table is created in the database and the payment status is set to "pending payment." Simultaneously, a delayed message for the order is created in a delayed queue. When an order payment operation is detected, the order status is updated to "paying" and a first time container is created to update the payment status to "paid" within a first valid time period determined based on the payment time and a first preset duration. When the delayed message expires, a second time container is created to update the payment status to "cancelled" within a second valid time period determined based on the cancellation time and a second preset duration. When payment success information is received, the order payment status is updated based on the first time container, the second time container, and a distributed lock. This effectively manages the order payment status, utilizes delayed messages and time containers to handle changes in order status under different scenarios, and combines a distributed lock to ensure the accuracy and consistency of payment status updates, avoiding state chaos and improving the reliability and stability of order processing. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in this disclosure or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of the payment architecture according to an embodiment of the present disclosure.

[0012] Figure 2 This is a schematic diagram of the structure of an exemplary electronic device according to an embodiment of the present disclosure.

[0013] Figure 3 This is a schematic flowchart illustrating a payment method according to an embodiment of the present disclosure.

[0014] Figure 4 This is a schematic diagram illustrating the principle of the payment method according to an embodiment of this disclosure.

[0015] Figure 5 This is a schematic diagram illustrating the principle of the payment method according to an embodiment of this disclosure.

[0016] Figure 6 This is a schematic diagram illustrating the principle of order payment in an embodiment of this disclosure.

[0017] Figure 7A This is a schematic diagram of a time capsule according to an embodiment of the present disclosure.

[0018] Figure 7B This is a schematic diagram of a time capsule according to an embodiment of the present disclosure.

[0019] Figure 8 This is a schematic diagram of order payment according to an embodiment of the present disclosure.

[0020] Figure 9 This is a schematic diagram of the state machine mechanism in an embodiment of this disclosure.

[0021] Figure 10 This is a schematic diagram of a payment device according to an embodiment of the present disclosure. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0023] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this disclosure should have the ordinary meaning understood by one of ordinary skill in the art to which this disclosure pertains. The terms "first," "second," and similar terms used in the embodiments of this disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0024] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0025] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.

[0026] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0027] Figure 1 A schematic diagram of a payment architecture according to an embodiment of this disclosure is shown. (See reference...) Figure 1The payment architecture 100 may include a server 110, a terminal 120, and a network 130 providing a communication link. The server 110 and the terminal 120 can be connected via a wired or wireless network 130. The server 110 may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, security services, and CDN.

[0028] Terminal 120 can be implemented in hardware or software. For example, when terminal 120 is implemented in hardware, it can be various electronic devices with a display screen and support page display, including but not limited to smartphones, tablets, e-book readers, laptops, and desktop computers. When terminal 120 is implemented in software, it can be installed in the electronic devices listed above; it can be implemented as multiple software programs or software modules (e.g., software programs or software modules used to provide distributed services) or as a single software program or software module, without specific limitations.

[0029] It should be noted that the payment method provided in this embodiment can be executed by the terminal 120 or by the server 110. It should be understood that... Figure 1 The number of terminals, networks, and servers shown is for illustrative purposes only and is not intended to be a limitation. Any number of terminals, networks, and servers can be used depending on implementation needs.

[0030] Figure 2 A schematic diagram of the hardware structure of an exemplary electronic device 200 provided in an embodiment of this disclosure is shown. For example... Figure 2 As shown, the electronic device 200 may include: a processor 202, a memory 204, a network module 206, a peripheral interface 208, and a bus 210. The processor 202, memory 204, network module 206, and peripheral interface 208 are interconnected within the electronic device 200 via the bus 210.

[0031] Processor 202 may be a Central Processing Unit (CPU), a Neural Processing Unit (NPU), a Microcontroller (MCU), a programmable logic device, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits. Processor 202 can be used to perform functions related to the techniques described in this disclosure. In some embodiments, processor 202 may also include multiple processors integrated as a single logic component. For example, such as... Figure 2As shown, processor 202 may include multiple processors 202a, 202b and 202c.

[0032] Memory 204 can be configured to store data (e.g., instructions, computer code, etc.). Figure 2 As shown, the data stored in memory 204 may include program instructions (e.g., program instructions for implementing the payment method of embodiments of this disclosure) and data to be processed (e.g., the memory may store configuration files of other modules, etc.). Processor 202 may also access the program instructions and data stored in memory 204 and execute the program instructions to operate on the data to be processed. Memory 204 may include volatile or non-volatile storage devices. In some embodiments, memory 204 may include random access memory (RAM), read-only memory (ROM), optical disk, magnetic disk, hard disk, solid-state drive (SSD), flash memory, memory stick, etc.

[0033] Network module 206 can be configured to provide communication with other external devices to electronic device 200 via a network. This network can be any wired or wireless network capable of transmitting and receiving data. For example, the network can be a wired network, a local wireless network (e.g., Bluetooth, WiFi, Near Field Communication (NFC), etc.), a cellular network, the Internet, or a combination thereof. It is understood that the type of network is not limited to the specific examples described above. In some embodiments, network module 206 may include any combination of any number of network interface controllers (NICs), radio frequency modules, transceivers, modems, routers, gateways, adapters, cellular network chips, etc.

[0034] The peripheral interface 208 can be configured to connect the electronic device 200 to one or more peripheral devices to enable information input and output. For example, peripheral devices may include input devices such as keyboards, mice, touchpads, touch screens, microphones, and various sensors, as well as output devices such as displays, speakers, vibrators, and indicator lights.

[0035] Bus 210 can be configured to transmit information between various components of electronic device 200 (e.g., processor 202, memory 204, network module 206, and peripheral interface 208), such as internal buses (e.g., processor-memory bus), external buses (USB port, PCI-E bus), etc.

[0036] It should be noted that although the architecture of the above-described electronic device 200 only shows the processor 202, memory 204, network module 206, peripheral interface 208, and bus 210, in specific implementations, the architecture of the electronic device 200 may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the architecture of the above-described electronic device 200 may only include the components necessary for implementing the embodiments of this disclosure, and does not necessarily include all the components shown in the figures.

[0037] In the order processing workflow of e-commerce platforms, the relevant technologies mainly rely on scheduled tasks and payment callback mechanisms to manage order status. In a normal business process, an order undergoes multiple status changes from creation to completion, such as "pending payment," "paying," "payment successful," and "cancelled." After a user places an order, the system typically sets a timeout period; if the user does not complete payment within this time, the order will be automatically cancelled. However, if the user completes payment just before the order is to be cancelled, a conflict arises. For example, if the system is set to automatically cancel an order if payment is not made within 15 minutes, and the user clicks to pay at 14 minutes and 40 seconds, the payment success callback will be triggered just as the scheduled task for order cancellation is about to execute. At this point, the payment callback needs to change the order status to "paid," while the scheduled task needs to change it to "cancelled," creating a race condition. Improper handling can lead to problems such as: successful user payment but order cancellation, inconsistencies in system accounting, and unreleased or duplicated inventory. Therefore, in high-concurrency scenarios, especially when user payment and automatic order cancellation occur almost simultaneously, the relevant technologies reveal the following significant shortcomings: Race condition issue: The time competition between the user's successful payment and the automatic cancellation of the order causes the user to have paid but the order status to be incorrectly changed to "cancelled", resulting in the user's funds being stuck and the order status being inconsistent.

[0038] Performance waste: Scanning the entire database table by scheduled tasks to find and cancel timed-out orders consumes a lot of system resources when the data volume is large, affecting overall performance.

[0039] Execution delay: Scheduled tasks are not executed in real time and have an inherent delay, which may lead to untimely updates of order status and further exacerbate race condition problems.

[0040] Risk of duplicate execution: In a distributed system, multiple nodes may execute the same scheduled task simultaneously, leading to duplicate operations and potential data inconsistencies.

[0041] Lack of fallback measures: Existing technologies lack effective recovery and compensation mechanisms for order status errors caused by system anomalies or payment platform delays.

[0042] Therefore, how to solve the race condition problem under high concurrency, improve system performance, reduce resource waste, ensure real-time update of order status, prevent duplicate execution, ensure data consistency, and enhance system robustness have become urgent technical problems to be solved.

[0043] In view of this, this disclosure proposes a payment method and related equipment. By optimizing the order status management logic, it ensures that when user payment and automatic order cancellation occur simultaneously, the final order status can be accurately determined and set, preventing situations where users have paid but orders are incorrectly cancelled, thus protecting user rights. By introducing a more efficient order timeout detection mechanism, it avoids the performance overhead of full table scans, significantly improving system processing capacity, especially in high-concurrency scenarios such as promotional activities. It reduces the latency of order status updates, ensuring users receive timely and accurate order status feedback after successful payment, improving user experience. In a distributed system, reasonable task allocation and locking mechanisms prevent multiple nodes from executing the same order operation simultaneously, ensuring data consistency and accuracy. It provides a comprehensive recovery and compensation mechanism for potential system anomalies or payment platform delays, ensuring rapid recovery of order status in abnormal situations and guaranteeing stable system operation. This solves problems such as race conditions, performance waste, execution latency, risk of duplicate execution, and lack of fallback solutions in existing technologies, providing a more stable, efficient, and reliable order processing service.

[0044] See Figure 3 , Figure 3 A schematic flowchart of a payment method according to an embodiment of the present disclosure is shown. The payment method according to an embodiment of the present disclosure can be deployed on a server. Figure 3 In this context, payment method 300 may further include the following steps.

[0045] In step S310, in response to receiving an order creation request for the target order from the user terminal, a corresponding order table is created in the database, the payment status of the order table is set to pending payment, and a delay message for the target order is created in the delay queue.

[0046] In this context, "user terminal" refers to the terminal device or application interface through which the user operates and interacts, such as a shopping app on a mobile phone or a web-based online store on a computer. Users initiate various order-related operation requests through this interface. "Target order" refers to the specific object to which the user terminal's creation request is directed. It can contain detailed order information, such as product information, quantity purchased, and user information, and is the core object of the entire order processing flow. "Order creation request" refers to the instruction sent by the user terminal to the system, requesting the creation of a new order. This request carries all the necessary information required to create the order. "Database" refers to the system used to store and manage data, such as storing order tables and related order information, ensuring data persistence and queryability. "Order table" refers to the table structure in the database used to record detailed order information. It can contain various attribute fields for the order, such as order number, payment status, and creation time. "Payment status" refers to a field in the order table used to identify the current payment status of the order, which can include pending payment, in progress payment, paid, and cancelled. "Delayed queue" refers to a queue where delayed messages are not processed immediately but are retrieved and processed only after a set delay period. It can be used to handle situations where orders have timed out and are not paid. Delayed messages refer to messages placed in a delay queue. They contain information about the target order and the set delay time. When the delay time expires, the corresponding order status update operation will be triggered.

[0047] Specifically, if a user places an order but doesn't pay, the order will automatically cancel after a timeout. If the user pays just as the order is about to be canceled, or if there's a slight delay on the payment platform, two scenarios will occur: Scenario 1: The user successfully pays, but at the moment of the payment callback, the order is automatically canceled due to a timeout (first come, first served, order canceled later). This results in the user having paid but the order being in a canceled state. Figure 4 As shown in the diagram. Scenario 2: The user successfully pays, but the payment order has already been cancelled at the moment of the payment callback. However, the user has already been charged (cancellation before payment). This will also result in the user paying but the order being in a cancelled state, as shown in the diagram. Figure 5 As shown.

[0048] When the system receives an order creation request from a user for a target order, it first creates a corresponding order table in the database, stores the initial information of the order, and sets the payment status of the order table to "pending payment," indicating that the order has not yet been paid. Simultaneously, to handle cases where orders time out and remain unpaid, the system creates a delayed message for the target order in a delayed queue, setting an appropriate delay time so that the order status can be processed accordingly after that time expires. For example, when a user submits an order and the database records it as "pending payment," a delayed exchange of type `x-delayed-message` is created based on RabbitMQ, and a queue is used to send the delayed message. The `x-delayed-type` is set to an exact match for the `direct` type, and the message attribute `{"x-delay", 15 * 60 * 1000}` is set to delay delivery to the consumer for 15 minutes. This effectively manages order creation and initial status settings, ensuring that order information is accurately stored in the database. By introducing delayed queues and delayed messages, orders that have timed out and are not paid can be handled automatically and promptly, preventing orders from remaining in a pending payment state for extended periods due to user forgetting to pay or problems occurring during the payment process, thus avoiding the consumption of system resources. Overall, this improves the automation and efficiency of order processing, enhances system stability and reliability, and provides users with a better shopping experience. It also resolves the issue of competition between "cancellation" and "payment" timeframes caused by high concurrency, which can lead to situations where users do not receive refunds after their orders have timed out.

[0049] In step S320, in response to detecting an order payment operation for the target order, the status of the target order is updated to "paying" and a first time container with a first priority is created; the first time container is used to update the payment status of the order table to "paid" within a first valid time period; the first valid time period is determined based on the payment time corresponding to the order payment operation and a first preset duration.

[0050] Order payment operation refers to a series of payment confirmation actions initiated by a user on the payment interface after order creation. This includes actions such as clicking the payment button in a shopping app, selecting a payment method (e.g., WeChat Pay, Alipay), entering a payment password, and completing the fund transfer. This demonstrates the user's intention to pay for the order and the actual execution of the payment action. The first time container can be a logical component with specific functions and attributes, and can be assigned the highest priority. It is created after the order payment operation is triggered and is used to monitor and update the order payment status within a preset time range, ensuring that the order payment status is accurately changed at the appropriate time. The first effective time period is a time interval calculated based on the payment time corresponding to the order payment operation and a pre-set first preset duration. The first effective time period defines the time span from the moment the payment operation occurs to the latest time when the order payment status is allowed to be updated to "paid."

[0051] See Figure 6 , Figure 6 A schematic diagram illustrating the principle of order payment according to an embodiment of this disclosure is shown. When the system detects that a user has initiated an order payment operation for a target order, it immediately updates the status of the target order to "Payment in Progress" to indicate that the order is undergoing the payment process. Simultaneously, the system creates a first time container with a first priority. This first time container determines a first valid time period based on the payment time corresponding to the order payment operation and a first preset duration. Within the first valid time period, if the payment process is successfully completed, the first time container updates the payment status of the order table to "Paid" according to preset logic, completing the accurate change of the order payment status.

[0052] By promptly responding to order payment operations and updating the order status to "Payment in Progress," the system can track the payment progress of orders in real time. Creating a first-priority container ensures that order payment status updates are processed first in the payment process, preventing delays or errors caused by other tasks. A first effective time period, determined based on payment time and a preset duration, provides a reasonable time range for changes in order payment status. This ensures timely status updates upon successful payment while preventing misjudgments due to network latency or other anomalies, improving the accuracy and reliability of order payment status management, enhancing the user payment experience, and improving system stability.

[0053] Specifically, the system has two important functional services: order timeout cancellation and order payment callback notification. The order timeout cancellation service listens for messages in a delayed queue, sets up a consumer to listen to the delayed queue, processes received messages, and adds a Redis distributed lock. A unique distributed lock is set for each key ("order_lock_" + orderNo). Any state change operation must acquire the lock first. The lock is set using Redis's `setnx` method with a lock duration of 30 seconds. The Redis distributed lock implementation mechanism ensures that whoever acquires the lock first uses it first. If the return value is true, it means the lock was successfully acquired. The consumer checks if the order is still unpaid. If so, it performs operations such as order cancellation, releasing inventory, and releasing coupons. If payment has already been made, order cancellation is not performed. Finally, the lock is released, and the message is acknowledged (ACK) to prevent duplicate processing. If the return value is false, it means the lock has been acquired by another node, and the order needs to be re-added to the `basicNack` queue. In this case, it needs to wait for a period of time before trying again.

[0054] First-time containers can be created based on the time capsule mechanism, which is similar to a real-world time capsule. It wraps the intention of an operation in a container with a time attribute, rather than executing the operation immediately. This mechanism coordinates concurrent operations through the time dimension. In practice, RabbitMQ provides a delayed message plugin (rabbitmq-delayed-message-exchange), which allows for delayed message delivery directly through the exchange. A delay time can be specified when sending a message, and the message will wait in the queue for the specified time before being consumed by the consumer. However, in business scenarios such as payments and cancellations, over-reliance on Redis locks in traditional technologies may bring more problems than solutions. In contrast, combining the time capsule mechanism with Redis locks allows for early filtering of invalid requests, reducing lock contention, providing business-level rationality checks, improving user experience, providing more accurate error feedback, and resulting in a better user experience, higher system availability, and lower maintenance costs.

[0055] In step S330, in response to detecting that the time has reached a preset time before the expiration of the delayed message, a second time container with a second priority is created; the second time container is used to update the payment status of the order table to canceled within a second valid time period; the second valid time period is determined based on the cancellation time corresponding to the order cancellation operation and a second preset duration.

[0056] The second time container can be a program component with specific functional logic, assigned a second priority. It can be created when a preset time is detected before the delayed message expires. Within a subsequent specified time interval, it updates the payment status of the order table, changing it to a cancelled status, thus handling abnormal situations such as unpaid orders due to timeouts. The second effective time period is a range determined by the cancellation time corresponding to the order cancellation operation (e.g., in this scenario, the delayed message expiration can be considered an implicit cancellation trigger) and a pre-set second preset duration. This time period clarifies the effective time limit for the second time container to update the order payment status to cancelled.

[0057] When the system detects a preset time before a delayed message expires, it immediately creates a second time container with a second priority. This second time container determines a second valid time period based on the implicit cancellation-related time point of the delayed message's expiration and a pre-set second preset duration. Within this second valid time period, if the order has not yet completed normal processes such as payment, the second time container will update the payment status of the order table to "cancelled" according to established rules, thus appropriately handling orders that have exceeded the time limit. By creating a second time container, the system can accurately respond to delayed message expiration and utilize the second priority to ensure orderly processing of order status update tasks in a multi-tasking environment. The setting of the second valid time period provides a clear and reasonable time constraint for order status changes, avoiding premature cancellation that may affect users' normal payments while promptly processing overdue orders and freeing up system resources. This improves the automation and intelligence of order management, enhances system stability and reliability, and effectively improves user experience and system operational efficiency.

[0058] In step S340, in response to receiving payment success information for the target order, the payment status of the order table is updated based on the first time container, the second time container, and the distributed lock.

[0059] Payment success information can be a feedback message sent by the payment system to the order processing system after completing a series of payment processes, including fund transfer and verification for the target order, and confirming that the payment operation is correct. Payment success information may include key information such as order number, payment amount, payment time, and payment method, and is the key basis for the order processing system to determine whether the order payment was successful. A distributed lock is a locking mechanism used in a distributed system to ensure data consistency and accuracy when multiple nodes concurrently access shared resources (such as the payment status of an order table). It allows only one node to acquire the lock and operate on the shared resource at a time. After the operation is completed, the lock is released, allowing other nodes to acquire the lock and perform operations, thus avoiding conflicts and errors caused by multiple nodes modifying data simultaneously.

[0060] When the system receives payment success information for a target order, since there might be situations where both the first and second time-based containers are simultaneously updating the order's payment status (e.g., the first time-based container is preparing to update the status to "paid," while the second time-based container is also preparing to update its status due to some abnormal situation), the system uses a distributed lock to avoid data inconsistency caused by such concurrent operations. First, the system attempts to acquire the distributed lock. Once successfully acquired, it accurately updates the payment status of the order table based on the logical states of the first and second time-based containers, ensuring that the order's payment status is ultimately correctly set to "paid." After the update is complete, the distributed lock is released.

[0061] By introducing payment success information as the trigger condition for order payment status updates, the accuracy and timeliness of status updates are ensured; a status change only occurs when payment is truly successful. Furthermore, the use of distributed locks effectively resolves data conflicts that may arise from multiple containers concurrently updating order payment status in a distributed environment, ensuring data consistency and integrity. Overall, this improves the reliability and stability of order payment status management, provides users with more accurate order status feedback, and enhances system robustness.

[0062] Specifically, the order payment callback notification service can notify this system after a successful payment through a third-party payment platform. This system then acquires a distributed lock using the same key (order number, i.e., the target order ID). Upon successful acquisition, it checks if the order is pending payment. If so, it changes the status to paid and removes the task message from the delayed queue. If cancelled, it initiates an automatic refund operation and finally releases the lock. If acquisition fails (the lock is occupied, such as during cancellation), it waits to try again for callback notification (the third-party platform has a delayed notification mechanism). Redis distributed locks are mechanisms used to implement mutual exclusion in distributed systems. They ensure that only one node can access shared resources at a time, preventing data inconsistency caused by concurrent modifications. Database optimistic locking: a concurrency control mechanism that prevents multiple users from modifying the same data simultaneously, resolving concurrent update conflicts. It typically uses version numbers / timestamps for checking; here, version numbers are used. State machine mechanism: a model describing the state changes of an object throughout its lifecycle, controlling business processes, order status, workflows, etc. Here, payment status control is used: pending payment -> payment in progress -> payment successful or cancelled.

[0063] In some embodiments, the first priority decreases over time, while the second priority increases over time; The payment status of the order table is then updated based on the first time container, the second time container, and the distributed lock, including: In response to the overlap between the first and second valid time periods, Based on the magnitude of the first priority and the second priority, it is determined whether the first time container or the second time container is used to update the payment status; The payment status is updated based on the first time container or the second time container, and the distributed lock; Specifically, determining whether to use the first time container or the second time container to update the payment status based on the magnitude of the first priority and the second priority includes: In response to the first priority being greater than the second priority, it is determined that the first time container is used to update the payment status; In response to the first priority being lower than the second priority, it is determined that the second time container is used to update the payment status; In response to the first priority being equal to the second priority, based on the first effective duration corresponding to the first time container and the second effective duration corresponding to the second time container, it is determined that the first time container or the second time container is used to update the payment status; Specifically, determining whether the first time container or the second time container is used to update the payment status based on the first effective duration corresponding to the first time container and the second effective duration corresponding to the second time container includes: In response to the first effective duration being greater than or equal to the second effective duration, it is determined that the first time container is used to update the payment status; In response to the first effective duration being less than the second effective duration, it is determined that the second time container is used to update the payment status.

[0064] In scenarios involving order payment status updates, a first time container can be assigned a higher priority than a second time container. When the first valid time period (the time range within which the first time container updates the order payment status to "paid") and the second valid time period (the time range within which the second time container updates the order payment status to "cancelled") overlap, the system determines the time container with the higher priority to perform the update operation. For example, if the first priority is higher than the second priority, the first time container performs the order payment status update; if the first priority is lower than the second priority, the second time container performs the order payment status update. Subsequently, a distributed lock mechanism ensures that only one operation can modify the payment status of the order table at any given time. Finally, the payment status update is completed based on the first time container and the acquired distributed lock. By clearly defining the priorities of different time containers, the system can quickly and accurately determine which container will lead the status update when valid time periods overlap, avoiding conflicts and confusion caused by multiple containers attempting to update simultaneously. The introduction of distributed locks further guarantees the atomicity and consistency of state update operations, ensuring that the order payment status can still be correctly and reliably modified in complex multi-threaded and distributed environments. This effectively improves the stability and data accuracy of the system, providing users with a better order processing experience.

[0065] Specifically, examples of the structure of a time capsule may include: public class TemporalCapsule <t> { public string Id { get; set;} / / Unique identifier public T Payload { get; set;} / / Operation content (e.g., payment information) public DateTime ValidFrom { get; set;} / / Effective start time public DateTime ValidTo { get; set;} / / Effective end time public string Intent { get; set;} / / Operation intent (pay / cancel) public int Priority { get; set;} / / Priority, payment has higher priority than cancellation. } See Figure 7A and Figure 7B , Figure 7A and Figure 7B A schematic diagram of a time capsule according to an embodiment of the present disclosure is shown. Figure 7A In the payment capsule, after creation, it enters a validity period. Once the validity period begins, its priority decays over time. The initial priority is high (100→90), then medium (90→70), and finally low (70→40), eventually expiring and becoming invalid. During the normal payment period, the payment capsule has a priority of 100. As time passes, the priority decreases as it approaches expiration, becoming 0 upon expiration. At this point, payment becomes invalid, and cancellation succeeds (meaning the cancellation logic takes effect).

[0066] After a cancellation capsule is created, it enters a waiting state, and its priority increases over time. The initial priority is low (50), then medium (50→65), and finally high (65→90). After creation, the cancellation capsule enters a waiting period with a priority of 50. This priority is maintained during the initial period of effectiveness, and increases after a longer period. If the priority of the cancellation operation might exceed that of a payment operation nearing its expiration, the cancellation operation will prevail. In this way, by dynamically adjusting the priorities of payment and cancellation operations through time factors, the execution priority of payment or cancellation operations is reasonably determined at different time stages to achieve orderly processing of business logic and avoid conflicts and chaos.

[0067] Figure 7B The document uses a timeline chart and key points to illustrate the dynamic changes in scores between payment and cancellation operations. Within 0-14 minutes, payment scores higher than cancellation scores, giving payment an advantage. Between 14-15 minutes, the scores are close, with payment having only a slight advantage. From 15 minutes onwards, if a cancellation operation is performed after the timeout, it receives a 50-point bonus, at which point the cancellation score surpasses the payment score, making cancellation even more advantageous. This allows for a reasonable determination of payment and cancellation priorities based on the time dimension. Dynamic priority generation: the priority of payment capsules gradually decreases over time (100, 90, 80...), while the priority of cancellation capsules gradually increases over time (50, 60, 70...).

[0068] Payment intent capsules are created before a user initiates a payment request and calls the payment gateway (purpose: to preempt order status and prevent concurrent payments); cancellation intent capsules are created when an order is about to expire, but their activation is delayed (giving payment a final time window). Payment time capsule creation node: Created immediately before calling the payment interface. Cancellation time capsule creation node: Created before the order expires, but with a delayed activation setting. Storage location: All time capsules are uniformly stored in a Redis Sorted Set, sorted by priority and activation time. Decision timing: Periodic scanning + event-driven processing selects the highest priority and active capsule for execution. This ensures mutual exclusion between payment and cancellation operations, avoiding extensive use of traditional distributed locks, and naturally resolving concurrency conflicts through time and priority.

[0069] In actual operation, when a user initiates payment or the system triggers a pre-set cancellation time, the order status is not directly modified; instead, a "payment time capsule" is created. For example: / / When User A pays var paymentCapsule = new TemporalCapsule <paymentinfo> { Id = "capsule_001", Payload = paymentInfo, ValidFrom = DateTime.UtcNow, / / Take effect immediately ValidTo = DateTime.UtcNow.AddSeconds(30), / / Validates after 30 seconds Intent = "PAY", Priority = 100 / / High priority }; / / Store the payment intent in a time capsule: await _temporalStorage.StoreCapsule($"order_{orderId}_intent", capsule); / / System B timeout cancellation preset time var cancelCapsule = new TemporalCapsule <object> { ID = "capsule_002", Payload = null, ValidFrom = DateTime.UtcNow.AddSeconds(5), / / Validates after 5 seconds (allows time for payment) ValidTo = DateTime.UtcNow.AddSeconds(35), Intent = "CANCEL", Priority = 50 / / Cancel low priority }; / / Reduce the intention to save to time capsule await _temporalStorage.StoreCapsule($"order_{orderId}_intent",capsule); All time capsules can be stored in a dedicated Redis storage area, sorted by priority and time. For example, a timeline example: T=0s:[Payment Capsule Creation] ----------Valid Time----------->T=30s T=5s: [Cancel capsule creation] -------Valid time-------------->T=35s Processing can be prioritized according to the following rules: higher priority is processed first; if priorities are the same, processing is based on the order of effectiveness. For asynchronous notifications from third-party payments and automatic cancellations by the system, the operation that wins the priority selection follows established rules. For example: public async Task ProcessCapsules(string orderId) { / / Get all currently valid capsules var validCapsules = GetValidCapsules(orderId); / / Sort by priority and effective time var winner = validCapsules .OrderByDescending(c =>c.Priority) .ThenBy(c => c.ValidFrom) .FirstOrDefault(); / / Execute the winning operation if (winner != null) { switch (winner.Intent) { case "PAY": ExecutePayment(winner.Payload as PaymentInfo); break case "CANCEL": ExecuteCancellation(); break } } / / Clean up the processed capsules ClearProcessedCapsules(orderId); } Suppose the user completes payment just before the order expires: Order creation time: T=0; Timeout period: T = 30 minutes; User payment time: T = 29 minutes and 55 seconds.

[0070] Traditional methods may result in a competitive situation: [Payment Request] ----\ >Competitive order lock -> Uncertainty about who will win [Cancelled after timeout] ---- / Based on the time capsule mechanism disclosed herein: T=29 minutes 55 seconds: Create payment capsule (Effective: T=29 minutes 55 seconds, Priority: 100) T=30 minutes 00 seconds: Create / Cancel Capsule (Effective: T=30 minutes 05 seconds, Priority: 50) T=30 minutes 06 seconds: System processing capsule As can be seen, the payment capsule (i.e., the first-time container) has a higher priority and occurs earlier than the cancellation capsule (i.e., the second-time container), so payment is executed and cancellation is ignored. This mechanism solves the race condition problem of concurrent operations by introducing time and priority dimensions, and is more flexible and reliable than the traditional single-lock mechanism.

[0071] In some embodiments, updating the payment status based on the first time container and the distributed lock includes: Acquire the first distributed lock for the target order; In response to successfully acquiring the first distributed lock of the target order, obtain the current payment status and first version number of the order table; In response to the current payment status being "paying", the first version number is compared with the current version number of the order table based on the update operation of the first time container on the current payment status; In response to the first version number being consistent with the current version number, the current payment status of the order table is updated to paid and the first version number is updated, and the first distributed lock is released; If the first version number is inconsistent with the current version number, retry updating the current payment status of the order table to paid, or terminate the process.

[0072] When updating the order payment status based on the first-time container and distributed lock, the process first attempts to acquire the first distributed lock corresponding to the target order. Upon successful acquisition, the current payment status and first version number of the order table are obtained. If the current payment status is "Paying," before updating the payment status using the first-time container, the first version number is compared with the current version number of the order table. If they match, it indicates that the order status has not been modified by other operations during this period. In this case, the payment status of the order table is updated to "Paid," the first version number is updated, and the first distributed lock is released. If the first version number does not match the current version number, it indicates that other operations have affected the order status. In this case, the update of the payment status can be retried. If the retry still fails or certain conditions are met, the update process ends.

[0073] By introducing distributed locks, it is ensured that only one operation can modify the order payment status at a time in a multi-threaded or distributed environment, effectively avoiding data inconsistency issues caused by concurrent operations. The version number comparison mechanism further enhances the accuracy and security of data updates; the status is only updated when the version numbers match, preventing data corruption caused by other concurrent operations. Overall, this improves the reliability and stability of order payment status updates, ensures the integrity and consistency of system data, and provides users with more accurate order status feedback.

[0074] Specifically, such as Figure 8 As shown, Figure 8 A schematic diagram of order payment according to an embodiment of this disclosure is shown. The order callback payment service queries order information, including the version number, checks whether the order has been paid, and if it has been cancelled, issues a refund; otherwise, it modifies the order status and version number based on the version number. The database SQL processing is as follows: UPDATEorders SETstatus=@status, paid_amount=@paidAmount, paid_time=@paidTime, payment_method=@paymentMethod, updated_time=@updatedTime, version = version + 1 WHEREid=@orderIdANDversion=@currentVersion A successful update indicates that the payment was successful. If the execution fails, it may be due to a concurrency conflict, and the payment callback mechanism will continue to execute the method.

[0075] In the order timeout cancellation service, the system queries order information, including the version number, and checks whether the order has been paid. If payment has been made, cancellation is not performed; otherwise, the order status and version number are updated based on the version number. The SQL is as follows: UPDATEorders SETstatus=@status, cancel_time=@cancelTime, updated_time=@updatedTime, version = version + 1 WHEREid=@orderIdANDversion=@currentVersion If the update is successful, the cancellation was successful. If the execution fails, it may be due to a concurrent conflict, and the timeout cancellation method will continue to be executed.

[0076] In some embodiments, method 300 further includes: In response to the current payment status being cancelled, a refund message is sent to the payer; In response to the failure to successfully acquire the first distributed lock for the target order, retry acquiring the first distributed lock or send an exception message to indicate that the target order is an abnormal order.

[0077] Upon successfully acquiring the first distributed lock and obtaining the current payment status and first version number from the order table, if the current payment status is found to be cancelled, the system will immediately send a refund message to the payer to facilitate timely refund processing. Furthermore, if the initial attempt to acquire the first distributed lock for the target order fails, the system will initiate a retry mechanism to attempt to acquire the lock again. If the acquisition still fails after multiple retries, an exception message will be sent, marking the target order as an abnormal order for subsequent specialized processing and investigation.

[0078] By promptly sending refund information to the payer when the payment status is cancelled, the payer's rights are protected, user experience is improved, and the refund process can be initiated quickly, reducing the payer's waiting time. For cases where the distributed lock cannot be successfully acquired, the retry mechanism increases the chance of acquiring the lock, improving the system's fault tolerance. When a retry fails, an exception message is sent to mark the order as abnormal, helping staff to promptly identify and address problematic orders, preventing order processing from stalling due to lock acquisition failure, and ensuring the smoothness and stability of the entire order processing flow.

[0079] See Figure 9 , Figure 9 A schematic diagram of the state machine mechanism according to an embodiment of this disclosure is shown. Case 1: Pending Payment -> Payment in Progress -> Payment Successful: After the user completes payment, the system attempts to change the order status from "Payment in Progress" to "Payment Successful". Case 2: Pending Payment -> Payment in Progress -> Cancelled: If the system decides to cancel the order, it will attempt to change the order status from "Payment in Progress" to "Cancelled".

[0080] Regarding scenario 1, if the payment callback succeeds, the status should have changed from "Payment in Progress" to "Payment Successful." Regarding scenario 2, if the payment order cancellation succeeds, the status should have changed from "Payment in Progress" to "Cancelled" (refund operation initiated). Therefore, when modifying the payment order status, based on the original status, normal processing can be performed. The database SQL processing is as follows: # Statement to call upon successful payment update pay_info set status='paySuccess' where orderNo='1' and status='paying'; # Cancel operation call statement update pay_info set status = 'cancel' where orderNo = '1' and status= 'paying'; If the payment success update is executed first and succeeds, the order status changes to "Payment Successful". Even if a cancellation operation subsequently occurs, the cancellation will not affect the order status because the status no longer matches (no longer "Payment in Progress"). This ensures that only one of the scenarios will succeed, and the other will definitely fail. Assuming scenario 1 succeeds, the user has already successfully paid, so the payment status has changed to "Paid," and the cancellation SQL will definitely fail; no further action is needed. Assuming scenario 2 succeeds, the order has already been cancelled, and the payment status has changed to "Cancelled." The payment success SQL will definitely fail; in this case, the order is cancelled, and a refund operation needs to be performed to issue a refund to the user.

[0081] In some embodiments, updating the payment status of the order table based on the first time container, the second time container, and the distributed lock further includes: In response to the detection that only the first time container exists, the payment status is updated based on the first time container and the distributed lock; In response to the detection that only the second time container exists, the payment status is updated based on the second time container and the distributed lock.

[0082] In the process of updating the order table payment status based on the first time container, the second time container, and the distributed lock, after receiving the payment success information of the target order, if the system detects that only the first time container exists in the current scenario, meaning there is no second time container interfering with the order payment status, the system will follow a predetermined procedure: first, acquire the distributed lock to ensure the atomicity and consistency of the operation; then, based on the preset logic in the first time container (such as updating the order payment status to "paid"), complete the payment status update operation, and release the distributed lock after the operation is completed. Similarly, when it is detected that only the second time container exists, the system will also first acquire the distributed lock, then update the order payment status according to the logic of the second time container (such as updating the order payment status to "cancelled"), and finally release the distributed lock.

[0083] By handling scenarios where only the first-time container or only the second-time container exists separately, the flexibility and adaptability of the order payment status update logic are enhanced. Distributed locks ensure the accuracy and consistency of data operations under different conditions, preventing omissions or errors in status updates. This improves the stability and reliability of the entire order management system, providing users with a higher quality order processing service.

[0084] In some embodiments, updating the payment status based on the second time container and the distributed lock includes: Acquire the second distributed lock for the target order; In response to successfully acquiring the second distributed lock of the target order, obtain the current payment status and second version number of the order table; In response to the current payment status being "paying", an order cancellation operation is performed, and based on the update operation of the current payment status in the second time container, the second version number is compared with the current version number of the order table; In response to the second version number being consistent with the current version number, the current payment status of the order table is updated to "cancelled" and the current version number is updated, and the second distributed lock is released; In response to the inconsistency between the second version number and the current version number, retry updating the current payment status of the order table to "cancelled" or terminate the process.

[0085] When updating the order payment status based on the second time container and distributed lock, the process first attempts to acquire the second distributed lock corresponding to the target order. Upon successful acquisition, the current payment status and second version number of the order table are obtained. If the current payment status is "Paying," the order is cancelled first. Before updating the payment status based on the second time container, the second version number is compared with the current version number of the order table. If they match, it indicates that the order status has not been modified by other operations. In this case, the payment status of the order table is updated to "Cancelled," the current version number is updated, and the second distributed lock is released. If the second version number does not match the current version number, it indicates that other operations have affected the order status. In this case, the update of the payment status can be retried. If the retry fails or certain conditions are met, the update process ends.

[0086] By leveraging a second distributed lock, it is ensured that only one operation can modify the order payment status at a time in a distributed environment, effectively avoiding concurrent conflicts. The version number comparison mechanism further guarantees the accuracy and security of data updates; status updates are only performed when version numbers match, preventing data overwriting. This improves the reliability and stability of order cancellation and payment status updates, ensures the integrity and consistency of system data, provides users with more accurate order status feedback, and enhances the user experience.

[0087] In some embodiments, method 300 further includes: In response to the failure to successfully acquire the second distributed lock for the target order, retry acquiring the second distributed lock or send an exception message to indicate that the target order is an abnormal order; In response to the current payment status being "paid", the order cancellation operation is refused, and the second distributed lock is released.

[0088] In the process of updating order payment status based on the second time container and distributed lock, if the initial attempt to acquire the second distributed lock corresponding to the target order fails, the system will initiate a retry mechanism to try to acquire the lock again. If it still fails to acquire the lock after multiple retries, an exception message will be sent, marking the target order as an abnormal order for subsequent processing. Furthermore, after successfully acquiring the second distributed lock and obtaining the current payment status from the order table, if the current payment status is found to be paid, the system will refuse to execute the order cancellation operation and release the acquired second distributed lock, avoiding unnecessary occupation of lock resources. This retry mechanism increases the success rate of acquiring the second distributed lock, improving the system's fault tolerance. Sending exception messages to mark abnormal orders after retry failures helps staff to promptly identify and handle problematic orders, ensuring the integrity of the order processing flow. Refusing to execute cancellation operations and promptly releasing the lock for paid orders not only follows business logic rules and prevents erroneous operations but also reasonably releases system resources, improving the overall operating efficiency and stability of the system and providing users with more reliable and accurate order management services.

[0089] In some embodiments, method 300 further includes: Batch process abnormal orders to update the payment status of the abnormal orders.

[0090] For abnormal orders that were previously marked for various reasons (such as failing to acquire the second distributed lock), the system will initiate a batch processing mechanism. This mechanism will collect information on these abnormal orders and, according to preset rules and logic, centrally check and update their payment status. For example, it will re-verify the actual payment situation of the order and update the payment status to the accurate status (such as paid, canceled, etc.) based on the verification results, ensuring that the payment status of abnormal orders matches the actual situation.

[0091] Batch processing of abnormal orders significantly improves processing efficiency, avoiding the time and resource waste associated with processing each abnormal order individually. It enables rapid and large-scale correction of the payment status of abnormal orders. This helps improve the data accuracy and consistency of the entire order management system, ensuring that order status accurately reflects the actual business situation. Simultaneously, it provides a reliable data foundation for subsequent order statistics, analysis, and customer service, enhancing system stability and reliability, and optimizing the user experience.

[0092] Specifically, the Hangfire JOB solution can be used for compensation to prevent omissions. The fallback mechanism uses a "direct database operation" approach to ensure eventual consistency and prevent task loss due to middleware failure. Hangfire distributed job scheduling is an open-source .NET task scheduling framework primarily used for background task scheduling, scheduled task execution, and persistent job storage. For example, a task can be executed at a scheduled time to batch process unprocessed orders—timed-out, canceled, and paid orders—using the JOB as a fallback mechanism for final status updates. MQ prioritizes real-time performance: a delayed message is sent immediately after a user places an order, triggering cancellation 15 minutes later. JOB acts as a fallback mechanism: it scans the database for unpaid and timed-out orders and updates their final status. The database is the core data source and is generally more stable than middleware; therefore, a "direct database operation" approach is used to ensure eventual consistency. The middleware (MQ) can be used as part of the main process for real-time processing.

[0093] In summary, database transaction control and Redis distributed locks can effectively resolve the conflict between user payments and order cancellations. This solution integrates RabbitMQ, a time capsule mechanism, Redis distributed transactions, optimistic database locking, a state machine mechanism, and eventual consistency.

[0094] Distributed Coordination: Redis locks prevent concurrent conflicts across multiple nodes; in payment callbacks and scheduled tasks, Redis locks are used to lock the order number, ensuring that only one operation can modify the order status at a time. Asynchronous Safety: Message queue + ACK mechanism prevents message loss or duplicate consumption; message persistence (preventing message loss), consumer acknowledgment mechanism (ACK), and retry mechanism (retry on failure). After processing a message, the consumer actively sends an ACK; if processing fails or times out, the message queue will re-deliver the message. Race Conditions: Optimistic locking + double confirmation prevents payment and cancellation conflicts; a version number field (version) is added to the order table, and the version number is checked every time the order status is updated to avoid concurrent modifications. Double confirmation involves checking again whether the order has been paid or cancelled in the cancellation or payment process. State Machine Mechanism: Automated flow from order payment to success or failure is achieved through preset rules; in the payment process, state management is not just about recording the order status, but about ensuring that each step accurately reflects the actual business operation. Hangfire JOB Solution + Compensation Mechanism: If a small number of messages are lost, a task can be executed at a preset time to cancel these unprocessed orders in batches. If any have already been paid, the refund interface can be called to automatically refund the money to the user. This fallback mechanism has minimal impact on the system. Data Consistency: Database transactions + eventual consistency compensation ensure consistency between accounts and inventory. In the order system, data consistency is a core requirement for ensuring transaction security, inventory accuracy, and account reconciliation. Especially in critical business processes such as payment, cancellation, and refund, it is essential to ensure that: order status changes, inventory deductions or releases, user account changes (such as balances and points), and payment record updates all either succeed or all fail. Final Failure Fallback: Exception logs + manual intervention mechanism handle abnormal situations. In the order system, even with distributed locks, database transactions, optimistic locking, and eventual consistency reconciliation mechanisms, it is still impossible to completely avoid the occurrence of certain extreme exceptions. Operation logs + cancellation / payment records facilitate problem localization, and the introduction of a failure fallback mechanism ensures the robustness and recoverability of the system. Eventual Consistency Guarantee: Reconciliation system + compensation mechanism as the last line of defense. In distributed systems or high-concurrency transaction systems, eventual consistency is the last line of defense to ensure data accuracy and reconciliation of accounts. Especially after handling race conditions such as "order timeout cancellation" and "user payment," some anomalies may arise, such as inconsistencies in status, unreleased inventory, and incorrect amounts. Regularly comparing core business data (such as order status, payment records, inventory, and account balances) to identify and record inconsistencies, and then automatically repairing or manually intervening in these inconsistencies, is crucial.

[0095] As can be seen, this disclosure achieves secure order status updates and exception handling under high concurrency through a collaborative mechanism of status recording, delayed queues, and distributed locks: When a user initiates a payment request, the system first marks the order status as "pending payment" and adds it to a delayed queue (such as RabbitMQ) for automatic cancellation upon timeout; after successful payment, the server attempts to acquire the order's distributed lock (such as a Redis lock), and upon successful acquisition, verifies the order's current status—if it is "pending payment," it updates it to "paid" and releases the lock; if it is already "paid" (due to duplicate callbacks or concurrent conflicts), a refund process is triggered; if the lock is not acquired, a retry or alert is issued. This solution ensures serialized processing of the same order through the locking mechanism, avoiding data inconsistency caused by concurrent updates. Simultaneously, the delayed queue acts as a timeout fallback, automatically canceling the order after timeout even if the payment callback fails, ultimately ensuring strong consistency between order status and cash flow, and improving system reliability.

[0096] It should be noted that the method of this embodiment can be executed by a single device, such as a computer or server. The method of this embodiment can also be applied to a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method of this embodiment, and the multiple devices will work together to generate video to complete the method described.

[0097] It should be noted that the above description describes some embodiments of this disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0098] Based on the same technical concept, corresponding to any of the above embodiments, this disclosure also provides a payment device, see [link to relevant documentation]. Figure 10 The payment device includes: The order creation module is used to respond to receiving an order creation request for a target order from the user terminal, create a corresponding order table in the database, set the payment status of the order table to pending payment, and create a delay message for the target order in the delay queue. A first container module is configured to, in response to detecting an order payment operation for the target order, update the status of the target order to "paying" and create a first time container with a first priority; the first time container is configured to update the payment status of the order table to "paid" within a first valid time period; the first valid time period is determined based on the payment time corresponding to the order payment operation and a first preset duration; The second container module is used to create a second time container with a second priority in response to the detection of a delayed message expiring; the second time container is used to update the payment status of the order table to canceled within a second valid time period; the second valid time period is determined based on the cancellation time corresponding to the order cancellation operation and a second preset duration; The status update module, in response to receiving payment success information for the target order, updates the payment status of the order table based on the first time container, the second time container, and the distributed lock.

[0099] For ease of description, the above apparatus is described in terms of its functions, divided into various modules. Of course, in implementing this disclosure, the functions of each module can be implemented in one or more software and / or hardware.

[0100] The apparatus of the above embodiments is used to implement the corresponding payment method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0101] Based on the same technical concept, corresponding to the methods of any of the above embodiments, this disclosure also provides a non-transitory computer-readable storage medium that stores computer instructions for causing the computer to execute the payment method as described in any of the above embodiments.

[0102] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0103] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the payment method as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0104] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this disclosure (including the claims) is limited to these examples; within the framework of this disclosure, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this disclosure as described above, which are not provided in detail for the sake of brevity.

[0105] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this disclosure, the provided drawings may or may not show well-known power / ground connections to integrated circuit (IC) chips and other components. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this disclosure, and this also takes into account the fact that the details of implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this disclosure will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this disclosure, it will be apparent to those skilled in the art that the embodiments of this disclosure can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0106] Although this disclosure has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0107] This disclosure is intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.< / object> < / paymentinfo> < / t>

Claims

1. An order payment method, comprising: In response to receiving an order creation request for a target order from a user, a corresponding order table is created in the database, the payment status of the order table is set to pending payment, and a delay message for the target order is created in the delay queue. In response to detecting an order payment operation for the target order, the status of the target order is updated to "paying" and a first time container with a first priority is created; the first time container is used to update the payment status of the order table to "paid" within a first valid time period; the first valid time period is determined based on the payment time corresponding to the order payment operation and a first preset duration; In response to the detection that the time has reached a preset time before the expiration of the delayed message, a second time container with a second priority is created; the second time container is used to update the payment status of the order table to canceled within a second valid time period; the second valid time period is determined based on the cancellation time corresponding to the order cancellation operation and a second preset duration; In response to receiving payment success information for the target order, the payment status of the order table is updated based on the first time container, the second time container, and the distributed lock.

2. The method according to claim 1, wherein, The first priority decreases over time, while the second priority increases over time. The payment status of the order table is then updated based on the first time container, the second time container, and the distributed lock, including: In response to the overlap between the first valid time period and the second valid time period, based on the magnitude of the first priority and the second priority, it is determined whether the first time container or the second time container is used to update the payment status; The payment status is updated based on the first time container or the second time container, and the distributed lock; Specifically, determining whether to use the first time container or the second time container to update the payment status based on the magnitude of the first priority and the second priority includes: In response to the first priority being greater than the second priority, it is determined that the first time container is used to update the payment status; In response to the first priority being lower than the second priority, it is determined that the second time container is used to update the payment status; In response to the first priority being equal to the second priority, based on the first effective duration corresponding to the first time container and the second effective duration corresponding to the second time container, it is determined that the first time container or the second time container is used to update the payment status; Specifically, determining whether the first time container or the second time container is used to update the payment status based on the first effective duration corresponding to the first time container and the second effective duration corresponding to the second time container includes: In response to the first effective duration being greater than or equal to the second effective duration, it is determined that the first time container is used to update the payment status; In response to the first effective duration being less than the second effective duration, it is determined that the second time container is used to update the payment status.

3. The method according to claim 2, wherein, Updating the payment status based on the first time container and the distributed lock includes: Acquire the first distributed lock for the target order; In response to successfully acquiring the first distributed lock of the target order, obtain the current payment status and first version number of the order table; In response to the current payment status being "paying", the first version number is compared with the current version number of the order table based on the update operation of the first time container on the current payment status; In response to the first version number being consistent with the current version number, the current payment status of the order table is updated to paid and the first version number is updated, and the first distributed lock is released; If the first version number is inconsistent with the current version number, retry updating the current payment status of the order table to paid, or terminate the process.

4. The method according to claim 3, further comprising: In response to the current payment status being cancelled, a refund message is sent to the payer; In response to the failure to successfully acquire the first distributed lock for the target order, retry acquiring the first distributed lock or send an exception message to indicate that the target order is an abnormal order.

5. The method according to claim 2, wherein, Updating the payment status of the order table based on the first time container, the second time container, and the distributed lock further includes: In response to the detection that only the first time container exists, the payment status is updated based on the first time container and the distributed lock; In response to the detection that only the second time container exists, the payment status is updated based on the second time container and the distributed lock.

6. The method according to claim 5, wherein, Updating the payment status based on the second time container and the distributed lock includes: Acquire the second distributed lock for the target order; In response to successfully acquiring the second distributed lock of the target order, obtain the current payment status and second version number of the order table; In response to the current payment status being "paying", an order cancellation operation is performed, and based on the update operation of the current payment status in the second time container, the second version number is compared with the current version number of the order table; In response to the second version number being consistent with the current version number, the current payment status of the order table is updated to "cancelled" and the current version number is updated, and the second distributed lock is released; In response to the inconsistency between the second version number and the current version number, retry updating the current payment status of the order table to "cancelled" or terminate the process.

7. The method according to claim 6, further comprising: In response to the failure to successfully acquire the second distributed lock for the target order, retry acquiring the second distributed lock or send an exception message to indicate that the target order is an abnormal order; In response to the current payment status being "paid", the order cancellation operation is refused, and the second distributed lock is released.

8. An order payment device, comprising: The order creation module is used to respond to receiving an order creation request for a target order from the user terminal, create a corresponding order table in the database, set the payment status of the order table to pending payment, and create a delay message for the target order in the delay queue. A first container module is configured to, in response to detecting an order payment operation for the target order, update the status of the target order to "paying" and create a first time container with a first priority; the first time container is configured to update the payment status of the order table to "paid" within a first valid time period; the first valid time period is determined based on the payment time corresponding to the order payment operation and a first preset duration; The second container module is used to create a second time container with a second priority in response to detecting that the time has reached a preset time before the expiration of the delayed message; the second time container is used to update the payment status of the order table to canceled within a second effective time period; the second effective time period is determined based on the cancellation time corresponding to the order cancellation operation and a second preset duration; The status update module, in response to receiving payment success information for the target order, updates the payment status of the order table based on the first time container, the second time container, and the distributed lock.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method as claimed in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform the method of any one of claims 1 to 7.

Images