A payment interface market dynamic matching and optimization method

Abstract

The present invention relates to the field of intelligent payment technology, and discloses a payment interface market dynamic matching and optimization method, including: obtaining multi-dimensional data, building a user portrait based on the multi-dimensional data; aggregating user behavior data based on a stream processing engine, and updating the user portrait; identifying the user portrait based on a decision tree model, determining the transaction scenario, building a differentiation strategy, and generating a payment method recommendation list based on the differentiation strategy; inputting the user portrait into a pre-trained probability model for comparison, and updating the payment method recommendation list based on a multi-objective algorithm; determining the payment channel status based on the multi-dimensional data, and obtaining a comprehensive score of the payment channel based on the payment channel status, and generating candidate channels based on the comprehensive score; obtaining the device health status, and determining the optimal payment channel based on the device health status. This application improves the user's operational fluency in complex usage scenarios.

Description

Technical Field

[0001] The present invention relates to the field of smart payment technology, and in particular to a payment interface market dynamic matching and optimization method. Background Art

[0002] Against the backdrop of the rapid development of the digital economy, the payment interface market is characterized by diversification, frequent updates, and intense competition. Payment systems must not only support traditional bank card payments but also be compatible with various third-party payment methods such as WeChat Pay, Alipay, and UnionPay QuickPass, as well as meet emerging payment needs.

[0003] At present, there are many payment solutions on the market, but most of them still focus on the integration and management of a single payment channel, lacking the ability to dynamically adapt and optimize different payment scenarios and hardware devices. In addition, existing payment solutions are often designed for specific payment channels or hardware devices, making it difficult to achieve seamless cross-channel and cross-device integration. As a result, merchants face technical barriers when accessing new payment channels or updating hardware devices. In complex and changing payment scenarios, existing technologies find it difficult to achieve dynamic matching of payment interfaces, resulting in cumbersome payment processes and slow response speeds, affecting user experience. Therefore, existing payment solutions still have many shortcomings.

[0004] Therefore, it is necessary to design a payment interface market dynamic matching and optimization method to solve the problems existing in current technology. Summary of the Invention

[0005] In view of this, the present invention proposes a payment interface market dynamic matching and optimization method, aiming to solve the problem of low efficiency of current payment interfaces.

[0006] The present invention proposes a payment interface market dynamic matching and optimization method, comprising:

[0007] Acquire multi-dimensional data, and construct a user profile based on the multi-dimensional data;

[0008] Based on the stream processing engine, aggregate user behavior data and update the user profile;

[0009] Identify user profiles based on a decision tree model, determine transaction scenarios, build a differentiation strategy, and generate a recommended list of payment methods based on the differentiation strategy;

[0010] Inputting the user profile into a pre-trained probability model and updating the payment method recommendation list based on a multi-objective algorithm;

[0011] Determining a payment channel status based on the multi-dimensional data, obtaining a comprehensive score of the payment channel based on the payment channel status, and generating a candidate channel based on the comprehensive score;

[0012] Obtaining a device health status, and determining an optimal payment channel based on the device health status.

[0013] Furthermore, obtaining multi-dimensional data and constructing a user profile based on the multi-dimensional data includes:

[0014] Collecting historical transaction records of users through the payment gateway, determining payment methods based on the historical transaction records, and calculating the usage frequency and success rate of each payment method to generate a user payment habit tag;

[0015] Collecting device operation data through device fingerprints, building a device compatibility matrix, and determining current device features based on the device compatibility matrix;

[0016] Determine the payment area through IP address and GPS positioning data, and determine the regional payment method whitelist based on the payment area;

[0017] A user profile is constructed based on the regional payment method whitelist, the device characteristics and the user payment habit label.

[0018] Furthermore, the payment channel is monitored in real time. When the health value of the payment channel is lower than a threshold, the circuit breaker mechanism is triggered, including:

[0019] Build a computing pipeline based on the Flink streaming computing engine and obtain transaction data from the payment channel;

[0020] Obtaining a health indicator of the payment channel based on a sliding time window;

[0021] The health indicators include transaction success rate, average latency and number of transactions;

[0022] Performing weighted calculation based on the transaction success rate, the average delay, and the number of transactions to obtain health value data;

[0023] When the health value data is lower than the threshold, the weight degradation is triggered and the weight parameters are updated through the configuration library;

[0024] When the health value data is lower than the threshold for three consecutive times, the circuit breaker mechanism is triggered and the traffic allocation of the payment channel is suspended.

[0025] Furthermore, when determining the payment area through IP address and GPS location data, it includes:

[0026] Convert the IP address to a country / city code using the MaxMind GeoIP service;

[0027] Converting the GPS positioning data into a standardized geographic location, fusing the country / city code with the standardized geographic location to obtain geographic fusion data;

[0028] Establishing a geographic database based on the map data, determining boundary information through the geographic database, and determining the shape and radius of the boundary information through latitude and longitude coordinates;

[0029] emitting horizontal rays based on the geographic fusion data, and counting the number of intersections between the horizontal rays and the boundary information; when the number of intersections is an odd number, determining that the geographic fusion data is located within the boundary information; and when the number of intersections is an even number, determining that the geographic fusion data is located outside the boundary information;

[0030] Calculating a spherical distance between the geographic fusion data and a center point of the boundary information; when the distance is less than a radius, determining that the geographic fusion data is located within the boundary information; and when the distance is greater than the radius, determining that the geographic fusion data is located outside the boundary information;

[0031] The payment area is determined based on the spherical distance information and the horizontal ray information.

[0032] Furthermore, when determining a regional payment method whitelist based on the payment area, it includes:

[0033] Based on the determination result of the payment area, obtaining a list of recommended payment methods for the payment area, and sorting the payment methods in the list of recommended payment methods in combination with the user profile;

[0034] When both IP address and GPS location data are unavailable, user profile data is used to determine the preferred payment method.

[0035] Furthermore, when aggregating user behavior data and updating the user profile, it includes:

[0036] Obtain payment success / failure data, page browsing data, and device usage data, and combine the payment success / failure data, the page browsing data, and the device usage data to obtain the user behavior data;

[0037] Subscribing to user behavior data streams based on the stream processing engine and removing duplicate data based on the device fingerprint;

[0038] Aggregating the user behavior data based on a sliding window, grouping based on user ID, and storing cumulative indicators;

[0039] The accumulated indicators are counted based on the Flink window, and the user portrait weight is updated based on the accumulated indicators.

[0040] Furthermore, when constructing a differentiation strategy based on the user profile and identifying its transaction scenario based on the decision tree model, the following steps are included:

[0041] Obtain historical transaction scenarios and historical user profiles to generate training sets;

[0042] Using information gain to screen key features based on the training set, and training a decision tree based on Scikit-learn to obtain the decision tree model;

[0043] The transaction data and the user profile are input into the decision tree model to obtain a scenario classification result, and a recommended payment method list is generated based on the scenario classification result.

[0044] Furthermore, when the user profile is input into the pre-trained probability model, the following steps are included:

[0045] The user profile is used to determine the global success rate of each payment method based on a Bayesian probability model, and the payment methods are ranked based on the global success rate, where the global success rate includes user habit matching probability, device matching probability, and geographic matching probability.

[0046] Furthermore, when updating the payment method recommendation list based on a multi-objective algorithm, the following steps are included:

[0047] Calculating a priority based on the global success rate, transaction time, and handling fee cost, and sorting the payment methods in the recommended payment method list according to the priority;

[0048] The priority is obtained by the following formula:

[0049] ;

[0050] Among them, H is the user portrait, D is the device feature, and L is the geographical location. For priority, is the global success rate, The probability of matching user habits, is the device matching probability, is the geographic matching probability, is the joint probability;

[0051] Sort the payment methods in the payment method recommendation list based on the priority:

[0052] ;

[0053] in, The priority of the payment method. is the historical average time, is the payment method fee rate, i is the index of the payment method, , , is the weight, and + + =1, n is the total number of payment methods.

[0054] Furthermore, obtaining a comprehensive score of the payment channel based on the payment channel status and generating candidate channels based on the comprehensive score include:

[0055] The comprehensive score of the payment channel is obtained by the following formula:

[0056] ;

[0057] in, For the comprehensive rating, , , and is the weight coefficient, and + + + =1, For delay, For device compatibility, is the handling fee rate;

[0058] Based on the descending order of comprehensive scores, the top three channels are selected as candidate channels.

[0059] Furthermore, obtaining the device health status and determining the optimal payment channel based on the device health status includes:

[0060] Obtain device health status, including camera status, NFC module status, network latency, and processor occupancy, to screen payment channels. Unavailable payment channels are eliminated based on the device health status, and the remaining payment channels are ranked by score to determine the optimal payment channel.

[0061] Compared with existing technologies, the present invention offers the following advantages: by integrating multi-dimensional data such as user basic attributes, historical transaction records, behavioral preferences, and device features, it can comprehensively characterize user profiles, breaking through the limitations of single-dimensional analysis and more accurately identifying their spending power, risk appetite, and usage scenario characteristics. This helps reduce the probability of misjudgment of user needs, provides a reliable basis for subsequent differentiated strategies, and reduces resource waste caused by one-sided data. Real-time aggregation and updating of user behavior data based on a stream processing engine captures instantaneous changes in user behavior and allows for immediate adjustments to assessments of their willingness to pay and decision anxiety. This improves the timeliness of profiles, avoids the information lag associated with traditional batch update models, makes recommendation strategies more relevant to the user's current state, and reduces decision bias caused by outdated information. A decision tree model is used to intelligently identify transaction scenarios, enabling differentiated recommendation logic tailored to the user's scenario characteristics (e.g., emergency top-ups, cross-border shopping, large-value transfers). This hierarchical decision-making mechanism overcomes the rigidity of single recommendation rules, improving user efficiency while reducing the risk of payment interruptions caused by strategy mismatches through scenario adaptation. Dynamically optimizing the recommended payment method list through a multi-objective algorithm balances success rate, cost, user experience, and other metrics, enhancing the ability to cope with complex business constraints and reducing strategic shortsightedness caused by fragmented objectives. Calculating a comprehensive score and generating a set of candidate channels based on real-time channel status data mitigates the risk of sudden failures or network congestion, improving the payment system's fault tolerance and reducing the probability of transaction failures due to single points of failure. Intelligent load balancing also prevents local overload of channel resources. By monitoring device operating status (such as battery power, network stability, and security environment), potential payment interruption risks can be predicted and channel selection can be optimized in advance, reducing payment process interruptions caused by terminal anomalies. Environmental adaptation also improves user experience in complex usage scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiment below. The accompanying drawings are for illustration purposes only and are not to be considered as limiting the present invention. The same reference symbols are used throughout the drawings to represent the same components. In the drawings:

[0063] Figure 1 This is a flowchart of the payment interface market dynamic matching and optimization method provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0064] Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art. It should be noted that, unless there is a conflict, the embodiments of the present disclosure and the features in the embodiments can be combined with each other. The present invention will be described in detail below with reference to the accompanying drawings and in conjunction with the embodiments.

[0065] In some embodiments of this application, see Figure 1 As shown, a payment interface market dynamic matching and optimization method includes:

[0066] S100: Acquire multi-dimensional data and build a user profile based on the multi-dimensional data.

[0067] S200: Based on the stream processing engine, aggregate user behavior data and update user profiles.

[0068] S300: Identify user portraits based on a decision tree model, determine transaction scenarios, build a differentiation strategy, and generate a recommended list of payment methods based on the differentiation strategy.

[0069] S400: Input the user profile into the pre-trained probability model and update the payment method recommendation list based on the multi-objective algorithm.

[0070] S500: Determine the payment channel status based on the multi-dimensional data, obtain a comprehensive score of the payment channel based on the payment channel status, and generate a candidate channel based on the comprehensive score.

[0071] S600: Obtain the device health status and determine the optimal payment channel based on the device health status.

[0072] Specifically, the payment gateway captures historical user transaction records, calculates the frequency and success rate of each payment method (face recognition payment, QR code payment, NFC payment), and generates a user payment habit label. For example, if a user's face recognition payment accounts for 85% in the past 30 days, they will be labeled as a "face recognition preferred user." When building a user profile, device fingerprint technology is also integrated to collect data such as device model, operating system version, and sensor type (such as NFC module, 3D structured light camera) to build a device compatibility matrix. For example, if it is detected that the user's device is equipped with an NFC chip, the NFC payment function is automatically unlocked, and the user's current location is determined by geographic location. Based on the IP address and GPS positioning data, a geographic fencing algorithm is used to delineate a regional payment method whitelist. For example, in cross-border scenarios, when the user's IP address is located outside of China, priority is given to payment interfaces that support cross-border settlement (such as Visa and MasterCard). Multi-dimensional data, including user payment preferences, device characteristics, and geographic location, is used to construct a user profile. The stream processing engine then performs windowed aggregation calculations on user behavior data (such as single transaction duration and number of payment failure retries). Real-time feature computation, built on Apache Flink, utilizes a stream-batch integrated processing model, ensuring accurate processing of out-of-order data through event time semantics and a watermark mechanism. It supports multiple window types, including sliding windows (5-second granularity), session windows (30-second timeout), and global windows, enabling millisecond-level latency aggregation analysis of high-frequency user behavior (such as payment requests). Flink's fault-tolerance mechanism ensures exactly-once semantics through state snapshots (checkpoints), ensuring the integrity and consistency of feature computations even in the event of node failures. This includes the percentile values ​​(P50 / P90 / P99) of single transaction duration and an exponentially decaying count of payment failures. Real-time statistics at the user level are achieved through a rolling window (1-minute granularity) and KeyedState. Standard deviation and threshold rules are combined to generate abnormal behavior indicators (e.g., three consecutive payment failures within 1 minute). User profiles are then constructed by integrating activity metrics from multiple time windows (normalized by Z-score of daily, weekly, and monthly operation frequency). A dynamic weight adjustment mechanism is implemented during the calculation process. Side outputs are used to respond to changes in business metrics (e.g., fluctuations in payment success rate) to enable dynamic updates of feature weights. A decision tree model is then used to classify scenarios based on transaction attributes (e.g., transaction amount, merchant type) and contextual information (e.g., network environment, timestamp). For example, a transaction occurring between 10:00 PM and 6:00 AM at a convenience store is classified as a "nighttime offline small-value payment scenario." Differentiated policies are implemented, such as: if the device supports NFC, prioritize NFC payments. Otherwise, if the location is cross-border, prioritize international credit cards.Otherwise, recommendations are made in descending order based on historical success rate. The rule library supports dynamic loading, allowing real-time adjustment of policy weights through the management backend. Based on the above approach, a preliminary list of recommended payment methods is generated (payment options in the recommended payment method list are sorted by historical preference). A Bayesian probability model is then used to calculate the priority of payment methods in the recommended payment method list. A top-three candidate list of payment methods is generated for each transaction request. The matching process balances success rate, transaction speed, and handling fee costs. A linear programming model is used to find the optimal solution, ultimately determining the optimal payment method. Once a payment method is determined, the payment channel's status is obtained to determine its comprehensive quality score. This score is used to generate candidate payment channels. This ensures that if a problem arises with the current channel, candidate channels can be switched in real time without impacting the user's payment process. If there are multiple candidate channels, the health of the payment device is monitored to eliminate unusable payment channels. For example, if a mobile phone does not have NFC, the NFC payment channel is eliminated. The remaining channels are sorted by priority to determine the optimal payment channel.

[0073] It's understandable that by integrating multi-dimensional data such as user payment habits (e.g., payment method preferences and usage frequency), device characteristics (e.g., hardware compatibility, sensor type), and real-time geolocation, dynamically updated user profiles are constructed, enabling deep insights into user needs. For example, by combining device fingerprinting technology with geo-fencing algorithms, the platform automatically adapts to supported payment methods (e.g., NFC unlocking) and regionally compliant interfaces (e.g., cross-border settlement channels), avoiding payment failures due to hardware limitations or regional policies and improving the compatibility and scenario coverage of payment interfaces. A decision tree model intelligently classifies transaction scenarios (e.g., amount range, merchant type, and time window) to dynamically generate payment recommendation strategies that are highly relevant to the scenario. For example, for low-value payments at night, quick payment methods are prioritized, while for large-value cross-border transactions, highly secure international channels are automatically selected. This reduces the complexity of manual selection and shortens the transaction decision-making process. A stream processing engine aggregates user payment behavior (e.g., transaction duration and number of failed retries) to update dynamic tags in the user profile in real time (e.g., payment success rate trends and abnormal behavior indicators). Through a flexible combination of sliding windows and session windows, the system quickly captures short-term changes in user behavior (such as shifts in payment habits) and provides immediate feedback for subsequent recommendation strategies. By incorporating probabilistic models and multi-objective algorithms, key metrics such as success rate, transaction speed, and transaction fee costs are balanced in payment method recommendations. For example, it prioritizes payment methods based on a user's historical preferences to improve success rates. It also dynamically adjusts the ranking based on channel transaction fee costs, avoiding business losses caused by single-dimensional optimization and maximizing overall returns. A candidate channel list is generated based on comprehensive payment channel scores (such as response latency, success rate, and load status), supporting failover and load balancing. If the primary channel experiences an anomaly, the system seamlessly switches to a backup channel, avoiding transaction interruptions caused by single points of failure and ensuring payment process continuity. By monitoring device status in real time (such as sensor availability and network stability), the system automatically eliminates incompatible payment methods (for example, hiding the NFC payment option when an NFC module is not available) and recommends the optimal channel based on device performance (for example, selecting a payment interface with low bandwidth requirements in weak network conditions), reducing the risk of payment failures due to device issues.

[0074] In some embodiments of the present application, obtaining multi-dimensional data and constructing a user profile based on the multi-dimensional data includes:

[0075] Collect user historical transaction records through the payment gateway, determine the payment method based on the historical transaction records, and count the frequency and success rate of each payment method to generate user payment habit labels.

[0076] Device operation data is collected through device fingerprints, a device compatibility matrix is ​​constructed, and the current device characteristics are determined based on the device compatibility matrix.

[0077] The payment area is determined by IP address and GPS positioning data, and the regional payment method whitelist is determined based on the payment area.

[0078] Build user profiles based on regional payment method whitelists, device characteristics, and user payment habit tags.

[0079] It is understandable that the original transaction data recorded by the payment gateway is obtained, including user ID, transaction time, payment method (such as face payment / code scanning payment / NFC payment, etc.), transaction status (success / failure), and duplicate transaction records are removed. The proportion of the number of times each payment method is used to the total number of times used for each user is counted, and then the proportion of successful transactions for each payment method is determined. When a payment method meets one of the following conditions, it is marked as a preference label: usage frequency ≥ 60%, success rate ≥ 95%, and the characteristics of the device fingerprint collection software and hardware, including device model, operating system version, sensor list (such as NFC module, camera module), network type, and then the device characteristics are converted into numerical feature vectors, and then compatibility is tested. The payment area is determined by IP address and GPS positioning to determine whether the user is located in a specific area (such as a cross-border area). When the user is in the country, the payment whitelist includes but is not limited to code scanning payment, face payment, and UnionPay card. When the user is abroad, the payment whitelist includes but is not limited to Visa, MasterCard, and international code scanning payment.

[0080] In some embodiments of the present application, when determining the payment area by IP address and GPS positioning data, it includes:

[0081] Convert IP addresses to country / city codes based on MaxMind GeoIP service.

[0082] The GPS positioning data is converted into a standardized geographic location, and the country / city code is fused with the standardized geographic location to obtain geographic fusion data.

[0083] A geographic database is established based on map data, and boundary information is determined through the geographic database, and the shape and radius of the boundary information are determined through latitude and longitude coordinates.

[0084] Horizontal rays are emitted based on the geographic fusion data, and the number of intersections with the boundary information is counted. When the number of intersections is an odd number, the geographic fusion data is determined to be within the boundary information. When the number of intersections is an even number, the geographic fusion data is determined to be outside the boundary information.

[0085] The spherical distance between the geographic fusion data and the center point of the boundary information is calculated. When the distance is less than the radius, the geographic fusion data is determined to be within the boundary information. When the distance is greater than the radius, the geographic fusion data is determined to be outside the boundary information.

[0086] The payment area is determined based on the spherical distance information and the horizontal ray information.

[0087] It is understandable that the IP address of the user device is obtained and converted into geographic information, such as calling the MaxMind GeoIP service API. The geographic information includes the country code, city name, and longitude and latitude coordinates. The original GPS coordinates of the device are then converted into the WGS84 standard format. The spherical distance between the IP address and the GPS coordinates is determined to determine whether the difference is greater than 1 kilometer. If the difference is greater than 1 kilometer, the GPS coordinates are used as the standard. At the same time, a geographic database is established to store coordinate sequences (such as national borders) and center coordinates and radii (such as business district coverage). The longitude and latitude are converted into a plane rectangular coordinate system by comparing the vertex coordinates to be determined with the vertex sequence of the coordinate sequence. A horizontal ray is emitted from the point to the right at the vertex coordinates to be determined. The number of intersections between the ray and the coordinate sequence is counted. When the number of intersections is odd, the vertex coordinates to be determined are within the coordinate sequence. When the number of intersections is even, the vertex coordinates to be determined are outside the coordinate sequence. The following is then calculated by combining the vertex coordinates to be determined with the center coordinates and the radius:

[0088] .

[0089] in, , , R is the radius of the earth, is the latitude difference (radians), is the longitude difference (radians), D is the spherical distance, is the dimension of the point to be judged (the user’s current location), is the latitude of the reference point (center coordinates and radius), is the longitude of the point to be determined, The longitude of the reference point (center coordinates and radius) needs to be converted to radians. Radians = longitude and latitude * π / 180. If the spherical distance between the user's coordinate point and the center point of the circular area is ≤ the radius, the judgment result is passed. If the distance is greater than the radius, the judgment result is failed. For example, for localized promotions, the coordinate sequence is the administrative boundary of Shanghai, the center coordinates and the radius are centered on the center of Shanghai, and the radius is 50 kilometers. In this case, the user must be within the administrative boundary of Shanghai (horizontal ray method) and ≤ 50 kilometers away from the city center (spherical distance method) to enjoy the local preferential payment channel.

[0090] In some embodiments of the present application, determining a regional payment method whitelist based on a payment region includes:

[0091] Based on the determination result of the payment area, a list of recommended payment methods for the payment area is obtained, and the payment methods in the list of recommended payment methods are sorted in combination with the user portrait.

[0092] When both IP address and GPS location data are unavailable, user profile data is used to determine the preferred payment method.

[0093] As you can imagine, generating a recommendation list based on payment region determination can align with local mainstream payment methods and user habits. For example, e-wallet payment methods are prioritized for the Southeast Asian market, while credit cards and localized bank transfer channels are prioritized for the European market. This regionalized filtering mechanism enhances the availability of payment options, reduces the risk of transaction interruptions due to payment methods not being supported by local merchants, and mitigates compliance risks by adhering to regional financial regulatory requirements. Introducing user profile ranking based on regional whitelists balances regional commonalities with individual characteristics. For example, if a user resides in an area with high credit card penetration, but historical data shows they frequently use mobile payments, mobile payments will be prioritized at the top of the recommendations. This dual filtering logic maintains the foundation for regional adaptability while respecting long-established user habits, reducing the perceived disconnect caused by overly mechanical recommendation strategies and avoiding decision fatigue caused by users having to repeatedly switch payment methods. When IP and GPS location data fail, user profile data is used to derive the preferred payment method, creating a backup decision path that doesn't rely on geographic information. For example, if a user has recently used a certain cross-border payment tool frequently, or the device language is set to a specific region, their potential payment preferences can be inferred even if the real-time location cannot be obtained. Fault-tolerant settings break the absolute reliance on a single data source, reduce the probability of service interruptions caused by technical failures or permission restrictions, and ensure the completion of the payment process under extreme conditions. The payment method is derived based on historical behavior, device characteristics and other portrait data, continuing the user's past operating habits. For example, if a user has successfully used the offline payment function in an off-network environment, this method will be recommended when the location data is missing again, rather than forcing the user to jump to an unfamiliar channel. This reduces the user's cognitive burden and operational complexity in abnormal scenarios, and avoids a decrease in trust or abandonment of the payment process due to sudden environmental changes.

[0094] In some embodiments of the present application, aggregating user behavior data and updating user profiles includes:

[0095] Obtain payment success / failure data, page browsing data, and device usage data, and combine the above data with device fingerprints to obtain user behavior data.

[0096] Subscribe to user behavior data streams based on the stream processing engine and remove duplicate data based on device fingerprints.

[0097] Aggregate user behavior data based on a sliding window, group them based on user ID, and store cumulative indicators.

[0098] The accumulated indicators are calculated based on Flink windows, and the user profile weights are updated based on the accumulated indicators.

[0099] It's understandable that by combining multi-dimensional data such as payment results, page views, and device operations, a three-dimensional record of user behavior can be formed. For example, by correlating payment failure events with the length of time users spent viewing the payment instructions page before the failure, it's possible to distinguish between payment interruptions caused by operational errors and voluntary abandonment due to unclear page information. This cross-process data correlation reduces the one-sidedness of single-event analysis and improves the accuracy of behavioral attribution. Using device fingerprints (such as device model, operating system characteristics, and network environment) as a basis for data merging solves the challenge of user identification across devices and sessions. For example, when a user logs into the same account on a different phone, device fingerprint differences can be used to identify the new device login behavior, preventing incorrect operations on different devices from being attributed to the same user profile. This mechanism reduces analysis bias caused by identity confusion and strengthens the correlation between data and real users. Subscribing to data streams based on a stream processing engine enables real-time computation. For example, when a user attempts multiple payment methods consecutively, the system can capture their behavioral sequence instantly (such as failing to try a credit card before switching to an e-wallet), rather than waiting for batch data synchronization to complete before processing. This low-latency processing mechanism reduces the risk of missing key behavioral signals and ensures that profile updates are synchronized with the user's current state. Device fingerprinting is used to deduplicate data streams, identifying and filtering redundant data from repeated reports or abnormal collection. For example, when network fluctuations cause the same successful payment event to be reported multiple times, duplicate records are automatically removed. This cleansing mechanism reduces storage and computing resource usage for invalid data while also preventing statistical distortion caused by data duplication. Data aggregation using a sliding window can identify sudden changes in behavioral patterns within a short time window. For example, cumulative metrics such as the duration of a user's stay on the payment page and the number of times they return to modify the payment page over the last five minutes can be used to promptly identify any confusion or fluctuations in their willingness to pay. This time-sensitive analysis surpasses the crudeness of traditional daily granularity statistics and improves responsiveness to immediate behavioral changes. Cumulative metrics are grouped and stored by user ID, preserving the complete context of the user's behavioral trajectory. For example, correlation analysis can be performed on metrics such as the frequency of device landscape and portrait switching and page refreshes after a user's first failed payment within a day to determine whether their subsequent actions represented active retries or passive abandonment. This reduces the likelihood of misinterpretation of isolated events and enhances a deeper understanding of the continuity of user intent.

[0100] In some embodiments of the present application, when constructing a differentiation strategy based on a decision tree model for a user profile and identifying its transaction scenario, the following steps are included:

[0101] Obtain historical transaction scenarios and historical user portraits to generate a training set.

[0102] Based on the training set, information gain is used to screen key features, and a decision tree is trained based on Scikit-learn to obtain a decision tree model.

[0103] Input transaction data and user profiles into the decision tree model to obtain scenario classification results, and generate a list of recommended payment methods based on the scenario classification results.

[0104] It is understandable that historical transaction scenarios and user profiles are input into the decision tree model. Historical transaction scenario data includes transaction time, amount, merchant type, payment method, and transaction results. Historical user profile data includes payment habit labels, device compatibility level, and geographic location whitelist. All of the above data are extracted and standardized, and then feature screening and decision tree training are performed. By measuring the degree of chaos in the data set:

[0105] .

[0106] in, is the entropy of the data set S, is the proportion of samples in the i-th category in the dataset (such as the proportion of "night trading"), c is the total number of categories (types of trading scenarios), and i is the sample in the i-th category, which further defines the criteria for selecting split features:

[0107] .

[0108] Among them, A is a candidate feature (such as transaction amount range), For the subset with feature A value v (e.g. amount range = 100-500 yuan), is the total number of samples in the dataset, For subset The number of samples is used to train the decision tree and obtain a trained decision tree model.

[0109] In some embodiments of the present application, when inputting a user profile into a pre-trained probability model for comparison, the following steps are performed:

[0110] The user portrait is used based on the Bayesian probability model to determine the global success rate of each payment method, and the payment methods are ranked based on the global success rate. The global success rate includes the user habit matching probability, device matching probability and geographic matching probability.

[0111] In some embodiments of the present application, updating the payment method recommendation list based on a multi-objective algorithm includes:

[0112] Priority is calculated based on the global success rate, transaction time, and handling fee cost, and the payment methods in the recommended payment method list are sorted according to the priority.

[0113] The priority is obtained by the following formula:

[0114] .

[0115] Among them, H is the user portrait, D is the device feature, and L is the geographical location. For priority, is the global success rate, The probability of matching user habits, is the device matching probability, is the geographic matching probability, is the joint probability.

[0116] Sort the payment methods in the recommended payment method list based on priority:

[0117] .

[0118] in, The priority of the payment method. is the historical average time, is the payment method fee rate, i is the index of the payment method, , , is the weight, and + + =1, n is the total number of payment methods.

[0119] As you can understand, the Bayesian model uses three inputs—user profile, device characteristics, and location—to integrate the matching probabilities of user habits, device characteristics, and location, forming a multi-dimensional, global success rate assessment. For example, if a user frequently uses an e-wallet (high user habit probability) but their current device network is unstable (low device match probability), or they are located in an overseas region where the wallet is not available (low geographic match probability), the model will automatically lower the priority of that payment method. This three-dimensional evaluation mechanism breaks through the recommendation inertia of relying solely on historical preferences and reduces the risk of payment failures due to environmental incompatibility. The probabilistic updating feature of the Bayesian model continuously absorbs new data and adjusts the weights of each dimension. For example, if a payment channel experiences a decline in service stability in a specific geographic area, the model automatically reduces the contribution of the geographic match probability in that area, rather than relying on manual adjustments based on a fixed rule base. This reduces the lag of manual maintenance strategies and improves responsiveness to market changes. Resource consumption is optimized while maintaining success rates by reducing transaction fees. For example, for small-value payments, channels with similar success rates but lower fees are prioritized, rather than blindly selecting the most expensive channels with the highest absolute success rates. This reduces the overall costs of payment providers and prevents users from abandoning their payments due to excessive fees. Transaction time addresses potential conflicts between payment speed and success assurance. For example, in scenarios where users urgently need to complete transactions (such as flash sales), the weighting of the transaction time factor is appropriately increased, prioritizing faster processing channels, even if their historical success rates are slightly lower. This reduces the experience rigidity caused by an excessive pursuit of stability and improves user experience in critical situations. Weighting parameters allow for tailored targeting to different business scenarios. For example, for transactions involving high-net-worth individuals, the weighting of transaction fees is reduced to improve payment success assurance. During promotional events, the weighting of transaction time is increased to accelerate transaction funnel conversion, enhancing the recommendation mechanism's ability to accommodate diverse business demands.

[0120] In some embodiments of the present application, obtaining a comprehensive score of the payment channel based on the payment channel status and generating candidate channels based on the comprehensive score include:

[0121] The comprehensive score of the payment channel is obtained by the following formula.

[0122] .

[0123] in, For the comprehensive rating, , , and is the weight coefficient, and + + + =1, For delay, For device compatibility, The handling fee rate.

[0124] Based on the descending order of comprehensive scores, the top three channels are selected as candidate channels.

[0125] It's understandable that by comprehensively considering the three core metrics of latency, device compatibility, and transaction fee rates, resource misallocation caused by single-metric decision-making can be avoided. For example, one channel may offer the lowest latency but high transaction fees, while another channel may offer low transaction fees but poor device compatibility. The comprehensive scoring mechanism can identify intermediate options with moderate latency, good compatibility, and reasonable fees, mitigating overall efficiency losses caused by excessive pursuit of local optima. For example, this avoids blindly selecting the lowest-latency channel, which leads to increased costs, or excessively low transaction fees, which sacrifice payment success rates. The configurable weighting coefficients allow for dynamic adjustment of evaluation priorities based on business needs. For example, during peak promotional periods, latency can be prioritized to ensure payment response speed. In response to the fragmented device landscape in emerging markets, device compatibility can be weighted higher to reduce payment interruptions caused by device incompatibility. For profit-sensitive business lines, transaction fee optimization can be prioritized to reduce the proportion of payment costs. Flexible weighting reduces rigid constraints on strategy adjustments and enhances the ability to accommodate diverse business objectives. Selecting the top three channels with the highest comprehensive scores as candidates ensures the overall quality of the recommended options while also protecting against unexpected risks by retaining alternative channels. For example, when the latency of the preferred channel increases due to network fluctuations, a seamless switch to the suboptimal channel can be achieved, rather than re-triggering the full channel evaluation. This reduces the probability of transaction failures caused by single points of failure and reduces the computational load of real-time decision-making through pre-screening.

[0126] In some embodiments of the present application, obtaining the device health status and determining the optimal payment channel based on the device health status include:

[0127] Obtain the device health status and filter payment channels. The device health status includes camera status, NFC module status, network latency, and processor occupancy. Unavailable payment channels are eliminated based on the device health status, and the remaining payment channels are ranked by score to determine the optimal payment channel.

[0128] It's understandable that by monitoring the operating status of key hardware like the camera and NFC module in real time, a precise match between payment methods and device functionality is established. For example, if camera focus anomalies are detected, QR code scanning payment channels are automatically excluded, preventing transaction interruptions due to QR code recognition failures. If unstable NFC module power supply is detected, the near-field payment option is proactively blocked, preventing transaction interruptions and the risk of frozen funds. Hardware-level compatibility verification transcends traditional usability testing that relies solely on software interfaces, reducing the probability of hidden payment failures due to physical device failures. A dynamic assessment mechanism is established to account for device performance differences. For example, on devices with processor utilization exceeding a threshold, payment channels with simple interaction flows (such as one-click payment) are prioritized, avoiding complex verification processes that increase system load and cause interface lag. This reduces the perceived disconnect for users of low-end devices and improves service coverage. The optimal communication protocol is selected based on real-time network latency characteristics. For example, in high-latency and high-jitter network environments, UDP payment channels are preferred, sacrificing some data integrity in exchange for transaction request reachability. In low-latency and stable networks, TCP channels are selected to ensure complete verification of transaction data.

[0129] In summary, the present invention offers the following beneficial effects: by integrating multi-dimensional data such as user basic attributes, historical transaction records, behavioral preferences, and device features, it can comprehensively characterize user profiles, breaking through the limitations of single-dimensional analysis and more accurately identifying their spending power, risk appetite, and usage scenario characteristics. This helps reduce the probability of misjudgment of user needs, provides a reliable basis for subsequent differentiated strategies, and reduces resource waste caused by one-sided data. Real-time aggregation and updating of user behavior data based on a stream processing engine can capture instantaneous changes in user behavior and instantly adjust assessments of their willingness to pay and decision anxiety. This improves the timeliness of profiles, avoids the information lag associated with traditional batch update models, makes recommendation strategies more relevant to the user's current state, and reduces decision bias caused by outdated information. A decision tree model is used to intelligently identify transaction scenarios, enabling differentiated recommendation logic tailored to the user's scenario characteristics (e.g., emergency top-ups, cross-border shopping, large-value transfers). This hierarchical decision-making mechanism overcomes the rigidity of single recommendation rules, improving user efficiency while reducing the risk of payment interruptions caused by strategy mismatches through scenario adaptation. Dynamically optimizing the recommended payment method list through a multi-objective algorithm balances success rate, cost, user experience, and other metrics, enhancing the ability to cope with complex business constraints and reducing strategic shortsightedness caused by fragmented objectives. Calculating a comprehensive score and generating a set of candidate channels based on real-time channel status data mitigates the risk of sudden failures or network congestion, improving the payment system's fault tolerance and reducing the probability of transaction failures due to single points of failure. Intelligent load balancing also prevents local overload of channel resources. By monitoring device operating status (such as battery power, network stability, and security environment), potential payment interruption risks can be predicted and channel selection can be optimized in advance, reducing payment process interruptions caused by terminal anomalies. Environmental adaptation also improves user experience in complex usage scenarios.

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

[0131] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0132] These computer program instructions may also be stored in a computer-readable storage device that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable storage device produce an article of manufacture comprising an instruction device that implements the process. Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0133] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0134] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, ordinary technicians in the field should understand that the specific implementation methods of the present invention can still be modified or replaced by equivalents. Any modification or equivalent replacement that does not depart from the spirit and scope of the present invention should be covered by the scope of protection of the claims of the present invention.

Claims

1. A payment interface market dynamic matching and optimization method, characterized in that: include: Acquire multi-dimensional data, and construct a user profile based on the multi-dimensional data; Based on the stream processing engine, aggregate user behavior data and update the user profile; Identify user profiles based on a decision tree model, determine transaction scenarios, build a differentiation strategy, and generate a recommended list of payment methods based on the differentiation strategy; Inputting the user profile into a pre-trained probability model and updating the payment method recommendation list based on a multi-objective algorithm; Determining a payment channel status based on the multi-dimensional data, obtaining a comprehensive score of the payment channel based on the payment channel status, and generating a candidate channel based on the comprehensive score; Obtaining a device health status, and determining an optimal payment channel based on the device health status; Acquiring multi-dimensional data and constructing a user profile based on the multi-dimensional data includes: Collecting historical transaction records of users through the payment gateway, determining payment methods based on the historical transaction records, and calculating the usage frequency and success rate of each payment method to generate a user payment habit tag; Collecting device operation data through device fingerprints, building a device compatibility matrix, and determining current device features based on the device compatibility matrix; Determine the payment area through IP address and GPS positioning data, and determine the regional payment method whitelist based on the payment area; Building a user profile based on the regional payment method whitelist, the device characteristics, and the user payment habit tag; Aggregating user behavior data and updating the user profile includes: Obtain payment success / failure data, page browsing data, and device usage data, and combine the payment success / failure data, the page browsing data, and the device usage data to obtain the user behavior data; Subscribing to user behavior data streams based on the stream processing engine and removing duplicate data based on the device fingerprint; Aggregating the user behavior data based on a sliding window, grouping based on user ID, and storing cumulative indicators; Counting the accumulated indicators based on the Flink window, and updating the user profile weight based on the accumulated indicators; Building a differentiated strategy based on the user profile and identifying its transaction scenarios includes: Obtain historical transaction scenarios and historical user profiles to generate training sets; Using information gain to screen key features based on the training set, and training a decision tree based on Scikit-learn to obtain the decision tree model; The transaction data and the user profile are input into the decision tree model to obtain a scenario classification result, and a recommended payment method list is generated based on the scenario classification result.

2. The payment interface market dynamic matching and optimization method according to claim 1, characterized in that: When determining the payment area through IP address and GPS location data, it includes: Convert the IP address to a country / city code using the MaxMind GeoIP service; Converting the GPS positioning data into a standardized geographic location, fusing the country / city code with the standardized geographic location to obtain geographic fusion data; Establishing a geographic database based on the map data, determining boundary information through the geographic database, and determining the shape and radius of the boundary information through latitude and longitude coordinates; emitting horizontal rays based on the geographic fusion data, and counting the number of intersections between the horizontal rays and the boundary information; when the number of intersections is an odd number, determining that the geographic fusion data is located within the boundary information; and when the number of intersections is an even number, determining that the geographic fusion data is located outside the boundary information; Calculating a spherical distance between the geographic fusion data and a center point of the boundary information; when the distance is less than a radius, determining that the geographic fusion data is located within the boundary information; and when the distance is greater than the radius, determining that the geographic fusion data is located outside the boundary information; The payment area is determined based on the spherical distance information and the horizontal ray information.

3. The payment interface market dynamic matching and optimization method according to claim 2, characterized in that: When determining a regional payment method whitelist based on the payment region, it includes: Based on the determination result of the payment area, obtaining a list of recommended payment methods for the payment area, and sorting the payment methods in the list of recommended payment methods in combination with the user profile; When both IP address and GPS location data are unavailable, user profile data is used to determine the preferred payment method.

4. The payment interface market dynamic matching and optimization method according to claim 1, characterized in that: When the user profile is input into the pre-trained probability model, it includes: The user profile is used to determine the global success rate of each payment method based on a Bayesian probability model, and the payment methods are ranked based on the global success rate, where the global success rate includes user habit matching probability, device matching probability, and geographic matching probability.

5. The payment interface market dynamic matching and optimization method according to claim 4, characterized in that: When updating the payment method recommendation list based on a multi-objective algorithm, it includes: Calculating a priority based on the global success rate, transaction time, and handling fee cost, and sorting the payment methods in the recommended payment method list according to the priority; The priority is obtained by the following formula: ; Among them, H is the user portrait, D is the device feature, and L is the geographical location. For priority, is the global success rate, The probability of matching user habits, is the device matching probability, is the geographic matching probability, is the joint probability; Sort the payment methods in the payment method recommendation list based on the priority: ； in, The priority of the payment method. is the historical average time, is the payment method fee rate, i is the index of the payment method, , , is the weight, and + + =1, n is the total number of payment methods.

6. The payment interface market dynamic matching and optimization method according to claim 5, characterized in that: Obtaining a comprehensive score of the payment channel based on the payment channel status, and generating candidate channels based on the comprehensive score, including: The comprehensive score of the payment channel is obtained by the following formula: ； in, For the comprehensive rating, , , and is the weight coefficient, and + + + =1, For delay, For device compatibility, is the handling fee rate; Based on the descending order of comprehensive scores, the top three channels are selected as candidate channels.

7. The payment interface market dynamic matching and optimization method according to claim 6, characterized in that: Obtaining the device health status and determining the optimal payment channel based on the device health status includes: Obtain device health status, including camera status, NFC module status, network latency, and processor occupancy, to screen payment channels. Unavailable payment channels are eliminated based on the device health status, and the remaining payment channels are ranked by score to determine the optimal payment channel.

Images