A distributed system, device and storage medium for payment status monitoring and exception handling

Abstract

The application discloses a distributed system, equipment and storage medium for payment state monitoring and abnormal processing, which comprises a distributed data acquisition module, a state analysis engine, an abnormal processing executor, a cooperative control node and the like. The payment order state data can be acquired in real time from multiple business nodes, the abnormality can be analyzed and identified based on preset rules and models, the corresponding processing flow is triggered, the interaction and scheduling among the modules can be coordinated, the multiple agencies can be processed in parallel, the model is optimized in combination with an intelligent learning module, the payment state full life cycle monitoring and efficient abnormal processing are realized, and the consistency and real-time performance under the distributed environment are ensured.

Description

Technical Field

[0001] This invention belongs to the field of information technology, and more specifically, relates to a distributed system, device and storage medium for payment status monitoring and anomaly handling. Background Technology

[0002] With the rapid development of internet technology and the deep integration of the financial industry, internet finance and online payment services have experienced explosive growth. Payment scenarios have become increasingly complex and diverse, covering multiple areas such as e-commerce shopping, utility bill payments, and financial lending, and involving collaboration between numerous institutions and systems. Simultaneously, the volume of payment orders has grown exponentially, placing unprecedented demands on payment status monitoring and anomaly handling. However, traditional payment systems mostly employ a centralized architecture, exhibiting significant limitations when facing massive data processing and high-concurrency scenarios, frequently experiencing problems such as data synchronization delays and low processing efficiency. The lack of unified data formats across different business nodes makes payment status monitoring extremely difficult, with anomaly detection relying primarily on manually set rules, making accuracy and real-time performance uncertain and prone to missed detections or misjudgments. Anomaly handling processes are cumbersome and lengthy, lacking automated mechanisms. Coordination is difficult in cross-institutional business processing, data consistency is hard to guarantee, and system scalability is poor, making it difficult to keep pace with rapid business growth and continuous innovation, severely impacting the stability of payment services and user experience. Therefore, the development of a new distributed system is urgently needed. Summary of the Invention

[0003] In response to the rapid development of existing internet finance and online payment businesses, the complexity of payment scenarios, and the surge in order volume, traditional centralized payment systems suffer from problems such as insufficient data processing capabilities, difficulties in status monitoring, inefficient anomaly detection and handling, poor cross-institutional collaboration, and weak scalability. These issues make it difficult to meet business needs and ensure the stability of payment services and user experience.

[0004] To address the aforementioned technical issues, this invention provides a distributed system for payment status monitoring and anomaly handling, comprising: a distributed data acquisition module, which acquires payment order status data from several business nodes in real time and stores it in a distributed database; it connects to business nodes with different architectures using an adaptive protocol converter; it collects discrete status logs and continuous time-series indicators of payment orders in real time and outputs order indicator status data; a status analysis engine module, which analyzes the order indicator status data based on preset status transition rules and anomaly judgment models to identify abnormal status types and outputs abnormal status data of order indicators; a processing path prediction module, which constructs a knowledge graph using historical handling cases based on the abnormal status data of order indicators, and generates an optimal handling path sequence with weighted scores through a graph neural network, combined with the contextual features of the current abnormal status data of order indicators; an anomaly handling execution module, which determines the abnormal status type of the order indicator data based on the optimal handling path sequence and triggers the corresponding processing flow for the abnormal status data of order indicators; and a collaborative control node module, which coordinates data interaction and task scheduling between modules.

[0005] Specifically, the distributed data acquisition module connects to multiple architecture business nodes through an adaptive protocol conversion interface, collecting discrete state logs and continuous time-series indicators. It then uses a spatiotemporal correlation algorithm to construct a payment status graph, which is stored in a distributed database. The state analysis engine module integrates a finite state machine rule layer and a reinforcement learning elastic rule layer to perform anomaly detection on the state graph data, outputting state data with anomaly type identifiers. The processing path prediction module, based on a historical case knowledge graph, uses a graph neural network to parse anomaly context features and generate a weighted processing path sequence. The anomaly handling execution module calls pre-set atomic operation components to perform operations such as account freezing and channel switching according to the path sequence. The collaborative control node module uses an improved Saga mechanism to coordinate transactions between modules, records state changes through event tracing, and dynamically calibrates protocol conversion parameters and rule thresholds based on feedback data, forming a closed-loop control process. The system establishes a bidirectional data feedback channel between the state graph and the knowledge graph, supporting real-time correction of monitoring benchmarks by processing results.

[0006] Furthermore, the processing path prediction module uses a historical case library as its basic data source. Through a knowledge extraction engine, it transforms the anomaly features, execution actions, environmental parameters, and handling results of the cases into graph-structured data, constructing a multi-dimensional, interconnected knowledge graph storage system. This knowledge graph uses anomaly type as the main node, context factors such as payment channel type, system load range, and time period characteristics as attribute nodes, and historical handling actions as edge entities. Edge weights are dynamically calculated based on indicators such as historical execution success rate, latency cost, and resource consumption. When the state analysis engine module outputs anomaly state data, it activates the real-time inference engine: first, it generates the context feature vector of the current anomaly, which includes 27 dimensions of features such as the number of concurrent transactions at the time of anomaly triggering, the status of upstream and downstream dependent services, and infrastructure monitoring indicators. The input feature encoder performs normalization processing. Then, the graph neural network model is activated to traverse the knowledge graph. A multi-head graph attention mechanism (GAT) is used to calculate the similarity probability distribution between the current feature and historical case nodes. During the path generation stage, a multi-objective optimization function under resource constraints is introduced to comprehensively evaluate parameters such as the expected execution latency, success rate fluctuation threshold, and transaction lock conflict probability of each operation node in the disposal path. The output is a weighted and scored optimal disposal path sequence. This sequence is stored using an operation chain encoding structure, containing atomic operation instruction codes, sequential dependency markers, timeout rollback contingency plan pointers, and execution priority coefficients. Key path nodes have pre-set real-time computed alternative operation branches to ensure dynamic switching of backup plans based on the current environment state when the main path execution is blocked. After sequence generation, the knowledge graph's self-correction mechanism is triggered synchronously, temporarily storing new abnormal feature vectors as candidate nodes in the incremental buffer. After the disposal results are fed back, the graph's topology optimization and edge weight calibration are completed.

[0007] In one embodiment, the distributed data acquisition module further includes a multi-source data access unit, a data cleaning unit, and a distributed storage unit. The multi-source data access unit collects payment-related data in real time from multiple business systems such as the application management system, order management system, loan management system, and refund management system. The data cleaning unit performs format standardization and outlier filtering on the collected data. The distributed storage unit uses a sharding storage strategy to store the cleaned data in a distributed database to support efficient storage and retrieval of massive amounts of payment status data.

[0008] In one embodiment, the state analysis engine module includes a state transition tracking module, an anomaly rule engine, and a risk assessment model. The state transition tracking module monitors the transition process of payment orders in real time between states such as pending review, disbursement, repayment, and refund. The anomaly rule engine detects anomalies in state transitions, unprocessed timeouts, and data inconsistencies based on a preset set of rules. The risk assessment model combines historical anomaly data with real-time transaction characteristics to assess the anomaly risk level, providing a basis for decision-making in anomaly handling.

[0009] In one embodiment, the exception handling execution module includes an exception classification processing unit, a process automation engine, and a manual intervention interface. The exception classification processing unit classifies exceptions into categories such as loan disbursement failure, overdue repayment, refund exception, and institutional buyback based on the exception type. The process automation engine automatically triggers corresponding processing procedures for different categories of exceptions, such as a re-review process for loan disbursement failure, a collection and buyback process for overdue repayment, and a manual review process for refund exceptions. The manual intervention interface provides a manual review and processing channel for high-risk exceptions, realizing a combination of automated processing and manual decision-making.

[0010] In one embodiment, the collaborative control node module includes a distributed transaction coordinator, a task scheduling engine, and a monitoring and alarm module. The distributed transaction coordinator uses a two-phase commit protocol to ensure the consistency of cross-node data interaction. The task scheduling engine dynamically allocates monitoring and processing tasks according to the load of each node. The monitoring and alarm module monitors the operating status of each module in real time. When system anomalies such as node failure or data synchronization delay are detected, a multi-level alarm mechanism is triggered to ensure the stable operation of the distributed system.

[0011] In one embodiment, the system further includes a payment status visualization module. This module generates a real-time status monitoring dashboard based on status data in a distributed database, which graphically displays the overall status distribution, abnormal trends, and processing progress of payment orders. It also provides multi-dimensional query functions, supporting the filtering and analysis of payment status data by institution, order type, abnormal category, and other dimensions, providing data support for operational decisions.

[0012] In one embodiment, the distributed database adopts an architecture that combines master-slave replication and sharded storage. The master node is responsible for data writing and real-time synchronization, while the slave nodes bear the query load. The sharded storage distributes the data to different nodes according to dimensions such as order type and institution identifier to improve the processing efficiency of large-scale payment status data, while ensuring data security through data backup and recovery mechanisms.

[0013] In one embodiment, when the exception handling executor handles overdue repayment exceptions, it automatically triggers the institution repurchase process, including extracting the repurchase principal from the overdue order, calculating the repurchase penalty, generating the repurchase order and pushing it to the institution, and updating the order status and financial flow in the distributed database at the same time, realizing full automation of the overdue repayment exception from detection to handling.

[0014] In one embodiment, the system supports parallel processing by multiple institutions in a distributed environment. Each institution node independently handles its own payment status monitoring and anomaly handling tasks. Through collaborative control nodes, cross-institutional data synchronization and conflict coordination are carried out to ensure the isolation and data consistency of payment business between different institutions, thus meeting the distributed payment management needs in multi-institutional scenarios.

[0015] In one embodiment, the system further includes an intelligent learning module, which trains on historical anomaly data based on machine learning algorithms, continuously optimizes anomaly judgment rules and risk assessment models, improves the accuracy of anomaly detection and the adaptability of processing strategies, and enables the system to continuously improve the intelligence level of payment status monitoring and anomaly handling during long-term operation.

[0016] Secondly, the present invention also provides a distributed device for payment status monitoring and anomaly handling, comprising: one or more processors; and a memory storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement any of the aforementioned distributed systems for payment status monitoring and anomaly handling.

[0017] Thirdly, the present invention provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform any of the aforementioned distributed systems for payment status monitoring and anomaly handling.

[0018] Beneficial effects

[0019] This system provides a distributed system, device, and storage medium for payment status monitoring and anomaly handling. Employing a distributed architecture, it breaks through the data processing bottlenecks of traditional centralized systems, easily handling the ever-increasing volume of payment data. It also supports multiple institutions processing business simultaneously in parallel, significantly improving overall processing efficiency and system scalability, providing strong support for continuous business development. The distributed data acquisition module, with its powerful multi-source real-time data access capabilities, cleans and stores data from different business nodes and in different formats, ensuring data accuracy and integrity, and laying a reliable foundation for subsequent status analysis and processing.

[0020] The status analysis engine integrates preset rules and intelligent models to accurately capture various payment status anomalies. The risk assessment model further categorizes anomalies, significantly improving detection accuracy. The anomaly handling executor organically combines automated processes with manual intervention, rapidly responding to different types of anomalies and initiating corresponding processing procedures, ensuring timeliness and accuracy. The collaborative control node, through an advanced distributed transaction coordination mechanism, ensures data consistency and operational stability in a distributed environment. Combined with monitoring and alarm mechanisms, it effectively reduces the impact of system failures. The intelligent learning module continuously learns and optimizes from historical data, constantly improving the system's intelligence and adaptability to complex business scenarios. The visualization module provides powerful data support for business decisions through intuitive data presentation, comprehensively improving the quality and efficiency of payment business management and significantly reducing operational risks and costs. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0022] Figure 1 A schematic diagram of a distributed system module for payment status monitoring and anomaly handling is provided for embodiments of the present invention;

[0023] Figure 2 This is a schematic diagram of the distributed device structure for payment status monitoring and anomaly handling provided in an embodiment of the present invention;

[0024] Figure 3 The flowchart illustrates the payment status monitoring and anomaly handling system provided in this embodiment of the invention. Detailed Implementation

[0025] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0026] It should be noted that if the embodiments of the present invention involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of the components in a specific posture. If the specific posture changes, the directional indicators will also change accordingly.

[0027] Furthermore, if the embodiments of this invention involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Thus, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the use of "and / or" or "and / or" throughout the text implies three parallel solutions. For example, "A and / or B" includes solution A, solution B, or a solution where both A and B are satisfied. Furthermore, the technical solutions of the various embodiments can be combined, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by this invention.

[0028] This embodiment addresses the problems of insufficient data processing capabilities, difficulties in status monitoring, inefficient anomaly detection and handling, poor cross-institutional collaboration, and weak scalability in traditional centralized payment systems, which suffer from the rapid development of existing internet finance and online payment businesses, complex payment scenarios, and a surge in order volume. It aims to solve the problem of failing to meet business needs and ensure the stability of payment services and user experience.

[0029] refer to Figure 1 , Figure 3 This invention provides a distributed system for payment status monitoring and anomaly handling, comprising: a distributed data acquisition module, which acquires payment order status data from several business nodes in real time and stores it in a distributed database; it connects to business nodes with different architectures using an adaptive protocol converter; it collects discrete status logs and continuous time-series indicators of payment orders in real time and outputs order indicator status data; a status analysis engine module, which analyzes the order indicator status data based on preset status transition rules and anomaly judgment models to identify abnormal status types and outputs abnormal status data of order indicators; a processing path prediction module, which constructs a knowledge graph using historical handling cases based on the abnormal status data of order indicators, and generates an optimal handling path sequence with weighted scores through a graph neural network, combined with the contextual features of the current abnormal status data of order indicators; an anomaly handling execution module, which determines the abnormal status type of the order indicator data based on the optimal handling path sequence and triggers the corresponding processing flow for the abnormal status data of order indicators; and a collaborative control node module, which coordinates data interaction and task scheduling between modules.

[0030] Furthermore, the distributed data acquisition module connects to multiple architecture business nodes through an adaptive protocol conversion interface, collecting discrete state logs and continuous time-series indicators. It then uses a spatiotemporal correlation algorithm to construct a payment state graph, which is stored in a distributed database. The state analysis engine module integrates a finite state machine rule layer and a reinforcement learning elastic rule layer to perform anomaly detection on the state graph data, outputting state data with anomaly type identifiers. The processing path prediction module, based on a historical case knowledge graph, uses a graph neural network to parse anomaly context features and generate a weighted processing path sequence. The anomaly handling execution module calls pre-set atomic operation components to perform operations such as account freezing and channel switching according to the path sequence. The collaborative control node module uses an improved Saga mechanism to coordinate transactions between modules, records state changes through event tracing, and dynamically calibrates protocol conversion parameters and rule thresholds based on feedback data, forming a closed-loop control process. The system establishes a bidirectional data feedback channel between the state graph and the knowledge graph, supporting real-time correction of monitoring benchmarks by processing results.

[0031] In this embodiment, the distributed data acquisition module further includes a multi-source data access unit, a data cleaning unit, and a distributed storage unit. The multi-source data access unit collects payment-related data in real time from multiple business systems such as the application management system, order management system, loan management system, and refund management system. The data cleaning unit performs format standardization and outlier filtering on the collected data. The distributed storage unit uses a sharding storage strategy to store the cleaned data in a distributed database to support efficient storage and retrieval of massive amounts of payment status data.

[0032] In this embodiment, the state analysis engine module includes a state transition tracking module, an anomaly rule engine, and a risk assessment model. The state transition tracking module monitors the transition process of payment orders in real time between states such as pending review, disbursement, repayment, and refund. The anomaly rule engine detects anomalies in state transitions, unprocessed timeouts, and data inconsistencies based on a preset set of rules. The risk assessment model combines historical anomaly data with real-time transaction characteristics to assess the anomaly risk level, providing a basis for decision-making in anomaly handling.

[0033] In this embodiment, the exception handling execution module includes an exception classification processing unit, a process automation engine, and a manual intervention interface. The exception classification processing unit classifies exceptions into categories such as loan disbursement failure, overdue repayment, refund exception, and institutional buyback based on the exception type. The process automation engine automatically triggers corresponding processing procedures for different categories of exceptions, such as a re-review process for loan disbursement failure, a collection and buyback process for overdue repayment, and a manual review process for refund exceptions. The manual intervention interface provides a manual review and processing channel for high-risk exceptions, realizing a combination of automated processing and manual decision-making.

[0034] In this embodiment, the collaborative control node module includes a distributed transaction coordinator, a task scheduling engine, and a monitoring and alarm module. The distributed transaction coordinator uses a two-phase commit protocol to ensure the consistency of cross-node data interaction. The task scheduling engine dynamically allocates monitoring and processing tasks according to the load of each node. The monitoring and alarm module monitors the operating status of each module in real time and triggers a multi-level alarm mechanism when system anomalies such as node failures or data synchronization delays are detected, ensuring the stable operation of the distributed system. The system supports the storage and querying of massive amounts of state data through a distributed database cluster (such as TiDB or Cassandra) and adopts an event-driven architecture (EDA) to achieve loosely coupled interaction between modules, ensuring high throughput and low latency. The detailed technical implementation schemes for each module will be described below.

[0035] In some embodiments, the system further includes: a payment status visualization module for providing real-time data visualization and multi-dimensional analysis; and an intelligent learning module for continuously optimizing anomaly detection rules and processing strategies. The system also includes a payment status visualization module, which generates a real-time status monitoring dashboard based on status data in a distributed database. This dashboard graphically displays the overall status distribution, anomaly trends, and processing progress of payment orders, while providing multi-dimensional query functions. It supports filtering and analyzing payment status data by institution, order type, anomaly category, and other dimensions, providing data support for operational decision-making.

[0036] The intelligent learning module trains models based on historical anomaly data and optimizes anomaly detection rules. When analyzing "signature refusal" data, a high percentage of certain errors was identified, prompting the system to automatically prioritize related checks and add a pre-verification step before user signing. Platform service fees are automatically calculated periodically based on the loan disbursement date, and the system automatically generates and pushes outstanding bills to users. Through the implementation of these modules, the system achieves full lifecycle monitoring and anomaly handling of payment status, ensuring data consistency and business continuity in a distributed architecture. It meets the payment management needs of multiple institutions and payment models, while continuously improving system accuracy and efficiency through intelligent optimization.

[0037] It should be noted that, in this embodiment, taking application status management as an example, the system tracks the entire lifecycle of the order status, including more than ten statuses such as personal authentication (pending ID card upload / bank card binding), information supplementation (pending completion of personal information), pending signing, signing in progress, and signing expired. Once the user completes the ID card upload, the system automatically triggers the status transition logic, updating the "personal authentication" status to "information supplementation" and synchronously updating the status field in the distributed database. The page function supports precise queries; users can filter data by application serial number, organization name, application time, etc. Query results are displayed in pages, with 10 records displayed per page by default. A reset function is also provided to clear the query conditions.

[0038] In the factoring model, the application management system receives application data from partner platforms, generates a unique application serial number, and associates it with information such as user name, source institution, number of installments, and financial product. When a user is in the "pending signature" state, the system automatically pushes a signature link to the user's terminal. If the user fails to complete the signature within the specified time, the status automatically changes to "signature expired," and an SMS reminder mechanism is triggered. For example, after a user submits a factoring application, the system records their mobile phone number, selected institution, number of installments, and financial product information. If the user's signature is rejected by the electronic signature platform due to incorrect information, the status changes to "signature rejected," the system automatically indicates the reason for rejection (such as incorrect ID number), and allows the user to resubmit the signature application. Once the signature is completed, the system automatically triggers the risk control review process, entering the "risk control review in progress" state. If the review is successful, the application is considered "successfully submitted"; otherwise, it is considered "rejected."

[0039] The application process for the billing model is similar to that of the factoring model, but differs in data synchronization mechanisms. After the target user confirms their application through the platform, the system synchronizes information such as the application serial number, course price, and order amount in real time. For example, when a user applies for a course, once the course price, order amount, and number of payments are determined, the system generates a course serial number and automatically associates the course information with the institution's revenue sharing rules. The page supports filtering by "application status." For example, when querying "refunded" orders, the system retrieves records from the distributed database showing that the institution initiated and approved the refund, displaying information such as the refund date and amount. For "cancelled" orders, the system records the cancellation reason (e.g., user-initiated cancellation) and releases relevant credit resources. When a factoring model application is successfully submitted, the system automatically generates a loan order, associating the order number with the application serial number and recording the loan disbursement status, overdue status, and card binding status. The order details page allows viewing of fee details, funding information, contract documents, and billing information.

[0040] For example, after an order is associated with another application, the system displays information such as the number of installments made by the user, the current number of repayments, the loan amount disbursed, and the remaining amount due. The system monitors changes in order status in real time through a status analysis engine. When the loan status changes from "pending review" to "disbursed," the system automatically updates the loan date and amount and triggers the bill generation process.

[0041] The loan statement details page supports "Payment Incoming" (single installment repayment) and "Full Payment" (full payment), suitable for offline repayment scenarios. After the user selects the repayment date (default is the current day) and uploads proof of payment, the system verifies the validity of the proof. If successful, the system updates the repayment status and calculates the remaining amount due. For overdue repayments, the system automatically calculates penalty interest. If the overdue period exceeds the specified limit, a compensation and repurchase process is triggered. The statement module synchronizes repayment data in real time. After a user makes a repayment, the system updates the actual payment date, actual principal paid, and interest, and generates a transaction record.

[0042] The loan management module triggers the review process the day after a loan order, supporting batch review of multiple orders from the same institution. Reviewers select orders to be reviewed; after selecting "Approved," the system generates a pending loan order. If the review is rejected, it returns to the "Rejected" status with the reason. When the loan is credited, the user selects the loan date and uploads a payment receipt. The system verifies that the receipt information matches the order amount. If successful, funds are deducted from the factoring account to the merchant's account. After the target user's order is approved, the system calculates the loan amount, service fees, etc. If offline loan is selected, the operator uploads a bank receipt. After the system verifies that the receipt amount matches the order, it marks the loan status as "Disbursed" and records the loan date. After a merchant initiates a refund, the system generates a refund transaction record with the status "Pending Review," recording the institution's refundable fees, principal due, and interest due from the funding party. During the review process, electronic account transfer can be selected, automatically deducting funds from the merchant's account, or offline transfer can be used. After the merchant makes the offline payment, they upload supporting documentation.

[0043] After a user's course withdrawal application is approved, the system generates a refund transaction record, showing the principal to be refunded by the institution and the service fee to be refunded by the platform. After the review is approved, if the user chooses to transfer the money to an electronic account, the system will automatically deduct the corresponding amount from the merchant's account to the user's account and update the refund status to "refund successful".

[0044] The system periodically scans orders that are overdue for more than a specified period and generates repurchase orders. For example, if an order is overdue for more than a specified number of days, the system calculates the principal, penalty, and repurchase amount to be repurchased, and pushes this information to the target user.

[0045] The target user selects the order to be repurchased, chooses a payment method (electronic account transfer or offline transfer), and after confirmation, the system deducts funds from the merchant's account to the factoring account. If offline transfer is chosen, the institution needs to upload a payment voucher. After system verification, the repurchase status is updated to "repurchased" and a repurchase transaction record is generated. After the target user successfully repurchases, the system generates a repurchase transaction record, recording the payment method, actual repurchase amount, repurchase date, etc. For example, the repurchase transaction record shows the payment method as electronic account transfer, the actual repurchase amount, and the date. The system simultaneously updates the order status to "repurchased" and records the relevant data in the financial statistics.

[0046] In some embodiments, a product management module is also included, which supports the creation of general products (applicable to all institutions) and dedicated products (available only to specific institutions). When adding a product, information such as the product name, installment period, fee rate, and loan-to-value ratio is entered. For example, when creating a product, the installment period, service fee rate, financing fee rate, and loan-to-value ratio are set, the funding party is associated, the product status is set to "enabled," and target users can associate with this product.

[0047] When adding a merchant, enter the merchant ID, unified credit code, initial credit limit, and controlling shareholder information. When adding an institution under a merchant, enter the institution name, business license information, risk control rules, and associated financial products. For example, when adding an institution, select factoring as the business model, associate products, and set institution limits. In course management, add courses and associate them with financial products, setting prices, durations, educational requirements, age requirements, etc. Payment management supports configuring multiple payment institutions; enter account numbers and rates. The financial statistics factoring module records all factoring order details, generates data periodically, and supports queries by order number and report month. For example, when querying data for a specific time period, the system displays the order number, order amount, platform service fee, factoring financing fee, and loan amount.

[0048] In some embodiments, a financial statistics and billing module is also included. This module records order details in a billing pattern, such as course price, order amount, number of installments, and payment status. The funding management module handles loan disbursements and refunds. Loans are disbursed from the factoring account to the merchant account, and refunds are disbursed from the platform account to the merchant account. Account transaction records document all transactions. For example, when a user makes a repayment, the system records the transaction number, transaction type, and remarks. During withdrawals, the user enters a withdrawal password, which is verified by the system, which then deducts funds from the account, records the handling fee, and displays the actual amount received.

[0049] It should be noted that in this embodiment, when a user applies to suspend deductions, the system adds a new suspension order, requiring the user to enter the order number and the reason for suspension. After the suspension, the user's terminal displays the corresponding status. For example, if an order is suspended for a specific reason, the system records the reason for suspension, suspends the deduction process, and resumes deductions after the user applies to resume. Institutional password-free authorization and electronic signature platform authorization are completed by obtaining an authorization link. For example, after adding an institution, the system generates an authorization link, and the merchant clicks the link to complete account authorization and set single transaction limits and daily limits.

[0050] The system coordinates data interaction among modules through collaborative control nodes and employs a two-phase commit protocol to ensure distributed transaction consistency. For example, during loan approval, the collaborative node first locks the order data. After approval, it synchronously updates the application status, order status, and fund account. If any step fails, the transaction is rolled back. The status analysis engine detects anomalies based on rule sets, such as loan timeouts or data inconsistencies, triggering an anomaly handling executor that automatically sends alarms to the administrator and initiates the corresponding process based on the anomaly type.

[0051] Secondly, the present invention also provides a distributed device for payment status monitoring and anomaly handling, comprising: one or more processors; and a memory storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement any of the aforementioned distributed systems for payment status monitoring and anomaly handling.

[0052] Thirdly, the present invention provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform any of the aforementioned distributed systems for payment status monitoring and anomaly handling.

[0053] Figure 2 This is a schematic diagram of the structure of the distributed device for payment status monitoring and anomaly handling provided in the embodiments of this application, with reference to... Figure 2 The distributed device for payment status monitoring and anomaly handling includes: a processor 31, a memory 32, a communication device 33, an input device 34, and an output device 35. The distributed device for payment status monitoring and anomaly handling can have one or more processors 31 and one or more memory units 32. The processor 31, memory 32, communication device 33, input device 34, and output device 35 of the distributed device for payment status monitoring and anomaly handling can be connected via a bus or other means.

[0054] The memory 32, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as program instructions / modules corresponding to the distributed system for payment status monitoring and anomaly handling in any embodiment of this application. The memory 32 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a function; the data storage area may store data created based on device usage. Furthermore, the memory 32 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0055] The communication device 33 is used for data transmission.

[0056] The processor 31 executes various functional applications and data processing of the device by running software programs, instructions and modules stored in the memory 32, thereby realizing the aforementioned distributed system for payment status monitoring and anomaly handling.

[0057] Input device 34 can be used to receive input digital or character information, and to generate key signal inputs related to user settings and function control of the device. Output device 35 may include display devices such as a display screen.

[0058] The distributed device for payment status monitoring and anomaly handling provided above can be used to execute the distributed system for payment status monitoring and anomaly handling provided in the above embodiments, and has the corresponding functions and beneficial effects.

[0059] This application also provides a storage medium containing computer-executable instructions. When executed by a computer processor, these instructions are used to perform a distributed system for payment status monitoring and anomaly handling. Specifically, the system includes a distributed data acquisition module, a status analysis engine module, an anomaly handling execution module, and a collaborative control node module. The distributed data acquisition module acquires payment order status data from multiple business nodes in real time and stores it in a distributed database. The status analysis engine module analyzes the status data based on preset status transition rules and anomaly determination models to identify abnormal states. The anomaly handling execution module triggers corresponding processing flows according to the anomaly type. The collaborative control node module coordinates data interaction and task scheduling between modules to ensure the consistency and real-time performance of payment status monitoring and anomaly handling in a distributed environment.

[0060] Storage medium – any type of memory device or storage apparatus. The term “storage medium” is intended to include: mounting media, such as CD-ROMs, floppy disks, or magnetic tape devices; computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory, such as flash memory, magnetic media (e.g., hard disks or optical storage); registers or other similar types of memory elements, etc. Storage media may also include other types of memory or combinations thereof. Furthermore, storage media may reside in a first computer system in which a program is executed, or may reside in a different second computer system connected to the first computer system via a network (such as the Internet). The second computer system can provide program instructions to the first computer for execution. The term “storage medium” can include two or more storage media residing in different locations (e.g., in different computer systems connected via a network). Storage media may store program instructions (e.g., specifically implemented as a computer program) executable by one or more processors.

[0061] Of course, the computer-executable instructions provided in the embodiments of this application are not limited to the distributed system for payment status monitoring and anomaly handling as described above, but can also execute related operations in the distributed system for payment status monitoring and anomaly handling provided in any embodiment of this application.

[0062] The distributed device for payment status monitoring and anomaly handling provided in the above embodiments can execute the distributed system for payment status monitoring and anomaly handling provided in any embodiment of this application. For technical details not described in detail in the above embodiments, please refer to the distributed system for payment status monitoring and anomaly handling provided in any embodiment of this application.

[0063] This invention provides a distributed system for payment status monitoring and anomaly handling. This system offers significant advantages. Its distributed architecture breaks through the data processing bottlenecks of traditional centralized systems, easily handling the ever-increasing volume of payment data. It also supports multiple institutions processing business simultaneously in parallel, greatly improving overall processing efficiency and system scalability, providing strong support for continuous business development. The distributed data acquisition module, with its powerful multi-source real-time data access capabilities, cleans and stores data from different business nodes and in different formats, ensuring data accuracy and integrity, and laying a reliable foundation for subsequent status analysis and processing. The status analysis engine integrates preset rules and intelligent models to accurately capture various payment status anomalies. The risk assessment model further classifies anomalies, greatly improving the accuracy of anomaly detection. The anomaly handling executor organically combines automated processes with manual intervention, quickly responding to different types of anomalies and initiating corresponding processing procedures, ensuring the timeliness and accuracy of anomaly handling. The collaborative control node, through an advanced distributed transaction coordination mechanism, ensures data consistency and operational stability in a distributed environment. Combined with the monitoring and alarm mechanism, it effectively reduces the impact of system failures. The intelligent learning module continuously learns and optimizes from historical data, constantly improving the system's intelligence level and adaptability to complex business scenarios. The visualization module provides strong data support for business decisions with intuitive data presentation, comprehensively improving the quality and efficiency of payment business management and significantly reducing operational risks and costs.

[0064] The above description is merely a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural transformations made using the contents of the present invention's specification and drawings under the inventive concept of the present invention, or direct / indirect applications in other related technical fields, are included within the patent protection scope of the present invention.

Claims

1. A distributed system for payment status monitoring and anomaly handling, characterized in that, It includes a distributed data acquisition module, a status analysis engine module, an exception handling execution module, and a collaborative control node module. The distributed data acquisition module acquires the status data of payment orders from several business nodes in real time and stores it in a distributed database. It connects to business nodes with different architectures according to an adaptive protocol converter, collects discrete status logs and continuous time-series indicators of payment orders in real time, and outputs order indicator status data. The status analysis engine module analyzes the order indicator status data based on preset status transition rules and anomaly judgment models to identify abnormal status types and output abnormal status data of order indicators. The processing path prediction module constructs a knowledge graph based on abnormal order indicator data and historical handling cases. It then combines the contextual features of the current abnormal order indicator data with a graph neural network to generate an optimal handling path sequence with weighted scores. The exception handling execution module determines the type of abnormal data status of order indicators based on the optimal handling path sequence and triggers the corresponding processing flow for abnormal data status of order indicators. The collaborative control node module coordinates data interaction and task scheduling between modules. The processing path prediction module uses a historical case library as its basic data source. Through a knowledge extraction engine, it transforms the abnormal features, execution actions, environmental parameters, and handling results in the cases into graph-structured data, constructing a multi-dimensional knowledge graph storage system. The knowledge graph uses the abnormal type as the main node, the context factors associated with payment channel type, system load range, and time period characteristics as attribute nodes, and historical handling actions as edge entities. The edge weights are dynamically calculated and generated based on historical execution success rate, latency cost, and resource consumption. When the state analysis engine module outputs abnormal state data, the real-time inference engine is started: First, the context feature vector of the current abnormality is determined. The context feature vector includes the number of concurrent transactions when the abnormality is triggered, the status of upstream and downstream dependent services, and infrastructure monitoring indicators. The input is normalized by the feature encoder. Then, the graph neural network model is activated to traverse the knowledge graph. The multi-head graph attention mechanism is used to calculate the similarity probability distribution between the current feature and historical case nodes. In the path generation stage, a multi-objective optimization function under resource constraints is introduced to comprehensively evaluate the expected execution latency, success rate fluctuation threshold, and transaction lock conflict probability parameters of each operation node in the disposal path. The optimal disposal path sequence with weighted scores is output. The optimal handling path sequence is stored using an operation chain encoding structure, which includes atomic operation instruction codes, sequential dependency flags, timeout rollback contingency plan pointers, and execution priority coefficients. Among them, critical path nodes are preset with real-time calculated alternative operation branches to ensure that when the main path execution is blocked, the backup plan is dynamically switched based on the current environment state. After the optimal handling path sequence is generated, the self-correction mechanism of the knowledge graph is triggered simultaneously. The new abnormal feature vectors are temporarily stored as candidate nodes in the incremental buffer. After the handling results are fed back, the topology optimization and edge weight calibration of the graph are completed.

2. The distributed system for payment status monitoring and anomaly handling according to claim 1, characterized in that, The distributed data acquisition module further includes a multi-source data access unit, a data cleaning unit, and a distributed storage unit. The multi-source data access unit collects payment-related data in real time from the inbound management system, the order management system, the loan management system, and the refund management system. The data cleaning unit performs format standardization and outlier filtering on the collected data. The distributed storage unit uses a sharding storage strategy to store the cleaned data in a distributed database.

3. The distributed system for payment status monitoring and anomaly handling according to claim 1, characterized in that, The state analysis engine module includes a state transition tracking module, an anomaly rule engine, and a risk assessment model. The state transition tracking module monitors the transition process of payment orders in real time between the states of pending review, disbursement, repayment, and refund. The anomaly rule engine detects anomalies in state transitions, unprocessed timeouts, and data inconsistencies based on a preset set of rules. The risk assessment model combines historical anomaly data with real-time transaction characteristics to assess the anomaly risk level, providing a basis for decision-making in anomaly handling.

4. The distributed system for payment status monitoring and anomaly handling according to claim 1, characterized in that, The exception handling execution module includes an exception classification and processing unit, a process automation engine, and a manual intervention interface. The exception classification and processing unit classifies exceptions into loan disbursement failure, overdue repayment, refund exception, and institutional repurchase according to the exception type. The process automation engine automatically triggers the corresponding processing flow for several types of exceptions.

5. The distributed system for payment status monitoring and anomaly handling according to claim 4, characterized in that, The collaborative control node module includes a distributed transaction coordinator, a task scheduling engine, and a monitoring and alarm module. The distributed transaction coordinator uses a two-phase commit protocol to ensure the consistency of cross-node data interaction. The task scheduling engine dynamically allocates monitoring and processing tasks according to the load of each node. The monitoring and alarm module monitors the operating status of each module in real time and triggers a multi-level alarm mechanism when a system anomaly is detected.

6. The distributed system for payment status monitoring and anomaly handling according to claim 5, characterized in that, The system also includes a payment status visualization module, which generates a real-time status monitoring dashboard based on status data in a distributed database. The dashboard graphically displays the overall status distribution, anomaly trends, and processing progress of payment orders.

7. The distributed system for payment status monitoring and anomaly handling according to claim 6, characterized in that, The distributed database adopts an architecture that combines master-slave replication and sharded storage. The master node is responsible for data writing and real-time synchronization, while the slave nodes bear the query load. The sharded storage distributes the data to several nodes according to the order type and organization identifier.

8. The distributed system for payment status monitoring and anomaly handling according to claim 7, characterized in that, When handling overdue repayment exceptions, the exception handling execution module automatically triggers the institution repurchase process, including extracting the repurchase principal from overdue orders, calculating repurchase penalties, generating repurchase orders and pushing them to the institution, and updating the order status and financial flow in the distributed database in real time.

9. The distributed system for payment status monitoring and anomaly handling according to claim 8, characterized in that, The system supports parallel processing by multiple institutions in a distributed environment. Each institution node independently handles its own payment status monitoring and anomaly handling tasks, and cross-institutional data synchronization and conflict coordination are achieved through collaborative control nodes.

10. The distributed system for payment status monitoring and anomaly handling according to claim 9, characterized in that, The system also includes an intelligent learning module, which trains on historical anomaly data based on machine learning algorithms to optimize anomaly judgment rules and risk assessment models, thereby improving the accuracy of anomaly detection and the adaptability of processing strategies.

11. A distributed device for payment status monitoring and anomaly handling, characterized in that, include: One or more processors; A memory that stores one or more programs, which, when executed by one or more processors, enable the one or more processors to implement a distributed system for payment status monitoring and anomaly handling as described in any one of claims 1-10.

12. A storage medium containing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a computer processor, are used to perform the distributed system for payment status monitoring and anomaly handling as described in any one of claims 1-10.

Images