A real-time payment transaction routing decision method and system based on an electronic wallet

Abstract

The application provides a real-time payment transaction routing decision method and system based on an electronic wallet, relates to the technical field of data processing, and comprises the following steps: calculating the vertical distance from each evaluation point to the straight line of the strategy boundary corresponding to the benchmark routing strategy based on the comparison and analysis of the dynamic optimization trajectory and the benchmark routing strategy, obtaining the distance evaluation parameter, and obtaining the routing correction parameter based on the distance evaluation parameter; calculating the multi-dimensional transaction feature set and the preset routing rule set, combining the routing correction parameter, and generating an adaptive payment path instruction; performing a payment operation according to the adaptive payment path instruction, performing the verification and cancellation operation of the receivables and payables after the payment is successful, generating processing state information, feeding back the processing state information to the user end, and saving the execution process and result as an operation record. The application improves the transaction success rate and processing efficiency.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method and system for real-time payment transaction routing decision based on an electronic wallet. Background Technology

[0002] In the e-wallet payment system of logistics platforms, for the high-frequency scenario of bulk payment of freight to a large number of drivers, existing technologies often use preset fixed payment paths to handle fund transfers. For example, most payments are deducted from the platform's main wallet balance or the entire batch of funds is transferred through a single bank's direct payment channel. These fixed routing schemes are mostly difficult to dynamically adjust according to the specific context of each bulk logistics payment. For example, when the platform's main wallet balance is sufficient and most drivers have activated their platform e-wallets, the platform could prioritize direct transfer from the internal account to the drivers' e-wallets at zero cost. However, the platform may still use the bank's direct payment channel, which has a certain fee. Or, in the case of bulk settlement of large-volume quarterly settlement business, due to the concentrated and large scale of a single settlement amount, a commonly used bank's direct payment channel may trigger a daily limit. Due to the lack of a suitable alternative path, the quarterly freight payments of some drivers may be delayed.

[0003] The core problem with existing technologies is that when logistics platforms make bulk payments for freight, the routing mechanism cannot perceive the transaction characteristics of the logistics scenario in real time (such as the real-time balance of the platform's main wallet, the bank channel limit in the case of large-volume quarterly settlement, the driver's e-wallet account opening status, etc.) and adjust the payment path accordingly. This may result in higher payment costs for logistics platforms in this scenario, and the stability of the success rate of bulk freight payments is also difficult to guarantee. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide a method and system for real-time payment transaction routing decision based on electronic wallets, which improves transaction success rate and processing efficiency.

[0005] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0006] Firstly, a real-time payment transaction routing decision method based on an e-wallet, the method comprising:

[0007] Step 1: Receive the user's payment transaction request and obtain the request data;

[0008] Step 2: Parse and process the request data to generate a multi-dimensional transaction feature set containing the payer's identity, transaction type, and transaction amount;

[0009] Step 3: Construct a routing evaluation index set based on a multi-dimensional transaction feature set, determine the benchmark routing strategy based on the routing evaluation index set, and generate the corresponding strategy angle interval based on the strategy direction vector.

[0010] Step 4: Set the first evaluation point within the strategy angle interval and the second evaluation point outside the strategy angle interval. Generate a dynamic optimization trajectory based on the time sequence of the two evaluation points in the historical execution process.

[0011] Step 5: Based on the comparative analysis of the dynamic optimization trajectory and the baseline routing strategy, calculate the vertical distance from each evaluation point to the corresponding policy boundary line of the baseline routing strategy to obtain the distance evaluation parameters. Based on the distance evaluation parameters, obtain the routing correction parameters. Calculate the multi-dimensional transaction feature set and the preset routing rule set, and combine them with the routing correction parameters to generate an adapted payment path instruction.

[0012] Step 6: Execute the payment operation according to the adapted payment path instruction. After successful payment, perform the reconciliation operation of accounts receivable and payable, generate processing status information, feed back the processing status information to the user terminal, and save the execution process and results as an operation record.

[0013] Secondly, a real-time payment transaction routing decision system based on an e-wallet includes:

[0014] The receiving module is used to receive payment transaction requests from the user and obtain the request data;

[0015] The processing module is used to parse and process the request data to generate a multi-dimensional transaction feature set containing the payer's identity, transaction type, and transaction amount;

[0016] The module is used to construct a set of routing evaluation indicators based on a multi-dimensional set of transaction features, determine the baseline routing strategy based on the set of routing evaluation indicators, and generate the corresponding strategy angle interval based on the strategy direction vector.

[0017] The optimization module is used to set a first evaluation point within the policy angle interval and a second evaluation point outside the policy angle interval, and to generate a dynamic optimization trajectory based on the time sequence of the two evaluation points in the historical execution process.

[0018] The calculation module is used to calculate the vertical distance from each evaluation point to the corresponding policy boundary line of the benchmark routing strategy based on the comparative analysis of the dynamically optimized trajectory and the benchmark routing strategy, to obtain the distance evaluation parameters, and to obtain the routing correction parameters based on the distance evaluation parameters; it calculates the multi-dimensional transaction feature set and the preset routing rule set, and combines the routing correction parameters to generate the adapted payment path instruction;

[0019] The feedback module is used to execute payment operations according to the adapted payment path instructions. After successful payment, it performs the reconciliation operation of accounts receivable and payable, generates processing status information, feeds back the processing status information to the user end, and saves the execution process and results as an operation record.

[0020] Thirdly, a computing device, comprising:

[0021] One or more processors;

[0022] A storage device for storing one or more programs that, when executed by one or more processors, cause the one or more processors to implement the method.

[0023] Fourthly, a computer-readable storage medium storing a program that, when executed by a processor, implements the method.

[0024] The above-described solution of the present invention has at least the following beneficial effects:

[0025] By combining pre-set routing rules with dynamically generated routing correction parameters, the system can output adapted paths for different transaction types such as consumption and transfer, reducing issues such as payment timeouts and channel rejections caused by path mismatches. Based on historical execution data, the system generates dynamically optimized trajectories that can respond in real time to external changes such as channel status, temporary rate limits, and fee fluctuations, automatically adjusting the most suitable path without frequent manual intervention. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of a real-time payment transaction routing decision method based on an electronic wallet, provided by an embodiment of the present invention.

[0027] Figure 2 This is a schematic diagram of a real-time payment transaction routing decision system based on an electronic wallet, provided by an embodiment of the present invention. Detailed Implementation

[0028] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0029] like Figure 1 As shown, an embodiment of the present invention proposes a real-time payment transaction routing decision method based on an electronic wallet, the method comprising the following steps:

[0030] Step 1: Receive the user's payment transaction request and obtain the request data;

[0031] Step 2: Parse and process the request data to generate a multi-dimensional transaction feature set containing the payer's identity, transaction type, and transaction amount;

[0032] Step 3: Construct a routing evaluation index set based on a multi-dimensional transaction feature set, determine the benchmark routing strategy based on the routing evaluation index set, and generate the corresponding strategy angle interval based on the strategy direction vector.

[0033] Step 4: Set the first evaluation point within the strategy angle interval and the second evaluation point outside the strategy angle interval. Generate a dynamic optimization trajectory based on the time sequence of the two evaluation points in the historical execution process.

[0034] Step 5: Based on the comparative analysis of the dynamic optimization trajectory and the baseline routing strategy, calculate the vertical distance from each evaluation point to the corresponding policy boundary line of the baseline routing strategy to obtain the distance evaluation parameters. Based on the distance evaluation parameters, obtain the routing correction parameters. Calculate the multi-dimensional transaction feature set and the preset routing rule set, and combine them with the routing correction parameters to generate an adapted payment path instruction.

[0035] Step 6: Execute the payment operation according to the adapted payment path instruction. After successful payment, perform the reconciliation operation of accounts receivable and payable, generate processing status information, feed back the processing status information to the user terminal, and save the execution process and results as an operation record.

[0036] In this embodiment of the invention, by combining preset routing rules with dynamically generated routing correction parameters, the output path can be adapted for different transaction types such as consumption and transfer, reducing problems such as payment timeout and channel rejection caused by path mismatch; the dynamic optimization trajectory generated based on historical execution data can respond in real time to external changes such as channel status such as temporary flow restriction of a certain channel and rate fluctuations, and automatically adjust the most suitable path without frequent manual intervention.

[0037] In a preferred embodiment of the present invention, step 1, receiving a payment transaction request from the user and obtaining request data, may include:

[0038] Step 101: Obtain the payer identification information, transaction amount data, and business type identifier from the received payment transaction request. Specifically, this includes: reading the payment transaction request message sent by the user terminal through the payment request parsing interface; extracting the payer identification information from the header field of the message, which may be a unique code generated by the payer during registration or a bound enterprise identity identifier or personal identity identifier; extracting the transaction amount data from the transaction details field of the message, which is the specific amount of funds involved in this payment, such as 500,000 yuan; and extracting the business type identifier from the business attribute field of the message, which is a pre-set character code used to distinguish different business scenarios. In the scenario of batch payment of freight on a logistics platform, this identifier may be associated with the specific waybill batch number or settlement cycle information.

[0039] Step 102: Determine the payer's identity category based on the payer's identifier information; perform a compliance check on the transaction amount data based on the identity category to obtain a confirmed valid transaction amount. Specifically, this includes: comparing the extracted payer identifier information with a pre-stored identity identifier database, and determining the payer's identity category based on the matching result. Identity categories include logistics platform entities, enterprise-level partners, individual drivers, etc.; for different identity categories, corresponding upper and lower limits for single transaction amounts are pre-set. For example, the upper limit for a single payment for a logistics platform entity is 10 million yuan, and the upper limit for a single payment for an individual driver as a payer is 500,000 yuan. The lower limit for a single payment for all identity categories is 1 yuan; compare the extracted transaction amount data with the upper and lower limits of the amount for the payer's identity category. If the transaction amount data is within the upper and lower limits, the transaction amount data is directly determined as a confirmed valid transaction amount; if the transaction amount data exceeds the upper limit, a notification of exceeding the limit is returned to the user and a request is made to resubmit a transaction amount that meets the upper limit; if the transaction amount data is lower than the lower limit, a notification is also returned and a request is made to supplement the transaction amount to above the lower limit until a confirmed valid transaction amount that meets the compliance requirements is obtained.

[0040] Step 103: Determine the corresponding standard business type based on the identity category and business type identifier. Combine the identity category, confirmed valid transaction amount, and standard business type to obtain the requested data, specifically including: a business type mapping table, which is a pre-set lookup table containing three core fields: identity category field, business type identifier field, and standard business type name field. The identity category field specifically stores identity information such as the logistics platform entity, enterprise-level partners, and individual drivers. The business type identifier field stores predefined character codes, each code corresponding to a specific business scenario. For example, code WLPY001 specifically corresponds to the batch freight payment scenario, and code QYJJ002 specifically corresponds to the inter-enterprise quarterly settlement scenario. The standard business type name field stores the standardized business name that matches the first two fields. When querying the standard business type, first determine the identity category of the current payment transaction, then extract the business type identifier. In the business type mapping table, first filter out all records whose identity category field is completely consistent with the current identity category, and then find the record whose business type identifier field completely matches the extracted business type identifier. The content of the standard business type name field of this record is the standard business type corresponding to the current transaction.

[0041] For example, if the current identity category is a logistics platform entity and the business type identifier is WLPY001, the standard business type obtained after the query is bulk payment of freight charges by the logistics platform; if the current identity category is an enterprise-level partner and the business type identifier is QYJJ002, the standard business type obtained after the query is quarterly settlement payment between enterprises. After obtaining the standard business type, the information is integrated according to a fixed structure, using a key-value pair structured format. The first key is the payer's identity category, and the corresponding value is the identity category determined in step 102; the second key is the valid transaction amount, and the corresponding value is the confirmed valid transaction amount obtained in step 102; the third key is the standard business type, and the corresponding value is the standard business type obtained in this query. Arranging and combining these three key-value pairs in the above order forms the complete structured data, which is the request data.

[0042] This embodiment provides accurate basic data for subsequent identity verification, business classification, and amount processing by precisely extracting key information from payment transaction requests.

[0043] In a preferred embodiment of the present invention, step 2, parsing the request data to generate a multi-dimensional transaction feature set including the payer's identity, transaction type, and transaction amount, may include:

[0044] Step 201: Standardize the identity categories in the request data to obtain standardized payer identities. Based on the standardized payer identities, perform classification analysis using preset classification rules to obtain type classifications. Specifically, the identity categories in the request data may have different expressions, such as a logistics platform entity being described as "platform provider" or "logistics main account." Standardization involves converting these different expressions into pre-defined standardized names, such as uniformly converting them to "logistics platform entity," thus forming standardized payer identities. The preset classification rules are set according to business needs. For example, for logistics platform entities, they are classified into large, medium, and small logistics platforms based on the platform's average daily transaction volume. Platforms with an average daily transaction volume of over 50 million yuan are classified as large, those between 10 million and 50 million yuan as medium, and those below 10 million yuan as small. For enterprise-level partners, they are classified into transportation companies, warehousing companies, and distribution companies based on their industry. The standardized payer identities are compared with the conditions in the classification rules, and those that meet the conditions are assigned to the corresponding category, thus obtaining type classifications.

[0045] Step 202: Based on the type classification and confirmed valid transaction amount, process to obtain the corresponding transaction amount level; based on the type classification and standard business type, obtain the corresponding transaction type features through feature mapping, specifically including: pre-setting a division table of transaction amount levels for different type classifications, the table clearly defines the correspondence between type classification and range, for example, the range for large logistics platforms is small (below 1 million yuan), medium (1 million to 5 million yuan), and large (above 5 million yuan); the range for medium-sized logistics platforms is small (below 500,000 yuan), medium (500,000 to 3 million yuan), and large (above 3 million yuan); the range for small logistics platforms is small (below 200,000 yuan), medium (200,000 to 1 million yuan), and large (above 1 million yuan); compare the confirmed valid transaction amount with the range corresponding to the type classification, and determine the corresponding transaction amount level based on which range it falls into, for example, if the type classification is medium-sized logistics platform and the valid amount is 800,000 yuan, it is determined to be medium. Simultaneously, a transaction type feature mapping rule table is configured, which contains three columns: type classification, standard business type, and transaction type feature. For example, the type classification of large logistics platforms and the standard business type of logistics platforms correspond to high-frequency batch freight settlements of large platforms, while the type classification of warehousing enterprises and the standard business type of enterprises correspond to periodic large-amount settlements of warehousing enterprises. Based on the current type classification and standard business type, the corresponding transaction type feature can be obtained by querying this table.

[0046] Step 203 integrates the type classification, transaction type characteristics, and transaction amount level to generate a multi-dimensional transaction feature set. Specifically, this includes: first, summarizing three key information items. The type classification is the result of identity standardization and categorization obtained in step 201, specifically one of the following: large logistics platform, medium-sized logistics platform, small logistics platform, transportation company, warehousing company, or delivery company. The transaction type characteristics are descriptions obtained in step 202 through mapping the type classification to standard business types. For example, a large logistics platform corresponds to high-frequency bulk freight settlement when matching bulk freight payments between logistics platforms; a warehousing company corresponds to periodic large-amount settlements when matching quarterly settlement payments between enterprises. The transaction amount level is determined in step 202 through the type classification... When comparing the category with the valid amount to obtain one of the following categories—small, medium, or large—it is necessary to ensure that all three information items are completely extracted without omission during the aggregation process. The description of each information item must be verified to conform to the preset specifications. The standardized description for category classification is fixed to the six specific category names mentioned above, and non-standard descriptions such as "large logistics platform" or "warehousing company" are not allowed. The standardized description of transaction type characteristics must include the core information of the category classification and the characteristics of the business scenario, such as sporadic freight payments by small logistics platforms or monthly settlement payments by transportation companies, avoiding simplified descriptions such as "small platform pays freight" or "transportation company settles monthly." The standardized description for transaction amount levels is only "small," "medium," or "large," and vague descriptions such as "small amount" or "large amount" are not allowed. If there are any discrepancies in the description, the corresponding previous steps must be returned for correction.

[0047] Data is organized in a structured list format according to a fixed order of type classification, transaction type characteristics, and transaction amount level. Each element in the list must clearly indicate its attributes. For example, the first element should indicate the type classification and be filled with a specific category (e.g., large logistics platform); the second element should indicate the transaction type characteristics and be filled with a specific description (e.g., high-frequency bulk freight settlement on a large platform); and the third element should indicate the transaction amount level and be filled with a specific level (e.g., medium amount). This forms a uniformly formatted structured data. The structured data undergoes a contradiction check based on preset matching rules between type classification and amount level: large logistics platforms and medium logistics platforms can correspond to small, medium, and large amounts; small logistics platforms can only correspond to small and medium amounts; transportation companies and delivery companies can correspond to small and medium amounts; and warehousing companies can correspond to medium and large amounts. If the structured data is classified as a small logistics platform and the transaction amount is large, or classified as a delivery company and the transaction amount is large, then a contradiction is found, and it is necessary to return to step 202 to re-verify the matching relationship between the valid amount and the type classification; if the data meets the matching rules and there are no other contradictions, the structured data is a multi-dimensional transaction feature set.

[0048] This embodiment, by classifying transaction amount levels and mapping transaction type characteristics, transforms transaction amounts and business attributes into features that are easier to use for decision-making, thereby enhancing the accurate description of transaction characteristics.

[0049] In a preferred embodiment of the present invention, step 3, constructing a routing evaluation index set based on a multi-dimensional transaction feature set, determining a baseline routing strategy based on the routing evaluation index set, and generating a corresponding strategy angle interval based on the strategy direction vector, may include:

[0050] Step 301: Extract payer identity features, transaction type features, and transaction amount level features from the multi-dimensional transaction feature set; based on the payer identity features, transaction type features, and transaction amount level features, generate a routing evaluation indicator set, specifically including: the multi-dimensional transaction feature set is a structured list, the first element of the list is the type classification, the second is the transaction type feature, and the third is the transaction amount level; during extraction, directly obtain the first element of the list as the payer identity feature, obtain the second element of the list as the transaction type feature, which is the specific business description obtained in step 202 through mapping the type classification with the standard business type, and obtain the third element of the list as the transaction amount level feature, which is the small, medium, or large amount determined in step 202 through comparison of the type classification with the effective amount. These three features together constitute the basis for indicator conversion.

[0051] The system converts indicators based on the payer's identity characteristics, according to preset rules. For example, if the characteristic is a large logistics platform (daily transaction volume exceeding 50 million RMB), the credit rating is converted to high, and the platform's payment records for the past 90 days are checked; if there are zero payment failures, a stable payment capability indicator is generated. If the characteristic is a medium-sized logistics platform (daily transaction volume between 10 million and 50 million RMB), the credit rating is converted to medium, and if there are fewer than three payment failures in the past 90 days, a stable payment capability indicator is generated. If the characteristic is a small logistics platform (daily transaction volume below 10 million RMB), the credit rating is converted to low-medium, and if there are fewer than five payment failures in the past 90 days, a stable payment capability indicator is generated. If the characteristic is a transportation or delivery company, the credit rating is converted to medium, and if there are fewer than four payment failures in the past 90 days, a stable payment capability indicator is generated. If the characteristic is a warehousing company, the credit rating is converted to high-medium, and if there are fewer than two payment failures in the past 90 days, a stable payment capability indicator is generated.

[0052] The metrics are converted based on the characteristics of the transaction type, according to preset business demand rules: If the characteristic is high-frequency batch freight settlement on a large platform, the number of sub-transactions per transaction is more than 50. Due to the need to quickly complete multiple fund transfers, the metrics are converted to high-efficiency processing requirements, while drivers require payment within 24 hours, resulting in low-latency requirements. If the characteristic is sporadic freight payments on a small logistics platform, the number of sub-transactions per transaction is less than 10. Due to the small number of transactions, there is no need for centralized and rapid processing, resulting in flexible channel requirements, where drivers are more tolerant of payment times. If the tolerance level is high, funds can arrive within 48 hours, and a regular arrival requirement indicator is simultaneously converted; if the characteristic is that of a warehousing company with periodic large-amount settlements, these transactions are settled at a fixed time each month. Due to the need to ensure the safe transfer of large sums of money, a high-security channel requirement indicator is converted, and because the settlement time is fixed, a timed arrival requirement indicator is simultaneously converted; if the characteristic is that of a transportation company with monthly freight payments, the number of sub-transactions per transaction is between 10 and 30. Due to the moderate number of transactions, a regular processing requirement indicator is converted, and because it needs to meet the company's reconciliation cycle, a fixed-time arrival requirement indicator is simultaneously converted.

[0053] The indicators are converted based on the characteristics of transaction amount levels, according to preset rules corresponding to transaction capacity: If the characteristic is "large amount," for large logistics platforms, "large amount" means over 5 million yuan; for medium-sized logistics platforms, it means over 3 million yuan; and for small logistics platforms, it means over 1 million yuan. Due to the large capital scale, the single-transaction capacity of the channel needs to be no less than 1 million yuan, resulting in a high channel capacity indicator. At the same time, every 0.1% difference in the rate will generate a cost of over 5,000 yuan, resulting in a high cost sensitivity indicator. If the characteristic is "medium amount," the medium amount for large logistics platforms is 1 million to 5 million yuan, and for medium-sized logistics platforms, it is 500,000 to 300,000 yuan. For small logistics platforms, the mid-range is 200,000 to 1,000,000 yuan, requiring a single-transaction capacity of at least 500,000 yuan. This translates to a medium-capacity channel indicator. A 0.1% difference in rates will result in a cost of 1,000 to 5,000 yuan, which translates to a medium-cost sensitivity indicator. For small-scale logistics platforms, the small-scale is below 1,000,000 yuan; for medium-scale, it is below 500,000 yuan; and for small-scale, it is below 200,000 yuan. This requires a single-transaction capacity of at least 100,000 yuan, which translates to a low-capacity channel indicator. A 0.1% difference in rates will result in a cost of less than 1,000 yuan, which translates to a low-cost sensitivity indicator.

[0054] The identity-related indicators, business-related indicators, and amount-related indicators obtained from the above transformations are summarized. Identity-related indicators include credit rating and stable payment capability. Business-related indicators include indicators for efficient processing needs, flexible channel needs, routine processing needs, high-security channel needs, low-latency needs, routine arrival needs, timed arrival needs, and fixed-period arrival needs. Amount-related indicators include indicators for high channel capacity, medium channel capacity, low channel capacity, high cost sensitivity, medium cost sensitivity, and low cost sensitivity. These indicators are arranged in the order of identity indicators, business indicators, and amount indicators to form a routing evaluation indicator set containing multiple evaluation dimensions.

[0055] Step 302: Match the routing evaluation metric set with the policy conditions in the predefined policy library to obtain the baseline routing policy; extract the policy direction vector from the baseline routing policy; calculate the angle range based on the policy direction vector to generate the corresponding policy angle interval. Specifically, the predefined policy library stores multiple routing policies, each containing explicit policy conditions. The policy conditions consist of multiple indicator thresholds. For example, the conditions for a certain policy are: a high credit rating indicator with a credit score of 80 or above, an efficient processing demand indicator with more than 30 sub-transactions per transaction, and a medium or lower amount indicator of less than 5 million yuan in a large logistics platform scenario. The execution plan of this policy is to prioritize the use of internal e-wallet transfer channels. Each indicator in the evaluation indicator set is compared one by one with the conditions of each strategy in the strategy library. For example, if the evaluation indicator set has a credit score of 85 points, 60 sub-transactions per transaction, and an amount of 4 million yuan, and it matches the above strategy conditions perfectly, then this strategy is the baseline routing strategy. The weight values ​​of each evaluation indicator are extracted from the baseline routing strategy, and the sum of the weight values ​​is 1. Among them, the credit rating weight ranges from 0.1 to 0.3, the processing efficiency weight ranges from 0.4 to 0.6, and the amount level weight ranges from 0.2 to 0.4. For example, in the current baseline strategy, the credit rating weight is 0.2, the processing efficiency weight is 0.5, and the amount level weight is 0.3. These three weight values ​​form the strategy direction vector (0.2, 0.5, 0.3).

[0056] The angle range is calculated based on the strategy direction vector. First, a three-dimensional coordinate system is constructed with credit rating weight as the x-axis, processing efficiency weight as the y-axis, and amount level weight as the z-axis. The magnitude of the vector is then calculated using a mathematical formula. Calculation, for example, the current vector magnitude is Next, calculate the angles between the vector and each coordinate axis. The angle with the x-axis is calculated using arccos(x-axis weight / magnitude), currently approximately 71.6 degrees (arccos(0.2 / 0.616)). The angle with the y-axis is approximately 37.5 degrees (arccos(0.5 / 0.616)). The angle with the z-axis is approximately 60.7 degrees (arccos(0.3 / 0.616)). Finally, determine the range of angle fluctuations, expanding by 10 to 20 degrees to both sides of the angle between each coordinate axis. For example, currently, it is expanded by 15 degrees. The range of angles with the x-axis is 56.6 to 86.6 degrees, with the y-axis is 22.5 to 52.5 degrees, and with the z-axis is 45.7 to 75.7 degrees. These ranges together constitute the policy angle range, and policies within these ranges are considered effective policies that conform to the baseline policy direction.

[0057] This embodiment achieves precise matching with a predefined strategy library by extracting key indicators to generate a routing evaluation indicator set, ensuring that the baseline routing strategy meets the core characteristics of the transaction; and by extracting the strategy direction vector and calculating the strategy angle interval, it helps to improve the efficiency and optimization effect of payment transactions.

[0058] In a preferred embodiment of the present invention, step 4, setting a first evaluation point within the policy angle interval and a second evaluation point outside the policy angle interval, and generating a dynamic optimization trajectory based on the temporal order of the two evaluation points in the historical execution process, may include:

[0059] Step 401: Calculate the coordinates of the first evaluation point based on the angle range of the strategy angle interval; calculate the coordinates of the second evaluation point based on the boundary range of the strategy angle interval. Specifically, this includes: defining the three-dimensional coordinate system: the x-axis represents the credit rating weight, the y-axis represents the processing efficiency weight, and the z-axis represents the amount level weight. The weight values ​​for all three axes are decimals between 0 and 1, and their sum is 1. The strategy angle interval is determined based on the direction vector of the baseline routing strategy, with the angle between the x-axis and the z-axis ranging from 56.6 degrees to 86.6 degrees, the angle between the y-axis and the z-axis ranging from 22.5 degrees to 52.5 degrees, and the angle between the y-axis and the z-axis ranging from 45.7 degrees to 75.7 degrees. When calculating the coordinates of the first evaluation point, the correspondence between the weight range of each axis and the angle interval must be determined first; that is, an angle of 56.6 degrees with the x-axis corresponds to a lower limit of 0.2 for the x-axis weight, and 86.6 degrees for the z-axis weight. The angle between the x-axis and z-axis corresponds to an upper limit of 0.3 for the x-axis and 0.6 for the z-axis. An angle of 22.5 degrees with the z-axis corresponds to an upper limit of 0.6 for the z-axis and 0.4 for the z-axis. An angle of 45.7 degrees with the z-axis corresponds to an upper limit of 0.4 for the z-axis and 0.2 for the z-axis. Weight combinations are selected within these ranges; that is, the y-axis weight is first determined to be 0.5 (between 0.4 and 0.6, corresponding to angles between 22.5 and 52.5 degrees with the z-axis), and then... The x-axis weight is set to 0.25 (between 0.2 and 0.3, corresponding to an angle of 56.6 to 86.6 degrees with respect to the x-axis). Finally, the sum of the x-axis weight and the y-axis weight is subtracted from 1, i.e., 1 minus the sum of 0.25 and 0.5, to obtain the z-axis weight of 0.25 (between 0.2 and 0.4, corresponding to an angle of 45.7 to 75.7 degrees with respect to the z-axis). Thus, the coordinate position of the first evaluation point is (0.25, 0.5, 0.25).

[0060] When calculating the coordinates of the second evaluation point, a combination exceeding the above weight range needs to be selected. That is, the x-axis weight is determined to be 0.4, which is greater than the upper limit of the x-axis weight of 0.3, and the corresponding angle with the x-axis will be less than 56.6 degrees (exceeding the lower limit of the interval); the y-axis weight is determined to be 0.3, which is less than the lower limit of the y-axis weight of 0.4, and the corresponding angle with the y-axis will be greater than 52.5 degrees (exceeding the upper limit of the interval); then, the sum of the x-axis weight and the y-axis weight is subtracted from 1, that is, 1 minus the sum of 0.4 and 0.3, to obtain the z-axis weight of 0.3. At this time, although the z-axis weight is in the range of 0.2 to 0.4, since the x-axis and y-axis weights have exceeded the corresponding angle interval, the whole is outside the strategy angle interval. Thus, the coordinate position of the second evaluation point is (0.4, 0.3, 0.3).

[0061] Step 402: Based on the coordinate positions of the first and second evaluation points, perform time series analysis on the historical execution records to obtain the execution time sequence of the two evaluation points, and perform trajectory connection processing to generate a dynamically optimized trajectory. The dynamically optimized trajectory is then optimized, specifically including: first, retrieving historical execution records from the past three months; during screening, identifying records consistent with the current business scenario by business type identifiers, logistics platform batch payment of freight, and transaction characteristics (multiple sub-transactions plus freight tags); then comparing the weight combinations of each transaction execution in these records, namely x-axis credit rating weight, y-axis processing efficiency weight, and z-axis amount level weight, and selecting weight combinations that match the first evaluation point (0.25, 0.5, 0.25) or the second evaluation point (0.25, 0.5, 0.25). Transaction records with completely identical evaluation points (0.4, 0.3, 0.3) are selected. Time series analysis is performed on the selected transaction records. First, the initiation time of each transaction is extracted, accurate to the hour. For example, a transaction initiated at 9:00 on March 1st uses the strategy corresponding to the second evaluation point, while transactions initiated at 14:00 on March 5th, 10:00 on March 10th, and 16:00 on March 15th all use the strategy corresponding to the first evaluation point. Then, the evaluation points corresponding to these transactions are arranged in order from earliest to latest initiation time, forming the time sequence as follows: 9:00 on March 1st (0.4, 0.3, 0.3), 14:00 on March 5th (0.25, 0.5, 0.25), 10:00 on March 10th (0.25, 0.5, 0.25), and 16:00 on March 15th (0.25, 0.5, 0.25).

[0062] When performing trajectory connection processing, time is used as the horizontal axis, with the horizontal axis labeled in the format of date plus hour, such as 9:00 AM on March 1st and 2:00 PM on March 5th. The vertical axes in a three-dimensional coordinate system are the x-axis (credit rating weight), y-axis (processing efficiency weight), and z-axis (amount level weight), with each vertical axis set to a value range of 0 to 1. The three weight values ​​for each time point are marked on the coordinate system, and then these weight values ​​are connected sequentially with straight lines to form a preliminary dynamically optimized trajectory. The preliminary dynamically optimized trajectory is then optimized. First, anomaly judgment criteria are set, including payment delays exceeding 24 hours and sub-transaction failure rates exceeding 5%. Then, all transaction records within the trajectory coverage period are checked. For example, if a transaction occurs at 11:00 AM on March 8th, its weight combination is different from the previous one. If an assessment point is consistent, but the actual payment is delayed by 28 hours and the sub-transaction failure rate is 6%, it meets the criteria for an anomaly point. Therefore, the point corresponding to this transaction is removed from the trajectory. Calculate the weight difference between two adjacent valid time points, and evenly distribute the difference according to the time interval to generate transition points. For example, between 9:00 on March 1st and 14:00 on March 5th, add the transition point at 12:00 on March 3rd on an even basis according to the time interval. The weight calculation method for the transition points is: x-axis: 0.4 + 0.25 + 2 = 0.325; y-axis: 0.3 + 0.5 + 2 = 0.4; z-axis: 0.3 + 0.25 + 2 = 0.275. By adding transition points, the weight change between adjacent time points is ensured to be continuous, and finally, the optimized dynamic trajectory is obtained.

[0063] This embodiment calculates the coordinates of the evaluation point by defining a specific angle range, providing a precise location basis for subsequent trajectory generation and strategy optimization, and ensuring that the evaluation point can truly reflect the strategy execution.

[0064] In a preferred embodiment of the present invention, step 5, based on the comparative analysis of the dynamic optimization trajectory and the baseline routing strategy, calculates the vertical distance from each evaluation point to the corresponding policy boundary line of the baseline routing strategy to obtain distance evaluation parameters, and obtains routing correction parameters based on the distance evaluation parameters; calculates the multi-dimensional transaction feature set with the preset routing rule set, and combines the routing correction parameters to generate an adapted payment path instruction, which may include:

[0065] Step 501: Compare and analyze the dynamic optimized trajectory with the baseline routing strategy to obtain strategy deviation data; calculate the perpendicular distances from the first and second evaluation points to the strategy boundary line based on the strategy deviation data to obtain a set of distance values. Specifically, this includes: first, clarifying the parameters corresponding to the baseline routing strategy. The direction vector of the baseline routing strategy is (0.2, 0.5, 0.3), and the strategy boundary line is a straight line extending along this direction vector. This line makes an angle of 56.6 degrees with the x-axis, 37.5 degrees with the y-axis, and 60.7 degrees with the z-axis. These angles are calculated using the ratio of the weights of each axis of the baseline vector to the magnitude of the baseline vector. When calculating the magnitude of the baseline vector, first calculate the square of the weights of each axis, i.e., 0.2. 2 =0.04, 0.5 2 =0.25, 0.3 2 =0.09, then add the three squares together to get 0.04 + 0.25 + 0.09 = 0.38, and finally use the mathematical formula. The calculated value is approximately 0.616, which is the magnitude of the reference vector. Taking the angle with the x-axis as an example, first calculate the ratio of the x-axis weight to the magnitude, i.e., 0.2 ÷ 0.616 ≈ 0.325. Then substitute this ratio into the arccosine function arccos(0.325), and the result calculated by the calculator is approximately 56.6 degrees. The calculation logic is the same as for the angles with the y-axis and z-axis. Substitute the corresponding axis weights into the ratios of the magnitudes, and calculate 37.5 degrees and 60.7 degrees using the arccos function, respectively.

[0066] By comparing the evaluation points on the dynamic optimization trajectory with the baseline policy parameters, the policy deviation data is calculated. The coordinates of the first evaluation point are (0.25, 0.5, 0.25). When calculating the deviation values ​​of each axis weight, the x-axis weight is 0.25 - 0.2 = 0.05, meaning the x-axis weight is 0.05 higher than the baseline; the y-axis weight is 0.5 - 0.5 = 0, meaning the y-axis weight is the same as the baseline; and the z-axis weight is 0.25 - 0.3 = -0.05, meaning the z-axis weight is 0.05 lower than the baseline. The coordinates of the second evaluation point are (0.4, 0.3, 0.3). The x-axis weight is 0.4 - 0.2 = 0.2, meaning the x-axis weight is 0.2 higher than the baseline; the y-axis weight is 0.3 - 0.5 = -0.2, meaning the y-axis weight is 0.2 lower than the baseline; and the z-axis weight is 0.3 - 0.3 = 0, meaning the z-axis weight is the same as the baseline. These deviation values ​​of each axis together constitute the policy deviation data.

[0067] The perpendicular distance from the first evaluation point to the policy boundary line is calculated using the perpendicular distance calculation logic from a point to a line in three-dimensional space. First, the cross product of the evaluation point vector and the reference vector is calculated. Then, the magnitude of the cross product result is calculated. Finally, the magnitude of the cross product is divided by the magnitude of the reference vector. When calculating the cross product, the x-component is calculated as: x = (y-axis weight of the first evaluation point × z-axis weight of the reference vector) - (z-axis weight of the first evaluation point × y-axis weight of the reference vector), i.e., 0.5 × 0.3 - 0.25 × 0.5 = 0.025; the y-component is calculated as: x = (z-axis weight of the first evaluation point × x-axis weight of the reference vector) - (x-axis weight of the first evaluation point × z-axis weight of the reference vector), i.e., 0.25 × 0.2 - 0.25 × 0.3 = -0.025; the z-component is calculated as: x = (x-axis weight of the first evaluation point × y-axis weight of the reference vector) - (y-axis weight of the first evaluation point × x-axis weight of the reference vector), i.e., 0.25 × 0.5 - 0.5 × 0.2 = 0.025. When calculating the magnitude of the cross product result, the square of each component is calculated first, i.e., 0.025. 2 =0.000625, (-0.025) 2 =0.000625, 0.025 2 =0.000625, then add the three squares together to get 0.000625 + 0.000625 + 0.000625 = 0.001875, and finally use the mathematical formula. The calculated value is approximately 0.0433; the cross product modulus is divided by the modulus of the reference vector, i.e., 0.0433 ÷ 0.616 ≈ 0.07, which is taken as the vertical distance of the first evaluation point.

[0068] Calculate the perpendicular distance from the second evaluation point to the policy boundary line, following the same logic. The cross product of the x-component is: second evaluation point y-axis weight × reference z-axis weight - second evaluation point z-axis weight × reference y-axis weight, i.e., 0.3 × 0.3 - 0.3 × 0.5 = -0.06; the y-component is: second evaluation point z-axis weight × reference x-axis weight - second evaluation point x-axis weight × reference z-axis weight, i.e., 0.3 × 0.2 - 0.4 × 0.3 = -0.06; the z-component is: second evaluation point x-axis weight × reference y-axis weight - second evaluation point y-axis weight × reference x-axis weight, i.e., 0.4 × 0.5 - 0.3 × 0.2 = 0.14; when calculating the modulus of the cross product result, first calculate the square value of each component, i.e., (-0.06). 2 =0.0036, (-0.06) 2 =0.0036, 0.14 2 =0.0196, then add the three squares together to get 0.0036 + 0.0036 + 0.0196 = 0.0268, using the mathematical formula. The calculated value is approximately 0.1637; the cross product modulus is divided by the modulus of the reference vector, i.e., 0.1637 ÷ 0.616 ≈ 0.27, which is taken as the vertical distance of the second evaluation point.

[0069] Step 502: Perform statistical analysis on the distance value set to obtain distance evaluation parameters; calculate the correction amount based on the distance evaluation parameters to obtain routing correction parameters; match the multi-dimensional transaction feature set with the preset routing rule set to obtain the initial routing instruction. Specifically, this includes: performing statistical analysis on the distance value set, where 0.02 corresponds to the vertical distance from the first evaluation point to the strategy boundary line, and 0.08 corresponds to the vertical distance from the second evaluation point to the strategy boundary line; when calculating the average value, first add the two distance values, i.e., 0.02 plus 0.08 to get 0.1, then divide 0.1 by the number of values, 2, to obtain the average value of 0.05, which reflects the overall deviation of the two evaluation points; when calculating the maximum value, compare 0.02 and 0.08 to determine the maximum value as 0.08, which reflects the maximum deviation of the evaluation point; when calculating the minimum value, compare the two values ​​to determine the minimum value as 0.02, which reflects the minimum deviation of the evaluation point. These three values ​​together constitute the distance evaluation parameters; calculate the correction amount, first setting the correction coefficient to 0.8, which is based on the logistics platform batch... The requirements for volume-based payment scenarios were determined. This scenario necessitates ensuring the effectiveness of corrections while avoiding over-adjustment. Therefore, the preset correction coefficient range was 0.7 to 0.9. Based on historical data from the past three months showing a stable payment success rate of over 95% after correction in this scenario, a final correction coefficient of 0.8 was determined. The total correction amount was then calculated by multiplying the average distance evaluation parameter (0.05) by the correction coefficient 0.8, resulting in a total correction amount of 0.04. This total correction amount serves as the base magnitude for adjusting the weights of each axis. Finally, the correction direction and specific adjustments for each axis were determined using previously obtained strategy deviation data. Correction amounts: The x-axis weight is too high in both evaluation points, 0.05 higher in the first evaluation point and 0.2 higher in the second evaluation point, so it needs to be adjusted downwards, and the correction amount is set to -0.04; the y-axis weight is too low in the second evaluation point and has no deviation in the first evaluation point, showing an overall downward trend, so it needs to be adjusted upwards, and the correction amount is set to +0.04; the z-axis weight is only too low in the first evaluation point and has no deviation in the second evaluation point, so the deviation is small, and it needs to be adjusted slightly upwards, and the correction amount is set to +0.01. The correction amounts of these three axes together constitute the routing correction parameters.

[0070] To perform routing rule matching, the specific composition of the multi-dimensional transaction feature set is first clarified. Large logistics platforms are categorized as type types obtained through identity standardization and classification in step 201; bulk freight payments by logistics platforms are transaction type features obtained through mapping type classification to standard business types in step 202; and medium-amount transactions are transaction amount levels obtained through comparing type classification with effective amounts in step 202. A pre-set routing rule set is retrieved. Each rule in this set includes preconditions such as type classification, transaction type features, and amount level, as well as corresponding channel selection and parameter settings. For example, it might include rules for large logistics platforms prioritizing internal e-wallet transfers for bulk freight payments and medium-amount transactions; rules for small logistics platforms prioritizing bank fast-track transfers for sporadic freight payments and small amounts; and rules for large logistics platforms prioritizing large amounts for single freight payments. Using rules such as direct bank-enterprise connections, the system compares multi-dimensional transaction feature sets with these rules one by one. Rules for small logistics platforms with sporadic freight payments and small amounts are excluded due to mismatched classifications. Rules for large logistics platforms with single freight payments and large amounts are excluded due to mismatched transaction type characteristics and amount levels. Finally, a perfectly matching rule is found: for large logistics platforms with bulk freight payments and medium amounts, the system prioritizes using internal e-wallet transfer channels. Based on this rule, an initial routing instruction is generated, where the internal e-wallet transfer channel is selected as the channel, and the single transfer limit of 5 million yuan is set based on the common size of medium-sized transactions of 1 million to 5 million yuan for large logistics platforms. The number of sub-transactions that can be processed in parallel is set to 5, based on the maximum parallel processing capacity of the internal e-wallet channel in a single batch. This forms the initial routing instruction.

[0071] Step 503: Adjust and optimize the initial routing instruction based on the routing correction parameters to generate an adapted payment path instruction. Specifically, this includes: first, establishing a correspondence between the routing correction parameters and the parameters of the initial routing instruction, where the x-axis correction parameter -0.04 corresponds to the credit rating weight, the y-axis correction parameter +0.04 corresponds to the processing efficiency weight, and the z-axis correction parameter +0.01 corresponds to the amount level weight; regarding the adjustment of the processing efficiency weight by +0.04, referencing the performance parameters of the internal e-wallet channel, for every 0.01 increase in the processing efficiency weight, this channel can support one more parallel-processed sub-transaction. Therefore, based on the initial parallel quantity of 5, 4 are added, adjusting to 8, to accelerate the overall processing speed of batch payments; regarding the adjustment of the x-axis credit rating weight by -0.04, according to the association rules between credit rating and channel limits... For every 0.01 decrease in credit rating weight, the single transfer limit increases by 125,000 yuan. Therefore, the initial limit of 5 million yuan is increased by 500,000 yuan, adjusting to 5.5 million yuan, to accommodate the need for a slight relaxation of channel security requirements after the credit rating weight is slightly reduced. The adjustment of the z-axis amount level weight is +0.01. Due to the small adjustment range and the need to maintain stable processing logic for medium-amount transactions, the initial instruction's minimum sub-transaction amount of 1,000 yuan remains unchanged. The adjusted channel selection, single transfer limit, number of parallel processing transactions, and minimum sub-transaction amount are integrated to generate an adapted payment path instruction. The instruction specifies that the internal e-wallet transfer channel will be used to process this batch of freight payments, with a single transfer limit of 5.5 million yuan, supporting 8 parallel sub-transactions, and a minimum sub-transaction amount of 1,000 yuan per transaction.

[0072] This embodiment calculates correction parameters by analyzing strategy deviation data and makes targeted adjustments to the initial routing instructions, thereby achieving dynamic adaptation of the routing strategy and ensuring that the payment path of each transaction matches its characteristics, thus improving the rationality of payment.

[0073] In a preferred embodiment of the present invention, step 6, which involves executing a payment operation according to the adapted payment path instruction, performing an accounts receivable and payable write-off operation after successful payment, generating processing status information, feeding back the processing status information to the user terminal, and saving the execution process and results as an operation record, may include:

[0074] Step 601: Execute the fund transfer operation based on the adapted payment path instruction to obtain the payment execution result; based on the success status in the payment execution result, initiate the accounts receivable and payable write-off operation to obtain the write-off processing result. Specifically, this includes: when executing the fund transfer operation, according to the adapted payment path instruction, first call the internal e-wallet transfer interface, then configure 8 parallel threads to split the 100 sub-transactions of this batch payment (each corresponding to one driver, with amounts ranging from 5,000 to 50,000 yuan, totaling 3 million yuan) into 13 batches of 8 transactions each (the first 12 batches have 8 transactions each, and the last batch has 4 transactions); before processing each batch of sub-transactions, call the driver e-wallet status query interface, input the driver's identity identifier, and obtain the wallet activation status. That is, the driver wallets corresponding to 98 sub-transactions return an activated status, and the fund transfer is completed within the limit of 5.5 million yuan per transfer; the drivers corresponding to 2 sub-transactions are newly registered users, and their wallets return an inactive status. The transfer request was rejected by the interface. The above processing results were compiled to obtain the payment execution result, which shows that this batch payment consisted of 100 sub-transactions, with 98 successful and 2 failed. The reason for the failure was that the newly registered driver's e-wallet was not activated. The total amount successfully transferred was 2.94 million yuan. Based on the 98 successful transactions in the payment execution result, a reconciliation operation was initiated. This involved extracting the waybill number of each successful sub-transaction, calling the accounts payable query interface of the finance department, inputting the waybill number to retrieve the corresponding accounts payable freight record (e.g., waybill number WL20240301001 corresponds to accounts payable of 5,000 yuan), and then calling the account status update interface to update the record status from pending payment to paid, and associating it with the transaction number of this payment. The 2 failed sub-transactions did not trigger the reconciliation interface call because the fund transfer was not completed. The reconciliation operation results were compiled to obtain the reconciliation processing result, which shows that the accounts payable freight corresponding to the 98 successful payments have been reconciled, and the accounts payable corresponding to the 2 failed payments have not yet been reconciled.

[0075] Step 602: Based on the write-off processing results, update the account status of the corresponding business voucher to obtain the updated account status; based on the payment execution results and the updated account status, generate processing status information; based on the processing status information, generate feedback information to be sent to the user, specifically including: waybill vouchers are stored in the waybill management of logistics business, and settlement statements are stored in the settlement management of finance; for the 98 written-off accounts, call the status update interface of waybill management through waybill number association to update the status of the corresponding waybill voucher from pending settlement to settled; at the same time, call the status update interface of settlement management to update the status of the corresponding settlement statement from pending payment to paid; for the 2 unwritten accounts, write an explanation of driver wallet inactivity and payment failure in the remarks field of waybill vouchers and settlement statements, maintaining the original voucher status. If the status remains unchanged, the updated account status is obtained. Integrating the payment execution result and the updated account status, processing status information is generated, which includes the time the operation was initiated (e.g., 2:00 PM on March 20, 2024), the completion time (e.g., 2:15 PM on March 20, 2024), the total number of sub-transactions involved (100), 98 successful transactions, 2 failed transactions, a successful amount of 2.94 million yuan, 98 settled vouchers, and 2 pending settlement vouchers. Based on the processing status information, feedback information is generated, which includes the core elements of the processing status and suggestions for subsequent operations. The feedback information is then pushed to the batch payment notification section of the logistics platform management backend through the message push interface. At the same time, the SMS sending interface is called to send a reminder SMS to the pre-registered mobile phone number of the financial administrator to ensure that the user receives the processing result in a timely manner.

[0076] Step 603: Based on the payment path instruction, payment execution result, reconciliation processing result, and processing status information, generate and store a complete operation record. This includes: first, organizing the information of each stage in a fixed order: the operation time is accurate to the second, representing the current processing time (e.g., 14:15:30 on March 20, 2024); the instruction content is the complete content of the adapted payment path instruction; the execution result is the detailed information of the payment execution result; the reconciliation result is the specific content of the reconciliation processing result; the status information is all elements of the processing status information; then, supplementing the operation-related information, i.e., the operator's account is the preset financial administrator account, in the format of prefix CW followed by 6 digits (e.g., CW123456); the transaction batch number is generated according to rules, using the rule WLPY followed by year, month, and day. Add a 3-digit serial number (e.g., WLPY20240320001, representing the first batch on March 20, 2024); the log number is an automatically generated 16-character string (e.g., LOG2024032014153001); integrate all the above information according to a preset structured format, which includes 8 fields: operation time, operator account, transaction batch number, log number, payment path instruction, payment execution result, verification processing result, and processing status information, forming a complete operation record; when storing the operation record, first write the structured record into the batch payment operation record table in the local database, with each field in the table corresponding one-to-one with the record content; then upload it to the logistics platform's March 2024 payment record backup directory on the cloud storage server through the cloud storage interface.

[0077] This embodiment updates the status of business credentials and generates feedback information, enabling real-time monitoring of processing progress and anomalies, while providing suggestions for subsequent operations and improving the continuity of business processing.

[0078] like Figure 2 As shown, embodiments of the present invention also provide a real-time payment transaction routing decision system based on an electronic wallet, comprising:

[0079] The receiving module is used to receive payment transaction requests from the user and obtain the request data;

[0080] The processing module is used to parse and process the request data to generate a multi-dimensional transaction feature set containing the payer's identity, transaction type, and transaction amount;

[0081] The module is used to construct a set of routing evaluation indicators based on a multi-dimensional set of transaction features, determine the baseline routing strategy based on the set of routing evaluation indicators, and generate the corresponding strategy angle interval based on the strategy direction vector.

[0082] The optimization module is used to set a first evaluation point within the policy angle interval and a second evaluation point outside the policy angle interval, and to generate a dynamic optimization trajectory based on the time sequence of the two evaluation points in the historical execution process.

[0083] The calculation module is used to calculate the vertical distance from each evaluation point to the corresponding policy boundary line of the benchmark routing strategy based on the comparative analysis of the dynamically optimized trajectory and the benchmark routing strategy, to obtain the distance evaluation parameters, and to obtain the routing correction parameters based on the distance evaluation parameters; it calculates the multi-dimensional transaction feature set and the preset routing rule set, and combines the routing correction parameters to generate the adapted payment path instruction;

[0084] The feedback module is used to execute payment operations according to the adapted payment path instructions. After successful payment, it performs the reconciliation operation of accounts receivable and payable, generates processing status information, feeds back the processing status information to the user end, and saves the execution process and results as an operation record.

[0085] It should be noted that this system is a system corresponding to the above method. All implementation methods in the above method embodiments are applicable to this embodiment and can achieve the same technical effect.

[0086] Embodiments of the present invention also provide a computing device, including: a processor and a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0087] Embodiments of the present invention also provide a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0088] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for routing decision of real-time payment transaction based on electronic wallet, characterized in that, The method comprises: Step 1, receiving a payment transaction request of a user terminal to obtain request data; Step 2, performing analysis processing on the request data to generate a multi-dimensional transaction feature set comprising a payment party identity, a transaction type and a transaction amount, including: performing standardized processing on the identity category in the request data to obtain a standardized payment party identity; performing classification analysis based on the standardized payment party identity and in combination with a preset classification rule to obtain a type classification; processing the corresponding transaction amount level according to the type classification and the confirmed valid transaction amount; processing the corresponding transaction type feature through feature mapping according to the type classification and the standard business type; and integrating the type classification, the transaction type feature and the transaction amount level to generate the multi-dimensional transaction feature set; Step 3, constructing a routing evaluation index set based on the multi-dimensional transaction feature set, determining a benchmark routing strategy according to the routing evaluation index set, and generating a corresponding strategy angle interval based on a strategy direction vector, including: extracting a payment party identity feature, a transaction type feature and a transaction amount level feature from the multi-dimensional transaction feature set; generating the routing evaluation index set based on the payment party identity feature, the transaction type feature and the transaction amount level feature; matching the routing evaluation index set with a strategy condition in a predefined strategy library to obtain the benchmark routing strategy; extracting the strategy direction vector from the benchmark routing strategy; calculating an angle range based on the strategy direction vector to generate the corresponding strategy angle interval; Step 4, setting a first evaluation point within the strategy angle interval and a second evaluation point outside the strategy angle interval, and generating a dynamic optimization trajectory based on the time sequence of the two evaluation points in the historical execution process; Step 5, comparing the dynamic optimization trajectory with the benchmark routing strategy to calculate the perpendicular distance of each evaluation point to the straight line of the corresponding strategy boundary of the benchmark routing strategy, obtaining a distance evaluation parameter, and obtaining a routing correction parameter based on the distance evaluation parameter; calculating the multi-dimensional transaction feature set and the preset routing rule set, and combining the routing correction parameter to generate an adapted payment path instruction; Step 6, performing a payment operation according to the adapted payment path instruction, performing a receivables and payables cancellation operation after the payment is successful, and generating processing state information, feeding back the processing state information to the user terminal, and saving the execution process and result as an operation record.

2. The electronic wallet based real-time payment transaction routing decision method as claimed in claim 1, wherein, Receiving a payment transaction request of a user terminal to obtain request data, including: Obtaining payment party identification information, transaction amount data and business type identification from the received payment transaction request; Determining the identity category of the payment party according to the payment party identification information; performing compliance check on the transaction amount data in combination with the identity category to obtain a confirmed valid transaction amount; Determining the corresponding standard business type according to the identity category and the business type identification; and combining the identity category, the confirmed valid transaction amount and the standard business type to obtain the request data.

3. The electronic wallet based real-time payment transaction routing decision method as claimed in claim 2, wherein, Setting a first evaluation point within the strategy angle interval and a second evaluation point outside the strategy angle interval, and generating a dynamic optimization trajectory based on the time sequence of the two evaluation points in the historical execution process, including: The position calculation processing is performed according to the angle range of the strategy included angle interval, and the coordinate position of the first evaluation point is obtained; the external position calculation processing is performed according to the boundary range of the strategy included angle interval, and the coordinate position of the second evaluation point is obtained; Based on the coordinate position of the first evaluation point and the coordinate position of the second evaluation point, time series analysis is performed in the historical execution record to obtain the execution time sequence of the two evaluation points, and trajectory connection processing is performed to generate a dynamic optimization trajectory; the dynamic optimization trajectory is optimized to obtain the dynamic optimization trajectory.

4. The electronic wallet based real time payment transaction routing decision method as claimed in claim 3, wherein, According to the comparison and analysis of the dynamic optimization trajectory and the benchmark routing strategy, the vertical distance of each evaluation point to the straight line corresponding to the strategy boundary of the benchmark routing strategy is calculated to obtain a distance evaluation parameter, and the routing correction parameter is obtained based on the distance evaluation parameter; The multi-dimensional transaction feature set and the preset routing rule set are calculated, and the adaptive payment path instruction is generated in combination with the routing correction parameter, including: According to the comparison and analysis of the dynamic optimization trajectory and the benchmark routing strategy, strategy deviation data is obtained; based on the strategy deviation data, the vertical distance of the first evaluation point and the second evaluation point to the straight line of the strategy boundary is calculated to obtain a distance value set; The distance value set is statistically analyzed to obtain a distance evaluation parameter; based on the distance evaluation parameter, a correction amount is calculated to obtain a routing correction parameter; the multi-dimensional transaction feature set and the preset routing rule set are matched and calculated to obtain an initial routing instruction; The initial routing instruction is adjusted and optimized in combination with the routing correction parameter to generate an adaptive payment path instruction.

5. The electronic wallet based real-time payment transaction routing decision method as claimed in claim 4, wherein, According to the adaptive payment path instruction, a payment operation is performed, and after the payment is successful, a receivables and payables cancellation operation is performed, and processing state information is generated, the processing state information is fed back to the user end, and the execution process and result are saved as operation records, including: Based on the adaptive payment path instruction, a fund transfer operation is performed to obtain a payment execution result; based on the success state in the payment execution result, a receivables and payables cancellation operation is started to obtain a cancellation processing result; Based on the cancellation processing result, the account state of the corresponding business voucher is updated to obtain an updated account state; based on the payment execution result and the updated account state, processing state information is generated; based on the processing state information, feedback information sent to the user end is generated; Based on the payment path instruction, the payment execution result, the cancellation processing result and the processing state information, a complete operation record is generated and stored.

6. An electronic wallet based real-time payment transaction routing decision system implementing the method as claimed in any one of claims 1 to 5, characterized by, Including: The receiving module is used for receiving the payment transaction request of the user end to obtain the request data; The processing module is used for analyzing and processing the request data to generate a multi-dimensional transaction feature set including the payment party identity, transaction type and transaction amount; The construction module is used for constructing a routing evaluation index set based on the multi-dimensional transaction feature set, determining a benchmark routing strategy according to the routing evaluation index set, and generating a corresponding strategy included angle interval based on a strategy direction vector; The optimization module is used for setting a first evaluation point in the strategy included angle interval and a second evaluation point outside the strategy included angle interval, generating a dynamic optimization trajectory based on the time sequence of the two evaluation points in the historical execution process; The computing module is configured to calculate the vertical distance from each evaluation point to the straight line of the strategy boundary corresponding to the benchmark routing strategy based on the comparison and analysis of the dynamic optimization trajectory and the benchmark routing strategy, obtain a distance evaluation parameter, obtain a routing correction parameter based on the distance evaluation parameter, and perform calculation on the multi-dimensional transaction feature set and the preset routing rule set, and generate an adaptive payment path instruction in combination with the routing correction parameter. The feedback module is configured to perform a payment operation according to the adaptive payment path instruction, perform a verification and cancellation operation of accounts receivable and accounts payable after the payment is successful, generate processing state information, feed back the processing state information to the user end, and save the execution process and result as an operation record.

7. A computing device, comprising: The method comprises the following steps: one or more processors; a storage device configured to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors are caused to implement the method according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a program, and the program is executed by the processor to implement the method according to any one of claims 1 to 5.

Images