Payment processing method and apparatus

Abstract

The embodiments of the present specification provide payment processing methods and devices, wherein a payment processing method comprises: creating a retry task of a payment order based on a payment failure result of the payment order sent by a payment platform; the retry task comprises performing pre-check and performing payment retry; starting the retry task, and cooperating with the payment platform to perform pre-check of the payment order; if the pre-check is successful, cooperating with the payment platform to perform payment retry of the payment order, and obtaining a payment retry result; and performing processing of the retry task according to the payment retry result.

Description

Technical Field

[0001] This document relates to the field of payment technology, and in particular to a payment processing method and apparatus. Background Technology

[0002] With the continuous development of online transactions, more and more users are choosing to shop online on electronic trading platforms. The types of products involved in the transactions are becoming increasingly diverse, and the frequency of payments during the transaction process is also increasing. For payment platforms that provide payment functions during the transaction process, improving the convenience and success rate of payments is crucial to increasing the use of their payment functions by all parties. However, in many payment scenarios, the success rate of payments is still not very high and fluctuates greatly. This places higher demands on payment platforms to improve the success rate of payments and the payment experience. Summary of the Invention

[0003] This specification provides one or more embodiments of a payment processing method, including: creating a retry task for a payment order based on a payment failure result sent by a payment platform. The retry task includes performing pre-verification and payment retries. The retry task is initiated, and pre-verification of the payment order is performed in cooperation with the payment platform. If the pre-verification is successful, payment retries of the payment order are performed in cooperation with the payment platform to obtain a payment retry result. The retry task is then processed based on the payment retry result.

[0004] This specification provides one or more embodiments of another payment processing method, including: processing a merchant's payment order and sending a payment failure result to a front-end system. The front-end system creates a retry task based on the payment failure result. The retry task includes performing pre-verification and payment retries. Pre-verification of the payment order is performed in cooperation with the front-end system. If the pre-verification is successful, a payment retry is performed in cooperation with the front-end system, and a payment retry result is returned to the front-end system.

[0005] This specification provides one or more embodiments of a payment processing apparatus, including: a retry task creation module configured to create a retry task for a payment order based on a payment failure result sent by a payment platform. The retry task includes performing pre-verification and performing a payment retrieval. A pre-verification module configured to initiate the retry task and cooperate with the payment platform to perform pre-verification of the payment order. A payment retry module configured to, if the pre-verification is successful, cooperate with the payment platform to perform a payment retrieval of the payment order and obtain a payment retry result. A retry task processing module configured to process the retry task based on the payment retry result.

[0006] This specification provides one or more embodiments of another payment processing apparatus, including: a payment processing module configured to process a merchant's payment order and send a payment failure result to a front-end system. The front-end system creates a retry task based on the payment failure result, the retry task including performing pre-verification and performing a payment retrieval. A pre-verification module is configured to cooperate with the front-end system to perform pre-verification of the payment order. A payment retry module is configured to, if the pre-verification is successful, cooperate with the front-end system to perform a payment retrieval of the payment order and return a payment retry result to the front-end system.

[0007] This specification provides one or more embodiments of a payment processing device, including: a processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to: create a retry task for a payment order based on a payment failure result sent by a payment platform. The retry task includes performing pre-verification and retrying the payment. The retry task is initiated, and pre-verification of the payment order is performed in cooperation with the payment platform. If the pre-verification is successful, the payment order is retried in cooperation with the payment platform to obtain a payment retry result. The retry task is then processed based on the payment retry result.

[0008] This specification provides one or more embodiments of another payment processing device, including: a processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to: process a merchant's payment order and send a payment failure result to a front-end system. The front-end system creates a retry task based on the payment failure result. The retry task includes performing pre-verification and retrying the payment. Pre-verification of the payment order is performed in cooperation with the front-end system. If the pre-verification is successful, a payment retry is performed in cooperation with the front-end system, and a payment retry result is returned to the front-end system.

[0009] This specification provides one or more embodiments of a storage medium for storing computer-executable instructions, which, when executed by a processor, implement the following process: Based on a payment failure result of a payment order sent by a payment platform, a retry task for the payment order is created. The retry task includes performing pre-verification and payment retries. The retry task is initiated, and pre-verification of the payment order is performed in cooperation with the payment platform. If the pre-verification is successful, payment retries of the payment order are performed in cooperation with the payment platform, and a payment retry result is obtained. The retry task is then processed based on the payment retry result.

[0010] This specification provides one or more embodiments of another storage medium for storing computer-executable instructions that, when executed by a processor, implement the following process: processing a merchant's payment order and sending a payment failure result to a front-end system. The front-end system creates a retry task based on the payment failure result. The retry task includes performing pre-verification and payment retries. Pre-verification of the payment order is performed in cooperation with the front-end system. If the pre-verification is successful, a payment retry is performed in cooperation with the front-end system, and a payment retry result is returned to the front-end system. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in one or more embodiments of this specification or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart illustrating a payment processing method provided in one or more embodiments of this specification;

[0013] Figure 2 A timing diagram illustrating a payment processing method for a direct debit payment scenario provided in one or more embodiments of this specification;

[0014] Figure 3 A flowchart illustrating another payment processing method provided in one or more embodiments of this specification;

[0015] Figure 4 A schematic diagram of a payment processing device provided for one or more embodiments of this specification;

[0016] Figure 5 A schematic diagram of another payment processing device provided in one or more embodiments of this specification;

[0017] Figure 6 This specification provides a schematic diagram of the structure of a payment processing device according to one or more embodiments.

[0018] Figure 7 This is a schematic diagram of another payment processing device provided in one or more embodiments of this specification. Detailed Implementation

[0019] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of the embodiments. Based on one or more embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this document.

[0020] This specification provides an example of a payment processing method:

[0021] The payment processing method provided in this application creates a retry task consisting of pre-verification of the payment order and payment retry when the payment platform fails to process the payment order. After the retry task is initiated, the pre-verification of the payment order is performed in cooperation with the payment platform. If the pre-verification is successful, the payment order is retried in cooperation with the payment platform. The retry task is then processed accordingly based on the payment retry results. This pre-verification simulates potential problems in the payment process, enabling the targeted identification of issues. If no problems are found in the payment process, the payment order is retried, thereby improving the payment success rate.

[0022] Step S102: Based on the payment failure result of the payment order sent by the payment platform, create a retry task for the payment order.

[0023] In this embodiment, the payment failure result of the payment order refers to the payment result obtained by the payment platform in the event of payment failure during the payment processing of the payment order. Optionally, the payment failure result is obtained after the payment order has been deducted, that is, the payment failure result is the deduction failure result of the payment order's deduction payment. Specifically, during the deduction payment process of the payment order, a deduction agreement signed by the user, merchant, and payment platform can be used. Based on this deduction agreement, the merchant can initiate a deduction from the user's account for the corresponding user order. Specifically, this is done by submitting a deduction request for the user order to the payment platform, which then generates a payment order for the user order and deducts the corresponding funds from the user's account to complete the payment order.

[0024] The retry task refers to a task used to re-execute the payment processing procedure of a payment order. Optionally, the retry task includes performing pre-verification and payment retries; wherein, the pre-verification refers to verifying potential problems in the payment process by simulating the payment process of the payment order before the payment processing of the payment order, such as performing risk detection on the payment order to check for potential risks, or performing payment rule verification on the payment order.

[0025] The payment retry refers to re-executing the payment process. Optionally, the payment retry may include re-executing the deduction payment, i.e., deduction payment retry, based on the payment failure result obtained after deducting payment for the payment order.

[0026] This embodiment simulates potential problems in the payment process of a payment order by performing pre-verification, which can specifically identify problems in the payment process. In addition, it detects whether the actual payment processing of the payment order can be successful through payment retries. In this way, by including pre-verification and payment retries in the retry task, the payment success rate of payment orders can be improved, thereby improving the payment experience.

[0027] In practice, the payment platform processes the merchant's payment order and returns a payment failure result if the payment processing fails. Here, a retry task for the payment order is created based on the payment failure result, so as to improve the payment success rate of the payment order by executing the created retry task in the future.

[0028] To further improve the order payment experience, an effective payment time can be set for the payment order. Within the effective payment time, payment retries can be performed to improve the payment success rate of the payment order, thereby reducing the possibility that the merchant perceives a payment failure. In one optional implementation of this embodiment, the effective payment time of the payment order is set before starting the retry task and cooperating with the payment platform to perform pre-verification of the payment order. Specifically, the effective payment time of the payment order can be set after the retry task of the payment order is created.

[0029] The effective payment time refers to the time range set for processing payment orders. Within this time range, payment processing and / or payment retries are permitted; outside this time range, payment processing and / or payment retries are no longer allowed. Specifically, the duration of the effective payment time can be determined based on the order information, such as the order type. Furthermore, the duration of the effective payment time can also be agreed upon in a deduction agreement signed by the user, merchant, and payment platform, for example, the effective payment time stipulated in the deduction agreement as x hours or x days.

[0030] It should be noted that, in addition to setting a valid payment time for the payment order, to avoid a negative payment experience caused by sending the payment failure result to the merchant too early, optionally, the payment failure result is sent to the merchant corresponding to the payment order at the end of the valid payment time. That is, the payment failure result is intercepted and sent to the merchant corresponding to the payment order at the end of the valid payment time. Similarly, the payment retry result obtained during the payment retry process described below can also be sent to the merchant corresponding to the payment order at the end of the valid payment time.

[0031] Step S104: Initiate the retry task and cooperate with the payment platform to perform pre-verification of the payment order.

[0032] In specific implementation, based on the retry task of the payment order created above, the retry task is initiated. Specifically, during the initiation of the retry task, it can be detected whether the valid payment time of the payment order has ended, thereby detecting whether the current retry task is within the valid payment time range of the payment order. If it has not ended, the task data of the retry task is read; if it has ended, the payment failure message is sent to the merchant corresponding to the payment order. In addition, during the initiation of the retry task, the retry task can also be read from the task queue, and the task data of the retry task can be read, thereby preparing for the pre-verification of the subsequent retry task and the execution of payment retry.

[0033] In this embodiment, the pre-verification of the payment order is performed in cooperation with the payment platform. One optional implementation of this embodiment includes the following:

[0034] Send a pre-verification request for the payment order to the payment platform;

[0035] Receive the pre-verification result returned by the payment platform; wherein the pre-verification result is either pre-verification successful or pre-verification failed.

[0036] In practical applications, there may be situations where payment channels support payment verification, or there may be situations where payment channels do not support payment verification. In response to this, this embodiment provides the following two optional implementation methods for the pre-verification process of the payment order in cooperation with payment platforms.

[0037] Implementation Method 1

[0038] Based on the aforementioned pre-verification request for the payment order sent to the payment platform, the payment platform performs the following operations upon receiving the pre-verification request:

[0039] The payment order is subject to risk detection, and the payment rule is verified after the risk detection is passed.

[0040] If the payment rule verification is successful, an account verification request is sent to the payment channel corresponding to the payment order;

[0041] Receive the account verification result returned by the payment channel, and return the account verification result as the pre-verification result.

[0042] The risk detection of the payment order refers to checking whether the payment order meets the corresponding risk rules. If it meets the risk rules, the risk detection passes; if it does not meet the risk rules, the risk detection fails. In the case of a failed risk detection, the failure can also be returned as the result of the pre-verification. This allows us to know the reason for the failure of the pre-verification by the returned pre-verification result, thereby improving our understanding of the reasons for the payment failure.

[0043] Payment rule verification for the payment order refers to checking whether the payment order meets the corresponding payment rules. For example, if the payment rule requires the merchant's location to match the currency supported by the current region, then it checks whether the currency used to pay for the payment order is a currency supported by the merchant's location. If so, the payment rule verification is successful; otherwise, the payment rule verification fails. In the case of payment rule verification failure, the failure can also be returned as the pre-verification result. This allows us to know the reason for the pre-verification failure, namely the payment rule verification failure, thereby improving our understanding of the reasons for payment order failures.

[0044] Optionally, the account verification result is generated after the payment channel verifies the account balance of the payment account (user account) corresponding to the payment order against the order amount of the payment order. Specifically, during execution, an account verification request is sent to the payment channel corresponding to the payment order. Upon receiving the request, the payment channel verifies whether the account balance of the payment account (user account) corresponding to the payment order meets the order amount. If it does, a successful account verification result is generated and sent to the payment platform; otherwise, a failed account verification result is generated and sent to the payment platform.

[0045] The above-described implementation method for pre-verification of payment orders provided in this embodiment can locate the stage in the payment processing that leads to payment failure. By implementing the above-described pre-verification method, it is possible to verify which stage in the payment process might cause the payment failure, thereby enabling targeted solutions to address the reasons for the payment failure and improving the order payment success rate.

[0046] Implementation Method Two

[0047] Based on the aforementioned pre-verification request for the payment order sent to the payment platform, the payment platform performs the following operations upon receiving the pre-verification request:

[0048] Perform risk detection on the payment order;

[0049] If the risk detection passes, the payment order is verified for payment rules, and the verification result is returned as the pre-verification result; wherein, the verification result is either successful or unsuccessful.

[0050] If the risk detection fails, the failure to detect the risk will be returned as the result of the pre-verification. This allows us to know the reason for the failure of the pre-verification by the returned result of the risk detection, thereby improving our understanding of the reasons for payment failure of payment orders.

[0051] In practice, after the pre-verification of the payment order is performed, if the pre-verification is successful, the following payment retry operation is performed in cooperation with the payment platform.

[0052] If the pre-verification fails, the payment retry operation for the payment order, which involves cooperation with the payment platform, will not be executed. In addition, based on the aforementioned setting of the effective payment time for the payment order, in the event of pre-verification failure, the effective payment time can be processed according to the verification failure type corresponding to the pre-verification failure, thereby improving the accuracy and comprehensiveness of the pre-verification. This processing includes either maintaining the effective payment time or deleting the effective payment time. Alternatively, in the event of pre-verification failure, an execution time for the retry task can be set to restart the retry task at the end of the execution time, thereby improving the order payment success rate.

[0053] Step S106: If the pre-verification is successful, cooperate with the payment platform to retry the payment order and obtain the payment retry result.

[0054] After the aforementioned pre-verification of the payment order in cooperation with the payment platform, if the pre-verification is successful, a payment retry is performed to obtain the payment retry result. Specifically, the payment retry for the payment order is performed in cooperation with the payment platform. Optionally, the payment retry for the payment order includes: re-performing the automatic deduction payment for the payment order.

[0055] In one optional implementation of this embodiment, the payment retry is performed in cooperation with the payment platform to obtain the payment retry result, including:

[0056] Send a payment retry instruction for the payment order to the payment platform;

[0057] Receive the payment retry result returned by the payment platform; the payment retry result is either payment retry successful or payment retry failed.

[0058] Optionally, after receiving the payment retry instruction, the payment platform performs the following operations:

[0059] The payment order is subject to risk detection, and the payment rule is verified after the risk detection is passed.

[0060] If the payment rule verification is successful, a payment deduction instruction is sent to the corresponding payment channel, and the payment deduction result of the payment channel is returned as the payment retry result.

[0061] It should be noted that the risk detection and payment rule verification performed during the payment retry process here are the same processing logic as those performed during the pre-verification process, which is the same as the payment order payment process. The difference is that the risk detection performed during the pre-verification process only simulates the risk detection of the payment order during the payment process, and the result returned is the risk detection result of whether the risk detection of the simulated payment passed or failed; while the risk detection performed during the payment retry process is the actual risk detection of the payment order, and the result returned is the risk detection result of whether the risk detection of the actual payment order passed or failed.

[0062] Similarly, the payment rule verification performed during the pre-verification process is merely a payment rule verification for a simulated payment order during the payment process. The result returned after the payment rule verification is either successful or unsuccessful for the simulated payment. However, the payment rule verification performed during the payment retry process is a payment rule verification for the actual payment order. The result returned after the payment rule verification is either successful or unsuccessful for the actual payment of the payment order.

[0063] Therefore, the specific implementation methods for risk detection and payment rule verification can be found in the detailed instructions on risk detection and payment rule verification provided above, and will not be repeated here.

[0064] In practical applications, based on the above-mentioned setting of the effective payment time of the payment order, and assuming successful pre-verification, the effective payment time detection operation can also be performed before cooperating with the payment platform to retry the payment of the payment order. This embodiment provides the detection of whether the effective payment time of the payment order has ended.

[0065] If the transaction is not completed, then the payment retry operation for the payment order in cooperation with the payment platform will be performed.

[0066] If the transaction has ended, the payment failure result of the payment order or the pre-verification result of the pre-verification will be returned to the merchant corresponding to the payment order, so that the merchant can promptly perceive the reason for the payment failure after the valid payment time has ended.

[0067] Step S108: Process the retry task based on the payment retry result.

[0068] In this step, the retry task is processed based on the payment retry result of the payment order retry in cooperation with the payment platform. As mentioned above, the payment retry result is either payment retry successful or payment failure. Based on this, in an optional implementation provided in this embodiment, if the payment retry result is payment retry failure, the execution time of the retry task is set so that the retry task can be restarted at the execution time; furthermore, if the payment retry result is payment retry successful, the retry task can be deleted.

[0069] The above-described payment processing method can be implemented by a front-end system. The following method embodiment provides another payment processing method that can be implemented by a payment platform. The two cooperate with each other during execution. Therefore, the above implementation process can be read with reference to the corresponding content of the following method embodiment. Similarly, the following implementation process can also be read with reference to the corresponding content of the above method embodiment.

[0070] The following example uses a payment processing method provided in this embodiment to illustrate its application in a direct debit payment scenario. Figure 2 The payment processing method provided in this embodiment will be further explained below. Figure 2 The payment processing method applied to direct debit payment scenarios includes the following steps.

[0071] Step S218: Receive the deduction failure result returned by the acquiring system of the payment platform, and create a retry task for the payment order based on the deduction failure result.

[0072] Step S220: Set the valid payment time for the payment order.

[0073] Step S222: Initiate the retry task and send a pre-verification request for the payment order to the acquiring system.

[0074] Step S242: If the pre-verification result is successful, check whether the valid payment time of the payment order has ended;

[0075] If so, return the deduction failure result and the pre-verification result to the merchant;

[0076] If not, proceed to step S244.

[0077] Step S244: Send a payment retry instruction for the payment order to the acquiring system.

[0078] Step S264: If the payment retry result is successful, then delete the retry task.

[0079] In addition, if the payment retry result is a payment retry failure, the execution time of the retry task is set so that the retry task can be restarted at the execution time.

[0080] Steps S218 to S264 provided in this embodiment are executed by the front-end system. It should be noted that the execution of steps S218 to S264 by the front-end system is coordinated with the execution of steps S202 to S262 by the payment platform in the following embodiment. Therefore, when reading this embodiment, please refer to the corresponding content of steps S202 to S262 below. Correspondingly, when reading steps S202 to S262 below, please also refer to the corresponding content of steps S218 to S264 provided in this embodiment.

[0081] Another payment processing method embodiment provided in this specification:

[0082] Step S302: Process the merchant's payment order and send the payment failure result to the front-end system.

[0083] In this embodiment, the payment failure result refers to the payment result obtained when payment fails during the payment processing of the payment order. Optionally, the payment failure result is obtained after the payment order has been deducted, that is, the payment failure result is the deduction failure result of the payment order's deduction payment. Specifically, during the deduction payment process for the payment order, a deduction agreement signed by the user, merchant, and payment platform can be used. Based on this deduction agreement, the merchant can initiate a deduction from the user's account for the corresponding user order. Specifically, this is done by submitting a deduction request for the user order to the payment platform, which then generates a payment order for the user order and deducts the corresponding funds from the user's account to complete the payment order.

[0084] In specific implementation, after the payment failure result is sent to the front-end system, optionally, the front-end system creates a retry task for the payment order based on the payment failure result. The retry task includes performing front-end verification and performing payment retry.

[0085] The retry task refers to a task used to re-execute the payment processing procedure of a payment order. Optionally, the retry task includes performing pre-verification and payment retries; wherein, the pre-verification refers to verifying potential problems in the payment process by simulating the payment process of the payment order before the payment processing of the payment order, such as performing risk detection on the payment order to check for potential risks, or performing payment rule verification on the payment order.

[0086] The payment retry refers to re-executing the payment process. Optionally, the payment retry may include re-executing the deduction payment, i.e., deduction payment retry, based on the payment failure result obtained after deducting payment for the payment order.

[0087] This embodiment simulates potential problems in the payment process of a payment order by performing pre-verification, which can specifically identify problems in the payment process. In addition, it detects whether the actual payment processing of the payment order can be successful through payment retries. In this way, by including pre-verification and payment retries in the retry task, the payment success rate of payment orders can be improved, thereby improving the payment experience.

[0088] To further improve the order payment experience, an effective payment time can be set for the payment order. Within the effective payment time, payment retries can be made to improve the payment success rate of the payment order, thereby reducing the possibility that the merchant will perceive a payment failure. In one optional implementation of this embodiment, the effective payment time of the payment order is set by the front-end system; specifically, the effective payment time of the payment order can be set after the retry task of the payment order is created.

[0089] The effective payment time refers to the time range set for processing payment orders. Within this time range, payment processing and / or payment retries are permitted; outside this time range, payment processing and / or payment retries are no longer allowed. Specifically, the duration of the effective payment time can be determined based on the order information, such as the order type. Furthermore, the duration of the effective payment time can also be agreed upon in a deduction agreement signed by the user, merchant, and payment platform, for example, the effective payment time stipulated in the deduction agreement as x hours or x days.

[0090] It should be noted that, in addition to setting a valid payment time for the payment order, in order to avoid negative payment experience caused by sending the payment failure result to the merchant too early, the payment failure result may optionally be sent to the merchant corresponding to the payment order at the end of the valid payment time. That is, the payment failure result is intercepted and sent to the merchant corresponding to the payment order at the end of the valid payment time.

[0091] Step S304: Perform pre-verification of the payment order in conjunction with the front-end system.

[0092] The pre-verification of the payment order is initiated by the front-end system. After the front-end system initiates the execution of the pre-verification, the payment order is verified in cooperation with the front-end system. In practical applications, there may be situations where the payment channel supports payment verification, or there may be situations where the payment channel does not support payment verification. In view of this, this embodiment provides the following two optional implementation methods for cooperating in the pre-verification process of the payment order.

[0093] In the first optional implementation provided in this embodiment, the pre-verification of the payment order is performed in conjunction with the front-end system, including:

[0094] Receive the pre-verification request for the payment order sent by the front-end system;

[0095] In response to the pre-verification request, risk detection is performed on the payment order, and payment rule verification is performed on the payment order after the risk detection passes;

[0096] If the payment rule verification is successful, an account verification request is sent to the payment channel corresponding to the payment order;

[0097] The account verification result returned by the payment channel is returned to the front-end system as the pre-verification result.

[0098] The risk detection of the payment order refers to checking whether the payment order meets the corresponding risk rules. If it meets the risk rules, the risk detection passes; if it does not meet the risk rules, the risk detection fails. In the case of a failed risk detection, the failure can be returned to the front-end system, which can also return the failed risk detection as a front-end verification result. This allows the system to understand the reason for the failure of the front-end verification by the returned front-end verification result, thereby improving the perception of the reasons for payment failure.

[0099] Payment rule verification for the payment order refers to checking whether the payment order meets the corresponding payment rules. For example, if the payment rule requires the merchant's location to match the currency supported by the current region, then it checks whether the currency used to pay for the payment order is supported by the merchant's location. If so, the payment rule verification is successful; otherwise, it fails. In the event of payment rule verification failure, the failure can be returned to the front-end system. The front-end system can also return the payment rule verification failure as the front-end verification result, thereby allowing the user to know the reason for the front-end verification failure through the returned front-end verification result, which also improves the perception of the reasons for payment order failure.

[0100] Optionally, the account verification result is generated after the payment channel verifies the account balance of the payment account (user account) corresponding to the payment order against the order amount of the payment order. Specifically, during execution, an account verification request is sent to the payment channel corresponding to the payment order. Upon receiving the request, the payment channel verifies whether the account balance of the payment account (user account) corresponding to the payment order meets the order amount. If it does, a successful account verification result is generated and returned; otherwise, a failed account verification result is generated and returned.

[0101] The above-described implementation method for pre-verification of payment orders provided in this embodiment can locate the stage in the payment processing that leads to payment failure. By implementing the above-described pre-verification method, it is possible to verify which stage in the payment process might cause the payment failure, thereby enabling targeted solutions to address the reasons for the payment failure and improving the order payment success rate.

[0102] In the second optional implementation provided in this embodiment, the pre-verification of the payment order is performed in conjunction with the front-end system, including:

[0103] Receive the pre-verification request for the payment order sent by the front-end system;

[0104] In response to the pre-verification request, risk detection is performed on the payment order;

[0105] If the risk detection passes, the payment order is verified for payment rules, and the payment rule verification result is returned to the front-end system as the pre-verification result.

[0106] If the risk detection fails, the failure to detect the risk will be returned to the front-end system as the result of the pre-verification.

[0107] Step S306: If the pre-verification is successful, cooperate with the pre-system to retry the payment of the payment order and return the payment retry result to the pre-system.

[0108] The payment retry for the payment order is initiated by the front-end system. After the front-end system initiates the payment retry for the payment order, the system cooperates with the front-end system to perform the payment retry for the payment order and returns the payment retry result to the front-end system after the payment retry.

[0109] In one optional implementation of this embodiment, the payment retry for the payment order is performed in conjunction with the front-end system, and the payment retry result is returned to the front-end system, including:

[0110] Receive the payment retry instruction for the payment order sent by the front-end system;

[0111] In response to the payment retry instruction, a risk detection is performed on the payment order, and the payment rule is verified on the payment order after the risk detection is passed;

[0112] If the payment rule verification is successful, a payment deduction instruction is sent to the corresponding payment channel, and the payment deduction result of the payment channel is returned to the front-end system as the payment retry result.

[0113] In the specific execution process, after receiving the returned payment retry result, the front-end system can process the retry task according to the payment retry result. Specifically, processing the retry task according to the payment retry result includes: if the payment retry result is a payment retry failure, setting the execution time of the retry task to restart the retry task at the execution time; if the payment retry result is a payment retry success, deleting the retry task.

[0114] The payment processing method provided in this embodiment is applied to a payment platform. Optionally, the payment platform includes an acquiring system, a risk detection system, and a payment system.

[0115] Specifically, the pre-verification of payment orders, in conjunction with the front-end system, is implemented based on the acquiring system, the risk detection system, and the payment system. Specifically, the risk detection system performs risk detection on the payment orders, and the payment system verifies the payment rules. Similarly, the payment retry of payment orders, in conjunction with the front-end system, is also implemented based on the acquiring system, the risk detection system, and the payment system. Again, the risk detection system performs risk detection on the payment orders, and the payment system verifies the payment rules.

[0116] The following example uses a payment processing method provided in this embodiment to illustrate its application in a direct debit payment scenario. Figure 2 The payment processing method provided in this embodiment will be further explained below. Figure 2 The payment processing method applied to direct debit payment scenarios includes the following steps.

[0117] Step S202: The acquiring system receives the deduction request for the payment order submitted by the merchant.

[0118] The payment platform consists of an acquiring system, a risk detection system, and a payment system. It receives deduction requests for payment orders submitted by merchants, specifically the acquiring system.

[0119] Step S204: The acquiring system sends a risk detection request to the risk detection system.

[0120] In step S206, the risk detection system performs risk detection on the payment order and sends a payment verification instruction to the payment system.

[0121] In step S208, the payment system sends a deduction payment instruction to the payment channel corresponding to the payment order.

[0122] Step S210: The payment system receives the deduction failure result returned by the payment channel.

[0123] In step S212, the payment system returns the deduction failure result to the risk detection system.

[0124] In step S214, the risk control system returns the deduction failure result to the acquiring system.

[0125] In step S216, the acquiring system returns the deduction failure result to the front-end system.

[0126] In step S224, the acquiring system receives the pre-verification request for the payment order and sends a risk detection request to the risk detection system.

[0127] Step S226: The risk detection system performs risk detection on the payment order.

[0128] Step S228: If the risk detection passes, send a payment rule verification request for the payment order to the payment system.

[0129] Step S230: The payment system verifies the payment rules for the payment order.

[0130] Step S232: If the payment rule verification is successful, send an account verification request to the payment channel.

[0131] Step S234: The payment system receives the account verification result returned by the payment channel.

[0132] In step S236, the payment system returns the account verification result as a preliminary verification result to the risk detection system.

[0133] In step S238, the risk detection system returns the pre-verification results to the acquiring system.

[0134] In step S240, the acquiring system returns the pre-verification result to the front-end system.

[0135] Step S246: The acquiring system sends a risk detection request to the risk detection system based on the payment retry instruction.

[0136] Step S248: The risk detection system performs risk detection on the payment order.

[0137] Step S250: If the risk detection passes, send a payment rule verification request for the payment order to the payment system.

[0138] Step S252: The payment system verifies the payment rules for the payment order.

[0139] Step S254: If the payment rule verification is successful, send a deduction payment instruction to the payment channel.

[0140] Step S256: The payment system receives the deduction payment result returned by the payment channel.

[0141] In step S258, the payment system returns the deduction payment result as the payment retry result to the risk detection system.

[0142] In step S260, the risk detection system returns the pre-verification results to the acquiring system.

[0143] In step S262, the acquiring system returns the pre-verification result to the front-end system.

[0144] This specification provides an embodiment of a payment processing device as follows:

[0145] In the above embodiments, a payment processing method is provided, and correspondingly, a payment processing device is also provided, which will be described below with reference to the accompanying drawings.

[0146] Reference Figure 4 The diagram shows a payment processing device provided in this embodiment.

[0147] Since the apparatus embodiments correspond to the method embodiments, the descriptions are relatively simple. For relevant parts, please refer to the corresponding descriptions of the method embodiments provided above. The apparatus embodiments described below are merely illustrative.

[0148] This embodiment provides a payment processing device, including:

[0149] The retry task creation module 402 is configured to create a retry task for the payment order based on the payment failure result of the payment order sent by the payment platform; the retry task includes performing pre-verification and performing payment retry.

[0150] The pre-verification module 404 is configured to initiate the retry task and cooperate with the payment platform to perform pre-verification of the payment order.

[0151] The payment retry module 406 is configured to cooperate with the payment platform to retry the payment order if the pre-verification is successful, and obtain the payment retry result.

[0152] The retry task processing module 408 is configured to process the retry task based on the payment retry result.

[0153] Another embodiment of the payment processing device provided in this specification is as follows:

[0154] In the above embodiments, another payment processing method is provided, and correspondingly, another payment processing device is also provided, which will be described below with reference to the accompanying drawings.

[0155] Reference Figure 5 The diagram shows a payment processing device provided in this embodiment.

[0156] Since the apparatus embodiments correspond to the method embodiments, the descriptions are relatively simple. For relevant parts, please refer to the corresponding descriptions of the method embodiments provided above. The apparatus embodiments described below are merely illustrative.

[0157] This embodiment provides a payment processing device, including:

[0158] The payment processing module 502 is configured to process payment orders from merchants and send payment failure results to the front-end system; the front-end system creates a retry task based on the payment failure result, and the retry task includes performing front-end verification and retrying the payment.

[0159] The pre-verification module 504 is configured to cooperate with the pre-verification system to perform pre-verification of the payment order.

[0160] The payment retry module 506 is configured to, if the pre-verification is successful, cooperate with the pre-system to retry the payment order and return the payment retry result to the pre-system.

[0161] This specification provides the following embodiment of a payment processing device:

[0162] Corresponding to the payment processing method described above, based on the same technical concept, one or more embodiments of this specification also provide a payment processing device for executing the payment processing method provided above. Figure 6 This is a schematic diagram of the structure of a payment processing device provided for one or more embodiments of this specification.

[0163] This embodiment provides a payment processing device, including:

[0164] like Figure 6 As shown, payment processing devices can vary significantly due to differences in configuration or performance. They may include one or more processors 601 and memory 602, with memory 602 storing one or more application programs or data. Memory 602 can be temporary or persistent storage. The application programs stored in memory 602 may include one or more modules (not shown), each module including a series of computer-executable instructions within the payment processing device. Furthermore, processor 601 may be configured to communicate with memory 602, executing the series of computer-executable instructions stored in memory 602 on the payment processing device. The payment processing device may also include one or more power supplies 603, one or more wired or wireless network interfaces 604, one or more input / output interfaces 605, one or more keyboards 606, etc.

[0165] In one specific embodiment, the payment processing device includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the payment processing device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following:

[0166] Based on the payment failure result of the payment order sent by the payment platform, a retry task for the payment order is created; the retry task includes performing pre-verification and retrying the payment.

[0167] Initiate the retry task and cooperate with the payment platform to perform pre-verification of the payment order;

[0168] If the pre-verification is successful, the payment order will be retried in cooperation with the payment platform to obtain the payment retry result;

[0169] The retry task is processed based on the payment retry result.

[0170] Another embodiment of the payment processing device provided in this specification is as follows:

[0171] Corresponding to the other payment processing method described above, based on the same technical concept, one or more embodiments of this specification also provide another payment processing device for executing the payment processing method provided above. Figure 7 This is a schematic diagram of another payment processing device provided in one or more embodiments of this specification.

[0172] This embodiment provides a payment processing device, including:

[0173] like Figure 7 As shown, payment processing devices can vary significantly due to differences in configuration or performance. They may include one or more processors 701 and memory 702, with memory 702 storing one or more application programs or data. Memory 702 can be temporary or persistent storage. The application programs stored in memory 702 may include one or more modules (not shown), each module including a series of computer-executable instructions within the payment processing device. Furthermore, processor 701 may be configured to communicate with memory 702, executing the series of computer-executable instructions stored in memory 702 on the payment processing device. The payment processing device may also include one or more power supplies 703, one or more wired or wireless network interfaces 704, one or more input / output interfaces 705, one or more keyboards 706, etc.

[0174] In one specific embodiment, the payment processing device includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the payment processing device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following:

[0175] The system processes merchant payment orders and sends payment failure results to the front-end system. The front-end system creates a retry task based on the payment failure results. The retry task includes performing front-end verification and retrying the payment.

[0176] The payment order is pre-verified in conjunction with the aforementioned front-end system.

[0177] If the pre-verification is successful, the payment order will be retried in conjunction with the pre-verification system, and the payment retry result will be returned to the pre-verification system.

[0178] This specification provides an example of a storage medium as follows:

[0179] Corresponding to the payment processing method described above, based on the same technical concept, one or more embodiments of this specification also provide a storage medium.

[0180] The storage medium provided in this embodiment is used to store computer-executable instructions, which, when executed by a processor, implement the following process:

[0181] Based on the payment failure result of the payment order sent by the payment platform, a retry task for the payment order is created; the retry task includes performing pre-verification and retrying the payment.

[0182] Initiate the retry task and cooperate with the payment platform to perform pre-verification of the payment order;

[0183] If the pre-verification is successful, the payment order will be retried in cooperation with the payment platform to obtain the payment retry result;

[0184] The retry task is processed based on the payment retry result.

[0185] It should be noted that the embodiments of a storage medium and the embodiments of a payment processing method in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and the repeated parts will not be described again.

[0186] Another embodiment of the storage medium provided in this specification is as follows:

[0187] In response to the other payment processing method described above, based on the same technical concept, one or more embodiments of this specification also provide another storage medium.

[0188] The storage medium provided in this embodiment is used to store computer-executable instructions, which, when executed by a processor, implement the following process:

[0189] The system processes merchant payment orders and sends payment failure results to the front-end system. The front-end system creates a retry task based on the payment failure results. The retry task includes performing front-end verification and retrying the payment.

[0190] The payment order is pre-verified in conjunction with the aforementioned front-end system.

[0191] If the pre-verification is successful, the payment order will be retried in conjunction with the pre-verification system, and the payment retry result will be returned to the pre-verification system.

[0192] It should be noted that the embodiments of another storage medium in this specification and the embodiments of another payment processing method in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and the repeated parts will not be described again.

[0193] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0194] In the 1930s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many improvements to the methodology today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that an improvement to the methodology cannot be implemented using a hardware physical module. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0195] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, ASICs, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0196] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0197] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, when implementing the embodiments of this specification, the functions of each unit can be implemented in one or more software and / or hardware.

[0198] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0199] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0200] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0201] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0202] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0203] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0204] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0205] It should also be noted that 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 limitation, 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.

[0206] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0207] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0208] The above description is merely an embodiment of this document and is not intended to limit the scope of this document. Various modifications and variations can be made to this document by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this document should be included within the scope of the claims of this document.

Claims

1. A payment processing method, applied to a front-end system, comprising: Based on the failure result of automatic deduction payment of the payment order sent by the payment platform, a retry task for the payment order is created and the effective payment time of the payment order is set; the retry task includes performing pre-verification and retrying the automatic deduction payment, and the effective payment time is determined according to the order type of the payment order; The retry task is initiated, and the payment platform is used to perform pre-verification of the payment order to obtain the pre-verification result. The pre-verification includes risk detection and payment rule verification during the simulated payment process of the payment order. The pre-verification result is determined by the payment platform after sending an account verification request to the payment channel corresponding to the payment order, based on the account verification result returned by the payment channel. The account verification request is sent when the payment platform successfully performs risk detection on the payment order and performs payment rule verification on the payment order after the detection passes. If the pre-verification fails, the valid payment time shall be maintained according to the verification failure type corresponding to the pre-verification failure. If the pre-verification is successful, check whether the valid payment time has ended. If it has not ended, cooperate with the payment platform to retry the automatic deduction payment of the payment order and obtain the payment retry result. The retry task is processed based on the payment retry result.

2. The payment processing method according to claim 1, wherein the result of the automatic deduction payment failure is obtained after the automatic deduction payment is performed on the payment order; The retry of the automatic deduction payment for the payment order includes: Re-deduct the payment for the aforementioned payment order.

3. The payment processing method according to claim 1 further includes: When the valid payment period ends, send the deduction failure result and / or payment retry result of the deduction payment to the merchant corresponding to the payment order.

4. The payment processing method according to claim 1, wherein the pre-verification of the payment order in cooperation with the payment platform includes: Send a pre-verification request for the payment order to the payment platform; Receive the pre-verification result returned by the payment platform; The result of the pre-verification is either pre-verification successful or pre-verification failed.

5. The payment processing method according to claim 1, wherein cooperating with the payment platform to retry the automatic deduction payment of the payment order and obtain the payment retry result includes: Send a payment retry instruction for the payment order to the payment platform; Receive the payment retry result returned by the payment platform; The payment retry result is either payment retry successful or payment retry failed.

6. According to the payment processing method of claim 5, after receiving the payment retry instruction, the payment platform performs the following operations: The payment order is subject to risk detection, and the payment rule is verified after the risk detection is passed. If the payment rule verification is successful, a payment deduction instruction is sent to the corresponding payment channel, and the payment deduction result of the payment channel is returned as the payment retry result.

7. The payment processing method according to claim 1, wherein processing the retry task based on the payment retry result includes: If the payment retry result is a payment retry failure, the execution time of the retry task is set so that the retry task is restarted at the execution time; If the payment retry result is a successful payment retry, the retry task is deleted.

8. A payment processing method, applied to a payment platform, comprising: Process merchant payment orders by deducting payments on their behalf and send the results of failed deductions to the front-end system. The front-end system creates a retry task based on the failure result of the automatic deduction payment and sets the effective payment time of the payment order. The retry task includes performing front-end verification and retrying the automatic deduction payment. The effective payment time is determined according to the order type of the payment order. The system receives a pre-verification request for the payment order from the front-end system, responds to the pre-verification request by performing risk detection on the payment order, and performs payment rule verification on the payment order after the risk detection passes. If the payment rule verification is successful, the system sends an account verification request to the payment channel corresponding to the payment order, and returns the account verification result returned by the payment channel as the pre-verification result to the front-end system. The pre-verification includes risk detection and payment rule verification simulating the payment process of the payment order. If the pre-verification fails, the pre-verification system shall maintain the valid payment time according to the verification failure type corresponding to the pre-verification failure. If the pre-verification is successful, the pre-system checks whether the valid payment time has ended. If it has not ended, it works with the pre-system to retry the automatic deduction payment of the payment order and returns the payment retry result to the pre-system so that the retry task can be processed according to the payment retry result.

9. The payment processing method according to claim 8, wherein the step of cooperating with the front-end system to retry the automatic deduction payment of the payment order and returning the payment retry result to the front-end system includes: Receive the payment retry instruction for the payment order sent by the front-end system; In response to the payment retry instruction, a risk detection is performed on the payment order, and the payment rule is verified on the payment order after the risk detection is passed; If the payment rule verification is successful, a payment deduction instruction is sent to the corresponding payment channel, and the payment deduction result of the payment channel is returned to the front-end system as the payment retry result.

10. The payment processing method according to claim 8, wherein the method is applied to a payment platform, the payment platform comprising an acquiring system, a risk detection system, and a payment system.

11. A payment processing device, comprising: The retry task creation module is configured to create a retry task for a payment order based on the failure result of automatic deduction payment of the payment order sent by the payment platform, and set the effective payment time of the payment order; the retry task includes performing pre-verification and retrying the automatic deduction payment, and the effective payment time is determined according to the order type of the payment order; The pre-verification module is configured to initiate the retry task and cooperate with the payment platform to perform pre-verification of the payment order and obtain the pre-verification result. The pre-verification includes risk detection and payment rule verification simulating the payment process of the payment order. The pre-verification result is determined by the payment platform after sending an account verification request to the payment channel corresponding to the payment order, based on the account verification result returned by the payment channel. The account verification request is sent when the payment platform successfully performs risk detection on the payment order and, after the detection passes, successfully performs payment rule verification on the payment order. The payment retry module is configured to maintain the valid payment time according to the failure type corresponding to the failure of the pre-verification if the pre-verification fails; if the pre-verification is successful, it checks whether the valid payment time has ended; if it has not ended, it cooperates with the payment platform to retry the automatic deduction payment of the payment order and obtain the payment retry result. The retry task processing module is configured to process the retry task based on the payment retry result.

12. A payment processing device, comprising: The payment processing module is configured to process merchant payment orders by deduction and send the result of deduction failure to the front-end system. The front-end system creates a retry task based on the failure result of the automatic deduction payment and sets the effective payment time of the payment order. The retry task includes performing front-end verification and retrying the automatic deduction payment. The effective payment time is determined according to the order type of the payment order. The pre-verification module is configured to receive a pre-verification request for the payment order sent by the pre-verification system, respond to the pre-verification request, perform risk detection on the payment order, and perform payment rule verification on the payment order after the risk detection passes. If the payment rule verification is successful, an account verification request is sent to the payment channel corresponding to the payment order, and the account verification result returned by the payment channel is returned to the pre-verification system as the pre-verification result. The pre-verification includes risk detection and payment rule verification simulating the payment process of the payment order. The payment retry module is configured to maintain the valid payment time according to the verification failure type corresponding to the pre-verification failure if the pre-verification fails. If the pre-verification is successful, the pre-system checks whether the valid payment time has ended. If it has not ended, it works with the pre-system to retry the automatic deduction payment of the payment order and returns the payment retry result to the pre-system so that the retry task can be processed according to the payment retry result.

13. A payment processing device, comprising: processor; And, a memory configured to store computer-executable instructions, which, when executed, cause the processor to: Based on the failure result of automatic deduction payment of the payment order sent by the payment platform, a retry task for the payment order is created and the effective payment time of the payment order is set; the retry task includes performing pre-verification and retrying the automatic deduction payment, and the effective payment time is determined according to the order type of the payment order; The retry task is initiated, and the payment platform is used to perform pre-verification of the payment order to obtain the pre-verification result. The pre-verification includes risk detection and payment rule verification during the simulated payment process of the payment order. The pre-verification result is determined by the payment platform after sending an account verification request to the payment channel corresponding to the payment order, based on the account verification result returned by the payment channel. The account verification request is sent when the payment platform successfully performs risk detection on the payment order and performs payment rule verification on the payment order after the detection passes. If the pre-verification fails, the valid payment time shall be maintained according to the verification failure type corresponding to the pre-verification failure. If the pre-verification is successful, check whether the valid payment time has ended. If it has not ended, cooperate with the payment platform to retry the automatic deduction payment of the payment order and obtain the payment retry result. The retry task is processed based on the payment retry result.

14. A payment processing device, comprising: processor; And, a memory configured to store computer-executable instructions, which, when executed, cause the processor to: The system processes merchant payment orders by deducting payments on their behalf and sends the result of failed deductions to the front-end system. The front-end system creates a retry task based on the failed deduction result and sets the effective payment time for the payment order. The retry task includes performing front-end verification and retrying the deduction payment. The effective payment time is determined according to the order type of the payment order. The system receives a pre-verification request for the payment order from the front-end system, responds to the pre-verification request by performing risk detection on the payment order, and performs payment rule verification on the payment order after the risk detection passes. If the payment rule verification is successful, the system sends an account verification request to the payment channel corresponding to the payment order, and returns the account verification result returned by the payment channel as the pre-verification result to the front-end system. The pre-verification includes risk detection and payment rule verification simulating the payment process of the payment order. If the pre-verification fails, the pre-verification system shall maintain the valid payment time according to the verification failure type corresponding to the pre-verification failure. If the pre-verification is successful, the pre-system checks whether the valid payment time has ended. If it has not ended, it works with the pre-system to retry the automatic deduction payment of the payment order and returns the payment retry result to the pre-system so that the retry task can be processed according to the payment retry result.

15. A storage medium for storing computer-executable instructions, which, when executed by a processor, perform the following process: Based on the failure result of automatic deduction payment of the payment order sent by the payment platform, a retry task for the payment order is created and the effective payment time of the payment order is set; the retry task includes performing pre-verification and retrying the automatic deduction payment, and the effective payment time is determined according to the order type of the payment order; The retry task is initiated, and the payment platform is used to perform pre-verification of the payment order to obtain the pre-verification result. The pre-verification includes risk detection and payment rule verification during the simulated payment process of the payment order. The pre-verification result is determined by the payment platform after sending an account verification request to the payment channel corresponding to the payment order, based on the account verification result returned by the payment channel. The account verification request is sent when the payment platform successfully performs risk detection on the payment order and performs payment rule verification on the payment order after the detection passes. If the pre-verification fails, the valid payment time shall be maintained according to the verification failure type corresponding to the pre-verification failure. If the pre-verification is successful, check whether the valid payment time has ended. If it has not ended, cooperate with the payment platform to retry the automatic deduction payment of the payment order and obtain the payment retry result. The retry task is processed based on the payment retry result.

16. A storage medium for storing computer-executable instructions, which, when executed by a processor, perform the following process: The system processes merchant payment orders by deducting payments on their behalf and sends the result of failed deductions to the front-end system. The front-end system creates a retry task based on the failed deduction result and sets the effective payment time for the payment order. The retry task includes performing front-end verification and retrying the deduction payment. The effective payment time is determined according to the order type of the payment order. The system receives a pre-verification request for the payment order from the front-end system, responds to the pre-verification request by performing risk detection on the payment order, and performs payment rule verification on the payment order after the risk detection passes. If the payment rule verification is successful, the system sends an account verification request to the payment channel corresponding to the payment order, and returns the account verification result returned by the payment channel as the pre-verification result to the front-end system. The pre-verification includes risk detection and payment rule verification simulating the payment process of the payment order. If the pre-verification fails, the pre-verification system shall maintain the valid payment time according to the verification failure type corresponding to the pre-verification failure. If the pre-verification is successful, the pre-system checks whether the valid payment time has ended. If it has not ended, it works with the pre-system to retry the automatic deduction payment of the payment order and returns the payment retry result to the pre-system so that the retry task can be processed according to the payment retry result.

Images