Top-up information management method and system based on third-party payment platform

Abstract

The invention relates to the technical field of electronic payment, in particular to a recharging information management method and system based on a third-party payment platform. The method comprises the following steps: receiving a recharging request and generating a unique internal order identifier; interactively initiating payment with a payment platform and appointing an asynchronous notification address; receiving an asynchronous notification containing a payment result sent by the payment platform; performing signature verification and idempotent processing on the asynchronous notification to confirm validity and uniqueness of the notification; updating the payment state of the internal order and corresponding user account information based on the asynchronous notification; and periodically acquiring transaction data of the third-party payment platform, performing automatic data check with the internal order record to identify and process the accounting difference, and executing a preset adjustment process. According to the method, the accuracy and the consistency of recharge information management can be remarkably improved, asynchronous notifications can be reliably processed, efficient automatic data checking is realized, various accounting errors are effectively reduced, and thus the user experience and the overall operation efficiency are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of electronic payment, and in particular to a recharge information management method and system based on a third-party payment platform. Background Art

[0002] With the rapid development and widespread application of internet technology, third-party payment platforms have become indispensable payment tools in a variety of scenarios, including e-commerce, online services, and even university tuition. Users use these platforms to top up and make payments, greatly improving transaction convenience. However, merchants and service providers face a series of technical challenges when accessing and managing these third-party payment platforms, particularly in managing top-up information.

[0003] Currently, a significant issue when integrating with third-party payment platforms is data inconsistency. Discrepancies often occur between the top-up information recorded by merchants' own business systems and the settlement data provided by third-party payment platforms. These discrepancies can manifest as "missed settlements" (where the merchant's system indicates a successful transaction but the payment platform hasn't settled, or vice versa), "duplicate settlements" (where the same transaction is settled multiple times), and "wrong settlements" (where the settlement amount or status doesn't match the actual amount). These data inconsistencies not only result in direct financial losses but also increase the complexity of financial reconciliation, consuming significant manpower for verification and adjustments. They can also severely impact the user experience due to untimely or erroneous account balance updates.

[0004] Another issue arises from the asynchronous notification mechanism commonly used by third-party payment platforms. After a user completes a payment, the payment result is often not immediately returned to the merchant's system. Instead, the payment platform asynchronously pushes the result to the merchant at a later time via a pre-set notification address. This asynchrony means that after initiating a payment request, the merchant's system must wait for and correctly process these subsequent notifications before confirming the final status of the top-up. During this process, network fluctuations, temporary server failures, or flaws in the notification processing logic can all lead to notification loss or processing failure.

[0005] Furthermore, the existing system also lacks real-time monitoring, anomaly warnings, and automated processing of various errors that occur during the payment process (such as signature errors, invalid parameters, and request timeouts). The lack of a unified, efficient, and automated recharge information management mechanism makes it difficult for merchants to ensure smooth, accurate, and secure recharge services in the complex third-party payment environment. Summary of the Invention

[0006] In order to solve the above problems such as inconsistent data, unreliable asynchronous notification processing, lack of unified management and real-time performance, the present invention proposes a recharge information management method and system based on a third-party payment platform.

[0007] A recharge information management method based on a third-party payment platform includes:

[0008] Receive a recharge request initiated by a user and generate a unique internal order identifier for the recharge request;

[0009] Constructing a payment instruction based on the payment method and amount specified in the recharge request, and sending the payment instruction to the corresponding third-party payment platform, wherein the payment instruction includes an asynchronous notification callback address for receiving the payment result;

[0010] receiving, at the asynchronous notification callback address, an asynchronous notification sent by the third-party payment platform, the notification including the payment result corresponding to the internal order identifier;

[0011] Perform signature verification on the received asynchronous notification to confirm the authenticity of its source, and perform idempotence processing to prevent repeated business operations on the same payment result;

[0012] If the asynchronous notification passes signature verification and is determined to be the first valid processing based on idempotence, the asynchronous notification is parsed to obtain the payment status, and the payment status of the internal order record associated with the internal order identifier and the corresponding user account information are updated according to the payment status;

[0013] Periodically obtaining transaction data recorded by one or more third-party payment platforms and automatically verifying the obtained transaction data with the internal order records, wherein the verification is used to identify one or more types of account discrepancies, including at least one or more types of missed settlements, duplicate settlements, or incorrect settlements;

[0014] Based on the account differences identified by the data verification, a preset adjustment process is executed to correct the differences or mark them for manual processing.

[0015] Preferably, the idempotent processing is performed to prevent repeated business operations on the same payment result, specifically including:

[0016] Check whether the unique notification identifier contained in the asynchronous notification has been processed;

[0017] Alternatively, a processing fingerprint is generated based on the internal order identifier and the currently known payment status, and the processing fingerprint is checked to see whether it indicates that the payment result has been processed.

[0018] Preferably, the omissions identified during the data verification process include: the internal order record shows that the payment is successful, but no corresponding successful settlement record is found in the transaction data of the third-party payment platform; or the transaction data of the third-party payment platform shows that the settlement has been successful, but no corresponding successful order is found in the internal order record or the order status is incorrect.

[0019] Preferably, the duplicate settlements identified during the data verification process include: one internal order identifier corresponding to multiple successful settlement records in the transaction data of the third-party payment platform.

[0020] Preferably, the discrepancies identified during the data verification process include: inconsistencies in actual payment amounts, handling fees or payment statuses between internal order records and transaction data of the third-party payment platform in successfully matched transactions.

[0021] Preferably, after receiving the asynchronous notification and before the automated data verification, if no asynchronous notification for a certain internal order identifier is received within a preset time, the payment status of the order is actively queried from the third-party payment platform through the query interface.

[0022] Preferably, after the asynchronous notification passes the signature verification and is determined to be the first valid processing based on the idempotence processing, a confirmation response indicating that the notification is successfully received and processed is sent back to the third-party payment platform.

[0023] The recharge information management system based on the third-party payment platform includes:

[0024] A recharge request receiving and pre-processing module configured to receive a recharge request initiated by a user and generate a unique internal order identifier for the recharge request;

[0025] A third-party payment gateway interface module is configured to construct a payment instruction based on the recharge request and send the payment instruction to the corresponding third-party payment platform, wherein the payment instruction includes an asynchronous notification callback address for receiving the payment result;

[0026] an asynchronous notification processing module configured to receive, at the asynchronous notification callback address, an asynchronous notification sent by the third-party payment platform and containing a payment result corresponding to the internal order identifier, perform signature verification and idempotence processing on the received asynchronous notification, and parse the asynchronous notification to obtain a payment status after verification and processing pass;

[0027] a user account and transaction ledger management module configured to store internal order records and user account information, and update the payment status of the internal order record associated with the internal order identifier and the corresponding user account information according to the payment status parsed by the asynchronous notification processing module;

[0028] A data verification and reconciliation module is configured to periodically obtain transaction data recorded by one or more third-party payment platforms, perform automated data verification on the obtained transaction data and the internal order records stored in the user account and transaction ledger management module, so as to identify one or more types of account discrepancies including at least missed settlements, duplicate settlements or incorrect settlements, and execute a preset reconciliation process based on the identified account discrepancies.

[0029] Preferably, the asynchronous notification processing module further includes:

[0030] Notification receiving and signature verification unit, used to receive asynchronous notifications and perform signature verification;

[0031] an idempotency processing unit, configured to perform idempotency processing on the asynchronous notification to ensure that the business logic of each asynchronous notification is executed only once;

[0032] The status update unit is used to parse validated, non-repeating asynchronous notifications and trigger updates to internal order status and user accounts.

[0033] Preferably, the data checking and adjustment module further includes:

[0034] Data collection unit, used to collect transaction data from third-party payment platforms and internal systems;

[0035] A transaction matching unit, used to match transaction records from different sources;

[0036] The discrepancy identification and classification unit is used to identify and classify accounting discrepancies such as missed settlements, duplicate settlements, and incorrect settlements;

[0037] Workflow adjustment unit, used to start automatic or manual difference processing process.

[0038] Compared with the prior art, the advantages of the present invention are:

[0039] Improve data accuracy and consistency: Through enhanced asynchronous notification processing and automated multi-dimensional data verification mechanisms, accounting errors caused by "missed settlements", "duplicate settlements", "wrong settlements" and other problems are significantly reduced, ensuring the synchronization and accuracy of data between merchant systems and third-party payment platforms.

[0040] Enhanced payment processing reliability: Idempotence ensures that user accounts are not mistakenly topped up or debited multiple times, even if the payment platform sends repeated notifications. Robust error handling and retry query mechanisms (such as proactive querying when no notification is received) further ensure final confirmation of payment status.

[0041] Improve reconciliation efficiency and automation: Automated data acquisition, matching, and discrepancy identification replace traditional, time-consuming and labor-intensive manual reconciliation, significantly improving operational efficiency, reducing operational risks, and enabling faster problem discovery and resolution.

[0042] Reduce operating costs and risks: By reducing manual intervention, lowering error rates, and providing a clearer view of transactions, it can help companies effectively control operating costs and financial risks. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 This is a system architecture diagram of the recharge information management system based on a third-party payment platform proposed in the present invention.

[0044] Figure 2 This is a flow chart of the method for managing recharge information based on a third-party payment platform proposed by the present invention. DETAILED DESCRIPTION

[0045] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0046] Example 1:

[0047] Refer to the following Figure 1 The overall architecture of the recharge information management system based on the third-party payment platform proposed by the invention is described in detail. The system mainly includes:

[0048] Recharge Request Receiving and Preprocessing Module: This module serves as the front-end for interaction between the system and the user or client application. When a user initiates a recharge operation, the request first arrives at this module. This module is specifically responsible for:

[0049] Receive recharge requests from the user interface or external system API calls. The request usually contains information such as user ID, desired recharge amount, and selected payment channel.

[0050] Perform validity checks on the received request parameters, such as checking whether the user exists, whether the amount is within the allowed range, and whether the payment channel is supported.

[0051] If the request is valid, a globally unique internal order identifier will be generated for the recharge.

[0052] Create an initial transaction record in the user account and transaction ledger management module, mark its status as "pending payment" or similar, and store request-related information.

[0053] Third-party payment gateway interface module: This module is the bridge for the system to communicate with various third-party payment platforms. This module is specifically responsible for:

[0054] Based on the payment channel selected in the recharge request and the configuration information of the corresponding payment platform (such as merchant ID, API key, request address, etc.), a payment request message that complies with the platform's API specifications is constructed.

[0055] Handle security mechanisms during communication with payment platforms, such as signing request data and using secure protocols such as HTTPS for data transmission.

[0056] Send the constructed payment request to the corresponding third-party payment platform and receive a possible synchronous response. The synchronous response is usually used to indicate whether the request was successfully received, or directly return the URL or form used to guide the user to pay.

[0057] Ensure that the callback URL for asynchronous notifications is correctly set in the request sent to the payment platform. The URL points to the specific entry point of the asynchronous notification processing module.

[0058] Asynchronous Notification Processing Module: This module handles payment result feedback from third-party payment platforms. It typically exists as a background service or API endpoint, waiting for callbacks from the payment platform. This module further includes a notification reception and signature verification unit, an idempotence processing unit, and a status update unit. Each unit is specifically responsible for:

[0059] Notification Receiving and Signature Verification Unit: This unit is responsible for monitoring and receiving asynchronous notifications sent by the payment platform to a pre-set callback URL via HTTP POST or other methods. Upon receiving the notification, it first verifies its legitimacy and authenticity. This primarily involves verifying the signature in the notification message, using the public key and signature algorithm (such as RSA) provided by the payment platform to verify that the data has not been tampered with during transmission and that it indeed originates from the payment platform.

[0060] Idempotent Processing Unit: Due to network issues or the payment platform's retry mechanism, the same payment success notification may be sent to the merchant system multiple times. To prevent duplicate accounting, this unit must ensure that the business processing for each notification is executed only once, thus achieving idempotence. This can be achieved by checking whether the unique notification ID provided by the payment platform in the notification has already been processed. Alternatively, a unique "transaction fingerprint" can be designed based on the internal order ID and payment status to determine whether the notification has been processed. If the notification is determined to be a duplicate, a successful receipt response is directly returned to the payment platform without executing subsequent business logic.

[0061] Status Update Unit: When a notification passes signature verification and idempotence checks confirm it's the first valid transaction, this unit parses the notification content and extracts key information, such as the payment platform's transaction serial number, actual payment amount, payment status (success / failure), and payment time. Based on this information, it updates the status of the corresponding internal order in the user account and transaction ledger management module (for example, from "pending payment" to "payment successful" or "payment failed").

[0062] In a preferred embodiment, this module also includes a response and exception queue management unit. After successfully processing the business logic, a standardized successful response must be sent back to the third-party payment platform. This informs the payment platform that the notification has been properly processed and no further retries are required. If an exception occurs during internal business logic processing, this unit should store the relevant information about the notification in an exception queue for subsequent error handling and manual intervention, rather than simply refusing to respond or responding incorrectly to the payment platform, which could lead the payment platform to mistakenly believe the notification was undelivered and continue to retry.

[0063] Data Verification and Adjustment Module: This module is used to ensure the long-term consistency of internal accounting data and third-party payment platform data, including data collection unit, transaction matching unit, difference identification and classification unit and work adjustment unit. Each unit is used to:

[0064] Data Collection Unit: Based on a predetermined schedule (e.g., daily at midnight), this unit retrieves all transaction records within a specified time period by calling the transaction query interface provided by the third-party payment platform or downloading reconciliation files. Simultaneously, it extracts internal order records from the user account and transaction ledger management modules for the same time period.

[0065] Transaction matching unit: matches the data obtained from both parties. The matching basis can be a combination of one or more fields such as the internal order ID, the transaction serial number returned by the payment platform, the transaction amount, and the transaction time.

[0066] Difference identification and classification unit: Analyzes the matching results and identifies inconsistent transactions. Specifically:

[0067] Missed settlement: An order that is recorded as successfully paid by the internal system cannot be found in the settlement data of the payment platform; or the payment platform has been settled but the internal system has not successfully recorded it or the status is incorrect.

[0068] Duplicate settlement: An order in the internal system corresponds to multiple successful settlement records in the settlement data of the payment platform.

[0069] Mismatch: The order is matched successfully, but key information (such as payment amount, handling fee, currency, payment status) is inconsistent.

[0070] Workflow Adjustment Unit: For identified differences, this unit initiates the corresponding processing flow.

[0071] For certain predictable discrepancies (for example, "there is an order internally but no external settlement" due to asynchronous notification delays or temporary loss), the system can be configured to automatically trigger an API status query for the order to obtain its latest status and attempt to automatically update it.

[0072] For complex discrepancies that cannot be resolved automatically, the system will generate a discrepancy report, mark these discrepancy records, and push them to finance or operations personnel through the work order system or management interface for manual investigation and processing.

[0073] User Account and Transaction Ledger Management Module: This module is the core data storage and management part of the system. This module is responsible for:

[0074] Maintain all user account information, especially account balances.

[0075] Record detailed information for each top-up transaction, including internal order ID, user ID, requested amount, actual payment amount, payment channel, payment platform serial number, transaction time, current status (such as pending payment, paying, successful, failed, refunded, discrepancy, etc.), as well as the history of all status changes and related adjustment information.

[0076] Ensure that updates to user balances and transaction status are atomic and consistent to prevent data corruption or inconsistency.

[0077] In a preferred embodiment, the system further includes an error handling and logging module for diary recording and problem tracking, which is specifically responsible for:

[0078] Comprehensively record all key operations, events, warnings, and error messages during system operation.

[0079] Categorize and handle common errors that occur during interaction with third-party payment platforms.

[0080] Simulate and test how the system handles connection failures and timeouts to ensure users receive clear and appropriate prompts.

[0081] When a serious error occurs (such as repeated inability to connect to the payment platform, significant amount discrepancies found during data verification, etc.), the alarm mechanism is triggered to promptly notify the operation and maintenance or management personnel.

[0082] Example 2:

[0083] Reference Figure 2The process of the recharge information management method based on the third-party payment platform proposed by the invention is described in detail in combination with a specific embodiment, including:

[0084] S1. Receiving a Recharge Request: A user initiates a recharge request through a client application (e.g., a website or mobile app). The recharge request receiving and preprocessing module receives this request. The request includes the user ID, recharge amount, and selected payment method. The module verifies the request and, if successful, generates a unique internal order ID. It then stores the initial order information (with the status set to "pending payment") in the user's account and the transaction ledger management module.

[0085] S2. Build and send a payment instruction to the third-party platform: The third-party payment gateway interface module constructs a payment request based on internal order information and the corresponding payment channel configuration. This request includes a callback URL pointing to the asynchronous notification processing module. The payment instruction is securely sent to the selected third-party payment platform.

[0086] S3. Processing the Synchronous Response: Some third-party payment platforms immediately return a synchronous response after receiving a payment instruction. This response may include a URL for redirecting to the payment page, form data to be submitted to the bank, or simply an acceptance status. The third-party payment gateway interface module processes this synchronous response and passes the necessary information to the user to complete the payment.

[0087] S4. Waiting for and receiving asynchronous notifications: After the user completes the payment operation on the third-party payment platform, the payment platform will send an asynchronous notification to the asynchronous notification processing module of this system through the previously specified callback URL to inform the payment result. Specifically, it includes:

[0088] Receive notifications and verify their legitimacy: The notification reception and signature verification unit listens for HTTP POST requests to the callback URL, retrieves the notification data from the request, and then performs signature verification on the received notification data to ensure that the notification comes from a legitimate payment platform and that the content has not been tampered with. If verification fails, an error is logged and a successful receipt status is not returned to the payment platform, prompting it to retry or trigger a security alert.

[0089] Idempotency Verification: After a notification passes legality verification, the idempotency processing unit checks the unique identifier in the notification, or the business key generated based on the order ID and current status, to determine whether the notification has already been processed. If it is a duplicate notification, a success status is directly returned to the payment platform, and the current notification processing flow is terminated to prevent duplicate accounting.

[0090] Parsing notification content: For the first valid notification received, the status update unit parses the parameters in the notification to obtain information such as the merchant order number, payment platform transaction serial number, transaction status, payment amount, payment time, etc. Based on the parsed payment status, the status of the corresponding internal order is updated in the user account and transaction ledger management module.

[0091] S5. Scheduled data verification process: To ensure eventual consistency and catch any issues that may be missed or processed incorrectly during asynchronous notification, the system regularly initiates the verification process of the data verification and adjustment module. This includes:

[0092] Pull data from both parties: The data collection unit downloads the transaction details or settlement files of the previous reconciliation cycle from all connected third-party payment platforms, and extracts the internal order records of the same cycle from the user account and transaction ledger management module.

[0093] Transaction matching: The transaction matching unit matches internal and external data according to preset rules (such as order number, amount, and time window).

[0094] Identify discrepancy types (missing orders, duplicate orders, wrong orders): Match the results of discrepancy identification and classification unit analysis to specifically look for "missing orders", "duplicate orders", "wrong orders", etc.

[0095] Generate a discrepancy report and initiate a resolution workflow: For identified discrepancies, the workflow adjustment unit generates a detailed discrepancy report. Some simple discrepancies can be automatically reconciled (e.g., by querying the latest status via an API), while complex discrepancies enter a manual process for investigation and resolution by relevant personnel.

[0096] In a preferred embodiment, it also includes:

[0097] Exception handling: In each step of the entire recharge information management method, the error handling and logging modules are continuously monitored.

[0098] If a network error or timeout occurs when communicating with the payment platform, or a specific error code is received from the payment platform (such as signature error, invalid parameters, merchant not activating the function, etc.), the error handling and logging module will record detailed error information.

[0099] For certain exceptions, the system may take pre-defined recovery measures. For example, if no asynchronous notification is received for a certain order for an extended period of time, and the order status is still "pending payment," the system may proactively call the transaction status query interface provided by the payment platform to obtain the final status of the order.

[0100] All exceptions and their handling are recorded to facilitate auditing and continuous improvement of the system.

[0101] By closely integrating the aforementioned system architecture and method steps, the present invention establishes a closed-loop recharge information management process. This solution not only ensures the correct processing of individual transactions, particularly the reliable receipt and idempotence of asynchronous notifications, but also detects and corrects cumulative or occasional errors through periodic, automated, and comprehensive data verification. This strategy, combining proactive management with post-verification, ensures the accuracy and consistency of recharge information in complex multi-party payment environments.

[0102] Throughout this specification, references to terms such as "one embodiment," "example," or "specific example" indicate that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of the present invention. In this specification, schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0103] The preferred embodiments of the present invention disclosed above are intended only to help illustrate the present invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the present invention to the specific embodiments described. Obviously, many modifications and variations are possible based on the content of this specification. These embodiments are selected and described in detail in this specification to better explain the principles and practical applications of the present invention, thereby enabling those skilled in the art to better understand and utilize the present invention. The present invention is limited only by the claims and their full scope and equivalents.

Claims

1. A recharge information management method based on a third-party payment platform, characterized in that: The following steps are involved: Receive a recharge request initiated by a user and generate a unique internal order identifier for the recharge request; Constructing a payment instruction based on the payment method and amount specified in the recharge request, and sending the payment instruction to the corresponding third-party payment platform, wherein the payment instruction includes an asynchronous notification callback address for receiving the payment result; receiving, at the asynchronous notification callback address, an asynchronous notification sent by the third-party payment platform, the notification including the payment result corresponding to the internal order identifier; Perform signature verification on the received asynchronous notification to confirm the authenticity of its source, and perform idempotence processing to prevent repeated business operations on the same payment result; If the asynchronous notification passes signature verification and is determined to be the first valid processing based on idempotence, the asynchronous notification is parsed to obtain the payment status, and the payment status of the internal order record associated with the internal order identifier and the corresponding user account information are updated according to the payment status; Periodically obtaining transaction data recorded by one or more third-party payment platforms and automatically verifying the obtained transaction data with the internal order records, wherein the verification is used to identify one or more types of account discrepancies, including at least one or more types of missed settlements, duplicate settlements, or incorrect settlements; Based on the account differences identified by the data verification, a preset adjustment process is executed to correct the differences or mark them for manual processing.

2. The recharge information management method based on the third-party payment platform according to claim 1 is characterized in that: The idempotent processing is performed to prevent repeated business operations on the same payment result, specifically including: Check whether the unique notification identifier contained in the asynchronous notification has been processed; Alternatively, a processing fingerprint is generated based on the internal order identifier and the currently known payment status, and the processing fingerprint is checked to see whether it indicates that the payment result has been processed.

3. The recharge information management method based on a third-party payment platform according to claim 1, characterized in that: The omissions identified during the data verification process include: the internal order record shows that the payment is successful, but no corresponding successful settlement record is found in the transaction data of the third-party payment platform; or the transaction data of the third-party payment platform shows that the settlement has been successful, but no corresponding successful order is found in the internal order record or the order status is incorrect.

4. The recharge information management method based on a third-party payment platform according to claim 1, characterized in that: The duplicate settlements identified during the data verification process include: one internal order identifier corresponding to multiple successful settlement records in the transaction data of the third-party payment platform.

5. The recharge information management method based on a third-party payment platform according to claim 1, characterized in that: The discrepancies identified during the data verification process include: inconsistencies in the actual payment amount, handling fee or payment status of transactions that are successfully matched between the internal order records and the transaction data of the third-party payment platform.

6. The recharge information management method based on a third-party payment platform according to claim 1, characterized in that: After receiving the asynchronous notification and before the automated data verification, if no asynchronous notification for a certain internal order identifier is received within a preset time, the payment status of the order is actively queried from the third-party payment platform through the query interface.

7. The recharge information management method based on a third-party payment platform according to claim 1, characterized in that: After the asynchronous notification passes the signature verification and is determined to be the first valid processing based on the idempotence processing, a confirmation response indicating that the notification is successfully received and processed is sent back to the third-party payment platform.

8. A recharge information management system based on a third-party payment platform, characterized in that: include: A recharge request receiving and pre-processing module configured to receive a recharge request initiated by a user and generate a unique internal order identifier for the recharge request; A third-party payment gateway interface module is configured to construct a payment instruction based on the recharge request and send the payment instruction to the corresponding third-party payment platform, wherein the payment instruction includes an asynchronous notification callback address for receiving the payment result; an asynchronous notification processing module configured to receive, at the asynchronous notification callback address, an asynchronous notification sent by the third-party payment platform and containing a payment result corresponding to the internal order identifier, perform signature verification and idempotence processing on the received asynchronous notification, and parse the asynchronous notification to obtain a payment status after verification and processing pass; a user account and transaction ledger management module configured to store internal order records and user account information, and update the payment status of the internal order record associated with the internal order identifier and the corresponding user account information according to the payment status parsed by the asynchronous notification processing module; A data verification and reconciliation module is configured to periodically obtain transaction data recorded by one or more third-party payment platforms, perform automated data verification on the obtained transaction data and the internal order records stored in the user account and transaction ledger management module, so as to identify one or more types of account discrepancies including at least missed settlements, duplicate settlements or incorrect settlements, and execute a preset reconciliation process based on the identified account discrepancies.

9. The recharge information management system based on the third-party payment platform according to claim 8, characterized in that: The asynchronous notification processing module further includes: Notification receiving and signature verification unit, used to receive asynchronous notifications and perform signature verification; an idempotency processing unit, configured to perform idempotency processing on the asynchronous notification to ensure that the business logic of each asynchronous notification is executed only once; The status update unit is used to parse validated, non-repeating asynchronous notifications and trigger updates to internal order status and user accounts.

10. The recharge information management system based on a third-party payment platform according to claim 8, characterized in that: The data checking and adjustment module further includes: Data collection unit, used to collect transaction data from third-party payment platforms and internal systems; A transaction matching unit, used to match transaction records from different sources; The discrepancy identification and classification unit is used to identify and classify accounting discrepancies such as missed settlements, duplicate settlements, and incorrect settlements; Workflow adjustment unit, used to start automatic or manual difference processing process.

Images