A unified state mapping and whole-process tracking method and system for enterprise multi-payment modes

Abstract

This invention relates to the field of data processing systems and methods specifically applicable to management, and provides a unified state mapping and full-process tracking method for multiple payment methods in enterprises. The method includes: acquiring enterprise payment tasks and dividing them into payment execution units based on user-confirmed payment schemes; establishing the association between each execution unit and the payment invocation process and external business status; constructing payment execution evidence relationships, determining whether each execution unit has entered the execution stage that influences external payments, and generating a unified payment status by combining the current valid payment scheme and historical valid payment status; when user-confirmed content or payment path changes, retaining the payment share that has formed a valid payment result or entered the external execution stage, and reconstructing the payment scheme only for the remaining payment share; and associating and recording the payment execution status, unified payment status, and path change process to generate a full-process tracking result.

Description

Technical Field

[0001] This invention relates to the field of data processing systems and methods specifically applicable to management, and in particular to a unified status mapping and end-to-end tracking method and system for multiple payment methods in an enterprise. Background Technology

[0002] In enterprise payment processes, various payment methods coexist, including digital bills, blockchain vouchers, digital RMB, foreign exchange, domestic letters of credit, and electronic guarantees. These different payment methods are typically handled by different business systems, with varying interface specifications, business processes, status names, and result feedback mechanisms. As AI payment agents invoke multiple payment capabilities through a unified entry point, a single enterprise payment task may be broken down into multiple payment execution branches, processed in parallel or sequentially by different payment systems. Because the original status returned by each payment system is inconsistent, and there may be asynchronous receipts, duplicate receipts, partial execution success, and payment path switching, updating the unified payment status solely based on a preset status code mapping table can easily lead to problems such as old statuses overwriting current statuses, missing partial payment results, and duplicate execution of remaining payment amounts. Existing customer business data also indicates that differences in the interfaces and status flows of different payment systems make unified status tracking difficult for multiple payment methods, necessitating a complete traceability system covering AI recognition, user confirmation, tool invocation, payment execution, and final results.

[0003] For example, international patent application WO2021063015A1, "Risk Control Method, System, Device, and Equipment," discloses a risk identification scheme across payment subsystems. This scheme addresses scenarios where a single user can log into multiple payment subsystems. It generates shared risk features based on business data from one of the payment subsystems, enabling other payment subsystems to use these shared risk features for risk identification. While this scheme improves the ability to share risk information among multiple payment subsystems, its processing primarily focuses on risk identification results and shared risk features. It does not address the unified generation of the original business states for different payment methods, nor does it solve the problems of state aggregation when multiple payment execution branches are processed in parallel, effective state identification after payment path changes, and control of remaining payment shares. Similarly, US patent US11216805B2, "COIN operated digital payment hub," discloses a digital payment center capable of receiving payment status updates from multiple external financial systems, maintaining transaction ledger status, and updating the transaction ledger based on payment events. This solution can centrally record payment events generated by different financial systems, but it mainly aims to update the status of the transaction ledger and balance accounting. It does not establish a corresponding relationship between user confirmation version, payment scheme version, payment execution share, tool call record and external business receipt. When the payment path is replaced and the original payment path has partially entered the external processing stage, it also does not provide a processing mechanism to distinguish between the still valid historical execution results and the payment share that can be reallocated.

[0004] In addition, the existing technology still has the following defects: 1. Most multi-payment systems only convert the original state into a standard state through a fixed state code table, which is difficult to reflect the actual completion status of multiple payment execution branches in a payment task; the status returned asynchronously by the external payment system is usually updated according to the receiving time, lacking correlation verification of the confirmation version, payment scheme and tool call process of the original state, which is prone to delayed state overwriting, duplicate state updates or old payment path state pollution; 2. When a payment task uses multiple payment methods and there are partial successes, partial failures or partial processing, the existing technology is difficult to accurately generate a unified payment status for the whole task based on the actual payment share of each payment execution branch; 3. When the user changes the payment method or the system regenerates the payment path, the existing technology usually directly abolishes the original payment scheme or recreates the complete payment task, which is difficult to retain the execution results that have formed external payment effect, and cannot generate a new payment path only for the remaining executable payment share; 4. AI recognition results, user confirmation records, payment tool call records, external business receipts and final processing results are usually stored in a scattered manner, without forming a correlation tracking structure that can reversely explain the basis for the generation of the unified payment status.

[0005] This invention addresses the common problems in the field, such as inconsistent definitions of heterogeneous payment status, difficulty in aggregating the status of multiple payment branches, status distortion caused by asynchronous receipts, pollution of historical payment path status, difficulty in accurately reconstructing the remaining amount after partial payment, and lack of complete generation basis for unified payment status. Summary of the Invention

[0006] The purpose of this invention is to address the shortcomings of existing technologies by proposing a unified state mapping and full-process tracking method and system for multiple payment methods in enterprises. To overcome the deficiencies of the prior art, this invention adopts the following technical solution: a unified state mapping and full-process tracking method for multiple payment methods in enterprises, comprising the following steps: S1, obtaining enterprise payment tasks, and dividing the enterprise payment tasks into one or more payment execution units according to the payment scheme confirmed by the user, each payment execution unit corresponding to a payment method and a corresponding payment execution share; S2, calling the payment processing system corresponding to each payment execution unit, and establishing an execution association relationship between each payment execution unit and the corresponding payment invocation process and external business status; S3, constructing the payment execution evidence relationship of the enterprise payment task based on user confirmation information, payment scheme, payment invocation process, and the external business status, and determining whether each payment execution unit has entered the execution stage that forms external payment influence based on the payment execution evidence relationship; S4, based on the current effective... S5. Determine the effective payment status for the current unified payment status by considering the payment execution status corresponding to the payment scheme and the payment execution status of historical payment schemes that have entered the execution stage but have not yet been withdrawn or compensated; S6. Generate the unified payment status of the enterprise payment task based on the payment execution share corresponding to each effective payment status; S7. When the user confirmation content changes or the payment path is adjusted, retain the payment execution shares that have formed effective payment results and the payment execution shares that have entered the execution stage, and determine the remaining payment execution share based on the difference between the current total payment share and the retained payment execution share, and generate an adjusted payment scheme for the remaining payment execution share; S8. Link and record the payment execution evidence relationship, the payment execution status of each payment execution unit, the unified payment status, and the payment path change process to generate the full-process tracking result of the enterprise payment task.

[0007] The beneficial effects achieved by this invention are as follows: 1. By using the payment invocation acceptance result, external business identifier, and the actual accepted payment execution share, it is determined whether the payment execution unit has entered the execution stage that forms external payment impact. For payment execution states in historical payment schemes that have entered the execution stage and whose corresponding external payment impact has not been withdrawn, reversed, or eliminated through compensation processing, they are retained as historical valid payment states, thereby avoiding the omission of payment execution shares that have entered the external payment processing process due to the replacement of internal payment schemes; 2. This invention associates and records user confirmation information, payment scheme, payment execution unit, payment invocation process, external business status, valid payment status, unified payment status, payment path change process, and final processing result, and generates the status formation basis corresponding to the unified payment status based on the payment execution evidence relationship, enabling the current unified payment status to be traced back to the corresponding user confirmation version, payment scheme version, payment execution unit, payment invocation process, and external business receipt, improving the traceability and verifiability of the unified payment status generation process; 3. By constructing a payment execution evidence relationship that includes user confirmation nodes, payment scheme nodes, payment execution unit nodes, payment invocation nodes, external business acceptance nodes, and payment result nodes, and by distinguishing different payment paths through user confirmation versions and payment scheme versions, when a payment scheme is adjusted, the state evidence of the payment path before the adjustment is retained. At the same time, payment execution states that have not yet entered the execution stage that has formed external payment impact and have been replaced are excluded from the current unified payment state generation process, which can prevent the state of invalid payment paths from continuing to interfere with the current payment task. Attached Figure Description

[0008] The invention will be further understood from the following description taken in conjunction with the accompanying drawings. The components in the drawings are not necessarily drawn to scale, but rather the emphasis is on illustrating the principles of the embodiments. In different views, the same reference numerals designate the same parts.

[0009] Figure 1 This is a schematic diagram of the hardware deployment structure of the unified state mapping and full-process tracking system of the present invention.

[0010] Figure 2 This is the overall framework diagram of the unified status mapping and full-process tracking system for multiple payment methods of enterprises according to the present invention.

[0011] Figure 3 This is a flowchart of the unified status mapping and full-process tracking method for multiple payment methods of an enterprise according to the present invention.

[0012] Figure 4 This is a schematic diagram illustrating the construction of payment execution evidence relationships and payment path substitution in this invention.

[0013] Figure 5This is a schematic diagram of the hardware structure of the business interaction terminal and enterprise payment intelligent agent processing device of the present invention.

[0014] Explanation of reference numerals in the attached drawings: 1. Display device; 2. Enterprise payment intelligent agent processing device; 3. Operation input device. Detailed Implementation

[0015] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can understand the advantages and effects of the present invention from the content disclosed in this specification. The present invention can be implemented or applied through other different specific embodiments, and various details in this specification can also be modified and changed based on different viewpoints and applications without departing from the spirit of the present invention. Furthermore, the accompanying drawings of the present invention are for simple illustrative purposes only and are not depictions of actual dimensions; this is stated beforehand. The following embodiments will further describe the relevant technical content of the present invention in detail, but the disclosed content is not intended to limit the scope of protection of the present invention.

[0016] according to Figure 1 , Figure 2 , Figure 3 , Figure 4 , Figure 5As shown, this embodiment provides a unified state mapping and full-process tracking method for multiple payment methods in an enterprise. The unified state mapping and full-process tracking method includes the following steps: S1, obtaining the enterprise payment task, and dividing the enterprise payment task into one or more payment execution units according to the payment plan confirmed by the user. Each payment execution unit corresponds to a payment method and a corresponding payment execution share. The enterprise payment task serves as the unified tracking object for this payment process, and each payment execution unit carries the payment execution process under its corresponding payment method, and together they correspond to the enterprise payment task; S2, calling the payment processing system corresponding to each payment execution unit. And establish execution association relationships between each payment execution unit and the corresponding payment invocation process and external business status; during the payment invocation and external business status return process, maintain the correspondence between the execution association relationships and the corresponding payment execution units, so that the subsequently obtained external business status can be attributed to the corresponding payment execution process; S3, based on user confirmation information, payment scheme, payment invocation process and the external business status, construct the payment execution evidence relationship of the enterprise payment task, and determine whether each payment execution unit has entered the execution stage that forms external payment impact based on the payment execution evidence relationship; the payment execution evidence relationship is used to characterize user confirmation information, payment scheme, The execution association and state formation relationship between the payment invocation process and the external business status are updated as the payment invocation process and the external business status change, serving as the basis for determining the effective payment status and generating the unified payment status; S4. Based on the payment execution status corresponding to the current effective payment scheme, and the payment execution status of historical payment schemes that have entered the execution stage but have not yet been withdrawn or compensated, the effective payment status participating in the generation of the current unified payment status is determined; wherein, the current effective payment scheme is the payment scheme currently used to continue executing the enterprise payment task, and the historical payment scheme is the payment scheme that has been replaced due to changes in user confirmation content or adjustments to the payment path. Payment scheme; For payment execution statuses in historical payment schemes that have already formed external payment impacts but have not yet been withdrawn or compensated, their impact on the current enterprise payment task status is retained to avoid omission of external execution processes that have already occurred due to changes in payment schemes; S5, Generate a unified payment status for the enterprise payment task based on the payment execution share corresponding to each valid payment status; The unified payment status is used to represent the current processing status of the enterprise payment task as a whole, and is different from the local payment execution status of any individual payment execution unit; When any valid payment status changes, the unified payment status of the enterprise payment task is regenerated based on the changed valid payment status;S6. When the user confirms a change in content or an adjustment to the payment path, retain the payment execution shares that have already formed a valid payment result and the payment execution shares that have entered the execution stage. Determine the remaining payment execution share based on the difference between the current total payment share and the retained payment execution share. Generate an adjusted payment plan for the remaining payment execution share. Determine the adjusted payment plan as the new currently valid payment plan, and continue executing steps S2 to S5 for the payment execution unit corresponding to the adjusted payment plan. For the already retained payment execution shares, do not generate the corresponding payment execution unit again. S7. Link and record the payment execution evidence relationship, the payment execution status of each payment execution unit, the unified payment status, and the payment path change process to generate the full-process tracking result of the enterprise payment task. The full-process tracking result retains the correlation between each payment execution status, the unified payment status, and the payment path change, and updates it accordingly when the payment execution status, the unified payment status, or the payment path changes, so that the unified payment status can be traced back to the corresponding payment execution process and the basis for the status formation. Steps S1 to S5 constitute the payment execution and unified payment status generation process under the current effective payment scheme; step S6 is triggered when the user's confirmed content changes or the payment path is adjusted; otherwise, the corresponding payment execution unit continues to be executed according to the current effective payment scheme; step S7 runs through the entire process of handling the enterprise payment task.

[0017] Optionally, in step S1, the enterprise payment task includes at least the business type, payer, payee, total payment share, and payment direction; the enterprise payment task is generated by the business interaction terminal receiving the user's input payment request or transaction materials and sending it to the enterprise payment intelligent agent processing device through the communication network; the processor in the enterprise payment intelligent agent processing device calls the task processing program in the memory to perform structured processing on the payment request or transaction materials; the business interaction terminal includes at least one of a mobile terminal, a computer terminal, or an enterprise payment business terminal; the payment scheme includes at least one payment method, the payment execution share corresponding to each payment method, and the payment execution order. The payment execution conditions and corresponding payment processing system are specified. The payment scheme is generated by the enterprise payment intelligent agent processing device and output through the business interaction terminal. After the user performs a confirmation operation on the business interaction terminal, it is written into the memory. The payment processing system is an external business system that can communicate with the enterprise payment intelligent agent processing device through an interface control gateway and receive corresponding payment call requests. The payment method includes at least one of digital bills, blockchain vouchers, digital RMB, foreign exchange, letters of credit, and electronic guarantees. Different payment methods correspond to pre-configured payment processing systems, communication interfaces, and payment execution conditions. The processor, based on the payment method determined in the payment scheme, processes the payment from the pre-configured payment processing system. The memory reads the corresponding interface configuration information and execution conditions to establish a call relationship between the payment execution unit and the corresponding payment processing system. When the payment scheme includes two or more payment methods, payment execution units are generated according to the payment execution share corresponding to each payment method. Each payment execution unit executes in parallel or sequentially according to the payment scheme. When there is no dependency on the execution results between payment execution units, the corresponding payment execution units are configured to execute in parallel. When a subsequent payment execution unit requires the execution result of the previous payment execution unit, the remaining payment share, or the external business status as an execution condition, the corresponding payment execution unit is configured to execute sequentially. The share is the proportion of the payment amount undertaken by the corresponding payment execution unit or the payment amount to the total payment share. When the payment execution share is expressed as a proportion, the processor determines the actual payment amount undertaken by each payment execution unit based on the total payment share and the corresponding proportion. The payment execution shares corresponding to each payment execution unit are distinguished from each other, and the sum of the payment execution shares corresponding to each payment execution unit corresponds to the total payment share. After each payment execution unit is generated, the processor writes the enterprise payment task, payment plan, payment method, payment execution share, execution order, execution conditions, and the relationship between the corresponding payment processing system into the memory for subsequent payment calls and payment status association.

[0018] In this embodiment, the payment execution unit is specifically a payment execution task instance created in the memory by the processor in the enterprise payment intelligent agent processing device according to the payment scheme confirmed by the user. The payment execution task instance is stored in a task queue or task database in the form of a task data structure and is loaded and scheduled by the processor. Each payment execution task instance corresponds to a payment item to be executed in the enterprise payment task and is bound to the corresponding payment method, payment execution share, payment processing program, and payment processing system.

[0019] The payment execution unit includes at least the following fields: payment execution unit identifier, enterprise payment task identifier, corresponding payment scheme version, payment method identifier, payment execution share, payer information, payee information, payment execution parameters, payment processing program identifier, payment interface identifier, execution order information, execution condition information, current payment execution status, and external business status association fields. Specifically, the payment processing program identifier points to the payment processing program in memory corresponding to the corresponding payment method; the payment interface identifier determines the interface used to send the payment call request to the corresponding payment processing system; the payment execution parameters carry the payer, payee, payment amount, and payment method-related parameters required for this payment call; and the current payment execution status records the corresponding payment execution task instance's status as pending execution, executing, successful execution, failed execution, canceled, or rejected. When executing the payment execution unit, the processor reads the corresponding payment execution task instance from the task queue or task database, calls the corresponding payment processing program according to the payment processing program identifier, and sends a payment call request to the corresponding payment processing system through the interface control gateway according to the payment interface identifier. The interface control gateway receives the external business identifier and external business status returned by the payment processing system, and writes the external business identifier and external business status into the corresponding payment execution task instance to update the payment execution status of the payment execution unit. For example, if a company needs to pay 1 million yuan, and the user confirms payment of 600,000 yuan using digital invoices, 200,000 yuan using digital RMB, and 200,000 yuan using foreign exchange, the processor in the enterprise payment intelligent agent processing device creates three payment execution task records in the task database: 1) First payment execution unit: Payment execution unit identifier: U001; Payment method: digital invoice; Payment execution share: 600,000 yuan; Payment processing program: digital invoice payment processing program; Payment interface: digital invoice processing system interface; Current status: pending execution. 2) Second Payment Execution Unit: Payment Execution Unit Identifier: U002; Payment Method: Digital RMB; Payment Execution Amount: 200,000 RMB; Payment Processing Program: Digital RMB Payment Processing Program; Payment Interface: Digital RMB Payment Processing System Interface; Current Status: Pending Execution. 3) Third Payment Execution Unit: Payment Execution Unit Identifier: U003; Payment Method: Foreign Exchange; Payment Execution Amount: 200,000 RMB; Payment Processing Program: Foreign Exchange Payment Processing Program; Payment Interface: Foreign Exchange Payment Processing System Interface; Current Status: Pending Execution. The processor schedules U001, U002, and U003 respectively and calls the corresponding payment processing programs. Each payment processing program sends a payment call request to different payment processing systems via the interface control gateway, and then writes the returned business transaction details and status back to U001, U002, and U003 respectively.

[0020] By establishing distinct payment execution task instances based on different payment methods and corresponding payment execution shares, the original business status returned by different payment processing systems can be attributed to the corresponding payment execution units, forming a unified payment execution status at the payment execution unit level. This provides a unified data foundation for subsequently aggregating payment execution results corresponding to different payment methods.

[0021] Optionally, in step S2, establishing the execution association includes: the processor in the enterprise payment intelligent agent processing device generating a unified payment task identifier for each enterprise payment task, generating a user confirmation version and a payment scheme version for each user-confirmed payment scheme, and generating a payment execution unit identifier for each payment execution unit; wherein, the unified payment task identifier is used to associate the user confirmation information, payment scheme, payment execution unit, and payment processing result corresponding to the same enterprise payment task; the user confirmation version is used to distinguish different user confirmation results; the payment scheme version is used to distinguish payment schemes generated based on different user confirmation results or payment path adjustment results; and the payment execution unit identifier is used to distinguish different payment execution task instances. The processor writes the association between the above identifiers into an execution association table in memory.

[0022] When invoking the payment processing system corresponding to a payment execution unit, the processor generates a payment call identifier for each actual payment call and generates a payment execution association identifier based on the unified payment task identifier, user confirmation version, payment scheme version, payment execution unit identifier, and payment call identifier. When the same payment execution unit re-initiates a payment call due to interface timeout, communication interruption, or call failure, a new payment call identifier and corresponding payment execution association identifier are generated to distinguish different payment call processes. The processor generates a payment call request based on the payment processing program corresponding to the payment execution unit and sends it to the corresponding payment processing system through the communication interface and interface control gateway; the payment execution association identifier is written into the request field, extended field, or call context of the payment call request. The interface control gateway records the sending time of the payment call request, the payment execution association identifier, and the call result. When the payment processing system supports returning the payment execution association identifier, a corresponding relationship is established based on the returned payment execution association identifier; when the payment processing system does not support receiving or returning the payment execution association identifier, the returned external business identifier and the payment execution association identifier corresponding to this payment call are written into the execution association table to establish a correspondence between the external payment processing process and the payment execution unit. The external business identifier includes at least one of the following: business serial number, transaction serial number, application number, bill business number, voucher transfer number, or payment acceptance number. Upon receiving an external business status actively pushed by the payment processing system or obtained through querying, the processor queries the execution association table based on the payment execution association identifier or the external business identifier to determine the enterprise payment task, user confirmation version, payment scheme version, payment invocation process, and payment execution unit corresponding to the external business status. The processor then writes the external business status into the status association field of the corresponding payment execution task instance for subsequent construction of payment execution evidence relationships. When an external business status cannot be temporarily associated with the corresponding payment execution unit, it is designated as a pending association status and stored in the pending association status area along with the external business identifier, status source, status generation time, and status content. After obtaining the corresponding association information, the execution association table is queried again. After completing the attribution verification of the enterprise payment task, payment scheme version, and payment execution unit, the pending association status is transferred to the corresponding payment execution unit. Before completing the attribution verification, the pending association status does not change the payment execution status of the payment execution unit, nor does it participate in the unified payment status generation. In this embodiment, the execution association process includes, in sequence: generating an internal task and version identifier, creating a payment execution task instance, generating a payment call identifier and a payment execution association identifier, sending a payment call request, receiving and associating an external business identifier and an external business status, and assigning the external business status to the corresponding payment execution unit.

[0023] By generating a unified payment status for the enterprise's payment tasks through the payment execution share corresponding to each valid payment status, the unified payment status not only reflects the status type of each payment execution branch, but also reflects the actual payment amount or payment ratio undertaken by each payment execution branch. When multiple payment execution branches are in the status of successful execution, in execution, failed execution, or pending execution, the processing status of the entire enterprise payment task can be determined based on the payment execution share corresponding to each status, thereby improving the accuracy of multi-payment branch status aggregation.

[0024] Optionally, in step S3, the payment execution evidence relationship is represented by a payment execution evidence graph. The payment execution evidence graph is a directed relational data structure constructed by the processor in the enterprise payment intelligent agent processing device based on user confirmation information, payment schemes, payment execution units, payment invocation processes, and external business status corresponding to the same enterprise payment task. It is stored in the memory of the enterprise payment intelligent agent processing device or in a relational database connected to it. The payment execution evidence graph uses a unified payment task identifier as the graph data index, ensuring that the status evidence nodes formed under different user confirmation versions, different payment scheme versions, and different payment execution paths for the same enterprise payment task belong to the same payment execution evidence graph.

[0025] The status evidence nodes include user confirmation nodes, payment scheme nodes, payment execution unit nodes, payment invocation nodes, external business acceptance nodes, and payment result nodes. Each status evidence node is stored in the form of node data records, including at least the node identifier, node type, unified payment task identifier, node generation time, and node status. Specifically, the user confirmation node records the user confirmation version and total payment share; the payment scheme node records the payment scheme version, payment method, and corresponding payment execution share; the payment execution unit node records the payment execution unit identifier, payment method, payment execution share, and payment execution status; the payment invocation node records the payment invocation identifier, payment execution association identifier, and payment invocation result; the external business acceptance node records the external business identifier and external acceptance status; and the payment result node records the payment processing result and actual payment share.

[0026] The relationships between the status evidence nodes include confirmation and authorization relationships, task splitting relationships, execution invocation relationships, status receipt relationships, payment share coverage relationships, and payment path substitution relationships. Specifically, the confirmation and authorization relationship points from the user confirmation node to the corresponding payment scheme node; the task splitting relationship points from the payment scheme node to the payment execution unit node generated based on that payment scheme; the execution invocation relationship points from the payment execution unit node to the corresponding payment invocation node; the status receipt relationship is established between the payment invocation node and the external business acceptance node or payment result node based on the payment execution association identifier or external business identifier; the payment share coverage relationship records the responsibility of each payment execution unit for the total payment share and verifies the correspondence between each payment execution share and the total payment share; and the payment path substitution relationship is established between the payment scheme node before adjustment and the payment scheme node after adjustment to record the change process of the payment path.

[0027] When the interface control gateway receives a new external service status, the processor determines the corresponding payment invocation node based on the payment execution association identifier or the external service identifier. When the external service status indicates that the payment processing system has accepted and started processing the corresponding payment service, an external service acceptance node is generated. When the external service status indicates that the corresponding payment execution unit has generated a success, failure, cancellation, or rejection result, a payment result node is generated. The newly generated status evidence node is appended to the payment execution evidence graph and establishes a status receipt relationship with the corresponding payment invocation node, without overwriting the already formed historical status evidence nodes.

[0028] When the user confirmation content changes or the payment path is adjusted, the processor generates a new user confirmation node or payment scheme node and establishes a payment path substitution relationship between the pre-adjustment payment scheme node and the post-adjustment payment scheme node. The payment execution unit node, payment invocation node, external business acceptance node, and payment result node corresponding to the pre-adjustment payment scheme remain in the payment execution evidence graph; among them, payment execution states that have entered the execution stage that forms external payment impact and whose corresponding external payment impact has not been withdrawn, reversed, or eliminated by compensation processing continue to serve as the basis for determining the valid payment state; payment execution states that have not yet entered the execution stage and have been replaced by the post-adjustment payment scheme no longer participate in the generation of the current unified payment state.

[0029] For example, in enterprise payment task T001, the total payment amount is 1 million yuan. The user confirms payment of 600,000 yuan via digital invoice and 400,000 yuan via foreign exchange. The processor generates a user confirmation node C01 and a payment scheme node P01, and based on the payment scheme P01, generates a digital invoice payment execution unit node U01 and a foreign exchange payment execution unit node U02, where U01 and U02 correspond to the payment execution amounts of 600,000 yuan and 400,000 yuan, respectively. After scheduling U01, the processor generates a payment call node M01. When the digital invoice processing system returns the acceptance status, it generates an external business acceptance node R01. Subsequently, when the payment success result is returned, it generates a payment result node F01 to record that the 600,000 yuan corresponding to U01 has been successfully paid.

[0030] When U02 fails and the corresponding 400,000 yuan is adjusted to digital RMB payment, the processor generates an adjusted payment scheme node P02 and establishes a payment path substitution relationship between P01 and P02. Simultaneously, a digital RMB payment execution unit node U03 is generated based on P02. The original payment scheme P01 and its corresponding status evidence nodes are retained. Specifically, the successful payment result of 600,000 yuan corresponding to U01 continues to participate in determining the valid payment status, while the failure status corresponding to U02 is used to retain the execution record of the original payment path. The adjusted payment scheme P02 continues to be executed only for the remaining 400,000 yuan.

[0031] Optionally, in steps S3 and S4, determining whether the payment execution unit has entered the execution stage that creates external payment impact includes judging whether the corresponding payment call has been sent to the payment processing system, whether the payment processing system has generated an external business identifier, whether a clear acceptance result has been returned, and whether the payment share corresponding to the acceptance result matches the payment execution share of the corresponding payment execution unit. The processor obtains the payment call result, external business identifier, and acceptance result through the interface control gateway, and determines the corresponding payment execution unit based on the payment execution association identifier.

[0032] The successful sending of a payment call only indicates that the payment call request has been sent and is not a sole criterion for entering the execution phase. The external business identifier includes at least one of the following: business serial number, transaction serial number, payment acceptance number, bill business number, voucher transfer number, letter of credit application number, or electronic guarantee application number, used to indicate that the payment processing system has established a corresponding external business processing object. The processor determines the payment execution unit corresponding to the acceptance result based on the external business identifier and compares the accepted amount, bill amount, voucher amount, payment limit, or payment ratio with the corresponding payment execution share. When all payment execution shares are accepted, they are all determined as accepted shares; when only a portion of the payment execution shares are accepted, the accepted shares and unaccepted shares are determined separately.

[0033] When the payment processing system has accepted a corresponding payment call and formed an external business processing status that cannot be eliminated simply by deleting the payment execution unit, stopping the internal payment process, or invalidating the current payment scheme, it is determined that the corresponding payment execution unit has entered the execution stage that creates external payment impact. The external business processing status includes at least one of the following: fund processing, payment quota occupation, bill endorsement processing, blockchain voucher circulation, digital RMB payment acceptance, foreign exchange payment processing, letter of credit application processing, or electronic guarantee application processing. If a payment call has only been sent but has not yet obtained a valid external business identifier or a clear acceptance result, it is not certain that it has entered the execution stage; if the payment processing system returns a result of non-acceptance, parameter verification failure, interface call failure, or no business application establishment result, it is determined that it has not yet entered the execution stage.

[0034] For a currently valid payment scheme that corresponds to the user-confirmed version and has not been replaced by a subsequent payment scheme, the processor determines the corresponding payment execution unit based on the payment scheme version and payment execution association identifier. The processor then defines the payment execution status that has not been eliminated through withdrawal, reversal, or compensation processing and has not been replaced by a subsequent valid payment result as the current valid payment status. For payment execution statuses in historical payment schemes that have entered the execution stage and whose corresponding external payment impact has not been eliminated through withdrawal, reversal, or compensation processing, these statuses are retained as historical valid payment statuses and continue to be associated with the corresponding payment execution share, participating in the unified payment status generation.

[0035] When the withdrawal, reversal, or compensation process is not yet completed, the validity of the original payment execution status is retained, and the corresponding processing status is recorded. When the withdrawal, reversal, or compensation is successful, and the original external payment impact has been eliminated or offset, the original payment execution status is marked as invalid and no longer participates in the unified payment status generation, but continues to be retained in the payment execution evidence diagram and the entire process tracking record. When the withdrawal, reversal, or compensation process fails, the original payment execution status is retained, and the corresponding status evidence node is updated according to the processing result.

[0036] For payment execution states that have been replaced by the adjusted payment scheme but have not yet entered the execution phase, they are excluded from the valid payment states and no longer participate in the determination of the current unified payment state and the remaining payment execution share. However, the corresponding payment scheme version, payment execution unit, payment call record, and state change process are still retained. The processor uses the current valid payment state and the payment execution share corresponding to the historical valid payment states as the state basis for generating the unified payment state in step S5.

[0037] When user-confirmed content changes or the payment path is adjusted, this invention retains the payment execution share that has already resulted in a valid payment, as well as the payment execution share that has entered the execution stage that will have an external payment impact but has not yet reached a final processing result. The remaining payment execution share is determined based on the difference between the current total payment share and the retained payment execution share. An adjusted payment plan is generated only for the remaining payment execution share, thereby improving the accuracy of determining the remaining payment share after partial payment and reducing the risk of duplicate payment or overpayment caused by the repeated allocation of payment execution shares that have been successfully paid or are still in the external processing process.

[0038] Optionally, in steps S5 and S6, the unified payment status includes pending review, approved, rejected, pending payment, pending receipt, in progress, in progress, partially failed, failed, successful, cancelled, and rejected;

[0039] Based on each valid payment status, the share of successful payment, the share of execution, the share of failed payment, and the share of unexecuted payment are determined. Specifically, the processor in the enterprise payment intelligent agent processing device reads the valid payment statuses generated by the current unified payment status from the payment execution evidence graph, and classifies the current total payment share according to the payment execution unit, payment execution share, external business acceptance node, and payment result node associated with each valid payment status. Among them, the same payment execution share is only classified into one of the following at the same time of status determination: successful payment share, execution share, failed payment share, or unexecuted payment share, so as to avoid the same payment execution share being counted repeatedly because there are payment call records, external business acceptance records, and payment result records at the same time.

[0040] When all payment execution shares of a payment execution unit have the same valid payment status, all payment execution shares corresponding to that payment execution unit are assigned to the corresponding status share. When the payment processing system only accepts, processes, or completes payment for a portion of the payment execution shares in a payment execution unit, the processor divides the payment execution shares corresponding to that payment execution unit into two or more payment status measurement sub-shares based on the actual accepted amount, actual processed amount, or actual payment amount recorded in the external business status, and determines the payment status corresponding to each payment status measurement sub-share. The payment status measurement sub-shares still maintain the association relationship with the original payment execution unit, payment invocation process, external business acceptance node, and payment result node.

[0041] The successful payment share refers to the payment execution share where a valid successful payment result has been formed and the corresponding payment result has not been withdrawn, reversed, or offset by a compensation result. The in-process payment share refers to the payment execution share that has entered the execution stage that forms an external payment impact, but has not yet formed a definite payment success, payment failure, cancellation, or rejection result. The in-process payment share also includes the payment execution share that is currently executing withdrawal, reversal, or compensation processing, but has not yet obtained a withdrawal completion, reversal completion, or compensation completion result. The failed payment share refers to the payment execution share that has formed a clear payment failure result and confirmed that no valid external payment result has been formed, or the original external payment impact has been eliminated through withdrawal, reversal, or compensation processing. The unexecuted payment share refers to the payment execution share that has not yet formed a successful payment result, has not entered the execution stage that forms an external payment impact, and has not been occupied by a valid payment call. In this embodiment, to determine the share of each status, the total payment share corresponding to the current user-confirmed version is recorded as follows: The total payment share is divided according to different valid payment statuses. The payment status measurement sub-share, the first The actual payment amount corresponding to each payment status measurement sub-share is denoted as: ,in: ; ;in, This indicates the total payment amount corresponding to the version confirmed by the current user; Indicates the first The actual payment amount corresponding to each payment status sub-share is measured; This indicates the number of payment status measurement sub-shares obtained based on the effective payment status; when the payment execution share is represented by a payment ratio, the processor determines the corresponding actual payment amount based on the current total payment amount and the corresponding payment ratio; the total payment share and each payment status measurement sub-share in the same enterprise payment task are represented by the same settlement currency or a unified payment measurement unit. For the first... Each payment status is used to measure sub-shares, and the current scheme identifier is set. Historical scheme identification External execution phase identifier and external impact elimination mark ,in: When the corresponding payment status measurement sub-share belongs to the currently valid payment scheme, ,otherwise When the corresponding payment status measurement sub-share belongs to a historical payment scheme, ,otherwise When the corresponding payment status measurement sub-share has entered the execution phase that creates external payment impact, ,otherwise When the external payment impact arising from the measurement of the corresponding payment status sub-share has been eliminated through withdrawal, reversal, or compensation, ,otherwise The determination of the first [item] based on the evidentiary relationship for payment enforcement. Valid participation identifier for each payment status measurement sub-share : ;in, ;when When, it indicates that the corresponding payment status measurement sub-share participates in the generation of the current unified payment status; when When this occurs, it indicates that the corresponding payment status measurement sub-share does not participate in the generation of the current unified payment status; the symbol " "Represents logical OR, , symbol" "Represents logical AND, , symbol" The "" indicates logical NOT. Therefore, payment execution shares belonging to the currently valid payment scheme participate in the generation of unified payment status; payment execution shares belonging to historical payment schemes that have entered the execution stage and have formed external payment impacts, and whose corresponding external payment impacts have not yet been eliminated, continue to participate in the generation of unified payment status; payment execution shares that have been withdrawn, reversed, or compensated and whose corresponding external payment impacts have been eliminated no longer participate in the generation of the current unified payment status. Furthermore, separate payment success status indicators are set. Execution status indicator Payment failure status indicator and status indicators that have not yet been executed ,in: For the same payment status measurement sub-shares participating in the generation of the current unified payment status, the following conditions must be met: .

[0042] When the corresponding payment result node indicates that the payment has been successful, and the successful payment result has not been withdrawn, reversed, or offset by compensation, then it is determined. When the corresponding payment execution unit has entered the execution stage that creates external payment impact, but a definite payment result has not yet been formed, the determination is... When the corresponding payment result node indicates that the payment execution failed, and it is confirmed that no external payment result was formed or the corresponding external payment impact has been eliminated, then determine... When the corresponding payment execution share has not yet entered the execution stage that creates external payment impact, and has not been occupied by a valid payment invocation, it is determined that... The percentage of successful payment. Share in execution Share of payment failure and the unexecuted share Determine them according to the following formulas respectively: ; ; ; .in, Indicates the amount successfully paid; Indicates the share in execution; Indicates the amount of payment that failed; This indicates that the share has not yet been executed; the value range of each share in each state satisfies: When all total payment shares are covered by current valid payment status, the payment share conservation relationship is satisfied: When all payment execution shares result in valid successful payments, the unified payment status is determined to be successful; that is, when ,and When a unified payment status is determined to be successful, and there are both successful and failed payment shares, and no shares are in progress, the unified payment status is determined to be partially failed; that is, when... , and When a payment fails, the unified payment status is determined to be partially failed. If there are still unexecuted portions, these unexecuted portions remain as pending portions or are subject to adjustment in subsequent payment plans. When there are no successfully executed portions, and all executed payment portions result in payment failure, the unified payment status is determined to be failed; that is, when... , If all payment execution shares that have entered the payment execution process result in payment failure, the unified payment status will be determined as failure.

[0043] When there is at least one payment execution unit that has entered the execution stage but has not yet formed a final processing result, the unified payment status is determined as either "paying" or "receiving"; that is, when At that time, the unified payment status is determined according to the payment direction corresponding to the enterprise's payment task; when the payment direction is an external payment from the payer to the payee, the unified payment status is determined as "Paying"; when the payment direction is an external payer to the current enterprise, the unified payment status is determined as "Receiving"; when the enterprise's payment task requires internal review, and user confirmation has been obtained but internal review results have not yet been obtained, the unified payment status is determined as "Pending Review"; when internal review has been passed, and the corresponding payment execution unit has not yet entered the execution stage that would affect external payments, the unified payment status is determined as "Review Passed"; when the enterprise's internal review returns a "Not Processing" result, the unified payment status is determined as "Rejected"; when the enterprise's payment task has completed user confirmation and necessary internal review, and At that time, the unified payment status will be determined as either pending payment or pending receipt based on the corresponding payment direction; when the user cancels the enterprise payment task, and , When the unified payment status is cancelled, the unified payment status will be determined as cancelled. When the external payment processing system, counterparty, or external business participant returns a clear rejection result, and all currently pending payment shares have corresponding rejection results, the unified payment status will be determined as rejected. Among them, rejected indicates that the internal review of the enterprise failed, and rejected indicates that the external payment processing system or external business participant refused to process the payment.

[0044] When determining the remaining payment execution share, the payment execution shares that have already resulted in valid payments and the payment execution shares that have entered the execution stage but have not yet reached a final processing result are deducted from the current total payment share. Specifically, the successfully paid share is defined as the payment execution share that has already resulted in a valid payment and cannot be paid again, and the execution share is defined as the execution share that has entered the external payment processing process but has not yet reached a final result. The execution share is not allocated to the adjusted payment scheme before the corresponding external payment result is determined. The remaining realizable payment execution share is denoted as... ,but: According to the principle of conservation of payment shares, the following conditions also apply: ;in, This represents the remaining payment execution share that can regenerate the payment path, and its value range satisfies: The payment failure share is only included in the remaining payment execution share after it has been confirmed that no valid external payment result has been formed, or the corresponding external payment impact has been eliminated by withdrawal, reversal, or compensation. The unexecuted share, not yet in the execution stage that forms an external payment impact, can be directly included in the remaining payment execution share. When a payment execution unit that has entered the execution stage results in a payment failure and confirms that no external payment result has been formed, the retention status of the corresponding payment execution share is released, and the corresponding payment execution share is re-included in the remaining payment execution share. When a payment execution unit that has entered the execution stage results in a payment success, the corresponding execution share is converted to a payment success share; when the external payment impact of the corresponding payment execution unit is eliminated through withdrawal, reversal, or compensation, the execution occupation status of the corresponding execution share is released, and the corresponding payment execution share is included in the remaining payment execution share. The processor regenerates the unified payment status of the enterprise payment task based on the updated payment success share, execution share, payment failure share, and unexecuted share. For example, in this embodiment, the total payment share corresponding to the current user-confirmed version... The total amount is 1 million yuan, and the payment plan includes 600,000 yuan in digital invoices, 200,000 yuan in digital RMB, and 200,000 yuan in foreign exchange. Of these, the 600,000 yuan corresponding to the digital invoices has been successfully paid; the 200,000 yuan corresponding to the digital RMB has been processed by the digital RMB payment system but has not yet reached a final processing result; and the 200,000 yuan corresponding to the foreign exchange has resulted in a payment failure and it has been confirmed that no bank payment has been made. Therefore: Ten thousand yuan; Ten thousand yuan; Ten thousand yuan; .because This indicates that there are still payment execution shares that have entered the execution stage and have formed an external payment impact, but have not yet reached a final processing result. Therefore, the current unified payment status is determined as "paying". At this time, the remaining payment execution shares are: The total amount is RMB 10,000. Therefore, the enterprise payment intelligent agent processing device only generates adjusted payment schemes for the RMB 200,000 for which foreign exchange payments failed and have been confirmed as not having resulted in external payments; the RMB 600,000 for which digital bills have already been successfully paid will not be redistributed, and the RMB 200,000 corresponding to the digital RMB will remain in an execution-occupied state and will not be reallocated to other payment paths. When the RMB 200,000 corresponding to digital RMB subsequently results in a successful payment, the successful payment share will be updated to RMB 800,000, the execution-in-progress share will be updated to 0, and the failed payment share will remain at RMB 200,000; since there are both successful and failed payment shares, and no execution-in-progress share, the unified payment status will be determined as partial failure. When the adjusted payment scheme generated for the remaining RMB 200,000 is successfully executed, the successful payment share will be updated to RMB 1,000,000, satisfying the requirement of RMB 1,000,000. This updates the unified payment status to successful. Furthermore, this application also provides a unified status mapping and end-to-end tracking system for multiple enterprise payment methods. The unified status mapping and end-to-end tracking system includes a payment task orchestration and execution association module, a payment execution evidence and status determination module, a unified status generation and payment scheme reconstruction module, and an end-to-end tracking module. The unified status mapping and end-to-end tracking system also includes a business interaction terminal, an enterprise payment intelligent agent processing device, an interface control gateway, and at least one payment processing system. The business interaction terminal is communicatively connected to the enterprise payment intelligent agent processing device and is used to receive enterprise payment requests input by the user, output payment schemes, and receive confirmation information input by the user for the payment schemes. The enterprise payment intelligent agent processing device is communicatively connected to each payment processing system through the interface control gateway and is used to send payment call requests to the corresponding payment processing system and receive external business identifiers and external business statuses returned by each payment processing system. The enterprise payment intelligent agent processing device is constructed from a processor, a memory, a communication interface, a data bus, and a power supply device. The processor, memory, and communication interface are respectively connected to the data bus, and program instructions are transmitted and payment business data is interacted through the data bus. The power supply device is electrically connected to the processor, memory, and communication interface, and is used to provide operating power to the processor, memory, and communication interface. The communication interface is communicatively connected to the business interaction terminal and the interface control gateway.

[0045] The power supply device is electrically connected to the enterprise payment intelligent agent processing device, the payment task orchestration and execution association module, the payment execution evidence and status determination module, the unified status generation and payment scheme reconstruction module, and the full-process tracking module, respectively, to maintain the normal operation of the enterprise payment intelligent agent processing device, the payment task orchestration and execution association module, the payment execution evidence and status determination module, the unified status generation and payment scheme reconstruction module, and the full-process tracking module. The power supply device adopts an integrated server power supply, an industrial computer power supply, or other ready-made power supply equipment compatible with the enterprise payment intelligent agent processing device; the input end of the power supply device is used to connect to the mains power, and the output end is electrically connected to the hardware carrier where the processor, memory, communication interface, and data bus are located, respectively, to convert the connected mains power into the power supply voltage required for the normal operation of the processor, memory, communication interface, and data bus, and to maintain the continuous operation of the enterprise payment intelligent agent processing device.

[0046] The processor is a central processing unit, server processor, or on-chip processor capable of calling program instructions stored in the memory and performing tasks such as payment task splitting, payment call control, external business status association, payment execution evidence relationship construction, valid payment status determination, unified payment status generation, payment scheme reconstruction, and full-process tracking. In this embodiment, the processor may be an Intel Xeon Silver 4310 processor, an Intel Xeon Gold 6330 processor, an AMD EPYC 7313P processor, or a Kunpeng 920 processor, or other processors with corresponding data processing and communication control capabilities.

[0047] The enterprise payment intelligent agent processing device is a shared hardware platform for the payment task orchestration and execution association module, the payment execution evidence and status determination module, the unified status generation and payment scheme reconstruction module, and the full-process tracking module. All four modules are deployed within the enterprise payment intelligent agent processing device, and are not separate hardware devices located outside of it. The memory stores program instructions corresponding to the four modules, as well as enterprise payment task data, user confirmation data, payment scheme data, payment execution unit data, external business status data, payment execution evidence data, unified payment status data, and full-process tracking data. The processor calls and executes the program instructions to respectively form the payment task orchestration and execution association module, the payment execution evidence and status determination module, the unified status generation and payment scheme reconstruction module, and the full-process tracking module. The four modules mentioned above share the processor, memory, communication interface, and data bus in the enterprise payment intelligent agent processing device, and are connected through the unified payment task identifier, user confirmation version, payment scheme version, payment execution unit identifier, and payment execution association stored in the memory. The processing result generated by the previous module is written into the memory and used as the input data when the next module performs the corresponding processing, so that payment task orchestration, external state association, effective payment status determination, unified payment status generation, payment scheme reconstruction, and full-process tracking are continuously executed under the same enterprise payment task.

[0048] The payment task orchestration and execution association module is used to acquire enterprise payment tasks and, based on the payment scheme confirmed by the user, divide the enterprise payment tasks into one or more payment execution units. Each payment execution unit corresponds to a payment method and a corresponding payment execution share. Specifically, the business interaction terminal sends the enterprise payment request and user confirmation information to the enterprise payment intelligent agent processing device. The processor calls the program instructions corresponding to the payment task orchestration and execution association module, generates a payment scheme based on the enterprise payment request and user confirmation information, and creates payment execution task instances in the memory that match each payment method and corresponding payment execution share, thus forming... The payment execution unit is formed; the payment task orchestration and execution association module calls the payment processing system corresponding to each payment execution unit, and establishes an execution association relationship between each payment execution unit and the corresponding payment call process and external business status; the processor generates a payment call request according to the payment method corresponding to each payment execution unit, and sends the payment call request to the interface control gateway through the communication interface; the interface control gateway adapts the payment call request to the interface according to the interface specification of the corresponding payment processing system and sends it to the corresponding payment processing system; the interface control gateway receives the external business identifier and external business status returned by the payment processing system, and sets the external business status as the external business status. The service identifier and external business status are sent to the enterprise payment intelligent agent processing device, whereby the processor writes them into the payment execution task instance of the corresponding payment execution unit. The payment execution evidence and status determination module constructs the payment execution evidence relationship of the enterprise payment task based on user confirmation information, payment scheme, payment invocation process, and the external business status, and determines whether each payment execution unit has entered the execution stage that forms an external payment impact based on the payment execution evidence relationship. The payment execution unit, payment invocation process, and execution association relationship formed by the payment task orchestration and execution association module are written into the memory and used as input data for the payment execution evidence and status determination module. According to the processor, the program instructions corresponding to the payment execution evidence and status determination module are invoked to convert user confirmation information, payment scheme, payment execution unit, payment invocation process, and external business status into interrelated status evidence data, and the status evidence data and corresponding relationships are stored in the memory or in an association database that is communicatively connected to the enterprise payment intelligent agent processing device; the payment execution evidence and status determination module determines the valid payment status participating in the generation of the current unified payment status based on the payment execution status corresponding to the current valid payment scheme and the payment execution status of historical payment schemes that have entered the execution stage but have not yet been withdrawn or compensated;The processor filters the payment execution status of the current and historical payment schemes based on the payment scheme version, payment execution correlation, and whether the external payment impact has been eliminated. It then writes the determined valid payment status and its corresponding payment execution share into the memory as input data for the unified status generation and payment scheme reconstruction module.

[0049] By using unified payment task identifier, user confirmation version, payment scheme version, payment execution unit identifier, payment call identifier, and payment execution association identifier, execution association relationships are established between payment execution units, payment call processes, external business identifiers, and external business statuses. For external business statuses whose affiliation cannot be determined, they are saved as pending association statuses and their direct participation in unified payment status generation is restricted. This reduces payment execution status errors and unified payment status distortions caused by asynchronous receipts, delayed receipts, duplicate receipts, or the mixing of different payment call results.

[0050] The unified status generation and payment scheme reconstruction module generates a unified payment status for the enterprise payment task based on the payment execution share corresponding to each valid payment status. The processor calls the program instructions corresponding to the unified status generation and payment scheme reconstruction module to generate a unified payment status representing the overall processing status of the enterprise payment task based on the payment success share, execution share, payment failure share, and unexecuted share corresponding to each valid payment status, and writes the unified payment status into the memory. When the user confirmation content changes or the payment path is adjusted, the payment execution shares that have formed valid payment results and the payment execution shares that have entered the execution stage are retained, and the remaining payment execution shares are determined based on the difference between the current total payment share and the retained payment execution shares. The remaining payment execution share generates an adjusted payment scheme; the processor marks the payment execution shares that have formed valid payment results and the payment execution shares that have entered the execution stage but have not yet formed a final processing result as reserved shares that will not be reassigned, and creates new payment execution task instances only for the remaining payment execution shares; the adjusted payment scheme is output through the business interaction terminal, and after user confirmation, it becomes the new currently valid payment scheme, and the payment task orchestration and execution association module continues to establish the corresponding payment execution units and execution association relationships; the full-process tracking module associates and records the payment execution evidence relationship, the payment execution status of each payment execution unit, the unified payment status, and the payment path change process, and generates the full-process tracking result of the enterprise payment task. The end-to-end tracking module acquires the payment execution unit and execution association data formed by the payment task orchestration and execution association module, the payment execution evidence relationship and valid payment status data formed by the payment execution evidence and status determination module, and the unified payment status and payment scheme change data formed by the unified status generation and payment scheme reconstruction module. The processor calls the program instructions corresponding to the end-to-end tracking module, using the unified payment task identifier as the association index, to associate and store user confirmation information, payment scheme version, payment execution unit, payment call process, external business status, valid payment status, unified payment status, payment path change process, and final processing result, and generates the end-to-end tracking result of the corresponding enterprise payment task.The end-to-end tracking results are sent to the business interaction terminal, review terminal, or audit terminal via the communication interface to display the current unified payment status of the enterprise payment task and the corresponding status formation process. Optionally, the payment task orchestration and execution association module includes a payment scheme generation unit, a payment execution task generation unit, and an execution association unit. In this embodiment, the payment scheme generation unit, payment execution task generation unit, and execution association unit are all program functional units deployed in the enterprise payment intelligent agent processing device, respectively corresponding to the payment scheme generation program, payment execution unit generation program, and execution association program stored in the memory. After the processor calls and executes the corresponding executable program or program instructions, it realizes the data processing function corresponding to each program functional unit. The payment scheme generation unit, payment execution task generation unit, and execution association unit are software functional units that rely on the processor, memory, communication interface, and data bus in the enterprise payment intelligent agent processing device to run. The payment scheme generation unit, payment execution task generation unit, and execution association unit are functional processing units formed by the processor in the enterprise payment intelligent agent processing device after calling corresponding program instructions, and they share the memory and communication interface in the enterprise payment intelligent agent processing device. The payment scheme data generated by the payment scheme generation unit is written into the memory and used as input data for the payment execution task generation unit to generate the payment execution unit. The payment execution unit data generated by the payment execution task generation unit is written into the memory and used as input data for the execution association unit to establish the execution association relationship. The payment scheme generation unit is used to generate a payment scheme based on user confirmation information. The payment scheme includes at least one payment method, the payment execution share corresponding to each payment method, the payment execution order, the payment execution conditions, and the corresponding payment processing system. The user confirmation information is obtained through a business interaction terminal. The payment scheme generation unit receives and establishes a corresponding relationship with the current enterprise payment task. Based on the total payment share, payment direction, and payment method confirmed in the user confirmation information, the payment scheme generation unit determines the payment execution share corresponding to each payment method and stores the generated payment scheme in association with the corresponding enterprise payment task. When the user confirmation information is modified, the modified user confirmation information is used as the new valid confirmation information, and a corresponding payment scheme version is generated accordingly. The payment execution task generation unit is used to divide the enterprise payment task into one or more payment execution units according to the payment methods and corresponding payment execution shares in the payment scheme. Each payment execution unit is a payment execution task instance created by the processor in the memory based on the payment scheme. Each payment execution task instance records at least the corresponding payment method, payment execution share, payment processing system, payment execution conditions, and current payment execution status.After completing the payment task division, the payment execution task generation unit sets the initial payment execution status of each payment execution unit to "pending execution" and establishes the attribution relationship between each payment execution unit and its respective enterprise payment task and corresponding payment scheme. When the same payment method needs to be completed through different payment accounts, different payment carriers, or different execution batches, corresponding payment execution units are generated respectively, so that each payment execution process can independently call and independently maintain the external business status. The execution association unit is used to generate a unified payment task identifier for the enterprise payment task, generate a user confirmation version and a payment scheme version for the payment scheme, and, based on the unified payment task identifier, user confirmation version, payment scheme version, and payment scheme version, generate a unified payment task identifier, user confirmation version, payment scheme version, and payment scheme version. The payment execution unit identifier and payment invocation identifier generate a payment execution association identifier. The user confirmation version identifies the user confirmation information upon which the current payment scheme is based. The payment scheme version distinguishes payment schemes formed under different user confirmation contents or different payment paths for the same enterprise payment task. The payment invocation identifier distinguishes different payment invocation processes initiated for the corresponding payment execution unit. A hierarchical association is established between the unified payment task identifier, user confirmation version, payment scheme version, payment execution unit identifier, and payment invocation identifier, enabling the payment invocation process to be traced back to the corresponding enterprise payment task and the user confirmation information and payment scheme upon which the payment invocation process was based. Specifically, by constructing a payment execution evidence relationship including user confirmation nodes, payment scheme nodes, payment execution unit nodes, payment invocation nodes, external business acceptance nodes, and payment result nodes, and by distinguishing different payment paths through user confirmation versions and payment scheme versions, when a payment scheme is adjusted, the state evidence of the payment path before the adjustment is retained. Simultaneously, payment execution states that have not yet entered the execution stage that forms external payment impact and have been replaced are excluded from the current unified payment state generation process, preventing the state of invalid payment paths from continuing to interfere with the current payment task.

[0051] The execution association unit is further configured to write the payment execution association identifier into the corresponding payment call process, and establish a correspondence between the external business identifier returned by the payment processing system and the payment execution association identifier, so as to determine the enterprise payment task, user confirmation version, payment scheme version and payment execution unit corresponding to the external business status based on the payment execution association identifier or the external business identifier; specifically, the execution association unit associates and stores the payment execution association identifier with the corresponding payment call request, payment call time and payment call result; when the payment processing system can receive the payment execution association identifier, it sends the payment execution association identifier to the corresponding payment processing system along with the payment call request; when the payment processing system cannot receive or returns the payment execution association identifier, it returns the payment execution association identifier to the corresponding payment processing system. The returned external business identifier and the corresponding payment execution association identifier of the payment call process are written into the execution association record to establish the correspondence between the external business status and the internal payment execution unit. When the same payment execution unit re-initiates a payment call due to communication timeout, interface abnormality, or the payment processing system not returning a clear acceptance result, the execution association unit generates a new payment call identifier and payment execution association identifier for the re-initiated payment call, and retains the execution association record corresponding to the previous payment call to avoid confusion between the external business statuses returned by different payment call processes. For external business statuses that cannot be associated with the corresponding payment execution unit, the external business status is marked as a pending association status, and the pending association status is restricted from participating in the generation of the current unified payment status. The execution association unit stores the pending association state along with the external business identifier, state source, state content, and state reception time in the pending association state area. When it subsequently obtains the payment execution association identifier, external business identifier, or payment call information corresponding to the pending association state, it re-executes the association matching. After determining the enterprise payment task, user confirmation version, payment scheme version, and payment execution unit corresponding to the pending association state, it transfers the pending association state to the corresponding payment execution unit. Before completing the association matching, the pending association state does not change the current payment execution state of any payment execution unit, nor does it serve as the basis for generating payment execution evidence relationships and unified payment states.

[0052] Optionally, the payment execution evidence and status determination module includes a payment execution evidence construction unit, an execution stage determination unit, and a valid status filtering unit. This module is a program function module deployed in the enterprise payment intelligent agent processing device. The payment execution evidence construction unit, execution stage determination unit, and valid status filtering unit are all program function units implemented by the processor calling corresponding executable programs or program instructions in the memory. Each program function unit shares the processor, memory, communication interface, and data bus. The payment execution evidence construction unit generates status evidence nodes based on user confirmation information, payment scheme, payment execution unit, payment invocation process, external business status, and payment processing result, and establishes payment execution evidence relationships between these status evidence nodes. The status evidence nodes are structured data records stored in the memory or an associated database. The payment execution evidence relationships are used to record the association between user confirmation, payment scheme, payment execution unit, payment invocation, and external processing result. The execution phase determination unit determines whether the corresponding payment execution unit has entered the execution phase that forms an external payment impact based on whether the payment call has been accepted by the corresponding payment processing system, whether a corresponding external business identifier has been generated, and the payment execution share corresponding to the external business status. Specifically, the execution phase determination unit associates the payment call node with the corresponding external business acceptance node and payment result node based on the payment execution association identifier, and determines whether the payment call has been accepted by the corresponding payment processing system, whether an external business identifier capable of identifying an independent external business processing process has been generated, and whether the payment share actually accepted by the payment processing system corresponds to all or part of the payment execution share of the corresponding payment execution unit. When the payment processing system has... Upon acceptance of a payment call, and the formation of an external business processing state that cannot be eliminated simply by deleting the payment execution task instance, stopping the internal payment process, or invalidating the current payment scheme, the execution stage determination unit determines that the corresponding payment execution unit has entered the execution stage that creates external payment impact, and records the actual payment execution share that has entered the execution stage. When a payment call is only sent, but the payment processing system has not yet returned a valid external business identifier or a clear acceptance result, it is not determined that the corresponding payment execution unit has entered the execution stage. When the payment processing system returns a result of parameter verification failure, interface call failure, business application not established, or clear non-acceptance, it is determined that the corresponding payment execution unit has not yet entered the execution stage.

[0053] When the payment processing system only accepts a portion of the payment execution shares in the payment execution unit, the execution stage determination unit determines the actually accepted payment execution shares as those that have entered the execution stage, and determines the unaccepted payment execution shares as those that have not yet entered the execution stage, in order to avoid incorrectly marking payment shares that have not actually entered the external payment processing process as execution shares.

[0054] The valid status filtering unit determines the payment execution status corresponding to the current valid payment scheme as the current valid payment status, and retains the payment execution status of historical payment schemes that have entered the execution stage but have not yet formed a withdrawal result, reversal result, or compensation result as historical valid payment statuses; wherein, the withdrawal result, reversal result, or compensation result is a processing result that confirms that the original external payment impact has been eliminated or offset; when the corresponding processing is still in progress or has failed, the original payment execution status continues to be regarded as a historical valid payment status. The valid status filtering unit is also used to exclude payment execution statuses that have been replaced by adjusted payment schemes and have not yet entered the execution stage from the generation process of the current unified payment status. For payment execution units that have been replaced by the adjusted payment scheme but have not yet entered the execution stage that forms an external payment impact, the effective status filtering unit marks their payment execution status as replaced and stops them from participating in the unified payment status generation and payment execution share statistics. The payment execution units marked as replaced, their corresponding payment schemes, payment call records, and status evidence nodes are not deleted from the memory, but are retained in the payment execution evidence relationship to record the task orchestration and payment call process before the payment path adjustment.

[0055] The effective status filtering unit writes the filtered current effective payment status, historical effective payment status, and their corresponding payment execution shares into the memory, and sends the effective payment status and payment execution shares to the unified status generation and payment scheme reconstruction module as input data for determining the payment success share, execution share, payment failure share, and unexecuted share, and generating the unified payment status of the enterprise payment task. Specifically, by using the payment call acceptance result, external business identifier, and the actual accepted payment execution share, it determines whether the payment execution unit has entered the execution stage that forms an external payment impact. For payment execution statuses in historical payment schemes that have entered the execution stage and whose corresponding external payment impact has not been withdrawn, reversed, or eliminated through compensation processing, they are retained as historical effective payment statuses, thereby avoiding the omission of payment execution shares that have entered the external payment processing process due to the replacement of internal payment schemes.

[0056] Optionally, the unified state generation and payment scheme reconstruction module includes an execution state determination unit, a unified state generation unit, a reserved share determination unit, and a remaining share reconstruction unit. This module is a program function module deployed in the enterprise payment intelligent agent processing device. The execution state determination unit, unified state generation unit, reserved share determination unit, and remaining share reconstruction unit are all program function units implemented by the processor calling corresponding executable programs or program instructions in the memory; they are not independent hardware devices. Each program function unit shares the processor, memory, communication interface, and data bus in the enterprise payment intelligent agent processing device and is associated with data through the unified payment task identifier, payment scheme version, and payment execution unit identifier in the memory. The execution state determination unit is used to determine the pending execution state, executing state, successful execution state, failed execution state, canceled state, or rejected state of the corresponding payment execution unit based on the external business state and payment processing result corresponding to each valid payment state. When different payment execution shares in the same payment execution unit result in different processing results, the corresponding execution state is determined according to the actual payment share corresponding to each processing result. The unified status generation unit is used to generate a unified payment status for the enterprise payment task based on the execution status of each payment execution unit and the corresponding payment execution share. The unified payment status includes pending review, approved review, rejected, pending payment, pending collection, in progress payment, in progress collection, partially failed, failed, successful, cancelled, and rejected. The unified payment status is used to represent the overall processing status of the enterprise payment task and is updated according to changes in the payment success share, execution share, payment failure share, and unexecuted share. When the user's confirmed content changes or the payment path is adjusted, the reservation share determination unit determines the payment execution share that has formed a valid payment result and the payment execution share that has entered the execution stage that forms an external payment impact but has not yet formed a final processing result. The payment execution share that has formed a valid payment result is determined as the completed reservation share, and the payment execution share that is still in the external payment processing process is determined as the execution occupied share, and the completed reservation share and the execution occupied share are restricted from being repeatedly allocated. When the execution occupied share forms a clear failure result and does not generate an external payment result, or its external payment impact has been withdrawn, reversed or eliminated by compensation processing, the occupancy status of the corresponding payment execution share is released.The remaining share reconstruction unit determines the remaining payment execution share based on the difference between the current total payment share and the determined payment execution share, and generates an adjusted payment scheme and corresponding payment execution unit only for the remaining payment execution share. The remaining share reconstruction unit is used to generate the adjusted payment scheme. After the adjusted payment scheme is confirmed by the user, the payment execution task generation unit in the payment task orchestration and execution association module creates a corresponding payment execution task instance to form a new payment execution unit, thereby avoiding the duplicate creation of payment execution units by different program functional units.

[0057] The end-to-end tracking module is also used to associate and record user confirmation information, payment schemes, payment execution units, payment invocation processes, external business status, effective payment status, unified payment status, payment path change processes, and final processing results. It also generates the status formation basis corresponding to the unified payment status based on the payment execution evidence relationship. The end-to-end tracking module is a program function module implemented by the processor calling the end-to-end tracking program in memory. It uses the unified payment task identifier as an association index to associate and store data generated at each stage. When the unified payment status changes, a corresponding status tracking record is added, and the unified payment status before the change and its status formation basis are retained to generate an end-to-end tracking result that reflects the complete processing of the enterprise's payment task. This invention associates and records user confirmation information, payment scheme, payment execution unit, payment invocation process, external business status, effective payment status, unified payment status, payment path change process, and final processing result. Based on the payment execution evidence relationship, it generates the status formation basis corresponding to the unified payment status, enabling the current unified payment status to be traced back to the corresponding user confirmation version, payment scheme version, payment execution unit, payment invocation process, and external business receipt, thereby improving the traceability and verifiability of the unified payment status generation process.

[0058] In this embodiment, the unified state mapping and end-to-end tracking system includes a business interaction terminal, an enterprise payment intelligent agent processing device, an interface control gateway, and multiple payment processing systems corresponding to different payment methods. The business interaction terminal is a human-computer interaction hardware device for business personnel to input enterprise payment requests, confirm payment schemes, and view payment status; it can be a computer terminal, a mobile terminal, or a dedicated enterprise payment terminal. The enterprise payment intelligent agent processing device is a hardware processing device constructed from a processor, memory, communication interface, data bus, and power supply. The interface control gateway is located between the enterprise payment intelligent agent processing device and each payment processing system, used to forward payment call requests, receive external business status, and complete interface adaptation. The enterprise payment intelligent agent is a collection of executable programs deployed in the enterprise payment intelligent agent processing device. The memory stores executable programs or program instructions for implementing payment task orchestration and execution association, payment execution evidence and status determination, unified state generation and payment scheme reconstruction, and end-to-end tracking. The processor loads and executes the corresponding programs to implement the corresponding functions of the payment task orchestration and execution association module, the payment execution evidence and status determination module, the unified state generation and payment scheme reconstruction module, and the end-to-end tracking module. like Figure 5 As shown, in this embodiment, the business interaction terminal includes a display device 1 and an operation input device 3, wherein the operation input device 3 includes a keyboard and a mouse. Business personnel input enterprise payment requests, confirm or modify payment plans through the operation input device 3, and view payment methods, payment execution shares, unified payment status, and full-process tracking results through the display device 1. The enterprise payment intelligent agent processing device 2 is communicatively connected to the display device 1 and the operation input device 3, and is used to receive payment business information input by business personnel, run the enterprise payment intelligent agent program, and send the generated payment plan, unified payment status, and full-process tracking results to the display device 1 for display.

[0059] During system deployment, the enterprise payment intelligent agent program is deployed in the memory of the enterprise payment intelligent agent processing device, and a communication connection is established between the business interaction terminal and the enterprise payment intelligent agent processing device. The enterprise payment intelligent agent processing device communicates with one or more payment processing systems, including digital bill system, blockchain voucher system, digital RMB system, foreign exchange payment system, letter of credit system, and electronic guarantee system, through an interface control gateway. Based on the interface requirements of the connected payment processing systems, the corresponding interface address, communication protocol, authentication information, and status return method are configured in the interface control gateway, and the association information between each payment method and its corresponding payment processing system is stored in the enterprise payment intelligent agent processing device. After configuration, the processor loads the enterprise payment intelligent agent program, enabling each program's functional modules to run. During system operation, business personnel input payment or collection requests, or upload business materials such as contracts, invoices, bills, and payment vouchers through the business interaction terminal; the business interaction terminal sends the enterprise payment request and corresponding business data to the enterprise payment intelligent agent processing device. The enterprise payment intelligent agent generates a payment plan based on the enterprise's payment request, business materials, and pre-configured payment methods. This plan, including the payment method, payment execution share, payment execution order, payment execution conditions, and the corresponding payment processing system, is then sent to the business interaction terminal for display. Business personnel confirm, modify, or reject the payment plan through the business interaction terminal. After confirmation, the processor creates one or more payment execution task instances in memory to form corresponding payment execution units, and establishes execution associations between the enterprise payment task, user confirmation version, payment plan version, payment execution unit, and payment invocation process. The enterprise payment intelligent agent processing device sends a payment invocation request to the corresponding payment processing system through the interface control gateway and receives the external business identifier, external business status, and payment processing result returned by the payment processing system. Based on the payment execution association identifier or external business identifier, the processor associates the returned data with the corresponding enterprise payment task, payment plan version, and payment execution unit, constructing payment execution evidence relationships and determining whether each payment execution unit has entered the execution stage that creates external payment impact. The processor determines the effective payment status based on the payment execution status corresponding to the current effective payment scheme and the payment execution status of historical payment schemes that have entered the execution stage and whose corresponding external payment impact has not been withdrawn, reversed, or eliminated by compensation processing; it generates a unified payment status for the enterprise payment task based on each effective payment status and the corresponding payment execution share, and displays the corresponding payment processing status and the execution status of each payment execution unit to business personnel through the business interaction terminal.When business personnel modify user confirmation content or adjust payment paths, the enterprise payment intelligent agent processing device retains the payment execution shares that have already resulted in valid payments, as well as the payment execution shares that have entered the execution stage that will have an external payment impact but have not yet reached a final processing result. The remaining payment execution shares are determined based on the difference between the current total payment shares and the retained payment execution shares. The processor generates an adjusted payment plan only for the remaining payment execution shares, and after confirmation by the business personnel, creates a new payment execution task instance and execution association.

[0060] This invention utilizes a business interaction terminal, an enterprise payment intelligent agent processing device, an interface control gateway, and multiple payment processing systems working collaboratively. The business interaction terminal receives user payment requests, confirms payment schemes, and adjusts payment paths. The enterprise payment intelligent agent processing device completes payment task orchestration, payment execution association, valid status determination, unified payment status generation, and remaining payment share reconstruction. Through the interface control gateway, it enables payment invocation and status interaction with different payment processing systems. This allows enterprise business personnel to view the overall processing status and full-process tracking results of multiple payment methods through a unified business entry point, reducing the need to query and manually summarize payment status across multiple payment processing systems.

[0061] The content disclosed above is only a preferred and feasible embodiment of the present invention, and is not intended to limit the scope of protection of the present invention. Therefore, all equivalent technical changes made based on the content of the present invention specification and drawings are included within the scope of protection of the present invention. Furthermore, the elements therein can be updated as technology develops.

Claims

1. A unified state mapping and end-to-end tracking method for multiple payment methods in enterprises, characterized in that, The unified state mapping and end-to-end tracking method includes the following steps: S1. Obtain the enterprise payment task, and divide the enterprise payment task into one or more payment execution units according to the payment plan confirmed by the user. Each payment execution unit corresponds to a payment method and a corresponding payment execution share. S2. Call the payment processing system corresponding to each payment execution unit, and establish an execution association relationship between each payment execution unit and the corresponding payment call process and external business status; S3. Based on the user confirmation information, payment plan, payment invocation process and the external business status, construct the payment execution evidence relationship of the enterprise payment task, and determine whether each payment execution unit has entered the execution stage that forms external payment impact based on the payment execution evidence relationship; S4. Based on the payment execution status corresponding to the current effective payment scheme, and the payment execution status of historical payment schemes that have entered the execution stage but have not yet been withdrawn or compensated, determine the effective payment status that participates in the generation of the current unified payment status. S5. Generate a unified payment status for the enterprise payment task based on the payment execution share corresponding to each valid payment status; S6. When the user confirms that the content has changed or the payment path has been adjusted, the payment execution share that has formed a valid payment result and the payment execution share that has entered the execution stage are retained. The remaining payment execution share is determined based on the difference between the current total payment share and the retained payment execution share. An adjusted payment plan is generated for the remaining payment execution share. S7. Link and record the payment execution evidence relationship, the payment execution status of each payment execution unit, the unified payment status, and the payment path change process to generate the full-process tracking result of the enterprise payment task.

2. The unified state mapping and end-to-end tracking method for multiple payment methods of an enterprise according to claim 1, characterized in that, In step S1, the enterprise payment task includes at least the business type, the payer, the payee, the total payment share, and the payment direction; the payment scheme includes at least one payment method, the payment execution share corresponding to each payment method, the payment execution order, the payment execution conditions, and the corresponding payment processing system; the payment method includes at least one of digital bills, blockchain vouchers, digital RMB, foreign exchange, letters of credit, and electronic guarantees. When the payment scheme includes two or more payment methods, payment execution units are generated according to the payment execution share corresponding to each payment method. Each payment execution unit is executed in parallel or sequentially according to the payment scheme. The payment execution share is the proportion of the payment amount undertaken by the corresponding payment execution unit or the payment amount to the total payment share.

3. The unified status mapping and end-to-end tracking method for multiple payment methods of an enterprise according to claim 2, characterized in that, In step S2, establishing the execution association includes: generating a unified payment task identifier for the enterprise payment task, generating a user-confirmed version and a payment scheme version for the user-confirmed payment scheme, and generating a payment execution unit identifier for each payment execution unit; when calling the payment processing system corresponding to each payment execution unit, generating a payment execution association identifier based on the unified payment task identifier, user-confirmed version, payment scheme version, payment execution unit identifier, and payment call identifier; writing the payment execution association identifier into the corresponding payment call process, and establishing a correspondence between the external business identifier returned by the payment processing system and the payment execution association identifier; after receiving the external business status, determining the enterprise payment task, user-confirmed version, payment scheme version, and payment execution unit corresponding to the external business status based on the payment execution association identifier or the external business identifier; when the external business status cannot be associated with the corresponding payment execution unit, determining the external business status as a pending association status, and prohibiting the pending association status from directly participating in the generation of the unified payment status.

4. The unified status mapping and end-to-end tracking method for multiple payment methods of an enterprise according to claim 3, characterized in that, In step S3, the payment execution evidence relationship is represented by a payment execution evidence graph, which includes state evidence nodes and the relationships between state evidence nodes. The status evidence nodes include user confirmation nodes, payment scheme nodes, payment execution unit nodes, payment invocation nodes, external business acceptance nodes, and payment result nodes.

5. The unified state mapping and end-to-end tracking method for multiple payment methods of an enterprise according to any one of claims 3 or 4, characterized in that, In steps S3 and S4, determining whether a payment execution unit has entered the execution phase that creates external payment impact includes: determining whether the corresponding payment call has been successfully sent to the payment processing system; determining whether the payment processing system has generated the corresponding external business identifier; determining whether the payment processing system has returned the acceptance result for the payment call; and determining whether the payment share corresponding to the acceptance result matches the payment execution share of the corresponding payment execution unit.

6. The unified state mapping and end-to-end tracking method for multiple payment methods in enterprises according to claim 5, characterized in that, In steps S5 and S6, the unified payment status includes pending review, approved review, rejected, pending payment, pending receipt, in progress, in progress, partially failed, failed, successful, cancelled, and rejected.

7. A unified state mapping and end-to-end tracking system for multiple payment methods in an enterprise, which applies the unified state mapping and end-to-end tracking method for multiple payment methods in an enterprise as described in claim 6, characterized in that, The unified state mapping and end-to-end tracking system includes a payment task orchestration and execution association module, a payment execution evidence and status determination module, a unified state generation and payment scheme reconstruction module, and an end-to-end tracking module. The payment task orchestration and execution association module acquires enterprise payment tasks and, based on user-confirmed payment schemes, divides the enterprise payment tasks into one or more payment execution units. Each payment execution unit corresponds to a payment method and a corresponding payment execution share. It then calls the payment processing system corresponding to each payment execution unit and establishes an execution association relationship between each payment execution unit and its corresponding payment invocation process and external business status. The payment execution evidence and status determination module constructs the payment execution evidence relationship of the enterprise payment tasks based on user confirmation information, payment schemes, payment invocation processes, and the external business status, and determines whether each payment execution unit has entered the execution stage that forms an external payment impact based on the payment execution evidence relationship. The effective payment status is determined by identifying the payment execution status corresponding to the effective payment scheme and the payment execution status of historical payment schemes that have entered the execution stage but have not yet been withdrawn or compensated. The unified status generation and payment scheme reconstruction module generates the unified payment status of the enterprise payment task based on the payment execution share corresponding to each effective payment status. When the user's confirmed content changes or the payment path is adjusted, the payment execution shares that have already formed effective payment results and the payment execution shares that have entered the execution stage are retained. The remaining payment execution share is determined based on the difference between the current total payment share and the retained payment execution share, and an adjusted payment scheme is generated for the remaining payment execution share. The full-process tracking module associates and records the payment execution evidence relationship, the payment execution status of each payment execution unit, the unified payment status, and the payment path change process to generate the full-process tracking result of the enterprise payment task.

8. The unified status mapping and end-to-end tracking system for multiple payment methods for enterprises according to claim 7, characterized in that, The payment task orchestration and execution association module includes a payment scheme generation unit, a payment execution task generation unit, and an execution association unit. The payment scheme generation unit generates a payment scheme based on user confirmation information. The payment scheme includes at least one payment method, the payment execution share corresponding to each payment method, the payment execution order, the payment execution conditions, and the corresponding payment processing system. The payment execution task generation unit divides the enterprise payment task into one or more payment execution units according to the payment methods and corresponding payment execution shares in the payment scheme. The execution association unit generates a unified payment task identifier for the enterprise payment task, generates a user confirmation version and a payment scheme version for the payment scheme, and generates a payment execution association identifier based on the unified payment task identifier, the user confirmation version, the payment scheme version, the payment execution unit identifier, and the payment call identifier.

9. The unified status mapping and end-to-end tracking system for multiple payment methods of an enterprise according to claim 7, characterized in that, The payment execution evidence and status determination module includes a payment execution evidence construction unit, an execution stage determination unit, and a valid status filtering unit. The payment execution evidence construction unit generates status evidence nodes based on user confirmation information, payment scheme, payment execution unit, payment invocation process, external business status, and payment processing result, and establishes payment execution evidence relationships between each status evidence node. The execution stage determination unit determines whether the corresponding payment execution unit has entered the execution stage that forms an external payment impact based on whether the payment invocation has been accepted by the corresponding payment processing system, whether a corresponding external business identifier has been generated, and the payment execution share corresponding to the external business status. The valid status filtering unit determines the payment execution status corresponding to the current valid payment scheme as the current valid payment status, and retains the payment execution status of historical payment schemes that have entered the execution stage but have not yet formed a withdrawal result, reversal result or compensation result as historical valid payment status.

10. The unified status mapping and end-to-end tracking system for multiple payment methods for enterprises according to claim 9, characterized in that, The unified status generation and payment scheme reconstruction module includes an execution status determination unit, a unified status generation unit, a reserved share determination unit, and a remaining share reconstruction unit. The execution status determination unit is used to determine the pending execution status, executing status, successful execution status, failed execution status, canceled status, or rejected status of the corresponding payment execution unit based on the external business status and payment processing results corresponding to each valid payment status. The unified status generation unit is used to generate the unified payment status of the enterprise payment task based on the execution status of each payment execution unit and the corresponding payment execution share. The unified payment status includes pending review, review passed, rejected, pending payment, pending collection, in progress payment, in progress collection, partial failure, failure, success, canceled, and rejected. The reserved share determination unit determines the payment execution share that has formed a valid payment result and the payment execution share that has entered the execution stage that forms an external payment impact but has not yet formed a final processing result when the user confirmation content changes or the payment path is adjusted. The remaining share reconstruction unit determines the remaining payment execution share based on the difference between the current total payment share and the determined payment execution share, and generates an adjusted payment scheme and corresponding payment execution unit only for the remaining payment execution share.

Images