Smart campus payment processing method and system

Abstract

The application provides a smart campus payment processing method and system, and relates to the technical field of education informatization. Through the financial end, the charging rules are configured to generate bills and publish events, the message queue synchronizes data and pushes reminders, the parent end initiates payment, the payment is completed through unified gateway scheduling and is verified by the core module, the state is updated after verification and automatic reconciliation, the problems of manual operation inefficiency, high error rate, data synchronization delay and security risk in campus payment management are solved, the campus payment process is automatically processed, the operation efficiency is significantly improved, human errors are reduced, the data real-time synchronization and payment security are ensured.

Description

Technical Field

[0001] This application relates to the field of educational informatization technology, and in particular to a smart campus payment processing method and system. Background Technology

[0002] Current campus fee management practices generally combine offline collection with manual bookkeeping, supplemented by simple online payment tools. Finance staff need to manually create invoices using Excel spreadsheets or basic accounting software, a process that is not only time-consuming and labor-intensive but also prone to data errors or omissions due to human error. Invoice notifications typically rely on WeChat group messages or paper notices. Information in WeChat groups is easily overwritten and overlooked, while paper notices are subject to distribution delays and loss, preventing parents from receiving timely payment information. In the payment process, the system often only supports a single third-party payment interface or bank transfer. When this interface malfunctions, the payment process is interrupted, impacting efficiency. After payment, finance staff must manually compare bank statements with invoice records and manually update the payment status, a process that is inefficient and prone to omissions or errors. Furthermore, the lack of a unified collaborative platform between finance, teachers, and parents means data synchronization relies entirely on manual operation, leading to information asymmetry. Subsequent processes such as reconciliation, refund processing, and report generation also require significant manual intervention, which is not only time-consuming but also difficult to guarantee accuracy. The lack of transparency in the fund transfer process means that parents cannot check payment status in real time, and the finance department also has difficulty effectively monitoring the flow of funds. At the same time, the simple data storage method poses a security risk of being tampered with or leaked, and cannot meet the requirements of modern campus management for fund security and operational standards.

[0003] To address the aforementioned issues, existing technologies urgently need improvement. Summary of the Invention

[0004] This application provides a smart campus payment processing method and system, which has the advantages of automating the campus payment process, significantly improving operational efficiency, reducing human error, and ensuring real-time data synchronization and payment security.

[0005] Firstly, the smart campus payment processing method provided in this application adopts the following technical solution: A smart campus payment processing method includes: The financial side configures the charging rules, which are then processed a second time after authentication by the permission and data rule engine. This generates a bill to be paid with payment conditions and writes it to the core database. The payment conditions include the payment channel, payment deadline, and additional business requirements. The bill generation event is published to the message queue, and the event is accompanied by an identity authentication identifier. The message queue listens for the bill generation event, determines the target sending end based on the identity authentication identifier, and synchronizes the bill data to the corresponding teacher's or parent's end; it generates a notification strategy in the preset reminder database according to the payment conditions, and pushes payment reminders according to the notification strategy; Parents initiate a payment request, which is then routed to a matching payment channel via the unified payment gateway to complete the payment. The payment channel then sends a callback with the payment result, and the core verification module verifies the consistency between the payment information and the billing data and payment terms. After verification, update the bill status to "paid", write the payment record and publish the payment success event, and update the payment status on both the teacher's and finance sides simultaneously; The reconciliation engine periodically retrieves settlement files from payment channels, automatically compares and matches them with the already paid transaction records, and generates reconciliation reports.

[0006] Optionally, the charging rules are subjected to a structured secondary parsing specific to the education scenario, and the payment conditions are bound to the bill ID, student ID, and class ID with a time-series unique index, and the core bill data is stored on the blockchain; the identity authentication identifier is generated using a three-level national cryptographic encryption of role-institution-student, and only terminals matching the encrypted identifier are allowed to receive bill data, preventing unauthorized access and data tampering.

[0007] Optionally, a zero-trust targeted routing distribution mechanism is built based on identity authentication identifiers. The target terminal is first verified for identity legitimacy, and then bill data is synchronized. At the same time, combined with payment conditions and parents' terminal usage habits, a notification strategy is preloaded through edge computing to achieve millisecond-level payment reminder push under low-bandwidth campus networks, and a tiered reminder strategy is automatically generated for overdue bills.

[0008] Optionally, the core verification module constructs a risk control model for campus payment behavior. Based on the payment condition fulfillment verification, it adds multi-dimensional verification of payment environment, transaction frequency, and terminal device fingerprint. Payment requests initiated beyond the time limit, through non-designated channels, or from abnormal devices are directly blocked by circuit breakers, and risk warning logs are generated simultaneously.

[0009] Optionally, the unified payment gateway can build a payment channel health time-series evaluation system to collect the success rate, response latency, and fee rate indicators of each channel in real time. Combined with the bill payment conditions, the system can dynamically and weightedly select the optimal channel and seamlessly switch to the backup channel when the main channel fails, thus ensuring the transaction stability in campus batch payment scenarios.

[0010] Optionally, the reconciliation engine uses a multi-dimensional difference attribution algorithm to automatically locate the difference type for abnormal transactions that fail to match, and triggers automated cross-source secondary verification. Data that is still abnormal after verification automatically generates a financial processing work order, forming a fully automated processing link of reconciliation-location-verification-closed loop.

[0011] Optionally, it also includes a closed-loop refund process: when the finance department initiates a refund instruction, the system first performs a reverse compliance check on the payment conditions of the original order. After the verification is passed, the system matches the original payment channel to execute the refund. The entire refund process is stored using homomorphic encryption and is linked with bills and payment logs to form an immutable full-link traceability chain for funds.

[0012] Secondly, this application provides a smart campus payment processing system, comprising: The bill configuration module is used by the finance department to configure the charging rules. After authentication by the permission and data rule engine, it performs secondary processing to generate a bill to be paid with payment conditions and write it to the core database. The payment conditions include the payment channel, payment deadline and additional business requirements. The bill generation event is published to the message queue, and the event is accompanied by an identity authentication identifier. The bill synchronization module is used to listen for the bill generation event in the message queue, determine the target sending end based on the identity authentication identifier, and synchronize the bill data to the corresponding teacher's or parent's end; generate a notification strategy in the preset reminder database according to the payment conditions, and push payment reminders according to the notification strategy; The payment module is used by parents to initiate payment requests, which are then dispatched to the matching payment channel through the unified payment gateway to complete the payment. The payment channel then sends back the payment result, and the core verification module verifies the consistency between the payment information and the billing data and payment conditions. The synchronization module is used to update the bill status to "paid" after verification, write the payment record and publish the payment success event, and synchronize the payment status between the teacher's side and the finance side. The reconciliation module is used by the reconciliation engine to periodically retrieve payment channel settlement files, automatically compare and match them with the paid transaction records, and generate reconciliation reports.

[0013] Thirdly, this application provides a computer device, the device comprising: a memory and a processor, wherein the processor, when executing computer instructions stored in the memory, performs the method described above.

[0014] Fourthly, this application provides a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the method described above.

[0015] In summary, this application generates bills and publishes events by configuring charging rules on the financial side, synchronizes data and pushes reminders through the message queue, and completes payments initiated by parents through a unified gateway and verification by the core module. After verification, the status is updated and accounts are automatically reconciled. This solves the problems of inefficiency, high error rate, data synchronization delay and security risks in campus payment management. It has the advantages of automating the campus payment process, significantly improving operational efficiency, reducing human error, and ensuring real-time data synchronization and payment security. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the computer device structure of the hardware operating environment involved in the embodiments of this application; Figure 2 This is a flowchart illustrating the first embodiment of the smart campus payment processing method of this application; Figure 3 This is a structural block diagram of the first embodiment of the smart campus payment processing system of this application. Detailed Implementation

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

[0018] Reference Figure 1 , Figure 1 This is a schematic diagram of the computer device structure of the hardware operating environment involved in the embodiments of this application.

[0019] like Figure 1 As shown, the computer device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen or an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wireless-Fidelity (Wi-Fi) interface). The memory 1005 may be high-speed random access memory (RAM) or stable non-volatile memory (NVM), such as a disk drive. The memory 1005 may also optionally be a storage device independent of the aforementioned processor 1001.

[0020] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on the computer device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0021] like Figure 1As shown, the memory 1005, which serves as a storage medium, may include an operating system, a network communication module, a user interface module, and a smart campus payment processing program.

[0022] exist Figure 1 In the computer device shown, the network interface 1004 is mainly used for data communication with the network server; the user interface 1003 is mainly used for data interaction with the user; the processor 1001 and the memory 1005 in this application can be set in the computer device, and the computer device calls the smart campus payment processing program stored in the memory 1005 through the processor 1001 and executes the smart campus payment processing method provided in the embodiment of this application.

[0023] Traditional campus fee payment management models often employ a simple combination of offline collection, manual bookkeeping, and online payment tools. Finance staff manually create invoices and notify parents through unsystematic methods; the payment process relies on a single interface, requiring manual verification and status updates after successful payment. The lack of a unified collaborative platform between these roles and the manual reliance on data synchronization result in inefficient processes such as reconciliation, refunds, and report generation, and also compromises transparency and security in fund transfers.

[0024] This application provides a smart campus payment processing method, referring to... Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the smart campus payment processing method of this application.

[0025] In this embodiment, the smart campus payment processing method includes the following steps: Step S10: Configure the billing rules on the financial side. After authentication by the permission and data rule engine, perform secondary processing to generate a bill to be paid with payment conditions and write it to the core database. The payment conditions include payment channel, payment time limit and additional business requirements. Publish the bill generation event to the message queue. The event is accompanied by an identity authentication identifier.

[0026] Step S20: The message queue listens for the bill generation event, determines the target sending end based on the identity authentication identifier, and synchronizes the bill data to the corresponding teacher's or parent's end; generates a notification strategy in the preset reminder database according to the payment conditions, and pushes payment reminders according to the notification strategy.

[0027] Step S30: The parent initiates a payment request, which is then dispatched to the matching payment channel via the unified payment gateway to complete the payment. The payment channel then sends back the payment result, and the core verification module verifies the consistency between the payment information and the billing data and payment conditions.

[0028] Step S40: After verification, update the bill status to "paid", write the payment record and publish the payment success event, and synchronously update the payment status on the teacher's side and the finance side.

[0029] Step S50: The reconciliation engine periodically pulls the settlement files from the payment channels, automatically compares and matches them with the already paid transaction records, and generates a reconciliation report.

[0030] For ease of understanding, the following explains some key terms in this embodiment: The financial module refers to the system interface or module responsible for school financial management, fee rule configuration, bill generation and verification, and other business operations. It is typically operated by the school's finance personnel and is used to manage the school's various income and expenditure items.

[0031] A permission and data rules engine is a software component used to perform user permission verification and data compliance checks. Based on a pre-defined set of rules, it authenticates and processes user operations and data to ensure the legality of operations and the accuracy of data.

[0032] The core database refers to a centralized data storage system that stores the system's core business data (such as bills, payment records, and user identities). It provides data persistence, query, and management functions and serves as the data foundation for the entire payment processing flow.

[0033] Payment terms refer to a series of constraints attached to an invoice when it is generated to regulate payment behavior. These typically include payment channels (specifying allowed payment methods, such as WeChat Pay, Alipay, bank cards, etc.), payment deadlines (stipulating the valid payment period for the invoice), and additional business requirements (such as whether installment payments are allowed, whether specific approvals are required, etc.).

[0034] A message queue is a middleware used for asynchronous communication between different system components. It decouples systems by storing and forwarding messages, improving scalability and reliability. When an event occurs, a message is published to the queue, and other components interested in that event can subscribe to and process the message from the queue.

[0035] An authentication token is a credential used to uniquely identify a user or terminal. Internally, it verifies the legitimacy of the operator and ensures the security and directionality of data transmission.

[0036] The teacher's or parent's app refers to a mobile application or web interface used by teachers or parents to receive bills, check payment status, and initiate payment requests. It serves as the entry point for users to interact with the smart campus payment system.

[0037] The default reminder database is a dedicated database that stores various notification strategies and reminder rules. It generates and manages the sending schedule of payment reminders based on the bill's payment terms.

[0038] Notification policies refer to the specific rules set based on payment conditions for sending payment reminders to users. These policies can include reminder timing, frequency, and method (such as SMS or in-app messages).

[0039] A unified payment gateway is an interface layer that centrally manages multiple payment channels. It is responsible for receiving payment requests, routing them to the appropriate payment channel based on preset rules or real-time status, and processing callback information from the payment channels.

[0040] Payment channels refer to the third-party payment service providers or banking systems that actually execute fund transfers. Examples include WeChat Pay, Alipay, and UnionPay.

[0041] The core verification module is a system component that verifies the consistency of payment results after payment is completed. It compares the payment information returned by the payment channel with the system's internal billing data and payment terms to ensure the accuracy and compliance of the payment.

[0042] A reconciliation engine is a system module that automates the comparison of payment records with settlement documents. It periodically retrieves settlement data from payment channels, matches it with the system's internal payment records, identifies discrepancies, and generates reconciliation reports.

[0043] This embodiment provides a smart campus payment processing method, the process of which includes the following steps: First, the finance department configures the fee rules. Specifically, finance personnel manually input or select preset fee items, amounts, applicable student ranges, and other information through the financial management system interface to construct basic fee rules. These rules are directly stored by the system as the basis for subsequent bill generation. During bill generation, the system directly generates bills to be paid based on these stored fee rules and attaches payment conditions to each bill. These payment conditions typically include a default payment channel (e.g., specifying that only a certain payment method is supported), a fixed payment deadline (e.g., uniformly set to seven days after bill generation), and no specific additional business requirements. The generated bills to be paid and their payment conditions are then written to the core database for persistent storage.

[0044] Secondly, the system publishes an invoice generation event to the message queue. Once an invoice to be paid is successfully generated and written to the core database, the system triggers an invoice generation event. This event is encapsulated into a message and sent to the message queue. A basic user ID or student ID is appended to this message as an authentication identifier, used to subsequently identify the user to whom the invoice belongs.

[0045] Next, the message queue listens for and processes the bill generation event. Upon receiving the event, the message queue queries the system's internal user information table based on the authentication identifier (e.g., student ID) attached to the event to determine whether the target recipient of the bill is the corresponding teacher's or parent's device. Subsequently, the bill data is synchronously sent to the target recipient via a simple push notification mechanism, such as SMS or in-app notification. Simultaneously, the system generates a basic notification strategy in a preset reminder database based on the payment conditions included in the bill (e.g., payment deadline). This notification strategy may only include a fixed reminder time (e.g., three days before the payment deadline), and a payment reminder is pushed to the target device according to this strategy.

[0046] Subsequently, the parent initiates a payment request. When a parent receives a payment reminder on either the teacher's or parent's end and decides to pay, they select a payment method through the interface and submit a payment request. This payment request is sent to the unified payment gateway. Upon receiving the request, the unified payment gateway routes the payment request directly to the corresponding payment channel based on the payment method specified in the request (e.g., WeChat Pay or Alipay). After the payment channel completes the fund transfer, it sends a payment result (e.g., payment successful or failed) back to the unified payment gateway. The unified payment gateway then passes this payment result to the core verification module. Upon receiving the payment result, the core verification module performs a simple comparison between the payment information (e.g., payment amount) and the billing data (e.g., bill amount) and verifies whether the payment status is successful to confirm consistency.

[0047] After successful verification, the system will update the bill status and record the payment transaction. Once the core verification module confirms that the payment information matches the bill data and the payment is successful, the system will update the status of the corresponding bill in the core database to "paid." Simultaneously, a simple record of the payment transaction (such as transaction time, amount, and payment channel) will be written to the payment transaction table. Subsequently, the system will issue a payment success event and send a simple notification to the teacher's and finance departments, informing them that the relevant bill has been paid. These departments can then refresh or check the latest payment status themselves.

[0048] Finally, the reconciliation engine periodically retrieves and compares payment channel settlement files. At preset fixed time intervals (e.g., a fixed time each day), the engine retrieves the daily settlement files from the interfaces or FTP servers of various partner payment channels. Then, the engine performs a simple one-to-one match between the transaction records in these settlement files and the payment records already recorded in the system, for example, by checking order numbers and transaction amounts. After the match is complete, the reconciliation engine generates a basic reconciliation report listing the successfully matched and unmatched transaction records.

[0049] The smart campus payment processing method proposed in this embodiment effectively solves the problems of low efficiency, untimely notifications, and delayed data synchronization in traditional campus payment processes by systematically configuring charging rules, automating bill generation, and accurately pushing bills. This method integrates multiple payment channels through a unified payment gateway, simplifying the payment process, and ensures the accuracy of payment information through a core verification module. Furthermore, the automated reconciliation engine improves the efficiency of financial verification and reduces the error rate of manual operations, thereby comprehensively improving the automation level of campus payment management and the accuracy of data processing.

[0050] In some of the embodiments described above, while the process of configuring charging rules, generating invoices, and synchronizing them to the target sender via a message queue has been proposed, along with subsequent payment and reconciliation procedures, there is still room for improvement in handling complex charging rules in educational scenarios, ensuring the authenticity and immutability of invoice data, and guaranteeing the security and preventing unauthorized access to sensitive invoice information during transmission and reception. Without refined rule parsing, robust data storage, and strict identity authentication mechanisms, invoice data may be susceptible to tampering, information leakage, or misdelivery, thereby affecting the accuracy, security, and credibility of the entire payment process.

[0051] To address this, this embodiment further proposes a structured secondary analysis of the charging rules specifically tailored to the education scenario. Specifically, this refers to in-depth, structured analysis and processing of the original charging rules configured on the financial side, tailored to the characteristics of the education field. For example, the system can identify and parse different fee types such as tuition, accommodation fees, meal fees, and textbook fees, along with their corresponding calculation formulas, applicable student ranges, reduction / exemption policies, and installment payment options. By transforming these unstructured or semi-structured rules into a structured data format that the system can recognize and operate, it can ensure that the system more accurately understands and executes complex charging logic, avoiding billing errors caused by misunderstandings of the rules from the outset, and providing a refined data foundation for subsequent billing generation and payment condition binding.

[0052] Building upon this foundation, this embodiment binds payment terms to a time-series unique index with the bill ID, student ID, and class ID. This means that in the core database, for each generated bill, its payment terms are not only associated with a unique bill ID, student ID, and class ID, but also incorporate timestamp information, collectively forming a composite, time-series unique index. This binding mechanism ensures that even bills generated for the same student or class at different times can have their payment terms independently and accurately identified and managed. This helps prevent data confusion, improves the efficiency of data querying and retrieval, and provides accurate and reliable data anchors for subsequent reconciliation, auditing, and historical bill tracing, ensuring the uniqueness and traceability of bill data.

[0053] Simultaneously, this embodiment uses blockchain to store the core bill data. Specifically, the system performs hash calculations on key bill information, such as bill ID, student ID, amount due, payment terms, and generation time, and uploads the generated hash value or encrypted digest to a pre-defined blockchain network. The decentralized, immutable, and traceable characteristics of blockchain provide a high degree of data integrity and authenticity assurance for the core bill data. Once the data is on the chain, any tampering with the original bill data will cause its hash value to change, thus contradicting the on-chain record, and the system can detect the data anomaly. This greatly enhances the credibility of the bill data, effectively reduces the risk of malicious data tampering, and provides strong, irrefutable evidence for potential payment disputes or audits.

[0054] Furthermore, the identity authentication identifier in this embodiment is generated using a three-tiered national cryptographic encryption system: role-institution-student. This means that when generating the identity authentication identifier for bill distribution, the system comprehensively considers the user's role (e.g., parent, teacher), affiliated institution (e.g., school, class), and the student's unique identity information, and uses encryption algorithms (such as SM2, SM3, SM4, etc.) that conform to the standards of the State Cryptography Administration for encryption processing. This layered encryption mechanism ensures the complexity and security of the identity authentication identifier, making it difficult to forge or crack. By applying national cryptographic algorithms, various cryptographic attacks can be effectively resisted, ensuring the security of the identity authentication process from the source and laying a solid security foundation for subsequent data transmission and access control.

[0055] Based on this, this embodiment only allows terminals matching the encrypted identifier to receive bill data. Specifically, after the message queue listens for the bill generation event and determines the target sender, the system performs strict identity verification before synchronizing the bill data to the corresponding teacher's or parent's terminal. Only when the identity authentication identifier provided by the receiving terminal completely matches the identity authentication identifier attached to the bill event and encrypted using national cryptographic standards is the terminal allowed to receive and further process the bill data. This strict access control mechanism ensures that bill data can only be received by authorized terminals whose identities have been strictly verified, thereby effectively preventing unauthorized terminals from obtaining sensitive bill information, achieving targeted and secure data distribution, and greatly improving the security of data transmission.

[0056] Through the above technical solutions, this embodiment significantly improves the security, accuracy, and reliability of smart campus payment processing compared to the original billing process. By performing a structured secondary parsing of the charging rules specific to the education scenario, the system can more precisely and accurately understand and execute complex education charging logic, preventing bill generation errors from the outset. Binding payment conditions to bill ID, student ID, and class ID with a time-series unique index ensures the uniqueness and traceability of each bill and its payment conditions, greatly improving the accuracy of data management and query efficiency. More importantly, blockchain notarization of core bill data leverages the immutability of blockchain to provide strong authenticity protection for bill data, effectively eliminating the risk of malicious data tampering and enhancing the credibility of the bills. Simultaneously, identity authentication identifiers are generated using a three-level national cryptographic encryption system (role-institution-student), and only terminals matching the encrypted identifier are allowed to receive bill data. This constructs a multi-layered, high-strength security protection system, fundamentally preventing unauthorized access and leakage of sensitive bill information, ensuring that bill data is delivered securely and accurately to authorized recipients. These improvements work together to create a safer, more transparent, and more efficient smart campus payment processing environment. They effectively address core pain points in traditional payment systems, such as inaccurate rule parsing, easy data tampering, and insecure information transmission, providing schools, parents, and students with a more reliable payment service experience.

[0057] In some of the embodiments described above, although it is proposed to synchronize billing data to the corresponding teacher's or parent's end through identity authentication identifiers and generate notification strategies to push payment reminders based on payment conditions, in actual operation, relying solely on identity authentication identifiers for data distribution may face security risks and is difficult to effectively prevent unauthorized access and data tampering. Furthermore, in the context of complex campus network environments and limited bandwidth resources, ensuring the timeliness and accuracy of payment reminders, as well as efficiently managing and collecting overdue bills, are technical challenges that require further solutions.

[0058] To address this, this embodiment further proposes a zero-trust targeted routing distribution mechanism based on identity authentication identifiers. It first performs a secondary verification of the target terminal's identity legitimacy before synchronizing billing data. Simultaneously, it combines payment conditions and parents' terminal usage habits, and uses edge computing to preload notification strategies to achieve millisecond-level payment reminder pushes in low-bandwidth campus networks. Furthermore, it automatically generates tiered reminder strategies for overdue bills.

[0059] Specifically, the Zero Trust Directed Routing mechanism is an advanced security architecture whose core principle is "never trust, always verify." This means the system does not trust any user, device, or network by default, even if they are located on an internal network. Each billing data synchronization request is considered a potential threat and requires rigorous authentication and authorization checks. This mechanism uses identity verification tokens as initial identification credentials, but adds multi-dimensional security policies and dynamic assessments to ensure the security of data transmission. Under this mechanism, secondary verification of identity legitimacy is a crucial step. It re-verifies the user's identity and device status of the target terminal before billing data synchronization. This may include, but is not limited to: requiring users to perform multi-factor authentication (such as SMS verification codes, fingerprint recognition, facial recognition, etc.), checking the health status of the terminal device (such as whether it is jailbroken / rooted, whether it contains malware, whether it meets security baselines), and verifying whether the terminal's geographical location or network environment is abnormal. Only terminals that pass the secondary verification are allowed to receive billing data, thus significantly improving the security of data distribution.

[0060] Meanwhile, to optimize the efficiency and accuracy of payment reminders, this embodiment employs an edge computing pre-loading notification strategy. Edge computing refers to moving computation and data storage to the edge of the network, i.e., near the data source, to reduce latency and bandwidth consumption. In this solution, the system combines the payment conditions of the bill (such as payment deadlines and amounts) with the historical usage habits of the parent's terminal (such as frequently used payment periods, preferred notification methods, and device activity times) to pre-calculate and load the notification strategy at edge nodes (such as campus gateways and regional servers) close to the parent's terminal. This means that the notification logic and some content are ready before they need to be pushed, eliminating the need to retrieve them from the central server each time. Through the edge computing pre-loading notification strategy, when the payment reminder conditions are triggered, the edge node can directly execute the notification push without waiting for instructions or data transmission from the central server. Since computation and data processing occur at the edge, closer to the user, the response time is greatly shortened. Even in a low-bandwidth campus network environment, near real-time millisecond-level payment reminder pushes can be achieved, ensuring that parents receive notifications promptly. In addition, the system can automatically generate tiered reminder strategies for overdue bills. A tiered collection strategy refers to automatically generating different levels of collection measures based on factors such as the length of time a bill is overdue, the amount, and the student's historical payment records. For example, for a bill that is just one day overdue, the system may send a mild SMS reminder; for a bill that is a week overdue, it may send an app push notification, a phone call, and a warning message; for bills that are even longer overdue, it may trigger a higher-level collection process, such as notifying the homeroom teacher or the finance department. This strategy can adopt differentiated collection methods according to the severity of the overdue situation, thereby improving collection efficiency.

[0061] Through the above technical solutions, this embodiment achieves significant improvements in security, efficiency, and intelligence in bill data synchronization and payment reminders. Based on a zero-trust directed routing distribution mechanism and secondary verification of identity legitimacy, the system effectively prevents unauthorized access to bill data and potential data leakage risks, ensuring the privacy and integrity of bill information. Simultaneously, by combining payment conditions with parents' terminal usage habits and employing an edge computing pre-loading notification strategy, the system greatly optimizes the efficiency of payment reminder pushes. Even in low-bandwidth campus network environments, millisecond-level reminder pushes can be achieved, significantly improving user experience and payment timeliness. Furthermore, the system automatically generates tiered collection strategies for overdue bills, enabling it to intelligently adopt different levels of collection measures based on the degree of overdue payment, effectively improving bill recovery rates, reducing the burden on finance personnel, and further improving the closed-loop management of the entire smart campus payment processing flow.

[0062] In some of the aforementioned implementation methods, the smart campus payment processing method verifies the consistency between payment information and billing data, as well as payment conditions, through a core verification module, ensuring the basic compliance of the payment process. However, in actual campus payment scenarios, relying solely on consistency verification between billing and payment information is insufficient to effectively address increasingly complex payment risks, such as malicious order fraud, account theft, unauthorized payments, or exploitation of system vulnerabilities for illegal operations. These potential risks could lead to financial losses, data breaches, or compromised system stability, posing a threat to campus payment security.

[0063] To address this, this embodiment further proposes that the core verification module constructs a campus payment behavior risk control model to enhance the ability to identify and prevent risks during the payment process. This campus payment behavior risk control model is a comprehensive risk management mechanism that integrates multiple risk assessment algorithms and rules to perform real-time, dynamic risk scoring on payment requests. The model can be based on machine learning algorithms, such as identifying abnormal patterns by training on historical payment data, or it can employ an expert rule system to preset a series of risk judgment conditions.

[0064] Building upon payment condition fulfillment verification, this method further enhances verification across multiple dimensions, including payment environment, transaction frequency, and terminal device fingerprinting. Specifically, payment environment verification assesses the security of external conditions at the time the payment request is initiated. This can include geolocation analysis of the IP address initiating the payment request to determine if it originates from a high-risk area or differs from commonly used locations; detecting network types, such as whether it's a public, insecure network; and identifying operating system and browser versions to uncover potential security vulnerabilities or abnormal configurations. Transaction frequency verification monitors the frequency of transactions by a specific user, device, or account within a short period. For example, the system records and analyzes the number of payment requests initiated by a parent within a given timeframe. If this frequency significantly exceeds normal levels or a preset threshold, it may indicate a risk of automated attacks or account theft. Terminal device fingerprint verification collects and analyzes unique or quasi-unique identifiers of the user's terminal device, such as hardware characteristics, software configuration, and browser parameters, to generate a unique "fingerprint." This fingerprint identifies whether the payment request originates from a known, trusted device or a novel, unverified, and unusual device, effectively preventing device forgery or identity misuse.

[0065] Based on the results of the multi-dimensional verification, the system can process high-risk payment requests in real time. Specifically, payment requests initiated by timed-out, non-designated channels, or abnormal devices are directly blocked by circuit breakers. Timed-out blocking means that if the submission time of a payment request exceeds the payment deadline specified in the pending bill, the system will immediately reject the payment request to ensure the timeliness and regularity of payment. Non-designated channel blocking means that if a payment request attempts to make payment through a payment channel that is not explicitly specified in the payment conditions of the pending bill, the system will directly block the transaction and force the user to use a compliant payment channel. Abnormal device blocking means that when the terminal device fingerprint verification result shows that the payment request comes from a device marked as abnormal or high-risk, the system will immediately block the execution of the payment request to prevent potential fraudulent activities. At the same time, the system will generate risk warning logs. These logs record all relevant information of the payment requests that are blocked by circuit breakers, including but not limited to the request time, bill ID, payment user identity, specific reasons for verification failure (such as timed-out, non-designated channel type, abnormal device fingerprint characteristics), and related payment environment and transaction frequency data. These logs provide crucial data support for subsequent risk analysis, audit follow-up, and continuous optimization of risk control models.

[0066] Through the aforementioned technical solutions, this embodiment builds a more comprehensive and in-depth risk control system on top of basic payment information and bill consistency verification. The introduction of a campus payment behavior risk control model, combined with multi-dimensional verification of the payment environment, transaction frequency, and terminal device fingerprints, enables the system to identify and prevent potential risks that traditional verification mechanisms struggle to detect, such as unauthorized payments, malicious attacks, or violations. When a payment request that does not comply with security policies (such as timeouts, non-designated channels, or requests initiated by abnormal devices) is detected, the system can immediately and decisively implement circuit breaker interception, effectively preventing high-risk transactions and significantly improving the overall security and stability of the campus payment system. Furthermore, the synchronously generated risk warning logs provide a data foundation for tracing and analyzing risk events and iteratively optimizing risk control strategies, forming a closed loop of proactive defense, real-time response, and continuous improvement in risk management. Ultimately, this ensures the safety of campus funds, maintains normal payment order, and reduces operational risks.

[0067] In some of the embodiments described above, a unified payment gateway is proposed to schedule payment requests to matching payment channels for completion. However, in actual campus bulk payment scenarios, the stability and efficiency of payment channels directly affect the user's payment experience and the overall operational efficiency of the system. A single or fixed payment channel selection strategy may lead to payment failures or delays due to channel failures, performance degradation, or other issues, thereby affecting the timeliness of payments and the smoothness of fund transfers.

[0068] To address this, this embodiment proposes a unified payment gateway to build a time-series evaluation system for the health of payment channels. This system collects data on the success rate, response latency, and fee rate of each channel in real time, and dynamically weights and selects the optimal channel based on bill payment conditions. When the main channel fails, the system seamlessly switches to the backup channel, ensuring transaction stability in campus batch payment scenarios.

[0069] Specifically, as a centralized processing entry point for payment requests, the unified payment gateway's core function is to route payment requests to appropriate payment channels according to preset rules. Building upon this, a time-series health assessment system for payment channels is established. This system, either within the unified payment gateway or as a closely collaborating module, provides a mechanism for continuously and dynamically monitoring and evaluating the operational status of each payment channel. This system can periodically or event-drivenly collect channel performance data, storing and managing it in time-series format to provide data support for subsequent channel selection and fault handling.

[0070] To accurately assess the health of payment channels, the system collects key metrics such as success rate, response latency, and fees for each channel in real time. Success rate reflects the completion rate of payment transactions, response latency reflects the speed of transaction processing, and fees are directly related to transaction costs. Real-time collection means the system can obtain this data continuously and instantly, for example, by recording transaction results and time consumption after each transaction, or by periodically querying the data through API interfaces with payment channels. This real-time data forms the basis for assessing the current health of the channels.

[0071] After acquiring real-time health data, the system dynamically and weights the selection of the optimal payment channel based on the bill payment conditions. Dynamic weighted selection means that the system uses an intelligent algorithm to comprehensively score and rank all available channels based on real-time collected payment channel health indicators and preset payment conditions in the bill to be paid (e.g., specified payment method, specific bank, etc.), thereby selecting the payment channel with the best performance, lowest cost, and compliance with the bill requirements. This selection process is dynamic and can be adjusted according to the channel's real-time performance and the specific requirements of the bill.

[0072] Furthermore, to further enhance the system's robustness, the system can seamlessly switch to a backup channel when the primary channel fails. Seamless switching means that when the currently selected primary payment channel fails (such as a sharp drop in success rate, response timeout, service unavailability, etc.) or its performance deteriorates significantly, the unified payment gateway can automatically and quickly route subsequent payment requests to a pre-determined backup payment channel in good condition based on the health assessment system, without requiring any user action or awareness of the switching process.

[0073] Through the aforementioned technical solution, a time-series assessment system for the health of payment channels is established on the unified payment gateway. Key indicators such as success rate, response latency, and fee rates for each channel are collected in real time. The system can dynamically and intelligently evaluate and select the optimal payment channel. When the primary channel fails or its performance degrades, it can seamlessly switch to a backup channel, effectively avoiding payment interruptions or delays caused by problems with a single payment channel. This mechanism significantly improves the transaction stability, reliability, and user experience in campus bulk payment scenarios, reduces operational risks and maintenance costs, and ensures the smooth operation of the payment process.

[0074] In some of the aforementioned implementations, the reconciliation engine can periodically retrieve payment channel settlement files and automatically compare and match them with paid transaction records to generate reconciliation reports. However, in actual operation, anomalies often occur where payment transaction records and settlement files fail to match. If these abnormal transaction records are simply recorded, subsequent discrepancy analysis, cause identification, and processing will heavily rely on manual intervention. This is not only inefficient and prone to errors, but also fails to meet the automation and high reliability requirements of a smart campus payment system.

[0075] To address this, this embodiment further proposes that the reconciliation engine adopts a multi-dimensional difference attribution algorithm to automatically locate the difference type for abnormal transactions that fail to match, and trigger automated cross-source secondary verification. Data that is still abnormal after verification automatically generates a financial processing work order, forming a fully automated processing link of reconciliation-location-verification-closed loop.

[0076] Specifically, the reconciliation engine is the core module responsible for comparing payment records with settlement documents. To handle anomalies during the comparison process more efficiently, this embodiment introduces a multi-dimensional discrepancy attribution algorithm. This algorithm aims to intelligently identify and classify the specific reasons for mismatches between payment records and settlement documents by analyzing multiple data dimensions such as transaction amount, transaction time, transaction type, payment channel, order number, and user identification. For example, the algorithm can determine whether the discrepancy is due to "amount discrepancy," "one-sided accounting" (i.e., one party has a record while the other does not), "inconsistent transaction status," or "fee discrepancy," based on a preset rule set or machine learning model. In this way, the system can automatically locate the type of discrepancy, avoiding the tedious and inefficient manual investigation.

[0077] After automatically identifying the type of discrepancy, the system triggers automated cross-source secondary verification. This means that, based on the initially identified discrepancy type, the reconciliation engine will automatically initiate query requests to relevant external systems (such as payment channel APIs, bank reconciliation systems, and campus order management or refund systems) to obtain more detailed transaction records or status information. For example, if the discrepancy type is identified as "one-sided transaction (existing in the system, but not in the payment channel)," the system may automatically query the transaction details of the payment channel to confirm whether the transaction did not actually reach the payment channel or was rejected by the payment channel. This cross-source verification mechanism provides more comprehensive evidence, significantly improving the accuracy and reliability of anomaly detection.

[0078] After automated cross-source secondary verification is completed, if discrepancies still exist and cannot be automatically corrected by the system (e.g., requiring manual judgment or coordination with a third party), the system will automatically generate a financial processing work order based on a preset work order template. This work order will include details of the abnormal transaction, the type of discrepancy, and the verification result. These work orders will be automatically assigned to the relevant financial personnel for further processing, ensuring that all anomalies are promptly and systematically transferred to the manual processing flow. In this way, this embodiment forms a complete automated closed loop from anomaly detection, cause location, verification confirmation to final processing, greatly improving the automation level of reconciliation and the efficiency of anomaly handling in the smart campus payment system.

[0079] By introducing a multi-dimensional discrepancy attribution algorithm, this embodiment can perform refined analysis of anomalies where payment records and settlement documents fail to match, automatically identifying and locating the specific types of discrepancies, thus avoiding the tedious and inefficient manual investigation. Furthermore, the automated cross-source secondary verification mechanism can proactively query relevant systems based on the identified discrepancy types to obtain more comprehensive information for cross-verification, significantly improving the accuracy and reliability of anomaly detection. For anomalies that cannot be resolved after automated verification, the system can automatically generate financial processing work orders, ensuring that all anomalies are promptly and systematically transferred to manual processing, forming a complete automated closed loop from anomaly detection, cause location, verification confirmation to final processing. This greatly improves the automation level and anomaly handling efficiency of the smart campus payment system, reduces the cost and error rate of manual operations, ensures the accuracy and security of fund flows, and provides solid technical support for campus financial management.

[0080] The aforementioned smart campus payment processing methods primarily focus on bill generation, payment, and reconciliation, constructing an efficient payment chain. However, in actual operation, refund scenarios are unavoidable. Without a rigorous, secure, and traceable refund mechanism, irregular refund operations may occur, fund flows may be unclear, and data tampering risks may arise, thereby affecting financial compliance and user trust.

[0081] To address this, this embodiment further proposes a closed-loop refund process to ensure the standardization and security of refund operations. Specifically, when the finance department initiates a refund instruction, the system first performs a reverse compliance check on the payment terms of the original order. This check aims to perform a reverse compliance check based on the payment terms of the original order, such as payment deadlines and additional business requirements, to ensure that the refund operation complies with preset business rules and financial policies, preventing non-compliant refunds from occurring. For example, the system will check whether the time window stipulated by the refund policy has been met, whether the relevant services have been completed, or whether there are any outstanding fees.

[0082] Once verification is successful, the system will match the original payment channel to process the refund. This is to ensure the accuracy and consistency of fund flows. The system will intelligently identify and match the payment channel used when the original order was paid, and then return the funds to the user's original payment account through that channel, avoiding the complexity and risks that may arise from cross-channel refunds.

[0083] To further ensure data security and privacy, the entire refund process is stored using homomorphic encryption. Homomorphic encryption technology allows computations to be performed on encrypted data without decryption. This means that sensitive information such as refund amount, refund time, and refund account are encrypted during storage. Even if the data is illegally obtained, its plaintext content cannot be directly read, thus greatly enhancing data privacy and security. At the same time, the system can still perform necessary statistics and analysis on the transaction data while it is encrypted.

[0084] Furthermore, while refund transaction data is stored encrypted, it is linked to invoices and payment logs to form an immutable, end-to-end traceability chain of funds. This linkage is achieved through encrypted hashes, timestamps, or blockchain technology, ensuring that once data is recorded, any modification will result in a break in the data chain or a hash value mismatch, thus creating a complete, transparent, and tamper-proof record of fund flows from invoice generation, payment, refund to reconciliation. This provides a reliable basis for subsequent auditing, dispute resolution, and risk control.

[0085] Through the above technical solution, this embodiment introduces a comprehensive closed-loop refund process into the smart campus payment processing method, effectively solving the problems of standardization, security, and traceability in refund operations. Before executing a refund instruction initiated by the finance department, the system strictly performs reverse compliance verification of payment conditions to ensure that the refund behavior complies with established rules and avoids non-compliant refunds. After verification, the system automatically matches the original payment channel for refund, ensuring the accuracy and consistency of fund flow. Furthermore, the entire refund process is stored using homomorphic encryption, which, while protecting data privacy and security, allows data processing in an encrypted state, effectively preventing the risk of sensitive information leakage. At the same time, by linking the refund process with the original bills and payment logs, an immutable full-link traceability chain of funds is constructed, providing a solid data foundation for financial auditing, risk control, and dispute resolution, significantly improving the transparency, security, and compliance of the entire payment system, and ensuring the rigor of campus fund management.

[0086] Furthermore, this embodiment also includes a closed-loop refund process. When the finance department initiates a refund instruction, the system first performs a reverse compliance check on the payment conditions of the original order. After the verification is successful, the refund is executed by matching the original payment channel. The entire refund process is stored using homomorphic encryption and is linked with invoices and payment logs to form an immutable, end-to-end traceability chain for funds, ensuring the transparency and auditability of the refund operation.

[0087] Through the above technical solutions, schools can overcome the inefficiency and risks of traditional manual operations, achieving automation, intelligence, and security in the payment process. Compared with existing technologies, this embodiment introduces secondary processing of permissions and data rules engines and blockchain notarization in the bill generation stage, significantly improving the accuracy, security, and immutability of bills; in the bill distribution stage, the use of national cryptographically encrypted identity authentication identifiers and a zero-trust directed routing distribution mechanism effectively prevents unauthorized access and data tampering; in terms of payment reminders, the edge computing pre-loading notification strategy achieves millisecond-level push notifications and tiered reminders, greatly improving payment efficiency; in the payment process, the unified payment gateway's channel health assessment and the risk control model of the core verification module ensure the stability and security of transactions; in the reconciliation process, multi-dimensional difference attribution algorithms and automated cross-source verification completely solve the pain points of traditional manual reconciliation, achieving automation and accuracy in reconciliation; and the homomorphic encrypted storage and full-link traceability of the refund closed-loop process further enhance the transparency and security of fund flows. These technological features work together to build an efficient, secure, and transparent smart campus payment processing system.

[0088] Furthermore, embodiments of this application also propose a computer-readable storage medium storing a program for smart campus payment processing. When the program for smart campus payment processing is executed by a processor, it implements the steps of the smart campus payment processing method described above.

[0089] Reference Figure 3 , Figure 3 This is a structural block diagram of the first embodiment of the smart campus payment processing system of this application.

[0090] like Figure 3 As shown in the embodiments of this application, the smart campus payment processing system includes: The bill configuration module 10 is used to configure the charging rules on the financial side. After authentication by the permission and data rule engine, it performs secondary processing to generate a bill to be paid with payment conditions and write it to the core database. The payment conditions include payment channel, payment time limit and additional business requirements. The bill generation event is published to the message queue, and the event is accompanied by an identity authentication identifier. The bill synchronization module 20 is used to listen to the bill generation event in the message queue, determine the target sending end based on the identity authentication identifier, and synchronize the bill data to the corresponding teacher's end or parent's end; generate a notification strategy in the preset reminder database according to the payment conditions, and push payment reminders according to the notification strategy; The payment module 30 is used by parents to initiate payment requests, which are then dispatched to the matching payment channel through the unified payment gateway to complete the payment. The payment channel then sends back the payment result, and the core verification module verifies the consistency between the payment information and the bill data and payment conditions. Synchronization module 40 is used to update the bill status to paid, write the payment record and publish the payment success event after the verification is passed, and synchronously update the payment status on the teacher's side and the finance side. The reconciliation module 50 is used by the reconciliation engine to periodically pull settlement files from payment channels, automatically compare and match them with the paid transaction records, and generate reconciliation reports.

[0091] It should be understood that the above are merely illustrative examples and do not constitute any limitation on the technical solution of this application. In specific applications, those skilled in the art can make settings as needed, and this application does not impose any restrictions on this.

[0092] This embodiment generates bills and publishes events by configuring charging rules on the financial side, synchronizes data and pushes reminders through the message queue, and completes the payment by the unified gateway and verification by the core module. After verification, the status is updated and the accounts are automatically reconciled. This solves the problems of inefficiency, high error rate, data synchronization delay and security risks in campus payment management. It has the advantages of automating the campus payment process, significantly improving operational efficiency, reducing human error, and ensuring real-time data synchronization and payment security.

[0093] It should be noted that the workflow described above is merely illustrative and does not limit the scope of protection of this application. In practical applications, those skilled in the art can select some or all of it to achieve the purpose of this embodiment according to actual needs, and no restrictions are imposed here.

[0094] In addition, for technical details not described in detail in this embodiment, please refer to the smart campus payment processing method provided in any embodiment of this application, which will not be repeated here.

[0095] Furthermore, it should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0096] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0097] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory (ROM) / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application. The above are only preferred embodiments of this application and do not limit the patent scope of this application. All equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A smart campus payment processing method, characterized in that, include: The financial side configures the charging rules, which are then processed a second time after authentication by the permission and data rule engine. This generates a bill to be paid with payment conditions and writes it to the core database. The payment conditions include the payment channel, payment deadline, and additional business requirements. The bill generation event is published to the message queue, and the event is accompanied by an identity authentication identifier. The message queue listens for the bill generation event, determines the target sending end based on the identity authentication identifier, and synchronizes the bill data to the corresponding teacher's or parent's end; it generates a notification strategy in the preset reminder database according to the payment conditions, and pushes payment reminders according to the notification strategy; Parents initiate a payment request, which is then routed to a matching payment channel via the unified payment gateway to complete the payment. The payment channel then sends a callback with the payment result, and the core verification module verifies the consistency between the payment information and the billing data and payment terms. After verification, update the bill status to "paid", write the payment record and publish the payment success event, and update the payment status on both the teacher's and finance sides simultaneously; The reconciliation engine periodically retrieves settlement files from payment channels, automatically compares and matches them with the already paid transaction records, and generates reconciliation reports.

2. The method according to claim 1, characterized in that, The charging rules are subjected to a structured secondary parsing specific to the education scenario. Payment conditions are bound to bill ID, student ID, and class ID with a time-series unique index, and the core bill data is stored on the blockchain. The identity authentication identifier is generated using a three-level national cryptographic encryption of role-institution-student, and only terminals matching the encrypted identifier are allowed to receive bill data, preventing unauthorized access and data tampering.

3. The method according to claim 1, characterized in that, A zero-trust targeted routing and distribution mechanism is built based on identity authentication identifiers. First, the identity of the target terminal is verified twice to ensure its legality before the bill data is synchronized. At the same time, combined with payment conditions and parents' terminal usage habits, a notification strategy is preloaded through edge computing to achieve millisecond-level payment reminder push in low-bandwidth campus networks, and a tiered reminder strategy is automatically generated for overdue bills.

4. The method according to claim 1, characterized in that, The core verification module constructs a risk control model for campus payment behavior. Based on the payment condition fulfillment verification, it adds multi-dimensional verification of payment environment, transaction frequency, and terminal device fingerprint. It directly blocks payment requests initiated beyond the time limit, through non-designated channels, or from abnormal devices, and generates risk warning logs simultaneously.

5. The method according to claim 1, characterized in that, The unified payment gateway establishes a time-series evaluation system for the health of payment channels, which collects the success rate, response latency, and fee rate indicators of each channel in real time. It dynamically selects the optimal channel based on the bill payment conditions and seamlessly switches to the backup channel when the main channel fails, ensuring the transaction stability of campus batch payment scenarios.

6. The method according to claim 1, characterized in that, The reconciliation engine uses a multi-dimensional discrepancy attribution algorithm to automatically locate the discrepancy type for abnormal transactions that fail to match, and triggers automated cross-source secondary verification. Data that is still abnormal after verification automatically generates a financial processing work order, forming a fully automated processing link of reconciliation-location-verification-closed loop.

7. The method according to claim 1, characterized in that, It also includes a closed-loop refund process: when the finance department initiates a refund instruction, the system first performs a reverse compliance check on the payment conditions of the original order. After the verification is passed, the system matches the original payment channel to execute the refund. The entire refund process is stored using homomorphic encryption and is linked with bills and payment logs to form an immutable full-chain traceability chain for funds.

8. A smart campus payment processing system, characterized in that, include: The bill configuration module is used by the finance department to configure the charging rules. After authentication by the permission and data rule engine, it performs secondary processing to generate a bill to be paid with payment conditions and write it to the core database. The payment conditions include the payment channel, payment deadline and additional business requirements. The bill generation event is published to the message queue, and the event is accompanied by an identity authentication identifier. The bill synchronization module is used to listen for the bill generation event in the message queue, determine the target sending end based on the identity authentication identifier, and synchronize the bill data to the corresponding teacher's or parent's end; generate a notification strategy in the preset reminder database according to the payment conditions, and push payment reminders according to the notification strategy; The payment module is used by parents to initiate payment requests, which are then dispatched to the matching payment channel through the unified payment gateway to complete the payment. The payment channel then sends back the payment result, and the core verification module verifies the consistency between the payment information and the billing data and payment conditions. The synchronization module is used to update the bill status to "paid" after verification, write the payment record and publish the payment success event, and synchronize the payment status between the teacher's side and the finance side. The reconciliation module is used by the reconciliation engine to periodically retrieve payment channel settlement files, automatically compare and match them with the paid transaction records, and generate reconciliation reports.

9. A computer device, characterized in that, The device includes a memory and a processor, wherein the processor, when executing computer instructions stored in the memory, performs the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Includes instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 7.

Images