A coupon automatic cancellation and account distribution method based on payment callback event driving

Abstract

This application discloses an automatic coupon redemption and revenue sharing method based on payment callback events. The method first receives a callback notification from the payment platform and verifies its validity. Upon successful verification, it updates the order status and publishes a payment success event. It then asynchronously listens for events using virtual threads and filters applicable coupons for users based on multi-dimensional rules. The method atomically executes coupon redemption and revenue sharing instruction generation within a single transaction. It calls the payment interface to execute revenue sharing and automatically retryes using an exponential backoff strategy. Idempotency is guaranteed through a dual mechanism. This application decouples payment callbacks from business processing through an event-driven architecture, ensures consistency between redemption and revenue sharing through atomic transactions, supports dynamic revenue sharing rule configuration, and leverages virtual thread technology to enhance high-concurrency processing capabilities, achieving fully automated, low-latency, and highly reliable business processing.

Description

Technical Field

[0001] This application relates to the fields of smart parking technology, electronic payment technology and distributed transaction processing technology, and in particular to a method for automatic card and coupon redemption and revenue sharing based on payment callback event-driven payment. Background Technology

[0002] With the rapid development of the smart parking industry, electronic payment and coupons (such as discount coupons, vouchers, and vouchers) have become core means to improve user experience and promote operational conversion. Existing smart parking systems generally suffer from the following technical deficiencies in the process of users paying parking fees using coupons:

[0003] Fragmented business processes and poor data consistency: The coupon redemption module and the fund allocation module are independent of each other. The allocation operation often relies on asynchronous notification of redemption results, which can easily lead to inconsistent status issues such as "coupon has been redeemed but allocation failed" or "allocation completed but coupon has not been redeemed", resulting in financial losses or user complaints.

[0004] High reliance on manual intervention and low settlement efficiency: Some systems require operators to manually review the legality of card and coupon usage before proceeding with the settlement, which takes several hours or even days and cannot meet the real-time reconciliation requirements.

[0005] Insufficient robustness in high-concurrency scenarios: Payment platform callback requests are characterized by high concurrency and repeated callbacks. Existing systems lack a sound idempotency design, which can easily lead to problems such as duplicate reconciliation, duplicate accounting, or callback processing timeouts.

[0006] Poor scalability and high maintenance costs: When adding new revenue-sharing entities (such as cooperative promotion parties or equipment suppliers) or adjusting the revenue-sharing ratio, it is necessary to modify the core business code and redeploy it, which violates the open / closed principle of software design and has a long cycle for adapting to new business models.

[0007] High resource consumption and limited concurrent processing capability: In the traditional thread model, each callback processing task occupies one physical thread. In high-concurrency scenarios, the exhaustion of thread resources leads to processing bottlenecks, which cannot meet the callback processing requirements of large-scale parking scenarios.

[0008] While some existing technologies employ message queues to decouple payment from business logic, they still fail to address the end-to-end closed-loop problem of "payment callback - automatic card / voucher matching - atomic execution of verification and revenue sharing," and do not fully leverage next-generation Java Virtual Machine (JVM) technology to enhance concurrent processing capabilities. Therefore, there is an urgent need for a highly reliable, low-latency, and scalable integrated processing solution to address the pain points of existing technologies. Summary of the Invention

[0009] Based on this, this application provides a method for automatic card and coupon redemption and accounting based on payment callback event-driven approach. It achieves decoupling of payment callback and business processing through event-driven architecture, ensures consistency between redemption and accounting with atomic transactions, supports dynamic accounting rule configuration, and utilizes virtual thread technology to improve high-concurrency processing capabilities, thereby achieving fully automated, low-latency, and highly reliable business processing.

[0010] Firstly, a method for automatic card and coupon redemption and revenue sharing based on payment callback events is provided, which includes:

[0011] S1 receives callback notifications from the payment platform; these callback notifications must include at least the order ID, user ID, payment amount, and scenario identifier.

[0012] S2, perform legality verification, and update the order status to paid after successful verification; wherein, the verification includes at least signature verification, order existence verification and transaction status verification;

[0013] S3, publish a payment success event carrying order context information; wherein, the payment success event carries at least the order ID, user ID, payment amount, payment time, and scenario identifier information;

[0014] S4, the payment success event is received using an asynchronous listening method, and electronic coupons applicable to the current order in the user's account are filtered according to preset coupon matching and filtering rules; wherein, the preset coupon matching and filtering rules include at least coupon status, validity period, order amount threshold and scenario adaptability;

[0015] S5, if a valid card is matched, card redemption is performed in a single transaction and a multi-entity revenue sharing instruction is generated based on the payment amount and the card discount amount. If no valid card is matched, a basic revenue sharing instruction is generated based on the payment amount.

[0016] S6. The payment interface is called to execute the splitting according to the splitting instruction. If it fails, it will automatically retry based on the exponential backoff strategy. If the retry fails, the splitting task will be transferred to the compensation queue and an alarm will be triggered.

[0017] S7 records the order processing status and calls the payment interface based on the unique split request number to prevent duplicate processing and complete the business loop.

[0018] Optionally, if a valid coupon is matched in S5, coupon redemption is performed within a single transaction, and a multi-entity revenue sharing instruction is generated based on the payment amount and the coupon discount amount, specifically including:

[0019] Update the coupon status to "redeemed" and link it to the current order ID;

[0020] Dynamic revenue sharing rules are loaded based on the scenario identifier, and the revenue sharing base is calculated based on the payment amount and coupon discount amount to generate multi-entity revenue sharing instructions.

[0021] Optionally, steps S3 and S4 are decoupled through the SpringApplicationEvent event mechanism, and the event listening logic in step S4 runs on the JDK21 virtual thread; the virtual thread is specifically created through the Thread.ofVirtual method.

[0022] Optionally, dynamic revenue sharing rules are stored in the configuration center and support hot updates. Revenue sharing rules include revenue sharing entities, account information, revenue sharing ratios, and applicable scenarios. No core business code needs to be modified when adding revenue sharing entities or adjusting revenue sharing ratios.

[0023] Optionally, the database transaction in step S5 is implemented using SpringTransactionTemplate to ensure the atomicity of card redemption and billing instruction generation, and to trigger transaction rollback if any operation fails.

[0024] Optionally, the automatic retry in step S6 adopts an exponential backoff strategy, the number of retries is configurable, and after a retry failure, the revenue sharing task is written to the compensation queue and an alarm notification is triggered.

[0025] Optionally, idempotency is guaranteed through a dual mechanism: recording the processing status based on the order ID, and ensuring idempotency of the revenue sharing interface based on the unique revenue sharing request number.

[0026] Secondly, a payment callback event-driven automatic voucher redemption and revenue sharing system is provided, which includes:

[0027] The callback receiving module is used to receive callback notifications from the payment platform; the callback notification includes at least the order ID, user ID, payment amount, and scenario identifier.

[0028] The legitimacy verification module is used to perform legitimacy verification and update the order status to "paid" after successful verification; wherein, the verification includes at least signature verification, order existence verification, and transaction status verification;

[0029] The order update module is used to publish a payment success event carrying order context information; wherein, the payment success event carries at least the order ID, user ID, payment amount, payment time, and scenario identifier information;

[0030] The event publishing module is used to receive the payment success event in an asynchronous listening manner, and to filter electronic coupons in the user's account that are applicable to the current order according to the preset coupon matching and filtering rules; wherein, the preset coupon matching and filtering rules include at least coupon status, validity period, order amount threshold and scenario adaptability;

[0031] The atomic processing module is used to perform card redemption in a single transaction if a valid card is matched, and to calculate the revenue sharing base based on the payment amount and the card discount amount to generate multi-entity revenue sharing instructions. If no valid card is matched, a basic revenue sharing instruction is generated based on the payment amount.

[0032] The revenue sharing execution module is used to call the payment interface to execute revenue sharing according to the revenue sharing instruction. If it fails, it will automatically retry based on the exponential backoff strategy. If the retry fails, the revenue sharing task will be transferred to the compensation queue and an alarm will be triggered.

[0033] The idempotency guarantee module is used to record the order processing status and call the payment interface based on the unique revenue sharing request number to prevent duplicate processing and complete the business loop.

[0034] Thirdly, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement any of the methods described in the first aspect above.

[0035] Fourthly, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements any of the methods described in the first aspect above.

[0036] The beneficial effects of the technical solutions provided in this application include at least the following:

[0037] High degree of automation, significantly improved settlement efficiency: From successful payment to settlement completion, no human intervention is required, processing delay is controlled in seconds, and settlement time is shortened from the traditional hours / days to seconds, improving user experience and operational efficiency;

[0038] Strong data consistency, avoiding the risk of financial loss: By binding card and coupon redemption with the generation of accounting instructions through atomic transactions, the state of the two is synchronized, which completely solves the pain point of "inconsistency between redemption and accounting" in existing technologies and reduces the risk of financial loss;

[0039] Excellent scalability and strong adaptability: The revenue sharing rules and coupon matching rules support dynamic configuration. When adding a revenue sharing entity, adjusting the revenue sharing ratio, or adding a coupon type, there is no need to modify the core code, only to update the configuration. The cycle of adapting to new business models is shortened to minutes.

[0040] Strong concurrent processing capability and low resource consumption: Based on JDK 21 virtual thread technology, each callback processing task occupies a virtual thread. The creation and switching cost of virtual threads is much lower than that of physical threads. A single machine can support a callback processing capability of thousands of TPS, and the resource consumption rate is significantly reduced.

[0041] High robustness and low maintenance cost: The robust idempotency design and fault tolerance mechanism ensure the correctness of business operations in high-concurrency and repetitive callback scenarios; the clear event-driven architecture facilitates monitoring, tracing, and fault location, reducing system maintenance costs.

[0042] High compatibility and reusability: It supports integration with mainstream third-party payment platforms (ePay, Alipay, WeChat Pay, etc.), can be seamlessly integrated into existing smart parking systems, and can also be extended to other scenarios that require card and coupon verification and multi-entity revenue sharing, such as ride-hailing and shared mobility. Attached Figure Description

[0043] To more clearly illustrate the embodiments of this application or the technical solutions in the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings in the following description are merely exemplary, and those skilled in the art can derive other embodiments based on the provided drawings without creative effort.

[0044] Figure 1 A flowchart illustrating the steps of an automatic card and coupon redemption and revenue sharing method driven by payment callback events, provided in this application embodiment;

[0045] Figure 2 A system flowchart provided for optional embodiments of this application;

[0046] Figure 3 System architecture diagram provided for embodiments of this application;

[0047] Figure 4 Timing interaction diagram provided for embodiments of this application;

[0048] Figure 5 A system block diagram of an automatic card and coupon redemption and revenue sharing method based on payment callback event-driven implementation of this application is provided in an embodiment of the present application.

[0049] Figure 6 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0051] In the description of this application, the terms "comprising," "having," and any variations thereof are intended to cover non-exclusive inclusion, such as a process, method, system, product, or apparatus that includes a series of steps or units, not necessarily limited to those steps or units that are expressly listed, but may also include other steps or units that are not expressly listed but are inherent to these processes, methods, products, or apparatuses, or steps or units added based on further optimizations conceived in this application.

[0052] This application relates to the fields of smart parking technology, electronic payment technology, and distributed transaction processing. Specifically, it relates to a method for integrated processing of automatic card and coupon redemption and multi-entity fund distribution based on payment callback events. This method is particularly suitable for intelligent parking operation systems in high-concurrency scenarios under a microservice architecture, enabling end-to-end automated closed-loop processing of card and coupon matching, redemption, and fund distribution after payment. Please refer to [reference needed]. Figure 1 The document illustrates a flowchart of an automatic voucher redemption and revenue sharing method based on payment callback events, provided in an embodiment of this application. This method may include the following steps:

[0053] S1 receives callback notifications from the payment platform.

[0054] The callback notification should include at least the order ID, user ID, payment amount, and scenario identifier.

[0055] S2 performs a validity verification and updates the order status to "paid" after the verification is successful.

[0056] The verification process includes at least signature verification, order existence verification, and transaction status verification.

[0057] S3 publishes a payment success event carrying order context information.

[0058] Among them, a successful payment event must carry at least the order ID, user ID, payment amount, payment time, and scenario identifier information.

[0059] S4 uses an asynchronous listening method to receive payment success events and filters electronic coupons in the user's account that are applicable to the current order according to preset coupon matching and filtering rules.

[0060] The preset coupon matching and filtering rules include at least coupon status, validity period, order amount threshold, and scenario suitability. Specifically, the preset coupon matching and filtering rules (i.e., the coupon matching engine filters applicable coupons based on the following rules):

[0061] Basic rules: The coupon status is "unused", the coupon validity period includes the current time, and the user ID is the same as the user ID to which the coupon belongs;

[0062] Amount rule: The actual payment amount of the order is greater than or equal to the minimum amount for using the coupon (e.g., coupons can be used when the amount is 10 yuan or more).

[0063] Scenario rules: The applicable scenarios for the coupons include the current parking lot ID or parking service type;

[0064] Priority rule: If a user has multiple applicable coupons, they are sorted by "discount strength in descending order + validity period in ascending order", and the best coupon is selected.

[0065] S5: If a valid coupon is matched, the coupon redemption is executed in a single transaction, and a multi-entity splitting instruction is generated based on the payment amount and the coupon discount amount. If no valid coupon is matched, a basic splitting instruction is generated based on the payment amount.

[0066] This includes updating the coupon status to "redeemed" and linking it to the current order ID;

[0067] Dynamic revenue sharing rules are loaded based on the scenario identifier, and the revenue sharing base is calculated based on the payment amount and coupon discount amount to generate multi-entity revenue sharing instructions.

[0068] In this embodiment, decoupling is achieved through the SpringApplicationEvent event mechanism. The event listening logic in step S4 runs on a JDK21 virtual thread; specifically, the virtual thread is created using the Thread.ofVirtual method. The database transaction in step S5 is implemented using SpringTransactionTemplate to ensure the atomicity of coupon redemption and billing instruction generation, and to trigger transaction rollback if either operation fails.

[0069] S6 calls the payment interface to execute the revenue sharing according to the revenue sharing instruction. If it fails, it will automatically retry based on the exponential backoff strategy. If the retry fails, the revenue sharing task will be transferred to the compensation queue and an alarm will be triggered.

[0070] In this application, the revenue sharing rules are stored in the configuration center in JSON format, which supports configuring the revenue sharing ratio of multiple entities according to the scenario and supports hot updates. The revenue sharing rules include the revenue sharing entity, account information, revenue sharing ratio and applicable scenario. When adding a revenue sharing entity or adjusting the revenue sharing ratio, there is no need to modify the core business code.

[0071] The specific calculation logic for the revenue sharing amount includes: actual revenue sharing base = payment amount - coupon discount amount, and revenue sharing amount for each revenue sharing entity = revenue sharing base × revenue sharing ratio.

[0072] S7 records the order processing status and calls the payment interface based on the unique split request number to prevent duplicate processing and complete the business loop.

[0073] In this application, order-level idempotency is achieved by creating the `processed_order` table to record the processed order ID, processing status, and processing time. This table is queried before each event is processed, and if the event has already been processed, it is returned directly.

[0074] Callback-level idempotency: Utilizes the unique transaction ID (transactionId) in the callback notification from the third-party payment platform as the idempotency key to avoid duplicate callback processing;

[0075] Interface-level idempotency: When calling the payment gateway's revenue sharing interface, a unique revenue sharing request number (generated based on the order ID) is passed in, and the payment platform implements idempotency processing based on this request number.

[0076] In this embodiment of the application, the retry mechanism is as follows: when the revenue sharing interface call fails, SpringRetry is used to retry up to 3 times, and the retry interval adopts an exponential backoff strategy (1s, 3s, 5s).

[0077] Transaction rollback: If an exception occurs during the generation of reimbursement or splitting instructions, a transaction rollback is triggered to restore the card / coupon status and order processing flags.

[0078] Manual compensation: After a retry fails, the revenue sharing task is written to the compensation queue, allowing operations personnel to manually trigger revenue sharing or adjust the status. At the same time, anomaly logs are recorded to facilitate troubleshooting.

[0079] like Figure 2 A flowchart of the core technology is provided. Additionally, as... Figure 3The system architecture diagram (relationship of microservice components) is given. Specifically, it shows the layered architecture design of the automatic card and coupon redemption and revenue sharing system based on payment callback event. The overall system adopts a four-layer structure to achieve a highly cohesive and loosely coupled system design. The top layer is the external system layer, which includes a third-party payment platform, configuration center, monitoring and alarm system, and database, responsible for payment callback access, hot updating of revenue sharing rules, performance monitoring and alarms, and data persistence, respectively. The middle layer is the application service layer, built on Spring Boot 3.4 and JDK 21, and is subdivided into an access layer, an event-driven layer, and a core business layer. The access layer completes callback reception and legality verification through a callback controller, a validation service, and an order service. The event-driven layer decouples payment processing from business logic through payment success events and event publishers. The core business layer completes core logic such as coupon redemption and revenue sharing listeners, coupon services, and revenue sharing services, and runs on a virtual thread pool. The bottom layer is the infrastructure layer, which provides general technical capabilities such as virtual thread pools, transaction management, retry mechanisms, and idempotency guarantees to support the high-concurrency and high-reliability execution of upper-layer businesses. This architecture achieves unified external service integration, independent evolution of core business logic, and reuse of general capabilities through a layered design. Combined with event-driven mechanisms and virtual thread technology, it achieves an end-to-end automated closed loop for payment callbacks, coupon redemption, and fund distribution.

[0080] like Figure 4 The sequence diagram illustrates the process, which begins with the payment platform sending a payment success callback to the callback controller. The controller first performs signature and validity verification. Upon successful verification, it calls the order service to update the order status to "paid," and then immediately returns a success response to the payment platform, achieving a second-level response. Simultaneously, a payment success event is asynchronously published via the event bus, received and processed by an event listener executed based on a virtual thread pool. The listener first performs an idempotency check to prevent duplicate processing, and then uses a coupon matching engine to select the optimal applicable coupon. Within the atomic transaction boundary, the process sequentially executes the following steps: updating the coupon redemption status, calculating the revenue sharing base based on the payment amount and coupon discount, generating multi-entity revenue sharing instructions according to dynamic rules, marking the order as processed, and asynchronously calling the revenue sharing service to execute the revenue sharing interface after the transaction is committed. It supports retrying on failure and a compensation queue, and finally completes the fund transfer and audit log recording. This sequence diagram clearly demonstrates the separation of synchronous fast response and asynchronous reliable processing, the transaction boundary and atomicity guarantee mechanism, and the multi-layered idempotency design, ensuring data consistency and business reliability in high-concurrency scenarios.

[0081] The following outlines the key code execution logic of this application, specifically including:

[0082] 1. Payment Callback Controller (Receiver Entry)

[0083] First, the system receives a payment success callback request from the third-party payment platform. It then uses a callback verification service to validate the callback notification, including signature verification, order existence verification, and transaction status verification. If verification fails, an error response is returned. Upon successful verification, the system calls the order service to atomically update the order status to "paid," ensuring consistency. Next, it publishes a payment success event carrying contextual information such as order ID, user ID, payment amount, payment time, and parking lot ID via an event publisher. This event is asynchronously listened to by the Spring event mechanism and executed using a JDK 21 virtual thread, decoupling payment processing from subsequent card / coupon redemption and revenue sharing. Finally, it returns a callback success response that meets the payment platform's requirements, completing end-to-end processing of the payment callback.

[0084] 2. Definition of payment success event (including scenario context)

[0085] This event is used to pass core context information to subsequent business modules after the payment callback process is completed. It includes key fields such as a unique order identifier, user identifier, payment amount, payment time, and parking lot scenario identifier, and employs thread-safe data encapsulation using immutable data record types.

[0086] 3. Card / coupon redemption and revenue sharing listener (core business logic)

[0087] First, payment success events are subscribed to via event listener annotations, and a virtual thread task executor is specified to achieve asynchronous non-blocking processing. Upon receiving an event, an idempotency check is performed, and the order processing status table is queried to determine whether the order has been processed. If it has been processed, it returns directly to avoid duplicate execution. If it has not been processed, a database transaction is started using a transaction template. Within a single transaction, the following operations are performed atomically: the coupon service is called to match the optimal coupon applicable to the current order. The matching rules are based on dimensions such as user identifier, order amount, and scenario identifier. If a valid coupon is matched, coupon redemption is executed, the status is updated to redeemed, and the order identifier is associated. Then, the revenue sharing base is calculated based on the payment amount and coupon discount amount to generate a multi-entity revenue sharing plan with discounts. If no coupon is matched, a basic revenue sharing plan is generated directly. After the revenue sharing plan is generated, it is submitted to the revenue sharing service for asynchronous execution of the revenue sharing task, and retry is supported on failure. Upon success, the order is marked as processed. If any abnormality occurs in any part of the transaction execution, the transaction is rolled back, the order processing is marked as failed, and an abnormal log is recorded. At the same time, an alarm service is triggered to notify the operations personnel to intervene and ensure the atomicity of coupon redemption and revenue sharing instruction generation and data consistency.

[0088] 4. Revenue Sharing Service (Supports Dynamic Rules)

[0089] Firstly, a dynamic revenue sharing rule loading function is provided. It prioritizes retrieving exclusive revenue sharing rules from the configuration center based on the parking lot scenario identifier. If these rules do not exist, it reverts to loading the default rules, enabling dynamic configuration and hot updates of revenue sharing rules. When constructing a revenue sharing plan with discounts, the actual revenue sharing base is calculated by subtracting the coupon discount amount from the payment amount. Based on the loaded revenue sharing rules, the revenue sharing amount is calculated according to the revenue sharing ratio of each entity, and a revenue sharing item list is assembled. Simultaneously, a unique revenue sharing request number is generated based on the order identifier and timestamp as an idempotent key. When submitting a revenue sharing task, the payment gateway revenue sharing interface is called through a retry template. If the interface returns an unsuccessful status, an exception is thrown to trigger automatic retry. During the retry process, the current number of retries and exception information are recorded. Upon successful submission, a revenue sharing submission success log is recorded, ensuring the reliability and eventual consistency of the revenue sharing operation.

[0090] 5. Virtual thread pool configuration

[0091] The virtual thread task executor is defined by a configuration class, and the thread pool is created using the JDK21 virtual thread factory. The core thread count is set to zero and the maximum thread count is unlimited, making full use of the lightweight characteristics of virtual threads. With the help of a synchronization queue and a 60-second thread survival time, the thread pool can dynamically create and reclaim virtual threads according to the amount of callback requests, avoiding the problem of resource exhaustion in traditional physical thread pools under high concurrency.

[0092] In summary, the innovation of this application lies in:

[0093] Event-driven end-to-end closed-loop design: Using payment callback as the sole trigger source, the SpringApplicationEvent event mechanism decouples payment processing from business logic, eliminating the need for polling or scheduled tasks and reducing system coupling and resource consumption;

[0094] Atomic transaction guarantee for reimbursement and reimbursement: The update of card and coupon reimbursement status and the generation of reimbursement instructions are encapsulated in the same business transaction to ensure that the two either succeed at the same time or roll back at the same time, avoiding data inconsistency;

[0095] A dynamically configurable revenue sharing rule system: rules such as revenue sharing entities, revenue sharing ratios, and revenue sharing scenarios are stored in the configuration center and support hot updates. No core code needs to be modified when adding revenue sharing entities or adjusting rules, which greatly improves the system's scalability.

[0096] High concurrency processing capability based on virtual threads: Utilizing JDK21's Project Loom virtual thread technology and Spring Boot 3.4's native support, each callback processing task occupies a virtual thread. The mapping between virtual threads and physical threads is dynamically managed by the JVM, which significantly reduces thread resource consumption and improves callback processing throughput in high-concurrency scenarios.

[0097] Multi-layered idempotency and fault tolerance mechanisms: Idempotency is achieved through order processing status marking to avoid business anomalies caused by repeated callbacks; combined with SpringRetry retry mechanism and manual compensation queue, the eventual consistency of billing operations is ensured.

[0098] like Figure 5 This application also provides an automatic coupon redemption and revenue sharing system based on payment callback events, which may include:

[0099] The callback receiving module is used to receive callback notifications from the payment platform; the callback notification includes at least the order ID, user ID, payment amount, and scenario identifier.

[0100] The legitimacy verification module is used to perform legitimacy verification and update the order status to "paid" after successful verification; wherein, the verification includes at least signature verification, order existence verification, and transaction status verification;

[0101] The order update module is used to publish a payment success event carrying order context information; wherein, the payment success event carries at least the order ID, user ID, payment amount, payment time, and scenario identifier information;

[0102] The event publishing module is used to receive the payment success event in an asynchronous listening manner, and to filter electronic coupons in the user's account that are applicable to the current order according to the preset coupon matching and filtering rules; wherein, the preset coupon matching and filtering rules include at least coupon status, validity period, order amount threshold and scenario adaptability;

[0103] The atomic processing module is used to perform card redemption in a single transaction if a valid card is matched, and to calculate the revenue sharing base based on the payment amount and the card discount amount to generate multi-entity revenue sharing instructions. If no valid card is matched, a basic revenue sharing instruction is generated based on the payment amount.

[0104] The revenue sharing execution module is used to call the payment interface to execute revenue sharing according to the revenue sharing instruction. If it fails, it will automatically retry based on the exponential backoff strategy. If the retry fails, the revenue sharing task will be transferred to the compensation queue and an alarm will be triggered.

[0105] The idempotency guarantee module is used to record the order processing status and call the payment interface based on the unique revenue sharing request number to prevent duplicate processing and complete the business loop.

[0106] Specific limitations regarding the payment callback event-driven automatic voucher redemption and revenue sharing system can be found in the above section on the limitations of the payment callback event-driven automatic voucher redemption and revenue sharing method, and will not be repeated here. Each module in the aforementioned payment callback event-driven automatic voucher redemption and revenue sharing system 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 a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0107] In one embodiment, an electronic device is provided, which may be a computer, and its internal structure diagram may be as follows: Figure 6 As shown, the electronic device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an 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 medium. The database of the computer device is used for automatic coupon redemption and billing data. The network interface of the computer device is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements an automatic coupon redemption and billing method.

[0108] Those skilled in the art will understand that, Figure 6 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.

[0109] In one embodiment of this application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, it implements the steps of the above-described automatic card and coupon redemption and accounting method driven by payment callback events.

[0110] In one embodiment of this application, a computer program product is provided, including a computer program / instructions, which, when executed by a processor, implements the steps of the above-described automatic card and coupon redemption and accounting method based on payment callback events.

[0111] The computer-readable storage medium and computer program product provided in this embodiment are similar in implementation principle and technical effect to the above method embodiments, and will not be repeated here.

[0112] Those skilled in the art will understand that all or part of the processes in 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 the computer program is executed, it can include the processes of the embodiments of the above methods.

[0113] 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.

[0114] 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 patent application. 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 automatic voucher redemption and revenue sharing based on payment callback events, characterized in that, The method includes: S1 receives callback notifications from the payment platform; these callback notifications must include at least the order ID, user ID, payment amount, and scenario identifier. S2, perform legality verification, and update the order status to paid after successful verification; wherein, the verification includes at least signature verification, order existence verification and transaction status verification; S3, publish a payment success event carrying order context information; wherein, the payment success event carries at least the order ID, user ID, payment amount, payment time, and scenario identifier information; S4, the payment success event is received using an asynchronous listening method, and electronic coupons applicable to the current order in the user's account are filtered according to preset coupon matching and filtering rules; wherein, the preset coupon matching and filtering rules include at least coupon status, validity period, order amount threshold and scenario adaptability; S5, if a valid card is matched, card redemption is performed in a single transaction and a multi-entity revenue sharing instruction is generated based on the payment amount and the card discount amount. If no valid card is matched, a basic revenue sharing instruction is generated based on the payment amount. S6. The payment interface is called to execute the splitting according to the splitting instruction. If it fails, it will automatically retry based on the exponential backoff strategy. If the retry fails, the splitting task will be transferred to the compensation queue and an alarm will be triggered. S7 records the order processing status and calls the payment interface based on the unique split request number to prevent duplicate processing and complete the business loop.

2. The method according to claim 1, characterized in that, In S5, if a valid coupon is matched, coupon redemption is performed within a single transaction, and a multi-entity revenue sharing instruction is generated based on the payment amount and coupon discount amount, specifically including: Update the coupon status to "redeemed" and link it to the current order ID; Dynamic revenue sharing rules are loaded based on the scenario identifier, and the revenue sharing base is calculated based on the payment amount and coupon discount amount to generate multi-entity revenue sharing instructions.

3. The method according to claim 1, characterized in that, Steps S3 and S4 are decoupled through the SpringApplicationEvent event mechanism. The event listening logic in step S4 runs on the JDK21 virtual thread; the virtual thread is specifically created through the Thread.ofVirtual method.

4. The method according to claim 1, characterized in that, Dynamic revenue sharing rules are stored in the configuration center and support hot updates. Revenue sharing rules include revenue sharing entity, account information, revenue sharing ratio and applicable scenarios. No core business code needs to be modified when adding a revenue sharing entity or adjusting the revenue sharing ratio.

5. The method according to claim 1, characterized in that, The database transaction in step S5 is implemented using SpringTransactionTemplate to ensure the atomicity of card redemption and billing instruction generation, and to trigger transaction rollback if any operation fails.

6. The method according to claim 1, characterized in that, The automatic retry in step S6 adopts an exponential backoff strategy. The number of retries is configurable. If the retry fails, the revenue sharing task is written to the compensation queue and an alarm notification is triggered.

7. The method according to claim 1, characterized in that, Idempotency is guaranteed through a dual mechanism: recording the processing status based on the order ID, and ensuring idempotency of the revenue sharing interface based on the unique revenue sharing request number.

8. A card and coupon automatic redemption and revenue sharing system based on payment callback events, characterized in that, The system includes: The callback receiving module is used to receive callback notifications from the payment platform; the callback notification includes at least the order ID, user ID, payment amount, and scenario identifier. The legitimacy verification module is used to perform legitimacy verification and update the order status to "paid" after successful verification; wherein, the verification includes at least signature verification, order existence verification, and transaction status verification; The order update module is used to publish a payment success event carrying order context information; wherein, the payment success event carries at least the order ID, user ID, payment amount, payment time, and scenario identifier information; The event publishing module is used to receive the payment success event in an asynchronous listening manner, and to filter electronic coupons in the user's account that are applicable to the current order according to the preset coupon matching and filtering rules; wherein, the preset coupon matching and filtering rules include at least coupon status, validity period, order amount threshold and scenario adaptability; The atomic processing module is used to perform card redemption in a single transaction if a valid card is matched, and to calculate the revenue sharing base based on the payment amount and the card discount amount to generate multi-entity revenue sharing instructions. If no valid card is matched, a basic revenue sharing instruction is generated based on the payment amount. The revenue sharing execution module is used to call the payment interface to execute revenue sharing according to the revenue sharing instruction. If it fails, it will automatically retry based on the exponential backoff strategy. If the retry fails, the revenue sharing task will be transferred to the compensation queue and an alarm will be triggered. The idempotency guarantee module is used to record the order processing status and call the payment interface based on the unique revenue sharing request number to prevent duplicate processing and complete the business loop.

9. An electronic device, characterized in that, It includes a memory and a processor, the memory storing a computer program that, when executed by the processor, implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images