A payment order whole-process intelligent processing method, device and equipment and storage medium

Abstract

The application provides a payment order whole-process intelligent processing method and device, equipment and storage medium, determines a payment preference strategy of a current user payment order request based on a current user's on-chain credit portrait and payment channel preferences in a user preference set; calls a smart contract of a block chain according to the payment preference strategy, selects a consensus contract node in the smart contract through a risk level preference in the user preference set, executes a payment processing flow of the payment order request on a block chain network, generates process state information of each consensus contract node matched with the current user in the payment processing flow based on information disclosure granularity preference in the user preference set; and updates historical payment behavior data associated with the on-chain credit portrait based on each process state information after the payment processing flow is completed. Based on the above scheme, dynamic matching of a payment strategy based on a user portrait and preference and intelligent screening of a block chain node can be realized.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and more specifically, to a method, apparatus, device, and storage medium for intelligent processing of the entire payment order process. Background Technology

[0002] Blockchain payment is a peer-to-peer value transfer method based on distributed ledger technology. It uses cryptography to ensure the immutability of transactions and relies on decentralized node consensus to replace traditional financial intermediaries for verification and settlement. This achieves transparency, trustworthiness, and automated execution of the transaction process. Blockchain payment can build a financial infrastructure that can achieve instant global settlement without the need for third-party trust.

[0003] In traditional blockchain payment systems, allocating the same computing and network resources to all payment orders, regardless of the amount, user credit, or preferences, incurs significant computational overhead and network latency when processing small, high-frequency transactions. This results in the inefficient use of valuable on-chain resources and limited system throughput. Conversely, when processing large transactions or those with high security requirements, the fixed set of nodes and verification strength cannot provide a higher level of security commensurate with the risk, and the potential for malicious consensus nodes cannot be effectively mitigated. Essentially, the system lacks the ability to dynamically schedule resources and restructure processes based on transaction context and user needs, making it difficult to achieve an optimal balance between security, efficiency, and personalized service. Therefore, achieving dynamic matching of payment strategies based on user profiles and preferences, and intelligent selection of blockchain nodes, has become a major challenge for the industry. Summary of the Invention

[0004] This application provides a method, apparatus, device, and storage medium for intelligent processing of the entire payment order process, which can realize dynamic matching of payment strategies based on user profiles and preferences and intelligent screening of blockchain nodes, thereby improving the personalization level of the payment process.

[0005] Firstly, this application provides a method for intelligent processing of the entire payment order process, including:

[0006] In response to a user's payment order request, obtain the user's historical payment behavior data;

[0007] Extract the current user's on-chain credit profile and user preference set from the historical payment behavior data, and then perform multi-objective decision fusion on the user's payment order request based on the payment channel preference in the on-chain credit profile and the user preference set to obtain the payment preference strategy for the payment order request;

[0008] The payment preference strategy is used to invoke the blockchain's smart contract. The consensus contract node in the smart contract is selected based on the risk level preference in the user preference set. Then, the payment processing flow of the payment order request is executed on the blockchain network. Based on the information disclosure granularity preference in the user preference set, the process status information of each consensus contract node in the payment processing flow is generated to match the current user.

[0009] After the payment processing flow is completed, the historical payment behavior data associated with the on-chain credit profile is updated based on the status information of each process, and the full process hash digest of this payment is recorded on the blockchain.

[0010] In some embodiments, extracting the current user's on-chain credit profile and user preference set from the historical payment behavior data specifically includes:

[0011] Each payment behavior record in the historical payment behavior data is converted into a structured feature vector;

[0012] Extract payment credit score, transaction agility, and risk volatility index from each structured feature vector;

[0013] The on-chain credit profile of the current user is determined by all payment credit scores, transaction agility, and risk volatility indices.

[0014] The user's payment channel preference, risk level preference, and information disclosure granularity preference are obtained from the user profile of the historical payment behavior data, thereby obtaining the user's user preference set.

[0015] In some embodiments, the payment preference strategy for a user's payment order request is obtained by performing multi-objective decision fusion based on the on-chain credit profile and the payment channel preference in the user preference set, specifically including:

[0016] Obtain multiple pre-defined payment processing strategies from the blockchain;

[0017] The preference matching degree between payment order requests and various payment processing strategies is calculated based on the on-chain credit profile and the payment channel preferences in the user preference set.

[0018] The payment preference strategy for a payment order request is selected from all payment processing strategies on the blockchain by filtering out all preference matching scores.

[0019] In some embodiments, invoking a smart contract on the blockchain according to the payment preference strategy specifically includes:

[0020] The payment parameters in the payment preference strategy are encoded into a data format that can be recognized by blockchain transactions;

[0021] Using the smart contract type specified in the payment preference strategy, locate the contract address of the smart contract on the blockchain;

[0022] The blockchain's smart contract is invoked based on the contract address and the identifiable data format.

[0023] In some embodiments, selecting consensus contract nodes in the smart contract based on risk level preferences within the user preference set specifically includes:

[0024] Obtain a list of available consensus nodes in the blockchain, and then determine the node reputation score of each available consensus node in the list of available consensus nodes;

[0025] The consensus reputation threshold and the number of consensus nodes for the payment preference strategy are determined based on the risk level preferences in the user preference set.

[0026] Consensus nodes whose reputation scores meet the selection rules are selected from the list of available consensus nodes using the consensus reputation threshold and the number of consensus nodes, and these nodes are then used as consensus contract nodes in the smart contract.

[0027] In some embodiments, the payment processing flow for executing the payment order request on a blockchain network specifically includes:

[0028] The consensus contract nodes are used to verify the contract content in the payment preference strategy through node consensus.

[0029] If the node consensus verification result is valid, the payment preference strategy is packaged into an execution block and added to the blockchain network to execute the payment processing flow of the payment order request.

[0030] In some embodiments, generating process status information matching the current user with each consensus contract node in the payment processing flow based on the information disclosure granularity preference in the user preference set specifically includes:

[0031] Predefine on-chain events in the blockchain for each consensus contract node in the payment processing flow;

[0032] Based on the information disclosure granularity preferences in the user preference set, triggering conditions and push content for each on-chain event are generated;

[0033] The process status information of each consensus contract node in the payment processing flow is determined by various triggering conditions and push content, matching the current user with the current process status information.

[0034] Secondly, this application provides an intelligent processing device for the entire payment order process, including a payment decision unit, the payment decision unit comprising:

[0035] The acquisition module is used to respond to a user's payment order request and acquire the current user's historical payment behavior data.

[0036] The processing module is used to extract the current user's on-chain credit profile and user preference set from the historical payment behavior data, and then perform multi-objective decision fusion on the user's payment order request based on the payment channel preference in the on-chain credit profile and the user preference set to obtain the payment preference strategy for the payment order request;

[0037] The processing module is also used to call the blockchain's smart contract according to the payment preference strategy, select the consensus contract node in the smart contract through the risk level preference in the user preference set, and then execute the payment processing flow of the payment order request on the blockchain network. Based on the information disclosure granularity preference in the user preference set, process status information matching each consensus contract node in the payment processing flow with the current user is generated.

[0038] The execution module is used to update the historical payment behavior data associated with the on-chain credit profile based on the status information of each process after the payment processing process is completed, and record the full process hash digest of this payment on the blockchain.

[0039] Thirdly, this application provides a computer device, which includes a memory and a processor. The memory is used to store a computer program, and the processor is used to call and run the computer program from the memory, so that the computer device executes the above-described intelligent processing method for the entire payment order process.

[0040] Fourthly, this application provides a computer-readable storage medium storing instructions or code that, when executed on a computer, cause the computer to implement the aforementioned intelligent processing method for the entire payment order process.

[0041] The technical solutions provided by the embodiments disclosed in this application have the following beneficial effects:

[0042] This application provides a method, apparatus, device, and storage medium for intelligent processing of the entire payment order process. In response to a user-initiated payment order request, the system acquires the user's historical payment behavior data. From this historical payment behavior data, it extracts the user's on-chain credit profile and user preference set. Based on the payment channel preferences in the on-chain credit profile and user preference set, it performs multi-objective decision fusion on the user's payment order request to obtain a payment preference strategy. According to the payment preference strategy, it invokes a smart contract on the blockchain, selects a consensus contract node in the smart contract based on the risk level preference in the user preference set, and then executes the payment processing flow of the payment order request on the blockchain network. Based on the information disclosure granularity preference in the user preference set, it generates process status information matching the current user with each consensus contract node in the payment processing flow. After the payment processing flow is completed, it updates the historical payment behavior data associated with the on-chain credit profile based on the process status information and records the full-process hash digest of this payment on the blockchain.

[0043] Therefore, in this application, after the payment processing flow is completed, the historical payment behavior data associated with the on-chain credit profile is updated based on the status information of each process, and the full-process hash digest of this payment is recorded on the blockchain. First, by determining the payment preference strategy, a dynamic execution scheme deeply bound to the user context can be obtained, thereby deconstructing the unified blockchain payment protocol into countless dynamically combinable technical units, realizing refined governance of on-demand allocation of system resources and risk control. It can upgrade the payment engine from a static machine that executes fixed instructions to a control system with perception and decision-making capabilities, thereby generating a highly parameterized technical instruction set. This technical instruction set precisely specifies the resource scheduling strategy and security verification strength of this transaction in the blockchain network, enabling the blockchain to allocate fast channel resources for transactions with high credit and high efficiency requirements, while automatically enabling a strong verification mode for high-risk transactions. This solves the inherent trade-off between throughput, latency, and security in traditional blockchain systems from the protocol level, realizing the utilization of network resources. The system achieves precise control over optimization and risk exposure. Then, by determining the process state information, a real-time translator can be obtained that maps the on-chain technical state to the user's cognitive model. This ensures system immutability while constructing a user-oriented observable system and forming a feedback loop that drives system self-optimization. A configurable and reliable information bridge is established between the untrusted underlying technology of the blockchain and the user's subjective experience, generating a state snapshot that matches the user's cognitive level. This snapshot is refined and translated information with clear business semantics, directly enhancing the user's sense of control and trust. Furthermore, the pushed information serves as high-quality, labeled training data, continuously calibrating and optimizing the blockchain system's core decision-making model, thus forming a self-reinforcing cycle and elevating the blockchain system's personalization capabilities from simple configuration to adaptive intelligence. In summary, based on the above scheme, dynamic matching of payment strategies based on user profiles and preferences and intelligent screening of blockchain nodes can be achieved, thereby improving the personalization level of the payment process. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1 This is an exemplary flowchart of a smart processing method for the entire payment order process according to some embodiments of this application;

[0046] Figure 2This is a flowchart illustrating the determination of process status information based on some embodiments of this application;

[0047] Figure 3 This is a schematic diagram of the structure of a payment decision unit according to some embodiments of this application;

[0048] Figure 4 This is a schematic diagram of the structure of a computer device for implementing a smart processing method for the entire payment order process, according to some embodiments of this application. Detailed Implementation

[0049] To better understand the technical solution of this application, the technical solution of this application will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0050] refer to Figure 1 The figure is an exemplary flowchart of a smart processing method for the entire payment order process according to some embodiments of this application. The smart processing method for the entire payment order process mainly includes the following steps:

[0051] In step 101, in response to a payment order request initiated by the user, the user's historical payment behavior data is obtained.

[0052] It should be noted that, in this application, a payment order request refers to a standardized data instruction generated by the client when a user confirms a payment operation in an e-commerce scenario, which includes the target account for payment, the payment amount, and a timestamp; historical payment behavior data is a structured collection of all past payment transaction records associated with the current user, and the data fields of the payment transaction records include the counterparty, transaction amount, transaction frequency, transaction status (success / failure / dispute), transaction fee, and the confirmation time required for the transaction to be completed.

[0053] In practice, after the listening module captures the payment order request initiated by the user, it first parses the user's unique identifier from the payment order request. Then, using this unique identifier as the index key, it initiates a query request to the blockchain network that stores complete transaction records. This query process will traverse all on-chain and off-chain transaction logs associated with this unique identifier, extract the structured fields related to payment behavior through the data interface, and finally combine the complete dataset reflecting the user's payment habits and credit history obtained from the query into the user's historical payment behavior data.

[0054] In step 102, the on-chain credit profile and user preference set of the current user are extracted from the historical payment behavior data. Then, based on the payment channel preferences in the on-chain credit profile and the user preference set, a multi-objective decision fusion is performed on the user's payment order request to obtain the payment preference strategy for the payment order request.

[0055] In some embodiments, extracting the current user's on-chain credit profile and user preference set from the historical payment behavior data can be achieved through the following steps:

[0056] Each payment behavior record in the historical payment behavior data is converted into a structured feature vector;

[0057] Extract payment credit score, transaction agility, and risk volatility index from each structured feature vector;

[0058] The on-chain credit profile of the current user is determined by all payment credit scores, transaction agility, and risk volatility indices.

[0059] The user's payment channel preference, risk level preference, and information disclosure granularity preference are obtained from the user profile of the historical payment behavior data, thereby obtaining the user's user preference set.

[0060] It should be noted that, in this application, the on-chain credit profile is a digital identity summary that depicts a user's credit status, behavioral habits, and risk characteristics in the payment field; the structured feature vector is a numerical array with fixed length and clear semantics that describes historical payment behavior, where each dimension of the structured feature vector (i.e., each element of the array) represents a payment behavior feature; the payment reputation score is a quantitative score used to measure the reliability and integrity demonstrated by a user in historical payment activities; transaction agility is an indicator used to quantify a user's payment efficiency tendency; the risk volatility index is a statistical indicator used to assess the stability and potential risk level of a user's payment behavior; the user preference set is a set of configurations for personalized settings of the payment process; the payment channel preference is a quantitative value that clarifies a user's preference for using specific payment methods; the risk level preference is a quantitative value that quantifies a user's proactive choice of the trade-off between transaction security and processing efficiency during the payment transaction process; and the information disclosure granularity preference is a quantitative value that quantifies the level of detail of the status notification information received by the user throughout the entire payment order processing process.

[0061] In practical implementation, firstly, each payment record in the historical payment behavior data is traversed. Based on a predefined data pattern, the counterparty, transaction amount, transaction frequency, transaction status (success / failure / dispute), transaction fee, and confirmation time required for the transaction are extracted from each individual payment record. This yields multiple heterogeneous field values. Through data standardization and normalization processes, these heterogeneous field values ​​are uniformly converted into numerical forms that can be mathematically compared and calculated. These values ​​are then arranged and combined in a fixed order, ultimately converting each payment record into a regular, machine-readable structured feature vector, resulting in multiple structured feature vectors. Secondly, for each structured feature vector, a pre-defined indicator calculation model is invoked. This model executes specified algorithm logic based on the values ​​of each dimension in the structured feature vector: the payment credit score model comprehensively calculates the transaction success rate and disputed transaction rate as the payment credit score in the structured feature vector; the transaction agility model statistically analyzes the reciprocal of the transaction confirmation time as the transaction agility in the structured feature vector; and the risk wave... The dynamic index model calculates the ratio of the standard deviation to the mean of the transaction amount sequence as the risk volatility index in the structured feature vector. Through the above calculation process, the payment credit score, transaction agility, and risk volatility index in each structured feature vector can be obtained. Then, the mean of all payment credit scores is taken as the current user's payment credit score, the mean of all transaction agility is taken as the current user's transaction agility, and the mean of all risk volatility indices is taken as the current user's risk volatility index. Thus, the set of payment credit score, transaction agility, and risk volatility index is taken as the current user's on-chain credit profile. Finally, the user profile storage area associated with the current user's historical payment behavior data is accessed. By parsing the data fields in the profile, the user's explicitly specified payment channel type sorting is read as payment channel preference, the user's selected security and efficiency balance option is read as risk level preference, and the user's set notification detail level is read as information disclosure granularity preference. The set of payment channel preference, risk level preference, and information disclosure granularity preference is taken as the current user's user preference set.

[0062] In some embodiments, the payment preference strategy for a user's payment order request can be obtained by performing multi-objective decision fusion based on the on-chain credit profile and the payment channel preference in the user preference set, which can be achieved through the following steps:

[0063] Obtain multiple pre-defined payment processing strategies from the blockchain;

[0064] The preference matching degree between payment order requests and various payment processing strategies is calculated based on the on-chain credit profile and the payment channel preferences in the user preference set.

[0065] The payment preference strategy for a payment order request is selected from all payment processing strategies on the blockchain by filtering out all preference matching scores.

[0066] It should be noted that in this application, the payment preference strategy is the payment processing strategy that best matches the current user's personalized profile and immediate preferences; the payment processing strategy is a set of immutable and parameterized business rules deployed on the blockchain; and the preference matching degree is a quantitative indicator used to measure the degree of consistency between a single payment processing strategy and the current user's payment channel preferences and historical credit characteristics.

[0067] In practice, firstly, a request to retrieve a list of strategies is sent to a public read-only smart contract deployed on the blockchain. Upon receiving the request, the smart contract reads all strategy identifiers and their corresponding complete parameter sets pre-defined and stored by the system administrator from its persistent state variables, and returns this strategy data as the query result to the caller. Finally, the returned complete list of strategies is used as the payment processing strategies, resulting in multiple payment processing strategies. Then, for each payment processing strategy, the ranking value of the payment channels supported by the strategy in the user's payment channel preferences is obtained. This ranking value is normalized and used as the basis for the payment order request and payment processing. The system calculates a basic matching score between strategies; then, using preset weighting coefficients, it calculates the weighted sum of the normalized payment reputation score, transaction agility, and risk volatility index in the on-chain credit profile as the current user's credit level value. It then calculates the ratio of the risk value to the credit level value of the payment processing strategy as the fit value between the payment order request and the payment processing strategy. Finally, it calculates the average of the basic matching score and the fit value as the preference matching degree between the payment order request and the payment processing strategy. This process yields the preference matching degree between the payment order request and each payment processing strategy. Finally, it selects the payment processing strategy with the highest preference matching degree from all payment processing strategies on the blockchain as the payment preference strategy for the payment order request.

[0068] In step 103, the smart contract of the blockchain is invoked according to the payment preference strategy. The consensus contract node in the smart contract is selected through the risk level preference in the user preference set. Then, the payment processing flow of the payment order request is executed on the blockchain network. Based on the information disclosure granularity preference in the user preference set, the process status information of each consensus contract node in the payment processing flow is generated to match the current user.

[0069] In some embodiments, invoking a smart contract on the blockchain according to the payment preference strategy can be achieved through the following steps:

[0070] The payment parameters in the payment preference strategy are encoded into a data format that can be recognized by blockchain transactions;

[0071] Using the smart contract type specified in the payment preference strategy, locate the contract address of the smart contract on the blockchain;

[0072] The blockchain's smart contract is invoked based on the contract address and the identifiable data format.

[0073] It should be noted that, in this application, a smart contract on a blockchain is a collection of automatically executable code and data deployed on a designated address on the blockchain; a recognizable data format is a standardized data encoding form that can be accurately parsed and processed by network nodes and smart contracts; and a contract address is a string that uniquely identifies a deployed smart contract in the blockchain network.

[0074] In practice, the process begins by reading the payment parameters contained in the payment preference strategy. These parameters include the target payee address, the exact payment amount, the specified payment channel identifier, and the maximum allowed transaction delay time. Then, a designated encoding library is invoked to convert all payment parameters from their initial program object or text representation into byte sequences conforming to the blockchain application's binary interface specification, according to the parameter serialization rules defined by the blockchain platform. These converted byte sequences serve as the data format recognizable by the blockchain transaction. Next, based on the smart contract type explicitly specified in the payment preference strategy, the system queries its internal contract registry, which records different contract types and their associated information. The process involves mapping the deployment addresses on the blockchain; retrieving a unique string identifier bound to that type on the blockchain network through a precise search in the contract registry using the smart contract type as the index, which serves as the contract address of the smart contract to be invoked; finally, using the located contract address as the target, constructing an operation request that conforms to blockchain transaction specifications using payment parameters encoded in a recognizable data format as the call payload; digitally signing the transaction using the current user's private key to authorize the operation request; and broadcasting the signed transaction to the entire blockchain network by connecting to a blockchain node, thus completing the invocation of the smart contract on the blockchain at the specified address.

[0075] In some embodiments, selecting consensus contract nodes in the smart contract based on risk level preferences from the user preference set can be achieved through the following steps:

[0076] Obtain a list of available consensus nodes in the blockchain, and then determine the node reputation score of each available consensus node in the list of available consensus nodes;

[0077] The consensus reputation threshold and the number of consensus nodes for the payment preference strategy are determined based on the risk level preferences in the user preference set.

[0078] Consensus nodes whose reputation scores meet the selection rules are selected from the list of available consensus nodes using the consensus reputation threshold and the number of consensus nodes, and these nodes are then used as consensus contract nodes in the smart contract.

[0079] It should be noted that, in this application, the consensus contract node is the set of consensus nodes in the smart contract execution parameters for the verification and confirmation of this payment transaction; the available consensus node list is the set of all node identifiers currently permitted by the blockchain network to participate in the accounting and verification work; the node reputation score is a quantitative assessment value used to measure the reliability of available consensus nodes in the process of participating in the consensus of the blockchain network; the consensus reputation threshold is the minimum reputation score standard used to screen consensus nodes; and the number of consensus nodes is the total number of nodes that need to be selected for consensus verification in this payment transaction.

[0080] In practice, the process is as follows: First, by querying the certified node information database within the blockchain network's built-in node management contract, the set of identifiers of all nodes currently permitted by the network to participate in accounting and verification is obtained as a list of available consensus nodes. The node reputation score of each available consensus node in this list is then retrieved from the node information database. Next, the explicitly specified risk level preferences in the user preference set are read, and a predefined configuration mapping table is obtained. The minimum reputation score requirement corresponding to the risk level preference is then selected from this configuration mapping table as the consensus reputation threshold for the payment preference strategy. The minimum number of consensus nodes corresponding to this threshold is also selected from the configuration mapping table as the number of consensus nodes for the payment preference strategy. Finally, the consensus reputation threshold is used to initially filter the list of available consensus nodes, excluding all nodes with reputation scores below the threshold. Among the remaining available consensus nodes, selection rules are applied based on the efficiency or security strategy type according to the payment preference strategy. For example, for security strategies, nodes are sorted from highest to lowest reputation score; for efficiency strategies, they are randomly sorted. The set of nodes at the top of the sorted list, whose number equals the number of consensus nodes, is selected as the consensus contract nodes for this smart contract call.

[0081] In some embodiments, the payment processing flow for executing the payment order request on a blockchain network may be implemented using the following steps:

[0082] The consensus contract nodes are used to verify the contract content in the payment preference strategy through node consensus.

[0083] If the node consensus verification result is valid, the payment preference strategy is packaged into an execution block and added to the blockchain network to execute the payment processing flow of the payment order request.

[0084] It should be noted that in this application, the payment processing flow is a complete business logic sequence that automatically completes irreversible operations such as fund locking, transfer, state change, and event recording under the drive of smart contracts on the blockchain; node consensus verification is the process by which the selected consensus contract node independently performs logical verification and compliance checks on the smart contract call requests and their parameters.

[0085] In practice, the first step is to broadcast the encoded payment preference strategy and call data to all selected consensus contract nodes. Each consensus contract node independently executes the smart contract code in its local sandbox environment, verifying the validity of the payment signature, the sufficiency of the user's account balance, the legality of the transaction parameters, and whether all contract preconditions are met. Each consensus node communicates and compares its verification results (valid or invalid) and digital signatures across the entire network in multiple rounds. The verification conclusion unanimously accepted by more than a preset proportion of nodes is taken as the result of the node consensus verification. Then, once the node consensus verification result is confirmed as valid, the transaction set containing the payment preference strategy call information, the hash value of the previous block, the timestamp, and other necessary metadata are assembled into a new data block. The consensus contract node broadcasts this new data block to the entire blockchain network, accepting it into the chain ledger maintained by the consensus contract node. Finally, the successful appending of the new data block to the blockchain network serves as the trigger point, automatically executing the payment processing flow defined by the smart contract.

[0086] In some embodiments, based on the information disclosure granularity preference in the user preference set, process status information matching the current user with each consensus contract node in the payment processing flow is generated, with reference to... Figure 2 The figure is a schematic diagram of the process status information determined in some embodiments of this application. In this embodiment, the process status information can be determined by the following steps:

[0087] In step 1031, on-chain events in the blockchain are predefined for each consensus contract node in the payment processing flow;

[0088] In step 1032, triggering conditions and push content for each on-chain event are generated based on the information disclosure granularity preference in the user preference set;

[0089] In step 1033, the process status information of each consensus contract node in the payment processing flow that matches the current user is determined by various triggering conditions and push content.

[0090] It should be noted that, in this application, the process status information is a personalized notification message about the stage and specific situation of the payment order during processing. This process status information is the final product of on-chain event data after being filtered by user preferences and formatted for content. On-chain events are logs actively triggered on the blockchain by the smart contract when it executes to a specified logical node and meets set conditions. The triggering conditions are the judgment rules that control the generation of status notification messages for each on-chain event. The pushed content is a text template of a status notification message about the specific details of the on-chain event.

[0091] In practical implementation, firstly, when deploying the smart contract for processing payment orders, developers insert trigger statements for various event types after each business logic node in the contract code. These business logic nodes include the start of consensus verification, the number of participating nodes reaching a specified percentage (20%, 50%, 70%), successful consensus achievement, and changes in fund status. Each event type is assigned a unique name and a series of data parameters to be recorded in the contract. The status markers explicitly defined in the contract code to identify key stages of the business process are predefined as on-chain events that need to be triggered by each consensus contract node in the payment processing flow. Then, the information disclosure granularity preference from the user preference set is read. For each on-chain event, its notification rules are configured according to the specific level of that information disclosure granularity preference: for concise granularity (i.e., information disclosure granularity preference of 1-3), only events that ultimately succeed or fail are set as triggers, and a concise result content template is configured; for standard granularity (i.e., information disclosure granularity preference of 4-6), major milestone events are set as triggers, and a summary progress content template is configured. For detailed granularity (i.e., information disclosure granularity preference of 7-9), all events are set as triggers, and detailed content templates containing technical details are configured. Finally, the activation rules and message templates configured for on-chain events according to the information disclosure granularity preference are used as the trigger conditions for on-chain events, and the card message template is used as the push content for on-chain events. The trigger conditions and push content for each on-chain event can be obtained in the above way. Finally, on-chain events triggered by consensus contract nodes on the blockchain are monitored in real time. Whenever an event is monitored, it is compared with the trigger conditions generated by the event. If the event meets the trigger conditions, the original on-chain data carried by the event is read, and the original data is filled into the corresponding position in the template according to the push content template pre-generated for the event. A user-readable text message is formatted and generated. Finally, the formatted text message that conforms to the user's information disclosure granularity preference is used as the process status information that needs to be pushed to the user and matches the current user. Thus, the process status information of each consensus contract node in the payment processing process that matches the current user can be obtained.

[0092] In step 104, after the payment processing flow is completed, the historical payment behavior data associated with the on-chain credit profile is updated based on the status information of each process, and the full process hash digest of this payment is recorded on the blockchain.

[0093] It should be noted that in this application, the full-process hash digest is a digital fingerprint that can uniquely and completely represent the entire payment process. In specific implementation, after the payment processing process is detected to be completed, the result data of the payment processing process is first extracted from all process status information generated by this payment. This result data includes, but is not limited to, the actual total time spent on this payment, the final payment status, the transaction fees generated, and the number of nodes participating in the consensus. Subsequently, this result data is compared and fused with the corresponding historical payment behavior data fields in the user's on-chain credit profile. For example, the actual time spent on this payment is used to update the calculation benchmark of transaction agility, and the successful result of the payment is used to update the calculation factor of payment reputation score. Finally, the fused data set is updated to the latest historical payment behavior data associated with the on-chain credit profile for future decision-making. At the same time, the hashes of all key blocks in this payment process and the hashes of the event logs are processed by Merkle tree to calculate the root hash value. This root hash value is permanently recorded on the blockchain through a write transaction as the full-process hash digest of this payment.

[0094] Furthermore, in another aspect of this application, in some embodiments, this application provides an intelligent processing device for the entire payment order process, which includes a payment decision unit, with reference to... Figure 3 The figure is a schematic diagram of the structure of a payment decision unit according to some embodiments of this application. The payment decision unit includes: an acquisition module 201, a processing module 202, and an execution module 203, which are described below:

[0095] The acquisition module 201 in this application is mainly used to respond to the payment order request initiated by the user and acquire the current user's historical payment behavior data.

[0096] Processing module 202, in this application, is used to extract the current user's on-chain credit profile and user preference set from the historical payment behavior data, and then perform multi-objective decision fusion on the user's payment order request based on the payment channel preference in the on-chain credit profile and the user preference set to obtain the payment preference strategy for the payment order request;

[0097] It should be noted that the processing module 202 is also used to call the smart contract of the blockchain according to the payment preference strategy, select the consensus contract node in the smart contract through the risk level preference in the user preference set, and then execute the payment processing flow of the payment order request on the blockchain network. Based on the information disclosure granularity preference in the user preference set, process status information matching each consensus contract node in the payment processing flow with the current user is generated.

[0098] The execution module 203 in this application is mainly used to update the historical payment behavior data associated with the on-chain credit profile based on the status information of each process after the payment processing process is completed, and record the full process hash digest of this payment on the blockchain.

[0099] The foregoing has detailed examples of the intelligent processing method, apparatus, device, and storage medium for the entire payment order process provided in the embodiments of this application. It is understood that, in order to achieve the above functions, the corresponding apparatus includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0100] In some embodiments, this application also provides a computer device, the computer device including a memory and a processor, the memory for storing a computer program, and the processor for calling and running the computer program from the memory, so that the computer device executes the above-described intelligent processing method for the entire payment order process.

[0101] In some embodiments, reference Figure 4 The dashed lines in the figure indicate that the unit or module is optional. This figure is a structural schematic diagram of a computer device for implementing a fully intelligent payment order processing method according to an embodiment of this application. The fully intelligent payment order processing method described in the above embodiments can... Figure 4 The computer device shown is used to implement this, and the computer device includes at least one processor 301, a memory 302 and at least one communication unit 305. The computer device may be a terminal device, a server or a chip.

[0102] Processor 301 can be a general-purpose processor or a special-purpose processor. For example, processor 301 can be a central processing unit (CPU), which can be used to control computer devices, execute software programs, and process data from software programs. The computer device may also include a communication unit 305 for inputting (receiving) and outputting (transmitting) signals.

[0103] For example, the computer device may be a chip, and the communication unit 305 may be the input and / or output circuit of the chip, or the communication unit 305 may be the communication interface of the chip, which may be a component of a terminal device, network device or other device.

[0104] For example, the computer device may be a terminal device or a server, and the communication unit 305 may be a transceiver of the terminal device or the server, or the communication unit 305 may be a transceiver circuit of the terminal device or the server.

[0105] The computer device may include one or more memories 302 storing a program 304. The program 304 can be executed by a processor 301 to generate instructions 303, causing the processor 301 to execute the method described in the above method embodiments according to the instructions 303. Optionally, the memory 302 may also store data (such as a target audit model). Optionally, the processor 301 may also read data stored in the memory 302, which may be stored at the same storage address as the program 304, or it may be stored at a different storage address than the program 304.

[0106] The processor 301 and memory 302 can be configured separately or integrated together, for example, integrated on the system on chip (SOC) of the terminal device.

[0107] It should be understood that each step of the above method embodiment can be completed by hardware logic circuits or software instructions in the processor 301. The processor 301 can be a CPU, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, such as discrete gate, transistor logic devices, or discrete hardware components.

[0108] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0109] For example, in some embodiments, this application also provides a computer-readable storage medium storing instructions or code that, when executed on a computer, cause the computer to implement the above-described intelligent processing method for the entire payment order process.

[0110] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0111] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for intelligent processing of the entire payment order process, characterized in that, Includes the following steps: In response to a user's payment order request, obtain the user's historical payment behavior data; Extract the current user's on-chain credit profile and user preference set from the historical payment behavior data, and then perform multi-objective decision fusion on the user's payment order request based on the payment channel preference in the on-chain credit profile and the user preference set to obtain the payment preference strategy for the payment order request; The payment preference strategy calls the blockchain's smart contract, selects a consensus contract node in the smart contract based on the risk level preference in the user preference set, and then executes the payment processing flow of the payment order request on the blockchain network. Based on the information disclosure granularity preference in the user preference set, process status information matching the current user with each consensus contract node in the payment processing flow is generated. The information disclosure granularity preference is a quantitative value of the level of detail of the status notification information received by the user throughout the entire payment order processing flow. After the payment processing flow is completed, the historical payment behavior data associated with the on-chain credit profile is updated based on the status information of each process, and the full process hash digest of this payment is recorded on the blockchain. Specifically, the process status information generated based on the information disclosure granularity preference in the user preference set, matching each consensus contract node in the payment processing flow with the current user, includes: Predefine on-chain events in the blockchain for each consensus contract node in the payment processing flow; Based on the information disclosure granularity preferences in the user preference set, triggering conditions and push content for each on-chain event are generated; The process status information of each consensus contract node in the payment processing flow is determined by various triggering conditions and push content, matching the current user with the current process status information.

2. The method as described in claim 1, characterized in that, Extracting the current user's on-chain credit profile and user preference set from the historical payment behavior data specifically includes: Each payment behavior record in the historical payment behavior data is converted into a structured feature vector; Extract payment credit score, transaction agility, and risk volatility index from each structured feature vector; The on-chain credit profile of the current user is determined by all payment credit scores, transaction agility, and risk volatility indices. The user's payment channel preference, risk level preference, and information disclosure granularity preference are obtained from the user profile of the historical payment behavior data, thereby obtaining the user's user preference set.

3. The method as described in claim 1, characterized in that, Based on the on-chain credit profile and the payment channel preferences in the user preference set, a multi-objective decision fusion is performed on the user's payment order request to obtain the payment preference strategy for the payment order request, which specifically includes: Obtain multiple pre-defined payment processing strategies from the blockchain; The preference matching degree between payment order requests and various payment processing strategies is calculated based on the on-chain credit profile and the payment channel preferences in the user preference set. The payment preference strategy for a payment order request is selected from all payment processing strategies on the blockchain by filtering out all preference matching scores.

4. The method as described in claim 1, characterized in that, Invoking the blockchain's smart contract according to the aforementioned payment preference strategy specifically includes: The payment parameters in the payment preference strategy are encoded into a data format that can be recognized by blockchain transactions; Using the smart contract type specified in the payment preference strategy, locate the contract address of the smart contract on the blockchain; The blockchain's smart contract is invoked based on the contract address and the identifiable data format.

5. The method as described in claim 1, characterized in that, The selection of consensus contract nodes in the smart contract based on risk level preferences from the user preference set specifically includes: Obtain a list of available consensus nodes in the blockchain, and then determine the node reputation score of each available consensus node in the list of available consensus nodes; The consensus reputation threshold and the number of consensus nodes for the payment preference strategy are determined based on the risk level preferences in the user preference set. Consensus nodes whose reputation scores meet the selection rules are selected from the list of available consensus nodes using the consensus reputation threshold and the number of consensus nodes, and these nodes are then used as consensus contract nodes in the smart contract.

6. The method as described in claim 1, characterized in that, The payment processing flow for executing the payment order request on the blockchain network specifically includes: The consensus contract nodes are used to verify the contract content in the payment preference strategy through node consensus. If the node consensus verification result is valid, the payment preference strategy is packaged into an execution block and added to the blockchain network to execute the payment processing flow of the payment order request.

7. A payment order end-to-end intelligent processing device, used to execute a payment order end-to-end intelligent processing method as described in any one of claims 1 to 6, the payment order end-to-end intelligent processing device comprising a payment decision unit, characterized in that, The payment decision unit includes: The acquisition module is used to respond to a user's payment order request and acquire the current user's historical payment behavior data. The processing module is used to extract the current user's on-chain credit profile and user preference set from the historical payment behavior data, and then perform multi-objective decision fusion on the user's payment order request based on the payment channel preference in the on-chain credit profile and the user preference set to obtain the payment preference strategy for the payment order request; The processing module is also used to call the blockchain's smart contract according to the payment preference strategy, select the consensus contract node in the smart contract through the risk level preference in the user preference set, and then execute the payment processing flow of the payment order request on the blockchain network. Based on the information disclosure granularity preference in the user preference set, process status information matching each consensus contract node in the payment processing flow with the current user is generated. The execution module is used to update the historical payment behavior data associated with the on-chain credit profile based on the status information of each process after the payment processing process is completed, and record the full process hash digest of this payment on the blockchain.

8. A computer device, characterized in that, The computer device includes a memory and a processor. The memory is used to store computer programs, and the processor is used to call and run the computer programs from the memory, so that the computer device executes the intelligent processing method for the entire payment order process as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions or code that, when executed on a computer, cause the computer to implement the intelligent processing method for the entire payment order process as described in any one of claims 1 to 6.

Images