Mobile payment multi-channel dynamic strategy adaptation method and system

Abstract

The application relates to the technical field of mobile payment, and more particularly to a mobile payment multi-channel dynamic strategy adaptation method and system. The method comprises the following steps: a four-dimensional routing network is constructed by an application configuration layer, double access rules are configured, a dynamic routing rule library is generated and delivered; a core service layer receives a payment request, analyzes transaction characteristics, completes basic permission filtering based on the dynamic routing rule library, and obtains an available candidate channel set; based on a multi-dimensional dynamic weight model, weight score calculation is performed on each channel in the candidate channel set, a candidate channel list is generated according to the score, and based on the candidate channel list, multi-objective optimization is performed in combination with a Pareto frontier algorithm, layered traffic distribution is completed, the traffic distribution ratio of a main channel, a backup channel and a long tail channel is determined, and payment transactions are executed through an infrastructure layer and a channel adaptation layer; when preset fuse rules are triggered, automatic channel switching is completed, and the parameters of the dynamic weight model are updated.

Description

Technical Field

[0001] This invention relates to the field of mobile payment technology, and more specifically to a method and system for adapting multi-channel dynamic strategies in mobile payment. Background Technology

[0002] With the diversification of mobile payment scenarios using electronic social security cards and the continuous growth of transaction volume, the system needs to connect to payment channels of various financial institutions such as UnionPay, banks, and third-party payment platforms (e.g., WeChat Pay, Alipay). The rigid channel selection, delayed anomaly handling, and high expansion costs of traditional aggregated payment systems are gradually becoming core issues, placing higher demands on the real-time performance, stability, and flexibility of the payment system. These three bottlenecks include: 1. Fragmented Interface Specifications. Significant differences exist in the technical standards across different channels. For example, UnionPay uses XML messages while some banks use JSON; encryption algorithms mix RSA and the national standard SM2; and asynchronous callback mechanisms are inconsistent (synchronous responses and asynchronous notifications coexist). This results in the need to repeatedly develop adaptation logic for the same function (such as payment and refund), leading to code redundancy exceeding 90%, and maintenance costs increasing by an O(N²) level with the number of channels.

[0003] 2. Rigid routing strategies. Traditional solutions rely on preset rules (such as polling or hard coding), which cannot dynamically respond to real-time metrics (such as success rate and response time). Multi-dimensional metrics (cost, load, user preferences) are fragmented. For example, government scenarios may force priority to UnionPay channels (for fund supervision compliance), while bank apps allow higher single transaction limits. However, the system lacks a comprehensive weighting calculation mechanism, making it difficult to balance efficiency and cost.

[0004] 3. Lack of self-healing in case of anomalies. Channel failures (such as network fluctuations or sudden load increases) require manual switching, with response delays exceeding 200ms, leading to a surge in payment failure rates. Adding new channels has a long cycle (an average of 21 person-days), and downtime for updates impacts business continuity, making it difficult to maintain system availability above 99.9%.

[0005] Therefore, how to provide a method and system for adapting multi-channel dynamic strategies for mobile payments is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0006] In view of this, the present invention provides a method and system for adapting multi-channel dynamic strategies for mobile payment, aiming to solve the above-mentioned technical problems.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: A method for adapting multi-channel dynamic strategies in mobile payment includes the following steps: S1. The application configuration layer constructs a four-dimensional routing network of payment channel-product-merchant-channel, completes the hierarchical management of payment channel and the dual access rule configuration of merchant-channel, and generates and distributes a dynamic routing rule library; S2. The core service layer receives the payment request, parses the transaction characteristics, and completes basic permission filtering based on the dynamic routing rule base to obtain a set of available candidate channels. S3. Based on a preset multi-dimensional dynamic weight model, calculate the weight score for each channel in the candidate channel set, and generate a candidate channel list by sorting the scores. S4. Based on the candidate channel list, multi-objective optimization is performed using the Pareto front algorithm to complete hierarchical traffic allocation, determine the traffic ratio of the main channel, alternative channels, and long-tail channels, and execute payment transactions through the infrastructure layer and channel adaptation layer. S5. Monitor the operating status of each payment channel in real time. When the preset circuit breaker rule is triggered, automatically switch the channel and update the parameters of the dynamic weight model to achieve self-healing of anomalies.

[0008] Furthermore, the core indicators of the multi-dimensional dynamic weight model include transaction success rate. Response time Fee Costs Channel load User preferences The corresponding weighting coefficients are respectively , , , , The formula for calculating the weighted score is: .

[0009] Furthermore, the specific rules for the hierarchical traffic allocation are as follows: The channel with the highest weight score and a transaction success rate of ≥98% will be designated as the main channel, and 70% of the transaction traffic will be allocated to it. Channels with the second-best weight score and a channel load rate of ≤60% will be designated as alternative channels and allocated 20% of the transaction traffic. Newly connected or gray-scale testing channels are designated as long-tail channels, and 10% of the transaction traffic is allocated to them. The multi-objective optimization rule of the Pareto front algorithm is as follows: if the difference in transaction success rate between the two channels is ≤1%, the channel with the lower fee rate is preferred; if the difference in fee rate between the two channels is ≤0.1%, the channel with the lower load rate is preferred.

[0010] Furthermore, the preset circuit breaker rule is that the circuit breaker is triggered when the channel times out three times consecutively or the transaction success rate is less than 95%, and the channel switching time is ≤50ms. The anomaly self-healing adopts a two-level circuit breaker mechanism: service-level circuit breaker, which means that when the current channel is abnormal and there is a backup channel, it automatically switches to the backup route and asynchronously detects the health status of the original channel; system-level circuit breaker, which means that when there is no available channel, it triggers a monitoring alarm and returns a user-friendly prompt. After the fault channel triggers the fuse, it enters a preset cooling period, and at the same time, the weight coefficients of the dynamic weight model are dynamically adjusted based on real-time monitoring data.

[0011] Furthermore, the channel adaptation layer adopts a plug-in architecture design. New payment channel extensions correspond to channel adapter implementation classes and are injected into the Spring container. There is no need to modify the core transaction logic. The adapter instance is dynamically loaded through Java reflection mechanism, and hot updates are achieved in combination with the routing rules issued by the configuration center.

[0012] Furthermore, channel switching records, dynamic weight calculation results, and abnormal events are all recorded and stored on the Hyperledger Fabric blockchain platform.

[0013] A mobile payment multi-channel dynamic strategy adaptation system includes an application configuration layer, a core service layer, an infrastructure layer, and a channel adaptation layer that are connected in sequence. The application configuration layer is used to build a four-dimensional routing network of payment channel-product-merchant-channel, complete the hierarchical management of payment channel, configure the dual access rules of merchant-channel, and generate and distribute a dynamic routing rule library. The core service layer is used to receive payment requests and parse transaction features, complete basic permission filtering based on the dynamic routing rule base to obtain a set of available candidate channels, calculate the weight score of each candidate channel through a preset multi-dimensional dynamic weight model, complete hierarchical traffic allocation in combination with Pareto front algorithm, and perform channel circuit breaking and abnormal self-healing control. The infrastructure layer is used to provide a standardized execution framework, which abstracts payment, refund, and query services into standardized processing units through a service card slot system, and completes transaction execution, full-link monitoring and asynchronous callback processing. The channel adaptation layer is used to complete protocol conversion, encryption adaptation and connection management through dynamically loaded channel adapters, so as to achieve standardized interaction with various external payment channels.

[0014] Furthermore, the core service layer incorporates an intelligent decision-making engine, employing a three-layer filtering mechanism to complete routing decisions: The first layer is permission filtering, which loads dual rules for merchant signed product permissions and channel whitelist to complete basic filtering; The second layer is weight calculation, which calculates the weight score of each candidate channel based on a multi-dimensional dynamic weight model; The third layer is the decision output, which generates a Top-3 candidate channel list by sorting the scores according to their weights, and completes the traffic allocation and payment execution.

[0015] Furthermore, the channel adapter of the channel adaptation layer includes an interface conversion module, a security adaptation module, and a protocol support module; The interface conversion module is used to dynamically reorganize standardized business parameters according to the message specifications of the target channel, and is compatible with XML, JSON and ISO8583 message formats. The security adaptation module is used to dynamically switch encryption algorithms and certificate systems according to channel characteristics, and supports automatic switching between RSA and the national cryptographic SM2 algorithm; The protocol support module is compatible with HTTP / HTTPS short connections, TCP long connections and private protocols, and has a built-in intelligent heartbeat detection mechanism that detects heartbeats every 30 seconds. If no response is received three times in a row, the session will be rebuilt automatically.

[0016] Furthermore, the asynchronous callback processor in the infrastructure layer listens to the MQ messages of the external payment channel, updates the order status after receiving the payment result; for transactions that have not received a callback for more than 30 seconds, the system actively initiates a query command to confirm the final state of the transaction, ensuring the consistency of transaction data; each standardized processing unit has a built-in monitoring component to track transaction time and success rate indicators in real time and dynamically capture abnormal events.

[0017] Compared to existing technologies, this invention separates business logic from technology through standardized core modules (such as transaction routing and parameter verification), achieving a standardization rate of 95%. It supports plug-in channel access, reducing the development cycle for new channels to 0.5 person-days, with hot updates taking effect (<1 second). A multi-dimensional dynamic weight model is designed, integrating indicators such as success rate, response time, and fee rate, and combining Pareto frontier algorithms to achieve cost-success rate balance. It supports scenario awareness (e.g., increasing the fee rate weight to 0.4 for e-commerce payments), and hierarchical scheduling of traffic allocation based on main channels (70%), backup channels (20%), and long-tail channels (10%). A 50ms-level circuit breaker switching mechanism is introduced, automatically routing to backup channels based on real-time monitoring (e.g., success rate <95% for 5 minutes). Abnormal events are documented through blockchain, ensuring system availability ≥99.99% and reducing overall operation and maintenance costs by 40%. Attached Figure Description

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

[0019] Figure 1 This is a schematic diagram of an adaptation strategy system architecture according to the present invention.

[0020] Figure 2 This is a schematic diagram of a dynamic decision-making process according to the present invention.

[0021] Figure 3 This is a breakdown diagram of an intelligent routing process according to the present invention.

[0022] Figure 4 This is a schematic diagram of a payment execution process according to the present invention.

[0023] Figure 5 This is a logic diagram of a card slot engine according to the present invention. Detailed Implementation

[0024] The technical solutions in the embodiments of the present invention will be clearly and completely described below. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] The mobile payment multi-channel dynamic strategy adaptation system of the present invention adopts a layered decoupling design, and the overall architecture is as follows: Figure 1 As shown, it consists of a four-level structure: application configuration layer, core service layer, infrastructure layer, and channel adaptation layer, achieving separation of business logic and technical implementation, with a standardization rate of 95%. The specific implementation methods of each layer are as follows: 1. Application Configuration Layer The application configuration layer serves as the cornerstone of dynamic routing, constructing a four-dimensional dynamic routing network encompassing payment channels, products, merchants, and distribution channels. This enables visualized configuration and real-time application of rules across the entire link. The specific implementation is as follows: Payment channel hierarchical management: UnionPay, banks and other institutions are defined as primary channels, and secondary channels (such as ICBC digital RMB and ICBC debit cards) are attached under the primary channels to form a "head-to-branch" service network; each channel is bound to service types such as payment, refund and query through the configuration management module and associated with the corresponding Spring Bean (such as mapping the ICBC digital RMB channel to ICBCXXXAdapter) to achieve decoupling of technical specifications and business instances.

[0026] Payment product matrix configuration: Define standardized payment method templates (such as WeChat H5, Alipay App), and support merchants to flexibly combine product packages through many-to-many configuration.

[0027] Merchant-channel dual access mechanism: After the merchant passes the qualification review, the merchant is forcibly bound to a three-level permission of "merchant → primary channel → product" (e.g., merchant A is only allowed to use the UnionPay channel); on the channel side, the local social security app and other entrances set up a channel whitelist (e.g., only the UnionPay channel and its designated secondary channels are allowed), forming the first layer of risk control filtering.

[0028] Real-time rule delivery and activation: The configuration rule engine pushes data such as channel permissions and rate policies to the core service layer in real time, providing a dynamic rule base for routing decisions; operations such as channel switching and rate adjustment can take effect in seconds, and hot update takes effect in less than 1 second, and configuration changes can be completed without downtime.

[0029] 2. Core Service Layer The core service layer is the system's intelligent decision-making engine, which includes a three-layer filtering mechanism and a two-level circuit breaker mechanism, as implemented as follows: The three-layer filtering routing decision mechanism is as follows: The first layer loads dual rules (merchant's signed product permissions + channel whitelist) to complete basic permission filtering; the second layer dynamically calculates the optimal weight of each candidate channel based on a dynamic weight model; and the third layer generates a Top-3 candidate channel list through intelligent routing decision to complete traffic allocation and payment execution.

[0030] Two-level circuit breaker mechanism: First, business-level circuit breaker: if the current channel is abnormal but there is an alternative channel, it will automatically switch to the backup route (such as switching from the ICBC channel to the ABC channel) and retry the health status check of the original channel through an asynchronous thread; Second, system-level circuit breaker: when there is no available channel, it will immediately send a red highlighted alarm to the monitoring component and return a user-friendly prompt "Payment channel is under maintenance, please try again later".

[0031] 3. Infrastructure Layer The infrastructure layer, serving as the standardized execution foundation of the system, transforms the abstract instructions of the core service layer into concrete channel interaction operations through a service card slot system and asynchronous callback handlers. The specific implementation is as follows: Service Slot System: Payment, refund, and inquiry services are abstracted into standardized processing units. Payment requests enter the order payment slot for amount verification and transaction registration, while refund operations are routed to the refund management slot to complete the reverse fund flow. Each slot has a built-in monitoring component that tracks key indicators such as transaction time (e.g., payment slot timeout threshold of 5000ms) and success rate in real time. An anomaly monitoring module dynamically captures abnormal events such as message format errors and signature verification failures. When a channel success rate of less than 50% or continuous timeouts are detected, the system automatically triggers a circuit breaker, switching transaction traffic to a backup channel and marking the faulty channel for a default 30-minute cooldown period.

[0032] Asynchronous callback processor: Listens for MQ messages from the bank channel, updates the order status after receiving the payment result, and drives the accounting system to record the transaction; for transactions that have not been callbackd within 30 seconds, the system actively initiates a query command to confirm the final state of the transaction, ensuring the consistency of transaction data.

[0033] 4. Channel Adaptor Layer The channel adaptation layer, acting as the system's protocol conversion hub, achieves "one-to-many" interface adaptation capabilities through a dynamic loading mechanism. It serves as a crucial bridge connecting the core service layer and external payment channels, and its implementation is as follows: Interface conversion module: Based on the message specifications of the target channel (such as UnionPay ISO8583 format, WeChat XML structure), it dynamically reorganizes unified parameters such as the four elements and amount, and supports field mapping, format verification and encoding conversion.

[0034] Security adaptation module: Dynamically switches encryption algorithms and certificate systems according to channel characteristics. For direct bank connection channels, it automatically loads the SM2 certificate issued by CFCA to complete the signature and uses the national cryptographic algorithm to encrypt the message end-to-end. For third-party payment channels, it switches to the RSA algorithm and ensures encryption strength through a key rotation mechanism, while also being compatible with the HTTPS two-way authentication process.

[0035] Protocol support modules: compatible with HTTP / HTTPS short connections, TCP long connections and UnionPay CUPS private protocol, optimizes resource reuse rate through connection pool management; built-in intelligent heartbeat detection mechanism, sends heartbeat packets to TCP long connection channels every 30 seconds, and if no response is received three times in a row, automatically triggers the session reconstruction process, improving the channel call success rate to over 99.95%.

[0036] Plug-in extension architecture: Adding a new payment channel only requires extending the corresponding adapter implementation class and injecting it into the Spring container. There is no need to modify the core transaction logic. The system dynamically loads the adapter instance through Java reflection at runtime, and the routing rules issued by the configuration center take effect in real time. This mechanism reduces the channel extension cycle from 21 person-days in the traditional solution to 0.5 person-days, while also supporting canary releases and hot updates.

[0037] like Figure 2 The diagram illustrates the dynamic decision-making process of this invention, implemented based on the aforementioned system, and specifically includes the following steps: 1. Routing rule initialization steps The application configuration layer completes the hierarchical configuration of payment channels, product template configuration, and merchant-channel dual access rule configuration, builds a four-dimensional routing network, generates a dynamic routing rule base and distributes it to the core service layer, and completes system initialization.

[0038] 2. Transaction Request Reception and Basic Filtering Steps The core service layer receives payment requests initiated by users, parses transaction characteristics (including transaction amount, transaction type, transaction location, and user information), and, based on a dynamic routing rule base, excludes channels that do not support the current transaction type, have regional restrictions, or do not comply with merchant-channel access rules, thus obtaining a set of available candidate channels.

[0039] 3. Dynamic Calculation Steps for Channel Weights Based on a pre-defined multi-dimensional dynamic weighting model, weight scores are calculated for each channel in the candidate channel set, and a Top-3 candidate channel list is generated by sorting the scores from high to low. The specific implementation is as follows: Table 1 Candidate Channel List

[0040] Dynamic weight formula: ; Parameter application rules: 1. Dynamic adjustment of coefficients: The system presets initial weight coefficients based on channel type and scenario (e.g., e-commerce channel, high-concurrency channel). The initial value is set to 0.4. High-concurrency channels require faster response times, so the initial coefficient is preset. It can be set higher. The coefficient is fine-tuned every 5 minutes based on real-time monitoring data: if the success rate of a certain channel is lower than 95% for 10 consecutive transactions, its success rate weight is reduced. Up to the lower limit (0.3) 2. Weight Calculation Process Step 1: Data Acquisition: Real-time acquisition of channel transaction logs and heartbeat detection data, updated every 5 seconds.

[0041] Second step in calculating the indicator: Success rate The sliding window displays statistics on all transactions within the last 5 seconds, including the success rate of transactions across different channels; response time. : Take the average of the last 50 transactions; User preferences : The percentage of users who selected this channel in the past 30 days.

[0042] Step 3: Weight Score Generation: Substitute into the dynamic weight formula for calculation. The Top-3 candidate channels are generated by sorting them by score.

[0043] Intelligent routing decision-making mechanism 1. Layered Filtering and Traffic Allocation The first step is basic filtering: excluding channels that do not support the current transaction type (such as e-commerce, large transactions) or have regional restrictions. The second step is dynamic sorting: a Top-3 candidate list is generated based on weighted scores, and the Pareto front algorithm (which generates a multi-objective optimization solution set) is used to balance success rate and cost. If the success rate difference between the two channels is ≤1%, the channel with the lower fee should be selected first. If the rate difference is ≤0.1%, the channel with the lower load rate will be selected first.

[0044] The third step is traffic allocation, as shown in Table 2: Table 2 Flow Allocation

[0045] Abnormal handover and closed-loop detection Circuit breaker rules: If three consecutive responses time out (threshold ≤ 200ms) or the success rate is < 95%, a switch to the suboptimal channel is triggered; the switchover time is ≤ 50ms, imperceptible to the user. After the circuit breaker switchover, the system automatically updates the sliding window statistics period (5 seconds / 100 transactions) and recalculates the success rate. With response time This ensures that the dynamic weight model takes effect in real time.

[0046] Closed-loop detection mechanism: Step 1: Control Channel Inspection (Pre-inspection Phase) Triggering condition: Before the payment request enters the intelligent routing engine, the system obtains the real-time status of the channel through the "Indicator Collection" module.

[0047] Detection actions: Send heartbeat detection data packets (such as HTTP HEAD requests or ICMP messages) to the target channel through the control channel; detection metrics include response time (≤200ms), success rate (≥99.5%!), and connection stability (no packet loss).

[0048] Step 2: Determining the Test Results Detection successful: The control channel returns a normal response, allowing the transmission of payment messages through this channel.

[0049] Detection failure (timeout, packet loss, or error code): Triggers the following actions: Marks the channel as "abnormal state", updates the "load monitoring" and "success rate / cost optimization" modules of the core decision-making layer; and switches to the backup data channel; the channel switching record is uploaded to the blockchain in real time (blockchain evidence storage module), supporting audit traceability.

[0050] Implementation Case: Scenario: During the operation, the load rate of the main channel (UnionPay) suddenly increased to 70%, and the response time rose to 250ms.

[0051] deal with: The system detected three consecutive timeouts and triggered a circuit breaker; it switched to the backup channel (Alipay) and allocated 70% of the traffic; it updated the weight score, deducting 0.1 from the weight of the UnionPay channel Li, and the score dropped to 0.78.

[0052] Abnormal self-healing Real-time monitoring and dynamic weight adjustment are shown in Table 3: Table 3

[0053] Security Mechanism Blockchain-based evidence storage: Channel switching records and weight calculation results are uploaded to the blockchain (Hyperledger Fabric), supporting auditing, traceability, and dynamic decision-making processes, such as... Figure 2 As shown.

[0054] Payment execution process like Figure 4 The diagram shows the payment execution process architecture. The system adopts a layered and decoupled design to isolate business logic from the payment channel. The key modules are as follows: 1. Channel Access Layer (User End): Payment entry points such as local government apps, Alipay, and WeChat mini programs, responsible for initiating standardized payment request messages (including merchant ID, channel ID, and order amount).

[0055] 2. Cashier middleware: Dynamically generates payment interface, aggregates payment methods and user card binding information, and implements the first layer of risk control interception (such as single transaction limit verification).

[0056] 3. Routing Decision Engine: Includes Merchant Configuration Parser (loads product permissions), Channel Permission Verifier (whitelist filtering), and Payment Channel Routing Calculator (rule engine); adopts a three-level routing strategy: Merchant signed product → Available channel → User card binding matching (card BIN identification).

[0057] 4. Payment Channel External Gateway: Implements protocol conversion and dynamically loads channel adapters (matching Spring container instances via BeanName). Performs encryption and data masking (processing card numbers using the SM4 algorithm) and message assembly (generating request data according to the channel template).

[0058] The payment process begins with a user submitting an order through channels such as a government affairs app, triggering a payment request containing the merchant ID, channel ID, order amount, and user ID. After receiving the request via the HTTP interface, the system first performs a message compliance check. If the message does not conform to the "Payment Interface Specification V3.2," an E1001 error code is returned to intercept the abnormal request. After successful verification, the cashier service dynamically renders the payment interface, generating an option list based on available payment methods returned by the routing engine (such as UnionPay, WeChat Pay, and linked social security card accounts). Simultaneously, the user card management module is called to load linked card information, filtering invalid cards (such as debit cards that do not support e-commerce payments) through card BIN identification. Sensitive fields such as card number and expiration date are anonymized on the front end (e.g., displayed as 6228****5678) to ensure user privacy and security.

[0059] Upon entering the routing decision phase, the system loads merchant-side and channel-side configuration rules in parallel: It retrieves the merchant's contracted payment products (such as UnionPay QuickPay) and bound primary channel permissions through a Redis cluster cache (response time <5ms), while simultaneously verifying whether the current channel allows the use of the target channel (e.g., government apps restricting the use of non-UnionPay channels). Based on the intersection of these two rules, the DBC rule engine comprehensively considers the user-selected card BIN (e.g., Agricultural Bank of China cards starting with 622848), order type (e.g., online payment), and real-time channel weights (success rate accounting for 60%, fee cost accounting for 40%) to calculate the optimal channel ID (e.g., UnionPay channel weight = 0.95 × 0.6 + 0.2 × 0.4 = 0.65), driving subsequent processes.

[0060] After the payment instruction enters the channel adaptation layer, the adapter for the target channel is dynamically loaded, converting standardized parameters into a channel-specific format: the UnionPay channel converts the amount to cents and encapsulates it into an ISO8583 message, using SM2 algorithm signature and SM3 digest; the WeChat channel converts it to a JSON structure and transmits it encrypted via HTTPS two-way authentication. After the external gateway calls the bank's interface, it listens for asynchronous callback results in real time via MQ messages. Upon success, it updates the order status and triggers T+1 reconciliation; if there is a 30-second timeout, it actively queries the final status. If the channel is abnormal (e.g., success rate <50% or TPS >10), the circuit breaker mechanism automatically switches to a backup channel and marks the faulty channel for cooling, ensuring a payment success rate of no less than 99.95%. Thus, the end-to-end link from user request to result feedback forms a closed loop, balancing efficiency, security, and stability.

[0061] like Figure 5The diagram shows the logic of the card slot engine. The payment system's engine entry point is centered on standardized business card slots, using a factory pattern combined with a strategy pattern to achieve dynamic routing and scheduling of payment channels. As the core service class, it is declared as a Spring-managed Bean using `@Service("XXXPayBPOImpl")`, and the `@Primary` annotation ensures it is the default injected object, uniformly handling standardized business operations such as payment, query, and refund. Business methods (such as `pay()`) dynamically load channel adapter instances (such as UnionPay XXXPayAdapter) based on the `channelId` through the `PayChannelFactory` factory injected via `@Resource`. Combined with the dependency lookup (DL) mechanism of the Spring IOC container, this achieves complete decoupling between business logic and channel implementation. This architecture, based on the runtime instance loading capability of Spring BeanFactory, supports hot-update routing strategies—channel configuration changes (such as adding XXXAdapter or adjusting encryption algorithms) can take effect within seconds (<1 second) through the configuration center, without requiring a service restart. Through a hybrid architecture design (factory pattern for managing instance creation, strategy pattern for encapsulating channel differences, and dynamic routing for determining the optimal path), the system can quickly expand payment channels (e.g., adding a new e-commerce payment channel only requires implementing the interface) while ensuring the high efficiency and stability of the core transaction chain, meeting the 99.99% availability requirement under high concurrency scenarios.

[0062] The core modules are as follows: Business service layer (XXXPayBPOImpl, i.e., standard card slot implementation) Positioning: The core payment entry point, handling payment, inquiry, and refund requests in a unified manner.

[0063] Dependency Injection: The dynamic routing factory generates specific channel instances based on the channelId.

[0064] RedisTemplate: Caches high-frequency data (such as channel configuration and transaction status).

[0065] Separation of duties: Standardized payment operations are defined through the XXXPayBPO interface, shielding the underlying differences between different payment channels. This decouples business logic from channel implementation.

[0066] Dynamic routing factory (PayChannelFactory.createPayChannel) Core logic: Enter the channelId (e.g., ALIPAY, UNIONPAY) and call findBeanName to get the Spring Bean name (e.g., XXXAdapter).

[0067] The channel implementation class is dynamically loaded using beanFactory.getBean().

[0068] Design Highlights: Configurable routing: The mapping between channel IDs and BeanNames can be updated dynamically (via Redis or a database).

[0069] Decoupling capability: Adding a new channel only requires implementing the interface and registering the Bean, without modifying the core logic.

[0070] Channel configuration service (findChannelBeanName method) Multi-level caching mechanism: Local caching: After the first query, the channelId→beanName is stored in Redis (valid for 60 minutes).

[0071] Remote call fallback: If the cache is not hit, the latest mapping relationship is obtained by calling the configuration center through payChannelClient.

[0072] Dynamically applied: When the configuration changes, new requests automatically load the latest BeanName (without needing to restart the service).

[0073] Channel implementation layer (UnionXXXPayChannel, etc.) Strategy pattern application: Each channel (such as UnionPay, Alipay) independently implements the XXXPayBPO interface.

[0074] Component-based registration: Declare it as a Spring Bean using @Component("UnionXXXPayChannel"), and support dynamic loading by name.

[0075] Dependency management: Use @Reference (Dubbo service reference) and @Autowired to integrate external services (such as risk control modules).

[0076] Its key workflow is the channel access process: Technology adaptation phase (3 days): Development of payment adapter implementation class Configure channel parameters: encryption key, channel call URL, callback URL, reconciliation method The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0077] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for adapting multi-channel dynamic strategies in mobile payment, characterized in that, Includes the following steps: S1. The application configuration layer constructs a four-dimensional routing network of payment channel-product-merchant-channel, completes the hierarchical management of payment channel and the dual access rule configuration of merchant-channel, and generates and distributes a dynamic routing rule library; S2. The core service layer receives the payment request, parses the transaction characteristics, and completes basic permission filtering based on the dynamic routing rule base to obtain a set of available candidate channels. S3. Based on a preset multi-dimensional dynamic weight model, calculate the weight score for each channel in the candidate channel set, and generate a candidate channel list by sorting the scores. S4. Based on the candidate channel list, multi-objective optimization is performed using the Pareto front algorithm to complete hierarchical traffic allocation, determine the traffic ratio of the main channel, alternative channels, and long-tail channels, and execute payment transactions through the infrastructure layer and channel adaptation layer. S5. Monitor the operating status of each payment channel in real time. When the preset circuit breaker rule is triggered, automatically switch the channel and update the parameters of the dynamic weight model to achieve self-healing of anomalies.

2. The mobile payment multi-channel dynamic strategy adaptation method according to claim 1, characterized in that, The core metrics of the multi-dimensional dynamic weight model include transaction success rate. Response time Fee Costs Channel load User preferences The corresponding weighting coefficients are respectively , , , , The formula for calculating the weighted score is: 。 3. The mobile payment multi-channel dynamic strategy adaptation method according to claim 1, characterized in that, The specific rules for the hierarchical traffic allocation are as follows: The channel with the highest weight score and a transaction success rate of ≥98% will be designated as the main channel, and 70% of the transaction traffic will be allocated to it. Channels with the second-best weight score and a channel load rate of ≤60% will be designated as alternative channels and allocated 20% of the transaction traffic. Newly connected or gray-scale testing channels are designated as long-tail channels, and 10% of the transaction traffic is allocated to them. The multi-objective optimization rule of the Pareto front algorithm is as follows: if the difference in transaction success rate between the two channels is ≤1%, the channel with the lower fee rate is preferred; if the difference in fee rate between the two channels is ≤0.1%, the channel with the lower load rate is preferred.

4. The mobile payment multi-channel dynamic strategy adaptation method according to claim 1, characterized in that, The preset circuit breaker rule is that the circuit breaker is triggered when the channel times out three times in a row or the transaction success rate is less than 95%, and the channel switching time is ≤50ms. The anomaly self-healing adopts a two-level circuit breaker mechanism: service-level circuit breaker, which means that when the current channel is abnormal and there is a backup channel, it automatically switches to the backup route and asynchronously detects the health status of the original channel; system-level circuit breaker, which means that when there is no available channel, it triggers a monitoring alarm and returns a user-friendly prompt. After the fault channel triggers the fuse, it enters a preset cooling period, and at the same time, the weight coefficients of the dynamic weight model are dynamically adjusted based on real-time monitoring data.

5. The mobile payment multi-channel dynamic strategy adaptation method according to claim 1, characterized in that, The channel adaptation layer adopts a plug-in architecture design. New payment channels are extended to include corresponding channel adapter implementation classes and injected into the Spring container. No modification to the core transaction logic is required. The adapter instance is dynamically loaded through Java reflection mechanism, and hot updates are achieved in combination with the routing rules issued by the configuration center.

6. The mobile payment multi-channel dynamic strategy adaptation method according to claim 1, characterized in that, Channel switching records, dynamic weight calculation results, and abnormal events are all recorded and stored on the Hyperledger Fabric blockchain platform.

7. A mobile payment multi-channel dynamic strategy adaptation system, applicable to any of the mobile payment multi-channel dynamic strategy adaptation methods described in claims 1-6, characterized in that, This includes the application configuration layer, core service layer, infrastructure layer, and channel adaptation layer, which are connected sequentially. The application configuration layer is used to build a four-dimensional routing network of payment channel-product-merchant-channel, complete the hierarchical management of payment channel, configure the dual access rules of merchant-channel, and generate and distribute a dynamic routing rule library. The core service layer is used to receive payment requests and parse transaction features, complete basic permission filtering based on the dynamic routing rule base to obtain a set of available candidate channels, calculate the weight score of each candidate channel through a preset multi-dimensional dynamic weight model, complete hierarchical traffic allocation in combination with Pareto front algorithm, and perform channel circuit breaking and abnormal self-healing control. The infrastructure layer is used to provide a standardized execution framework, which abstracts payment, refund, and query services into standardized processing units through a service card slot system, and completes transaction execution, full-link monitoring and asynchronous callback processing. The channel adaptation layer is used to complete protocol conversion, encryption adaptation and connection management through dynamically loaded channel adapters, so as to achieve standardized interaction with various external payment channels.

8. A mobile payment multi-channel dynamic strategy adaptation system according to claim 7, characterized in that, The core service layer has a built-in intelligent decision-making engine and uses a three-layer filtering mechanism to complete routing decisions: The first layer is permission filtering, which loads dual rules for merchant signed product permissions and channel whitelist to complete basic filtering; The second layer is weight calculation, which calculates the weight score of each candidate channel based on a multi-dimensional dynamic weight model; The third layer is the decision output, which generates a Top-3 candidate channel list by sorting the scores according to their weights, and completes the traffic allocation and payment execution.

9. A mobile payment multi-channel dynamic strategy adaptation system according to claim 7, characterized in that, The channel adapter of the channel adaptation layer includes an interface conversion module, a security adaptation module, and a protocol support module; The interface conversion module is used to dynamically reorganize standardized business parameters according to the message specifications of the target channel, and is compatible with XML, JSON and ISO8583 message formats. The security adaptation module is used to dynamically switch encryption algorithms and certificate systems according to channel characteristics, and supports automatic switching between RSA and the national cryptographic SM2 algorithm; The protocol support module is compatible with HTTP / HTTPS short connections, TCP long connections and private protocols, and has a built-in intelligent heartbeat detection mechanism that detects heartbeats every 30 seconds. If no response is received three times in a row, the session will be rebuilt automatically.

10. A mobile payment multi-channel dynamic strategy adaptation system according to claim 7, characterized in that, The asynchronous callback processor in the infrastructure layer listens to the MQ messages of the external payment channel and updates the order status after receiving the payment result. For transactions that have not received a callback for more than 30 seconds, the system actively initiates a query command to confirm the final state of the transaction and ensure the consistency of transaction data. Each standardized processing unit has a built-in monitoring component to track transaction time and success rate indicators in real time and dynamically capture abnormal events.

Images