Payment processing method and device, electronic equipment, storage medium and program product
By employing intelligent channel identification and standardized protocol conversion payment processing methods, the problems of system complexity and high maintenance costs caused by multiple payment channel access are solved, enabling flexible management and rapid response capabilities for payment channels.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- LINGGU LIUGUANG TECHNOLOGY (NANJING) CO LTD
- Filing Date
- 2025-12-18
- Publication Date
- 2026-05-05
AI Technical Summary
Existing technologies lead to complex system architecture, redundant functions, and redundant code when multiple payment channels are integrated, resulting in high maintenance costs. Furthermore, adding, removing, or changing payment channels requires significant code modifications, leading to long development cycles, high error risks, and difficulty in adapting to rapidly changing payment business needs.
By receiving the original payment request containing payment information, the system intelligently determines the target payment channel (if the channel information is included, it is determined directly; otherwise, it is determined according to preset rules), and uses a preset protocol conversion strategy to convert the request into a request adapted to the target payment channel, and finally calls the channel to complete the payment.
It has achieved unified and automated management of payment channel access, reduced system complexity and redundant development costs, improved system maintainability and scalability, shortened development cycle, reduced error risk, and enhanced adaptability to rapidly changing payment needs.
Smart Images
Figure CN121981718A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a payment processing method, apparatus, electronic device, storage medium, and program product. Background Technology
[0002] With the rapid development of mobile internet and e-commerce, payment has become a core component of various business scenarios. Whether it's e-commerce platforms, online-to-offline (O2O) services, or diverse business models such as cross-border transactions, all need to support users in completing transactions through multiple payment channels, such as accessing mainstream domestic third-party payment tools, bank card payments, and localized overseas payment methods, to meet the payment habits and regional needs of different user groups.
[0003] Currently, when enterprises integrate with multiple payment channels, they typically develop separate adaptation modules for each channel. This results in complex system architecture, redundant functions, and redundant code, leading to high maintenance costs, poor scalability, and management difficulties. Furthermore, adding, removing, or changing payment channels requires significant code modifications, resulting in long development cycles, high error risks, and difficulty in adapting to rapidly changing payment business needs. Summary of the Invention
[0004] This application provides payment processing methods, devices, electronic devices, storage media, and program products to achieve the effects of unified integration with multiple payment channels, reduced system complexity, and improved scalability and maintenance efficiency.
[0005] In a first aspect, embodiments of this application provide a payment processing method, including:
[0006] Receive an original payment request, which contains at least one payment information;
[0007] If the payment information includes channel payment information indicating a payment channel, the target payment channel is determined based on the channel payment information;
[0008] If the payment information does not contain channel payment information indicating the payment channel, the target payment channel is determined according to a preset channel determination rule;
[0009] A preset protocol conversion strategy is used to convert the original payment request into a target payment request adapted to the target payment channel;
[0010] Invoke the target payment channel and complete the payment according to the target payment request.
[0011] In one possible implementation, determining the target payment channel based on the channel payment information includes:
[0012] Obtain the request identifier of the original payment request, and extract the payment channel identifier from the channel payment information;
[0013] Based on the payment channel identifier, or the request identifier and the payment channel identifier, a preset payment channel routing table is queried to determine the target payment channel corresponding to the original payment request.
[0014] In one possible implementation, the target payment channel is determined according to a preset channel determination rule, including at least one of the following methods:
[0015] Obtain the default payment channel and determine the default payment channel as the target payment channel;
[0016] Obtain payment channels with a historical payment success rate higher than a preset threshold, and identify these payment channels as target payment channels;
[0017] The target payment channel is determined based on one or more of the at least one payment information and a preset channel selection strategy.
[0018] In one possible implementation, a preset protocol conversion strategy is used to convert the original payment request into a target payment request adapted to the target payment channel, including:
[0019] Obtain the target protocol conversion strategy corresponding to the target payment channel from the preset protocol conversion strategies;
[0020] According to the target protocol conversion strategy, at least one payment information in the original payment request is format converted and / or parameter mapped to generate a target payment request that meets the requirements of the target payment channel.
[0021] In one possible implementation, invoking the target payment channel and completing the payment according to the target payment request includes:
[0022] When the target payment channel returns a payment failure response, a preset payment retry strategy is obtained;
[0023] According to the payment retry strategy, the backup payment channel will be identified as the new target payment channel;
[0024] Based on the new target payment channel, the payment request conversion and payment invocation process is re-executed until a payment success response is received, at which point the payment is completed.
[0025] In one possible implementation, after receiving the original payment request, the method further includes:
[0026] Based on the at least one payment information, determine whether the original payment request carries any payment risk;
[0027] If it is determined that the original payment request poses a payment risk, then a preset risk handling operation is performed;
[0028] If it is determined that the original payment request does not pose a payment risk, then the step of determining the target payment channel for the original payment request is executed.
[0029] Secondly, embodiments of this application provide a payment processing apparatus, comprising:
[0030] A payment request acquisition module is used to receive an original payment request, wherein the original payment request contains at least one payment information;
[0031] The first channel determination module is used to determine the target payment channel based on the channel payment information when the payment information contains channel payment information indicating the payment channel.
[0032] The second channel determination module is used to determine the target payment channel according to a preset channel determination rule when the payment information does not contain channel payment information indicating the payment channel.
[0033] The payment request conversion module is used to convert the original payment request into a target payment request adapted to the target payment channel using a preset protocol conversion strategy.
[0034] The payment module is used to invoke the target payment channel and complete the payment according to the target payment request.
[0035] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;
[0036] The memory stores computer-executed instructions;
[0037] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.
[0038] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.
[0039] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.
[0040] The payment processing method, apparatus, electronic device, storage medium, and program product provided in this application receive an original payment request containing payment information. Based on whether the payment information includes channel payment information, the system intelligently determines the target payment channel (if included, it is determined directly based on the channel payment information; otherwise, it is determined according to preset rules). Then, using a preset protocol conversion strategy, the original payment request is converted into a target payment request adapted to the target payment channel, and finally, the channel is invoked to complete the payment. This solution, through unified and automated management of payment channel access, reduces the complexity and repetitive development costs caused by independent connection of multiple channels, improving system maintainability and scalability. Simultaneously, intelligent channel determination and standardized protocol conversion mean that adding, removing, or changing payment channels does not require significant modifications to business code, shortening the development cycle, reducing error risks, and enhancing the system's adaptability to rapidly changing payment demands. Attached Figure Description
[0041] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0042] Figure 1 An application scenario diagram of the payment processing method provided in this application;
[0043] Figure 2 A flowchart illustrating the payment processing method provided in this application;
[0044] Figure 3 A schematic diagram of the payment processing device provided in this application;
[0045] Figure 4 This is a block diagram of an electronic device provided in this application.
[0046] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation
[0047] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.
[0048] The collection, storage, use, processing, transmission, provision, and disclosure of financial data or user data involved in the technical solution of this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.
[0049] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of the relevant data shall comply with relevant laws, regulations and standards, and corresponding operation entry points shall be provided for users to choose to authorize or refuse.
[0050] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.
[0051] With the rapid development of mobile internet and e-commerce, payment has become a core component of various business scenarios. Whether it's e-commerce platforms, online-to-offline (O2O) services, or diverse business models such as cross-border transactions, all need to support users in completing transactions through multiple payment channels, such as accessing mainstream domestic payment tools, bank card payments, and localized overseas payment methods, to meet the payment habits and regional needs of different user groups.
[0052] Currently, when enterprises integrate with multiple payment channels, they typically develop separate adaptation modules for each channel. This results in complex system architecture, redundant functions, and redundant code, leading to high maintenance costs, poor scalability, and management difficulties. Furthermore, adding, removing, or changing payment channels requires significant code modifications, resulting in long development cycles, high error risks, and difficulty in adapting to rapidly changing payment business needs.
[0053] To address the aforementioned technical problems, this application provides a payment processing method aimed at resolving them. Specifically, by receiving an original payment request containing payment information, and intelligently determining the target payment channel based on whether the payment information includes channel payment information (if it does, the channel payment information is used directly; otherwise, a preset rule is used), the original payment request is converted into a target payment request adapted to the target payment channel using a preset protocol conversion strategy, and finally, the channel is invoked to complete the payment. This solution achieves unified and automated management of payment channel access, reducing the complexity and repetitive development costs caused by independent connection of multiple channels, and improving the maintainability and scalability of the system. Simultaneously, intelligent channel determination and standardized protocol conversion mean that adding, removing, or changing payment channels does not require significant modifications to business code, shortening the development cycle, reducing the risk of errors, and enhancing the system's adaptability to rapidly changing payment demands.
[0054] The payment processing method provided in this application is applicable to various online transaction and business processing scenarios that require the integration of multiple payment channels.
[0055] For example, in payment scenarios, this method can be used by e-commerce platforms to uniformly handle diverse payment requests from different users, such as simultaneously accessing multiple payment channels including mainstream domestic payment tools, bank card payments, and international payments. It can also be used in online-to-offline (O2O) services, intelligently selecting and calling the corresponding localized payment channels based on the user's location or order type.
[0056] In addition, the above methods can also be applied to cross-border transaction platforms, automatically adapting and routing to the corresponding overseas payment gateway based on the transaction currency, user location, or compliance requirements; they can also be used in enterprise-level unified cashier or payment middleware systems to provide standardized and scalable payment access and management capabilities for multiple business lines within the group.
[0057] In summary, any business system that involves multi-channel payment access and requires unified processing and intelligent routing of payment requests falls under the application scenario of the payment processing technology solution in this application.
[0058] The following is combined Figure 1 The application scenarios applicable to the embodiments of this application are described below. Figure 1 This is a diagram illustrating an application scenario of the payment processing method provided in this application.
[0059] See Figure 1Taking a typical scenario of a user making an online payment through an e-commerce platform as an example, this scenario mainly involves a user device and a payment processing device. The user device initiates an original payment request containing product information, amount, and an identifier of an optional payment channel; the payment processing device, as a server-side system deployed with the technical solution of this application, receives and processes the request and ultimately calls an external payment channel to complete the transaction.
[0060] Based on this, the payment processing technical solution provided in this application mainly includes the following steps:
[0061] 1. The payment processing device receives the original payment request from the user device, which includes at least payment information such as the payment amount and order identifier;
[0062] 2. The payment processing equipment parses the payment information to determine whether it contains channel payment information that clearly indicates the payment channel (such as payment method identifier).
[0063] 3. If payment channel information is included, the target payment channel will be determined directly based on that information; if not, the target payment channel will be intelligently selected based on preset channel determination rules (such as default channels, user historical preferences, channel availability strategies, etc.).
[0064] 4. The payment processing device uses a preset protocol conversion strategy to convert the original payment request into a target payment request that is fully compatible with the interface specifications of the selected target payment channel;
[0065] 5. The payment processing device calls the payment interface of the target payment channel, submits the target payment request, and calls the channel to complete the subsequent payment process.
[0066] The above solution simplifies the payment system architecture, reduces development and maintenance costs, and enhances business expansion flexibility by unifying payment request processing and adapting to intelligent channels.
[0067] It should be understood that in the above scheme, the user equipment and the payment processing equipment can be the same physical or logical device, or they can be different devices connected via a network. This embodiment does not specifically limit this. For example, in integrated applications or local processing scenarios, the user equipment can simultaneously carry out payment initiation and payment processing functions; while in a distributed system architecture, payment processing can be completed by an independent server or cloud service, and the user equipment is only responsible for initiating payment requests and receiving processing results. Regardless of the device deployment, it does not affect the implementation of core processes such as payment channel determination, request conversion, and payment execution in this embodiment.
[0068] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.
[0069] Figure 2 This is a flowchart illustrating the payment processing method provided in this application. The method can be executed by a payment processing device, which can be a server or an electronic device; the following explanation uses an electronic device as an example. The method in this embodiment can be implemented through software, hardware, or a combination of both. Figure 2 As shown, the method includes:
[0070] S201. Receive the original payment request, which contains at least one payment information.
[0071] In this embodiment, the current payment processing device, such as a payment middleware system deployed on a server, receives raw payment requests from the business front end, i.e., shopping applications, web pages, or merchant POS systems on user terminals. Here, the raw payment request can be transmitted through a predefined unified interface and at least contains standardized payment information necessary to complete the payment.
[0072] This can be explained by the fact that due to differences in the technical architecture and data formats of different shopping applications or systems, the payment requests they send often exhibit diverse characteristics in terms of field definitions, parameter types, and message structures, easily leading to inconsistencies in payment request formats. To facilitate standardized and unified payment management of various payment requests, this embodiment predefines a unified transmission interface. This interface clearly specifies the standard requirements for the field composition, data types, transmission protocols, and verification rules of payment requests. Based on this, user terminals can transmit raw payment requests containing standard payment information through this transmission interface, facilitating centralized processing of various payment requests by processing equipment, thereby improving the standardization and management efficiency of the payment process.
[0073] Specifically, standard payment information may include, but is not limited to: payment amount, unique order identifier, user identifier, merchant representation, product or service description information, and other general transaction fields and their corresponding field information.
[0074] Considering the fragmented configuration of risk control rules across payment channels in related technologies, it is impossible to correlate and analyze abnormal transactions across channels, resulting in weak risk control capabilities. Based on the above technical situation, in this embodiment, upon receiving the original payment request, the payment parameters contained within it are used as identification parameters to perform risk control identification and determine whether it is a risky transaction.
[0075] Optionally, one possible implementation of risk control identification may include: determining whether there is a payment risk in the original payment request based on at least one payment information; if it is determined that there is a payment risk in the original payment request, then performing a preset risk processing operation; if it is determined that there is no payment risk in the original payment request, then performing the step of determining the target payment channel of the original payment request.
[0076] In this embodiment, specifically, when the payment processing device parses the original payment request and obtains at least one corresponding payment information, it can call a preset risk identification algorithm or risk identification model, use the aforementioned payment information as input for risk identification processing, and output the corresponding identification result.
[0077] During the risk identification process, payment processing equipment can perform correlation analysis on the transaction behavior of the same user or related entity across different payment channels, thereby identifying cross-channel composite risk patterns. For example, the system can detect risk characteristics such as the same user initiating high-frequency transactions continuously within a short period of time on multiple payment channels, abnormal amounts being dispersed across different channels, or a specific payee receiving funds from different users in a concentrated manner on multiple channels, and then comprehensively determine whether payment risks exist.
[0078] If the identification result indicates that the original payment request poses a payment risk, the payment processing device will automatically execute preset risk handling operations. Risk handling operations include, but are not limited to: rejecting the transaction, transferring the transaction to a manual review process, sending an identity verification request to the user, or temporarily restricting the payment function of the relevant account, so as to achieve real-time interception and effective control of risky transactions.
[0079] If the identification result indicates that there is no payment risk in the original payment request, the payment processing device will continue to execute the subsequent payment process, that is, determine the target payment channel for processing the transaction according to the preset channel selection strategy, and complete the corresponding payment processing operation.
[0080] Through the above implementation methods, this embodiment realizes the unified configuration and centralized management of risk control rules for various payment channels, and supports the correlation analysis and risk identification of cross-channel transaction behaviors, thereby improving the detection capability of complex and abnormal transaction patterns and enhancing the accuracy and real-time response efficiency of the overall risk control system.
[0081] Based on the above implementation method, the payment information may further include indicative data related to the selection of payment channels, such as the payment method code and channel type identifier explicitly specified by the user.
[0082] Based on this, after receiving the original payment request, the payment processing device can parse the payment information contained therein and determine whether the request information contains channel payment information indicating the payment channel. Based on the judgment result, the payment channel determination logic of the original payment request can be accurately selected, and the target payment channel can be determined quickly and accurately, thereby improving the certainty of the payment process and the overall processing efficiency.
[0083] S202. If the payment information includes channel payment information indicating the payment channel, determine the target payment channel based on the channel payment information.
[0084] In this embodiment, if the parsed payment information contains channel payment information indicating the payment channel, and the payment method field is the payment identifier or bank code corresponding to the third-party payment tool, the payment processing device can directly determine the target payment channel required for this payment operation based on the channel payment information.
[0085] Specifically, the payment processing device can pre-build a mapping table or configuration rules between payment channel identifiers and corresponding payment channel services. When valid channel payment information is identified, the target payment channel corresponding to the channel payment information can be determined by querying the mapping table or configuration rules. For example, the target payment channel includes, but is not limited to, third-party payment services or a bank gateway service.
[0086] In the above implementation, the target payment channel is determined directly based on the payment intention of the user or the initiator, which realizes the precise routing of payment requests, avoids unnecessary channel selection logic, and improves the certainty and processing efficiency of the payment process.
[0087] S203. If the payment information does not contain channel payment information indicating the payment channel, determine the target payment channel according to the preset channel determination rules.
[0088] In this embodiment, if it is determined that the parsed payment information does not contain channel payment information indicating the payment channel, the payment processing device can automatically determine the target payment channel according to the preset channel determination rules.
[0089] In this embodiment, the preset channel determination rules can be flexibly configured based on a variety of strategies, such as: selecting the most frequently used channel based on the user's historical payment habits, matching the optimal rate or supported channel based on the order amount or type, allocating currently available channels based on the system load balancing strategy, or selecting the regional default channel based on geographical location or transaction currency, etc.
[0090] By executing these predefined rule logics, a target payment channel can be intelligently and reasonably selected without explicit user specification, thereby ensuring a smooth and efficient payment process and optimizing user experience and system resource allocation.
[0091] S204. Using a preset protocol conversion strategy, the original payment request is converted into a target payment request adapted to the target payment channel.
[0092] In this embodiment, after determining the target payment channel, the payment processing device will invoke a preset protocol conversion strategy. Here, the preset protocol conversion strategy typically includes conversion rules, data templates, or field mapping relationships configured for various different payment channels, in order to convert the original payment request in a uniform format received and processed by the device into a payment request that fully conforms to the interface specification of the specific target payment channel.
[0093] Specifically, the payment processing device obtains the corresponding protocol conversion strategy based on the selected target payment channel, and parses and reconstructs the original payment request based on the strategy to obtain a target payment request that meets the requirements of the target payment channel.
[0094] The above conversion method allows R&D personnel to integrate payment functions without needing to understand the technical details of each channel, simply by connecting to a unified interface. This reduces redundant development work, improves system compatibility and scalability, and reduces the risk of payment failure due to protocol errors.
[0095] S205. Invoke the target payment channel and complete the payment according to the target payment request.
[0096] In this embodiment, the payment processing device sends the target payment request to the corresponding payment channel server through a standard interface provided by the target payment channel, such as an API gateway, payment SDK, or proprietary communication protocol, to trigger and complete the payment process.
[0097] Upon receiving a request, the payment channel server executes its internal payment processing logic, including but not limited to: verifying the legality of the request, executing fund deduction or authorization, generating payment vouchers, and returning a payment result response to the payment processing device.
[0098] The payment processing device also receives responses from payment channels and parses them to obtain the result status and related information, indicating whether the payment was successful or failed. Regardless of the payment result, the payment processing device records the result and, according to business rules or system configuration, can send standardized payment result notifications back to the original business initiator, such as the user terminal or merchant system, thereby completing the entire payment process.
[0099] Through the above-mentioned calling process, the payment business logic and specific payment channels can be effectively decoupled, enabling the payment processing equipment to connect to and manage multiple heterogeneous payment channels in a unified and reliable manner, thereby improving the system's scalability and maintainability.
[0100] In the above technical solution, the system receives an original payment request containing payment information and intelligently determines the target payment channel based on whether the payment information includes channel payment information (if it does, the channel payment information is used directly; otherwise, preset rules are used). Then, a preset protocol conversion strategy is used to convert the original payment request into a target payment request adapted to the target payment channel, and finally, the channel is invoked to complete the payment. This solution achieves unified and automated management of payment channel access, reducing the complexity and repetitive development costs caused by independent connection of multiple channels, and improving the maintainability and scalability of the system. Simultaneously, intelligent channel determination and standardized protocol conversion mean that adding, removing, or changing payment channels does not require significant modifications to the business code, shortening the development cycle, reducing the risk of errors, and enhancing the system's adaptability to rapidly changing payment needs.
[0101] The following section will further detail the execution process of the payment processing technology solution. It should be noted that the following description is merely an exemplary implementation of the technical solution in this application and does not constitute a limitation on the technical solution of this application.
[0102] In this embodiment, if the payment information of the received original payment request includes channel payment information indicating the payment channel, the target payment channel can be determined according to the preset channel determination rules.
[0103] Based on this, one implementation method for determining the target payment channel may include: obtaining the request identifier of the original payment request and extracting the payment channel identifier from the channel payment information; querying a preset payment channel routing table based on the request identifier and / or payment channel identifier to determine the target payment channel corresponding to the original payment request.
[0104] Upon receiving an original payment request, the payment processing device obtains its request identifier. This request identifier can be a unique transaction sequence number generated by the device, a user session identifier, or a request timestamp—any information uniquely identifying the payment request. Simultaneously, the device extracts the payment channel identifier from the channel payment information. The payment channel identifier can be information representing the specific payment channel type or channel code involved in the payment request, such as a bank card channel, a third-party payment channel, or a digital currency channel.
[0105] During this process, the payment processing device can also invoke a preset payment channel routing table. In this embodiment, the payment channel routing table is pre-configured with mapping relationships or routing rules between request identifiers, payment channel identifiers, and target payment channels for different payment scenarios. For example, the routing table can match the target payment channel suitable for the current payment request based on the business type, user level, or transaction amount range in the request identifier, combined with the payment channel identifier.
[0106] In one implementation, the payment processing device can query a preset payment channel routing table based solely on the payment channel identifier extracted from the channel payment information. In this case, the routing table pre-establishes a correspondence between payment channel identifiers and target payment channels. For example, when the payment channel identifier is "Third-Party Payment A," the routing table can directly map to the corresponding target payment channel code.
[0107] In another implementation, the payment processing device can simultaneously query the payment channel routing table based on both the payment channel identifier and the request identifier of the original payment request. In this case, the routing table not only contains the mapping relationship between the payment channel identifier and the target payment channel, but also includes routing rules configured based on dimensions such as business type, user attributes, and transaction characteristics in the request identifier. The device will obtain the two query results and perform a consistency check: if the two query results point to the same target payment channel, the system determines the final target payment channel based on this consistency result; if the query results are inconsistent, a preset conflict handling mechanism is triggered, such as selecting one channel according to priority rules, transferring the request to manual review, or processing it according to the default channel.
[0108] By employing the aforementioned flexible routing query methods, we can achieve both fast routing based on payment channel identifiers and refined routing decisions that combine multi-dimensional request identifiers, thereby improving routing efficiency while ensuring business adaptability and system reliability.
[0109] In this embodiment, if the payment information of the received original payment request does not contain channel payment information indicating the payment channel, the target payment channel can be determined according to the preset channel determination rules.
[0110] Based on this, another implementation method for determining the target payment channel may include: obtaining the default payment channel and determining the default payment channel as the target payment channel.
[0111] In this embodiment, the payment processing device pre-sets at least one default payment channel in the configuration management. The default payment channel is usually selected based on factors such as channel stability, service availability, cooperation priority, or historical comprehensive performance, and supports dynamic updates according to business needs.
[0112] When the payment processing device confirms that the original payment request lacks channel payment information, it will directly retrieve the currently effective default payment channel identifier from the pre-configuration and directly determine that channel as the target payment channel for processing this payment process.
[0113] During this process, the payment processing device does not need to perform complex channel matching or strategy calculations; it can determine the channel simply by reading the pre-configured settings, thereby shortening the routing decision time. After determining the target payment channel, the payment processing device then continues to perform subsequent operations such as payment request forwarding, transaction processing, and result return based on the channel's interface specifications and processing flow.
[0114] In this way, this embodiment can achieve a fast and deterministic routing response by calling the default payment channel when the payment request does not carry channel information. This avoids process interruption caused by the lack of a channel and ensures the processing efficiency and robustness of the payment system in simple scenarios.
[0115] Optionally, another implementation of determining the target payment channel may include: acquiring payment channels with a historical payment success rate higher than a preset threshold, and determining the payment channel as the target payment channel.
[0116] Specifically, the payment processing equipment can first access the historical transaction database to obtain payment success rate data for each payment channel within a preset statistical period. The statistical period can be set according to business needs, such as the last 24 hours, the last 7 days, or the last 30 days; the payment success rate is defined as the proportion of the number of transactions successfully completed by that channel to the total number of transactions initiated.
[0117] The historical payment success rate of each payment channel is compared with a preset threshold, and a set of payment channels with a success rate higher than the threshold is selected. The threshold can be dynamically adjusted according to business requirements, for example, set to 95%, 98%, or other reasonable levels.
[0118] If the selected channel set contains multiple payment channels, the payment processing device can further determine the final target payment channel based on additional strategies, such as selecting the channel with the highest success rate, selecting the channel with the shortest average processing time, or selecting according to channel priority.
[0119] Subsequently, the payment processing device will use the identified payment channel as the target payment channel and continue the payment process based on that channel.
[0120] The above method, by selecting channels based on historical payment success rates, can automatically prioritize stable and high-success-rate payment channels when the payment request does not explicitly specify a payment channel. This effectively improves the overall transaction success rate and user payment experience, while reducing the risk of payment failure due to channel instability.
[0121] Optionally, another implementation of determining the target payment channel may further include: determining the target payment channel based on one or more of at least one payment information and a preset channel selection strategy.
[0122] Specifically, the payment processing device obtains one or more payment information items extracted from the original payment request. In addition to the transaction amount, user identity identifier, merchant category, and type of goods or services, the payment information may also include information such as user geographical location, transaction time, and device type.
[0123] Subsequently, the payment processing device invokes a preset channel selection strategy. In this embodiment, the strategy includes mapping rules or decision logic between different payment information features and recommended payment channels.
[0124] For example, the preset channel selection strategy can include several rules: if the transaction amount exceeds the preset large amount threshold, the system will automatically select a bank direct connection channel with high risk control level and strong fund security; if the user identity belongs to a specific membership level or user group, the system will prioritize third-party payment channels that have close cooperation with that user group and enjoy preferential rates; if the merchant category is virtual goods or high-frequency small-amount transactions, the system will recommend designated payment channels with fast processing speed and high interface adaptability; if the user's geographical location is detected to be overseas, the system will automatically route the user to an international payment channel that supports cross-border payments.
[0125] Based on this, the payment processing device matches the extracted payment information with the aforementioned strategy rules, and determines the final target payment channel according to the matching results. If multiple rules are matched simultaneously, a comprehensive decision can be made according to the rule priority or weight preset in the strategy.
[0126] Through the above methods, this embodiment achieves refined channel routing based on multi-dimensional payment information, which can dynamically select the most suitable payment channel according to specific transaction scenarios, user characteristics and business needs, thereby improving payment success rate and user experience while optimizing channel resource allocation and business compliance.
[0127] If the target payment channel is determined based on the above implementation method, the original payment request can be converted into a target payment request corresponding to the target payment channel in order to complete the payment.
[0128] Optionally, one possible implementation of the payment request conversion may include: obtaining the target protocol conversion strategy corresponding to the target payment channel from a preset protocol conversion strategy; and, according to the target protocol conversion strategy, performing format conversion and / or parameter mapping on at least one payment information in the original payment request to generate a target payment request that meets the requirements of the target payment channel.
[0129] Specifically, the payment processing device obtains the target protocol conversion strategy corresponding to the target payment channel from a preset protocol conversion strategy. In this embodiment, the protocol conversion strategy library is pre-configured with the protocol format, field specifications, encryption methods, signature algorithms, and parameter mapping relationships required by each payment channel, thereby forming a channel-differentiated conversion rule set.
[0130] Based on this, the payment processing device performs conversion processing on at least one payment information contained in the original payment request according to the target protocol conversion strategy. The conversion processing includes, but is not limited to, format conversion, parameter mapping, security processing, and parameter supplementation.
[0131] For example, the conversion process may include one or more of the following operations: standardizing the data format, such as unifying the date and time format, converting monetary units, or converting character encoding; mapping parameter names according to the target channel's field naming rules, such as mapping the internal parameter "order_id" to the target channel's interface parameter "outTradeNo"; encrypting or de-identifying sensitive information according to the target channel's security specifications, and adding the digital signature or authentication token required by the channel; and supplementing specific parameters required by the target channel, such as channel identifier, interface version number, or business extension fields.
[0132] Through the structured conversion process described above, the payment processing device can adapt the original payment request into a standardized format that can be recognized and processed by the target payment channel, thereby ensuring the accuracy, security, and interface compatibility of the payment request during cross-channel transmission.
[0133] After converting the original payment request into a target payment request, the target payment channel can be invoked, and the payment can be completed according to the target payment request.
[0134] Based on this, one possible implementation of calling the target payment channel and completing the payment may include: when the target payment channel returns a payment failure response, obtaining a preset payment retry strategy; determining the backup payment channel as the new target payment channel according to the payment retry strategy; and re-executing the payment request conversion and payment call process based on the new target payment channel until a payment success response is received, thereby completing the payment.
[0135] Specifically, after the target payment channel is determined, the system will initiate a payment invocation process for that target payment channel to facilitate the fulfillment of the original payment request.
[0136] When the target payment channel returns a payment failure response due to factors such as channel interface timeout, insufficient account balance, or channel service abnormality, the payment processing device can automatically obtain a preset payment retry strategy. This strategy is pre-configured with core parameters such as the priority order of backup payment channels, the maximum number of retries, and the retry time interval.
[0137] Based on this, the payment processing device will select the highest priority channel from the list of backup payment channels according to the priority rules of the payment retry strategy mentioned above, and determine it as the new target payment channel.
[0138] Then, based on the new target payment channel, the payment request parameter conversion operation is re-executed to generate a standardized payment instruction adapted to the new channel, and the payment call process is initiated again. The above channel call and result verification steps are repeated until a payment success response is received, thus completing this payment process.
[0139] Understandably, the payment retry strategy also includes a maximum number of retries. If the maximum number of retries is reached and a successful payment response is still not received, the retry process is terminated and a payment failure message is returned.
[0140] Through the above methods, this embodiment can automatically and intelligently switch payment channels and retry when payment fails, thereby effectively improving the final success rate of payment and the system's fault tolerance, and improving the user's payment experience.
[0141] Figure 3 A schematic diagram of the payment processing device provided in this application is shown below. Figure 3 As shown, the payment processing device 30 provided in this embodiment includes:
[0142] The payment request acquisition module 301 is used to receive an original payment request, which contains at least one payment information.
[0143] The first channel determination module 302 is used to determine the target payment channel based on the channel payment information when the payment information contains channel payment information indicating the payment channel.
[0144] The second channel determination module 303 is used to determine the target payment channel according to preset channel determination rules when the payment information does not contain channel payment information indicating the payment channel.
[0145] The payment request conversion module 304 is used to convert the original payment request into a target payment request adapted to the target payment channel using a preset protocol conversion strategy.
[0146] The payment module 305 is used to call the target payment channel and complete the payment according to the target payment request.
[0147] In one possible implementation, the first channel determination module 302, when determining the target payment channel based on the channel payment information, is specifically used for:
[0148] Obtain the request identifier of the original payment request and extract the payment channel identifier from the channel payment information;
[0149] Based on the payment channel identifier, or the request identifier and the payment channel identifier, query the preset payment channel routing table to determine the target payment channel corresponding to the original payment request.
[0150] In one possible implementation, the second channel determination module 303, when determining the target payment channel according to preset channel determination rules, is specifically used for:
[0151] Obtain the default payment channel and set it as the target payment channel;
[0152] or,
[0153] Acquire payment channels with a historical payment success rate higher than a preset threshold, and identify these payment channels as target payment channels;
[0154] or,
[0155] The target payment channel is determined based on one or more of the payment information and a preset channel selection strategy.
[0156] In one possible implementation, the payment request conversion module 304, when converting the original payment request into a target payment request adapted to the target payment channel using a preset protocol conversion strategy, specifically performs the following:
[0157] Obtain the target protocol conversion strategy corresponding to the target payment channel from the preset protocol conversion strategies;
[0158] According to the target protocol conversion strategy, at least one payment information in the original payment request is format converted and / or parameter mapped to generate a target payment request that meets the requirements of the target payment channel.
[0159] In one possible implementation, the payment module 305, when invoking the target payment channel and completing the payment according to the target payment request, is specifically used for:
[0160] When the target payment channel returns a payment failure response, retrieve the preset payment retry strategy;
[0161] Based on the payment retry strategy, the backup payment channel will be identified as the new target payment channel;
[0162] Based on the new target payment channel, the payment request transformation and payment invocation process is re-executed until a payment success response is received, at which point the payment is completed.
[0163] In one possible implementation, the device, after receiving the original payment request, is further used to:
[0164] Based on at least one piece of payment information, determine whether the original payment request is subject to payment risk;
[0165] If it is determined that the original payment request poses a payment risk, then the preset risk handling operation will be executed;
[0166] If it is determined that there is no payment risk in the original payment request, then proceed with the step of determining the target payment channel for the original payment request.
[0167] The payment processing device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.
[0168] Figure 4 This is a block diagram of an electronic device provided in this application. The device can be a client terminal device or a cloud server, etc. See also... Figure 4 The device 400 may include one or more of the following components: processing component 402, memory 404, power supply component 406, multimedia component 408, audio component 410, input / output interface 412, sensor component 414, and communication component 416.
[0169] Processing component 402 typically controls the overall operation of device 400, such as operations associated with display, telephone calls, data communication, camera operation, and recording. Processing component 402 may include one or more processors 420 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 402 may include one or more modules to facilitate interaction between processing component 402 and other components. For example, processing component 402 may include a multimedia module to facilitate interaction between multimedia component 408 and processing component 402.
[0170] Memory 404 is configured to store various types of data to support the operation of device 400. Examples of this data include instructions for any application or method operating on device 400, contact data, phonebook data, messages, pictures, videos, etc. Memory 404 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.
[0171] Power supply component 406 provides power to various components of device 400. Power supply component 406 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to device 400.
[0172] Multimedia component 408 includes a screen that provides an output interface between device 400 and the user. In some embodiments, the screen may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen may be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors may sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 408 includes a front-facing camera and / or a rear-facing camera. When device 400 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.
[0173] Audio component 410 is configured to output and / or input audio signals. For example, audio component 410 includes a microphone (MIC) configured to receive external audio signals when device 400 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 404 or transmitted via communication component 416. In some embodiments, audio component 410 also includes a speaker for outputting audio signals.
[0174] Input / output interface 412 provides an interface between processing component 402 and peripheral interface modules, which may be keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, start buttons, and lock buttons.
[0175] Sensor assembly 414 includes one or more sensors for providing state assessments of various aspects of device 400. For example, sensor assembly 414 may detect the on / off state of device 400, the relative positioning of components such as the display and keypad of device 400, changes in the position of device 400 or a component of device 400, the presence or absence of user contact with device 400, the orientation or acceleration / deceleration of device 400, and temperature changes of device 400. Sensor assembly 414 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 414 may also include an optical sensor, such as a complementary metal-oxide-semiconductor (CMOS) sensor or a charge-coupled device (CCD) sensor, for use in imaging applications. In some embodiments, sensor assembly 414 may also include an accelerometer, a gyroscope, a magnetometer, a pressure sensor, or a temperature sensor.
[0176] Communication component 416 is configured to facilitate wired or wireless communication between device 400 and other devices. Device 400 can access wireless networks based on communication standards, such as WiFi, 4G, or 5G, or combinations thereof. In one exemplary embodiment, communication component 416 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 416 also includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), and other technologies.
[0177] In an exemplary embodiment, device 400 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processors (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the methods described above.
[0178] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 404 including instructions, which can be executed by a processor 420 of the device 400 to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.
[0179] A non-transitory computer-readable storage medium, wherein instructions in the storage medium, when executed by a server's processor, enable the server to perform the aforementioned large model data processing method.
[0180] This application also provides a chip for executing instructions, which is used to execute the technical solution of the large model data processing method in the above embodiments.
[0181] This application also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are executed on a computer, the computer performs the technical solution of the large model data processing method described in the above embodiments.
[0182] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium. When the at least one processor executes the computer program, it can implement the technical solution of the large model data processing method described in the above embodiments.
[0183] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.
[0184] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.
[0185] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.
[0186] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.
Claims
1. A payment processing method, characterized in that, include: Receive an original payment request, which contains at least one payment information; If the payment information includes channel payment information indicating a payment channel, the target payment channel is determined based on the channel payment information; If the payment information does not contain channel payment information indicating the payment channel, the target payment channel is determined according to a preset channel determination rule; A preset protocol conversion strategy is used to convert the original payment request into a target payment request adapted to the target payment channel; Invoke the target payment channel and complete the payment according to the target payment request.
2. The method according to claim 1, characterized in that, Determining the target payment channel based on the aforementioned channel payment information includes: Obtain the request identifier of the original payment request, and extract the payment channel identifier from the channel payment information; Based on the payment channel identifier, or the request identifier and the payment channel identifier, a preset payment channel routing table is queried to determine the target payment channel corresponding to the original payment request.
3. The method according to claim 1, characterized in that, The target payment channel is determined according to preset channel determination rules, including at least one of the following methods: Obtain the default payment channel and determine the default payment channel as the target payment channel; Obtain payment channels with a historical payment success rate higher than a preset threshold, and identify these payment channels as target payment channels; The target payment channel is determined based on one or more of the at least one payment information and a preset channel selection strategy.
4. The method according to claim 1, characterized in that, The original payment request is converted into a target payment request adapted to the target payment channel using a preset protocol conversion strategy, including: Obtain the target protocol conversion strategy corresponding to the target payment channel from the preset protocol conversion strategies; According to the target protocol conversion strategy, at least one payment information in the original payment request is format converted and / or parameter mapped to generate a target payment request that meets the requirements of the target payment channel.
5. The method according to claim 1, characterized in that, Invoking the target payment channel and completing the payment according to the target payment request includes: When the target payment channel returns a payment failure response, a preset payment retry strategy is obtained; According to the payment retry strategy, the backup payment channel will be identified as the new target payment channel; Based on the new target payment channel, the payment request conversion and payment invocation process is re-executed until a payment success response is received, at which point the payment is completed.
6. The method according to any one of claims 1-5, characterized in that, After receiving the original payment request, the method further includes: Based on the at least one payment information, determine whether the original payment request carries any payment risk; If it is determined that the original payment request poses a payment risk, then a preset risk handling operation is performed; If it is determined that the original payment request does not pose a payment risk, then the step of determining the target payment channel for the original payment request is executed.
7. A payment processing device, characterized in that, include: A payment request acquisition module is used to receive an original payment request, wherein the original payment request contains at least one payment information; The first channel determination module is used to determine the target payment channel based on the channel payment information when the payment information contains channel payment information indicating the payment channel. The second channel determination module is used to determine the target payment channel according to a preset channel determination rule when the payment information does not contain channel payment information indicating the payment channel. The payment request conversion module is used to convert the original payment request into a target payment request adapted to the target payment channel using a preset protocol conversion strategy. The payment module is used to invoke the target payment channel and complete the payment according to the target payment request.
8. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-6.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.
10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-6.