Revenue sharing payment method and device, electronic device and storage medium

Abstract

This application relates to the fields of computer and financial services technology, and in particular to a method, apparatus, electronic device, and storage medium for split payment. The method includes: upon receiving a transaction event to be split, transferring balances from the target enterprise's target virtual ledger to a first virtual sub-account, a second virtual sub-account, and a third virtual sub-account according to preset split rules, while simultaneously recording corresponding tax attribute information; then, based on the real-time health indicators of each payment channel for the target user, determining the optimal payment channel, and transferring balances to the target user based on the optimal payment channel. This solves problems such as reliance on manual splitting, susceptibility to failure due to single payment channels, and disconnect between cash flow and tax flow. By constructing a regulatory entity account + N-level virtual ledger system, it achieves the technical effects of automated multi-level splitting, high payment availability, and integrated tax compliance.

Description

Technical Field

[0001] This application relates to the fields of computer and financial services technology, and in particular to a split payment method, apparatus, electronic device and storage medium. Background Technology

[0002] With the popularization of flexible employment models, the frequency of cooperation between enterprises and temporary workers has increased significantly. The payroll scenario is characterized by "high frequency, multiple roles, and high compliance requirements". Under this model, employment settlement involves four parties: enterprises, intermediary service platforms, human resources service providers, and C-end users. The flow of funds needs to meet multiple requirements such as service fee splitting, individual income tax declaration, and invoice issuance.

[0003] In related technologies, most rely on a combination of manual and single-channel batch payment solutions, which have the following problems: (1) Low settlement efficiency: Funds need to be transferred manually at each level, the process is lengthy and prone to errors; (2) Single payment channel: Only bank card payment is supported, and it is easy to fail due to bank interface flow restriction during peak payday periods; (3) High tax compliance risk: Service fees, individual income tax, net income, etc. cannot be split and bound to invoice information at the same time when funds are transferred, resulting in the disconnect between "fund flow" and "invoice flow"; (4) Lack of fault tolerance mechanism: The failure of a single payment channel will cause the overall payment to be interrupted, affecting the user experience, which needs to be solved urgently. Summary of the Invention

[0004] This application provides a method, device, electronic device, and storage medium for split payment to solve problems such as reliance on manual processing for multi-party split payments, easy failure of single payment channels, and disconnect between cash flow and tax flow.

[0005] The first aspect of this application provides a method for split payment, comprising the following steps: determining whether a pending split transaction event has been received; if the pending split transaction event is received, then according to preset split rules, transferring balances from the target virtual ledger of the target enterprise to the first virtual sub-account, the second virtual sub-account, and the third virtual sub-account respectively, and simultaneously recording the corresponding tax attribute information; based on the real-time health index of each payment channel of the target user, determining the optimal payment channel from each payment channel, and transferring balances to the target user based on the optimal payment channel.

[0006] Preferably, before determining whether a pending revenue sharing event has been received, the method further includes: obtaining the registration information of the target enterprise, the qualification to use the target platform within the target enterprise, the agreement information of the target service provider within the target enterprise, and the identity information of the target user within the target enterprise; constructing a target virtual account and a target virtual ledger for the target enterprise based on the registration information of the target enterprise; constructing a first virtual sub-account for the target platform based on the qualification to use the target platform; constructing a second virtual sub-account for the target service provider based on the agreement information of the target service provider; and constructing a third virtual sub-account for the target user based on the identity information of the target user; wherein the virtual account, the first virtual sub-account, the second virtual sub-account, and the third virtual sub-account are all associated with the same regulatory entity account, and a dedicated fund partition, a target platform service fee partition, a target service provider fund partition, and a target user fund partition are respectively allocated in the regulatory entity account.

[0007] Preferably, after constructing the target virtual account, the first virtual sub-account, the second virtual sub-account, and the third virtual sub-account, the method further includes: setting preset revenue sharing rules based on the enterprise dimension of the target enterprise, the order type of the target enterprise, and the cooperation mode of the target enterprise, and obtaining the first revenue sharing ratio of the target platform, the second revenue sharing ratio of the target service provider, and the third revenue sharing ratio of the target user according to the preset revenue sharing rules.

[0008] Preferably, the step of transferring balances from the target virtual ledger of the target enterprise to the first virtual sub-account, the second virtual sub-account, and the third virtual sub-account according to the preset revenue sharing rules includes: calculating the platform service amount of the target platform, the service provider service amount of the target service provider, the tax amount due to the target user, and the actual income amount of the target user based on the preset revenue sharing rules; deducting the total amount due for revenue sharing from the target virtual accounts, and adding the platform service amount to the first virtual sub-account, the service provider service amount and the tax amount due to the second virtual sub-account, and adding the actual income amount of the target user to the third virtual sub-account.

[0009] Preferably, determining the optimal payment channel from each payment channel based on the real-time health index of each payment channel for the target user includes: collecting the real-time health index of each payment channel, wherein the real-time health index includes at least one of payment channel load, payment channel fee rate, average response latency, transaction success rate, and circuit breaker status; calculating the comprehensive score of each payment channel based on the real-time health index using a target weighted scoring model according to the multiple payment channels pre-bound by the target user; and determining the optimal payment channel among each payment channel for the target user based on the comprehensive score.

[0010] Preferably, after transferring the balance to the target user based on the optimal payment channel, the method further includes: receiving a split notification returned by the optimal payment channel, updating the target user's third virtual sub-account according to the split notification, and generating a split voucher.

[0011] A second aspect of this application provides a payment splitting device, comprising: a judgment module for judging whether a pending payment splitting event has been received; a splitting module for, if the pending payment splitting event is received, transferring the balance from the target enterprise's target virtual ledger to a first virtual sub-account, a second virtual sub-account, and a third virtual sub-account respectively according to preset splitting rules, and simultaneously recording the corresponding tax attribute information; and a determination module for determining the optimal payment channel from each payment channel based on the real-time health index of each payment channel of the target user, so as to transfer the balance to the target user based on the optimal payment channel.

[0012] Preferably, before determining whether a pending revenue sharing event has been received, the determination module is further configured to: obtain the registration information of the target enterprise, the usage qualification of the target platform within the target enterprise, the target service provider agreement information within the target enterprise, and the identity information of the target user within the target enterprise; construct a target virtual account and a target virtual ledger for the target enterprise based on the registration information of the target enterprise; construct a first virtual sub-account for the target platform based on the usage qualification of the target platform; construct a second virtual sub-account for the target service provider based on the target service provider agreement information; and construct a third virtual sub-account for the target user based on the identity information of the target user; wherein the virtual account, the first virtual sub-account, the second virtual sub-account, and the third virtual sub-account are all associated with the same regulatory entity account, and a dedicated fund partition, a target platform service fee partition, a target service provider fund partition, and a target user fund partition are respectively allocated in the regulatory entity account.

[0013] Preferably, after constructing the target virtual account, the first virtual sub-account, the second virtual sub-account, and the third virtual sub-account, the judgment module is further configured to: set a preset revenue sharing rule based on the enterprise dimension of the target enterprise, the order type of the target enterprise, and the cooperation mode of the target enterprise, and obtain the first revenue sharing ratio of the target platform, the second revenue sharing ratio of the target service provider, and the third revenue sharing ratio of the target user according to the preset revenue sharing rule.

[0014] Preferably, the revenue sharing module is specifically used for: calculating the platform service amount of the target platform, the service provider service amount of the target service provider, the tax amount to be paid by the target user, and the actual income amount of the target user based on the preset revenue sharing rules; deducting the total amount to be shared from the target virtual account, and adding the platform service amount to the first virtual sub-account, the service provider service amount and the tax amount to be paid to the second virtual sub-account, and the actual income amount of the target user to the third virtual sub-account.

[0015] Preferably, the determining module is specifically used for: collecting real-time health indicators for each payment channel, wherein the real-time health indicators include at least one of payment channel load, payment channel fee rate, average response latency, transaction success rate, and circuit breaker status; calculating a comprehensive score for each payment channel based on the real-time health indicators and using a target weighted scoring model, according to the multiple payment channels pre-bound by the target user; and determining the optimal payment channel among the target user's payment channels based on the comprehensive score.

[0016] Preferably, after transferring the balance to the target user based on the optimal payment channel, the determining module is further configured to: receive the split notification returned by the optimal payment channel, update the target user's third virtual sub-account according to the split notification, and generate a split voucher.

[0017] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the revenue-sharing payment method as described in the above embodiments.

[0018] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the revenue-sharing payment method as described in the above embodiments.

[0019] Therefore, this application has at least the following beneficial effects: By constructing a fund management architecture of "one regulatory entity account + multi-level virtual ledger", combined with an event-driven automatic revenue sharing engine and intelligent multi-channel payment gateway, the system effectively solves problems such as cumbersome settlement processes, error-prone manual reconciliation, low payment success rate and high tax compliance risks in flexible employment scenarios. It not only achieves second-level automation of fund splitting among enterprises, platforms, human resource service providers and freelancers, but also ensures the atomicity of the revenue sharing process and data consistency, thereby improving settlement efficiency, system reliability and tax compliance.

[0020] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0021] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a diagram illustrating the revenue-sharing payment method for related technologies. Figure 2 This is a flowchart illustrating a revenue-sharing payment method according to an embodiment of this application. Figure 3 This is a schematic diagram of the overall process of split payment according to an embodiment of this application; Figure 4 This is an example diagram of a split payment device according to an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application.

[0022] Explanation of the attached diagram labels: 100 - Judgment module; 200 - Revenue sharing module; 300 - Confirmation module. Detailed Implementation

[0023] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0024] Specifically, before introducing the application process for resignation, let's first explain the revenue-sharing payment logic of the relevant technologies, such as... Figure 1As shown, the revenue-sharing payment logic of the relevant technology is as follows: First, the company transfers the full amount of payroll funds to the physical bank account of the cooperating HR service provider or platform; second, the finance personnel compile information such as the employee list and payroll amount into a standardized Excel spreadsheet; finally, they log into the bank's batch payment system, manually upload the spreadsheet, and initiate a transfer instruction, relying on the bank interface to complete the fund disbursement. It can be seen that the core of the above solution relies on manual operation and a single bank channel, which is a common choice for flexible employment and payroll payment for SMEs. However, it does not address the core needs of multi-role revenue sharing and compliant synchronization, thus presenting the following problems: (1) Low reconciliation efficiency and high error rate: Since the splitting of funds (platform fee, service fee, salary) relies on manual calculation and secondary transfer, errors in amount statistics and personnel information matching are likely to occur during manual operation. A lot of time needs to be invested in verifying the flow of funds, resulting in high reconciliation costs. (2) Poor payment stability and low fault tolerance: Only a single bank payment channel is bound. During the peak period of salary payment, the bank interface is prone to congestion due to concurrent pressure, or suspension of service due to interface maintenance and risk control restrictions. The system has no backup alternative, which directly leads to the failure of the entire salary payment. (3) Long settlement cycle and high compliance risk: Funds must first be deposited into the service provider's account before the salary payment process can be started. The flow of funds and the business flow (task delivery, review) are completely disconnected, resulting in settlement delays. At the same time, manual recording of invoice transfer nodes is prone to omissions, and it is impossible to achieve synchronization of "fund flow-information flow-invoice flow", which poses a tax compliance risk.

[0025] Based on the aforementioned problems, this application provides a payroll payment method that can automatically process multi-level fund clearing, support automatic switching of payment channels, and handle high concurrency.

[0026] The following description, with reference to the accompanying drawings, details a method, apparatus, vehicle, and storage medium for detecting labeled data samples according to embodiments of this application. Specifically, Figure 1 This is a schematic flowchart of a revenue-sharing payment method provided in an embodiment of this application.

[0027] like Figure 2 As shown, this revenue-sharing payment method includes the following steps: In step S201, it is determined whether a pending revenue sharing event has been received.

[0028] Preferably, before determining whether a revenue-sharing event has been received, the method further includes: obtaining the target company's registration information, the target platform's usage qualifications within the target company, the target service provider's agreement information within the target company, and the target user's identity information within the target company; constructing a target virtual account and a target virtual ledger for the target company based on the target company's registration information; constructing a first virtual sub-account for the target platform based on the target platform's usage qualifications; constructing a second virtual sub-account for the target service provider based on the target service provider's agreement information; and constructing a third virtual sub-account for the target user based on the target user's identity information. The virtual accounts, the first virtual sub-account, the second virtual sub-account, and the third virtual sub-account are all associated with the same regulatory entity account, and a dedicated fund partition, a target platform service fee partition, a target service provider fund partition, and a target user fund partition are respectively allocated within the regulatory entity account.

[0029] Specifically, based on the problems existing in related technologies, the core of this application lies in designing a virtual ledger core engine, developing a multi-channel payment adaptation layer, constructing a split account rule configuration system and state triggering mechanism, and developing an exception handling and reconciliation module.

[0030] The core functionality of the virtual ledger engine is designed to support multiple account types, such as balance management, freezing / unfreezing, and internal transfers for enterprises, platforms, service providers, and users, without relying on real-time physical fund flows. The mapping rule adopts a one-to-one binding model of "1 physical supervisory account + N virtual sub-accounts." The physical supervisory account is linked to a bank or third-party payment reserve account, and the virtual sub-account balance is synchronized to the corresponding partition of the physical account in real time, ensuring complete equivalence between virtual balances and physical funds. Fund accumulation is mainly reflected in the fact that all virtual sub-account transfers only change the balance allocation. The system ensures that the funds remain in the entity's supervisory account at all times, and are only transferred to the user's entity account at the final payment stage. Supervision follows the payment regulations of the relevant field. The system can automatically record the operation logs of each virtual sub-account, including the transfer entity, amount, time, and associated order number. The logs are retained for no less than 5 years, supporting traceability and verification by regulatory authorities. Consistency is guaranteed by adopting a two-stage mechanism of "pre-deduction + confirmation" in multi-level transfer scenarios. In asynchronous payment scenarios, a transaction log rollback mechanism is introduced. If the payment fails, the balance of the virtual sub-account is automatically rolled back to the original account, avoiding discrepancies between the actual funds and the records.

[0031] The core function of developing a multi-channel payment adaptation layer is to encapsulate and ensure compatibility with various payment channels, such as Alipay, WeChat Pay, and direct connections between multiple banks and enterprises, and to unify payment instruction formats and response callback standards. Specifically, the adaptation layer includes built-in interface adaptation templates that support dynamically adding new payment channels (without modifying the core code), encapsulate the differences in interfaces between different channels (such as parameter formats, signature rules, and timeout thresholds), and provide unified APIs (Application Programming Interfaces) for "Initiate Payment," "Query Status," and "Receive Callback," ensuring decoupling between upper-layer business modules and specific payment channels.

[0032] The core function of building a revenue sharing rule configuration system and status triggering mechanism is to realize the automatic linkage between the revenue sharing process and business status (delivery confirmation, approval), and support the custom configuration of revenue sharing ratios. Specifically, the rule configuration system provides a visual interface, which supports setting differentiated revenue sharing rules by "enterprise dimension", "order type" and "cooperation mode" (e.g., 5% platform service fee for enterprise A, 8% for enterprise B). The rules are stored in a versioned manner, and changes take effect automatically and historical versions are retained for retrospection. The status triggering mechanism is implemented by listening to WebHook events in the order system. When events such as "task delivery qualified" or "compliance review approved" are received, the corresponding revenue sharing rule is automatically matched and the transfer process is triggered, with a trigger delay of ≤1 second.

[0033] The core function of the anomaly handling and reconciliation module is to ensure system stability and data consistency, covering scenarios such as payment anomalies, account splitting anomalies, and reconciliation discrepancies. Anomaly handling includes initiating a "channel retry + fund rollback" process when payment anomalies occur, supporting up to 3 backup channel switches. If the retry fails, the virtual account funds are automatically rolled back to the initiating account, and an SMS / email alarm is triggered. When account splitting anomalies occur (such as missing rules or frozen accounts), the transfer operation is suspended, an anomaly work order is generated and pushed to the operations backend, and the account splitting can be manually triggered after manual handling. The reconciliation mechanism adopts a "three-party reconciliation" mode, automatically synchronizing the system's internal accounting records, third-party payment channel records, and bank supervision account records every day at midnight. Through three-dimensional verification of "order number + amount + timestamp", it identifies discrepancies in the transactions (such as omissions or errors), generates a reconciliation discrepancy report and marks the reasons for the discrepancies, and supports automatic correction (such as accounting omissions caused by missed channel callbacks) or manual intervention correction, thereby ensuring system stability and data consistency.

[0034] The key challenge of this application lies in ensuring data consistency across multiple account splitting and in the dynamic monitoring and intelligent switching of payment channels. Ensuring data consistency across multiple account splitting requires ensuring that "deducting the balance of the superior account" and "increasing the balance of the subordinate account" are executed atomically to avoid fund anomalies. Dynamic monitoring and intelligent switching of payment channels requires real-time acquisition of the load, rate, and availability status of each channel to quickly determine the optimal channel.

[0035] Specifically, the technical means to ensure data consistency in multi-level revenue sharing mainly include: distributed transaction locking mechanism, two-phase commit + transaction log, and real-time consistency verification. The distributed transaction locking mechanism uses Redis distributed locks, which automatically lock the involved upper-level virtual accounts (such as enterprise accounts) and all lower-level accounts (such as platform, service provider, and user accounts) when revenue sharing is triggered. During the locking period, other revenue sharing operations are prohibited from intervening, ensuring atomic execution of the entire "deduction-transfer" process and avoiding funding gaps or duplicate payments caused by partial success or failure of some operations. The two-phase commit + transaction log revenue sharing process... The system consists of two phases: "pre-deduction" and "confirmation of receipt." In the first phase, only the corresponding amount in the superior account is frozen and the transaction log is recorded (including account, amount, timestamp, and order number). In the second phase, the funds are transferred to the subordinate account simultaneously. If the second phase fails, the system automatically performs a rollback operation based on the transaction log, restoring the frozen funds to the superior account. Real-time consistency verification aims to compare the "deduction amount in the superior account" with the "total amount received by all subordinate accounts" in real time after the accounting is completed. If a discrepancy occurs (such as data synchronization deviation caused by network latency), an alarm is immediately triggered and automatic reconciliation and repair are initiated to ensure the total amount of funds is kept constant.

[0036] The technical means for dynamic monitoring and intelligent switching of payment channels mainly include: real-time channel status monitoring, multi-dimensional data collection and synchronization, intelligent routing decision algorithms, and circuit breaker and degradation mechanisms. Real-time channel status monitoring primarily uses a dual mechanism of "timed probes + interface heartbeat detection" to obtain channel status. Timed probes (e.g., every 5 seconds) call the status query interface of each payment channel to collect load rate (current concurrency / maximum concurrent capacity), response time, and available credit. Interface heartbeat detection (e.g., every 1 second) verifies channel connectivity by sending empty requests; if three consecutive heartbeats fail, the channel is marked as "abnormal." Multi-dimensional data collection and synchronization captures in real-time dynamic rates (e.g., temporarily adjusted large-amount transfer discount rates by banks), limit rules (single transaction / daily limit), risk control interception rates, etc., for each channel. Data is stored in a distributed cache (e.g., Redis) to provide real-time data support for decision-making; the intelligent routing decision algorithm has a built-in dual-objective routing model of "priority + cost optimization", with priority weights configured as "stability (availability status, response time) > cost (rate) > speed (payment timeliness)"; a comprehensive score for each channel is calculated through weighted calculation, and the optimal channel is selected in milliseconds; if the optimal channel exceeds the load threshold (e.g., 80%) or is in an abnormal state, it is automatically switched to a backup channel according to the score, with a switching response time of ≤100 milliseconds; the circuit breaker and degradation mechanism is mainly for channels with a consecutive failure number exceeding the threshold (e.g., 3 payment failures in a single channel), which automatically triggers the circuit breaker (e.g., calls are prohibited for 10 minutes), during which all payment requests are routed to other available channels to avoid efficiency loss caused by invalid retries.

[0037] Furthermore, the main system modules involved in this application include a corporate recharge and fund locking module, a revenue sharing rule management module, an intelligent revenue sharing execution module, a multi-channel payment gateway module, and a compliance and reconciliation module. The modules collaborate with each other through data interfaces and event triggering mechanisms.

[0038] Specifically, the core function of the enterprise recharge and fund locking module is to connect with enterprise payment accounts, such as online banking, Alipay, and WeChat Pay, to receive recharge funds and convert them into virtual ledger balances. It dynamically marks "available / frozen" attributes based on business status to ensure funds are used for their designated purpose. Specific details (the mapping relationship between business status and attributes) mainly include mapping rules and status synchronization. The mapping rules use a three-dimensional mapping table of "business scenario - status code - account attribute" to clarify the fund attributes at different stages. This mainly includes the following four scenarios: Scenario 1: The enterprise initiates a recharge but has not associated it with a task order; status code "pending association" - account attribute "frozen" (…). Funds can only be used to unlock orders after binding); Scenario 2: Funds are associated with an order but the task is not completed, status code "Task in progress" - account attribute "Frozen" (to prevent misappropriation to other orders); Scenario 3: The enterprise confirms "Task delivery qualified", status code "Delivery passed" - account attribute "Available" (allows triggering first-level revenue sharing); Scenario 4: Order canceled / task fails review, status code "Order terminated" - account attribute "Frozen - Pending refund" (triggers fund refund to the enterprise account via the original payment method); The status synchronization module listens for status change events in the order system in real time, and automatically updates fund attributes after receiving status code pushes, with a synchronization delay of ≤500 milliseconds.

[0039] The core function of the revenue sharing rules management module is to provide a visual configuration interface (supporting drag-and-drop rule combinations), allowing enterprises, platforms, and service providers to customize revenue sharing ratios according to business needs. Rule storage adopts version-based management and is synchronized to the revenue sharing execution module in real time. Specific details include that rule configuration supports multi-dimensional condition matching (such as enterprise type, order amount range, employment scenario), and priority can be set (order-specific rules > enterprise-customized rules > system default rules) to meet diverse revenue sharing needs.

[0040] The core function of the intelligent revenue sharing execution module is to monitor business order status change events, accurately invoke revenue sharing rules, and automatically complete fund transfers between virtual accounts through a distributed transaction mechanism. Specific details include the status change determination method, a detailed explanation of the revenue sharing rules, and guarantees of revenue sharing accuracy. The status change determination method uses a dual mechanism of "active triggering + passive callback" to confirm status changes, ensuring no omissions. Active triggering: Enterprises, platforms, and service providers directly generate status change instructions and push them to the module through system interface operations (such as clicking "Confirm Delivery" or "Approval"); Passive callback: This involves integration with third-party business systems (such as enterprise ERP systems). The platform (including Enterprise Resource Planning and Task Management) receives status notifications (such as an ERP push notification of "Task Acceptance Passed") via API callbacks, automatically verifies the instruction signature, and confirms the status is effective. The revenue sharing rules employ a hierarchical + multi-dimensional rule system, clearly defining the logic for fund splitting. Basic rules: splitting according to four roles: "Enterprise - Platform - HR Service Provider - C-end User," with each level having a preset default revenue sharing ratio (customizable). It supports three splitting modes: fixed amount, percentage, and tiered rates. Extended rules: supporting differentiated configuration based on order attributes, such as "Large orders (≥50,000 RMB) receive a 1% discount on platform service fees," and "Long-term partner companies receive a 0.5% reduction in HR service fees." %"; Rule priority: Order-specific rules (highest) > Enterprise-customized rules > Scenario-wide rules > System default rules, in case of conflict, priority takes effect; Proof of revenue sharing accuracy includes pre-transfer verification: Before the transfer, verify the completeness of the revenue sharing rules (such as whether a certain role's proportion configuration is missing) and the validity of the account status (such as whether the service provider's account is normal); In-process verification: Use "total amount conservation verification" to ensure that "the amount deducted from the superior account = the sum of the amounts received by all subordinate accounts", and if the deviation exceeds 0.01 yuan, the operation will be terminated and an alarm will be triggered; And post-transfer traceability: Each revenue sharing generates a unique revenue sharing transaction number, associated with the rule ID (Identifier), order ID, and operation timestamp, supporting full-link traceability and verification.

[0041] The core function of the multi-channel payment gateway module is to integrate multiple payment channels such as bank cards, Alipay, and WeChat Pay. Through four main units—channel adaptation, status monitoring, routing decision-making, and exception handling—it achieves efficient and stable issuance of payment instructions. Specific details include the channel health detection method and its impact, the optimal channel confirmation logic, and the fault handling mechanism. The channel health detection method and its impact mechanism employs a dual-mode approach of "1-second heartbeat detection + 5-second status probe," collecting three core indicators in real time. Connectivity is demonstrated by sending empty requests to check if the channel interface is reachable; three consecutive timeouts mark it as "connectivity abnormal." Availability is demonstrated by statistically analyzing the payment success rate (threshold ≥ 99.5%) and response time (threshold ≤ 300 milliseconds) over the past minute. The impact is assessed by the health score (out of 100, with 30 points for connectivity, 40 for availability, and 30 for load rate) directly determining channel priority: a score ≥ 80 is considered a "preferred channel," 60-79 is a "usable channel," and < A score of 60 indicates a "disabled channel," which automatically enters a circuit breaker state. The optimal channel confirmation logic's decision process is as follows: first, select available channels with a health score ≥ 60, then calculate the comprehensive score of each channel, and select the channel with the highest score in milliseconds. If multiple channels have the same score, the user's frequently used payment channel (e.g., if the user's default payment is Alipay, the Alipay channel will be pushed first) will be prioritized. The fault handling mechanism mainly includes a retry strategy: after a single payment failure, it automatically switches to the second-best channel for retry, with a maximum of 3 retries (each 500 milliseconds apart). If the retry fails, a "manual intervention alarm" will be triggered. Circuit breaker mechanism: if a single channel fails 3 times consecutively or has a health score < 60, it will automatically be suspended for 10 minutes, during which time new payment requests will be prohibited. After the suspension period expires, a health re-check will be performed, and if the health score is met, the channel will be restored to availability. Funds will be returned: after a payment failure (e.g., incorrect account information, channel failure), the system will immediately trigger a virtual account fund rollback, returning the "pending payment" amount to the HR service provider's virtual ledger to avoid funds being outstanding.

[0042] The core function of the compliance and reconciliation module is to record tax-related information of fund flows, automatically generate compliance vouchers, and synchronize multi-source transactions to complete reconciliation, thereby reducing tax and financial risks. Tax attributes include: each fund flow is recorded with complete tax-related information to ensure "three flows in one." Basic attributes include tax type (value-added tax, individual income tax, etc.), tax rate (e.g., 6% VAT rate for platform service fees, 1.5% pre-collection rate for individual income tax), and tax item (service fee, labor fee). Related attributes include invoice flow node (pending invoice / invoiced / reversed), corresponding order number, and sub-account transaction number. The reconciliation mechanism employs a "dual-dimensional reconciliation + differential closed-loop processing" method. Internal reconciliation involves daily synchronization of virtual... The system verifies that "the amount of the accounting entries matches the order amount" and "the accounting roles match the business participants" by checking the transaction records (fund transfer records) and business order records (task delivery and review records). External reconciliation automatically retrieves transaction data from third-party payment channels and bank-supervised accounts every day at midnight, comparing the consistency between internal and external transaction records using a three-dimensional verification of "order number + amount + timestamp". Discrepancy handling identifies omissions, errors, and duplicate entries, generating a discrepancy report (marking the discrepancy type, amount involved, and related orders). It supports automatic correction (e.g., for missing entries due to missed channel callbacks, supplementing with external transaction records) or manual review and correction, and synchronously updates the virtual ledger and compliance records after correction.

[0043] Furthermore, the collaborative logic between the modules in this application mainly includes triggering links, data flow, and abnormal collaboration. The triggering link is manifested in the process of enterprise recharge - the enterprise recharge and fund locking module completes the fund freeze - the order status change triggers the intelligent splitting execution module - the splitting rule management module provides configuration rules - after the splitting is completed, the payment instruction is pushed to the multi-channel payment gateway module - after the payment is completed, the data is synchronized to the compliance and reconciliation module. The data flow is manifested in the synchronization of status information (such as splitting completion event, payment success event) between the modules through the event bus, and the data format is ensured to be consistent through a unified data model (order model, account model, transaction model). The abnormal collaboration is manifested in the event notification that triggers the linkage of related modules (such as the multi-channel payment gateway module switching to a backup channel, and the compliance and reconciliation module recording abnormal transactions) when an abnormality occurs in a certain module (such as payment channel failure), ensuring that the process is not interrupted and the data is not lost.

[0044] Specifically, firstly, obtain the target company's registration information, such as its business registration information, unified social credit code, and bank account authorization certificate, to complete the company's KYC (Know Your Customer) authentication; simultaneously, obtain the target platform's qualifications for use, such as the target platform's ICP (Internet Content Provider) filing information, flexible employment platform operating qualifications, and cooperation agreements with the target company, to confirm its legal status as a partner; simultaneously, obtain the target human resources service provider's agreement information, such as the target human resources service provider's human resources service license, entrusted tax collection and payment qualification documents, and tripartite service agreements with the platform / company, to ensure that it has the qualifications for individual income tax withholding and payment and invoicing; and simultaneously, obtain the target user's (i.e., freelancer's) identity information, such as the target user's real-name identity information, bank card number, or third-party payment account, and complete real-name verification and binding through the public security / UnionPay interface.

[0045] Furthermore, based on the aforementioned authentication information, the system constructs a four-level logical account structure within the unified virtual ledger system, mainly including: creating a virtual enterprise account (i.e., the target virtual account) for the target enterprise, serving as the initiator for fund collection and distribution; creating a virtual platform sub-account (i.e., the first virtual sub-account) for the target platform, used to collect platform service fees; creating a virtual HR service provider sub-account (i.e., the second virtual sub-account) for the target HR service provider, used to collect HR service fees and withhold personal income tax; and creating a virtual freelancer sub-account (i.e., the third virtual sub-account) for the target user, used to record their due net income.

[0046] It should be noted that all the aforementioned virtual accounts do not correspond to independent bank accounts, but are logically linked to the same regulatory entity account held in custody by a licensed partner bank. This regulatory entity account uses logical partitions to isolate the use of funds, mainly including a dedicated fund partition, a target platform service fee partition, a target service provider fund partition, and a target user fund partition. The dedicated fund partition stores the total funds to be settled by the target company and can only be used for the distribution of revenue in this task; the target platform service fee partition temporarily stores commissions to be transferred to the target platform and will be used for withdrawals or invoicing settlements on the target platform later; the target service provider fund partition includes human resources service fees and withheld individual income tax to ensure that tax funds are used for their designated purpose; and the target user fund partition is used to aggregate all net income to be paid to users, serving as a fund source pool for multi-channel payments.

[0047] In this system, the balances of each zone are only reflected in the virtual ledger, while the real funds are always deposited in a single regulatory entity account. This not only meets the regulatory requirements of relevant payment regulations, but also ensures the clear traceability of the fund rights of all parties through logical isolation, laying a data foundation for subsequent automatic accounting, compliant invoicing, and third-party reconciliation.

[0048] Preferably, after constructing the target virtual account, the first virtual sub-account, the second virtual sub-account, and the third virtual sub-account, the method further includes: setting preset revenue sharing rules based on the target enterprise's enterprise dimension, the target enterprise's order type, and the target enterprise's cooperation mode, and obtaining the target platform's first revenue sharing ratio, the target service provider's second revenue sharing ratio, and the target user's third revenue sharing ratio according to the preset revenue sharing rules.

[0049] The preset revenue sharing rules can be set by those skilled in the art based on the relevant labor costs, service fees, etc. of enterprises, platforms, and users, and are not specifically limited here.

[0050] Specifically, after completing the construction of the target enterprise virtual account, the platform's first virtual sub-account, the human resources service provider's second virtual sub-account, and the freelancer's third virtual sub-account, the system further executes the dynamic configuration and parameter parsing of the revenue sharing rules.

[0051] Specifically, firstly, this application can set preset revenue sharing rules based on the target company's enterprise dimension, order type, and cooperation model to accurately match or generate corresponding revenue sharing strategies. The enterprise dimension can identify the unique identifier of the target company (such as enterprise ID or unified social credit code) and support customized rates for different companies. The order type can be set with differentiated service structures based on task attributes (such as "hourly workers", "project outsourcing", "content creation" etc.). The cooperation model distinguishes cooperation architectures such as "direct platform contract", "HR outsourcing", and "joint service" to determine whether to enable HR service provider revenue sharing nodes and individual income tax withholding logic.

[0052] Secondly, based on the preset revenue-sharing rules matched by the above dimensions, the system parses the following structured revenue-sharing parameters: Target platform service fee rate (i.e., the first revenue-sharing ratio), which represents the proportion of the service fee that the target platform, as a partner, should collect as a percentage of the total labor costs, for example, 5%; Human resources service fee rate (i.e., the second revenue-sharing ratio), which represents the fee rate charged by the human resources service provider for services such as tax collection and payment, and compliant invoicing, for example, 7%; The individual income tax withholding parameter is not a fixed percentage, but rather a calculation model based on the cumulative withholding method or the assessed tax rate table, used to dynamically calculate the amount of individual income tax to be withheld; The freelancer net income ratio (i.e., the third revenue-sharing ratio) is the remaining portion, i.e., net income = total labor costs. (Platform service fee + human resources service fee + withheld individual income tax).

[0053] In step S202, if a pending accounting event is received, the balance is transferred from the target virtual ledger of the target enterprise to the first virtual sub-account, the second virtual sub-account, and the third virtual sub-account respectively according to the preset accounting rules, and the corresponding tax attribute information is recorded simultaneously.

[0054] Preferably, according to preset revenue sharing rules, balance transfers are made from the target enterprise's target virtual ledger to the first virtual sub-account, the second virtual sub-account, and the third virtual sub-account, respectively. This includes: calculating the platform service amount of the target platform, the service provider service amount of the target service provider, the tax amount due to the target user, and the actual income amount of the target user based on the preset revenue sharing rules; deducting the total amount due for revenue sharing from the target virtual accounts, and adding the platform service amount to the first virtual sub-account, the service provider service amount and the tax amount due to the second virtual sub-account, and adding the actual income amount of the target user to the third virtual sub-account.

[0055] Specifically, such as Figure 3 As shown, after receiving a business event indicating that the task delivery has been approved, the system triggers an automatic revenue sharing process. First, it loads the preset revenue sharing rules that match the current order, and calculates the amount of each revenue sharing item based on the total labor costs to be settled (i.e., the total amount to be shared) according to the following logic: Platform service amount = total amount to be shared × platform service fee rate; Service provider service amount = total amount to be shared × human resources service fee rate; Tax payable: This is not a simple proportional calculation, but rather, based on the freelancer's income type, accumulated income, special deductions, etc., it calls the built-in individual income tax calculation engine (supporting cumulative withholding method or assessed collection) to dynamically generate the amount of individual income tax to be withheld; Actual income amount = total amount to be shared. Platform service amount Service provider service amount Amount of taxes payable.

[0056] Secondly, under distributed transaction control (e.g., using Redis distributed locks + local message tables + two-phase commit mechanism), the system atomically executes the following four virtual account operations: deducting the total amount to be distributed from the target enterprise's virtual account, adding the platform service amount to the platform's first virtual sub-account, adding the service provider's service amount and tax payable amount to the human resources service provider's second virtual sub-account, and adding the actual income amount to the freelancer's third virtual sub-account. All of the above transfer operations are completed in the internal virtual ledger system, without involving any cross-bank real fund flows, and only updating the available balance of each logical account.

[0057] Finally, at the same time as each virtual transfer record is generated, the system automatically attaches the corresponding tax metadata to form a structured accounting record. This mainly includes the identity of the transferor and transferee, the service type (such as "platform matching service" or "human resources outsourcing service"), the applicable tax rate and tax amount, the invoicing party (platform or human resources service provider), and the corresponding tax classification code (according to the standards of the State Taxation Administration). If any of the above sub-operations fails (such as account locking, insufficient balance, database abnormality, etc.), the system will immediately trigger a global rollback to ensure that the virtual account balance of the target enterprise is restored to its original state and that all sub-accounts remain unchanged, thereby eliminating the risk of "loss" or "double allocation" of funds. After the accounting is successfully split, the system releases an "account split complete" event to drive the subsequent payment and voucher generation process.

[0058] The following application will combine Figure 3 Let's take a task order of 1000 yuan as an example for illustration: Step S1: Corporate Top-up and Fund Freezing: Source data: The company initiates a 1,000 yuan flexible employment prepayment recharge request (carrying the target task order ID and company account identifier); Processing: The system integrates with the enterprise's online banking / third-party payment to complete fund collection. An automatic association mechanism binds orders and recharge funds. When an enterprise initiates a recharge, a unique order ID must be provided. After verifying the validity of the order ID (whether it is an unsettled order and whether the order amount matches the recharge amount), the system automatically associates the recharge funds with the order. Simultaneously, a balance of 1000 yuan is added to the "Enterprise Virtual Ledger" and marked as "frozen," generating a recharge-order association log (including association timestamp and verification results). Result: The funds have been physically escrowed (deposited into a regulatory account) and logically locked, and can only be used for the payment of this order, preventing misappropriation.

[0059] Additional explanation: The automatic association logic is "unique mapping of order ID + amount verification". If the enterprise does not provide an order ID or the order information is invalid, the system will refuse to recharge or mark it as "pending association". The association information needs to be manually entered to unlock it, ensuring that funds and orders are accurately bound.

[0060] Step S2: Task delivery triggers primary fund transfer: Triggering condition: The enterprise confirms in the system that the "task delivery is qualified" (this can be done by uploading acceptance documents, clicking the confirmation button, etc.); Processing: The system executes fund transfer through a two-phase commit transaction mechanism based on Redis distributed lock: (1) Pre-deduction phase: Lock the corresponding balance of the enterprise virtual ledger and record the transaction log (including order ID, transfer amount, and timestamp); (2) Confirmation phase: Deduct RMB 1,000 from the "enterprise virtual ledger" and simultaneously add RMB 1,000 to the "platform virtual ledger", and mark the transaction log as "completed"; If any phase fails, the pre-deduction operation is automatically rolled back, the enterprise account balance is restored, and an alarm is triggered; Result: The ownership of funds was transferred to the platform, and the system automatically recorded the fund transfer vouchers between the "enterprise and the platform" (including the account holder, amount, and order relationship), providing basic data for issuing service fee invoices in the future.

[0061] Additional explanation: The core purpose of the transaction mechanism is to ensure the atomic execution of "deduction-transfer" and avoid fund stagnation or duplicate transfers caused by network latency or node failure; Step S3: Business review triggers secondary revenue sharing: Triggering conditions: The platform completes the business compliance review and must meet the following conditions simultaneously: (1) Complete order information (including mandatory fields such as task type, number of employees, salary standard, and description of deliverables); (2) Valid enterprise qualifications (business license and flexible employment filing certificate are within the validity period); (3) Complete task delivery vouchers (acceptance documents confirmed by the enterprise and task completion vouchers of C-end users); (4) Compliant fund flow (no abnormality in the source of recharge funds and matching with the order amount); After the review is approved, the system will automatically trigger the profit sharing; Processing: The revenue sharing module reads the preset rules (such as a 6% platform service fee), leaves 60 yuan in the "Platform Virtual Ledger", and transfers the remaining 940 yuan to the "HR Service Provider Virtual Ledger"; Result: The platform service fee was automatically credited to the account, and the system generated the basic data for the platform to issue service fee invoices to the enterprise.

[0062] Step S4: Service provider review triggers three-tier revenue sharing and payment: Triggering condition: The HR service provider completes the review of individual income tax declaration information; Processing: Split according to the rules (e.g., HR service fee 5%, user salary 95%), 47 yuan is transferred to the "HR Service Provider Revenue Ledger", and 893 yuan is pushed to the payment gateway; Payment gateway processing: Detects the type of the user's linked receiving account (bank card / Alipay), and selects the optimal payment channel to initiate the transfer based on channel load and fee rate; Result: 893 yuan in salary was deposited into the user's account, the HR service provider received the service fee, and the process ended.

[0063] In step S203, based on the real-time health index of each payment channel of the target user, the optimal payment channel is determined from each payment channel, so as to transfer the balance to the target user based on the optimal payment channel.

[0064] Preferably, the optimal payment channel is determined from each payment channel based on the real-time health index of each payment channel for the target user. This includes: collecting the real-time health index of each payment channel, wherein the real-time health index includes at least one of payment channel load, payment channel fee rate, average response latency, transaction success rate, and circuit breaker status; calculating the comprehensive score of each payment channel based on the real-time health index using a target weighted scoring model according to the multiple payment channels pre-bound by the target user; and determining the optimal payment channel among each payment channel for the target user based on the comprehensive score.

[0065] Specifically, after completing multi-level virtual revenue sharing, the system needs to transfer the actual income amount in the freelancer's virtual sub-account to their receiving account using real funds. To ensure payment success rate and user experience in high-concurrency payroll scenarios, the system executes an intelligent payment channel selection process.

[0066] Specifically, firstly, the system pre-integrates mainstream payment channels, including bank card payments (UnionPay / NetUnion), Alipay transfers to accounts, WeChat Wallet / bank card transfers, etc. Each freelancer can bind one or more real-name payment methods (such as their own bank card, Alipay account, WeChat Pay account) when registering or making their first withdrawal, forming their personal set of available payment channels. This set constitutes the candidate pool for subsequent routing decisions.

[0067] Secondly, through the payment channel health probe service, multi-dimensional health indicators of each channel are continuously collected at a rate of seconds, including but not limited to: transaction success rate: number of successful transactions in the past 5 minutes / total number of requests (highest weight, reflecting channel stability); average response latency: average time from initiating a request to receiving the final result (unit: milliseconds); current concurrent load: number of requests currently being processed by the channel or queue depth, used to assess capacity bottlenecks; payment channel fee rate: cost per transaction (e.g., 0.1% or a fixed 3 yuan), affecting overall costs; circuit breaker status: if the number of consecutive failures of a channel exceeds a threshold (e.g., 3 times), it will automatically enter circuit breaker status, suspend use and start a recovery countdown (e.g., 5 minutes).

[0068] Secondly, the system uses a configurable weighted scoring model to quantitatively evaluate each available channel and calculate a comprehensive score. Then, the system excludes channels that are in a circuit breaker state from the user's bound available channels, calculates the comprehensive score for the remaining channels according to the above model, and selects the one with the highest score as the optimal payment channel. If the payment fails during the process due to network jitter or third-party traffic throttling, the system immediately triggers an automatic retry mechanism: First failure: retry the original channel after waiting for a random backoff time; ≥2 consecutive failures: skip the original channel and automatically switch to the second-best channel to re-initiate the payment, with a maximum of 3 retries; All channels fail: enter the manual review queue and notify the user to update the payment method. If the order is canceled or the task is not completed, the system can trigger a frozen funds return process, returning the unallocated funds to the "Enterprise Virtual Ledger".

[0069] Finally, the complete context of each channel selection process is recorded, including user ID, candidate channel list, health indicators of each channel, weight configuration, final selection result and reason. This log is used for post-event analysis, model optimization and compliance audit. At the end of each month, the system automatically summarizes the fund flow data and invoice issuance status of each role and generates compliance reports for enterprises and service providers to verify.

[0070] For example, a company pre-charges 10,000 yuan to the platform. After the order is completed, the company clicks "Confirm Completion". The system automatically transfers 10,000 yuan to the platform account. The system automatically deducts 500 yuan (5%) as a platform technical service fee. The remaining 9,500 yuan is transferred to the HR service provider's account. The system automatically deducts 700 yuan (7%) as individual income tax and collection service fee. The remaining 8,800 yuan generates a payment order. If the payment gateway detects an abnormal bank card, the system automatically switches to the Alipay account to complete the payment. The whole process takes about 30 seconds, and the balances of all parties' accounts are automatically balanced.

[0071] Preferably, after transferring the balance to the target user based on the optimal payment channel, the method further includes: receiving the split notification returned by the optimal payment channel, updating the target user's third virtual sub-account according to the split notification, and generating a split voucher.

[0072] Specifically, after the system successfully initiates a real fund transfer from the regulated entity account to the target user's real-name receiving account through the optimal payment channel (such as bank card, Alipay or WeChat), it enters the payment result processing and compliance closed-loop stage.

[0073] Specifically, after the payment channel completes the fund transfer, it pushes an asynchronous settlement notification to the system through an encrypted callback interface. This notification includes key fields such as a unique order number, the actual payment amount, the payment channel identifier, the transaction status (success / failure / processing), the third-party transaction serial number, and a timestamp and digital signature. The system first verifies the legality of the notification source and the integrity of the data to prevent forged callbacks. If the notification status is successful, the system updates the "pending payment" balance in the freelancer's third virtual sub-account to "paid" and records the actual amount received, payment time, channel type, and third-party transaction serial number in the user's payment details table. If there is a slight difference between the payment amount and the amount due (such as due to bank fees), the system automatically marks it as an "abnormal difference" and triggers a financial review process.

[0074] Furthermore, based on the tax metadata already bound during the revenue sharing phase and the payment result, the system automatically generates an electronic revenue sharing voucher, which mainly includes information on the four parties, details of fund splitting, a unique association identifier, and the voucher generation time and digital signature. This voucher is stored in JSON data exchange format or PDF document format and is simultaneously pushed to the enterprise's financial and tax system, the platform's settlement backend, and the HR service provider's invoicing platform, serving as the legal basis for subsequent automatic application for electronic invoices and tax declarations.

[0075] Furthermore, since flexible employment payroll is concentrated at the end of the month and quarter, tens of thousands of payment instructions may be generated in a short period of time. Directly calling the payment interface can easily lead to channel congestion or system overload. Therefore, this application introduces a Kafka message queue to write payment instructions in high-concurrency scenarios into the queue first, and then consume and process them asynchronously by the payment execution unit. The message queue can buffer requests, realize "peak shaving and valley filling", and ensure the stable operation of the system under high load, thereby enabling the message queue to achieve traffic peak shaving.

[0076] Furthermore, due to the risks of network latency and node failures in distributed systems, the revenue sharing process may be interrupted (e.g., only the balance of the superior account is deducted without increasing the balance of the subordinate account). Distributed locks can prevent funds from "disappearing out of thin air" or "receiving duplicate funds," ensuring data consistency. This application adopts a Redis distributed lock, using "order ID + upstream and downstream account identifier combination" as the unique lock key. In the multi-level revenue sharing process, all upstream and downstream virtual ledgers involved are locked through Redis atomic operations to ensure atomic execution of the entire "deduction-transfer" process. The lock expiration time is set to 30 seconds (adapting to the maximum time consumption of revenue sharing operations), and a lock renewal mechanism is introduced. If revenue sharing is not completed, the lock validity period is automatically extended to prevent the lock from being released prematurely.

[0077] The core working principle of Redis distributed lock mainly includes: (1) Locking logic: When the splitting execution module triggers splitting, it sends the atomic instruction "SETNX lock key random value EX30NX" to Redis. SETNX ensures that the lock is created only when the lock key does not exist (avoiding repeated locking). EX30 sets the lock's automatic expiration time (to prevent deadlock). The random value is used as the unlocking certificate (to avoid misunderstanding of the lock). If the lock is successfully acquired, the splitting operation is entered. If the lock fails, it means that the splitting has been triggered by other threads. The system waits for 50 milliseconds and then retryes. It can retry a maximum of 3 times. If it still fails, an alarm is triggered. (2) Execution of business: After the lock is successfully acquired, the splitting execution module executes the "upper account deduction + lower account arrival" operation according to the rules. During this period, it uses Red The distributed lock blocks other requests for splitting and transferring data for this group of virtual ledgers, ensuring that the operation is free from concurrent interference; (3) Unlocking logic: After the splitting operation is completed (successfully or unsuccessfully), the system performs atomic unlocking through Lua script - first verify that the random value corresponding to the lock is consistent with the local storage (to confirm that the current thread holds the lock), and then delete the lock key; if the system node fails during the splitting process, the lock will automatically expire and be released after 30 seconds to avoid long-term occupation of lock resources and deadlock; (4) Splitting scenario adaptation: For multi-level splitting (such as enterprise-platform-HR service provider-user), the "one-time locking of the entire chain account" strategy is adopted. The lock key contains the complete chain identifier to ensure the atomicity of the entire chain splitting operation and avoid the abnormal situation of some levels of splitting succeeding and some failing.

[0078] Furthermore, due to differences in fee rates among different payment channels (e.g., 0.1% for bank transfers, 0.08% for Alipay), and the fact that some channels offer fee discounts for large transfers (e.g., bank transfers of ≥50,000 RMB have a fee reduced to 0.05%), while others have hidden additional costs (e.g., WeChat Pay has no additional fee for small transfers, but bank card transfers <100 RMB incur an additional withdrawal fee of 0.02 RMB per transaction); dynamic adaptation can accurately calculate the actual cost of each payment, avoiding the trap of "seemingly low fees but high additional costs," reducing overall payment costs, and improving the solution. To ensure cost-effectiveness, the payment gateway in this application incorporates a three-dimensional weighted calculation model consisting of "basic fee rate + additional discounts + additional costs". This model accesses data such as the basic fee rate, large discount policies, and additional fees (e.g., withdrawal fees, cross-border fees) of each payment channel in real time. Combined with the current transfer amount and channel availability weight, it calculates the "comprehensive cost rate" for each payment and ultimately selects the available channel with the lowest comprehensive cost rate. The model supports dynamic parameter updates (e.g., channel fee rate adjustments, changes in discount policies), with the update frequency synchronized with channel status monitoring (refreshed every 5 seconds).

[0079] The core logic and calculation steps of the rate calculation model are as follows: The core components of the model consist of four modules: "Basic Fee Rate Processing Unit", "Preferential Rule Parsing Unit", "Additional Cost Calculation Unit" and "Availability Weight Calibration Unit". The data source is the status monitoring unit of the multi-channel payment gateway (real-time collection of channel fee rate policies, preferential rules and additional fee standards). (2) Input parameter definition: Key parameters: Basic channel fee rate (e.g., 0.1% for banks, 0.08% for Alipay, and 0.07% for WeChat), transfer amount (denoted as M), channel discount rules (e.g., "50% off fee rate for M≥50,000" or "0.01% fee reduction for the first month of a new channel"), and additional costs (e.g., withdrawal fee F and cross-border transfer surcharge R). Constraint parameters: Channel availability weight (denoted as W, converted from channel health score, ranging from 0.8 to 1.0; if health score is ≥80, W=1.0; if health score is 60-79, W=0.8).

[0080] (3) Specific calculation process: 1) Calculate the basic fee rate cost = transfer amount M × channel basic fee rate; 2) Analyze the discount rules and calculate the discount amount: If the tiered discount is met (e.g., M≥50,000, base rate×0.5): Discount reduction = base rate cost×(1-discount). If a fixed discount is applied (e.g., a 0.01% discount in the first month): Discount = M × Fixed Discount Rate; If there is no discount, the discount amount is 0. 3) Calculate additional costs: Additional fees per transaction (e.g., withdrawal fee of 0.02 yuan per transaction): directly added to the total cost; Proportional surcharges (e.g., 0.03% surcharge for cross-border transfers): Surcharge cost = M × proportional surcharge rate; 4) Calculate the actual cost = (basic rate cost - discounts and exemptions) + additional costs; 5) Weighted calibration (considering availability): Overall cost score = actual cost × (2 - W) (The higher the availability weight W, the lower the score after calibration, ensuring that the "low cost + high availability" channel is prioritized; when W=1.0, the calibration coefficient is 1.0, and when W=0.8, the calibration coefficient is 1.2, to avoid selecting unstable channels due to excessive pursuit of low cost).

[0081] (4) Decision logic: The model calculates the “comprehensive cost score” for all available channels with a health score ≥ 60, and selects the channel with the lowest score as the “cost-optimal channel”; if multiple channels have the same score, the user’s commonly used payment channel type is matched first (e.g., if the user defaults to binding Alipay, the Alipay channel is selected first).

[0082] The following examples illustrate this (using transfers of 1000 yuan and 20000 yuan as examples): Scenario 1: Transfer amount M = 1000 yuan (small amount), 3 channels available: Channel A (Bank): Base fee rate 0.1%, no discounts, additional cost 0.02 yuan / transaction; W=1.0 Actual cost = (1000 × 0.1% - 0) + 0.02 = 1.02 yuan; Overall cost score = 1.02 × 1.0 = 1.02 Channel B (Alipay): Base fee rate 0.08%, no discounts, no additional costs; W=1.0 Actual cost = 1000 × 0.08% = 0.8 yuan; Overall cost score = 0.8 × 1.0 = 0.8 Channel C (WeChat): Base fee rate 0.07%, no discounts, no additional costs; W=0.9 (health score 75). Actual cost = 1000 × 0.07% = 0.7 yuan; Overall cost score = 0.7 × (2 - 0.9) = 0.77 Decision result: Channel B (lowest overall cost score of 0.8) is selected. Although Channel C has a lower base rate, its score is higher after availability weight calibration. Therefore, Channel B, which is highly available and low-cost, is preferred.

[0083] Scenario 2: Transfer amount M = 20,000 yuan (large amount), Channel A (bank) offers a discount: "M ≥ 50,000 yuan enjoys 50% off, M ≥ 10,000 yuan enjoys 20% off": Actual cost of channel A = (20000 × 0.1%) × 0.8 + 0.02 = 16.02 yuan; Overall cost score = 16.02 × 1.0 = 16.02 Channel B (Alipay): 20000 × 0.08% = 16 yuan; Score = 16 × 1.0 = 16 Decision result: Select channel B (score 16 < 16.02), which accurately adapts to the differences in discounts in large-value scenarios.

[0084] It should be noted that, in addition to the revenue-sharing payment method discussed in this application, there are two other alternative technical solutions, mainly including: (1) Multi-role splitting interface provided by the bank Core logic: Directly utilize the B2B2C revenue sharing service offered by the bank. Enterprises transfer funds to a bank-designated escrow account, and the bank automatically splits the funds to the platform, service providers, and user accounts according to a preset ratio. The difference between this application and the above-mentioned method is: flexibility: the proportion configuration of bank revenue sharing interfaces is mostly a fixed template, which cannot adapt to the needs of "different revenue sharing proportions for different orders" in flexible employment scenarios; this application supports customized revenue sharing rules and adapts to diverse cooperation models. Compliance linkage: Banks are only responsible for fund splitting and cannot simultaneously record compliance information such as invoice circulation and individual income tax declaration; this application realizes the linkage of "fund flow and compliance flow", meeting tax needs in one stop; Cost: Bank splitting services typically charge a fixed service fee (e.g., 0.5 yuan per transaction), which is high for long-term, high-frequency use; this invention allows users to choose a low-cost channel to reduce overall costs.

[0085] (2) Combination of bulk payment on third-party payment platforms and manual revenue sharing Core logic: User salaries are distributed through the bulk payment function of Alipay and WeChat Pay, and service fees between the platform and service providers are settled through offline transfers, with compliance data recorded manually; Differences from the methods described in this application: Automation level: The previous solution required manual breakdown of service fees, offline transfers, and data recording, which was inefficient and prone to errors; the present invention achieves full automation without human intervention. Data consistency: Offline revenue sharing and online salary payment data are disconnected, making reconciliation difficult; this invention completes all fund transfers within the system, with automatic synchronization of transaction records and zero reconciliation errors; Concurrency support: Third-party payment platforms have single-transaction limits for batch payments (e.g., a maximum of 1,000 transactions per transaction), which makes it difficult to meet the high-concurrency payroll needs of large-scale enterprises; this invention can support tens of thousands of concurrent transactions per second through traffic management.

[0086] Therefore, the two alternative solutions mentioned above also have some limitations. This application, through its original four-in-one architecture of "virtual ledger + intelligent accounting engine + multi-channel payment gateway + compliant data closed loop," achieves end-to-end automated collaboration of business flow, capital flow, invoice flow, and tax flow, constituting a technically unavoidable solution. It possesses outstanding substantive features and significant progress, mainly reflected in: (1) Automated Multi-Level Fund Clearing: Solving the Pain Points of Complex Settlement Chains. Core Principle: Constructing an automated mechanism of "four-party account hierarchical binding + preset clearing rules" to replace manual transfer and reconciliation. Technical Logic: By preset the account association and sharing ratio of the employing enterprise, platform, human resources service provider, and C-end user, the system automatically triggers fund splitting after a transaction occurs, completing multi-level circulation without manual intervention, and generating real-time reconciliation data to eliminate human operation errors.

[0087] (2) Multi-channel intelligent switching + high-concurrency adaptation: Solving the pain point of payment failure. Core principle: Integrating multiple types of payment channels, achieving load balancing through dynamic monitoring and routing algorithms, and adapting to high-concurrency scenarios. Technical logic: On the one hand, it connects to multiple channels such as bank cards and third-party payments to form redundant backups; on the other hand, it monitors the load and limit status of each channel in real time, and automatically switches to the optimal backup channel when a channel is congested or fails. At the same time, it adopts traffic management, asynchronous processing and resource isolation technologies to cope with the concurrent pressure during peak payday periods and avoid system overload.

[0088] (3) Real-time synchronization of accounting and taxation: Overcoming the pain point of non-synchronization in compliance. Core principle: Establish a real-time linkage mechanism that integrates the "funds flow - information flow - invoice flow" to replace the traditional "collect first, pay later" model. Technical logic: The amount and flow of platform service fees, human resources service fees, and labor fees are recorded simultaneously during fund splitting, and electronic vouchers and invoice flow node records that meet tax requirements are automatically generated to ensure that accounting data and tax compliance data are matched in real time and to eliminate compliance risks.

[0089] According to the revenue-sharing payment method proposed in this application, upon receiving a revenue-sharing transaction event, the balance is transferred from the target enterprise's target virtual ledger to the first virtual sub-account, the second virtual sub-account, and the third virtual sub-account respectively, based on preset revenue-sharing rules. Simultaneously, the corresponding tax attribute information is recorded. Then, based on the real-time health indicators of each payment channel for the target user, the optimal payment channel is determined, and the balance transfer is made to the target user through the optimal payment channel. This solves problems such as reliance on manual multi-party revenue sharing, the susceptibility to failure due to single payment channels, and the disconnect between cash flow and tax flow. By constructing a system of one regulatory entity account + N-level virtual ledgers, it achieves the technical effects of automated multi-level revenue sharing, high payment availability, and integrated tax compliance.

[0090] Next, the revenue-sharing payment device proposed according to the embodiments of this application is described with reference to the accompanying drawings.

[0091] Figure 4 This is a block diagram of a revenue-sharing payment device according to an embodiment of this application.

[0092] like Figure 4 As shown, the split payment device 10 includes: a judgment module 100, a split payment module 200, and a determination module 300.

[0093] Among them, the judgment module 100 is used to determine whether a pending revenue sharing business event has been received; The accounting module 200 is used to transfer the balance from the target virtual ledger of the target enterprise to the first virtual sub-account, the second virtual sub-account and the third virtual sub-account respectively according to the preset accounting rules when a business event to be accounted for is received, and to record the corresponding tax attribute information at the same time. The determination module 300 is used to determine the optimal payment channel from each payment channel based on the real-time health index of each payment channel of the target user, so as to transfer the balance to the target user based on the optimal payment channel.

[0094] Preferably, before determining whether a pending revenue sharing event has been received, the determination module 100 is further configured to: Obtain the target company's registration information, the target company's qualifications for using the target platform, the target company's service provider agreement information, and the target company's user identity information; Based on the target company's registration information, construct the target company's target virtual account and target virtual ledger; Based on the user qualifications of the target platform, construct the first virtual sub-account of the target platform; Based on the target service provider's agreement information, construct a second virtual sub-account for the target service provider; Based on the target user's identity information, construct the target user's third virtual sub-account; Among them, the virtual account, the first virtual sub-account, the second virtual sub-account, and the third virtual sub-account are all associated with the same regulatory entity account, and are respectively allocated a dedicated fund partition, a target platform service fee partition, a target service provider fund partition, and a target user fund partition in the regulatory entity account.

[0095] Preferably, after constructing the target virtual account, the first virtual sub-account, the second virtual sub-account, and the third virtual sub-account, the determination module 100 is further configured to: Based on the target company's corporate dimensions, order types, and cooperation models, preset revenue sharing rules are set, and the first revenue sharing ratio of the target platform, the second revenue sharing ratio of the target service provider, and the third revenue sharing ratio of the target user are obtained according to the preset revenue sharing rules.

[0096] Preferably, the revenue sharing module 200 is specifically used for: Based on the preset revenue sharing rules, calculate the platform service amount of the target platform, the service provider service amount of the target service provider, the tax payable amount of the target user, and the actual income amount of the target user; The total amount to be distributed is deducted from the target virtual account, and the platform service amount is added to the first virtual sub-account, the service provider service amount and the amount of tax payable are added to the second virtual sub-account, and the actual income amount of the target user is added to the third virtual sub-account.

[0097] Preferably, the determining module 300 is specifically used for: Collect real-time health metrics for each payment channel, including at least one of the following: payment channel load, payment channel fee rate, average response latency, transaction success rate, and circuit breaker status. Based on the multiple payment channels pre-bound by the target user, and using a target weighted scoring model to calculate the comprehensive score of each payment channel based on real-time health indicators; The optimal payment channel for each payment channel for the target user is determined based on the overall score.

[0098] Preferably, after transferring the balance to the target user based on the optimal payment channel, the determining module 300 is further configured to: Receive the revenue sharing notification returned by the optimal payment channel, update the target user's third virtual sub-account according to the revenue sharing notification, and generate revenue sharing vouchers.

[0099] It should be noted that the foregoing explanation of the implementation of the revenue sharing method also applies to the data defect detection device of this embodiment, and will not be repeated here.

[0100] Figure 5 is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include: The memory 501, the processor 502, and the computer program stored on the memory 501 and capable of running on the processor 502.

[0101] When processor 502 executes the program, it implements the revenue sharing payment method provided in the above embodiments.

[0102] Furthermore, electronic devices also include: Communication interface 503 is used for communication between memory 501 and processor 502.

[0103] The memory 501 is used to store computer programs that can run on the processor 502.

[0104] The memory 501 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage.

[0105] If the memory 501, processor 502, and communication interface 503 are implemented independently, then the communication interface 503, memory 501, and processor 502 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0106] Optionally, in a specific implementation, if the memory 501, processor 502, and communication interface 503 are integrated on a single chip, then the memory 501, processor 502, and communication interface 503 can communicate with each other through an internal interface.

[0107] The processor 502 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of this application.

[0108] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described revenue sharing payment method.

[0109] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0110] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0111] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0112] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or more of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (FPGAs), field-programmable gate arrays (FPGAs), etc.

[0113] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware, and the program can be stored in a computer-readable storage medium. When executed, the program includes one or a combination of the steps of the method embodiments.

[0114] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for splitting payments, characterized in that, Includes the following steps: Determine whether a pending revenue sharing event has been received; If the pending accounting event is received, then according to the preset accounting rules, the balance is transferred from the target virtual ledger of the target enterprise to the first virtual sub-account, the second virtual sub-account and the third virtual sub-account respectively, and the corresponding tax attribute information is recorded simultaneously. Based on the real-time health index of each payment channel for the target user, the optimal payment channel is determined from each payment channel, and the balance is transferred to the target user based on the optimal payment channel.

2. The method according to claim 1, characterized in that, Before determining whether a pending revenue sharing event has been received, the process also includes: Obtain the registration information of the target company, the qualification to use the target platform within the target company, the agreement information of the target service provider within the target company, and the identity information of the target user within the target company; Based on the registration information of the target company, construct the target virtual account and target virtual ledger of the target company; Based on the user qualifications of the target platform, construct the first virtual sub-account of the target platform; Based on the target service provider's agreement information, a second virtual sub-account of the target service provider is constructed; Based on the target user's identity information, a third virtual sub-account for the target user is constructed; The virtual account, the first virtual sub-account, the second virtual sub-account, and the third virtual sub-account are all associated with the same regulatory entity account, and are respectively allocated a dedicated fund partition, a target platform service fee partition, a target service provider fund partition, and a target user fund partition in the regulatory entity account.

3. The method according to claim 2, characterized in that, After constructing the target virtual account, the first virtual sub-account, the second virtual sub-account, and the third virtual sub-account, the method further includes: Based on the enterprise dimension of the target enterprise, the order type of the target enterprise, and the cooperation mode of the target enterprise, a preset revenue sharing rule is set, and the first revenue sharing ratio of the target platform, the second revenue sharing ratio of the target service provider, and the third revenue sharing ratio of the target user are obtained according to the preset revenue sharing rule.

4. The method according to claim 1, characterized in that, The step of transferring balances from the target enterprise's target virtual ledger to the first virtual sub-account, the second virtual sub-account, and the third virtual sub-account according to preset accounting rules includes: Based on the preset revenue sharing rules, calculate the platform service amount of the target platform, the service provider service amount of the target service provider, the tax amount to be paid by the target user, and the actual income amount of the target user; The total amount to be distributed is deducted from the target virtual account, and the platform service amount is added to the first virtual sub-account, the service provider service amount and the tax payable amount are added to the second virtual sub-account, and the actual income amount of the target user is added to the third virtual sub-account.

5. The method according to claim 1, characterized in that, The process of determining the optimal payment channel from each payment channel based on the real-time health index of the target user includes: Collect real-time health indicators for each payment channel, wherein the real-time health indicators include at least one of payment channel load, payment channel fee rate, average response latency, transaction success rate, and circuit breaker status; Based on the multiple payment channels pre-bound by the target user, and using the real-time health index, a target weighted scoring model is used to calculate the comprehensive score of each payment channel. The optimal payment channel for each payment channel for the target user is determined based on the comprehensive score.

6. The method according to claim 1, characterized in that, After transferring the balance to the target user based on the optimal payment channel, the process also includes: Receive the revenue sharing notification returned by the optimal payment channel, update the third virtual sub-account of the target user according to the revenue sharing notification, and generate revenue sharing vouchers.

7. A split-payment device, characterized in that, include: The judgment module is used to determine whether a pending revenue sharing event has been received; The revenue sharing module is used to transfer the balance from the target virtual ledger of the target enterprise to the first virtual sub-account, the second virtual sub-account and the third virtual sub-account respectively according to the preset revenue sharing rules if the revenue sharing business event to be shared is received, and to record the corresponding tax attribute information at the same time. The determination module is used to determine the optimal payment channel from each payment channel based on the real-time health index of each payment channel of the target user, so as to transfer the balance to the target user based on the optimal payment channel.

8. The apparatus according to claim 7, characterized in that, Before determining whether a pending revenue sharing event has been received, the determination module is further configured to: Obtain the registration information of the target company, the qualification to use the target platform within the target company, the agreement information of the target service provider within the target company, and the identity information of the target user within the target company; Based on the registration information of the target company, construct the target virtual account and target virtual ledger of the target company; Based on the user qualifications of the target platform, construct the first virtual sub-account of the target platform; Based on the target service provider's agreement information, a second virtual sub-account of the target service provider is constructed; Based on the target user's identity information, a third virtual sub-account for the target user is constructed; The virtual account, the first virtual sub-account, the second virtual sub-account, and the third virtual sub-account are all associated with the same regulatory entity account, and are respectively allocated a dedicated fund partition, a target platform service fee partition, a target service provider fund partition, and a target user fund partition in the regulatory entity account.

9. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the revenue-sharing payment method as described in any one of claims 1-6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the revenue sharing payment method as described in any one of claims 1-6.

Images