A real-time distribution and risk monitoring method based on multi-dimensional aggregated payment

Abstract

The present application relates to the field of electronic payment and financial technology, and particularly relates to a real-time account distribution and risk monitoring method based on multi-dimensional aggregated payment. The method comprises: obtaining a payment request and verification information to generate a payment flow, receiving marketing activity rules and merchant account distribution agreements based on the payment flow, and generating account distribution information by fusing marketing coupon cancellation status; further receiving multi-dimensional risk control data based on the account distribution information and matching merchant historical transaction data to complete order status update and account distribution state control; then performing account distribution settlement processing and marketing coupon cancellation status association processing based on the account distribution state control result, and generating a closed-loop processing record. The present application realizes the continuous connection of payment flow, account distribution processing and risk control, effectively improving the consistency and processing stability of real-time account distribution and risk monitoring.

Description

Technical Field

[0001] This invention relates to the field of electronic payment and financial technology, and in particular to a real-time revenue sharing and risk monitoring method based on multi-dimensional aggregated payment. Background Technology

[0002] In the fields of electronic payment and fintech, existing solutions typically revolve around payment request access, payment transaction generation, revenue sharing rule execution, risk control, and result notification. These solutions suffer from limitations such as insufficient coordination between marketing campaign rules and merchant revenue sharing agreements, a disconnect between marketing coupon redemption status and revenue sharing results, and a lack of coordination between revenue sharing status control and subsequent accounting processing. Existing methods often operate along separate paths for payment processing, revenue sharing processing, and risk control, or rely on independent rule configurations, independent risk control judgments, and independent notification chains. In scenarios where payment transactions, revenue sharing information, and revenue sharing status control results are continuously transmitted, inconsistencies in the revenue sharing pending settlement processing entry point and unstable correlation with marketing coupon redemption status can easily arise, making it difficult to achieve stable real-time revenue sharing and risk monitoring. For the joint processing of payment transaction records, revenue sharing information, revenue sharing status control results, and marketing coupon redemption status, existing technologies generally suffer from fragmented receiving, matching, judgment, control, and recording processes. This makes it difficult to establish a consistent process for generating payment transaction records, revenue sharing information, revenue sharing status control, revenue sharing pending settlement processing, marketing coupon redemption status association processing, and closed-loop processing records in real-time revenue sharing and risk monitoring applications based on multi-dimensional aggregated payments. This results in insufficient continuity of the processing links before notifying relevant parties and merchants, and further affects the recording and processing connections in related production, settlement, and transaction processes. Summary of the Invention

[0003] To address the aforementioned technical problems, this invention provides a real-time revenue sharing and risk monitoring method based on multi-dimensional aggregated payment, comprising: S100: Obtain payment request and verification information, perform order data assembly and payment request submission processing, and execute payment transaction record generation and field mapping processing to obtain payment transaction record; S200. Based on the payment transaction, perform marketing activity rule reception and merchant revenue sharing agreement reception processing, and execute marketing coupon redemption status information reception, data format adaptation, consistency judgment processing, and generate revenue sharing information. S300. Based on the revenue sharing information, perform merchant historical transaction data matching processing, and execute response trigger condition determination, order status update and revenue sharing status control processing to generate revenue sharing status control results. S400. Based on the revenue sharing status control result, perform revenue sharing pending settlement processing and marketing coupon redemption status association processing, and execute pending settlement notification generation and notification return processing to relevant parties and merchants to generate closed-loop processing records.

[0004] Furthermore, the process of assembling order data and submitting payment requests includes: The order data assembly process includes assembling user identity information, bill amount and transaction information as basic fields, order identifier, merchant identifier and payment method as control fields, and verification status, matching status and the exception flag as status fields, into unified order data in a preset order. The payment request submission process includes reading the payment method, bill amount, merchant identifier, and order identifier from the order data to organize them into submission content that the payment channel can accept, and reading the verification status and matching status from the order data again before submission. When both are valid, the submission is executed.

[0005] Furthermore, the field mapping process includes: The field mapping process includes extracting user identity information, bill amount, transaction information, payment method, verification status, matching status, and anomaly marker from the order data, mapping them to the corresponding user identity field, amount field, transaction field, payment field, and status field in the payment transaction record, and generating a payment transaction record containing the user identity information, the verification status, the matching status, and the anomaly marker.

[0006] Furthermore, the process of receiving and processing marketing campaign rules and merchant revenue sharing agreements includes: The marketing activity rule receiving and processing includes reading the merchant identifier, transaction information and bill amount from the payment transaction record, locating the applicable marketing activity rules according to the merchant identifier and transaction time, and filtering out invalid and mismatched rules according to the applicable time of the activity and the scope of applicable merchants. The merchant revenue sharing agreement receiving and processing includes reading the merchant identifier, order identifier, and payment method from the payment transaction data, extracting the agreement effective time, revenue sharing party identifier, revenue sharing conditions, and revenue sharing amount recording method from the merchant's registered agreements, and removing agreements that are ineffective, expired, or do not correspond to the current payment method.

[0007] Furthermore, the process of receiving marketing coupon redemption status information, adapting data formats, and performing consistency checks includes: The marketing coupon redemption status information receiving and processing includes reading the order identifier, user identity information and transaction information from the payment flow, extracting the coupon identifier, redemption status and redemption time corresponding to the current order identifier, and registering the temporal relationship between the redemption status and the payment status; The data format adaptation process includes transcribing the fields registered by activity dimension in the marketing activity rules into fields arranged by order dimension, transcribing the fields registered by agreement dimension in the merchant revenue sharing agreement into fields arranged by revenue sharing party dimension, transcribing the fields registered by coupon dimension in the marketing coupon redemption status information into fields arranged by order correspondence, and combining them with payment transaction records into a unified record format. The consistency judgment process includes determining the consistency between payment status and redemption status, the consistency between the activity's applicable time and the agreement's effective time, the consistency between the order identifier and the coupon identifier, and the consistency between the activity's corresponding revenue sharing rules and the agreement's revenue sharing conditions, and writing a matching flag, a suspended flag, or a blocking flag.

[0008] Furthermore, the process of matching merchants' historical transaction data includes: The merchant historical transaction data matching includes associating and matching the merchant identifier corresponding to the current transaction with the merchant's existing transaction records, extracting the transaction time distribution, order status distribution, payment status distribution, reconciliation status distribution and anomaly marker distribution, and comparing them item by item with the fields corresponding to the current transaction, and registering high-attention matching items or regular matching items.

[0009] Furthermore, the process of determining the trigger conditions for implementing response measures, updating order status, and controlling the revenue sharing status includes: The trigger condition determination of the response measures includes determining whether the current transaction enters the normal processing, pending verification processing or high-risk processing based on the risk category field and classification basis field in the risk score, and outputting response measures such as allowing entry into subsequent processing, triggering identity verification, suspending some account functions, restricting transaction behavior or suspending the transaction. The order status update includes rewriting the current transaction's order status to a pending processing status, a pending verification status, or a suspended status based on the judgment result of the response trigger condition. The revenue sharing status control process includes, based on the updated order status and risk score, combined with the revenue sharing amount record, revenue sharing party identifier and write-off status in the revenue sharing information, writing the revenue sharing information corresponding to the current transaction into a state that allows entry into the revenue sharing pending settlement processing state, a state that suspends processing, or a state that blocks processing.

[0010] Furthermore, the process of processing the pending settlement of revenue sharing includes: The pre-settlement processing includes being initiated by the pre-settlement processing unit when it receives the pre-settlement status control result and the current transaction's pre-settlement status is allowed to enter the pre-settlement processing status. It reads the order identifier, pre-settlement party identifier, and pre-settlement amount record, and, in conjunction with the order status and risk category fields, registers the pre-settlement amount record as a pre-settlement amount record and writes it into the pre-settlement processing context, or writes the transaction into the pending verification hold record or the suspended hold record.

[0011] Furthermore, the process of associating the marketing coupon redemption status includes: The marketing coupon redemption status association processing includes reading the order identifier, activity identifier, revenue amount record, and revenue party identifier from the revenue sharing status control result, and combining them with the previously established redemption status correspondence. When the current transaction is in the allowed revenue sharing pending settlement processing state, a one-to-one correspondence is established between the redemption status, order identifier, activity identifier, and revenue sharing amount record and written into the association processing context. When the current transaction is in the pending verification state or suspended state, a pending verification flag or a suspended flag is written accordingly and the redemption status correspondence is locked.

[0012] Furthermore, the process of generating pending settlement notifications and processing the responses from relevant parties and merchants includes: The pending settlement notification generates an order identifier, a revenue sharing party identifier, a pending settlement balance update result, an order status, and a revenue sharing status from the read status update result. It also assembles a revenue sharing record identifier and an associated processing record identifier to generate a pending settlement notification content that includes an order identifier, a revenue sharing party identifier, a pending settlement amount record, a revenue sharing status, and a notification generation time. The notification process for relevant parties includes locating the corresponding receiving end according to the revenue sharing party identifier and sending the settlement notification content to the corresponding receiving link. If the receiving end does not respond immediately, an unconfirmed flag is written and an entry point for resending is reserved. The merchant-side return processing includes reading the order identifier, payment transaction record update result, order status, accounting status, and pending settlement balance update result. Combined with the corresponding relationship of the verification status, the merchant-side return content containing the corresponding relationship of payment status, order status, accounting status, pending settlement processing status, and verification status is assembled and sent back to the merchant-side.

[0013] The key innovations of this invention include: (1) Based on the payment flow, the marketing activity rules and merchant revenue sharing agreement are received and processed, and the marketing coupon redemption status information is received, data format is adapted, and consistency is judged and processed to generate revenue sharing information. The marketing activity rules, merchant revenue sharing agreement and marketing coupon redemption status information are pushed into the same revenue sharing information generation link.

[0014] (2) Based on the revenue sharing information, multi-dimensional risk control data is received and matched with the merchant's historical transaction data. Then, the trigger condition for the response measures is determined, the order status is updated and the revenue sharing status is controlled. The revenue sharing status control result is generated and the merchant's historical transaction data matching and revenue sharing status control are connected into a continuous processing link for the current transaction.

[0015] (3) Based on the revenue sharing status control result, perform revenue sharing pending settlement processing and marketing coupon redemption status association processing, and execute pending settlement notification generation and notification return processing to relevant parties and merchants, generate closed-loop processing records, and connect revenue sharing pending settlement processing, marketing coupon redemption status association processing and closed-loop processing record generation as subsequent processing links.

[0016] The following are its main beneficial effects: (1) In response to the problems of insufficient coordination between marketing activity rules and merchant revenue sharing agreements and the separation between marketing coupon redemption status and revenue sharing results in the existing solutions, marketing activity rules, merchant revenue sharing agreements and marketing coupon redemption status information are uniformly received on the basis of the payment flow, and data format adaptation and consistency judgment are completed, so that the revenue sharing information is formed within the same transaction context, thereby providing a unified input basis for the subsequent revenue sharing status control and closed-loop processing record generation.

[0017] (2) In response to the problem that risk control and revenue sharing are executed separately in the existing scheme and that risk judgment is difficult to directly affect the current transaction, by placing the multi-dimensional risk control data reception, merchant historical transaction data matching, response trigger condition determination, order status update and revenue sharing status control in the same processing link, the risk judgment result is directly implemented on the order status and revenue sharing status control result of the current transaction, so that the subsequent revenue sharing pending settlement processing has a clear status entry.

[0018] (3) In response to the problems of inconsistent entry points for pending settlement processing, unstable association of marketing coupon redemption status, and scattered foundations for subsequent notification links in the existing scheme, the pending settlement processing and marketing coupon redemption status association processing are first performed on the basis of the aforementioned settlement status control results, and then the pending settlement notification generation and notification return processing are performed to ensure that the closed-loop processing record is continuously formed at the current transaction level, thereby ensuring that the settlement processing chain, marketing coupon redemption status chain and notification link are kept in a consistent and connected manner.

[0019] (4) Through the continuous generation of the payment flow, splitting information, splitting status control results and closed-loop processing records, a clear record link is formed between the payment request submission processing, splitting information generation, splitting status control processing and subsequent return processing. This is suitable for continuous processing and subsequent review in real-time splitting and risk monitoring scenarios based on multi-dimensional aggregated payment.

[0020] (5) The closed-loop processing record is used to record the payment flow generation, the split account information generation, the split account status control processing, the split account pending settlement processing, the marketing coupon redemption status association processing, and the notification of relevant parties and the merchant terminal return processing. This makes the problem of the scattered receiving, matching, judging, controlling and recording links in the prior art correspondingly organized, and makes the connection between the transaction processing process, the settlement processing process and the recording processing process clearer. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating a real-time revenue sharing and risk monitoring method based on multi-dimensional aggregated payment, provided in an embodiment of this application. Detailed Implementation

[0022] Example 1: Refer to Figure 1 This is a flowchart illustrating a real-time revenue sharing and risk monitoring method based on multi-dimensional aggregated payment provided by an embodiment of the present invention. The process may include at least steps S100-S400: S100: Obtain payment request and verification information, perform order data assembly and payment request submission processing, and execute payment transaction record generation and field mapping processing to obtain payment transaction record; S200. Based on the payment transaction, perform marketing activity rule reception and merchant revenue sharing agreement reception processing, and execute marketing coupon redemption status information reception, data format adaptation, consistency judgment processing, and generate revenue sharing information. S300. Based on the revenue sharing information, perform merchant historical transaction data matching processing, and execute response trigger condition determination, order status update and revenue sharing status control processing to generate revenue sharing status control results. S400. Based on the revenue sharing status control result, perform revenue sharing pending settlement processing and marketing coupon redemption status association processing, and execute pending settlement notification generation and notification return processing to relevant parties and merchants to generate closed-loop processing records.

[0023] Step S100 includes at least steps S110-S130: S110. Obtain payment request and verification information, process payment request records, and obtain payment request records.

[0024] Specifically, the payment request is a request data initiated by the user on the merchant's end and sent into the current transaction processing flow via the aggregated payment access link. The payment request carries at least the order identifier, merchant identifier, bill amount, payment method indication, time information, and terminal source information. The verification information consists of pre-stored verification data and real-time received data corresponding to the payment request, including at least user identity information, merchant contract information, payment channel availability information, order status information, and transaction time consistency information. Understandably, the payment request and verification information do not directly enter subsequent verification but first enter the payment request record processing. The payment request record processing is executed by the aggregated payment access side. The access timing is when the merchant submits a transaction and triggers the establishment of the payment link. The access location is the connection point between the aggregated payment access link and the merchant transaction link. The access method involves receiving, sorting, associating, and recording the payment request and verification information. Sorting is used to fix the order of reception corresponding to the same order identifier; association is used to bind the payment request and verification information of the same transaction to the same record unit; and recording is used to form a payment request record that can be called subsequently.

[0025] Furthermore, during the payment request record processing, the payment request is first split into fields, including order identifier, merchant identifier, bill amount, payment method indication, and time information. Then, the verification information is extracted to obtain user identity information, merchant contract information, payment channel availability information, and order status information. Next, same order number aggregation is performed, writing the payment request fields and verification information fields under the same order identifier into the same payment request record. Finally, receiving time registration is performed, writing the payment request entry time, verification information entry time, and record formation time into the payment request record. In cases of missing fields, abnormal receiving order, or duplicate entries of the same order identifier, the payment request record processing does not terminate the recording process. Instead, an exception marker is written into the payment request record, and the original received content and the exception marker are retained for subsequent payment request verification. For cases where a merchant submits a payment request repeatedly but the order status information indicates that payment has not yet been completed, the system retains the latest payment request and marks the previous record as a history record. For cases where the order status information indicates that payment has been completed or the order has been closed, the system writes the payment request record to an interception flag. When subsequent steps read the order, the system will either reject the submission or stop issuing payment requests based on the order status information.

[0026] In a feasible engineering embodiment, the chain store merchant receives a user's payment action in a checkout scenario. The merchant submits a payment request to the aggregated payment access link, including an order identifier, merchant identifier, bill amount, and payment method indication. Simultaneously, it retrieves corresponding verification information from the merchant's contract information and payment channel availability information. After receiving the above data, the aggregated payment access side writes the payment request and verification information into the same payment request record according to the order identifier, and registers the user's identity information, order status information, and transaction time consistency information in this record. After this processing, the output field is named "Payment Request Record," which is directly called as the "Payment Request Record" in S120. At the same time, the payment request record also serves as the sole input carrier for subsequent steps within S100, maintaining the correspondence between the payment request, verification information, and anomaly flags.

[0027] S120. Based on the payment request record, perform payment request verification, payment method matching, and order data assembly processing to generate order data.

[0028] Specifically, the payment request verification is a process of comparing and judging the payment request content and verification information in the payment request record item by item. The verification content includes at least the legality of the order identifier, the matching of merchant contract information, the integrity of user identity information, the validity of the bill amount, the accessibility of payment channel availability information, and the submitability of order status information. The payment method matching is a process of determining the payment method corresponding to the current transaction within the range of available payment channels based on the payment method indication, merchant contract information, and payment channel availability information in the payment request record. The order data assembly process is a process of writing the verified and matched payment method records into the order data in a unified order. The order data here is not a simple concatenation of fields, but a centralized assembly of the core fields required for subsequent submission and transaction record generation of the current transaction. After assembly, it includes at least user identity information, bill amount, transaction information, order identifier, merchant identifier, payment method, and verification status.

[0029] Furthermore, the payment request verification is performed in the order of basic fields first, followed by status fields. First, the order identifier, merchant identifier, and bill amount in the payment request record are read to determine if any fields are missing, conflicting, or consistent with the corresponding content in the verification information. Then, user identity information, merchant contract information, payment channel availability information, and order status information are read to determine if the current transaction is in a submitable state. For records that pass verification, payment method matching is initiated. For records that fail verification but can be completed, a "to be completed" flag is written, and the current record is retained. For records that fail verification and whose order status information does not allow submission, a "prohibited submission" flag is written, and subsequent submissions are stopped. During payment method matching, the payment method indication is read first, then the merchant contract information is used to determine if the merchant has the access conditions for the corresponding payment method, and then the payment channel availability information is used to determine if the corresponding payment channel is in a callable state. When the payment method indication is unavailable, alternative matching is performed according to the order of payment methods already enabled in the merchant contract information, and the alternative result is written to the matching field of the payment request record. Understandably, the payment method matching is not an arbitrary selection of all payment methods, but a limited matching based on the received payment method instructions, the registered merchant contract information, and the available payment channels at the current moment.

[0030] During the order data assembly and processing phase, the system reads verified payment request records that have completed payment method matching. User identity information, bill amount, and transaction information are used as the basic fields of the order data. Order identifier, merchant identifier, and payment method are used as the control fields of the order data. Verification status, matching status, and exception flags are used as the status fields of the order data. These fields are then assembled into unified order data according to a preset field order. The transaction information is used to identify the transaction context corresponding to the current transaction's time information, terminal source information, and order status information. The verification status indicates whether the payment request verification has been completed, and the matching status indicates the payment method matching result. If the same order identifier has historical records, the order data assembly and processing only reads the latest valid payment request record and writes the historical record reference relationship into the order data so that S130 can identify whether it is a retry transaction when the payment request is submitted. In the above engineering embodiment, in a transaction scenario initiated by a chain store merchant, the system first verifies the payment request based on the merchant's contract information, bill amount, and order status information. Then, it matches the currently available payment methods from the available payment channel information. Finally, it assembles the user's identity information, bill amount, transaction information, order identifier, merchant identifier, and payment method into order data. After this processing, the output field is named "Order Data," which is directly called as "Order Data" in S130. This order data also provides an order-level basic identifier for receiving marketing activity rules and merchant revenue sharing agreements in subsequent steps S200.

[0031] S130. Based on the order data, submit a payment request, generate payment transaction records, and perform field mapping processing to generate payment transaction records.

[0032] Specifically, the payment request submission is the process of sending the order data to the corresponding payment channel according to the matched payment method and triggering payment execution. The payment transaction record generation is the process of collecting and writing transaction return information, channel processing information, and order data after the payment request is submitted. The field mapping process is the process of establishing a correspondence between order data fields and payment transaction record fields. Here, the payment transaction record is the formal record of the current transaction in the payment chain, which includes at least the order identifier, merchant identifier, payment method, bill amount, payment status, submission time, return time, and transaction record identifier. The field mapping process is used to convert the order data assembled in S120 into payment transaction record fields that can be directly called by S200, and retain the previous verification status, matching status, and exception flags.

[0033] Furthermore, when a payment request is submitted, the system reads the payment method, bill amount, merchant identifier, and order identifier from the order data, organizes them into submission content acceptable to the payment channel, and reads the verification status and matching status from the order data again before submission. If both the verification and matching statuses are valid, submission is executed; if either status is marked as prohibiting submission, submission is aborted and the abort information is written to the pre-recorded payment transaction history. After the payment channel returns, the system reads the return status, return time, and channel-side transaction identifier, and aggregates them with the order identifier, merchant identifier, bill amount, and payment method from the order data to form the initial payment transaction history. In cases where the payment channel does not return immediately, the system first generates a pending confirmation payment transaction history, writing the submission time, order identifier, merchant identifier, and payment method into the pending confirmation field. The payment status and return time are then added after the channel returns. In cases of abnormal or duplicate channel returns, the system performs a merging process based on the order identifier and channel-side transaction identifier, retaining only one valid payment transaction history corresponding to the current order data, and writing the other return records into the associated processing record.

[0034] The field mapping process is executed immediately after the payment transaction record is generated. Specifically, user identity information, bill amount, transaction information, payment method, verification status, matching status, and anomaly flag are extracted from the order data and mapped to the user identity field, amount field, transaction field, payment field, and status field in the payment transaction record. Specifically, user identity information is mapped to the user identity field, bill amount to the amount field, time information and terminal source information in the transaction information to the transaction field, payment method to the payment field, and verification status, matching status, and anomaly flag are collectively mapped to the status field. Through this mapping, the payment request and verification information link recorded in S110, the order data link formed in S120, and the payment transaction record link formed in S130 maintain a one-to-one correspondence. Understandably, the payment transaction record is not only stored internally within this main step, but is directly input as the "payment transaction record" in S210 for subsequent reception of marketing activity rules, merchant revenue sharing agreements, and marketing coupon redemption status information. Simultaneously, the order identifier, merchant identifier, payment method, bill amount, and status fields retained in the payment transaction record are also integrated into subsequent processing in S200, S300, and S400. In the aforementioned engineering embodiment for the chain store merchant side, the system submits the transaction to the payment channel corresponding to the matched payment method based on the order data. After receiving the payment status, it generates a payment transaction record and maps the user identity information, bill amount, transaction information, and status fields from the order data into the payment transaction record, forming a unified record for subsequent rule synchronization and integration. After this processing, the output field is named "payment transaction record," which is input as the "payment transaction record" in S210 and serves as the basic data carrier connecting to S200 across main steps.

[0035] In summary, this step links payment requests, verification information, order data, and payment transaction records into a single processing chain in a fixed order. This eliminates the fragmentation of payment request verification, payment method matching, and payment transaction record generation across different record units. Compared to existing methods that only process payment request submissions or order data transmissions, this step continuously retains verification status, matching status, and anomaly flags in the payment transaction record. This provides a common source of input for subsequent reception of marketing activity rules, merchant revenue sharing agreements, and marketing coupon redemption status information. Consequently, subsequent revenue sharing information generation and revenue sharing status control are based on the same transaction record.

[0036] Step S200 includes at least steps S210-S230: S210. Based on the payment transaction record, process the receipt of marketing activity rules, merchant revenue sharing agreement, and marketing coupon redemption status information to obtain rule verification data.

[0037] Specifically, the payment transaction record comes from the payment transaction record generated in S130. The payment transaction record includes at least an order identifier, merchant identifier, payment method, bill amount, payment status, submission time, return time, and transaction identifier, and continues to retain the user identity information, transaction information, verification status, matching status, and anomaly flag from the previous steps. The marketing activity rules are the activity constraints corresponding to the current transaction, including at least an activity identifier, applicable activity time, applicable merchant scope, applicable order scope, corresponding revenue sharing rules, corresponding allocation strategy, and redemption conditions. The merchant revenue sharing agreement is the agreement data pre-registered between the merchant and the revenue sharing party and can be invoked by the current transaction, including at least an agreement identifier, agreement effective time, revenue sharing party identifier, revenue sharing order, revenue sharing conditions, and revenue sharing amount recording method. The marketing coupon redemption status information is the coupon status data associated with the current transaction, including at least a coupon identifier, coupon source identifier, redemption status, redemption time, and corresponding order identifier. Understandably, this step does not involve receiving the rules first and then processing them separately from the payment transaction record. Instead, it uses the payment transaction record as the sole transaction entry point, and uses the order identifier, merchant identifier, and payment status in the payment transaction record to locate the marketing activity rules, merchant revenue sharing agreement, and marketing coupon redemption status information corresponding to the current transaction, and writes these three types of information into the same processing chain.

[0038] Furthermore, the marketing campaign rule receiving and processing first reads the merchant identifier, transaction information, and bill amount from the payment transaction history. If the payment status is "submitted" and the return time is registered, it locates the applicable marketing campaign rules for the current transaction based on the merchant identifier and transaction time. If multiple marketing campaign rules exist, invalid rules are first filtered out based on the applicable time of the campaign, then mismatched rules are filtered out based on the applicable merchant scope and applicable order scope. Finally, the remaining rules are mapped to the order identifier based on the campaign identifier. The merchant revenue sharing agreement receiving and processing proceeds simultaneously with the above processing. It first reads the merchant identifier, order identifier, and payment method from the payment transaction history, then extracts the agreement's effective time, revenue sharing party identifier, revenue sharing conditions, and revenue sharing amount recording method from the merchant's registered agreements. Ineffective agreements, expired agreements, and agreements that do not correspond to the current payment method are eliminated, and the available agreements are bound to the current transaction. The marketing coupon redemption status information receiving and processing process reads the order identifier, user identity information, and transaction information from the payment flow, extracts the coupon identifier, redemption status, and redemption time corresponding to the current order identifier from the marketing coupon record, and registers the temporal relationship between the redemption status and the payment status; in the case of duplicate redemption records, missing redemption status, or inconsistent order identifiers corresponding to redemption, the receiving link is not interrupted, but the abnormal content is written into the receiving record and the output continues.

[0039] In a feasible engineering embodiment, a merchant completes a payment transaction in a chain store promotion scenario. The payment transaction output by S130 already carries the order identifier, merchant identifier, bill amount, and payment status. After reading the payment transaction, this step receives the marketing activity rules corresponding to the merchant's daily discount activity, the merchant revenue sharing agreement between the store and the platform, and between the store and the supplier, and the coupon redemption status information corresponding to the order. Subsequently, the activity identifier, agreement identifier, coupon identifier, and their correspondence with the order identifier are written into the same record unit, and the transaction information in the payment transaction is associated with the above three types of content. After the above processing, the output field is named rule verification data. The rule verification data is directly called as the "rule verification data" in S220. At the same time, the marketing activity rules, merchant revenue sharing agreement, and marketing coupon redemption status information continue to be processed in the revenue sharing rule matching, allocation strategy matching, and revenue sharing information generation process of S230.

[0040] S220. Based on the rule verification data, perform integrity verification, accuracy verification, data format adaptation and consistency judgment processing to generate rule matching data.

[0041] Specifically, the rule verification data comes from the output of S210 and includes at least the payment transaction field, marketing activity rule field, merchant revenue sharing agreement field, marketing coupon redemption status information field, and receiving anomaly flag. The integrity verification is a process of checking whether the current transaction possesses the minimum set of fields required for subsequent revenue sharing rule matching. This minimum set of fields includes at least order identifier, merchant identifier, bill amount, payment status, activity identifier, agreement identifier, revenue sharing party identifier, revenue sharing conditions, coupon identifier, and redemption status. The accuracy verification is a process of comparing the content correspondence between the above fields item by item. The data format adaptation is a process of organizing the marketing activity rules, merchant revenue sharing agreement, and marketing coupon redemption status information into a unified field order and a unified record format. The consistency judgment is a process of determining whether the payment transaction, marketing activity rules, merchant revenue sharing agreement, and marketing coupon redemption status information can enter the same revenue sharing processing chain.

[0042] Further, the integrity verification first extracts the order identifier, merchant identifier, bill amount, and payment status from the rule verification data, then extracts the activity identifier, agreement identifier, revenue sharing party identifier, revenue sharing conditions, coupon identifier, and redemption status, and registers any missing fields. When the missing field is a core field, the current transaction is marked as pending completion, and an entry point for subsequent manual completion is retained. When the missing field is an extended field, the field is recorded as null, and the null value is written into the rule matching data. The accuracy verification is then performed, first verifying whether the scope of applicable merchants in the marketing activity rules covers the merchant identifier, then verifying whether the scope of applicable orders in the marketing activity rules covers the order identifier, then verifying whether the agreement effective time in the merchant revenue sharing agreement covers the submission time in the payment transaction, and finally verifying whether the order identifier corresponding to the redemption in the marketing coupon redemption status information is consistent with the order identifier in the payment transaction. If, during the verification process, situations arise such as incompatibility between the bill amount and the corresponding revenue sharing rules for the activity, abnormal correspondence between the revenue sharing party identifier and the agreement identifier, or mismatch between the coupon identifier and the activity identifier, the abnormal content will be written into the verification record, while retaining the original data and abnormal markers for the current transaction to proceed to the next step.

[0043] Data format adaptation processing is performed after the above verification. Specifically, fields registered by activity dimension in the marketing activity rules are rewritten as fields arranged by order dimension; fields registered by agreement dimension in the merchant revenue sharing agreement are rewritten as fields arranged by revenue sharing party dimension; and fields registered by coupon dimension in the marketing coupon redemption status information are rewritten as fields arranged by order correspondence. These are then combined with the order identifier, merchant identifier, and payment status in the payment transaction record to form a unified record format. After the unified record format is formed, a consistency judgment is performed. The consistency judgment includes at least the consistency judgment between payment status and redemption status, the consistency judgment between the activity applicable time and the agreement effective time, the consistency judgment between the order identifier and coupon identifier correspondence, and the consistency judgment between the activity-related revenue sharing rules and the agreement revenue sharing conditions. For records that pass the consistency judgment, the system writes a matching flag; for records that fail the consistency judgment but can be suspended, the system writes a suspension flag and retains a subsequent re-examination entry; for records that fail the consistency judgment and cannot continue revenue sharing, the system writes a blocking flag. Furthermore, the rule matching data not only retains the matchable markers but also the revenue sharing basis field after splitting by revenue sharing party. In this embodiment, the revenue sharing basis field constitutes the basic content of the revenue sharing details called in S230. In the aforementioned chain store promotion scenario, the system performs integrity and accuracy verification on the activity identifier, agreement identifier, and coupon identifier corresponding to the payment transaction. Then, it converts the fields registered by activity, by agreement, and by coupon into a unified record arranged by order. Subsequently, it performs consistency judgment on the payment status, redemption status, activity applicable time, and agreement effective time. After the above processing, the output field name is rule matching data. The rule matching data is directly called as the rule matching input of S230. The revenue sharing basis field split by revenue sharing party is input as the "revenue sharing details" of S230 and continues to serve as one of the sources for payment information extraction and transaction information extraction in subsequent S300.

[0044] S230. Based on the aforementioned revenue sharing details, perform revenue sharing rule matching, allocation strategy matching, and revenue sharing information generation processing to generate revenue sharing information.

[0045] Specifically, the revenue sharing details come from the revenue sharing basis field in the rule matching data generated by S220. The revenue sharing details include at least order identifier, merchant identifier, bill amount, activity identifier, agreement identifier, revenue sharing party identifier, revenue sharing conditions, reconciliation status, and matchable flag. The revenue sharing rule matching is a process of determining the applicable revenue sharing rules for each revenue sharing detail based on the activity-corresponding revenue sharing rules registered in the marketing activity rules and the revenue sharing conditions registered in the merchant revenue sharing agreement. The allocation strategy matching is a process of matching the recording order and amount writing order of each revenue sharing party based on the activity-corresponding allocation strategy registered in the marketing activity rules and the revenue sharing amount recording method registered in the merchant revenue sharing agreement. The revenue sharing information generation process is a process of writing the revenue sharing party information, revenue sharing amount information, coupon status information, and transaction status information corresponding to the current transaction into a unified revenue sharing record after completing the revenue sharing rule matching and allocation strategy matching.

[0046] Furthermore, the revenue sharing rule matching process first reads the activity identifier and agreement identifier from the revenue sharing details, then reads the bill amount, revenue sharing party identifier, and reconciliation status. When the matchable flag is in a valid state, the corresponding revenue sharing rule for the activity is located first by the activity identifier, then the revenue sharing conditions in the merchant's revenue sharing agreement are located by the agreement identifier, and finally, the two are matched item by item within the same revenue sharing detail. If the corresponding revenue sharing rule and the revenue sharing conditions both point to the same revenue sharing party identifier, a direct matching result is written. If the corresponding revenue sharing rule and the revenue sharing conditions point to different revenue sharing party identifiers, the order is rearranged according to the revenue sharing order registered in the merchant's revenue sharing agreement, and the rearranged result is written to the revenue sharing intermediate record of the current transaction. If the reconciliation status indicates that the current transaction has not formed a valid reconciliation, a reconciliation restriction flag is written to the revenue sharing intermediate record. The allocation strategy matching is then executed. First, the allocation order for the current transaction is determined according to the allocation strategy corresponding to the activity. Then, the amount writing method is determined according to the amount recording method in the merchant's revenue sharing agreement. During the amount writing process, the amount record corresponding to the main revenue sharer is written first, followed by the amount records corresponding to the other revenue sharers. The correspondence between each revenue sharer and the order identifier, activity identifier, and coupon identifier is written simultaneously. The allocation strategy matching here does not exist independently of the revenue sharing rule matching, but is executed continuously around the same revenue sharing detail in the order of rule first and then strategy.

[0047] During the revenue sharing information generation and processing stage, the system reads the matched intermediate revenue sharing records and assembles the order identifier, merchant identifier, payment method, bill amount, activity identifier, agreement identifier, revenue sharing party identifier, revenue sharing amount record, reconciliation status, payment status, and matching flag into revenue sharing information. This revenue sharing information serves as a unified input record for subsequent risk scoring processing, and at least has entry points for payment information extraction, transaction information extraction, and multi-dimensional risk control data reception. For records with reconciliation restriction flags, suspension flags, or blocking flags, revenue sharing information is still generated, but the restriction status is retained in the corresponding fields for use by S310 and S330. In a feasible engineering embodiment, after the current transaction is completed and payment is made, the system extracts the revenue sharing details corresponding to the order from the rule matching data. First, it completes the revenue sharing rule matching according to the revenue sharing rules corresponding to the activity and the revenue sharing conditions in the merchant's revenue sharing agreement. Then, it completes the allocation strategy matching according to the allocation strategy corresponding to the activity and the revenue sharing amount record method. Finally, it forms revenue sharing information containing the corresponding relationships of each revenue sharing party identifier, revenue sharing amount record, and reconciliation status. After the above processing, the output field name is "revenue sharing information". The revenue sharing information is directly input as "revenue sharing information" in S310 and continues to run through the risk score generation in S320 and the revenue sharing status control processing in S330.

[0048] In summary, this step integrates payment records, marketing campaign rules, merchant revenue sharing agreements, and marketing coupon redemption status information into a single rule processing chain. It first generates rule verification data, then rule matching data, and finally revenue sharing information. This ensures that revenue sharing rule matching and allocation strategy matching are no longer processed separately from the current transaction. Compared to existing methods that rely solely on revenue sharing rules, this step incorporates both marketing campaign rules and marketing coupon redemption status information into the revenue sharing information generation process, directly retaining the consistency judgment results in the revenue sharing information. This allows subsequent risk scoring and revenue sharing status control to be based on a single transaction record where rule matching has been completed.

[0049] Step S300 includes at least steps S310-S330: S310. Obtain the revenue sharing information, extract payment information, extract transaction information, and receive and process multi-dimensional risk control data to obtain risk score input data.

[0050] Specifically, the revenue sharing information comes from the revenue sharing information generated by S230. This revenue sharing information includes at least an order identifier, merchant identifier, payment method, bill amount, activity identifier, agreement identifier, revenue sharing party identifier, revenue sharing amount record, reconciliation status, payment status, and matching flag. It also retains the rule reception results, rule verification results, and anomaly flags transmitted from S210 and S220. The payment information extraction extracts fields directly corresponding to the payment behavior from the revenue sharing information. This payment information includes at least a payment method, bill amount, payment status, submission time, return time, and transaction identifier. The transaction information extraction extracts fields corresponding to the current transaction context from the revenue sharing information. This transaction information includes at least an order identifier, merchant identifier, user identity information, transaction time, terminal source information, activity identifier, and reconciliation status. The multi-dimensional risk control data reception and processing receives external or internal data related to risk assessment for the current transaction. This multi-dimensional risk control data includes at least transaction frequency records, order status change records, merchant contract information reference records, payment channel availability information reference records, and anomaly flag records corresponding to the current transaction. Understandably, this step is not to further divide the revenue sharing information, but rather to extract and reorganize the payment, transaction, and risk control fields from the previous revenue sharing information into risk scoring input data, based on the minimum data set required for subsequent risk scoring.

[0051] Furthermore, payment information extraction is performed by the receiving unit in the risk scoring processing chain, after S230 outputs the revenue sharing information and before S320 performs merchant historical transaction data matching. The receiving unit first reads the payment method and bill amount from the revenue sharing information, then reads the payment status, submission time, and return time, and establishes payment field groups according to the order identifier. When there are duplicate payment status records for the same order identifier, the latest record consistent with the payment flow is retained first, and other records are written to the payment status change record. Transaction information extraction is then performed, first reading the order identifier, merchant identifier, and user identity information from the revenue sharing information, then reading the transaction time, terminal source information, activity identifier, and verification status, and forming transaction field groups according to the time sequence of the current transaction. In cases where the activity identifier is missing, the verification status is suspended, or the terminal source information is abnormal, subsequent processing is not terminated, but the abnormal content is retained in the transaction field group. Multi-dimensional risk control data reception and processing is performed after the above two extraction actions are completed. The data sources include data already registered within the current exchange's processing chain and historical registration data related to the current transaction. The reception method involves associating data according to order identifier, merchant identifier, and user identity information, and then writing it into the risk control field group of the current transaction in a unified field order. The core minimum set of fields for the multi-dimensional risk control data consists of transaction frequency records, order status change records, and anomaly marker records. These three fields support subsequent risk classification. Merchant contract information reference records and payment channel availability information reference records are preferred extended fields, participating in subsequent risk classification when merchant access scenarios are complex or payment channel switching is frequent.

[0052] In a feasible engineering embodiment, after receiving the accounting information output by S230 in a chain store promotion payment scenario, the system first extracts the payment method, bill amount, payment status, submission time, and return time of the transaction to form payment field groups; then it extracts the order identifier, merchant identifier, user identity information, transaction time, terminal source information, activity identifier, and verification status to form transaction field groups; subsequently, it receives the transaction frequency record, order status change record, and anomaly marker record corresponding to the order identifier, and synchronously receives the merchant contract information reference record when the merchant contract information is temporarily adjusted. After the above processing, the output field name is Risk Score Input Data. The Risk Score Input Data is directly called as the "Risk Score Input Data" of S320. At the same time, the payment information and transaction information therein are also referenced by the subsequent response measures trigger condition judgment and order status update of S330, thereby maintaining the continuous processing relationship of the same transaction object by S310, S320, and S330.

[0053] S320. Based on the risk score input data, perform historical transaction data matching, historical revenue data matching, and risk classification processing to generate a risk score.

[0054] Specifically, the risk scoring input data comes from the output of S310, and includes at least payment field grouping, transaction field grouping, and risk control field grouping. The merchant historical transaction data matching process involves associating the merchant identifier corresponding to the current transaction with the merchant's existing transaction records. The matching content includes at least transaction time distribution, order status distribution, payment status distribution, reconciliation status distribution, and anomaly marker distribution. The historical revenue data matching process involves associating the merchant identifier and revenue sharer identifier corresponding to the current transaction with existing revenue records. The matching content includes at least bill amount correspondence, revenue sharer record correspondence, and activity identifier correspondence. The risk classification process is based on the payment field, transaction field, multi-dimensional risk control data, and the matched historical transactions and historical revenue content of the current transaction to determine the risk category of the current transaction and generate a risk score. Here, the risk score is not an abstract label, but rather a direct input field for the current transaction in subsequent S330 processes such as triggering response conditions, order status updates, and revenue sharer status control.

[0055] Furthermore, the merchant's historical transaction data matching process first reads the merchant identifier, order identifier, and transaction time from the risk scoring input data. Then, it extracts existing transaction records adjacent to the current transaction time from the merchant's historical records and arranges them in chronological order. After arrangement, the system extracts the order status distribution, payment status distribution, reconciliation status distribution, and anomaly marker distribution from the historical records and compares them item by item with the corresponding fields of the current transaction. When the current transaction and the merchant experience repeated order status changes, repeated payment status switches, or consecutive anomaly markers within a short period, the corresponding content is registered as a high-priority matching item. When the current transaction and existing transaction records maintain stable consistency in bill amount, activity identifier, and reconciliation status, the corresponding content is registered as a regular matching item. The historical revenue data matching process then proceeds. The system reads the merchant identifier, revenue sharer identifier, bill amount, and revenue sharer record from the risk scoring input data. It then extracts the existing bill amount correspondence and revenue sharer record correspondence from the historical revenue records corresponding to that merchant and revenue sharer. If the bill amount of the current transaction deviates significantly from the existing revenue record, the revenue sharer record of the current transaction deviates significantly from the existing records under the same activity identifier, or if there is an abnormally dense number of amount records for the same revenue sharer identifier within a short period, this type of content is written into the abnormal revenue matching record. In essence, merchant historical transaction data matching addresses the relationship between the current transaction and existing transaction behaviors, while historical revenue data matching addresses the relationship between the current transaction and existing revenue distribution. Both together form the input basis for subsequent risk classification.

[0056] Risk classification is performed after the above two types of matching are completed. Specifically, the system first reads the payment status, write-off status, anomaly marker records, high-concern matching items, regular matching items, and abnormal profit matching records of the current transaction, and then classifies them according to a preset classification order; the preset classification order includes at least regular transaction category, pending verification transaction category, and high-risk transaction category. For current transactions with stable payment status, normal write-off status, few anomaly marker records, and whose historical transactions and historical profits all show regular matching items, they are written into the regular transaction category; for current transactions with short-term fluctuations in payment status, pending confirmation content in write-off status, anomaly marker records that exist but do not appear continuously, or where both regular matching items and abnormal profit matching records exist in historical transactions and historical profits, they are written into the pending verification transaction category; for current transactions with abnormal payment status, abnormal write-off status, continuous anomaly markers, and simultaneous matching of high-concern matching items and abnormal profit matching records, they are written into the high-risk transaction category. After classification, the system writes the category to which the current transaction belongs and the classification criteria into a unified risk record, and generates a risk score accordingly. The risk score includes at least a risk category field, a classification basis field, and a current transaction reference field. The risk category field is used to determine the triggering conditions for S330's response measures, the classification basis field is used for S330's order status update and revenue sharing status control processing, and the current transaction reference field is used to maintain the correspondence with the order identifier and the merchant identifier.

[0057] In the aforementioned chain store promotion payment scenario, the system matches the merchant identifier of the current transaction with the store's recent transaction records to identify whether there are repeated order status changes or consecutive occurrences of abnormal markers within a short period. It then matches the current transaction's revenue share record with the store's existing revenue records under the same activity identifier to identify any deviations. Finally, the system categorizes the transaction into a regular transaction category, a pending verification transaction category, or a high-risk transaction category, generating a corresponding risk score. After the above processing, the output field is named "Risk Score," which is directly called as the "Risk Score" in S330. Furthermore, the classification criteria field in the risk score is also used in subsequent revenue share pending settlement processing and marketing coupon redemption status association processing in S410, ensuring consistency between the risk classification result and subsequent revenue share status control for each individual transaction.

[0058] S330. Based on the risk score, determine the triggering conditions for response measures, update the order status, and control the revenue sharing status to generate the revenue sharing status control result.

[0059] Specifically, the risk score comes from the output of S320, and includes at least a risk category field, a classification basis field, and a current transaction reference field. The response trigger condition determination is a process of determining whether the current transaction enters normal processing, pending verification processing, or high-risk processing based on the risk category field and classification basis field corresponding to the risk score. The order status update is a process of rewriting the status content of the current transaction in the order chain based on the response trigger condition determination result. The revenue sharing status control processing is a process of controlling whether the revenue sharing information corresponding to the current transaction enters subsequent revenue sharing pending settlement processing based on the updated order status and risk score. The response measures here include at least allowing entry into subsequent processing, triggering identity verification, suspending some account functions, restricting transaction behavior, and suspending transactions. The order status includes at least a pending processing status, a pending verification status, and a suspended status. The revenue sharing status includes at least an allowed entry into revenue sharing pending settlement processing status, a suspended processing status, and a blocked status.

[0060] Furthermore, the determination of the triggering conditions for the response measures is executed by the decision unit in the revenue sharing status control chain. The decision unit first reads the risk category field in the risk score, and then reads the payment status anomaly content, reconciliation status anomaly content, continuous occurrence of anomaly marker content, and abnormal income matching record in the classification basis field. When the risk category field corresponds to a regular transaction category, the decision unit outputs the response measures that allow entry into subsequent processing. When the risk category field corresponds to a transaction category to be verified, the decision unit outputs the response measures that trigger identity verification or suspend some account functions. When the risk category field corresponds to a high-risk transaction category, the decision unit outputs the response measures that restrict transaction behavior and suspend the transaction. In the case of repeated entry of the same order identifier in a short period of time, the decision unit will also read the order identifier and merchant identifier in the current transaction reference field to identify whether it is a retry transaction. If it is a retry transaction and the previous transaction has entered the pending verification state, the current transaction will continue to use the pending verification processing chain and will not be directly transferred to the regular processing chain. The order status update is then executed. Based on the trigger condition determination result, the system rewrites the current transaction's order status to "Pending Processing," "Pending Verification," or "Suspended," and writes the update time, trigger source, and referenced risk category fields into the order status record. Understandably, the order status update does not replace the original order status; rather, it adds new status content to the original order status, allowing S410 to simultaneously see the previous payment status and the order status formed in this step.

[0061] Revenue sharing status control is executed after the order status is updated. Specifically, the system first reads the revenue sharing amount record, revenue sharing party identifier, and reconciliation status from the revenue sharing information, and then reads the updated order status and risk score. When the order status is pending processing and the reconciliation status does not contain any restrictions, the revenue sharing information corresponding to the transaction is written to allow entry into the revenue sharing pending settlement processing status. When the order status is pending verification, the revenue sharing information corresponding to the transaction is written to the suspended processing status, and a status flag indicating that identity verification or partial account functions have been triggered is registered. When the order status is suspended or the reconciliation status contains abnormal content, the revenue sharing information corresponding to the transaction is written to the blocked status, and a transaction behavior restriction flag is registered simultaneously. For transactions that have entered the suspended processing status, the system retains an entry point for re-invoking the identity verification result; for transactions that have entered the blocked status, the system retains an entry point for manual review and an entry point for referencing subsequent related processing records. In a feasible engineering embodiment, a promotional payment transaction from a chain store merchant is categorized as a pending verification transaction in S320. The system triggers identity verification accordingly, updates the order status to pending verification, and then writes the corresponding revenue sharing information to a suspended processing status. Another transaction is categorized as a high-risk transaction, and the system restricts and suspends the transaction, simultaneously writing the corresponding revenue sharing information to a blocked status. After the above processing, the output field is named "Revenue Sharing Status Control Result." This result is directly input as the "Revenue Sharing Status Control Result" in S410 and continues to be used in the status update result generation in S420 and the closed-loop processing record generation in S430.

[0062] In summary, the technical effects of this step are as follows: Building upon existing revenue sharing information, this step compresses payment information, transaction information, multi-dimensional risk control data, merchant historical transaction data, and historical revenue data into a single risk scoring processing chain. The risk score is then directly linked to order status updates and revenue sharing status control, ensuring that risk classification results no longer remain at an independent warning level. Compared to existing methods that only identify risks in user groups or payment behaviors, this step directly applies risk scoring to the revenue sharing status of individual transactions. This ensures that subsequent revenue sharing settlement processing, marketing coupon redemption status association processing, and notification of relevant parties are all based on the completed order status updates and revenue sharing status control results.

[0063] Step S400 includes at least steps S410-S430: S410. Obtain the revenue sharing status control result, perform revenue sharing pending settlement processing, marketing coupon redemption status association processing, and association processing record writing processing to obtain the association processing result.

[0064] Specifically, the revenue sharing status control result comes from the output of S330. This result includes at least the order identifier, merchant identifier, payment method, bill amount, revenue sharing party identifier, revenue sharing amount record, risk category field, classification basis field, order status, and revenue sharing status. The revenue sharing status indicates whether the revenue sharing information corresponding to the current transaction is in a state of being allowed to enter the revenue sharing pending settlement processing state, a state of being suspended, or a state of being blocked. The order status indicates whether the current transaction is in a state of being pending further processing, a state of being pending verification, or a state of being suspended. The revenue sharing pending settlement processing is the process of transferring the revenue sharing amount record to the pending settlement caliber for transactions whose revenue sharing status is "allowed to enter the revenue sharing pending settlement processing state." The marketing coupon redemption status association processing is the process of establishing a correspondence between the redemption status corresponding to the current transaction and the revenue sharing amount record, order identifier, and activity identifier. The association processing record writing processing is the process of registering the status changes, writing time, trigger source, and abnormal content during the above processing. Understandably, this step does not directly perform final settlement. Instead, after the split status has been controlled by S330, it establishes a pending settlement relationship and a write-off status relationship for transactions that can enter the subsequent links, and writes the relationship into a unified record.

[0065] Furthermore, the pending settlement processing is executed by the pending settlement processing unit. This unit is deployed at the connection point between the core accounting system and the pending settlement processing chain, and is activated when the pending settlement status control result is received and the current transaction's pending settlement status is allowed. The pending settlement processing unit first reads the order identifier, the party identifier, and the pending amount record from the pending settlement status control result, and then reads the order status and risk category fields. When the order status is pending processing and the risk category field does not correspond to a high-risk transaction category, the pending amount record is registered as a pending settlement amount record, and written into the pending settlement processing context one by one according to the party identifier. When the order status is pending verification, the pending amount record is not transferred to the pending settlement amount record, but is written to the pending verification hold record, and the source of the pending verification status is registered in this record. When the order status is suspended or the pending settlement status is blocked, the pending settlement amount is not written, but the current transaction is written to the suspended hold record. In the case of duplicate entries for the same order identifier, the settlement processing unit first compares the order status and accounting status in the previous write record, and only performs the write operation on the current transaction for which no pending settlement amount record has been formed; in the case of a pending settlement amount record already existing and the current transaction re-enters, the original pending settlement amount record is retained, and the current transaction is written into the duplicate entry record.

[0066] The marketing coupon redemption status association processing is executed after the pending settlement processing unit completes the current transaction status judgment. Specifically, the system reads the order identifier, activity identifier, split amount record, and split party identifier from the split status control result, and then reads the redemption status correspondence already formed in the preceding S230; if the current transaction is already in the allowed split pending settlement processing state, a one-to-one correspondence is established between the redemption status, order identifier, activity identifier, and split amount record, and this correspondence is written into the association processing context of the current transaction; if the current transaction is in the pending verification state, the original redemption status value is retained, a pending verification flag is written into the association processing context, and the reason for not transferring to the pending settlement amount record is recorded; if the current transaction is in the suspended state, a suspended flag is written into the association processing context, and the redemption status correspondence is locked and not pushed forward. The association processing here is not simply saving the coupon status, but rather putting the redemption status, order identifier, activity identifier, and split amount record into the same subsequent traceable relationship chain, so that when S420 executes the split pending settlement balance update, it calls the processing result that has already completed the registration of the corresponding relationship of the redemption status.

[0067] The associated processing record writing process is executed after the above two processes are completed. Specifically, the system writes the pending settlement processing result, the reconciliation status associated result, the current transaction entry time, the processing completion time, the trigger source, the order status, the accounting status, and any abnormal content into the associated processing record. When the current transaction has a pending verification record, a suspended record, or a duplicate entry record, the corresponding record identifier is synchronously written into the associated processing record. Understandably, the associated processing record is the core output carrier of this step; it reflects both whether the pending settlement processing has been executed and whether the marketing coupon reconciliation status has been registered accordingly. In an operational engineering embodiment, a promotional transaction of a chain store merchant is determined in S330 to be allowed to enter the pending settlement processing state. After the pending settlement processing unit reads the order identifier, accounting party identifier, and accounting amount record of the transaction, it writes the accounting amount record into the pending settlement amount record and synchronously reads the activity identifier and reconciliation status corresponding to the order, establishing a correspondence between the reconciliation status and the accounting amount record. Then, it writes the processing time, trigger source, and processing status into the associated processing record. After the above processing, the output field name is "Association Processing Result". The association processing result is directly called as the "Association Processing Result" of S420. At the same time, the order status, accounting status and reconciliation status correspondence retained therein continue to run through the generation of pending settlement notification, notification of relevant parties and merchant return processing of S430.

[0068] S420. Based on the association processing result, perform the processing of updating the balance pending settlement, writing the accounting records and payment flow, and generate the status update result.

[0069] Specifically, the association processing result comes from the output of S410, and the association processing result includes at least the order identifier, merchant identifier, revenue sharing identifier, pending settlement amount record, reconciliation status correspondence, order status, revenue sharing status, association processing time, and association processing record identifier. The pending settlement balance update is the process of writing the pending settlement amount record corresponding to the current transaction into the pending settlement balance of the revenue sharing party; the revenue sharing record writing is the process of writing the revenue sharing amount record, revenue sharing status, order status, and reconciliation status correspondence corresponding to the current transaction into the revenue sharing record; the payment transaction writing is the process of appending the status change content of the current transaction after completion in S410 into the payment transaction. Here, the pending settlement balance update is not a uniform accumulation for all transactions, but only executed on the current transaction for which a pending settlement amount record has already been formed in the association processing result and the revenue sharing status is allowed to enter the pending settlement processing state; the revenue sharing record writing and payment transaction writing are not duplicate generation of previous records, but rather status and link supplementation of existing records.

[0070] Furthermore, the update of the pending settlement balance is performed by the balance update unit. The balance update unit first reads the settlement party identifier, the pending settlement amount record, and the settlement status from the associated processing result, and then reads the correspondence between the order status and the write-off status. When the settlement status is "allowed to enter the pending settlement processing state" and the order status is "pending further processing state", the balance update unit locates the pending settlement balance record corresponding to the current settlement party based on the settlement party identifier, adds the pending settlement amount record of the current transaction to the original pending settlement balance record, and writes the balance before and after the addition to the update log. When the settlement status is "temporarily suspended processing state" or the order status is "pending verification state", the balance is not added, but a "pending verification hold" flag is written to the update log. When the settlement status is "blocked state" or the order status is "suspended state", the balance is not added, and the current transaction is written to the "blocked hold" flag. For cases where a balance has already been added to the same order ID, the balance update unit first compares the associated processing record ID. Only if the current associated processing record ID is a new record and the previous processing is marked as pending verification or blocked will the balance addition be allowed to be performed again. In this way, when the current transaction is manually approved and re-enters the subsequent chain, the balance update logic can still continue to run according to the same order ID.

[0071] The split record writing process is executed after the balance update unit completes the current transaction balance status determination. Specifically, the system reads the order identifier, merchant identifier, split party identifier, pending settlement amount record, reconciliation status correspondence, order status, and split status from the associated processing results, and writes them into the split records according to the order dimension and the split party dimension respectively. When writing by order dimension, at least the order identifier, merchant identifier, split status, and order status are written; when writing by split party dimension, at least the split party identifier, pending settlement amount record, and reconciliation status correspondence are written. The payment transaction record writing process is then executed. The system reads the payment transaction record identifier formed in S130 for the current transaction, and appends the newly added order status, split status, associated processing record identifier, and pending settlement balance update result to the payment transaction record, so that the payment transaction record fully reflects the status changes of the payment chain, rule chain, risk control chain, and pending settlement chain. Understandably, the payment transaction record writing here plays a status tracing role, connecting the previous payment transaction record with the current associated processing result and balance update result into the same queryable link.

[0072] In a feasible engineering embodiment, for a promotional transaction of a chain store merchant, the system first determines, based on the association processing result, that the transaction has formed a pending settlement amount record and the order status is pending further processing. Then, the pending settlement amount record is appended to the pending settlement balance records of both the platform and the supplier. Subsequently, the correspondence between the order identifier, merchant identifier, revenue sharing identifier, pending settlement amount record, and verification status is written into the revenue sharing record, and the current revenue sharing status and order status are written into the transaction record corresponding to the original payment transaction. After the above processing, the output field is named "Status Update Result," which is directly called as the "Status Update Result" in S430. Simultaneously, the pending settlement balance update result, revenue sharing record identifier, and payment transaction record supplementation result together constitute the pre-input content of the closed-loop processing record.

[0073] S430. Based on the status update result, generate a pending settlement notification, notify relevant parties and merchants to return the processing, and generate a closed-loop processing record.

[0074] Specifically, the status update result comes from the output of S420, and includes at least the order identifier, merchant identifier, revenue sharing party identifier, pending settlement balance update result, revenue sharing record identifier, payment transaction record completion result, order status, revenue sharing status, and associated processing record identifier. The pending settlement notification generation is a process of organizing the pending settlement amount record, revenue sharing party identifier, order status, and revenue sharing status corresponding to the current transaction into pending settlement notification content. The notification to relevant parties is a process of sending the pending settlement notification content to the corresponding receiving end of the revenue sharing party. The merchant-side return processing is a process of organizing the correspondence between the payment status, revenue sharing status, order status, and verification status corresponding to the current transaction into merchant-side return content and sending it back to the merchant. The pending settlement notification is not generated immediately after payment is completed, but after S420 has completed the pending settlement balance update, revenue sharing record writing, and payment transaction record writing. The merchant-side return processing also does not only return the payment result, but returns the current transaction processing result including the revenue sharing status and order status.

[0075] Furthermore, the generation of the pending settlement notification is executed by the notification generation unit. The notification generation unit first reads the order identifier, revenue sharer identifier, pending settlement balance update result, order status, and revenue share status from the status update result. Then, it reads the revenue share record identifier and associated processing record identifier, assembling them into the pending settlement notification content. The minimum set of fields for the pending settlement notification content includes the order identifier, revenue sharer identifier, pending settlement amount record, revenue share status, and notification generation time. The revenue share record identifier and associated processing record identifier are preferred extended fields, written together when the revenue sharer needs to perform subsequent verification or audit tracing. If the status update result indicates that the current transaction is in a pending verification state or a suspended state, the notification generation unit still generates the pending settlement notification content, but writes a delayed processing flag or a blocked processing flag into the notification content, without writing a pending settlement amount addition completion flag. The notification process for relevant parties is executed after the notification content is assembled. The system locates the corresponding receiving end based on the revenue sharing party's identifier and sends the notification content to be settled to the corresponding receiving link. If the corresponding receiving end does not respond immediately, an unconfirmed mark is written to the notification record of the current transaction, and an entry point for resending is reserved. If the corresponding receiving end has responded, the receiving confirmation time is written to the notification record. The relevant parties here include at least the platform, the supplier, and the merchant-side revenue sharing receiving end. The platform and the supplier receive the notification content to be settled, while the merchant-side revenue sharing receiving end receives the result content related to the revenue sharing status.

[0076] Merchant-side response processing and notification of relevant parties are executed in parallel. Specifically, the system reads the order identifier, payment transaction record update result, order status, revenue sharing status, and pending settlement balance update result from the status update result, and then combines this with the corresponding verification status relationship retained in the previous processing chain to assemble the merchant-side response content. The merchant-side response content includes at least the correspondence between payment status, order status, revenue sharing status, pending settlement status, and verification status. For transactions in the pending verification or suspended status, a pending verification mark or suspended mark is synchronously written into the merchant-side response content, enabling the merchant to initiate supplementary verification, manual review query, or transaction status display accordingly. After the pending settlement notification is generated, relevant parties are notified, and the merchant-side response processing is completed, the system uniformly writes the notification generation time, notification sending result, receipt confirmation time, merchant-side response time, order status, revenue sharing status, payment transaction record update result, revenue sharing record identifier, and associated processing record identifier into the closed-loop processing record. Understandably, the closed-loop processing record is not an isolated new record, but a collection of the results of the entire chain of processing from S110 to S430. It references both the preceding payment transaction history and the associated processing records and status update results, so that the entire process of a single transaction from the payment request to the issuance of the settlement notification can be queried under the same order identifier.

[0077] In a feasible engineering embodiment, for a promotional transaction whose pending settlement balance update has been completed, the system first generates a pending settlement notification containing an order identifier, a revenue share identifier, a pending settlement amount record, and a revenue share status, and sends it to the corresponding receiving terminals of the platform and the supplier. Subsequently, the system returns the correspondence between the payment status, order status, revenue share status, pending settlement processing status, and verification status to the merchant's POS interface, enabling the merchant to display that the transaction has entered the pending settlement processing state. After the above processing, the output field is named "Closed-Loop Processing Record." The closed-loop processing record completes the convergence of the association processing result of S410 and the status update result of S420. At the same time, the closed-loop processing record and the payment request record in the preceding S110 form a traceable connection through the order identifier. When the same order identifier is retried, awaiting verification review, or re-entered through manual review, it can still serve as a subsequent reading entry point.

[0078] In summary, this step integrates the processing of pending settlement, the association of marketing coupon redemption status, the updating of pending settlement balances, the writing of settlement records, the writing of payment transaction records, the generation of pending settlement notifications, and the processing of merchant responses into a single closed-loop chain. This ensures that the status changes of a single transaction after risk control are no longer scattered across different records. Compared to the existing method where payment, settlement, and notification are executed independently, this step unifies the redemption status correspondence, the pending settlement balance update result, and the notification sending result into the closed-loop processing record. This creates a continuous record from the settlement status control result to the relevant party's receipt of the result, and allows subsequent retry transactions, pending verification transactions, and suspended transactions to continue processing within the same chain.

Claims

1. A method for real-time revenue sharing and risk monitoring based on multi-dimensional aggregated payment, characterized in that, include: S100: Obtain payment request and verification information, perform order data assembly and payment request submission processing, and execute payment transaction record generation and field mapping processing to obtain payment transaction record; S200. Based on the payment transaction, perform marketing activity rule reception and merchant revenue sharing agreement reception processing, and execute marketing coupon redemption status information reception, data format adaptation, consistency judgment processing, and generate revenue sharing information. S300. Based on the revenue sharing information, perform merchant historical transaction data matching processing, and execute response trigger condition determination, order status update and revenue sharing status control processing to generate revenue sharing status control results. S400. Based on the revenue sharing status control result, perform revenue sharing pending settlement processing and marketing coupon redemption status association processing, and execute pending settlement notification generation and notification return processing to relevant parties and merchants to generate closed-loop processing records.

2. The method according to claim 1, characterized in that, The process of assembling order data and submitting payment requests includes: The order data assembly process includes assembling user identity information, bill amount and transaction information as basic fields, order identifier, merchant identifier and payment method as control fields, and verification status, matching status and the exception flag as status fields, into unified order data in a preset order. The payment request submission process includes reading the payment method, bill amount, merchant identifier, and order identifier from the order data to organize them into submission content that the payment channel can accept, and reading the verification status and matching status from the order data again before submission. When both are valid, the submission is executed.

3. The method according to claim 1, characterized in that, The field mapping process includes: The field mapping process includes extracting user identity information, bill amount, transaction information, payment method, verification status, matching status, and anomaly marker from the order data, mapping them to the corresponding user identity field, amount field, transaction field, payment field, and status field in the payment transaction record, and generating a payment transaction record containing the user identity information, the verification status, the matching status, and the anomaly marker.

4. The method according to claim 1, characterized in that, The process of receiving and processing marketing campaign rules and merchant revenue sharing agreements includes: The marketing activity rule receiving and processing includes reading the merchant identifier, transaction information and bill amount from the payment transaction record, locating the applicable marketing activity rules according to the merchant identifier and transaction time, and filtering out invalid and mismatched rules according to the applicable time of the activity and the scope of applicable merchants. The merchant revenue sharing agreement receiving and processing includes reading the merchant identifier, order identifier, and payment method from the payment transaction data, extracting the agreement effective time, revenue sharing party identifier, revenue sharing conditions, and revenue sharing amount recording method from the merchant's registered agreements, and removing agreements that are ineffective, expired, or do not correspond to the current payment method.

5. The method according to claim 1, characterized in that, The process of receiving marketing coupon redemption status information, adapting data formats, and performing consistency checks includes: The marketing coupon redemption status information receiving and processing includes reading the order identifier, user identity information and transaction information from the payment flow, extracting the coupon identifier, redemption status and redemption time corresponding to the current order identifier, and registering the temporal relationship between the redemption status and the payment status; The data format adaptation process includes transcribing the fields registered by activity dimension in the marketing activity rules into fields arranged by order dimension, transcribing the fields registered by agreement dimension in the merchant revenue sharing agreement into fields arranged by revenue sharing party dimension, transcribing the fields registered by coupon dimension in the marketing coupon redemption status information into fields arranged by order correspondence, and combining them with payment transaction records into a unified record format. The consistency judgment process includes determining the consistency between payment status and redemption status, the consistency between the activity's applicable time and the agreement's effective time, the consistency between the order identifier and the coupon identifier, and the consistency between the activity's corresponding revenue sharing rules and the agreement's revenue sharing conditions, and writing a matching flag, a suspended flag, or a blocking flag.

6. The method according to claim 1, characterized in that, The process of matching merchants' historical transaction data includes: The merchant historical transaction data matching includes associating and matching the merchant identifier corresponding to the current transaction with the merchant's existing transaction records, extracting the transaction time distribution, order status distribution, payment status distribution, reconciliation status distribution and anomaly marker distribution, and comparing them item by item with the fields corresponding to the current transaction, and registering high-attention matching items or regular matching items.

7. The method according to claim 1, characterized in that, The process of determining the trigger conditions for implementing response measures, updating order status, and controlling the revenue sharing status includes: The trigger condition determination of the response measures includes determining whether the current transaction enters the normal processing, pending verification processing or high-risk processing based on the risk category field and classification basis field in the risk score, and outputting response measures such as allowing entry into subsequent processing, triggering identity verification, suspending some account functions, restricting transaction behavior or suspending the transaction. The order status update includes rewriting the current transaction's order status to a pending processing status, a pending verification status, or a suspended status based on the judgment result of the response trigger condition. The revenue sharing status control process includes, based on the updated order status and risk score, combined with the revenue sharing amount record, revenue sharing party identifier and write-off status in the revenue sharing information, writing the revenue sharing information corresponding to the current transaction into a state that allows entry into the revenue sharing pending settlement processing state, a state that suspends processing, or a state that blocks processing.

8. The method according to claim 1, characterized in that, The process of processing pending settlement of accounts includes: The pre-settlement processing includes being initiated by the pre-settlement processing unit when it receives the pre-settlement status control result and the current transaction's pre-settlement status is allowed to enter the pre-settlement processing status. It reads the order identifier, pre-settlement party identifier, and pre-settlement amount record, and, in conjunction with the order status and risk category fields, registers the pre-settlement amount record as a pre-settlement amount record and writes it into the pre-settlement processing context, or writes the transaction into the pending verification hold record or the suspended hold record.

9. The method according to claim 1, characterized in that, The process of associating the marketing coupon redemption status includes: The marketing coupon redemption status association processing includes reading the order identifier, activity identifier, revenue amount record, and revenue party identifier from the revenue sharing status control result, and combining them with the previously established redemption status correspondence. When the current transaction is in the allowed revenue sharing pending settlement processing state, a one-to-one correspondence is established between the redemption status, order identifier, activity identifier, and revenue sharing amount record and written into the association processing context. When the current transaction is in the pending verification state or suspended state, a pending verification flag or a suspended flag is written accordingly and the redemption status correspondence is locked.

10. The method according to claim 1, characterized in that, The process of generating a pending settlement notification and processing the return to relevant parties and merchants includes: The pending settlement notification generates an order identifier, a revenue sharing party identifier, a pending settlement balance update result, an order status, and a revenue sharing status from the read status update result. It also assembles a revenue sharing record identifier and an associated processing record identifier to generate a pending settlement notification content that includes an order identifier, a revenue sharing party identifier, a pending settlement amount record, a revenue sharing status, and a notification generation time. The notification process for relevant parties includes locating the corresponding receiving end according to the revenue sharing party identifier and sending the settlement notification content to the corresponding receiving link. If the receiving end does not respond immediately, an unconfirmed flag is written and an entry point for resending is reserved. The merchant-side return processing includes reading the order identifier, payment transaction record update result, order status, accounting status, and pending settlement balance update result. Combined with the corresponding relationship of the verification status, the merchant-side return content containing the corresponding relationship of payment status, order status, accounting status, pending settlement processing status, and verification status is assembled and sent back to the merchant-side.

Images