Intelligent payment method recommendation method based on transaction context

Abstract

The present invention relates to the field of smart payment technology, specifically to a method for recommending smart payment methods based on transaction context, comprising the following steps: the payment gateway obtains information from the current payment request, assigns a corresponding benchmark risk score to each information according to a preset benchmark score table, and generates a quantitative risk factor vector. During the payment request initiation phase, the present invention generates a quantitative risk factor vector by extracting in real time the geographic location anomaly, time anomaly, amount anomaly, merchant risk level, device trust, and network environment status that are directly related to the transaction environment, and numerically maps each status in combination with the benchmark score, thereby achieving high-dimensional quantification of the transaction background. In the process of constructing the risk index, the risk potential of each risk factor is bound to the historical transaction status, and the transaction risk index is formed in a dynamic cumulative manner, thereby enhancing the continuity and sensitivity of risk characterization.

Description

Technical Field

[0001] The present invention relates to the field of smart payment technology, and in particular to a method for recommending smart payment methods based on transaction context. Background Art

[0002] The field of intelligent payment technology is a comprehensive technology system based on digital payment, integrating multi-dimensional factors such as user behavior modeling, environmental perception, risk assessment and dynamic strategy recommendation, to promote the evolution of payment systems from static operations to intelligent decision-making.

[0003] While existing technologies integrate user behavior and risk information, they struggle to automatically adjust authentication levels based on real-time fluctuations, and they struggle to ensure that authentication strength matches transaction threats. When it comes to payment method selection, most current systems employ a combination of pre-set payment priorities and device support, failing to effectively consider the compatibility between authentication strength and operational costs. For example, in certain scenarios, even if transaction risk significantly increases, a payment channel with lower authentication requirements and higher costs may still be matched, increasing the probability of transaction interception or failure, reducing user experience and resulting in a waste of service resources. Therefore, improvements are needed. Summary of the Invention

[0004] The purpose of the present invention is to solve the shortcomings of the prior art and to propose an intelligent payment method recommendation method based on transaction context.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a transaction context-based intelligent payment method recommendation method, comprising the following steps:

[0006] The payment gateway obtains information from the current payment request, assigns a corresponding benchmark risk score to each piece of information based on a preset benchmark score table, and generates a quantitative risk factor vector;

[0007] Performing a weighted operation on each benchmark risk score in the quantitative risk factor vector to obtain risk potential, and accumulating the risk potential bound to the current transaction token to obtain a transaction risk index;

[0008] Based on the transaction risk index, sequentially compare it with a preset risk threshold to determine the numerical range in which the transaction risk index falls, obtain a matching risk range, select an authentication credential level based on the matching risk range, and establish a cost-balanced authentication level;

[0009] Based on the cost-balancing certification level, a configuration table of payment methods and certification levels is retrieved, all payment methods compatible with the cost-balancing certification level are screened, a list of optional payment methods is obtained, the list of optional payment methods and the cost-balancing certification level are combined into a payment instruction, and an adaptive payment recommendation instruction is generated.

[0010] Preferably, the step of obtaining the quantitative risk factor vector is:

[0011] The payment gateway receives the current payment request and, through the data interface carried in the payment request, extracts the geographic location information, transaction timestamp, payment amount, merchant identification code, device identification code, and current network connection type. It then compares each item with the corresponding historical transaction records, calculates the degree of deviation between each item and the historical transaction record, and generates a real-time status value for each item.

[0012] Based on the real-time status values ​​of each item, the pre-set geographic location abnormality benchmark score table, time abnormality benchmark score table, amount abnormality benchmark score table, merchant risk level benchmark score table, device trust benchmark score table, and network environment benchmark score table are respectively called to search and obtain the benchmark risk score corresponding to each real-time status value item by item, and generate a benchmark risk score sequence corresponding to each status value;

[0013] Based on the benchmark risk score sequence, the geographic location abnormality benchmark risk score, time abnormality benchmark risk score, amount abnormality benchmark risk score, merchant risk level benchmark risk score, device trust benchmark risk score and network environment benchmark risk score are combined and arranged in sequence to establish a quantitative risk factor vector composed of each benchmark risk score.

[0014] Preferably, the steps of obtaining the risk potential energy are:

[0015] According to the quantitative risk factor vector, the risk potential is calculated using the following formula:

[0016] ;

[0017] in, Indicates the The risk potential of a risk factor, Indicates the The basic coefficient of each risk factor, Indicates the Item numbered benchmark risk score, Indicates the Item 1 The interaction enhancement factor of the risk factors, Indicates the The range adjustment item of the item numbered benchmark risk score, Represents the total number of risk factors in the numbered benchmark risk score sequence, Indicates the Item numbered benchmark risk score.

[0018] Preferably, the steps for obtaining the transaction risk index are:

[0019] Based on the risk potential, the transaction risk index is calculated using the following formula:

[0020] ;

[0021] in, Indicates the transaction risk index generated by this transaction. Represents the current transaction risk weight factor, Represents the sum of all risk potential in the current transaction, Indicates the historical cumulative risk index of the transaction token before this transaction.

[0022] Preferably, the steps of obtaining the matching risk interval are:

[0023] Based on the transaction risk index and the historical transaction risk index, the current transaction risk index value and the historical risk index value corresponding to the previous transaction are extracted, and the risk level configuration entry into which the transaction risk index falls is read, from which the minimum threshold and maximum threshold of the current risk interval are extracted as the interval boundaries. At the same time, the basic authentication level of the current interval and the number of authentication levels in the interval are extracted to obtain a matching risk interval.

[0024] Preferably, the steps for obtaining the cost-balanced certification level are:

[0025] Calculating a certification level value based on the matched risk interval;

[0026] Based on the authentication level value, the level fields of the authentication credentials are compared one by one in the authentication credential level and operation cost configuration table, and the authentication credential entries whose level field values ​​are equal to the authentication level values ​​are filtered out. After sorting by operation cost from small to large, the record with the lowest operation cost is selected as the authentication type required for the current transaction to generate a cost-balanced authentication level.

[0027] Preferably, the steps for obtaining the list of optional payment methods are:

[0028] Based on the cost-balanced authentication level, the authentication level required for each payment method is compared one by one from the configuration table of payment methods and authentication levels, the minimum authentication level value of each payment method is extracted, and the minimum authentication level value is numerically compared with the cost-balanced authentication level of the current transaction one by one. If the minimum authentication level value corresponding to the payment method is less than or equal to the cost-balanced authentication level, the payment method is determined to be suitable for the current transaction scenario, and a payment method adaptation flag set is obtained;

[0029] Based on the payment method adaptation mark set, all payment methods marked as adapted in the set are scanned one by one, and the payment method name, payment channel identifier and payment service interface corresponding to the adapted payment method are extracted to form the payment method information items available in the current transaction environment. The payment method information items are summarized one by one and arranged in a preset order to form a list of optional payment methods.

[0030] Preferably, the steps of obtaining the adaptive payment recommendation instruction are:

[0031] Based on the list of optional payment methods, the cost balance authentication level is called, and the cost balance authentication level is attached to the back end of each payment method information item. Payment instructions containing the payment method name, payment channel identifier, payment service interface and the cost balance authentication level are generated one by one, and summarized to form an adaptive payment recommendation instruction.

[0032] Compared with the prior art, the advantages and positive effects of the present invention are:

[0033] During the payment request initiation phase, the present invention generates a quantitative risk factor vector by extracting, in real time, geographic location anomaly, time anomaly, amount anomaly, merchant risk level, device trust, and network environment status, all directly related to the transaction environment. This vector then numerically maps each status to a benchmark score, achieving high-dimensional quantification of the transaction context. During the risk index construction process, the risk potential of each risk factor is bound to historical transaction status, dynamically accumulating to form a transaction risk index, enhancing the continuity and sensitivity of risk characterization. The risk index is then compared with multi-level thresholds for interval determination. After mapping to authentication levels, operational cost factors are then considered to establish a cost-balanced authentication level, thereby achieving a balance between authentication strength and cost efficiency. During the payment method screening process, compatible payment methods are screened based on authentication levels, and the result set is further compressed based on operational cost, forming a payment instruction combination with differentiated control capabilities. By introducing a risk status accumulation mechanism, a multi-factor mapping strategy, and a coupled control mechanism between authentication levels and payment methods, payment methods are enabled to respond to real-time risk dynamics, adjust costs, and identify the constraints between authentication levels and payment methods, thereby enhancing the security of payment recommendations. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 It is a schematic diagram of the steps of the present invention. DETAILED DESCRIPTION

[0035] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0036] See also Figure 1 The present invention provides a technical solution, a method for recommending intelligent payment methods based on transaction context, comprising the following steps:

[0037] The payment gateway obtains information from the current payment request, assigns a corresponding benchmark risk score to each piece of information based on a preset benchmark score table, and generates a quantitative risk factor vector;

[0038] Perform a weighted operation on each benchmark risk score in the quantitative risk factor vector to obtain the risk potential, and then add the risk potential bound to the current transaction token to obtain the transaction risk index;

[0039] Based on the transaction risk index, a sequential comparison is performed with the preset risk threshold to determine the numerical range in which the transaction risk index falls, and a matching risk range is obtained. Based on the matching risk range, the authentication credential level is selected to establish a cost-balanced authentication level;

[0040] Based on the cost-balancing certification level, a configuration table of payment methods and certification levels is retrieved, all payment methods compatible with the cost-balancing certification level are screened, a list of optional payment methods is obtained, the list of optional payment methods and the cost-balancing certification level are combined into a payment instruction, and an adaptive payment recommendation instruction is generated.

[0041] The steps to obtain the quantitative risk factor vector are:

[0042] The payment gateway receives the current payment request and, through the data interface carried in the payment request, extracts the geographic location information, transaction timestamp, payment amount, merchant identification code, device identification code, and current network connection type. It then compares each item with the corresponding historical transaction records, calculates the degree of deviation between each item and the historical transaction record, and generates a real-time status value for each item.

[0043] Based on the real-time status value of each item, the pre-set geographic location abnormality benchmark score table, time abnormality benchmark score table, amount abnormality benchmark score table, merchant risk level benchmark score table, device trust benchmark score table, and network environment benchmark score table are called respectively to search and obtain the benchmark risk score corresponding to each real-time status value item by item, and generate the benchmark risk score sequence corresponding to each status value;

[0044] Based on the benchmark risk score sequence, the geographic location abnormality benchmark risk score, time abnormality benchmark risk score, amount abnormality benchmark risk score, merchant risk level benchmark risk score, device trust benchmark risk score and network environment benchmark risk score are combined and arranged in sequence to establish a quantitative risk factor vector composed of each benchmark risk score.

[0045] Specifically, after receiving the current payment request, the payment gateway first parses and extracts six core transaction information through the standardized data interface contained in the payment request, including geographic location information represented by latitude and longitude coordinates, transaction timestamp recorded in UNIX timestamp format, payment amount value expressed in a specific currency unit, unique merchant identification code, device identification code bound to the user's device, and network connection type that identifies the current network environment. Then, the system retrieves the historical transaction records associated with the current transaction token. This record library contains the above six information of at least one thousand successful transactions of the user in the past. The system then calculates the current transaction token. For each piece of information, the system starts the comparison and deviation calculation process with the historical records. Specifically, for geographic location information, the system first calculates the centroid of the historical transaction geographic location coordinates, that is, the average of the latitude and longitude of all historical transactions, and then uses the Haversine formula to calculate the spherical distance between the current transaction location and the centroid. This distance value is directly used as the deviation value of the geographic location. For transaction timestamps, the system divides a day into 48 half-hour time periods, counts the frequency of historical transactions in each time period, and constructs a probability distribution histogram of user transaction time. After the current transaction timestamp is mapped to the corresponding time period, its deviation is defined as For example, if 90% of the user's transactions occur between 8 pm and 10 pm, and the current transaction occurs at 3 am, the historical probability of this time period is 0.1%, and the deviation is 0.999. For the payment amount, the system calculates the average and standard deviation of the historical transaction amounts, and then converts the current payment amount into a Z-score, that is, the current amount minus the average and then divided by the standard deviation. The absolute value of the Z-score is the deviation value of the amount. For the merchant identification code, the system queries the number of transactions with the current merchant in the historical transactions, and its deviation is calculated by the formula 1-(with The deviation of a new merchant is 1. For the device identification code, the system maintains a list of trusted devices for the user. If the current device identification code exists in the list, the deviation is 0. If it is a new device, the deviation is 1. For the network connection type, the system directly assigns a deviation value based on a preset risk ranking table (for example, home WiFi = 0.1, cellular network = 0.3, public WiFi = 0.7, proxy or VPN = 0.95). After calculating the deviation values ​​of these six items of information separately, the system integrates these values ​​to generate the real-time status value of each item.

[0046] Based on the real-time status values ​​of geographic location, transaction time, payment amount, merchant, device and network connection type generated in the previous process, the system will then match each real-time status value with a standard benchmark risk score. This process relies on six independent, pre-built benchmark score tables. The construction of these tables is based on the results of in-depth statistical analysis of the platform's full historical transaction data (including hundreds of millions of fraud and normal transaction samples). The score mapping relationship is determined by analyzing the distribution patterns of different status values ​​in various types of fraudulent transactions. The specific search process is as follows: For the geographic location anomaly benchmark score table, the input is the deviation value of the geographic location (i.e., distance). The table divides the distance into Divide into multiple intervals and map them into scores. For example, a distance less than 1 km is mapped to 5 points, 1 to 10 km is mapped to 20 points, 10 to 100 km is mapped to 60 points, and greater than 100 km is mapped to 90 points. These interval boundaries and scores are determined based on the quartiles of the distance distribution of transaction locations deviating from the normal range in historical fraud cases. For the time anomaly benchmark score table, the input is the time deviation value. The table linearly or nonlinearly maps the deviation from 0 to 1 to a score from 0 to 100. For example, the function score = 100*(deviation)^2 is used for conversion to amplify the risk of high deviation. For the amount anomaly benchmark score table, the input is the amount deviation The table also divides the Z-score into intervals. For example, a Z-score less than 1 is mapped to 5 points, between 1 and 2.5 is mapped to 40 points, and greater than 2.5 is mapped to 85 points. The threshold of 2.5 is based on the statistical principle that events exceeding 2.5 times the mean value are low-probability events. For the merchant risk level benchmark score table, its input includes not only the merchant deviation, but also a global merchant risk rating, which is dynamically calculated based on the merchant's industry category, historical return order rate and other information. The score table is a two-dimensional matrix. For example, a merchant with a deviation of 1 (new merchant) and a global risk rating of "high" For example, a user with a deviation of 0.1 (old merchant) and a "low" rating has a score of only 10 points. For the device trust benchmark score table, the input is the device's deviation (0 or 1). If it is 0 (trusted device), the score is 0, and if it is 1 (new device), the score is 70. For the network environment benchmark score table, the input is the network's deviation value, which is directly multiplied by 100 as the benchmark risk score. For example, if the deviation of public WiFi is 0.7, its benchmark risk score is 70. By performing the above table lookup or conversion operations on the six real-time status values ​​one by one, the benchmark risk score sequence corresponding to each status value is finally generated.

[0047] Based on the benchmark risk score sequence generated in the previous step, which is composed of the benchmark risk scores corresponding to the geographical location abnormality, time abnormality, amount abnormality, merchant risk level, equipment trust and network environment, the system performs combination and arrangement operations. Its core purpose is to integrate these six independent values ​​into a structured data entity to facilitate subsequent unified mathematical modeling and risk calculation. This process first ensures that all benchmark risk scores have been standardized to a closed interval of 0 to 100 through their respective generation rules. This standardization ensures that risk factors of different natures are comparable in subsequent weighted operations, avoiding calculation deviations caused by different dimensions. Subsequently, the system sorts these six benchmark risk scores in a fixed, globally unified order. The fixed order is defined as follows: the first is the geographic location abnormality benchmark risk score, the second is the time abnormality benchmark risk score, the third is the amount abnormality benchmark risk score, the fourth is the merchant risk level benchmark risk score, the fifth is the device trust benchmark risk score, and the sixth is the network environment benchmark risk score. This ensures that in the subsequent risk potential calculation formula, the index representing a specific risk factor (such as k or j) can accurately correspond to the risk dimension it represents. For example, when the formula refers to the first element, it always points to the geographic location risk and will never be mistakenly operated as other risk scores. By placing these six benchmark risk scores arranged in a preset order into a vector structure, a quantitative risk factor vector composed of each benchmark risk score is finally established.

[0048] The steps to obtain risk potential are:

[0049] According to the quantitative risk factor vector, the risk potential is calculated using the following formula:

[0050] ;

[0051] in, Indicates the The risk potential of a risk factor, Indicates the The basic coefficient of each risk factor, Indicates the Item numbered benchmark risk score, Indicates the Item 1 The interaction enhancement factor of the risk factors, Indicates the The range adjustment item of the item numbered benchmark risk score, Represents the total number of risk factors in the numbered benchmark risk score sequence, Indicates the Item numbered benchmark risk score.

[0052] Specifically, the formula: The benefit of the formula is that by introducing an interaction enhancement term To quantify the synergistic effect between different risk factors, for example, when remote login (high geographical location risk) and the use of new equipment (high equipment risk) occur at the same time, the compound risk is much greater than the simple addition of the two independent risks. The formula is enhanced by the interaction factor This risk amplification effect; in addition, the hyperbolic tangent function The application of nonlinear saturation mechanism introduces the nonlinear saturation mechanism, which combines other risk factors The impact is limited to arrive This can effectively prevent an extremely abnormal risk factor (such as a huge The value) has a disproportionate and uncontrolled impact on the risk potential of other risk factors, making the model more robust; finally, through the basic coefficient and amplitude adjustment items The formula is highly flexible and configurable, allowing risk control strategy analysts to make adjustments based on the intrinsic importance and numerical distribution characteristics of different risk factors.

[0053] Indicates the The basic coefficient of the risk factor, which represents the The inherent importance or basic weight of each risk factor in the risk assessment model is obtained by first extracting at least one million labeled (normal or fraudulent) transaction records from the production database. Each record contains risk information in six dimensions: geographic location, transaction time, payment amount, merchant ID, device ID, and network type. Then, a logistic regression model is constructed with the baseline risk scores of these six dimensions as independent variables and whether the transaction is fraudulent (yes = 1, no = 0) as the dependent variable. After the model training is completed, the absolute value of the regression coefficient of each independent variable is obtained, after normalization, and can be used as the basic coefficient corresponding to each risk factor. For example, after model training, the regression coefficient of geographic location (k=1) is 0.45, and the regression coefficient of device trust (k=5) is 0.92, which shows that the device factor has a greater impact on risk judgment. In order to give it a higher basic weight in the subsequent formula, a basic scaling value (for example, 2.0) can be set. In this example, the risk potential of the geographical location (k=1) is calculated and its basic coefficient is set .

[0054] and Respectively represent Item and The numbered benchmark risk score is obtained by mapping the real-time status values ​​of each item with the preset benchmark score table in the previous step. It is a value between 0 and 100 that directly quantifies the risk level of a single dimension. Each risk score is extracted from the quantitative risk factor vector generated in the previous step. For example, a transaction initiated late at night from a city 150 kilometers away, using a new device, and at a new merchant in a high-risk industry that far exceeds the average user consumption level, the benchmark risk scores in the quantitative risk factor vector are: Geographical Abnormality Baseline Risk Score , temporal anomaly benchmark risk score , the benchmark risk score of the amount abnormality , merchant risk level benchmark risk score , device trust benchmark risk score , network environment baseline risk score .

[0055] Indicates the Item 1 The interaction enhancement factor of the risk factors, which quantifies the When high risk occurs, risk factors The establishment of this factor matrix is ​​based on the in-depth correlation analysis of historical fraud samples. The specific calculation method is to first define the high-risk threshold of each risk factor. For example, the 80th percentile of the historical distribution of each benchmark risk score is selected as the threshold, which is recorded as , then, the interaction enhancement factor The calculation formula is: ,in, represents the probability of fraudulent transactions under given conditions, obtained by statistical calculation of the entire historical fraud data. For example, to calculate the enhancement factor of a new device (j=5) for an abnormal geographic location (k=1), , statistics show that in abnormal geographical locations The fraud rate is 4% in transactions with unusual locations and new devices. The fraud rate rises to 11.2% in transactions. In this example, the interaction enhancement factors of the geographical location risk factor (k=1) and other risk factors are set as follows: .

[0056] Indicates the The amplitude adjustment item of the item numbered benchmark risk score, which is used to adjust the hyperbolic tangent function The sensitive range determines the risk factor The saturation speed of the influence of The statistical distribution characteristics of historical transaction data will The value of the risk factor is set to The standard deviation of all non-zero values ​​of , which makes most common risk values ​​fall within The slope of the function is large and the area is more sensitive, while the risk value of extreme abnormalities will quickly enter the saturation area and its influence will be smoothed. For example, to set the amplitude adjustment item of the amount abnormality (j=3) , calculate the abnormality benchmark risk score of the amount of all historical transactions , calculate its standard deviation to be 35.5, then set In this example, the amplitude adjustment items are set for the other five risk factors except geographical location. Their values ​​are calculated using the above method and are: .

[0057] Represents the total number of risk factors in the numbered benchmark risk score sequence. This is a fixed value determined by the system design. In this method, since six risk dimensions are defined, namely, geographic location, transaction time, payment amount, merchant, device, and network, .

[0058] Calculation process:

[0059] Calculate the risk potential of the geographic location risk factor (k=1) based on the quantitative risk factor vector , enter the specific value:

[0060] ;

[0061] First, each term in the sum is calculated:

[0062] ;

[0063] Then calculate the sum:

[0064] ;

[0065] Finally calculate the risk potential :

[0066] ;

[0067] By repeating the above process for the other five risk factors, we can obtain their respective risk potentials, which together constitute the risk potential set.

[0068] The result shows that the risk potential of the geographic location risk factor in this transaction is 568.57. This value itself is not a probability or absolute risk level, but a comprehensive risk contribution measure formed by the significant amplification of the geographic location risk (basic score 90) through the interaction with the other five high-risk factors (time, amount, merchant, equipment, and network) under the current transaction environment. This value will be summed up with the risk potential of the other five risk factors to calculate the final transaction risk index.

[0069] The steps to obtain the transaction risk index are as follows:

[0070] Based on the risk potential, the transaction risk index is calculated using the following formula:

[0071] ;

[0072] in, Indicates the transaction risk index generated by this transaction. Represents the current transaction risk weight factor, Represents the sum of all risk potential in the current transaction, Indicates the historical cumulative risk index of the transaction token before this transaction.

[0073] Specifically, the formula: The benefit of the formula is that it uses the idea of ​​exponential moving average to update the risk index of the transaction token. This design avoids the isolated and static evaluation of transaction risk by integrating the instantaneous risk of the current transaction. and the historical cumulative risk of the token , a dynamic and memory-based risk assessment model was established; the parameters The introduction of , enables the model to intelligently adjust its sensitivity to current events. For new users with less historical records, the system can use a higher value, making its risk assessment more dependent on current trading behavior, while for mature users with a long-term good record, a lower value, making its risk index more stable and less likely to fluctuate violently due to a single accidental abnormal behavior, thereby effectively distinguishing between occasional risks and persistent risks, improving the accuracy of risk assessment and the smoothness of user experience.

[0074] Represents the current transaction risk weight factor, which determines the risk generated by the current transaction The weight used when updating the final transaction risk index. Its value ranges from 0 to 1 and is dynamically calculated for each transaction. The specific calculation formula is: ,in and They are the upper and lower limits of the weight factor, which are set according to the system risk control strategy. For example, for new users or high-risk scenarios, the model needs to respond quickly. For old users or common scenarios, maintain model stability and set , The total number of historical transactions associated with the current transaction token, obtained from the user database. is a decay rate constant that controls The speed at which the value decreases as the number of transactions increases, for example, , which means that after about 50 transactions, the user's risk weight factor will drop significantly and tend to be stable. For example, a user who has completed 30 transactions will have a .

[0075] Represents the sum of all risk potentials in the current transaction. This value represents the total instantaneous risk after a comprehensive assessment of all observable risk information for the current transaction. Its calculation depends on the previous step, that is, it is necessary to first calculate each benchmark risk score in the quantitative risk factor vector. , call the risk potential energy calculation formula to calculate the corresponding risk potential energy Then all (Here ) risk potential values ​​are summed. In this example, the risk potential of the geographical location risk factor (k=1) has been calculated in the previous step. Now, the risk potential of the other five risk factors can be obtained by the same calculation method, for example: time risk potential , amount of risk potential , merchant risk potential , equipment risk potential , network risk potential , add up these six values ​​to get the total risk potential of the current transaction .

[0076] Indicates the historical cumulative risk index of the transaction token before this transaction. This value is a long-term measure of the risk status of the user (or his payment credentials). It reflects the cumulative risk effect of all past transaction behaviors of the user. As part of the user profile, it is persistently stored in the risk database associated with the transaction token. After each transaction is calculated, the newly generated transaction risk index Will overwrite the old , as the "history" value of the next transaction, for a brand new transaction token, its An initial value is required, which is usually set to the average value of the historical risk index of all users in the system. For example, the system can set the initial value of all new tokens to The value is 1000. In this example, the user with a transaction record is processed. The risk index of the record at the end of the last transaction is queried from the database to obtain .

[0077] Calculation process:

[0078] Calculate the transaction risk index based on risk potential , enter the specific value:

[0079] ;

[0080] The calculation process is as follows:

[0081] ;

[0082] The result shows that the transaction risk index generated by this transaction is 2049.52. This value combines the high instantaneous risk of the current transaction (reflected by the higher value) and the user's relatively neutral historical risk record The final index has significantly increased compared to the historical value, but due to the weight factor The smoothing effect of the market is such that its growth is controlled and not completely dominated by the high risk of the current transaction.

[0083] The steps to obtain the matching risk interval are:

[0084] Based on the transaction risk index and the historical transaction risk index, the current transaction risk index value and the historical risk index value corresponding to the previous transaction are extracted, and the risk level configuration entry that the transaction risk index falls into is read. The minimum threshold and maximum threshold of the current risk interval are extracted as the interval boundaries. At the same time, the basic certification level of the current interval and the number of certification levels in the interval are extracted to obtain a matching risk interval.

[0085] Specifically, based on the current transaction risk index generated in the previous step and the historical transaction risk index of the transaction token recorded at the end of the previous transaction retrieved from the user risk database, the system first extracts these two values, namely the current transaction risk index value and the historical risk index value corresponding to the previous transaction. Then, the system accesses a pre-built risk level configuration table stored in the configuration center. This table is formulated by risk control strategy experts based on the statistical analysis of the platform's full historical transaction data (including tens of millions to hundreds of millions of marked fraud and normal transactions). The specific formulation process is to sort the final risk indexes of all historical transactions and divide them into several non-overlapping intervals using the percentile method. For example, the 0-70 percentile is a low-risk area, the 70-90 percentile is a medium-risk area, the 90-98 percentile is a high-risk area, and the 98-100 percentile is an extreme risk area. In the high-risk area, each interval is configured with clear upper and lower limits of the risk index, a basic certification level, and the number of sub-levels that can be subdivided within an interval. For example, the configuration entries of a medium-risk interval may be: the minimum threshold is 1001, the maximum threshold is 2500, the basic certification level value is 3, and the number of certification levels in the interval is 2. The system sequentially compares the current transaction risk index value with each record in the configuration table, and determines the risk interval to which it belongs by judging whether the current transaction risk index value is greater than or equal to the minimum threshold in the entry and less than the maximum threshold in the entry. Once a matching entry is found, the system immediately reads and locks all the configuration information of the entry, including the minimum and maximum thresholds as the boundaries of the risk interval, as well as the basic certification level and the number of certification levels in the interval for subsequent refined calculation of the certification level, so as to obtain a matching risk interval.

[0086] The steps to obtain the cost-neutral certification level are:

[0087] According to the matching risk interval, the certification level value is calculated using the following formula:

[0088] ,

[0089] in, Indicates the certification level value, Indicates the basic certification level value corresponding to the current risk range, Indicates the number of sub-levels in the risk interval, Indicates the current transaction risk index, Indicates the historical risk index of the previous transaction, represents the lower threshold of the risk interval, represents the upper threshold of the risk interval, represents the dynamic sensitivity factor, Represents the basic response sensitivity factor of the risk interval configuration, is the risk volatility adjustment coefficient, represents the risk velocity scaling factor;

[0090] Based on the authentication level value, the level fields of the authentication credentials are compared one by one in the authentication credential level and operation cost configuration table, and the authentication credential entries whose level field values ​​are equal to the authentication level values ​​are filtered out. After sorting by operation cost from small to large, the record with the lowest operation cost is selected as the authentication type required for the current transaction to generate a cost-balanced authentication level.

[0091] Specifically, the formula: .

[0092] The formula is useful in that the first formula is used to calculate the dynamic sensitivity factor , introducing the change in risk index and through The function processes it nonlinearly, which makes the adjustment of the certification level depend not only on the absolute level of risk, but also on the speed and direction of change of risk. When the risk index rises sharply, will increase significantly, causing the S-shaped curve (Sigmoid function) in the second formula to become steeper, and the certification level will be more sensitive to a small increase in the risk score, thereby achieving a fast and strong risk response; the second formula uses the characteristics of the logistic function (Sigmoid function) to smoothly map a continuous risk value normalized within a specific risk interval to a discrete sub-level within the interval, which avoids the "cliff effect" caused by the use of rigid, step-by-step threshold division (that is, a small fluctuation in the risk value near the threshold causes a sharp jump in the certification level), making the certification experience smoother. By Added to the dynamically calculated sub-level offset, it forms a multi-level certification level value that has both macro-interval divisions and micro-dynamic adjustments.

[0093] Indicates the basic response sensitivity factor of the risk interval configuration. This parameter defines the baseline sensitivity of the certification level to changes in the risk index within the interval, provided that the risk index does not fluctuate dramatically. It is preset in the risk level configuration table and corresponds to each risk interval. Its value is determined by risk control strategy analysts through simulation tests on historical data. The goal is to achieve the optimal risk-cost balance within different risk intervals. For example, in the low-risk interval, in order to reduce the disturbance to normal users, The value will be set low (such as 1.5) to make the certification level change smoothly, and in the high-risk range, to ensure safety, The value will be set higher (such as 4.0) to make the certification level respond more quickly to the increase in risk. For the medium risk range matched in this example (transaction risk index is between 1001 and 2500), Set to 3.0.

[0094] is the risk volatility adjustment coefficient, which is used to adjust the dynamic sensitivity factor Fluctuation of risk index The response intensity is usually between 0 and 1. The specific value is set based on the analysis of the user group behavior pattern. For user groups with relatively stable transaction behavior patterns and small standard deviation of historical risk index fluctuations, a smaller value can be set. A larger value (such as 0.3) can be set to avoid the system from overreacting to normal, small-scale risk fluctuations. For new users or user groups with changing behavior patterns, whose historical risk index fluctuation standard deviation is large, a larger value can be set. A value (e.g. 0.8) enables the system to respond more actively to significant changes in its risk status. In this example, the user's historical transaction record is moderate, showing a certain degree of behavioral uncertainty, so the system configuration The value is 0.5.

[0095] Represents the risk speed scaling factor, which is used to convert the difference in risk index that fluctuates at different orders of magnitude into Normalize to a value suitable for the input The interval of the function to ensure that the function can effectively distinguish different degrees of risk changes, The value is usually set as the reciprocal of the average absolute value of the historical risk index difference of all transactions in the system. The average value is calculated through regular (such as daily) batch processing tasks. For example, the system processed 10 million transactions in the past 24 hours, and all The average value of is 400, then Can be set to , this setting ensures that when the risk index change is at the average level, The value of is around 1, The function is in its most sensitive response area. In this example, this method is used to set .

[0096] are all parameters that have been determined or obtained in the previous steps, The transaction risk index generated for this transaction, The historical cumulative risk index of the transaction token before this transaction. is the basic certification level value corresponding to the current risk range, is the number of sub-levels in the risk interval, is the lower threshold of the risk interval, is the upper threshold of the risk interval. In this example, the value obtained in the previous step is substituted into: , and extracted from the matched risk intervals: .

[0097] Calculation process:

[0098] First, calculate the dynamic sensitivity factor based on the matched risk interval :

[0099] ;

[0100] Next, calculate the certification level value L:

[0101] First calculate the normalized risk position:

[0102] ;

[0103] Then calculate the input part of the Sigmoid function:

[0104] ;

[0105] Finally calculate the certification level value L:

[0106] ;

[0107] The result shows that after two steps of refined calculation, the final certification level value of the current transaction is 4. This level is based on the basic certification level 3, and is obtained by floating up by 1 sub-level according to the relative position of the current risk index in the corresponding range (about 70% position) and the significant upward trend of the risk index compared with the history.

[0108] Based on the authentication level value calculated in the previous step, the system starts the authentication method screening process. This process relies on a core "Authentication Credential Level and Operation Cost Configuration Table". This table is jointly established by the security administrator and business operations personnel during system initialization. The table lists in detail all the authentication methods supported by the payment gateway and annotates two key attributes for each method: the level field value and the operation cost. The level field value is an integer starting from 0, representing the security strength of the authentication method. The higher the value, the greater the security strength. For example, the static password is 1, the SMS verification code is 2, the device biometric is 4, and the U-Key is 5. The operation cost is a comprehensive quantitative indicator. Its calculation comprehensively considers three dimensions: first, the direct financial cost of each authentication, such as the communication fee of sending SMS; second, the user experience friction cost. Through large-scale user surveys and A / B testing, the operation time and psychological burden brought to users by different authentication methods are quantified into a score from 0 to 100; and finally, the technical integration and maintenance cost, which evaluates the human and resource expenditure required for the integration and daily maintenance of each authentication method. These three costs are calculated using a weighted formula. To aggregate into a final score, the system first traverses each row of the configuration table and accurately matches the "level field value" in the row with the authentication level value calculated for the current transaction. All authentication credential entries whose level field value is equal to the current authentication level value are screened out to form a temporary set of candidate authentication methods. Subsequently, the system sorts all entries in this candidate set in ascending order according to their "operation cost" field, and automatically selects the first entry, that is, the record with the lowest operation cost, as the final recommended authentication type for this transaction, thereby generating a cost-balanced authentication level.

[0109] The steps to obtain the list of available payment methods are:

[0110] Based on the cost-balanced authentication level, the authentication level required by each payment method is compared one by one from the configuration table of payment methods and authentication levels. The minimum authentication level value of each payment method is extracted. The minimum authentication level value is numerically compared with the cost-balanced authentication level of the current transaction. If the minimum authentication level value corresponding to the payment method is less than or equal to the cost-balanced authentication level, the payment method is determined to be suitable for the current transaction scenario, and a payment method adaptation tag set is obtained;

[0111] Based on the payment method adaptation tag set, scan all payment methods marked as adapted in the set one by one, extract the payment method name, payment channel identifier and payment service interface corresponding to the adapted payment method, and construct the payment method information items available in the current transaction environment. Summarize the payment method information items one by one and arrange them in a preset order to form a list of optional payment methods.

[0112] Specifically, based on the cost-balanced authentication level generated in the previous step, the system then filters out all available payment methods in the current transaction scenario from a pre-configured "payment method and authentication level configuration table". This configuration table is jointly maintained by the business operations team and the security team. It records in detail all payment methods supported by the payment gateway and clearly marks a key parameter for each payment method: the minimum authentication level value, which represents the minimum security verification strength that must be met to enable this payment method. The setting is based on the security features of the payment method itself, the compliance requirements of the relevant payment channels, and the results of historical fraud data analysis. For example, a payment method such as "balance payment" that is directly related to the user's core assets may have a minimum authentication level value set to 3, while a payment method such as "quick payment (small amount without password)" may have a minimum authentication level value of only 0 or 1, the system will start an iterative comparison program and read the records in the configuration table one by one. For each record, the system will extract the corresponding payment method name and minimum authentication level value, and then directly compare the minimum authentication level value with the cost-balanced authentication level determined by the current transaction. The comparison logic is that if the minimum authentication level value required by a payment method is less than or equal to the cost-balanced authentication level of the current transaction, the system will determine that the security of the payment method meets the requirements of the current risk scenario and is adapted. On the contrary, if the minimum authentication level value required is higher than the cost-balanced authentication level, it is determined to be incompatible. For each payment method whose comparison result is adapted, the system will generate a tag containing the unique identifier of the payment method and the "adapted" status. Finally, all these tags are summarized to obtain a payment method adaptation tag set.

[0113] Based on the payment method adaptation tag set generated in the previous step, the system begins to build a list of optional payment methods to be presented to the user. This process first scans the set one by one to filter out all payment methods with the status of "adapted". For each payment method marked as adapted, the system will use its unique identifier to query the "Payment Method and Authentication Level Configuration Table" or other related payment channel configuration libraries again to extract the complete information items of the payment method. These information items are necessary for building the user interface and subsequent payment processes, and specifically include three core fields: the first is the user-oriented "payment method name", such as "Credit Card Quick Payment" or "XX Bank Savings Card Payment", and the second is the "Payment Channel Identifier" used for routing and identification within the system. This is a unique code, such as "CC_VISA_01" or "D C_ICBC_02", and finally the "payment service interface" address or identifier required to call the payment channel to complete the payment operation. This is a specific API endpoint or function name. After extracting these three fields, the system combines them into a structured payment method information item. This process will be repeated for all adapted payment methods in the set to generate a series of payment method information items. These information items will then be aggregated and arranged in a preset order. The preset order is based on business strategy and aims to optimize user experience and transaction success rate. For example, it can be sorted according to the principles of giving priority to payment methods frequently used by users in history, payment methods with strong promotional activities, or payment channels with high stability. Finally, the aggregated and sorted sequence of payment method information items forms a list of optional payment methods.

[0114] The steps to obtain the adaptive payment recommendation instruction are as follows:

[0115] Based on the list of optional payment methods, the cost balance authentication level is called, and the cost balance authentication level is attached to the backend of each payment method information item. Payment instructions containing the payment method name, payment channel identifier, payment service interface and cost balance authentication level are generated one by one, and summarized to form adaptive payment recommendation instructions.

[0116] Specifically, based on the list of available payment methods generated in the previous steps, the system performs the final step, generating a final adaptive payment recommendation instruction. This instruction is a structured data packet that will be passed as core data to the front-end application (such as a webpage or mobile app) for dynamic rendering of the payment selection interface. The system first calls the cost-balanced authentication level determined in the previous step, which represents the authentication strength required for this transaction. Then, the system iterates over each payment method information item in the list of available payment methods. For each information item, the system combines the three fields contained in the information item: the payment method name, payment channel identifier, and payment service interface with the obtained cost-balanced authentication level. Specifically, the system adds a field named "requiredAuthLevel" to the data structure of each payment method information item and assigns it the value of the cost-balanced authentication level. In this way, the system generates payment instructions containing the payment method name, payment channel identifier, payment service interface, and cost-balanced authentication level one by one. These independent payment instructions are then encapsulated into a JSON array or similar data structure, ultimately forming a complete adaptive payment recommendation instruction that can be directly parsed and used by the front-end.

[0117] The above are merely preferred embodiments of the present invention and do not limit the present invention in any other form. Any technician familiar with the profession may use the technical content disclosed above to change or modify it into an equivalent embodiment with equivalent changes and apply it to other fields. However, any simple modification, equivalent change and modification made to the above embodiment based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of protection of the technical solution of the present invention.

Claims

1. An intelligent payment method recommendation method based on transaction context, characterized in that: The following steps are involved: The payment gateway obtains information from the current payment request, assigns a corresponding benchmark risk score to each piece of information based on a preset benchmark score table, and generates a quantitative risk factor vector; Performing a weighted operation on each benchmark risk score in the quantitative risk factor vector to obtain risk potential, and accumulating the risk potential bound to the current transaction token to obtain a transaction risk index; Based on the transaction risk index, sequentially compare it with a preset risk threshold to determine the numerical range in which the transaction risk index falls, obtain a matching risk range, select an authentication credential level based on the matching risk range, and establish a cost-balanced authentication level; Based on the cost-balancing authentication level, searching a configuration table of payment methods and authentication levels, screening all payment methods compatible with the cost-balancing authentication level, obtaining a list of optional payment methods, combining the list of optional payment methods with the cost-balancing authentication level into a payment instruction, and generating an adaptive payment recommendation instruction; The steps for obtaining the quantitative risk factor vector are: The payment gateway receives the current payment request and, through the data interface carried in the payment request, extracts the geographic location information, transaction timestamp, payment amount, merchant identification code, device identification code, and current network connection type. It then compares each item with the corresponding historical transaction records, calculates the degree of deviation between each item and the historical transaction record, and generates a real-time status value for each item. Based on the real-time status values ​​of each item, the pre-set geographic location abnormality benchmark score table, time abnormality benchmark score table, amount abnormality benchmark score table, merchant risk level benchmark score table, device trust benchmark score table, and network environment benchmark score table are respectively called to search and obtain the benchmark risk score corresponding to each real-time status value item by item, and generate a benchmark risk score sequence corresponding to each status value; Based on the benchmark risk score sequence, the geographic location abnormality benchmark risk score, time abnormality benchmark risk score, amount abnormality benchmark risk score, merchant risk level benchmark risk score, device trust benchmark risk score and network environment benchmark risk score are combined and arranged in sequence to establish a quantitative risk factor vector composed of each benchmark risk score.

2. The transaction context-based intelligent payment method recommendation method according to claim 1, characterized in that: The steps for obtaining the risk potential are: According to the quantitative risk factor vector, the risk potential is calculated using the following formula: ； in, Indicates the The risk potential of a risk factor, Indicates the The basic coefficient of each risk factor, Indicates the Item numbered benchmark risk score, Indicates the Item 1 The interaction enhancement factor of the risk factors, Indicates the The range adjustment item of the item numbered benchmark risk score, Represents the total number of risk factors in the numbered benchmark risk score sequence, Indicates the Item numbered benchmark risk score.

3. The transaction context-based intelligent payment method recommendation method according to claim 1, characterized in that: The steps for obtaining the transaction risk index are: Based on the risk potential, the transaction risk index is calculated using the following formula: ； in, Indicates the transaction risk index generated by this transaction. Represents the current transaction risk weight factor, Represents the sum of all risk potential in the current transaction, Indicates the historical cumulative risk index of the transaction token before this transaction.

4. The transaction context-based intelligent payment method recommendation method according to claim 1, characterized in that: The steps for obtaining the matching risk interval are: Based on the transaction risk index and the historical transaction risk index, the current transaction risk index value and the historical risk index value corresponding to the previous transaction are extracted, and the risk level configuration entry into which the transaction risk index falls is read, from which the minimum threshold and maximum threshold of the current risk interval are extracted as the interval boundaries. At the same time, the basic authentication level of the current interval and the number of authentication levels in the interval are extracted to obtain a matching risk interval.

5. The transaction context-based intelligent payment method recommendation method according to claim 1, characterized in that: The steps for obtaining the cost-balanced certification level are as follows: Calculating a certification level value based on the matched risk interval; Based on the authentication level value, the level fields of the authentication credentials are compared one by one in the authentication credential level and operation cost configuration table, and the authentication credential entries whose level field values ​​are equal to the authentication level values ​​are filtered out. After sorting by operation cost from small to large, the record with the lowest operation cost is selected as the authentication type required for the current transaction to generate a cost-balanced authentication level.

6. The transaction context-based intelligent payment method recommendation method according to claim 1, characterized in that: The steps for obtaining the optional payment method list are: Based on the cost-balanced authentication level, the authentication level required for each payment method is compared one by one from the configuration table of payment methods and authentication levels, the minimum authentication level value of each payment method is extracted, and the minimum authentication level value is numerically compared with the cost-balanced authentication level of the current transaction one by one. If the minimum authentication level value corresponding to the payment method is less than or equal to the cost-balanced authentication level, the payment method is determined to be suitable for the current transaction scenario, and a payment method adaptation flag set is obtained; Based on the payment method adaptation mark set, all payment methods marked as adapted in the set are scanned one by one, and the payment method name, payment channel identifier and payment service interface corresponding to the adapted payment method are extracted to form the payment method information items available in the current transaction environment. The payment method information items are summarized one by one and arranged in a preset order to form a list of optional payment methods.

7. The transaction context-based intelligent payment method recommendation method according to claim 1, characterized in that: The steps for obtaining the adaptive payment recommendation instruction are as follows: Based on the list of optional payment methods, the cost balance authentication level is called, and the cost balance authentication level is attached to the back end of each payment method information item. Payment instructions containing the payment method name, payment channel identifier, payment service interface and the cost balance authentication level are generated one by one, and summarized to form an adaptive payment recommendation instruction.

Images