Real-time correction method and device for payment sub-account errors, medium and computer equipment

Abstract

The invention relates to the technical field of electronic payment, and discloses a payment sub-account error real-time correction method and device, a medium and computer equipment, which can be applied to payment sub-account scenes in the technical field of financial science and technology and the technical field of medical health, and the method comprises the following steps: when a user initiates a transaction order to a merchant, real-time monitoring is carried out on the real-time correction of the payment sub-account error generated based on the transaction order; drawing a bill for the original of the platform; when it is monitored that the to-be-deduced amount in the original deduced bill exceeds the upper limit of the deduced proportion of the total transaction amount, recalculating the deduced amount receivable of the platform based on the total transaction amount and the deduced proportion receivable of the platform; and generating a virtual adjustment drawing bill based on the difference between the receivable drawing amount and the to-be-paid drawing amount, so that when the platform performs drawing and payment based on the transaction order, the original drawing bill and the virtual adjustment drawing bill perform common payment to obtain the receivable drawing amount. Before actual drawing and division, monitoring can be carried out in advance, correction measures are taken, and the accuracy of the transaction process is improved.

Description

Technical Field

[0001] This application relates to the fields of electronic payment technology, financial technology technology and medical and health technology, and in particular to a method, device, medium and computer equipment for real-time correction of payment and accounting errors. Background Technology

[0002] With the booming development of the O2O (Online to Offline) business model, it is becoming increasingly common for users and merchants to initiate transactions through online platforms and complete the delivery of services or goods offline. In this transaction ecosystem, platforms typically act as a bridge connecting users and merchants, providing both parties with transaction channels, credit guarantees, marketing promotions, and other services, and charging a certain percentage as revenue based on the transaction.

[0003] In the transaction process, when a user initiates a transaction order with a merchant, the system generates an initial commission bill for the platform based on that order. The commission amount to be transferred in the initial commission bill is the portion allocated to the platform from the total transaction amount according to preset rules. The platform sets a commission rate and a commission rate cap for the total transaction amount. The commission rate is the reasonable percentage of revenue the platform expects to obtain, while the commission rate cap is a limit set to protect the interests of merchants and prevent the platform from taking excessive commissions.

[0004] However, in actual transaction monitoring, due to potential factors such as system calculation errors, rule configuration mistakes, or malicious data tampering, the amount of commission to be paid in the original commission invoice may exceed the commission rate cap of the total transaction amount. If this anomaly is not handled promptly, it will, on the one hand, lead to the platform obtaining unreasonably high commissions, harming the interests of merchants and affecting the cooperative relationship between merchants and the platform; on the other hand, it may also cause users to question the reasonableness of the platform's fees, damaging the platform's reputation and credibility. Summary of the Invention

[0005] In view of this, this application provides a method, apparatus, medium, and computer equipment for real-time correction of payment and revenue sharing errors, which can monitor and take corrective measures in advance before the actual revenue sharing, thereby improving the accuracy of the transaction process.

[0006] According to one aspect of this application, a method for real-time correction of payment splitting errors is provided, the method comprising:

[0007] During the process of transactions between users and merchants through the O2O model, when a user initiates a transaction order to a merchant, the platform's original commission bill generated based on the transaction order is monitored in real time. The transaction order corresponds to a total transaction amount, and the original commission bill includes the commission amount to be transferred from the total transaction amount to the platform. The platform has a commission rate and a commission rate cap corresponding to the total transaction amount.

[0008] When it is detected that the amount of commission to be paid exceeds the upper limit of the commission rate for the total transaction amount, the commission amount receivable by the platform will be recalculated based on the total transaction amount and the platform's commission rate.

[0009] Based on the difference between the amount of commission receivable and the amount of commission to be paid, a virtual adjusted commission bill is generated so that when the platform makes commission payments based on transaction orders, the amount of commission receivable is obtained by jointly making payments using the original commission bill and the virtual adjusted commission bill.

[0010] According to another aspect of this application, a real-time payment splitting error correction device is provided, the device comprising:

[0011] The revenue sharing monitoring module is used to monitor in real time the original commission bill generated by the platform based on the transaction order when a user initiates a transaction order to a merchant during the O2O transaction process between users and merchants. The transaction order corresponds to a total transaction amount, and the original commission bill includes the commission amount to be transferred from the total transaction amount to the platform. The platform has a corresponding commission rate and a commission rate cap for the total transaction amount.

[0012] The security verification engine is used to recalculate the platform's receivable commission amount based on the total transaction amount and the platform's receivable commission rate when it detects that the amount of commission to be transferred exceeds the upper limit of the commission rate for the total transaction amount.

[0013] The virtual adjustment module is used to generate a virtual adjusted commission bill based on the difference between the commission amount receivable and the commission amount to be paid. This allows the platform to use both the original commission bill and the virtual adjusted commission bill to make joint payments when making commission payments based on transaction orders.

[0014] According to another aspect of this application, a medium is provided having a computer program stored thereon, which, when executed by a processor, implements the above-described method for real-time correction of payment splitting errors.

[0015] According to another aspect of this application, a computer device is provided, including a medium, a processor, and a computer program stored on the medium and executable on the processor, wherein the processor executes the program to implement the above-described real-time correction method for payment splitting errors.

[0016] By employing the above technical solution, this application provides a method, apparatus, medium, and computer equipment for real-time correction of payment and revenue sharing errors. When a user initiates a transaction order with a merchant, the system monitors in real-time the original commission bill generated based on the transaction order for the platform. When it detects that the commission amount to be transferred in the original commission bill exceeds the commission ratio limit of the total transaction amount, it recalculates the platform's receivable commission amount based on the total transaction amount and the platform's receivable commission ratio. Based on the difference between the receivable commission amount and the commission amount to be transferred, a virtual adjusted commission bill is generated. This allows the platform to jointly transfer the receivable commission amount using both the original commission bill and the virtual adjusted commission bill when making commission payments based on the transaction order. This allows for early monitoring and corrective measures before actual commission allocation, improving the accuracy of the transaction process.

[0017] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0019] Figure 1 A flowchart illustrating a real-time payment splitting error correction method provided in an embodiment of this application is shown.

[0020] Figure 2 A flowchart illustrating another real-time payment splitting error correction method provided in an embodiment of this application is shown;

[0021] Figure 3 This paper illustrates a flowchart of another method for real-time correction of payment splitting errors provided in an embodiment of this application.

[0022] Figure 4 This illustration shows a schematic diagram of a real-time payment splitting error correction device provided in an embodiment of this application;

[0023] Figure 5 A schematic diagram of another payment splitting error real-time correction device provided in an embodiment of this application is shown. Detailed Implementation

[0024] The present application will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of the present application can be combined with each other.

[0025] This embodiment provides a method for real-time correction of payment splitting errors, such as... Figure 1 As shown, the method includes:

[0026] Step 101: During the transaction process between users and merchants through the O2O model, when a user initiates a transaction order to a merchant, the platform's original commission bill generated based on the transaction order is monitored in real time. The transaction order corresponds to a total transaction amount, and the original commission bill includes the commission amount to be transferred from the total transaction amount to the platform. The platform has a commission rate and a commission rate cap corresponding to the total transaction amount.

[0027] Step 102: When it is detected that the amount of commission to be paid exceeds the upper limit of the commission rate of the total transaction amount, the commission amount of the platform is recalculated based on the total transaction amount and the platform's commission rate.

[0028] Step 103: Based on the difference between the amount of commission receivable and the amount of commission to be paid, generate a virtual adjusted commission bill so that when the platform makes commission payments based on transaction orders, it can use the original commission bill and the virtual adjusted commission bill to make joint payments to obtain the amount of commission receivable.

[0029] The embodiments described above in this application can be applied to O2O payment revenue sharing scenarios, and can also be applied to automated revenue sharing error correction systems based on bank interfaces in offline O2O scenarios. Specifically, they can relate to the fields of financial technology and healthcare technology, for example:

[0030] In the realm of fintech, the integration of micro-merchant lending with O2O consumption scenarios creates a demand for O2O payment revenue sharing. For example, a small catering merchant partnering with a financial institution might have a customer order and pay for their meal through an online platform (such as the financial institution's app or a partnered lifestyle service app), constituting an O2O transaction. The financial institution can provide credit services based on the merchant's transaction history. During the payment revenue sharing process, the platform takes a percentage of the total transaction amount according to an agreed-upon ratio, while the financial institution can also participate in revenue sharing based on the credit cooperation agreement. When revenue sharing errors occur, such as the platform's commission exceeding the preset commission rate limit, the method described in this application can be used to monitor and correct these errors in real time, ensuring the accuracy of revenue sharing amounts for all parties and safeguarding the cooperative relationship and profit distribution among financial institutions, platforms, and merchants.

[0031] In the field of healthcare technology, there exists an O2O (online-to-offline) healthcare scenario where online appointments are made and offline services are provided. For example, some private medical institutions or health management organizations offer online appointments for specialist consultations and physical examination packages, with consumers completing payments on online platforms. During revenue sharing, the platform, medical institutions, and potentially involved third-party health management service providers all need to share revenue according to certain rules. For instance, the platform provides appointment and service display functions and receives a certain percentage of the commission; medical institutions provide the actual medical services; and third-party health management service providers can provide follow-up health tracking services and also participate in revenue sharing. If errors occur during revenue sharing, the real-time error correction method proposed in this application can promptly identify and adjust the problem, ensuring that all participants receive accurate revenue and promoting the healthy development of healthcare O2O services.

[0032] Specifically, O2O payment revenue sharing refers to the process by which transaction funds are automatically distributed between online platforms and offline merchants according to preset rules. This mechanism is crucial in the O2O (Online To Offline) business model, ensuring transparency and efficiency in fund transfers while reducing risks and disputes caused by human intervention. The core process of O2O payment revenue sharing includes, for example:

[0033] Consumers select goods or services through O2O platforms and complete payments using various payment methods (such as Alipay, WeChat Pay, bank cards, etc.). The payment information is received and initially processed by the aggregated payment platform.

[0034] The O2O platform will simultaneously upload order information to the revenue sharing system, including the total transaction amount, information of the participants (such as the platform, merchants, suppliers, etc.) and the preset revenue sharing rules.

[0035] The revenue-sharing system automatically distributes transaction funds to the participating parties according to preset revenue-sharing rules. For example, in an e-commerce scenario, if a user pays 100 yuan, 90 yuan may be distributed to the seller and 10 yuan may be taken by the platform; in a ride-hailing scenario, the funds may be distributed to the driver, the platform service provider, etc.

[0036] The partner bank manages the funds according to the instructions of the revenue-sharing system, allocating funds to the accounts of each participating party. For example, revenue goes into the brand's corporate account, while other funds are distributed to franchisees, channel partners, etc., according to a set ratio.

[0037] Each participant can view and withdraw funds in their account, enabling flexible use of funds.

[0038] Specifically, in the O2O payment revenue sharing process, the revenue sharing system can automatically identify and process various transaction data, achieving accurate and efficient revenue sharing operations according to preset revenue sharing rules. For example, the system can share revenue based on the amount or proportion of each order, supporting single or multiple revenue sharing, with each share distributed to multiple parties. The revenue sharing system also supports multiple payment methods to meet diverse user payment needs and improve payment success rates. Simultaneously, the system can set different settlement cycles and methods, such as daily settlement, transaction-by-transaction settlement, or weekly settlement. Furthermore, the revenue sharing system establishes independent accounts for different participants, supporting functions such as account balance inquiry and transaction record viewing, allowing participants to monitor their financial status at any time. The system can collect and organize transaction data, generating statistical and financial reports, helping participants understand transaction and revenue situations and providing a basis for business decisions. The revenue sharing system can also monitor the transaction process in real time, detect anomalies, and take corresponding risk control measures. For example, it can identify potential fraudulent transactions or abnormal transaction behaviors and issue timely warnings and prevent them.

[0039] For O2O payment revenue sharing application scenarios, such as:

[0040] 1. E-commerce scenario:

[0041] In e-commerce O2O platforms, after users purchase goods online and complete payment, the platform needs to distribute the payment to different merchants or suppliers, while also paying a platform service fee. A revenue-sharing system can help the platform achieve multi-party fund distribution and settlement, simplifying the transaction process.

[0042] 2. Dining scenarios:

[0043] In the O2O catering industry, after users book or order food through a platform and complete payment, the platform needs to allocate the payment to the restaurant according to a certain percentage, while also paying a service fee to the payment institution. A revenue-sharing system can help catering platforms achieve fast and accurate fund allocation, improving efficiency.

[0044] 3. Service Scenarios:

[0045] In the O2O service industry, after a user books a service and completes payment, the platform needs to distribute the payment to the service provider according to a certain ratio, while also paying a platform service fee. A revenue-sharing system can help the platform automatically distribute and settle service fees, improving efficiency.

[0046] 4. Sharing economy scenarios:

[0047] In the sharing economy sector, such as shared bicycles and shared power banks, after users pay usage fees, the funds need to be distributed among equipment providers, platform operators, and others. A revenue-sharing system can automate the allocation of funds, ensuring that the profits of all parties are distributed in real time and transparently.

[0048] Furthermore, several pressing issues remain in the payment and revenue sharing field. Regarding error detection mechanisms, existing methods primarily rely on manual reconciliation or batch verification at the end of T+1 days, which is inefficient and makes timely error detection difficult. For correction triggers, when a revenue sharing error needs correction, operations staff must manually submit a work order, which requires a two-tier approval process, making rapid correction impractical. In terms of security verification, current methods often combine digital signatures with SMS two-factor authentication, offering some security but limiting their effectiveness in handling complex scenarios and rapid processing needs. Regarding fund flow processing, the current approach of processing refunds and payments independently may result in inefficient and inconsistent fund transfers. In terms of bank interface calls, correcting revenue sharing errors requires separate calls to the reversal interface and a new payment interface, increasing complexity and time costs. Additionally, some existing solutions require blockchain-based evidence storage, which places high demands on the technical environment and implementation costs.

[0049] In the above embodiments of this application, by real-time monitoring of the revenue sharing process, a revenue sharing equation is constructed and controlled in real time to ensure that the revenue sharing data is always in a precise and controllable state. When an anomaly in revenue sharing is detected, a correction process can be automatically triggered without manual intervention, greatly improving the timeliness of problem handling. Meanwhile, in terms of order matching, the original order four-tuple dynamic matching method is adopted, abandoning the traditional signature verification method, and accurately locating order information in a more flexible and efficient mode. For fund operations, refunds and payments are atomically bound, processing them as an inseparable whole, ensuring the consistency and accuracy of fund flow. Furthermore, in terms of interface calls, related operations are encapsulated into combined instructions, called through the Witness Treasure batch API, and implemented using a pure bank interface, simplifying the operation process, improving the efficiency of system-bank interface interaction, and effectively reducing the complexity and error probability of operations. In particular, Witness Treasure can be used to witness, record, and supervise transaction information during the transaction process, ensuring the security and compliance of the transaction. It is commonly used in O2O (online-to-offline) transactions, e-commerce platform transactions, revenue sharing, and other scenarios, with the following functions:

[0050] Transaction information witnessing: Recording and verifying key transaction information, such as the identity information of both parties, transaction amount, transaction time, and transaction subject matter, to ensure the authenticity and accuracy of transaction information and provide strong evidence support for any potential disputes.

[0051] Funds Supervision: During the transaction process, transaction funds are supervised to ensure that funds flow in accordance with agreed rules. For example, in a profit-sharing scenario, WitnessBao can accurately allocate transaction funds to each participant according to preset profit-sharing rules, avoiding the risk of misappropriation or incorrect allocation of funds.

[0052] Risk control: Through the built-in risk monitoring mechanism, transactions are monitored in real time to identify potential risky transactions, such as abnormally large transactions or frequent transactions, and corresponding measures are taken in a timely manner, such as early warning and interception, to ensure the security of transactions.

[0053] Examples of application scenarios for Witness Treasure:

[0054] O2O transactions: In scenarios where users place orders through an online platform and then consume at offline merchants, WitnessPay can witness the transaction process and supervise funds. For example, if a user buys a restaurant voucher online and then consumes it at a physical restaurant, WitnessPay ensures that the consumption amount is accurately settled to the restaurant, while protecting the rights and interests of both the platform and the user.

[0055] E-commerce platform transactions: For transactions on e-commerce platforms, WitnessPro can verify the authenticity of the transaction and monitor the flow of transaction funds. After the buyer confirms receipt, the funds are transferred to the seller according to the platform's rules, and any refunds, after-sales service, and other financial operations that may be involved are also handled.

[0056] Revenue Sharing Scenario: In transactions involving multiple parties such as platforms, merchants, and suppliers, WitnessBao can reasonably allocate transaction funds to each participant according to the agreements and rules of all parties, ensuring the accuracy and fairness of revenue sharing.

[0057] Specifically, in the fintech field, taking the example of a user purchasing wealth management products issued by micro and small merchants through a financial platform, the process of real-time monitoring of the original commission bill is as follows:

[0058] A user places an order through the financial platform's app to purchase a 1,000 yuan wealth management product offered by a small and micro-sized merchant. The transaction order is generated simultaneously, clearly indicating that the total transaction amount is 1,000 yuan. According to the agreement between the platform and the merchant, the platform sets a commission rate of 2% for this transaction (theoretically 20 yuan), while setting a maximum commission rate of 25 yuan to protect the merchant's interests (i.e., the platform can only take a maximum of 25 yuan).

[0059] After a transaction order is generated, the system automatically triggers the revenue sharing process, generating an initial commission bill for the platform based on the order information. The "commission amount to be transferred" recorded in the initial commission bill is initially calculated by the system according to preset rules. Assuming that due to a system configuration error, the commission amount to be transferred recorded in the initial commission bill is 30 yuan (exceeding the 25 yuan limit).

[0060] At this time, the platform's revenue sharing monitoring module scans the transaction flow in real time, automatically extracts the original commission bill information of the transaction order, and makes a real-time judgment through the built-in security verification engine: First, it checks the total transaction amount (1,000 yuan), the platform's commission rate (2%), and the commission rate limit (25 yuan) to calculate that the theoretical maximum commission amount to be paid should be 25 yuan; then, it compares the 30 yuan recorded in the original commission bill with 25 yuan and immediately detects that the commission amount to be paid exceeds the limit.

[0061] Upon detecting an anomaly, the system automatically triggers a correction process without manual intervention. Based on the total transaction amount (1000 yuan) and the platform's commission rate (2%), it recalculates the commission amount (20 yuan) and generates a virtual adjusted commission invoice (adjusted amount: -10 yuan, i.e., 30 yuan - 20 yuan). Ultimately, the platform uses both the original commission invoice (30 yuan) and the virtual adjusted commission invoice (-10 yuan) for payment, actually receiving 20 yuan in commission, ensuring the commission amount complies with the preset rules.

[0062] Optionally, regarding step 102, "recalculating the platform's receivable commission amount based on the total transaction amount and the platform's receivable commission rate," specifically includes:

[0063] Step 1021: Create a virtual adjustment commission bill associated with the transaction order, wherein the virtual adjustment commission bill corresponds to an adjustment amount.

[0064] Step 1022: Based on the difference between the amount of commission receivable and the amount of commission to be paid, determine the adjustment amount of the virtual commission adjustment bill. The adjustment amount includes positive and negative values. When the amount of commission receivable is greater than the amount of commission to be paid, the adjustment amount is positive. When the amount of commission receivable is less than the amount of commission to be paid, the adjustment amount is negative.

[0065] In the above embodiments of this application, the adjustment amount of the virtual commission adjustment bill is determined based on the difference between the amount of commission receivable and the amount of commission to be transferred. For example, if the amount of commission receivable is 500 yuan (the total transaction amount is 5000 yuan, calculated at a rate of 1%), and the amount of commission to be transferred is 700 yuan, the difference between the two is 500 - 700 = -200 yuan. Because the amount of commission receivable is less than the amount of commission to be transferred, the adjustment amount is negative, i.e., -200 yuan.

[0066] Specifically, a virtual adjustment commission bill is created. This means that after the system determines the adjustment amount to be -200 yuan, it creates a virtual adjustment commission bill associated with that transaction order. The virtual adjustment commission bill can contain the following key information:

[0067] Related transaction order number: clearly marked as being associated with the 5,000 yuan transaction order for subsequent tracing and verification.

[0068] Adjustment amount: Recorded as -200 yuan, to be deducted from the original commission bill of 700 yuan.

[0069] Reason for adjustment: The reason is that the amount of commission to be paid in the original commission bill exceeds the commission rate limit, so an adjustment is required.

[0070] The original order quadruple information includes the original order (original transaction order) number, the outgoing account (merchant account), the incoming account (platform account), and the original remarks (such as "fund product transaction - platform commission of 1%)", which are used to dynamically match order information to ensure the accuracy and legality of the adjustments.

[0071] Ultimately, the platform made the payment using both the original commission bill (700 yuan) and the virtual adjusted commission bill (-200 yuan). The actual commission amount paid to the platform was 700 + (-200) = 500 yuan, which was consistent with the amount calculated according to the commission receivable ratio, ensuring that the commission amount complied with the preset rules and protecting the interests of the platform, the fund company, and the user.

[0072] Optionally, the transaction order corresponds to transaction information, and the method also includes:

[0073] Step 104: When the platform makes commission payments based on transaction orders, monitor the amount of commission already paid to the platform in real time.

[0074] Step 105: If the detected amount of commission paid is zero, the rationality of zero commission payment is reassessed based on the transaction information of the transaction order.

[0075] Step 106: When the reasonableness assessment result is unreasonable, the platform’s missed commission is corrected through a reverse correction mechanism until the platform receives the commission amount due.

[0076] In the above embodiments of this application, such as Figure 2 As shown, the system involved in this application may include multiple core functional modules to collaboratively achieve precise control and security of payment and revenue sharing. Specifically:

[0077] The revenue sharing monitoring module plays a crucial role in monitoring revenue sharing results in real time. During the revenue sharing process, when it detects a transfer of funds from account A to account B, and there are specific abnormal conditions (with condition C=0 as the trigger for correction), the module will automatically trigger the correction mechanism to ensure that the revenue sharing results comply with preset rules.

[0078] The security verification engine employs a four-tuple verification method to rigorously verify the revenue sharing operation. The four-tuple specifically includes the original order number, the outgoing sub-account, the incoming sub-account, and remarks information. By matching and verifying these four key elements, the legality and accuracy of the revenue sharing operation can be effectively confirmed, preventing illegal or erroneous revenue sharing activities.

[0079] The WitnessPay interface adaptation layer serves as a bridge between the system and external payment channels, possessing the function of automatically generating instructions. When adjustments to account splitting are required, this adaptation layer can automatically generate reverse instructions to transfer funds from account B back to account A; simultaneously, it generates forward instructions to complete the transfer of funds from account A to the target account C, ensuring smooth and accurate fund flow.

[0080] To ensure the accuracy and reliability of system operations, this application also employs a dual-verification design for trigger conditions to prevent erroneous operations. When performing account reconciliation or other critical operations, the system will perform dual verification of the trigger conditions from different dimensions. Only when both dimensions of verification pass will the corresponding operation be executed, effectively avoiding erroneous operations caused by a single verification failure, and further improving the stability and security of the system.

[0081] Specifically, taking the financial transaction scenario of a user purchasing money market fund products through a financial platform as an example, the following are examples of how to achieve real-time monitoring of the platform's deducted commission amount, assessment of the reasonableness of zero commission, and full-process control of the reverse correction mechanism:

[0082] A user purchases a 100,000 yuan money market fund product issued by a fund company through a financial platform, generating a transaction order and completing the payment. According to the cooperation agreement between the platform and the fund company, the platform sets a commission rate of 0.2% for this transaction (theoretically, a commission of 200 yuan is due), and the agreement explicitly states that there are no commission-free clauses (meaning the platform must collect its commission). After the transaction order is generated, the system should automatically calculate the commission amount based on the order information and transfer the 200 yuan commission from the fund company's account (outgoing account) to the platform's account (receiving account) through a settlement process, completing the normal commission payment.

[0083] The platform's revenue sharing monitoring module monitors the revenue sharing results in real time. In this transaction, the monitoring module scans the fund transfer records returned by the bank interface to extract the platform's already paid commission amount corresponding to this transaction order. Suppose that due to system configuration errors or interface transmission anomalies, the bank interface returns a commission amount of 0 yuan (significantly inconsistent with the theoretically due 200 yuan). The revenue sharing monitoring module immediately identifies this anomaly (the commission amount is zero) and triggers a reasonableness assessment process.

[0084] The system activates its security verification engine to perform multi-dimensional verification of the rationality of zero-commission payments based on detailed transaction order information:

[0085] Extract key information from the transaction order, such as the total transaction amount (100,000 yuan), product type (money market fund), and merchant ID (fund company), to confirm whether the transaction falls within the scope of the commission-free period stipulated in the agreement. For example, if verification reveals that the agreement does not contain any commission-free clauses for money market funds or the fund company, then a zero-commission payment does not comply with the agreement.

[0086] By matching the revenue sharing rules (including the fund company ID and a commission rate of 0.2%) in the remarks information, it was confirmed that the system should charge a commission rate of 0.2%. The remarks information contained no special instructions or commission-free indications, further verifying the anomaly of the zero-commission payment.

[0087] Specifically, historical transaction data from the same fund company or similar products can be retrieved to confirm that the platform has consistently charged a 0.2% commission in past transactions, with no precedent for zero commission. By comparing historical data, the possibility of zero commission due to special events or temporary policies can be ruled out.

[0088] After multi-dimensional verification, the system determined that this zero-commission payment was unreasonable and abnormal, requiring immediate triggering of the reverse correction mechanism. Subsequently, the system automatically initiated the reverse correction process, generating reverse and forward instructions through the WitnessTreasure interface adaptation layer, ensuring the atomicity of the instructions (failure of either instruction results in a complete rollback):

[0089] 1. Reverse Instruction Generation: The adaptation layer generates a reverse refund instruction, requiring the previously incorrectly transferred 0 yuan to be returned from the platform account (original receiving sub-account) to the fund company account (original issuing sub-account), thus canceling the abnormal zero-commission transfer operation.

[0090] 2. Forward Instruction Generation: Simultaneously, the adaptation layer recalculates the receivable commission amount (200 yuan) based on the total transaction amount (100,000 yuan) and the receivable commission rate (0.2%), and generates a forward payment instruction, requesting the transfer of 200 yuan from the fund company account (original outgoing account) to the platform account (original incoming account) to complete the correct commission transfer.

[0091] 3. Instruction Atomicity Guarantee: The system binds reverse and forward instructions into an indivisible transaction unit. During execution, if either the reverse or forward instruction fails (e.g., the bank interface returns an error), the entire transaction will be automatically rolled back. That is, the executed reverse refund or forward payment operation will be undone, restoring the transaction to its initial state before execution, ensuring the consistency of financial data.

[0092] With the atomicity of instructions guaranteed, both the reverse and forward instructions were successfully executed: the platform account returned 0 yuan via the reverse instruction (cancelling the abnormal operation), and then received 200 yuan via the forward instruction (completing the correct commission payment). Ultimately, the platform actually received 200 yuan in commission receivable, consistent with the agreement.

[0093] During this process, the security verification engine rigorously verifies the correction operation through a four-tuple check (original order number, outgoing account number, incoming account number, and remarks information):

[0094] The original order number is verified, which confirms that the correction operation is associated with the correct original transaction order to avoid confusion in the operation.

[0095] The account verification process verifies the legitimacy of the funding source (fund company account) to ensure that only authorized accounts are allowed to initiate fund transfers.

[0096] Sub-account verification upon receipt of funds is to verify the legality of the funding target (platform account) and ensure that the commission funds are only transferred to the authorized account.

[0097] The remarks information is verified, that is, matched with the preset revenue sharing rules (including the fund company ID and the commission rate of 0.2%), to ensure that the correction operation complies with the agreement.

[0098] Through the above process, this application embodiment realizes real-time monitoring of the commission amount already paid by the platform, reasonableness assessment of zero commission, and automatic reverse correction, ensuring that the platform accurately obtains the commission receivable in financial transactions and protecting the legitimate rights and interests of the platform, merchants, and users.

[0099] Therefore, the payment splitting scheme proposed in this application has significant advantages in multiple dimensions such as performance and security. For example, this application has real-time processing capabilities, enabling it to quickly initiate a correction process after an error is detected, and ensuring that the entire process from error detection to correction completion is efficiently completed within the T+0 timeframe stipulated by the bank interface. That is, during the payment splitting process, once the system detects a splitting error, it immediately triggers an automatic correction mechanism, without waiting for subsequent settlement cycles, completing error correction in a very short time. This ensures the timeliness and accuracy of fund transfers, effectively avoiding problems such as fund occupation and transaction disputes caused by delayed error correction, and improving overall transaction efficiency. In terms of security verification, an innovative four-tuple verification method is adopted to replace traditional digital signature technology. Four-tuple verification performs comprehensive and multi-layered security verification of the splitting operation by accurately matching four key elements: the original order number, the outgoing sub-account, the incoming sub-account, and the remarks information. This verification method not only accurately confirms the legality and accuracy of the operation, effectively preventing illegal or erroneous splitting behavior, but also has lower computational complexity and higher processing efficiency compared to digital signature technology, improving the overall performance of the system while ensuring security. Furthermore, this application boasts excellent compatibility, seamlessly adapting to mainstream bank interfaces such as WitnessPay without requiring any modifications to existing protocols. By establishing a dedicated WitnessPay interface adaptation layer within the system architecture, efficient integration and stable interaction with bank interfaces are achieved. This adaptation layer automatically identifies and processes the instruction formats and data requirements of the bank interface, accurately converting the system's accounting instructions into a format recognizable by the bank interface, and receiving and processing the information returned by the bank interface. This compatibility design allows this application to be easily integrated into existing financial payment systems, reducing system integration costs and risks, and enhancing the solution's promotion and application value.

[0100] Optionally, users correspond to user accounts, merchants correspond to merchant accounts, and the platform corresponds to platform accounts. Regarding step 106, "using a reverse correction mechanism to correct any missed commissions collected by the platform until the platform receives the due commission amount," this specifically includes:

[0101] Step 1061: Generate a revised transaction order based on the recalculated platform commission amount.

[0102] Step 1062: Perform atomic operations based on the modified transaction order, wherein the atomic operations include deducting the receivable commission amount from the merchant account, increasing the receivable commission amount in the user account, simultaneously deducting the receivable commission amount from the user account, and increasing the receivable commission amount in the platform account.

[0103] In the embodiments described above, an instruction atomicity mechanism can also be employed to tightly bind the reverse refund operation and the forward payment operation into an indivisible transaction unit. During this transaction processing, the system ensures that these two operations either execute successfully simultaneously, completing the reversal of funds from the incorrect flow and the transfer to the correct flow; or, if either operation fails, the entire transaction will be automatically rolled back, meaning the executed reverse refund or forward payment operation will be canceled, restoring the system to its initial state before the transaction execution. This design effectively avoids inconsistencies in fund data caused by the success of partial operations, ensuring the integrity and accuracy of the payment and accounting process.

[0104] Specifically, a corrected transaction order is a crucial document used to rectify initial erroneous revenue sharing and ensure the platform receives the receivable commission. It contains comprehensive and accurate information so the system can accurately execute subsequent fund adjustment operations. A complete corrected transaction order can include the following key parts:

[0105] 1. Basic order information:

[0106] Order Number: A unique identifier is generated for each corrected transaction, used to uniquely identify and track this corrected operation throughout the system.

[0107] Associate original order number: Record the original transaction order number corresponding to the initial erroneous accounting, and clarify the target transaction for this correction operation.

[0108] Generation Time: Records the creation time of the corrected transaction order, accurate to the second, for subsequent auditing and querying.

[0109] 2. Transaction amount information:

[0110] For example, in a scenario where user A pays 100 yuan and merchant B receives 100 yuan (10 yuan should be given to platform C), the platform's receivable commission is 10 yuan.

[0111] 3. Account Information:

[0112] Billing Account: Based on business logic and fund flow, determine which merchant's account the receivable commission amount should be deducted from. In the above embodiments of this application, an initial error may occur, such as Merchant B overcharging, so the deduction should be made from Merchant B's account.

[0113] Receiving accounts: These can include transitional user accounts and platform accounts, specifically:

[0114] Transitional user account: Used to temporarily record the increase and deduction of receivable commission amounts to clearly reflect the logic of fund flow.

[0115] Platform Account: Clearly define the account on which the platform receives the commission receivable, and record it as Platform Account C.

[0116] 4. Transaction Remarks:

[0117] Please explain in detail the reasons and purpose of this correction, such as "Correcting the initial incorrect revenue sharing: User A paid 100 yuan, but Merchant B overcharged. The 10 yuan commission that should have been collected from Platform C should have been collected."

[0118] Regarding the execution of atomic operations, atomic operations are used to ensure that all related operations either all succeed or all fail and roll back, thus guaranteeing the consistency and security of funds. Based on the above-mentioned modified transaction order, the system can execute the following atomic operations:

[0119] 1. Deduct the commission amount from the merchant's account:

[0120] The system calls the WitnessPay interface to send an instruction to the bank to deduct 10 yuan from Merchant B's account. The bank system will first verify whether Merchant B's account balance is sufficient. If the balance is insufficient, the operation will fail and trigger the rollback mechanism of the entire atomic operation, meaning that no subsequent operations will be performed, and the fund status will remain unchanged.

[0121] 2. Increase the amount of commission receivable in the user's account:

[0122] In the system's internal accounting system, a record of 10 yuan is added to the transitional user account. This step mainly aims to clearly reflect the flow of accounts receivable at the accounting level. In the system database, the balance record of the transitional user account is updated, the balance is increased by 10 yuan, and relevant operation logs are recorded, including operation time, operation type (increase amount), operation amount (10 yuan), associated order number, and other information.

[0123] 3. Simultaneously deduct the outstanding commission amount from the user's account:

[0124] Following the previous step, the system's internal accounting system deducts 10 yuan from the transitional user's account. This step corresponds to the previous addition operation, creating a complete fund flow record at the accounting level, preparing for the final transfer of funds to the platform account. In the system database, the transitional user's account balance record is updated, decreasing the balance by 10 yuan, and relevant operation logs are recorded, including operation time, operation type (deduction amount), operation amount (10 yuan), and associated order number.

[0125] 4. Increase the amount of commission receivable in the platform account:

[0126] The system calls the WitnessPay interface again, sending an instruction to the bank to transfer 10 yuan from the transitional user account (in actual operation, this may be the source of funds processed internally by the system) to the C platform account. The bank system will verify the transferability of the funds related to the transitional user account (although this is a logical transfer processed internally by the system, the bank interface will ensure the legality of the fund transfer). If the verification passes, the transfer is successfully completed.

[0127] Therefore, by generating corrected transaction orders and executing atomic operations as described above, the initial incorrect revenue sharing can be accurately corrected, ensuring that Platform C receives the 10 yuan commission due, while also guaranteeing the security and accuracy of fund transfers.

[0128] Specifically, the merchants mentioned above can also be the responsible parties, and correspondingly, the merchant accounts correspond to the responsible party's accounts.

[0129] Optionally, the transaction information includes remarks, outgoing sub-account, and incoming sub-account. Specifically, step 105, "reassessing the rationality of zero-commission payment based on transaction information from transaction orders," includes:

[0130] Step 1051: Based on the transaction information of the transaction order, verify whether the outgoing account is a merchant account and the incoming account is a platform account.

[0131] Step 1052: If the sub-account receiving the payment is not a platform account, then parse the remarks to confirm whether there is at least one of the following: system anomaly mark, special subsidy policy, or commission-free clause agreed upon by the platform and the merchant.

[0132] Step 1053: If the remarks contain at least one of the following: system anomaly mark, special subsidy policy, or commission-free clause agreed upon by the platform and the merchant, the reasonableness assessment result is reasonable. If the billing sub-account is not a merchant account or does not contain a system anomaly mark, special subsidy policy, or commission-free clause agreed upon by the platform and the merchant, the reasonableness assessment result is unreasonable.

[0133] In the above embodiments of this application, to ensure data security during the payment and revenue sharing process, a rigorous and efficient data security system can be constructed, which includes a lightweight verification mechanism. This mechanism performs comprehensive verification of the revenue sharing operation through multiple key verification fields, as follows:

[0134] Original Order Number Verification: This verification field is used to accurately link the operation to the original transaction. When performing revenue sharing operations, the system will strictly verify the original order number to ensure that the current operation is initiated based on the correct original transaction, preventing incorrect revenue sharing due to order confusion, and ensuring the integrity and traceability of transaction data.

[0135] Sub-account verification for outgoing funds: By verifying the outgoing sub-account, the system can effectively confirm the legitimacy of the fund source. Funds will only be allowed to be transferred from the sub-account if it meets the preset rules and permissions, preventing illegal fund outflows and ensuring the security and compliance of fund transfers.

[0136] Sub-account verification for incoming funds: Sub-account verification for incoming funds focuses on verifying the legitimacy of the fund destination. The system will check whether the sub-account for incoming funds is a legitimate receiving account to ensure that funds are accurately transferred to the designated target account, preventing funds from being mistransferred or flowing into illegal accounts, and protecting the rights and interests of the fund recipient.

[0137] Remarks Information Verification: The remarks information includes preset revenue sharing rules and key information such as relevant merchant IDs. By matching and verifying the remarks information, the system can ensure that revenue sharing operations are strictly executed according to preset rules, especially for revenue sharing requirements of specific merchants (C platform), ensuring the accuracy and fairness of revenue sharing.

[0138] Through the synergistic effect of the above lightweight verification mechanisms, this application can effectively protect data security in the payment and revenue sharing process without increasing the system burden too much, ensuring that every revenue sharing operation is accurate, legal and compliant.

[0139] Suppose a transaction order is as follows:

[0140] Outgoing account: merchant_123 (Merchant B account), incoming account: platform_456 (Platform C account), remarks: system error: order processing failed; special subsidy: new user discount.

[0141] The system verifies whether a sub-account belongs to a merchant account by querying the internal interface or database. For example, if the account name starts with "merchant_", it is determined to be a merchant account. In this example, "merchant_123" matches the characteristics of a merchant account and passes the verification.

[0142] Verify whether the sub-account receiving the payment belongs to the platform account by querying the internal interface or database. For example, if the account starts with "platform_", it is determined to be a platform account. In this example, "platform_456" matches the characteristics of a platform account and passes the verification.

[0143] If the sub-account receiving the payment is a platform account, it is automatically deemed legitimate. If the sub-account receiving the payment is not a platform account, further analysis of the remarks is required. In this example, the sub-account receiving the payment is a platform account, so no remarks analysis is needed, and it is automatically deemed legitimate.

[0144] When the sub-account receiving the payment is not a platform account, for example, the transaction order information is:

[0145] Outgoing account: merchant_123 (Merchant B account), incoming account: other_account (non-platform account), remarks: system error: order processing failed; special subsidy: new user discount.

[0146] When verifying the account information, merchant_123 is the merchant account, and the verification was successful.

[0147] When verifying incoming sub-accounts, if other_account is not a platform account, the remarks need to be parsed.

[0148] Check if the remarks contain one of the following keywords:

[0149] System anomaly markers (such as "system anomaly"), special subsidy policies (such as "special subsidies"), and commission-free clauses agreed upon by the platform and merchants (such as "commission-free clauses"). In this example, the remarks include "system anomaly" and "special subsidies," which meet at least one of the conditions and are therefore deemed reasonable.

[0150] Optionally, after performing the atomic operation based on the modified transaction order in step 1062, the process further includes:

[0151] Step 1063: If the atomic operation fails to execute, the transaction rollback mechanism is triggered to undo the executed atomic operation.

[0152] Step 1064: Based on the transaction order corresponding to the unsuccessful atomic operation, generate a commission payment execution failure alarm message and send it to the preset receiving terminal.

[0153] In the above embodiments of this application, such as Figure 3 As shown, when an atomic operation fails, the system can trigger a transaction rollback and generate a fault alarm through the following process to ensure fund security and operational traceability. Specifically:

[0154] Taking a corrected transaction as an example, the transaction rollback mechanism is implemented as follows:

[0155] 1. Transaction initialization:

[0156] The atomic operations of deducting funds from the merchant's account and transferring funds to the platform's account are performed by wrapping all operations in a database transaction to ensure atomicity.

[0157] 2. Fault detection and rollback:

[0158] The trigger condition is that any atomic operation throws an exception (such as the platform account becoming unavailable). The rollback logic is to catch the exception, perform a database rollback, and undo the executed operations.

[0159] 3. Final state verification:

[0160] Merchant account balance: 100.0 (no deduction, due to rollback).

[0161] Platform account balance: 0.0 (not credited, due to rollback).

[0162] Transaction logs: Record fault information and rollback status.

[0163] The final generated fault alarm information will include core fields such as timestamp, order number, error reason (platform account unavailable), and operation status (rollback successful). The alarm information will then be written to the `alerts` table in the database, simulating reception by a preset terminal.

[0164] Optionally, when it is detected that the amount of commission to be transferred exceeds the upper limit of the commission rate for the total transaction amount, the following measures are also included:

[0165] Step 107: Based on the transaction order corresponding to the commission amount to be transferred that exceeds the upper limit of the commission ratio of the total transaction amount, generate commission transfer over-limit alarm information and send the commission transfer over-limit alarm information to the preset receiving terminal.

[0166] In the above embodiments of this application, for scenarios involving excessive commission payments, the following process can be used to generate and send alarms, ensuring compliance and rapid risk response. Specifically:

[0167] 1. The maximum commission rate is determined as the highest commission rate stipulated in the agreement signed between the platform and the merchant (e.g., 5%).

[0168] 2. Calculation of the amount to be transferred for commission: The commission amount is calculated based on the total transaction amount (e.g., if the total transaction amount is 200 yuan, the commission should be 10 yuan at 5%).

[0169] 3. Exceeding Limit Detection: An alarm is triggered when the calculated commission amount exceeds the agreement limit.

[0170] To address this, the commission amount is calculated based on the total transaction amount and system rules, compared to the agreed-upon limit, to determine if it has exceeded the limit. Details of any exceeding the limit (amount, percentage, time, etc.) are then packaged and communicated to relevant personnel via email / SMS / system message. This allows for real-time monitoring of commission compliance, preventing legal risks and merchant disputes arising from exceeding the limit, while also improving risk control response efficiency.

[0171] By applying the technical solution of this embodiment, a logical equation is constructed in which the total amount of funds transferred out by the payee equals the total amount of funds transferred in by the payee, and the change in funds in the third-party account is zero (A out = B in ∧ C in = 0), thereby achieving real-time compliance verification of each transaction's accounting. This mechanism runs continuously during transaction execution, ensuring that the flow of funds always meets the preset equation constraints. The system adopts an event-driven architecture design. When the accounting equation is not met or an anomaly is detected, a preset processing flow is automatically triggered. This process is entirely executed through the system's built-in rule engine, completing the entire automated operation from anomaly detection to processing instruction issuance without manual intervention. For original transaction orders, the system implements a signature-free dynamic parameter matching mechanism. By constructing a four-tuple parameter model containing (merchant identifier, transaction type, amount threshold, time window), the system compares the matching degree of the current transaction parameters with historical benchmark parameters in real time during transaction execution, thereby achieving dynamic verification of transaction legality. The system innovatively defines related transaction operations as indivisible atomic units, specifically constructing refund operations and original payment operations as a logically integrated transaction. By employing database transaction management technology, the system ensures that the combined operations either execute entirely successfully or are completely rolled back, thus maintaining the consistency of the funds account. To improve batch processing efficiency, the system also encapsulates multiple atomic operations into a standardized set of combined instructions. This instruction set adopts the Witness Treasure batch API specification commonly used by financial institutions, achieving standardized processing of various transaction types through a unified instruction template, while maintaining seamless integration with the bank's core system. Furthermore, the system can implement all functional modules based on the standard funds interface provided by the bank, without relying on any third-party payment channels. By integrating the real-time clearing interfaces of multiple banks, a direct connection channel covering mainstream financial institutions is built, ensuring the real-time nature and security of fund transfers.

[0172] Furthermore, as Figure 1 In terms of specific implementation, this application provides a real-time payment and billing error correction device, such as... Figure 4 As shown, the device includes:

[0173] The revenue sharing monitoring module 201 is used to monitor in real time the original commission bill generated by the platform based on the transaction order when the user initiates a transaction order to the merchant during the transaction process between the user and the merchant through the O2O model. The transaction order corresponds to a total transaction amount, and the original commission bill includes the commission amount to be transferred from the total transaction amount to the platform. The platform has a commission rate and a commission rate cap for the total transaction amount.

[0174] Security verification engine 202 is used to recalculate the platform's receivable commission amount based on the total transaction amount and the platform's receivable commission ratio when it detects that the amount of commission to be transferred exceeds the upper limit of the commission ratio of the total transaction amount.

[0175] The virtual adjustment module 203 is used to generate a virtual adjustment commission bill based on the difference between the commission amount receivable and the commission amount to be paid, so that when the platform makes commission payments based on transaction orders, it can make joint payments using the original commission bill and the virtual adjustment commission bill to obtain the commission amount receivable.

[0176] Optionally, the virtual adjustment module 203 is further configured to:

[0177] Create a virtual adjustment commission bill associated with the transaction order, wherein the virtual adjustment commission bill corresponds to an adjustment amount;

[0178] The adjustment amount of the virtual adjusted commission bill is determined based on the difference between the amount of commission receivable and the amount of commission to be paid. The adjustment amount includes positive and negative values. When the amount of commission receivable is greater than the amount of commission to be paid, the adjustment amount is positive. When the amount of commission receivable is less than the amount of commission to be paid, the adjustment amount is negative.

[0179] Optionally, the transaction order corresponds to transaction information, and the virtual adjustment module 203 is further used for:

[0180] When the platform makes commission payments based on transaction orders, it monitors the amount of commission already paid out in real time.

[0181] If it is detected that the amount of commission already paid is zero, the rationality of zero commission payment will be reassessed based on the transaction information of the transaction order.

[0182] When the reasonableness assessment result is unreasonable, the platform’s missed commission is corrected through a reverse correction mechanism until the platform receives the commission amount due.

[0183] Optionally, the virtual adjustment module 203 is further configured to:

[0184] Based on the recalculated platform commission amount, a revised transaction order is generated;

[0185] Atomic operations are performed based on the modified transaction order, wherein the atomic operations include deducting the receivable commission amount from the merchant account, adding the receivable commission amount to the user account, simultaneously deducting the receivable commission amount from the user account, and adding the receivable commission amount to the platform account.

[0186] Optionally, the virtual adjustment module 203 is further configured to:

[0187] Based on the transaction information of the transaction order, verify whether the outgoing sub-account is a merchant account and whether the incoming sub-account is a platform account;

[0188] If the sub-account receiving the payment is not a platform account, then analyze the remarks to confirm whether there is at least one of the following: system anomaly mark, special subsidy policy, or commission-free clause agreed upon by the platform and the merchant.

[0189] If the remarks contain at least one of the following: a system anomaly mark, a special subsidy policy, or a commission-free clause agreed upon by the platform and the merchant, the reasonableness assessment result is reasonable. If the billing sub-account is not a merchant account or does not contain a system anomaly mark, a special subsidy policy, or a commission-free clause agreed upon by the platform and the merchant, the reasonableness assessment result is unreasonable.

[0190] Furthermore, embodiments of this application provide another real-time payment splitting error correction device, such as... Figure 5 As shown, the device includes:

[0191] The revenue sharing monitoring module 201 is used to monitor in real time the original commission bill generated by the platform based on the transaction order when the user initiates a transaction order to the merchant during the transaction process between the user and the merchant through the O2O model. The transaction order corresponds to a total transaction amount, and the original commission bill includes the commission amount to be transferred from the total transaction amount to the platform. The platform has a commission rate and a commission rate cap for the total transaction amount.

[0192] Security verification engine 202 is used to recalculate the platform's receivable commission amount based on the total transaction amount and the platform's receivable commission ratio when it detects that the amount of commission to be transferred exceeds the upper limit of the commission ratio of the total transaction amount.

[0193] The virtual adjustment module 203 is used to generate a virtual adjustment commission bill based on the difference between the commission amount receivable and the commission amount to be paid, so that when the platform makes commission payments based on transaction orders, it can make joint payments using the original commission bill and the virtual adjustment commission bill to obtain the commission amount receivable.

[0194] The exception alarm module 204 is used to trigger the transaction rollback mechanism if the atomic operation fails to execute, and to roll back the executed atomic operation based on the transaction rollback mechanism; based on the transaction order corresponding to the failed atomic operation, it generates a commission payment execution failure alarm message and sends it to the preset receiving terminal.

[0195] Optionally, the virtual adjustment module 203 is further configured to:

[0196] Create a virtual adjustment commission bill associated with the transaction order, wherein the virtual adjustment commission bill corresponds to an adjustment amount;

[0197] The adjustment amount of the virtual adjusted commission bill is determined based on the difference between the amount of commission receivable and the amount of commission to be paid. The adjustment amount includes positive and negative values. When the amount of commission receivable is greater than the amount of commission to be paid, the adjustment amount is positive. When the amount of commission receivable is less than the amount of commission to be paid, the adjustment amount is negative.

[0198] Optionally, the transaction order corresponds to transaction information, and the virtual adjustment module 203 is further used for:

[0199] When the platform makes commission payments based on transaction orders, it monitors the amount of commission already paid out in real time.

[0200] If it is detected that the amount of commission already paid is zero, the rationality of zero commission payment will be reassessed based on the transaction information of the transaction order.

[0201] When the reasonableness assessment result is unreasonable, the platform’s missed commission is corrected through a reverse correction mechanism until the platform receives the commission amount due.

[0202] Optionally, the virtual adjustment module 203 is further configured to:

[0203] Based on the recalculated platform commission amount, a revised transaction order is generated;

[0204] Atomic operations are performed based on the modified transaction order, wherein the atomic operations include deducting the receivable commission amount from the merchant account, adding the receivable commission amount to the user account, simultaneously deducting the receivable commission amount from the user account, and adding the receivable commission amount to the platform account.

[0205] Optionally, the virtual adjustment module 203 is further configured to:

[0206] Based on the transaction information of the transaction order, verify whether the outgoing sub-account is a merchant account and whether the incoming sub-account is a platform account;

[0207] If the sub-account receiving the payment is not a platform account, then analyze the remarks to confirm whether there is at least one of the following: system anomaly mark, special subsidy policy, or commission-free clause agreed upon by the platform and the merchant.

[0208] If the remarks contain at least one of the following: a system anomaly mark, a special subsidy policy, or a commission-free clause agreed upon by the platform and the merchant, the reasonableness assessment result is reasonable. If the billing sub-account is not a merchant account or does not contain a system anomaly mark, a special subsidy policy, or a commission-free clause agreed upon by the platform and the merchant, the reasonableness assessment result is unreasonable.

[0209] Optionally, the anomaly alarm module 204 is further configured to:

[0210] Based on the transaction order corresponding to the commission amount to be transferred that exceeds the upper limit of the commission rate for the total transaction amount, a commission transfer over-limit alarm message is generated and sent to a preset receiving terminal.

[0211] It should be noted that other corresponding descriptions of the functional units involved in the payment splitting error real-time correction device provided in this application embodiment can be found in the following references. Figures 1 to 3 The corresponding descriptions in the method will not be repeated here.

[0212] Based on the above, Figures 1 to 3 Accordingly, this application also provides a medium on which a computer program is stored, which, when executed by a processor, implements the above-described method. Figures 1 to 3 The method shown is for real-time correction of payment splitting errors.

[0213] Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile medium (such as a CD-ROM, USB flash drive, or portable hard drive) and includes several instructions to cause a computer device (such as a personal computer, server, or network device) to execute the methods described in the various implementation scenarios of this application.

[0214] Based on the above, Figures 1 to 3 The method shown, and Figure 4 and 5 To achieve the above objectives, the present application also provides a computer device, specifically a personal computer, server, network device, etc., as shown in the virtual device embodiment. This computer device includes a medium and a processor; the medium stores a computer program; the processor executes the computer program to achieve the above-described objectives. Figures 1 to 3 The method shown is for real-time correction of payment and revenue sharing errors.

[0215] Optionally, the computer device may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Bluetooth interfaces, Wi-Fi interfaces), etc.

[0216] Those skilled in the art will understand that the computer device structure provided in this embodiment does not constitute a limitation on the computer device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0217] The medium may also include an operating system and a network communication module. The operating system is a program that manages and stores the hardware and software resources of a computer device, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the medium, as well as communication with other hardware and software within the physical device.

[0218] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented using software plus necessary general-purpose hardware platforms, or it can be implemented using hardware to monitor in real time the original commission bill generated based on the transaction order when a user initiates a transaction order with a merchant; when it is detected that the commission amount to be paid in the original commission bill exceeds the commission ratio limit of the total transaction amount, the platform's receivable commission amount is recalculated based on the total transaction amount and the platform's receivable commission ratio; based on the difference between the receivable commission amount and the commission amount to be paid, a virtual adjusted commission bill is generated, so that when the platform makes commission payments based on the transaction order, the receivable commission amount is obtained by jointly making payments using the original commission bill and the virtual adjusted commission bill. This allows for early monitoring and corrective measures to be taken before the actual commission allocation, improving the accuracy of the transaction process.

[0219] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of a preferred embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing this application. Those skilled in the art will understand that the modules in the apparatus of the embodiment can be distributed within the apparatus of the embodiment as described, or can be modified to be located in one or more apparatuses different from this embodiment. The modules of the above-described embodiment can be combined into one module, or further divided into multiple sub-modules.

[0220] The serial numbers in this application are for descriptive purposes only and do not represent the superiority or inferiority of any particular implementation scenario. The above disclosures are merely a few specific implementation scenarios of this application; however, this application is not limited thereto, and any modifications that can be made by those skilled in the art should fall within the protection scope of this application.

Claims

1. A method for real-time correction of payment splitting errors, characterized in that, The method includes: During the process of transactions between users and merchants through the O2O model, when a user initiates a transaction order to a merchant, the platform's original commission bill generated based on the transaction order is monitored in real time. The transaction order corresponds to a total transaction amount, and the original commission bill includes the commission amount to be transferred from the total transaction amount to the platform. The platform has a commission rate and a commission rate cap corresponding to the total transaction amount. When it is detected that the amount of commission to be paid exceeds the upper limit of the commission rate for the total transaction amount, the commission amount receivable by the platform will be recalculated based on the total transaction amount and the platform's commission rate. Based on the difference between the amount of commission receivable and the amount of commission to be paid, a virtual adjusted commission bill is generated so that when the platform makes commission payments based on transaction orders, the amount of commission receivable is obtained by jointly making payments using the original commission bill and the virtual adjusted commission bill.

2. The method according to claim 1, characterized in that, The process of generating a virtual adjusted commission bill based on the difference between the amount of commission receivable and the amount of commission to be paid includes: Create a virtual adjustment commission bill associated with the transaction order, wherein the virtual adjustment commission bill corresponds to an adjustment amount; The adjustment amount of the virtual adjusted commission bill is determined based on the difference between the amount of commission receivable and the amount of commission to be paid. The adjustment amount includes positive and negative values. When the amount of commission receivable is greater than the amount of commission to be paid, the adjustment amount is positive. When the amount of commission receivable is less than the amount of commission to be paid, the adjustment amount is negative.

3. The method according to claim 1, characterized in that, The transaction order corresponds to transaction information, and the method further includes: When the platform makes commission payments based on transaction orders, it monitors the amount of commission already paid out in real time. If it is detected that the amount of commission already paid is zero, the rationality of zero commission payment will be reassessed based on the transaction information of the transaction order. When the reasonableness assessment result is unreasonable, the platform’s missed commission is corrected through a reverse correction mechanism until the platform receives the commission amount due.

4. The method according to claim 3, characterized in that, Users have corresponding user accounts, merchants have corresponding merchant accounts, and the platform has corresponding platform accounts. The reverse correction mechanism corrects for any missed commissions collected by the platform, including: Based on the recalculated platform commission amount, a revised transaction order is generated; Atomic operations are performed based on the modified transaction order, wherein the atomic operations include deducting the receivable commission amount from the merchant account, adding the receivable commission amount to the user account, simultaneously deducting the receivable commission amount from the user account, and adding the receivable commission amount to the platform account.

5. The method according to claim 3, characterized in that, The transaction information includes remarks, outgoing sub-account, and incoming sub-account. The reassessment of the rationality of zero-commission payments based on transaction order information includes: Based on the transaction information of the transaction order, verify whether the outgoing sub-account is a merchant account and whether the incoming sub-account is a platform account; If the sub-account receiving the payment is not a platform account, then analyze the remarks to confirm whether there is at least one of the following: system anomaly mark, special subsidy policy, or commission-free clause agreed upon by the platform and the merchant. If the remarks contain at least one of the following: a system anomaly mark, a special subsidy policy, or a commission-free clause agreed upon by the platform and the merchant, the reasonableness assessment result is reasonable. If the billing sub-account is not a merchant account or does not contain a system anomaly mark, a special subsidy policy, or a commission-free clause agreed upon by the platform and the merchant, the reasonableness assessment result is unreasonable.

6. The method according to claim 4, characterized in that, After performing atomic operations based on the modified transaction order, the method further includes: If the atomic operation fails to execute, the transaction rollback mechanism is triggered, and the executed atomic operation is rolled back based on the transaction rollback mechanism. Based on the transaction orders corresponding to the atomic operations that failed to execute, a commission payment execution failure alarm message is generated and sent to the preset receiving terminal.

7. The method according to any one of claims 1 to 6, characterized in that, When the method detects that the amount of commission to be transferred exceeds the upper limit of the commission rate for the total transaction amount, the method further includes: Based on the transaction order corresponding to the commission amount to be transferred that exceeds the upper limit of the commission rate for the total transaction amount, a commission transfer over-limit alarm message is generated and sent to a preset receiving terminal.

8. A real-time payment splitting error correction device, characterized in that, The device includes: The revenue sharing monitoring module is used to monitor in real time the original commission bill generated by the platform based on the transaction order when a user initiates a transaction order to a merchant during the O2O transaction process between users and merchants. The transaction order corresponds to a total transaction amount, and the original commission bill includes the commission amount to be transferred from the total transaction amount to the platform. The platform has a corresponding commission rate and a commission rate cap for the total transaction amount. The security verification engine is used to recalculate the platform's receivable commission amount based on the total transaction amount and the platform's receivable commission rate when it detects that the amount of commission to be transferred exceeds the upper limit of the commission rate for the total transaction amount. The virtual adjustment module is used to generate a virtual adjusted commission bill based on the difference between the commission amount receivable and the commission amount to be paid. This allows the platform to use both the original commission bill and the virtual adjusted commission bill to make joint payments when making commission payments based on transaction orders.

9. A medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the method for real-time correction of payment splitting errors as described in any one of claims 1 to 7.

10. A computer device, comprising a medium, a processor, and a computer program stored on the medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method for real-time correction of payment splitting errors as described in any one of claims 1 to 7.

Images