A payment processing method and device, electronic equipment and storage medium

Abstract

The application relates to a payment processing method and device, electronic equipment and a storage medium. The method comprises the following steps: in response to a payment request of a target commodity, determining a target payment type corresponding to the target commodity from at least one preset payment type configured for the target commodity, each preset payment type corresponding to at least one preset payment channel; determining channel state information of each preset payment channel corresponding to the target payment type; based on the obtained channel state information, determining a target payment channel from each preset payment channel corresponding to the target payment type; and based on the target payment channel, performing payment on the target commodity. The application reduces the configuration and maintenance cost and improves the payment success rate and member conversion efficiency.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a payment processing method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the rapid development of various membership-based business platforms (such as video streaming, e-commerce, and lifestyle services), these platforms need to provide users with diverse payment methods to enhance their experience. This typically requires integration with hundreds of underlying payment channels, including WeChat Pay, Alipay, UnionPay, and bank card gateways. Currently, platforms generally configure specific payment channels directly within product listings, resulting in deep coupling between payment channels and business operations. This leads to highly redundant and error-prone configurations. Furthermore, routing rules often rely on manual pre-setting, causing payment channels with high failure rates to be continuously recommended, resulting in persistently high payment failure rates and severely impacting member payment conversion efficiency and user experience. Summary of the Invention

[0003] In view of this, in order to solve the above-mentioned technical problems or some of the technical problems, embodiments of this application provide a payment processing method, apparatus, electronic device and storage medium.

[0004] Firstly, this application provides a payment processing method, including: In response to a payment request for a target product, a target payment type corresponding to the target product is determined from at least one preset payment type configured for the target product, and each preset payment type corresponds to at least one preset payment channel; Determine the channel status information of each of the preset payment channels corresponding to the target payment type; Based on the obtained channel status information, the target payment channel is determined from each of the preset payment channels corresponding to the target payment type; Payment is made for the target product based on the target payment channel.

[0005] In an optional implementation, determining the target payment channel from the preset payment channels corresponding to the target payment type based on the obtained channel status information includes: For each preset payment channel corresponding to the target payment type, a target channel score is determined based on the channel status information corresponding to the preset payment channel. The highest target channel score is determined from all the target channel scores obtained; Based on the preset payment channel corresponding to the highest target channel score, the target payment channel is determined from each of the preset payment channels corresponding to the target payment type.

[0006] In an optional implementation, the channel status information includes channel success rate, channel latency, and channel selection rate; The step of determining the target channel score corresponding to the preset payment channel based on the channel status information corresponding to the preset payment channel includes: Determine a first preset weight corresponding to the channel success rate, a second preset weight corresponding to the channel latency, and a third preset weight corresponding to the number of channel selections. Using the first preset weight, the second preset weight, and the third preset weight, the channel success rate, the channel latency, and the channel selection rate are weighted and summed to determine the target channel score corresponding to the preset payment channel. Wherein, the channel success rate is used to characterize the ratio between the number of successful payments through the preset payment channel and the number of payments made through the preset payment channel within the first sliding window; the channel latency is used to characterize the average response latency of the preset payment channel within the second sliding window; and the channel selection rate is used to indicate the ratio between the number of payments made through the preset payment channel and the total number of payments made through all preset payment channels under the target payment type within the third sliding window.

[0007] In an optional implementation, determining the target channel score corresponding to the preset payment channel based on the channel status information corresponding to the preset payment channel includes: Based on the channel status information corresponding to the preset payment channel, determine the initial channel score corresponding to the preset payment channel; Determine whether the preset payment channel is associated with a preset adjustment strategy, wherein the preset adjustment strategy is used to characterize the strategy for adjusting the initial channel score corresponding to the preset payment channel; When the preset payment channel is associated with the preset adjustment strategy, the preset adjustment strategy is used to adjust the initial channel score in order to determine the target channel score corresponding to the preset payment channel.

[0008] In an optional implementation, determining the channel status information of each preset payment channel corresponding to the target payment type includes: Determine the payment scenario corresponding to the target product and the device information of the payment device used to pay for the target product; Filter out all preset payment channels that meet the first preset condition from all preset payment channels corresponding to the target payment type to obtain a preset payment channel set corresponding to the target payment type. The first preset condition includes: the preset payment channel does not support the payment scenario and does not support the device information. Determine the channel status information of each of the preset payment channels in the preset payment channel set.

[0009] In an optional implementation, determining the channel status information of each of the preset payment channels in the preset payment channel set includes: Obtain the payment amount corresponding to the target product and the object level corresponding to the target object paying for the target product; The preset payment channels that meet the second preset condition are filtered out from the preset payment channel set to complete the update of the preset payment channel set. The second preset condition includes: the preset payment amount range corresponding to the preset payment channel does not include the payment amount and the preset payment channel does not support the object level. Determine the channel status information of each preset payment channel in the updated preset payment channel set.

[0010] In an optional implementation, determining the target payment channel from the preset payment channels corresponding to the target payment type based on the preset payment channel corresponding to the highest target channel score includes: When there are multiple highest target channel scores, determine the channel priority of the preset payment channel corresponding to each highest target channel score; Based on the channel priority, channel success rate, and channel latency of the preset payment channels corresponding to the highest target channel scores, the target payment channel is determined from the preset payment channels corresponding to the highest target channel scores.

[0011] Secondly, this application provides a payment processing apparatus, comprising: The type determination module is used to determine the target payment type corresponding to the target product from at least one preset payment type configured for the target product in response to the payment request of the target product, wherein each preset payment type corresponds to at least one preset payment channel; The information determination module is used to determine the channel status information of each preset payment channel corresponding to the target payment type; The channel determination module is used to determine the target payment channel from the preset payment channels corresponding to the target payment type based on the obtained channel status information. The payment module is used to make payment for the target product based on the target payment channel.

[0012] Thirdly, this application provides an electronic device, including a processor and a memory, wherein the processor is configured to execute a payment processing program stored in the memory to implement the payment processing method described above.

[0013] Fourthly, this application also provides a storage medium storing one or more programs that can be executed by one or more processors to implement the payment processing method described above.

[0014] Compared with the prior art, the technical solution provided in this application has the following advantages. The method provided in this application includes: responding to a payment request for a target product, determining a target payment type corresponding to the target product from at least one preset payment type configured for the target product, each preset payment type corresponding to at least one preset payment channel; determining the channel status information of each preset payment channel corresponding to the target payment type; determining a target payment channel from each preset payment channel corresponding to the target payment type based on the obtained channel status information; and making payment for the target product based on the target payment channel. Through the above method, this application abstracts and merges multiple underlying payment channels into preset payment types, so that product configuration is only associated with payment type rather than specific payment channel, realizing the decoupling and centralized management of payment configuration and business logic; on this basis, by acquiring and dynamically determining the final payment channel based on the status information of each channel in real time, intelligent routing decision-making is realized, avoiding configuration redundancy and errors caused by direct binding of payment channels to products, and overcoming the problem of high failure rate payment channels being continuously recommended due to reliance on manual static rules, reducing configuration maintenance costs and improving payment success rate and member conversion efficiency. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0016] 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, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0017] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0018] Figure 1 A flowchart illustrating a payment processing method provided in an embodiment of this application; Figure 2 A flowchart illustrating another payment processing method provided in this application embodiment; Figure 3 A schematic diagram illustrating the working principle of a payment processing system provided in this application embodiment; Figure 4 A schematic diagram of the structure of a payment processing device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] The following disclosure provides numerous different embodiments or examples for implementing various structures of the invention. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of the invention. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0021] refer to Figure 1 , Figure 1 This is a flowchart illustrating a payment processing method provided in an embodiment of this application. The payment processing method provided in this embodiment includes the following steps: S101: In response to a payment request for the target product, determine the target payment type corresponding to the target product from at least one preset payment type configured for the target product.

[0022] In this embodiment, the target product refers to the object on which the user initiates a payment request. This is typically a product or service available for purchase on a membership-based commercial platform, such as an iQiyi Gold continuous monthly membership package or a JD PLUS annual membership card. The payment request is actively triggered by the user, usually through actions such as clicking "Pay Now" or "Confirm Payment." The payment request includes the target product identifier, the ordering scenario (e.g., an app, mini-program), device information (e.g., device type, device version number), payment amount, and user level.

[0023] Preset payment types can be understood as categories formed by the platform abstracting and classifying fragmented payment channels at the underlying level according to user cognitive habits and business adaptation needs. Each preset payment type corresponds to a set of sub-preset payment channels with similar functional attributes. Its purpose is to decouple product configuration from specific payment channels, simplifying configuration logic and reducing redundancy. For example, sub-preset payment channels such as WeChat APP payment, WeChat Mini Program payment, and WeChat direct debit (continuous packages) are categorized under the preset payment type "WeChat Pay". Preset payment channels can be understood as the specific payment execution vehicle under a preset payment type, possessing independent technical call interfaces and service capabilities.

[0024] Before payment can be implemented, preliminary configuration must be completed. Hundreds of underlying payment channels (such as WeChat APP payment, Alipay Huabei, UnionPay direct debit, debit card quick payment, etc.) need to be abstracted and categorized into 8-10 preset payment types (such as WeChat payment, Alipay payment, bank card payment, UnionPay QuickPass, etc.), and a mapping relationship between preset payment types and preset payment channels needs to be established.

[0025] When a target product is listed, operations staff do not need to configure specific payment channels for it. They only need to associate it with pre-defined payment types. For example, for the iQiyi Gold Continuous Monthly Subscription Package, they can configure WeChat Pay and Alipay as pre-defined payment types. When a user clicks the "Pay Now" button for the product in the iQiyi APP, the user's device generates and sends a payment request.

[0026] Upon receiving the payment request, the system responds to the request and displays the various preset payment types for the target product. Users can then select the target payment type corresponding to the target product from the displayed preset payment types.

[0027] S102: Determine the channel status information of each preset payment channel corresponding to the target payment type.

[0028] In this embodiment, the channel status information represents the current service quality of the preset payment channel and the user's preference for the preset payment channel.

[0029] After determining the target payment type corresponding to the target product, all preset payment channels associated with that target payment type are retrieved, and then the status information of each preset payment channel is collected in real time through the platform's built-in data collection module.

[0030] S103: Based on the obtained status information of each channel, determine the target payment channel from the preset payment channels corresponding to the target payment type.

[0031] In this embodiment, the target payment channel can be understood as the optimal payment channel determined from all preset payment channels corresponding to the target payment type after filtering by channel status information. It is the specific execution carrier for the user to finally complete the payment for the target product.

[0032] After obtaining the preset payment channels corresponding to the target payment type, for each preset payment channel, a score is given based on the channel status information corresponding to that preset payment channel. Based on the scores of each preset payment channel, the target payment channel is determined from the preset payment channels corresponding to the target payment type.

[0033] S104: Pay for the target goods based on the target payment channel.

[0034] In this embodiment, after obtaining the target payment channel, the call parameters of the target payment channel (including order number, payment amount, callback address, etc.) are encapsulated into a standard interface instruction and sent to the APP on the user's current device. After receiving the instruction, the APP on the device automatically launches the payment APP corresponding to the target payment channel and redirects to the payment confirmation page, displaying information such as order amount and payee.

[0035] After users complete payment via fingerprint verification or by entering a payment password, the payment app sends a notification of successful payment to the platform. Upon receiving this notification, the platform updates the order status to "payment successful" and completes the payment for the target product for the user, thus completing the entire payment process.

[0036] This embodiment provides a payment processing method that abstracts and merges multiple underlying payment channels into a preset payment type, allowing product configuration to be associated only with the payment type rather than the specific payment channel. This achieves decoupling and centralized management of payment configuration and business logic. Furthermore, by acquiring and dynamically determining the final payment channel based on the status information of each channel in real time, intelligent routing decisions are realized. This avoids configuration redundancy and errors caused by directly binding payment channels to products, and overcomes the problem of high failure rates due to reliance on manual static rules leading to the continuous recommendation of payment channels. This reduces configuration and maintenance costs and improves payment success rate and member conversion efficiency.

[0037] refer to Figure 2 , Figure 2 This is a flowchart illustrating another payment processing method provided in an embodiment of this application. The payment processing method provided in this embodiment includes the following steps: S201: In response to a payment request for the target product, determine the target payment type corresponding to the target product from at least one preset payment type configured for the target product.

[0038] In this embodiment, step S201 is the same as step S101 described above. For details, please refer to step S101 described above. This embodiment will not repeat the details here.

[0039] S202: Determine the channel status information of each preset payment channel corresponding to the target payment type.

[0040] In this embodiment, step S202 specifically includes: Determine the payment scenario corresponding to the target product and the device information of the payment device used to pay for the target product; Filter out all preset payment channels that meet the first preset condition from all preset payment channels corresponding to the target payment type to obtain the preset payment channel set corresponding to the target payment type; Determine the channel status information of each preset payment channel in the preset payment channel set.

[0041] The payment scenario and device information are included in the payment request. The payment scenario can be understood as the specific environment in which the user uses the target product to make the payment, such as an app payment scenario, an H5 payment scenario, or a mini-program payment scenario. The payment device can be understood as the terminal used by the user to make the payment for the target product. Device information includes device type and device version number; device type includes mobile phones, computers, etc.

[0042] The first preset condition includes: the preset payment channel does not support payment scenarios and does not support device information. Its purpose is to quickly exclude preset payment channels that are completely incompatible, narrow the scope of subsequent channel status information collection, and reduce the amount of calculation required for target channel scoring.

[0043] After obtaining the target payment type, the payment request initiated by the user is parsed to obtain the payment scenario corresponding to the target product and the device information of the payment device used to pay for the target product.

[0044] Retrieve all preset payment channels associated with the target payment type, verify each preset payment channel to see if it meets the first preset condition, filter out only the preset payment channels that meet the first preset condition, and retain at least one preset payment channel that does not meet the first preset condition to obtain the preset payment channel set.

[0045] For the obtained set of preset payment channels, the built-in data acquisition module collects the channel status information of each preset payment channel in real time, ensuring that the collected information is only for preset payment channels that are compatible with the current payment scenario and device information, and avoiding invalid data collection.

[0046] By first determining the payment scenario and device information, and then filtering out completely incompatible preset payment channels, this embodiment collects channel status information only for compatible preset payment channels. This not only eliminates interference from invalid preset payment channels and avoids the useless data collection and processing of incompatible preset payment channels, thus improving the efficiency of obtaining the status information of preset payment channels, but also ensures the accuracy of subsequent selection of target payment channels based on channel status information. This reduces the risk of payment failure due to incompatibility between payment channels and scenarios / devices, and guarantees the smoothness of the payment process and user experience.

[0047] The above-mentioned determination of the channel status information of each preset payment channel in the preset payment channel set specifically includes: Obtain the payment amount corresponding to the target product and the object level corresponding to the target object for paying the target product; The preset payment channels that meet the second preset condition are filtered out from the preset payment channel set to complete the update of the preset payment channel set; Determine the channel status information of each preset payment channel in the updated preset payment channel set.

[0048] The payment amount can be understood as the total transaction amount of the target product, i.e., the specific amount the user needs to pay, and the target audience is the user who initiated the payment request. The audience level can be understood as a tiered identifier assigned by the platform based on dimensions such as the target audience's spending power, membership qualifications, and activity level. Its purpose is to adapt to the level and permission requirements of the preset payment channels, ensuring that the audience level matches the permissions supported by the preset payment channels. For example, the platform's classification of Gold Members, Diamond Members, and Regular Users all belong to audience levels.

[0049] The second preset condition includes: the preset payment amount range corresponding to the preset payment channel does not include the payment amount, and the preset payment channel does not support the object level. Its purpose is to further exclude preset payment channels whose payment amounts and object levels do not match, based on the existing filtering for compatible payment scenarios and device information, thus narrowing down the range of effective payment channels. The preset payment amount refers to the amount range of transactions pre-configured for the preset payment channel.

[0050] The payment request is parsed and the account information corresponding to the target object is obtained. The payment amount corresponding to the target product is obtained from the payment request, and the object level of the target object is obtained from the account information. For example, if the membership level identifier of the target object in the query account information is gold member, then the object level is gold member.

[0051] Retrieve the preset configuration information (corresponding payment amount range and supported object level) of each preset payment channel in the preset payment channel set, verify whether each preset payment channel meets the second preset condition, filter out only the preset payment channels that meet the second preset condition, retain at least one matching preset payment channel, and complete the update of the preset payment channel set.

[0052] For the updated set of preset payment channels, the platform's data acquisition module collects the channel status information of each preset payment channel in real time, avoiding data collection on filtered invalid preset payment channels.

[0053] Through the above methods, this embodiment adds a secondary screening of payment amount and object level on the basis of payment scenario and device information adaptation filtering, excluding preset payment channels where the payment amount and object level do not match, thereby improving the accuracy and efficiency of obtaining channel status information, further reducing the risk of payment failure, and ensuring smooth payment and user experience.

[0054] S203: For each preset payment channel corresponding to the target payment type, determine the target channel score corresponding to the preset payment channel based on the channel status information corresponding to the preset payment channel.

[0055] S204: Determine the highest target channel score from all the target channel scores obtained.

[0056] S205: Based on the preset payment channel corresponding to the highest target channel score, determine the target payment channel from each preset payment channel corresponding to the target payment type.

[0057] Regarding steps S203 to S205 above, before payment is implemented, the platform needs to pre-set a unified target channel scoring calculation rule. This rule clarifies the calculation method and weight allocation of each item in the channel status information. When a user initiates a payment request and determines the target payment type corresponding to the target product, all preset payment channels associated with that target payment type are first extracted. Then, the channel status information corresponding to each preset payment channel is determined. Subsequently, the channel status information of each preset payment channel is substituted into the preset calculation rule to calculate the score of each preset payment channel one by one, thus obtaining the target channel score of the preset payment channel.

[0058] The target channel scores of all preset payment channels are aggregated to form a channel score set. Then, the highest target channel score is selected from this set through numerical comparison. The preset payment channel with the highest target channel score is then retrieved from the preset payment channels corresponding to the target payment type, and that preset payment channel is directly selected as the target payment channel for this payment.

[0059] By using the above methods, this embodiment transforms the channel status information of preset payment channels into a unified and comparable target channel score, and selects the target payment channel based on the highest score. This avoids the bias of subjective judgment and evaluation, makes the selection of payment channels more objective and accurate, ensures payment stability, and improves the user experience.

[0060] In one embodiment, step S204 specifically includes: Determine the first preset weight corresponding to channel success rate, the second preset weight corresponding to channel latency, and the third preset weight corresponding to the number of channel selections; Using the first preset weight, the second preset weight, and the third preset weight, the channel success rate, channel latency, and channel selection rate are weighted and summed to determine the target channel score corresponding to the preset payment channel.

[0061] The channel status information includes channel success rate, channel latency, and channel selection rate. The channel success rate represents the ratio of the number of successful payments through a preset payment channel to the total number of payments made through the preset payment channel within a first sliding window. The first sliding window can be set according to actual needs; in this embodiment, the specific value of the first sliding window is not limited, for example, it can be 30 minutes. To avoid data lag, the channel success rate can be obtained by smoothing using an exponential moving average (EMA) model, with a smoothing coefficient set to 0.2. For example, when the first sliding window is 30 minutes, iterative calculation can be performed based on the real-time channel success rate (i.e., the ratio of the number of successful payments through the preset payment channel to the total number of payments made through the preset payment channel) every minute within 30 minutes, and the resulting EMA value at the 30th minute can be used as the channel success rate under this first sliding window.

[0062] Channel latency is used to characterize the average response latency of a preset payment channel within the second sliding window. The second sliding window can be set according to actual needs; in this embodiment, the specific value of the second sliding window is not limited. For example, the second sliding window can be 5 minutes. Similarly, to avoid data lag, the channel latency can be obtained by smoothing using an exponential moving average (EMA) model, with a smoothing coefficient set to 0.2. For example, when the first sliding window is 5 minutes, iterative calculation can be performed based on the instantaneous channel latency (i.e., the ratio between the response delay of the preset payment channel and the maximum allowable response time of the preset payment channel) every 30 seconds within 5 minutes, so that the EMA value obtained at the 5th minute can be used as the channel latency under the second sliding window.

[0063] The channel selection count indicates the ratio between the number of times a user selects a preset payment channel within the third sliding window and the total number of times all preset payment channels are selected under the target payment type. The third sliding window can be set according to actual needs; in this embodiment, the specific value of the third sliding window is not limited. For example, the third sliding window can be 7 days. Similarly, to avoid data lag, the channel selection rate can be obtained by smoothing using an exponential moving average (EMA) model, with a smoothing coefficient set to 0.2. For example, when the third sliding window is 7 minutes, the EMA value on the 7th day can be used as the channel selection rate under the second sliding window, calculated iteratively based on the real-time channel selection rate for each day within the 7-day period (i.e., the ratio between the number of times a user selects a preset payment channel and the total number of times a user selects all preset payment channels under the target payment type).

[0064] The first preset weight is a coefficient pre-set by the platform to quantify the importance of channel success rate in the target channel score. The second preset weight is a coefficient pre-set by the platform to quantify the importance of channel latency in the target channel score. The third preset weight is a coefficient pre-set by the platform to quantify the importance of channel selection rate in the target channel score. The first, second, and third preset weights can be set according to actual needs, and this embodiment does not limit them. For example, the first preset weight can be 40%, the second preset weight can be 20%, and the third preset weight can be 40%.

[0065] For each preset payment channel corresponding to the target payment type, after determining the channel status information, the weight information corresponding to the preset payment channel is called to obtain the first preset weight corresponding to the channel success rate, the second preset weight corresponding to the channel latency, and the third preset weight corresponding to the channel selection rate from the channel status information. For each preset payment channel, the channel success rate, channel latency, and channel selection rate, along with the first, second, and third preset weights, are substituted into a weighted summation formula to calculate the target channel score for the preset payment channel. The target channel score can be expressed by the following formula: Target channel score = Channel success rate × First preset weight + (1 - Channel latency) × Second preset weight + Channel selection rate × Third preset weight It should be noted that if the channel success rate is lower than the first success rate threshold (e.g., 85%), the first preset weight will be reduced. If the channel success rate is lower than the second success rate threshold (e.g., 75%), the preset payment channel corresponding to the channel success rate will be filtered out, its target channel score will not be calculated, and an operation and maintenance alarm will be triggered.

[0066] By using the above methods, this embodiment improves the accuracy of channel selection, ensures payment stability, and enhances the user experience by clarifying the core dimensions of channel status information, combining real-time data from sliding window statistics with preset weighted summation to obtain the target channel score.

[0067] In another embodiment, step S204 above further includes: Based on the channel status information corresponding to the preset payment channel, determine the initial channel score corresponding to the preset payment channel; There are preset adjustment strategies to determine whether the target product is associated; When a preset adjustment strategy is associated with a preset payment channel, the preset adjustment strategy is used to adjust the initial channel score in order to determine the target channel score corresponding to the preset payment channel.

[0068] The initial channel score refers to the basic quantitative score calculated based on the channel status information of a preset payment channel, according to the platform's preset weighted summation calculation rules. For details, please refer to the above description; this embodiment will not elaborate further. The preset adjustment strategy is used to characterize the strategy for adjusting the initial channel score corresponding to a preset payment channel. The preset adjustment strategy can be understood as the platform pre-setting score adjustment rules associated with a specific preset payment channel to adapt to needs such as business promotion and payment channel cooperation. For example, to promote the Alipay Huabei channel, a preset adjustment strategy is set to multiply the initial channel score associated with Alipay Huabei by 1.2; or to support the newly integrated UnionPay QuickPass channel, a preset adjustment strategy is set to add a fixed 10 points associated with UnionPay QuickPass.

[0069] After obtaining the initial channel score corresponding to the preset payment channel based on the above weighted summation calculation method, the configuration center is queried using the unique identifier of the preset payment channel (such as the ID of the preset payment channel) to determine whether the preset payment channel is pre-associated with a preset adjustment strategy. If the preset payment channel is associated with a preset adjustment strategy, the specific adjustment rules in the preset adjustment strategy (such as multiplier coefficient, fixed bonus, proportional bonus, etc.) are extracted, and the initial channel score corresponding to the preset payment channel is adjusted in a targeted manner to obtain the target channel score; if the preset payment channel is not associated with a preset adjustment strategy, its initial channel score is directly used as the target channel score.

[0070] For example: WeChat App payment without association strategy: Target channel score = Initial channel score = 84.5 points. Alipay Huabei with association strategy (×1.2 times): Target channel score = Initial channel score 81.9 points × 1.2 = 98.28 points.

[0071] In this embodiment, the initial channel score corresponding to the objective preset payment channel is obtained based on the channel status information, and then the target channel score is obtained by targeted adjustment according to the preset adjustment strategy associated with the preset payment channel. This takes into account both the quality of the payment channel and the needs of platform operation, so as to help improve the achievement rate of operational goals and payment conversion efficiency.

[0072] In the above, step S205 specifically includes: When there are multiple highest target channel scores, determine the channel priority of the preset payment channel corresponding to each highest target channel score; Based on the channel priority, success rate, and latency of the preset payment channels corresponding to the highest target channel scores, the target payment channels are determined from the preset payment channels corresponding to the highest target channel scores.

[0073] When there are multiple highest target channel scores, the preset channel priority of the preset payment channel corresponding to each highest target channel score is extracted by querying the mapping relationship between preset payment channels and channel priorities stored in the platform's centralized configuration center.

[0074] Decisions are made in the order of channel priority > channel success rate > channel latency to ensure that only one preset payment channel is ultimately selected and that preset payment channel is designated as the target payment channel.

[0075] Priority determination: If the preset payment channels with the highest scores have different channel priorities, the preset payment channel with the highest priority will be directly selected as the target payment channel.

[0076] If the priorities are the same, the success rate of the channels is judged, and the preset payment channel with the higher success rate is selected as the target payment channel.

[0077] If the channel priority and channel success rate are the same, then the channel latency is determined: compare the channel latency of the two channels and select the preset payment channel with the shorter channel latency as the target payment channel.

[0078] In this embodiment, for scenarios where multiple preset payment channels have the same highest target channel score, a unique target payment channel is determined by channel priority, channel success rate, and channel latency. This avoids the dilemma of choosing a payment channel when target channel scores are the same and improves the stability and rationality of payment channel selection.

[0079] S206: Pay for the target goods based on the target payment channel.

[0080] In this embodiment, if payment is completed, the channel status information corresponding to the target payment channel is updated; if payment fails, the reason for failure is recorded. If the reason for failure is payment rejection, the first preset weight corresponding to the channel success rate is reduced; if the reason for failure is response timeout, the second preset weight corresponding to the channel latency is reduced; if the reason for failure is user abandonment, the third preset weight corresponding to the channel selection rate is reduced. This updates the weight information corresponding to the target payment channel, and based on the updated weight information, the process returns to step S201. By classifying and correcting weights according to the reason for failure, the interference of subjective user failures on channel scoring is avoided, and channel scoring is made more closely aligned with actual service quality, achieving objective, accurate, and closed-loop optimization of payment channel routing decisions.

[0081] This embodiment provides a payment processing method that abstracts and merges multiple underlying payment channels into a preset payment type, allowing product configuration to be associated only with the payment type rather than the specific payment channel. This achieves decoupling and centralized management of payment configuration and business logic. Furthermore, by acquiring and dynamically determining the final payment channel based on the status information of each channel in real time, intelligent routing decisions are realized. This avoids configuration redundancy and errors caused by directly binding payment channels to products, and overcomes the problem of high failure rates due to reliance on manual static rules leading to the continuous recommendation of payment channels. This reduces configuration and maintenance costs and improves payment success rate and member conversion efficiency.

[0082] This embodiment provides a solution for intelligent routing of order payment methods, which can be applied to payment processing systems. Figure 3 This is a schematic diagram illustrating the working principle of the payment processing system in this embodiment. The payment processing system includes the following functional modules: a distributed configuration module, a business input module, a payment type abstraction module, a centralized configuration management module, a data acquisition module, an AI dynamic optimization module, a routing engine module, and a payment channel invocation module. These modules work together to enable users to pay for goods. The functions of each module are explained below: Distributed configuration module: The configuration base, which stores static configurations such as adaptation rules for each preset payment channel, mapping relationships between payment types and each preset payment channel, and outputs rule information to the centralized configuration management module.

[0083] Business Input Module: The front-end information entry point, which receives the user's payment scenario, device information, payment amount, and object level and passes them to the payment type abstract module.

[0084] Payment type abstraction module: performs mapping and conversion between business and payment types, transforms front-end information into standardized payment type results, and outputs them to the centralized configuration management module.

[0085] Centralized configuration management module: Integrates configuration rules and payment type results, initially identifies the range of candidate payment channels that meet the basic conditions, and passes them to the routing engine module.

[0086] Data acquisition module: Full-link data acquisition and closed-loop feedback, real-time acquisition of data such as channel success rate, channel latency and channel selection rate of preset payment channels, and synchronization to AI dynamic optimization module; at the same time, it receives payment result feedback from payment channel calling module.

[0087] AI Dynamic Optimization Module: Based on real-time collected data and weights, it outputs dynamic decision-making basis for preset payment channels to the routing engine.

[0088] Routing engine module: Integrates payment channel range and dynamic optimization data, determines the optimal target payment channel through decision-making, and issues instructions to the payment channel calling module.

[0089] Payment channel invocation module: Receives instructions from the target payment channel, parses and sends them to the user end, and simultaneously sends the actual payment result back to the data acquisition layer, forming a closed loop.

[0090] The following is an example illustrating the entire payment processing flow: Scenario setting: A user places an order for the target product—a Gold Continuous Monthly Membership Package (25 RMB / month) on the iQiyi APP (device type: mobile phone, device version: iOS 15.4), and the user selects WeChat Pay as the target payment method. The user's corresponding object type is Gold Member.

[0091] WeChat Pay offers three default payment channels: WeChat App Payment, WeChat JSAPI Payment, and WeChat Contracted Debit Payment. WeChat App Payment supports the following scenarios: app, mobile phone, iOS version 12 or higher, and membership level 1 or higher (Gold Member). The default payment amount range is 0-5000 RMB. WeChat JSAPI Payment supports H5 / Mini Programs, PC, iOS version 12 or lower, and membership level 1 or lower (Gold Member). The default payment amount range is also 0-5000 RMB. WeChat Contracted Debit Payment supports the following scenarios: app, mobile phone, iOS version 12 or higher, and membership level 1 or higher (Gold Member). The default payment amount range is also 0-5000 RMB.

[0092] The system filters WeChat APP payments, WeChat JSAPI payments, and WeChat deductions after signing a contract based on payment scenario, device type, device version number, object level, and preset payment amount range, in order to filter out WeChat JSAPI payments.

[0093] The channel status information corresponding to WeChat APP payment and WeChat contract deduction is determined, and the target channel score corresponding to WeChat APP payment and WeChat contract deduction is determined based on the channel status information.

[0094] The target channel score for WeChat App payment and the target channel score for WeChat contract deduction were determined, and it was ultimately determined that the target channel score for WeChat App payment was greater than the target channel score for WeChat contract deduction.

[0095] The WeChat App payment channel is distributed, and users initiate payment through the WeChat App. If the user completes the payment, the channel status information corresponding to the WeChat App payment is updated; if the payment fails (e.g., the user cancels), the reason for the failure is recorded, and the weights corresponding to channel success rate, channel latency, and channel selection rate in that payment channel are adjusted.

[0096] refer to Figure 4 , Figure 4 This is a schematic diagram of a payment processing device provided in an embodiment of this application. The payment processing device provided in this embodiment includes: a type determination module 10, an information determination module 20, a channel determination module 30, and a payment module 40. The type determination module 10 is used to determine the target payment type corresponding to the target product from at least one preset payment type configured for the target product in response to a payment request for the target product, wherein each preset payment type corresponds to at least one preset payment channel; the information determination module 20 is used to determine the channel status information of each preset payment channel corresponding to the target payment type; the channel determination module 30 is used to determine the target payment channel from each preset payment channel corresponding to the target payment type based on the obtained channel status information; and the payment module 40 is used to make payment for the target product based on the target payment channel.

[0097] In this embodiment, the channel determination module 30 is further configured to: For each preset payment channel corresponding to the target payment type, a target channel score is determined based on the channel status information corresponding to the preset payment channel. The highest target channel score is determined from all the target channel scores obtained; Based on the preset payment channel corresponding to the highest target channel score, the target payment channel is determined from each of the preset payment channels corresponding to the target payment type.

[0098] In this embodiment, the channel status information includes channel success rate, channel latency, and channel selection rate; the channel determination module 30 is further used for: Determine a first preset weight corresponding to the channel success rate, a second preset weight corresponding to the channel latency, and a third preset weight corresponding to the number of channel selections. Using the first preset weight, the second preset weight, and the third preset weight, the channel success rate, the channel latency, and the channel selection rate are weighted and summed to determine the target channel score corresponding to the preset payment channel. Wherein, the channel success rate is used to characterize the ratio between the number of successful payments through the preset payment channel and the number of payments made through the preset payment channel within the first sliding window; the channel latency is used to characterize the average response latency of the preset payment channel within the second sliding window; and the channel selection rate is used to indicate the ratio between the number of payments made through the preset payment channel and the total number of payments made through all preset payment channels under the target payment type within the third sliding window.

[0099] In this embodiment, the channel determination module 30 is further configured to: Based on the channel status information corresponding to the preset payment channel, determine the initial channel score corresponding to the preset payment channel; Determine whether the preset payment channel is associated with a preset adjustment strategy, wherein the preset adjustment strategy is used to characterize the strategy for adjusting the initial channel score corresponding to the preset payment channel; When the preset payment channel is associated with the preset adjustment strategy, the preset adjustment strategy is used to adjust the initial channel score in order to determine the target channel score corresponding to the preset payment channel.

[0100] In this embodiment, the information determination module 20 is further configured to: Determine the payment scenario corresponding to the target product and the device information of the payment device used to pay for the target product; Filter out all preset payment channels that meet the first preset condition from all preset payment channels corresponding to the target payment type to obtain a preset payment channel set corresponding to the target payment type. The first preset condition includes: the preset payment channel does not support the payment scenario and does not support the device information. Determine the channel status information of each of the preset payment channels in the preset payment channel set.

[0101] In this embodiment, the information determination module 20 is further configured to: Obtain the payment amount corresponding to the target product and the object level corresponding to the target object paying for the target product; The preset payment channels that meet the second preset condition are filtered out from the preset payment channel set to complete the update of the preset payment channel set. The second preset condition includes: the preset payment amount range corresponding to the preset payment channel does not include the payment amount and the preset payment channel does not support the object level. Determine the channel status information of each preset payment channel in the updated preset payment channel set.

[0102] In this embodiment, the channel determination module 30 is further configured to: When there are multiple highest target channel scores, determine the channel priority of the preset payment channel corresponding to each highest target channel score; Based on the channel priority, channel success rate, and channel latency of the preset payment channels corresponding to the highest target channel scores, the target payment channel is determined from the preset payment channels corresponding to the highest target channel scores.

[0103] This embodiment provides a payment processing device that abstracts and merges multiple underlying payment channels into a preset payment type, allowing product configuration to be associated only with the payment type rather than the specific payment channel. This achieves decoupling and centralized management of payment configuration and business logic. Furthermore, by acquiring and dynamically determining the final payment channel based on the status information of each channel in real time, intelligent routing decisions are realized. This avoids configuration redundancy and errors caused by directly binding payment channels to products, and overcomes the problem of high-failure-rate payment channels being continuously recommended due to reliance on manual static rules. This reduces configuration and maintenance costs and improves payment success rate and member conversion efficiency.

[0104] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 5 The illustrated electronic device 500 includes at least one processor 501, a memory 502, at least one network interface 504, and other user interfaces 503. The various components in the electronic device 500 are coupled together via a bus system 505. It is understood that the bus system 505 is used to implement communication between these components. In addition to a data bus, the bus system 505 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 5 The general designated all buses as Bus System 505.

[0105] The user interface 503 may include a display, keyboard, or clicking device (e.g., mouse, trackball, touchpad, or touchscreen).

[0106] It is understood that the memory 502 in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 502 described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0107] In some implementations, memory 502 stores elements, executable units or data structures, or subsets thereof, or extended sets thereof: operating system 5021 and application program 5022.

[0108] The operating system 5021 includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application program 5022 includes various applications, such as a media player and a browser, used to implement various application functions. Programs implementing the methods of this application embodiment can be included in application program 5022.

[0109] In this embodiment of the application, the processor 501 executes the method steps provided in each method embodiment by calling the program or instructions stored in the memory 502, specifically the program or instructions stored in the application program 5022.

[0110] The methods disclosed in the embodiments of this application can be applied to or implemented by processor 501. Processor 501 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware or by instructions in the form of software in processor 501. The processor 401 mentioned above may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software units in the decoding processor. The software units may be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 502. Processor 501 reads the information in memory 502 and, in conjunction with its hardware, completes the steps of the above method.

[0111] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or combinations thereof.

[0112] For software implementation, the techniques described herein can be implemented by units that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented in the processor or external to the processor.

[0113] The electronic device provided in this embodiment may be as follows: Figure 5 The electronic device shown can perform the following: Figure 1 and Figure 2 All steps of the payment processing method in China, thereby achieving Figure 1 and Figure 2 For details on the technical effects of the payment processing method shown, please refer to [link / reference]. Figure 1 and Figure 2 The relevant descriptions are presented concisely and will not be elaborated upon here.

[0114] This application also provides a storage medium (computer-readable storage medium). This storage medium stores one or more programs. The storage medium may include volatile memory, such as random access memory; it may also include non-volatile memory, such as read-only memory, flash memory, hard disk, or solid-state drive; and it may also include combinations of the above types of memory.

[0115] One or more programs in the storage medium can be executed by one or more processors to implement the payment processing method described above that is executed on the payment processing device side.

[0116] The processor is used to execute a payment processing program stored in the memory to implement the steps of the payment processing method executed on the payment processing device side.

[0117] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0118] It should be noted that the terms "one implementation," "embodiment," "exemplary embodiment," and "some embodiments" used in the specification indicate that the described embodiment may include a specific feature, structure, or characteristic, but not every embodiment necessarily includes that specific feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Moreover, when a specific feature, structure, or characteristic is described in connection with an embodiment, implementing such a feature, structure, or characteristic in conjunction with other embodiments, whether explicitly described or not, is within the knowledge scope of those skilled in the art.

[0119] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

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

Claims

1. A payment processing method, characterized in that, include: In response to a payment request for a target product, a target payment type corresponding to the target product is determined from at least one preset payment type configured for the target product, and each preset payment type corresponds to at least one preset payment channel; Determine the channel status information of each of the preset payment channels corresponding to the target payment type; Based on the obtained channel status information, the target payment channel is determined from each of the preset payment channels corresponding to the target payment type; Payment is made for the target product based on the target payment channel.

2. The method according to claim 1, characterized in that, The step of determining the target payment channel from the preset payment channels corresponding to the target payment type based on the obtained channel status information includes: For each preset payment channel corresponding to the target payment type, a target channel score is determined based on the channel status information corresponding to the preset payment channel. The highest target channel score is determined from all the target channel scores obtained; Based on the preset payment channel corresponding to the highest target channel score, the target payment channel is determined from each of the preset payment channels corresponding to the target payment type.

3. The method according to claim 2, characterized in that, The channel status information includes channel success rate, channel latency, and channel selection rate. The step of determining the target channel score corresponding to the preset payment channel based on the channel status information corresponding to the preset payment channel includes: Determine a first preset weight corresponding to the channel success rate, a second preset weight corresponding to the channel latency, and a third preset weight corresponding to the number of channel selections. Using the first preset weight, the second preset weight, and the third preset weight, the channel success rate, the channel latency, and the channel selection rate are weighted and summed to determine the target channel score corresponding to the preset payment channel. Wherein, the channel success rate is used to characterize the ratio between the number of successful payments through the preset payment channel and the number of payments made through the preset payment channel within the first sliding window; the channel latency is used to characterize the average response latency of the preset payment channel within the second sliding window; and the channel selection rate is used to indicate the ratio between the number of payments made through the preset payment channel and the total number of payments made through all preset payment channels under the target payment type within the third sliding window.

4. The method according to claim 2, characterized in that, The step of determining the target channel score corresponding to the preset payment channel based on the channel status information corresponding to the preset payment channel includes... Based on the channel status information corresponding to the preset payment channel, determine the initial channel score corresponding to the preset payment channel; Determine whether the preset payment channel is associated with a preset adjustment strategy, wherein the preset adjustment strategy is used to characterize the strategy for adjusting the initial channel score corresponding to the preset payment channel; When the preset payment channel is associated with the preset adjustment strategy, the preset adjustment strategy is used to adjust the initial channel score in order to determine the target channel score corresponding to the preset payment channel.

5. The method according to claim 1, characterized in that, The determination of the channel status information for each preset payment channel corresponding to the target payment type includes: Determine the payment scenario corresponding to the target product and the device information of the payment device used to pay for the target product; Filter out all preset payment channels that meet the first preset condition from all preset payment channels corresponding to the target payment type to obtain a preset payment channel set corresponding to the target payment type. The first preset condition includes: the preset payment channel does not support the payment scenario and does not support the device information. Determine the channel status information of each of the preset payment channels in the preset payment channel set.

6. The method according to claim 5, characterized in that, The step of determining the channel status information of each of the preset payment channels in the preset payment channel set includes: Obtain the payment amount corresponding to the target product and the object level corresponding to the target object paying for the target product; The preset payment channels that meet the second preset condition are filtered out from the preset payment channel set to complete the update of the preset payment channel set. The second preset condition includes: the preset payment amount range corresponding to the preset payment channel does not include the payment amount and the preset payment channel does not support the object level. Determine the channel status information of each preset payment channel in the updated preset payment channel set.

7. The method according to claim 3, characterized in that, The determination of the target payment channel from the preset payment channels corresponding to the target payment type, based on the preset payment channel corresponding to the highest target channel score, includes: When there are multiple highest target channel scores, determine the channel priority of the preset payment channel corresponding to each highest target channel score; Based on the channel priority, channel success rate, and channel latency of the preset payment channels corresponding to the highest target channel scores, the target payment channel is determined from the preset payment channels corresponding to the highest target channel scores.

8. A payment processing device, characterized in that, include: The type determination module is used to determine the target payment type corresponding to the target product from at least one preset payment type configured for the target product in response to the payment request of the target product, wherein each preset payment type corresponds to at least one preset payment channel; The information determination module is used to determine the channel status information of each of the preset payment channels corresponding to the target payment type; The channel determination module is used to determine the target payment channel from the preset payment channels corresponding to the target payment type based on the obtained channel status information. The payment module is used to make payment for the target product based on the target payment channel.

9. An electronic device, characterized in that, include: A processor and a memory, the processor being configured to execute a payment processing program stored in the memory to implement the payment processing method according to any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores one or more programs, which can be executed by one or more processors to implement the payment processing method according to any one of claims 1 to 7.

Images