E-commerce payment mode intelligent recommendation system and method based on multi-dimensional decision

Abstract

The invention discloses an e-commerce payment mode intelligent recommendation system and method based on multi-dimensional decision, and aims to solve the problems that an existing payment recommendation scheme is single in decision dimension, lacks performance optimization and is lagged in risk control. Comprising a data acquisition module, a payment candidate pool module, a multi-dimensional decision engine module and a rendering and feedback module. The core is that a decision engine adopts a pipeline type framework, and multi-stage dynamic screening and optimization are performed on payment modes through a region matching filter, a supplier optimization device, an equipment adaptation enhancer and a risk control collaborative filter in sequence. According to the method, a personalized, high-success-rate and safe simplified payment list is finally generated by collecting context information of a user in real time and integrating multiple dimensions such as a geographic position, an equipment type, supplier real-time performance and a risk level. According to the invention, the payment recommendation precision and intelligence are realized, the payment success rate and commercial tenant economic benefits are improved, the fraud risk is effectively reduced through risk control preposition, and the user experience and the order conversion rate are improved.

Description

Technical Field

[0001] This invention relates to the field of e-commerce payment technology, specifically to an intelligent recommendation system and method for e-commerce payment methods based on multi-dimensional decision-making. Background Technology

[0002] With the booming development of global e-commerce, online payment has become a core infrastructure for business activities. However, the current payment market is characterized by high fragmentation and dynamism: on the one hand, the mainstream payment methods that users in different countries and regions are accustomed to vary significantly; on the other hand, payment technology itself continues to evolve, with various forms coexisting, such as digital wallets (e.g., Apple Pay, Google Pay), integrated payment gateways (e.g., Adyen, Stripe), and buy-now-pay-later services (e.g., Klarna, Afterpay).

[0003] Against this backdrop, e-commerce merchants targeting the global market face a significant challenge in the settlement process: how to intelligently filter and present each user with the most appropriate, user-friendly, and secure payment options from a multitude of available payment methods. Displaying too many or inappropriate payment methods not only lengthens the user's decision-making process, leading to a confusing experience and decreased conversion rates, but may also result in direct order and revenue losses due to payment failures or fraud risks.

[0004] Currently, common payment method recommendation or display solutions in the industry are mainly based on a single or limited decision-making dimension, specifically including:

[0005] (1) Region-based static configuration scheme: This is the most basic method. The system usually determines the country or region of a user based on their IP address or billing address, and then displays a pre-configured, fixed list of payment methods to all users in that region. For example, users from Germany are uniformly shown credit cards, PayPal, and Giropay. However, this method lacks consideration for individual user characteristics, real-time context, and supplier performance, and has poor flexibility.

[0006] (2) Recommendation scheme based on user history: Some systems record the payment preferences of registered users. If a user has used a certain payment method before, that method will be displayed first in subsequent transactions. Although this method has a certain degree of personalization, its effectiveness depends entirely on the user's historical data. It is ineffective for new users or users with variable behavior, and it cannot adapt to the dynamic changes in the performance of payment channels.

[0007] (3) Simple device adaptation solution: Some websites detect the type of device the user is accessing, for example, displaying the Apple Pay icon on Apple devices and the Google Pay icon on Android devices. However, this is usually an isolated judgment logic and is not integrated with other key decision-making factors such as user region, transaction risk, and supplier status, so its effect is limited.

[0008] Therefore, it can be seen that the existing solutions typically rely on only one or two isolated factors (such as geographical location or historical behavior) for judgment, failing to build a collaborative decision-making model that integrates multi-dimensional information (including real-time geographical location, device environment, real-time supplier performance, user risk profile, order attributes, etc.), resulting in inaccurate and unintelligent recommendation results. Furthermore, for the same payment type supported by multiple suppliers (such as credit card payment channels provided by multiple service providers), existing solutions cannot dynamically select the best option and allocate traffic based on the real-time changing performance indicators of each supplier (such as payment success rate, processing speed, fee rate, dispute rate), thus making it difficult to improve user payment success rate while optimizing merchant payment processing costs. In addition, functional modules such as region matching, device identification, and risk control often operate independently or are simply superimposed, and their output results may conflict with each other or be merely mechanically listed, failing to be organically integrated and prioritized through a unified decision-making framework. This results in the final payment list presented to the user potentially still appearing redundant or logically chaotic. Summary of the Invention

[0009] To address the shortcomings of existing technologies, this invention provides an intelligent recommendation system and method for e-commerce payment methods based on multi-dimensional decision-making. This solves the problems of existing payment recommendation schemes having a single decision-making dimension, lack of performance optimization, and lagging risk control. It achieves more accurate and intelligent payment recommendations, improves payment success rates and merchant economic benefits, and enhances user experience and order conversion rates.

[0010] To achieve the above objectives, the present invention provides the following technical solution:

[0011] An intelligent recommendation system for e-commerce payment methods based on multi-dimensional decision-making includes:

[0012] The data acquisition and context awareness module is used to acquire and process the user's context information in real time. The context information includes at least geographical location information, device type information, and user identity information.

[0013] The payment method candidate pool module is used to store metadata of payment methods supported by merchants and associated supplier information. The payment method metadata includes payment method type, enabled region, and amount limit, and the supplier information includes performance indicators that are updated in real time.

[0014] A multi-dimensional decision engine, connected to the data acquisition and context awareness module and the payment method candidate pool module, is used to perform multi-level filtering and optimization processing on the payment methods in the payment method candidate pool module based on the context information, and generate a final recommendation list.

[0015] The recommendation list rendering module is connected to the multi-dimensional decision engine and is used to display the final recommendation list on the settlement page according to priority.

[0016] The payment decision feedback module is used to collect payment results, update the performance indicators in the payment method candidate pool module, and trigger secondary recommendation or risk handling processes based on the reasons for payment failure.

[0017] Preferably, the multi-dimensional decision engine includes sequentially communicated connections to:

[0018] A region matching filter is used to filter out payment methods enabled in the corresponding geographical area based on the geographical location information, forming a first payment method list;

[0019] The supplier selector is used to select and retain one target supplier for each payment type from multiple suppliers in the first payment method list based on their real-time performance indicators and preset diversion rules, thereby forming a second payment method list.

[0020] A device adapter enhancer is used to adjust the display priority of payment methods associated with the device in the second payment method list based on the device type information, thereby forming a third payment method list;

[0021] The risk control collaborative filter is used to filter or sort the payment methods in the third payment method list based on the risk level assessed based on user context information and order information, and generate the final recommendation list.

[0022] Preferably, the data acquisition and context awareness module obtains geographic location information by resolving the user's public IP address from the REMOTE_ADDR field in the HTTP request header, or from the X-Real-IP and X-Forwarded-For fields, and obtaining country or region information through IP address database mapping.

[0023] Preferably, the real-time performance indicators of suppliers stored in the payment method candidate pool module include at least one of payment success rate, average processing time, fee rate, and dispute rate; wherein the payment success rate is updated daily and the dispute rate is updated monthly.

[0024] Preferably, the supplier selector includes:

[0025] A performance evaluation unit is used to calculate the priority score of each supplier based on the real-time performance indicators;

[0026] The traffic allocation execution unit is used to allocate user sessions to the corresponding target vendors based on the priority scores of each vendor and the preset traffic allocation ratio for new users using a hash algorithm; for existing users, it directly recommends vendors that they have successfully used in the past.

[0027] Preferably, the risk control collaborative filter is communicatively connected to a third-party risk control system, used to send user context information and order information to the third-party risk control system, and receive the risk level judgment result returned by it; wherein, for transactions judged as high-risk, the preset high-risk payment methods are hidden or downgraded in the final recommendation list.

[0028] Preferably, it also includes a risk control backup processing unit, which is used to automatically activate the risk control strategy provided by the payment provider or force the user to perform 3D security verification when the third-party risk control system times out or malfunctions.

[0029] Preferably, the payment decision feedback module further includes a self-learning unit, which records the processing results corresponding to different payment failure reasons and dynamically optimizes the secondary recommendation strategy or risk handling rules after payment failure.

[0030] This invention also discloses an intelligent recommendation method for e-commerce payment methods based on multi-dimensional decision-making, applied to the aforementioned system, comprising the following steps:

[0031] Step S1: In response to the user entering the checkout page, obtain the user's context information through the data collection and context awareness module;

[0032] Step S2: Using the region matching filter, based on the geographical location information in the context information, select matching payment methods from the payment method candidate pool to generate a first payment method list;

[0033] Step S3: Using a supplier selector, select the best supplier for the same payment type from the first payment method list based on real-time performance indicators and traffic splitting rules, and generate a second payment method list;

[0034] Step S4: Using the device adapter enhancer, the priority of the second payment method list is adjusted according to the device type information in the context information to generate a third payment method list;

[0035] Step S5: Using a risk control collaborative filter, perform security filtering on the list of third payment methods based on the risk assessment results, and generate and output the final recommendation list;

[0036] Step S6: Display the final recommendation list on the checkout page using the recommendation list rendering module;

[0037] Step S7: Monitor payment results and update performance indicators through the payment decision feedback module. If payment fails, perform secondary recommendations or risk management based on the reason for failure.

[0038] Preferably, the risk assessment result in step S5 is obtained by sending user context information and order information to a third-party risk control system; the security filtering includes: for high-risk transactions, hiding at least one of the payment methods, either credit card or digital wallet, in the recommendation list;

[0039] When the third-party risk control system responds abnormally, it automatically switches to the risk control verification process provided by the payment provider.

[0040] This invention provides an intelligent recommendation system and method for e-commerce payment methods based on multi-dimensional decision-making. It has the following beneficial effects:

[0041] By integrating multi-source information such as user geolocation, device characteristics, and identity status in real time through data acquisition and context awareness modules, and processing this information via a multi-dimensional decision engine, the system achieves dynamic sorting and accurate recommendations of payment methods. The system can dynamically respond to the specific scenario of each user, outputting a short list of payment options that best suits their current environment, habits, and needs. This not only significantly improves the accuracy of recommendations but also signifies an upgrade in payment recommendations from simple rule matching to complex, scenario-based intelligent decision-making.

[0042] By setting up a supplier optimizer, the system dynamically evaluates the merits of each supplier based on performance metrics such as real-time payment success rate, processing time, fees, and dispute rate. It then uses intelligent routing algorithms or historical preference locking to select the optimal supplier for each payment type. This ensures that payment requests are directed to the best-performing, most cost-effective, or most reliable channel at the time, directly improving the overall payment success rate and reducing order loss due to payment failures. Simultaneously, by guiding transactions to suppliers with more competitive fees, it effectively reduces merchants' payment processing costs, achieving a dual optimization of success rate and cost-effectiveness.

[0043] By employing a risk control collaborative filter, the real-time assessment results of third-party professional risk control systems are deeply integrated into the payment option generation stage. Based on the returned risk level and recommended actions, the system proactively hides or downgrades high-risk payment methods such as credit cards and digital wallets for high-risk transactions, blocking the main path of fraudulent transactions at the source. This not only significantly reduces potential financial losses and dispute resolution costs but also enhances the security of the entire payment ecosystem, providing merchants with more proactive and fundamental risk protection. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in this invention or the prior art, the accompanying drawings used in the description of the prior art will be briefly introduced below.

[0045] Figure 1 A schematic diagram of the system module structure of this invention;

[0046] Figure 2 The flowchart of the method of this invention;

[0047] Figure 3 Flowchart of the supplier selector in this invention;

[0048] Figure 4 Flowchart of risk control coordination and backup processing in this invention;

[0049] Figure 5 The payment decision feedback and system optimization closed-loop diagram in this invention. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings.

[0051] Example 1, as Figures 1 to 5 As shown, the intelligent recommendation system for e-commerce payment methods based on multi-dimensional decision-making provided by this invention can be deployed in a typical e-commerce platform technical architecture. This platform includes clients (web browsers, mobile apps), application server clusters, database servers, and multiple external service interfaces (such as payment gateways, risk control services, IP geolocation databases, etc.). At the software level, it is composed of multiple logical modules working together. These modules can communicate and exchange data through application programming interfaces (APIs), message queues, or direct function calls.

[0052] The hardware environment employs a distributed microservice architecture to enhance system scalability and reliability. Each module can be deployed in an independent Docker container and orchestrated and managed via Kubernetes. A relational database (such as MySQL) can be used to store payment method metadata, supplier information, and performance metrics, while an in-memory database such as Redis is used to cache real-time performance data and user session information to ensure low-latency response of the decision engine.

[0053] Each logic module includes:

[0054] The data acquisition and context awareness module is used to acquire and process user context information in real time. Context information includes at least geographic location information, device type information, and user identity information; specifically, it includes:

[0055] 11) Geographic Location Acquisition Submodule: Triggered when a user visits the checkout page or submits an order. First, it checks if the order data contains the user-filled "delivery address." If it exists and is in a complete format, the country, province, and city fields are directly parsed as the primary geographic location. If no delivery address is found, the IP address is extracted from the current HTTP / S request. In a direct server connection scenario, it is read from the REMOTE_ADDR environment variable. In a production environment using a CDN or proxy server, the first valid IP address in the X-Forwarded-For request header is parsed first. Subsequently, the obtained IP address (or the country information extracted from the delivery address) is used as the query key to call the API of a built-in or third-party IP geographic information database (such as MaxMind GeoIP2) to parse out the corresponding country code (such as "US", "DE") and possible regional information.

[0056] 12) Device Information Collection Submodule: By parsing the User-Agent string in the HTTP request header, it uses regular expressions or open-source libraries (such as UAParser) to identify the operating system (iOS, Android, Windows, macOS), device type (mobile device, desktop device) and browser information.

[0057] 13) User Identification Submodule: This module checks if a logged-in user ID exists in the current HTTP session. If it does, it marks the user as a "registered user." If not, it checks if a persistent visitor ID exists (e.g., a UUID stored in the browser's local storage). If not, it generates a new unique visitor ID and binds it to the current session. The user ID or visitor ID serves as the core identifier for this decision-making process.

[0058] The payment method candidate pool module stores metadata about the payment methods supported by merchants and associated supplier information. Payment method metadata includes payment method type, enabled region, and amount limits, while supplier information includes real-time updated performance metrics. As a configuration and data management center, the payment method candidate pool module is typically implemented using a database (such as MySQL or PostgreSQL) combined with a cache (such as Redis). Specifically, it includes:

[0059] 21) Database Design: Create the main data tables, for example:

[0060] The payment_methods table stores basic attributes of payment methods (ID, name, icon URL, type, supported client types).

[0061] The payment_providers table stores supplier information (ID, name, API key / secret key, base URL, whether enabled).

[0062] The provider_performance table stores time-series performance metrics (supplier ID, payment success rate, average response time, dispute rate, and statistical time window).

[0063] The `method_geo_rules` table stores the association rules between payment methods and enabling region / amount restrictions.

[0064] 22) Performance Metric Updates: Implement a background scheduled task (e.g., every 15 minutes) to analyze recent payment transaction logs, calculate the payment success rate (number of successful transactions / total attempts), average processing time, dispute rate, and other metrics for each supplier within the latest time window, and update these metrics in real-time to the `provider_performance` table or cache. This ensures the multi-dimensional decision engine obtains near real-time data. Rate information is typically contractually agreed upon and can be manually configured or synchronized from suppliers via API.

[0065] A multi-dimensional decision engine, connected to the data acquisition and context-aware module and the payment method candidate pool module, is used to perform multi-level filtering and optimization processing on the payment methods in the payment method candidate pool module based on context information, generating a final recommendation list. As the core of the recommendation system, the multi-dimensional decision engine adopts a chain-of-responsibility or pipeline filter design pattern, executing four core filters in series. Each filter receives the output list from the previous filter, processes it, and then passes it to the next. Specifically, it includes:

[0066] 31) Region Matching Filter: Input the user's current geographical location information (country code) and payment method candidate pool. Execute a database query (query the method_geo_rules table), join the tables to find all payment methods and their suppliers that are enabled in the user's country (is_active is true and exists in the region configuration table), and generate a payment method ID list List_Payment_1.

[0067] 32) Supplier Selector: Input List_Payment_1, user identifier. Using the user identifier as the key, query the user's historical order database. If the user has a recent successful payment record, extract the last payment method-supplier combination used. Group List_Payment_1 by payment method. For each group:

[0068] a) If the user is an existing user and the historical supplier exists in the current list and is in a normal state, query the user's most recent successfully paid order record, obtain the corresponding supplier ID, and set it as the only option in this group.

[0069] b. If the user is a new user, read the real-time performance metrics of all enabled providers in the group (preferably from the cache). Then, perform a comprehensive ranking based on a scoring algorithm (e.g., score = success rate × weight 1 - dispute rate × weight 2 - average duration × weight 3 - rate × weight 4).

[0070] c. Based on the preset global traffic distribution configuration (e.g., 50% traffic for the top-ranked user, 30% for the second-ranked user, and 20% for the third-ranked user), perform a consistent hash calculation using the user session ID to determine the target provider assigned to the user for this session. Ensure that only one specific payment option for each provider is retained for each group.

[0071] The final output is a simplified list of payment methods, List_Payment_2, where each payment type is associated with a unique preferred supplier.

[0072] 33) Device Adaptation Enhancer: Input List_Payment_2 and device type information. By traversing the list, identify payment methods strongly related to the device (e.g., Apple Pay for iOS, Google Pay for Android). Prioritize these payment methods within the list. For non-corresponding devices, sort them lower or remove them from the recommendations based on configuration. Finally, reorder the list according to the adaptation score to generate a device-optimized list List_Payment_3.

[0073] 34) Risk Control Collaborative Filter: Input List_Payment_3 and complete user context information and order snapshot. Its processing includes:

[0074] a. Risk Control Call: Call the assessment API of a third-party risk control system (such as Riskified), encapsulate key risk control data (IP, address, device fingerprint, user ID) and order information (amount, product list) into JSON, and send it to the third-party risk control system for real-time risk assessment. To reduce latency, a synchronous call with a timeout (e.g., 500ms) can be used. While waiting for a response, some rendering preparation work that is not dependent on risk control can be executed in parallel.

[0075] b. Risk Management: Receive risk levels and recommended actions from third-party risk control systems.

[0076] If the returned result is high risk and the recommended action is "block high-risk payment methods", then according to the pre-configured "high-risk strategy", high-risk payment types (such as "credit_card" and "digital_wallet") will be filtered out from the list, and only low-risk options such as "local bank transfer" and "cash payment" will be retained.

[0077] If the returned result indicates medium risk, the ranking of credit card payment methods may simply be lowered.

[0078] If the returned result is low risk and the risk control recommendation is "approved / normal processing", then List_Payment_3 is retained in its entirety.

[0079] c. Timeout and Degradation: Set a timeout for risk control API calls (e.g., 500ms). If a risk control service call times out or returns a system error, the risk control backup processing unit will be triggered immediately. The backup logic of the risk control backup processing unit can be configured as follows: A) Force 3D security verification to be enabled for all credit card payment methods and pass it to the supplier in the payment request; B) Enable the fraud screening rules built into the payment supplier (e.g., Adyen) (by setting specific parameters in the payment API call); C) Degrade to displaying only the 1-2 lowest-risk payment methods.

[0080] The final output is a list of payment methods adjusted by the risk control strategy: List_Payment_Final.

[0081] The recommendation list rendering module, connected to the multi-dimensional decision engine, is used to display the final recommendation list on the checkout page according to priority; its processing includes:

[0082] 41) Input List_Payment_Final (usually an array of objects containing fields such as payment method ID, supplier ID, display name, icon, sort priority, etc.).

[0083] 42) Processing and rendering: The backend encapsulates this list along with information such as total order amount and currency into the response data of the settlement page.

[0084] 43) Front-end rendering: After receiving the response data, the front-end (Vue / React components) renders the payment option buttons or cards in priority order. By default, the payment method with the highest priority is set as the default selected state. For payment methods requiring complex interactions (such as credit card input, digital wallet launch), the corresponding initialization script is triggered. For example, for credit cards, the payment gateway's JavaScript SDK is dynamically loaded to render the secure input box; for PayPal, its button script is loaded.

[0085] 44) User experience: Through the above processing, users will see a streamlined payment list on the checkout page, with the most likely options listed first, and which is highly matched to the current device and usage scenario.

[0086] The payment decision feedback module is used to collect payment results, update performance metrics in the payment method candidate pool module, and trigger secondary recommendation or risk handling processes based on the reasons for payment failure. Specifically, it includes:

[0087] 51) Payment Result Monitoring: Through the payment gateway's callback interface or active query, monitor the final status (success, failure, and failure code) of each transaction in real time. These records serve as raw data, driving a background scheduled task to update the `provider_performance` table, ensuring the real-time nature of decision-making.

[0088] 52) Data closed loop: If the transaction is successful, update the successful transaction count and total amount for the corresponding supplier, and trigger the performance metric recalculation service. If the transaction fails, record the reason for the failure (such as payment rejection, verification timeout, risk control interception) and associate it with the evaluation dimensions of the payment method and the supplier.

[0089] 53) Intelligent Response:

[0090] For retryable failures (such as "3D verification failed" or "payment tool temporarily rejected"), the front end can automatically trigger a page prompt to guide the user to retry the same method, or automatically switch to the second-best payment method in the list.

[0091] For a clear rejection of a payment method, a lightweight secondary recommendation process can be triggered: based on the reason for failure, similar payment methods that may also fail are filtered out from List_Payment_Final (for example, after a credit card payment fails, all credit card options are temporarily hidden, and digital wallet or BNPL options are highlighted), and the user is guided to switch.

[0092] 54) Strategy Self-Learning (Optional Advanced Implementation): Machine learning components can be introduced. Historical payment data (features: context information, payment method selection, risk control score; tags: payment success or failure) is periodically used to train the machine learning model to optimize the distribution weight allocation of the supplier selector or fine-tune the strategy threshold of the risk control filter in specific scenarios, so that the system recommendation effect can be continuously improved.

[0093] Taking cross-border e-commerce as an example, suppose a visitor in France using an iPhone places an order for a product worth 100 euros on an e-commerce website.

[0094] S10: Trigger: The user clicks to enter the checkout page and has already filled in the delivery address as Paris, France.

[0095] S20: Data Acquisition: The data acquisition module obtains the country code "FR", the device is "iOS", and the identity is "Visitor-Session ID: XYZ123".

[0096] S30: Decision-making pipeline: Specifically includes:

[0097] S31: Region Matching: Filter for payment methods available in France, such as credit cards (Visa / Mastercard via Stripe & Adyen), PayPal, and Apple Pay.

[0098] S32: Supplier Selection: The user is a new customer, and there are two suppliers for credit cards: Stripe (99% success rate) and Adyen (98% success rate). The system allocates traffic according to a preset 70% / 30% split, and assigns a Stripe to the user after hash calculation. List_Payment_2 contains: 1. Credit Card (Stripe), 2. PayPal, 3. Apple Pay.

[0099] S33: Device Compatibility: Because the device is iOS, Apple Pay is prioritized. List_Payment_3 becomes: 1. Apple Pay, 2. Credit Card (Strip), 3. PayPal.

[0100] S34: Risk Control Collaboration: Calls the risk control API, and the evaluation result is low_risk. The risk control filter does not perform any filtering. List_Payment_Final is consistent with List_Payment_3.

[0101] S40: Rendering: The page displays the following in sequence: ① Apple Pay button (selected by default), ② Credit card payment box (Stripe channel), ③ PayPal button.

[0102] S50: Payment and Feedback: The user selects Apple Pay and successfully completes the payment. The system records this successful transaction and updates the performance data for Apple Pay and the provider Stripe (because it is on the candidate list). The mapping between the user's session ID and the provider is recorded so that the user can be identified as a "returning user" on their next visit.

[0103] This invention integrates multi-source information such as user geolocation, device characteristics, and identity status in real time through a data acquisition and context-aware module. This information is then processed via a pipelined process by a multi-dimensional decision engine (region matching → supplier selection → device adaptation → risk control collaboration) to achieve dynamic sorting and accurate recommendations of payment methods. The system can dynamically respond to the specific scenario of each user, outputting a short list of payment options that best suits their current environment, habits, and needs. This not only significantly improves the accuracy of recommendations but also signifies an upgrade in payment recommendations from simple rule matching to complex, scenario-based intelligent decision-making.

[0104] To address the industry pain point of having multiple suppliers for the same payment method, this invention implements a supplier optimizer. This module dynamically evaluates the merits of each supplier based on real-time tracking of performance metrics such as payment success rate, processing time, fees, and dispute rate. It then uses an intelligent routing algorithm (for new customers) or historical preference locking (for existing customers) to select the optimal supplier for each payment type. This ensures that payment requests are directed to the best performing, most cost-effective, or most reliable channel at the time, directly improving the overall payment success rate and reducing order loss due to payment failures. Simultaneously, by guiding transactions to suppliers with more competitive fees, it effectively reduces merchants' payment processing costs, achieving a dual optimization of success rate and cost-effectiveness.

[0105] By employing a risk control collaborative filter, the real-time assessment results of third-party professional risk control systems are deeply integrated into the payment option generation stage. Based on the returned risk level and recommended actions, the system proactively hides or downgrades high-risk payment methods such as credit cards and digital wallets for high-risk transactions, blocking the main path of fraudulent transactions at the source. This not only significantly reduces potential financial losses and dispute resolution costs but also enhances the security of the entire payment ecosystem, providing merchants with more proactive and fundamental risk protection.

[0106] Through the aforementioned multi-dimensional filtering and optimization, a streamlined, familiar, secure, and device-compatible list of payment options is ultimately presented to the user. This brings multiple user experience advantages: it reduces the time users spend searching and deciding among numerous unrelated payment methods; it avoids confusion and distrust caused by seeing unfamiliar or unavailable payment methods; and it provides the convenience of one-click payment through device compatibility. A smooth and seamless payment experience directly reduces shopping cart abandonment rates and shortens the transaction completion path, thus having a direct and measurable positive impact on improving order conversion rates.

[0107] The multi-dimensional decision engine employs a clear pipeline and filter architecture. Functional modules such as region matching, supplier selection, equipment adaptation, and risk control coordination are sequentially linked as independent "processors," each with a single responsibility and clearly defined interfaces. This design enables the system to possess high flexibility and scalability: in the future, new decision filters (such as filters based on user loyalty levels or shopping cart item types) can be easily inserted as business develops, or existing filters can be upgraded without requiring major adjustments to the overall system architecture. Simultaneously, the modular design facilitates independent testing, deployment, and troubleshooting, significantly improving system maintainability and iteration efficiency, and reducing long-term operational costs.

[0108] Example 2, as Figures 2 to 5 As shown, this invention also discloses an intelligent recommendation method for e-commerce payment methods based on multi-dimensional decision-making, applied to the above-mentioned system, comprising the following steps:

[0109] Step S1: Payment recommendation process triggering and multi-source context information collection;

[0110] When a user visits the order checkout page of an e-commerce platform, the system automatically triggers a payment method recommendation process. First, the system verifies whether the current session already contains valid delivery address information; if not, it guides the user to fill in or select a delivery address. Then, a parallel data acquisition task is initiated to obtain real-time contextual information constituting the user's current payment scenario, primarily including:

[0111] Geographic location information: The delivery address actively submitted by the user is used as the highest priority and most accurate geographic location basis, and its country and region codes are parsed. If the delivery address is missing, a backup mechanism is used: the user's public IP address is extracted from the current network request, obtained by parsing HTTP request header fields such as X-Forwarded-For or REMOTE_ADDR, and an authoritative IP geographic information database is called to map the IP address to a specific country and possible region information.

[0112] Device and Environment Information: By parsing the User-Agent string in the HTTP request header or calling the mobile native SDK, the system can accurately identify the user's device type (such as iOS phone, Android tablet, Windows PC), operating system version, and browser information.

[0113] User Identity and Status Information: Identify whether a user is a logged-in registered user or an unlogged-in visitor. For registered users, extract their unique user ID; for visitors, obtain or generate a unique visitor ID bound to the current session. Simultaneously, query the user's historical payment records to determine if they are a "returning user" with a successful payment history.

[0114] Step S2: Primary filtering based on geographic compliance (region matching);

[0115] The system uses the geographic location information (country / region code) obtained in step S1 as input to execute the region matching filtering logic. It queries the preset payment method-region configuration rules and quickly filters all technically available payment methods that are permitted and enabled in that geographic location from the global payment method candidate pool, forming a first payment method candidate list. This step ensures the regional compliance and basic availability of the payment recommendations; for example, it filters the list to include iDEAL for Dutch users while excluding payment methods that are only available in Japan.

[0116] Step S3: Deep screening based on performance-cost optimization (supplier preference);

[0117] The supplier selector processes the candidate list of the first payment method, essentially solving the selection problem when there are multiple suppliers for a single payment type. This step employs a divide-and-conquer strategy based on user identity:

[0118] For existing users: Query the "Payment Method-Supplier" combination used in the user's most recent successful payment. If the supplier is in the current list and in a normal status, lock that supplier for that payment type to align with user habits and improve user consistency.

[0119] For new users: Multiple suppliers in the same payment method list are comprehensively evaluated and ranked based on their real-time performance metrics (including but not limited to payment success rate, average processing time, dispute rate, and transaction fee rate). Then, according to a preset intelligent traffic allocation ratio linked to performance ranking (e.g., allocating 50% of new user traffic to the top-performing supplier), and using a consistent hashing algorithm to calculate the user's session ID, a unique target supplier is assigned to each new user. This strategy aims to ensure scientific traffic allocation while optimizing overall payment success rate and controlling payment costs.

[0120] After completing the above logic, a second payment method candidate list is output. In this list, only one optimal supplier representative is retained for each payment type, eliminating redundant options.

[0121] Step S4: Enhance the user experience based on device interactivity (device adaptation); Based on the device type information collected in Step S1, optimize and sort the candidate list of the second payment method at the interaction level. The main rules include:

[0122] If the user's device is identified as an Apple product, the display priority of "Apple Pay" in the list will be adjusted to the highest level.

[0123] If the user's device is identified as an Android product, the display priority of "Google Pay" in the list will be adjusted to the highest level.

[0124] For non-corresponding devices (such as accessing from a PC), reduce the priority of payment methods specific to such devices, or hide them.

[0125] This step ensures that the payment list seen by the user is highly matched to their device capabilities, reduces interference from invalid options, and generates a candidate list of third payment methods.

[0126] Step S5: Security pre-filtering based on real-time risk assessment (risk control collaboration);

[0127] Real-time risk control is implemented before payment options are displayed, allowing for proactive security measures. Specifically, this includes:

[0128] S51: Risk Assessment Request: Send the user's context information (IP, device fingerprint, email, address) and the order information (amount, goods) to a third-party professional risk control system in real time for in-depth analysis.

[0129] S52: Receive and execute risk control instructions: Receive the risk_level and recommended_action returned by the risk control system. Perform security filtering on the candidate list of third-party payment methods according to the instructions.

[0130] If a payment method is deemed high-risk and the recommended action is "restrict high-risk payment methods," then payment methods prone to fraud, such as credit cards and digital wallets, will be proactively filtered out from the list.

[0131] If the risk level is low to medium, the list will remain largely unchanged, or only minor sorting adjustments will be made.

[0132] S53: Service Degradation Guarantee: Set up a call timeout mechanism. If the risk control service is unavailable, it will automatically degrade to a backup strategy, such as forcing 3D security verification to be enabled for specific payment methods, or enabling the default risk control of the payment gateway to ensure that the process is not interrupted and maintains basic security.

[0133] This step generates the final list of recommended secure and personalized payment methods.

[0134] Step S6: Terminal rendering and real-time initialization of payment options;

[0135] The final personalized security recommendation list is passed to the front-end checkout page. The front-end interface renders and displays payment methods in priority order, with the top-ranked payment method selected by default. Simultaneously, for payment methods requiring client-side initialization (such as credit card input fields and digital wallet buttons), the corresponding supplier's client SDK is asynchronously loaded and initialized to ensure users can immediately perform payment operations.

[0136] Step S7: Payment result feedback and system self-optimization closed loop;

[0137] Establish a feedback loop from payment outcomes back to the decision-making model to enable continuous learning and evolution of the system; specifically including:

[0138] S71: Result Recording and Performance Updates: Results are recorded regardless of whether the payment is successful or not. Successful transactions are used to update the corresponding supplier's performance metrics data in real time; failed transactions are recorded with specific error codes and reasons.

[0139] S72: Intelligent Anomaly Handling: For payment failures, the system automatically analyzes the cause. For retryable errors such as network timeouts, it guides the user to retry; for serious errors such as risk control rejection, it can trigger a lightweight secondary recommendation, instantly hiding payment options that may also lead to the same failure.

[0140] S73: Strategy Iteration and Optimization: Periodically summarize historical payment data, user behavior data, and risk control results, and use data analysis or machine learning models to dynamically adjust the diversion ratio in supplier selection, the filtering threshold in risk control collaboration, and the failure handling strategy, so that the entire recommendation system has the ability to self-iterate and continuously improve performance.

[0141] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. An e-commerce payment method intelligent recommendation system based on multi-dimensional decision-making, characterized by: include: The data acquisition and context awareness module is used to acquire and process the user's context information in real time. The context information includes at least geographical location information, device type information, and user identity information. The payment method candidate pool module is used to store metadata of payment methods supported by merchants and associated supplier information. The payment method metadata includes payment method type, enabled region, and amount limit, and the supplier information includes performance indicators that are updated in real time. A multi-dimensional decision engine, connected to the data acquisition and context awareness module and the payment method candidate pool module, is used to perform multi-level filtering and optimization processing on the payment methods in the payment method candidate pool module based on the context information, and generate a final recommendation list. The recommendation list rendering module is connected to the multi-dimensional decision engine and is used to display the final recommendation list on the settlement page according to priority. The payment decision feedback module is used to collect payment results, update the performance indicators in the payment method candidate pool module, and trigger secondary recommendation or risk handling processes based on the reasons for payment failure. 2.The e-commerce payment method intelligent recommendation system based on multi-dimensional decision according to claim 1, characterized in that: The multi-dimensional decision engine includes sequentially communicated connections: A region matching filter is used to filter out payment methods enabled in the corresponding geographical area based on the geographical location information, forming a first payment method list; The supplier selector is used to select and retain one target supplier for each payment type from multiple suppliers in the first payment method list based on their real-time performance indicators and preset diversion rules, thereby forming a second payment method list. A device adapter enhancer is used to adjust the display priority of payment methods associated with the device in the second payment method list based on the device type information, thereby forming a third payment method list; The risk control collaborative filter is used to filter or sort the payment methods in the third payment method list based on the risk level assessed based on user context information and order information, and generate the final recommendation list. 3.The e-commerce payment method intelligent recommendation system based on multi-dimensional decision according to claim 1, characterized in that: The data acquisition and context awareness module obtains geographic location information by resolving the user's public IP address from the REMOTE_ADDR field in the HTTP request header, or from the X-Real-IP and X-Forwarded-For fields, and obtaining country or region information through IP address database mapping.

4. The intelligent recommendation system for e-commerce payment methods based on multi-dimensional decision-making as described in claim 1, characterized in that: The payment method candidate pool module stores real-time performance indicators of suppliers, including at least one of payment success rate, average processing time, fee rate, and dispute rate; wherein the payment success rate is updated daily and the dispute rate is updated monthly.

5. The intelligent recommendation system for e-commerce payment methods based on multi-dimensional decision-making as described in claim 1, characterized in that: The supplier selector includes: A performance evaluation unit is used to calculate the priority score of each supplier based on the real-time performance indicators; The traffic allocation execution unit is used to allocate user sessions to the corresponding target vendors based on the priority scores of each vendor and the preset traffic allocation ratio for new users using a hash algorithm; for existing users, it directly recommends vendors that they have successfully used in the past.

6. The intelligent recommendation system for e-commerce payment methods based on multi-dimensional decision-making according to claim 1, characterized in that: The risk control collaborative filter communicates with a third-party risk control system to send user context information and order information to the third-party risk control system and receive the risk level judgment result returned by it; wherein, for transactions judged as high-risk, the preset high-risk payment methods are hidden or downgraded in the final recommendation list.

7. The intelligent recommendation system for e-commerce payment methods based on multi-dimensional decision-making as described in claim 6, characterized in that: It also includes a risk control backup processing unit, which is used to automatically activate the risk control strategy provided by the payment provider or force the user to perform 3D security verification when the third-party risk control system times out or malfunctions.

8. The intelligent recommendation system for e-commerce payment methods based on multi-dimensional decision-making according to claim 1, characterized in that: The payment decision feedback module also includes a self-learning unit, which records the processing results corresponding to different payment failure reasons and dynamically optimizes the secondary recommendation strategy or risk handling rules after payment failure.

9. A smart recommendation method for e-commerce payment methods based on multi-dimensional decision-making, applied to the system as described in any one of claims 1 to 8, characterized in that, Includes the following steps: Step S1: In response to the user entering the checkout page, obtain the user's context information through the data collection and context awareness module; Step S2: Using the region matching filter, based on the geographical location information in the context information, select matching payment methods from the payment method candidate pool to generate a first payment method list; Step S3: Using a supplier selector, select the best supplier for the same payment type from the first payment method list based on real-time performance indicators and traffic splitting rules, and generate a second payment method list; Step S4: Using the device adapter enhancer, the priority of the second payment method list is adjusted according to the device type information in the context information to generate a third payment method list; Step S5: Using a risk control collaborative filter, perform security filtering on the list of third payment methods based on the risk assessment results, and generate and output the final recommendation list; Step S6: Display the final recommendation list on the checkout page using the recommendation list rendering module; Step S7: Monitor payment results and update performance indicators through the payment decision feedback module. If payment fails, perform secondary recommendations or risk management based on the reason for failure.

10. The intelligent recommendation method for e-commerce payment methods based on multi-dimensional decision-making as described in claim 9, characterized in that: The risk assessment results mentioned in step S5 are obtained by sending user context information and order information to a third-party risk control system; the security filtering includes: for high-risk transactions, hiding at least one of the payment methods, either credit card or digital wallet, in the recommendation list; When the third-party risk control system responds abnormally, it automatically switches to the risk control verification process provided by the payment provider.

Images