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

Abstract

The application relates to the technical field of electronic payment, in particular to a recharge information management method and system based on a third-party payment platform. The method comprises the following steps: receiving a recharge request and generating a unique internal order identifier; interacting with a payment platform to initiate payment and specifying an asynchronous notification address; receiving an asynchronous notification containing a payment result sent by the payment platform; verifying and processing the asynchronous notification for idempotency to confirm the validity and uniqueness of the notification; updating the payment state of the internal order and the corresponding user account information based on the asynchronous notification; periodically obtaining transaction data of the third-party payment platform and automatically checking the data with the internal order record to identify and process account differences and execute a preset adjustment process. The application can significantly improve the accuracy and consistency of recharge information management, reliably process asynchronous notifications, realize efficient automatic data checking, effectively reduce various account errors, and thus improve user experience and overall operation efficiency.

Description

Technical Field

[0001] This invention relates to the field of electronic payment technology, specifically to a method and system for managing recharge information based on a third-party payment platform. Background Technology

[0002] With the rapid development and widespread application of internet technology, third-party payment platforms have become indispensable payment tools in various scenarios such as e-commerce, online services, and even university tuition fees. Users can greatly improve the convenience of transactions by using these platforms for top-ups and payments. However, merchants or service providers face a series of technical challenges when accessing and managing these third-party payment platforms, especially in the management of top-up information.

[0003] Currently, a significant issue when integrating with third-party payment platforms is data inconsistency. Discrepancies frequently arise between the recharge information recorded in merchants' own business systems and the settlement data provided by third-party payment platforms. These discrepancies can manifest as "missed settlement" (i.e., the merchant's system shows a successful transaction but the payment platform has not settled it, or vice versa), "duplicate settlement" (i.e., the same transaction is settled multiple times), and "incorrect settlement" (i.e., the settlement amount or status does not match the actual amount). Such data inconsistencies not only lead to direct economic losses but also increase the complexity of financial reconciliation, requiring significant manpower for verification and adjustments. Furthermore, untimely or incorrect account balance updates can severely impact user experience.

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

[0005] Furthermore, the existing system has shortcomings in real-time monitoring, anomaly alerts, and automated handling 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 the smoothness, accuracy, and security of their recharge transactions when facing complex third-party payment environments. Summary of the Invention

[0006] To address the aforementioned issues of data inconsistency, unreliable asynchronous notification processing, lack of unified management, and real-time performance, this invention proposes a recharge information management method and system based on a third-party payment platform.

[0007] Methods for managing recharge information based on third-party payment platforms include:

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

[0009] Based on the payment method and amount specified in the recharge request, a payment instruction is constructed and sent to the corresponding third-party payment platform. The payment instruction includes an asynchronous notification callback address for receiving the payment result.

[0010] The asynchronous notification callback address receives an asynchronous notification from the third-party payment platform containing the payment result corresponding to the internal order identifier;

[0011] The received asynchronous notification is signed to verify its authenticity and is idempotent to prevent duplicate business operations on the same payment result.

[0012] If the asynchronous notification passes signature verification and is determined to be a valid first-time processing based on idempotency processing, then 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 based on the payment status.

[0013] The system periodically retrieves transaction data recorded by one or more of the aforementioned third-party payment platforms and performs automated data reconciliation with the internal order records. The data reconciliation is used to identify one or more types of accounting discrepancies, including at least omissions, duplicates, or errors.

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

[0015] Preferably, the idempotency processing to prevent duplicate business operations on the same payment result specifically includes:

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

[0017] Alternatively, a processing fingerprint can be generated based on the internal order identifier and the currently known payment status, and the processing fingerprint can be checked to see if 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 was successful, but no corresponding successful settlement record was 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 was successful, but no corresponding successful order was found in the internal order record or the order status is incorrect.

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

[0020] Preferably, the errors identified during the data verification process include: discrepancies in the actual payment amount, handling fee, or payment status between the internal order records and the 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 system will proactively query the third-party payment platform for the payment status of the order through the query interface.

[0022] Preferably, after the asynchronous notification passes signature verification and is determined to be a valid first-time processing based on idempotency processing, a confirmation response indicating successful receipt and processing of the notification is sent back to the third-party payment platform.

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

[0024] The recharge request receiving and preprocessing module is configured to receive recharge requests initiated by users and generate a unique internal order identifier for the recharge request;

[0025] The 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. The payment instruction includes an asynchronous notification callback address for receiving the payment result.

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

[0027] The user account and transaction ledger management module is 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] The data verification and adjustment module is configured to periodically obtain transaction data recorded by one or more of the third-party payment platforms, automatically verify the obtained transaction data with the internal order records stored in the user account and transaction ledger management module, identify one or more types of accounting discrepancies including at least omissions, duplicates, or errors, and execute a preset adjustment process based on the identified accounting discrepancies.

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

[0030] The notification receiving and signature verification unit is used to receive asynchronous notifications and perform signature verification.

[0031] An idempotency processing unit is used to perform idempotency processing on the asynchronous notifications to ensure that the business logic of each asynchronous notification is executed only once.

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

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

[0034] The data collection unit is used to collect transaction data from third-party payment platforms and internal systems.

[0035] The transaction matching unit is used to match transaction records from different sources;

[0036] The difference identification and classification unit is used to identify and classify accounting differences such as omissions, duplicates, and errors.

[0037] The workflow adjustment unit is used to initiate automatic or manual difference processing procedures.

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

[0039] Improve data accuracy and consistency: By strengthening asynchronous notification processing and automated multi-dimensional data verification mechanisms, accounting errors caused by issues such as "missed settlements," "duplicate settlements," and "incorrect settlements" are significantly reduced, ensuring the synchronization and accuracy of data between the merchant system and the third-party payment platform.

[0040] Enhanced payment processing reliability: Idempotent processing ensures that user accounts are not mistakenly topped up or deducted multiple times, even if the payment platform repeatedly sends notifications. Robust error handling and retry query mechanisms (such as proactively querying when no notification is received) further guarantee 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, greatly improving operational efficiency, reducing operational risks, and enabling faster discovery and resolution of problems.

[0042] Reduce operating costs and risks: By reducing human intervention, lowering error rates, and providing a clearer view of transactions, businesses can effectively control operating costs and financial risks. Attached Figure Description

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

[0044] Figure 2 This is a flowchart of the recharge information management method based on a third-party payment platform proposed in this invention. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of this invention clearer, the 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 merely illustrative and not intended to limit the invention.

[0046] Example 1:

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

[0048] Recharge Request Receiving and Preprocessing Module: This module acts 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 reaches this module. Specifically, this module is responsible for:

[0049] Receive recharge requests from user interface or external system API calls. The requests typically include information such as user ID, expected recharge amount, and selected payment channel.

[0050] Perform validity checks on the received request parameters, such as checking if the user exists, if the amount is within the allowed range, and if 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 a similar status, and store the request-related information.

[0053] Third-party payment gateway interface module: This module serves as the bridge for actual communication between the system and various third-party payment platforms. Specifically, this module is responsible for:

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

[0055] Security mechanisms are implemented during communication with payment platforms, such as signing request data and using secure protocols like HTTPS for data transmission.

[0056] The completed payment request is sent to the relevant third-party payment platform, and a synchronous response is received, which may be returned. The synchronous response typically indicates whether the request was successfully received, or directly returns a URL or form to guide the user to make the payment.

[0057] Ensure that the callback URL for the asynchronous notification is correctly set in the request sent to the payment platform, and that 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, typically in the form of a backend service or API endpoint, awaiting a callback from the payment platform. This module further includes a notification receiving and signature verification unit, an idempotency processing unit, and a status update unit. Each unit is specifically used for:

[0059] Notification Receiving and Signature Verification Unit: This unit is responsible for listening to and receiving asynchronous notifications sent by the payment platform to a preset callback URL via methods such as HTTP POST. Upon receiving a 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 whether the data has been tampered with during transmission and whether it truly originates from the payment platform.

[0060] Idempotency Processing Unit: Due to network issues or the payment platform's retry mechanism, a successful payment notification may be sent to the merchant's system multiple times. To prevent duplicate accounting, this unit must ensure that the business processing for each notification is executed only once, i.e., achieve idempotency. 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 by combining the internal order ID and payment status for this determination. If a duplicate notification is detected, a successful receipt response is directly returned to the payment platform, and subsequent business logic is not executed.

[0061] Status Update Unit: When a notification passes signature verification and is confirmed as a valid first-time processing result by an idempotency check, this unit is responsible for parsing the notification content and extracting 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, the status of the corresponding internal order in the user account and transaction ledger management module is updated (e.g., from "Pending Payment" to "Payment Successful" or "Payment Failed").

[0062] In a preferred embodiment, the module may further include a response and exception queue management unit: after successfully processing the business logic, it must send a successful response conforming to its specifications back to the third-party payment platform. This informs the payment platform that the notification has been properly processed and does not require retrying. If an exception occurs during internal business logic processing, this unit should store the relevant information of the notification in an exception queue for subsequent error handling and manual intervention, rather than simply not responding or responding with an error to the payment platform, as this might cause the payment platform to mistakenly believe that the notification has not been delivered and continue to retry.

[0063] Data Verification and Adjustment Module: This module ensures long-term consistency between internal accounting data and third-party payment platform data. It includes a data collection unit, a transaction matching unit, a discrepancy identification and classification unit, and a work adjustment unit. Each unit is specifically used for:

[0064] Data Collection Unit: Following a pre-defined 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 a third-party payment platform or downloading reconciliation files. Simultaneously, it extracts internal order records for the same time period from the user account and transaction ledger management modules.

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

[0066] The discrepancy identification and classification unit analyzes the matching results to identify inconsistent transactions. Specifically:

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

[0068] Duplicate settlement: A single order in the internal system corresponds to multiple successful settlement records in the payment platform's settlement data.

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

[0070] Workflow Adjustment Unit: This unit initiates the corresponding processing flow for the identified differences.

[0071] For certain predictable discrepancies (e.g., "orders exist internally, but settlement is temporarily unavailable externally" 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 update it automatically.

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

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

[0074] Maintain all users' account information, especially account balances.

[0075] Record detailed information for each recharge 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, in progress, successful, failed, refunded, discrepancy, etc.), as well as a 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 inconsistencies.

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

[0078] It comprehensively records all critical operations, events, warnings, and error messages during system operation.

[0079] Common errors that occur during interactions with third-party payment platforms are categorized and addressed.

[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 being unable to connect to the payment platform multiple times in a row, or discovering significant discrepancies in data verification), an alarm mechanism is triggered to promptly notify the operations or maintenance personnel.

[0082] Example 2:

[0083] Reference Figure 2The present invention provides a detailed description of the process of the recharge information management method based on a third-party payment platform, using a specific embodiment as an example, including:

[0084] S1. Receiving a Recharge Request: The user initiates a recharge request through a client application (such as a webpage or mobile app). The recharge request receiving and preprocessing module receives this request. The request includes the user identifier, recharge amount, and selected payment method. The recharge request receiving and preprocessing module verifies the request, and upon successful verification, generates a unique internal order ID and stores the initial order information (status set to "Pending Payment") in the user account and transaction ledger management module.

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

[0086] S3. Handling Synchronous Responses: Some third-party payment platforms will immediately return a synchronous response after receiving a payment instruction. This response may contain a URL to redirect 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 guide 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 them of the payment result. Specifically, this includes:

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

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

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

[0091] S5. Scheduled Data Verification Process: To ensure eventual consistency and capture any issues that may be missed or mishandled during asynchronous notification, the system schedules a verification process initiated by the data verification and adjustment module. This includes:

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

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

[0094] Identify discrepancy types (missing orders, duplicate orders, incorrect orders): The discrepancy identification and classification unit analysis matching results are specifically used to find out if there are "missing orders", "duplicate orders", "incorrect orders" and other similar situations.

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

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

[0097] Error handling: The error handling and logging module continuously monitors each step of the entire recharge information management process.

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

[0099] For certain specific anomalies, the system may take preset recovery measures. For example, if no asynchronous notification for an order is received for an extended period and the order status remains "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 anomalies and their handling processes are logged for auditing and continuous system improvement.

[0101] Through the close coordination of the aforementioned system architecture and methodological steps, this invention establishes a closed-loop recharge information management process. This solution not only focuses on the correct processing of individual transactions, particularly the reliable reception and idempotency guarantee of asynchronous notifications, but also identifies and corrects accumulated or occasional errors through periodic, automated, and comprehensive data verification. This strategy, combining proactive management and post-event verification, ensures the accuracy and consistency of recharge information in complex multi-party payment environments.

[0102] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above 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 one or more embodiments or examples.

[0103] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A method for managing recharge information based on a third-party payment platform, characterized in that, The method comprises the following steps: receiving a user-initiated recharge request and generating 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, the payment instruction containing an asynchronous notification callback address for receiving payment results; receiving an asynchronous notification containing a payment result corresponding to the internal order identifier sent by the third-party payment platform at the asynchronous notification callback address; performing signature verification on the received asynchronous notification to confirm its authenticity and performing idempotency processing to prevent repeated business operations on the same payment result; if the asynchronous notification passes the signature verification and is judged to be the first valid processing according to the idempotency processing, parsing the asynchronous notification to obtain the payment status, and updating 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; periodically obtaining transaction data recorded by one or more third-party payment platforms, and automatically checking the obtained transaction data with the internal order record, the data checking being used to identify one or more types of accounting differences including missing, repeated or incorrect settlement; wherein the missing settlement includes: the internal order record shows payment success, 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 successfully settled, but no corresponding successful order or incorrect order status is found in the internal order record; the repeated settlement includes: one internal order identifier corresponds to multiple successful settlement records in the transaction data of the third-party payment platform; the incorrect settlement includes: the internal order record and the transaction data of the third-party payment platform are inconsistent in actual payment amount, commission or payment status in a successfully matched transaction; based on the accounting differences identified by the data checking, performing a preset adjustment process to correct the differences or mark them for manual processing. 2.The third-party payment platform based recharge information management method according to claim 1, characterized in that, The idempotency processing to prevent repeated business operations on the same payment result specifically includes: checking whether the unique notification identifier contained in the asynchronous notification has been processed; or generating a processing fingerprint based on the internal order identifier and the current known payment status, and checking whether the processing fingerprint indicates that the payment result has been processed. 3.The third-party payment platform based recharge information management method of claim 1, wherein, After receiving the asynchronous notification and before the automated data checking, if no asynchronous notification is received for a certain internal order identifier within a preset time, actively query the payment status of the order from the third-party payment platform through an inquiry interface. 4.The third-party payment platform based recharge information management method of claim 1, wherein, After the asynchronous notification passes the signature verification and is judged to be the first valid processing according to the idempotency processing, a confirmation response indicating that the notification has been successfully received and processed is sent back to the third-party payment platform.

5. A recharge information management system based on a third party payment platform, characterized by, The method comprises the following steps: receiving a user-initiated recharge request and generating a unique internal order identifier for the recharge request; The third-party payment gateway interface module is configured to construct a payment instruction based on the recharge request and send the payment instruction to a corresponding third-party payment platform, and the payment instruction contains an asynchronous notification callback address for receiving a payment result; The asynchronous notification processing module is configured to receive an asynchronous notification containing a payment result corresponding to the internal order identifier sent by the third-party payment platform at the asynchronous notification callback address, perform signature verification and idempotency processing on the received asynchronous notification, and parse the asynchronous notification to obtain a payment state after the verification and processing pass; The user account and transaction ledger management module is configured to store internal order records and user account information, and update the payment state of the internal order record associated with the internal order identifier and the corresponding user account information according to the payment state parsed by the asynchronous notification processing module; The data reconciliation and adjustment module is configured to periodically obtain transaction data recorded by one or more third-party payment platforms, automatically reconcile the obtained transaction data with the internal order records stored in the user account and transaction ledger management module, identify one or more types of accounting differences including missing settlement, repeated settlement, or incorrect settlement, and perform a preset adjustment process based on the identified accounting differences; The missing settlement includes that the internal order record shows payment success, 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 successfully settled, but no corresponding successful order or incorrect order state is found in the internal order record; the repeated settlement includes that one internal order identifier corresponds to multiple successful settlement records in the transaction data of the third-party payment platform; and the incorrect settlement includes that the internal order record and the transaction data of the third-party payment platform are inconsistent in the actual payment amount, commission, or payment state in a successfully matched transaction.

6. The third party payment platform based recharge information management system of claim 5, wherein, The asynchronous notification processing module further includes: A notification receiving and signature verification unit for receiving asynchronous notifications and performing signature verification; An idempotency processing unit for performing idempotency processing on the asynchronous notifications to ensure that the business logic of each asynchronous notification is executed only once; A state updating unit for parsing the verified and non-repeated asynchronous notifications and triggering updates to the internal order state and the user account.

7. The third party payment platform based recharge information management system of claim 5, wherein, The data reconciliation and adjustment module further includes: A data collection unit for collecting transaction data from third-party payment platforms and internal systems; A transaction matching unit for matching transaction records from different sources; A difference identification and classification unit for identifying and classifying accounting differences such as missing settlement, repeated settlement, and incorrect settlement; A workflow adjustment unit for starting automatic or manual difference processing processes.

Images