Method and device for reducing complex payment risk
By binding the sub-account and the parent account, and using whitelist to trigger the second sub-payment regularly, the problem of high risk of fund errors in complex payment methods is solved, and the security and simplicity of the payment process is improved.
Patent Information
- Application Number
- CN202411383621.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-30
- Publication Date
- 2024-12-31
AI Technical Summary
The existing complex payment methods have multiple participants, multiple payment methods and multiple layers of capital flow, resulting in high risk of fund errors and unsafe payment process.
By binding the sub-account and the parent account, and triggering the sub-account to make a second sub-payment to the account to be paid based on the whitelist, simplifying the payment process and reducing the risk of fund errors.
It has achieved improved security of the payment process, reduced the risk of fund errors, simpler coding and clearer process.
Smart Images
Figure CN119228370A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of data processing technology, and in particular to a method and device for reducing complex payment risks. Background Art
[0002] As business scenarios become more diverse, a single transfer payment can no longer meet customer needs. For example, when paying through a payment platform account, if the account balance is insufficient, you can choose to complete the payment by combining payment with a bank card. Today, smart payment supports multiple functions such as linkage payment, agent payment, automatic payment request, and smart batch payment, which makes people's lives more convenient.
[0003] In the existing technology, these complex payment methods usually involve multiple participants, multiple payment methods, multiple layers of fund flow, and complex business logic. How to reduce the risk of fund errors in these complex payment processes and improve the security of the payment process has become an urgent problem to be solved. Summary of the invention
[0004] Based on the above problems, the present application provides a method and device for reducing complex payment risks, so as to reduce the risk of fund errors in these complex payment processes and improve the security of the payment process.
[0005] The present application discloses a method for reducing complex payment risks, the method comprising:
[0006] Bind a sub-account to a parent account; the sub-account is the account that initiates the payment transaction;
[0007] The master account makes a first sub-payment to the sub-account according to the payment transaction information;
[0008] Based on the whitelist, the second sub-payment from the sub-account to the account to be paid is triggered at a fixed time to complete the payment transaction.
[0009] Optionally, the status of the payment transaction includes unpayable, pending payment, paying, successful payment, payment verification, and payment failure, and the parent account performs a first sub-payment to the sub-account according to the payment transaction information, including:
[0010] Performing transaction verification on the status of the first sub-payment;
[0011] If the status of the first sub-payment changes from being paid to being successfully traded, the status of the second sub-payment changes from being unpayable to being paid;
[0012] If the status of the first sub-payment changes from payment in progress to transaction failure, the status of the second sub-payment is changed from unpayable to payment failure, and the second sub-payment is no longer processed.
[0013] Optionally, after changing the status of the second sub-payment from unpayable to payment failed, the method further includes:
[0014] The sub-account performs a third sub-transaction with the parent account to return the failed payment amount to the parent account;
[0015] Performing transaction verification on the status of the third sub-payment;
[0016] If the status of the third sub-payment changes from payment verification to transaction success, it is determined that the amount of the failed payment has been returned, and the payment transaction is terminated;
[0017] If the status of the third sub-payment changes from payment verification to transaction failure, it is determined that the amount of the failed payment has not been returned, and an error occurs in the third sub-payment in the payment transaction.
[0018] Optionally, the timing triggering of the second sub-payment by the sub-account to the account to be paid based on the whitelist includes:
[0019] After the state of the second sub-payment changes to a preset time interval of pending payment, determining whether a target group exists in the whitelist; the parent account and the sub-account belong to the target group;
[0020] When the target group exists in the whitelist, the balance of the parent account is checked;
[0021] When the balance check fails, repeating the balance check at a preset frequency;
[0022] When the balance check passes, the status of the second sub-payment is changed from pending payment to paying;
[0023] When the target group does not exist in the whitelist, the status of the second sub-payment is changed from pending payment to paying.
[0024] Optionally, after repeatedly performing the balance check at a preset frequency, the method further includes:
[0025] When the number of balance checks reaches a preset number, an error in the balance check in the payment transaction is reported.
[0026] Optionally, after the second sub-payment from the sub-account to the account to be paid is triggered at a fixed time and the payment transaction is completed, the method further includes:
[0027] Performing transaction verification on the status of the second sub-payment;
[0028] If the status of the second sub-payment changes from payment in progress to transaction successful, the payment transaction is judged to be successful;
[0029] If the status of the second sub-payment changes from payment in progress to transaction failure, the payment transaction is determined to have failed.
[0030] Optionally, after determining that the payment transaction fails, the method further includes:
[0031] The sub-account performs a third sub-transaction with the parent account to return the failed payment amount to the parent account;
[0032] Performing transaction verification on the status of the third sub-payment;
[0033] If the status of the third sub-payment changes from payment verification to transaction success, it is determined that the amount of the failed payment has been returned, and the payment transaction is terminated;
[0034] If the status of the third sub-payment changes from payment verification to transaction failure, it is determined that the amount of the failed payment has not been returned, and an error occurs in the third sub-payment in the payment transaction.
[0035] Optionally, there are multiple parent accounts.
[0036] Based on the above method for reducing complex payment risks, the present application also discloses a device for reducing complex payment risks, including: a binding unit, a first payment unit, and a second payment unit;
[0037] The binding unit is used to bind the sub-account to the parent account; the sub-account is the initiating account of the payment transaction;
[0038] The first payment unit is used for the master account to make a first sub-payment to the sub-account according to the payment transaction information;
[0039] The second payment unit is used to trigger the second sub-payment from the sub-account to the account to be paid based on the whitelist to complete the payment transaction.
[0040] Optionally, the status of the payment transaction includes unpayable, pending payment, paying, successful payment, payment verification, and payment failure, and the first payment unit includes:
[0041] A verification subunit, used to perform transaction verification on the status of the first sub-payment;
[0042] A waiting-for-payment sub-unit, configured to change the status of the second sub-payment from unpayable to waiting-for-payment if the status of the first sub-payment changes from being paid to being successfully traded;
[0043] The failure sub-unit is used to change the status of the second sub-payment from unpayable to payment failure if the status of the first sub-payment changes from payment in progress to transaction failure, and no longer conduct the second sub-payment.
[0044] Optionally, the device further comprises:
[0045] A return unit, used for the sub-account to perform a third sub-transaction with the parent account to return the failed payment amount to the parent account;
[0046] a return verification unit, configured to perform transaction verification on the status of the third sub-payment;
[0047] A return termination unit, configured to determine that the amount of the failed payment has been returned and terminate the payment transaction if the status of the third sub-payment changes from payment verification to successful transaction;
[0048] The return failure unit is used to determine that the amount of the failed payment has not been returned if the status of the third sub-payment changes from payment verification to transaction failure, and report that an error has occurred in the third sub-payment in the payment transaction.
[0049] Optionally, the second payment unit includes:
[0050] A whitelist determination subunit is used to determine whether a target group exists in the whitelist after the state of the second sub-payment changes to a preset time interval to be paid; the parent account and the sub-account belong to the target group;
[0051] A balance verification subunit, used to verify the balance of the parent account when the target group exists in the whitelist;
[0052] A re-check subunit, used for repeating the balance check at a preset frequency when the balance check fails;
[0053] A verification pass subunit, used for changing the status of the second sub-payment from pending payment to paying when the balance verification passes;
[0054] The verification failure sub-unit is used to change the status of the second sub-payment from pending payment to paying when the target group does not exist in the white list.
[0055] Optionally, the re-verification subunit is further used for:
[0056] When the number of balance checks reaches a preset number, an error in the balance check in the payment transaction is reported.
[0057] Optionally, the device further comprises:
[0058] A second verification unit, used for performing transaction verification on the status of the second sub-payment;
[0059] A second success unit, configured to determine that the payment transaction is successful if the state of the second sub-payment changes from payment in progress to transaction successful;
[0060] The second failure unit is used to determine that the payment transaction has failed if the status of the second sub-payment changes from payment in progress to transaction failure.
[0061] Optionally, the second failure unit is further used for:
[0062] The sub-account performs a third sub-transaction with the parent account to return the failed payment amount to the parent account;
[0063] Performing transaction verification on the status of the third sub-payment;
[0064] If the status of the third sub-payment changes from payment verification to transaction success, it is determined that the amount of the failed payment has been returned, and the payment transaction is terminated;
[0065] If the status of the third sub-payment changes from payment verification to transaction failure, it is determined that the amount of the failed payment has not been returned, and an error occurs in the third sub-payment in the payment transaction.
[0066] Optionally, there are multiple parent accounts.
[0067] The present application discloses a method and device for reducing the risk of complex payments, which is aimed at complex but rarely used payment transactions. The initiating account of the payment transaction, that is, the sub-account, is bound to the parent account. The parent account makes the first sub-payment to the sub-account based on the payment transaction information. Based on the whitelist, the second sub-payment made by the sub-account to the account to be paid is triggered on a regular basis to complete the payment transaction. A complex payment transaction actually includes two or even more payment transactions. The method described in the present application simplifies the process that originally required multiple payments to only implement the first sub-payment. The second sub-payment is uniformly implemented based on the whitelist and the scheduled task, which makes the coding simpler and the process clearer. It also reduces the risk of fund errors when facing complex payment transactions and improves the security of the payment process. BRIEF DESCRIPTION OF THE DRAWINGS
[0068] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.
[0069] Figure 1 A flow chart of a method for reducing complex payment risks disclosed in an embodiment of the present application;
[0070] Figure 2 A flowchart of another method for reducing complex payment risks disclosed in an embodiment of the present application;
[0071] Figure 3 This is a schematic diagram of the structure of a device for reducing complex payment risks disclosed in an embodiment of the present application. DETAILED DESCRIPTION
[0072] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.
[0073] Embodiment 1: This application discloses a method for reducing complex payment risks.
[0074] For details, please refer to Figure 1 A method for reducing complex payment risks disclosed in this embodiment includes the following steps:
[0075] Step 101: Bind the sub-account to the parent account.
[0076] In the method described in this embodiment, the sub-account is the initiating account of the payment transaction, and the parent account can be multiple. For example, in the scenario where the sub-account needs to transfer 100 yuan to the receiving account and selects the linked payment, the single parent account linked to the sub-account needs to transfer 100 yuan to the sub-account first, and the sub-account then transfers the 100 yuan to the receiving account. In the scenario where the sub-account needs to transfer 100 yuan to the receiving account and selects the automatic payment request, the available balance of the sub-account is 50 yuan, and it is necessary to request 30 yuan from the parent account A and 20 yuan from the parent account B before the 100 yuan can be transferred to the receiving account.
[0077] From the transaction dimension, a payment transaction actually includes multiple payment transactions, and each payment transaction has many states. In order to confirm the payment status of a large number of transactions and query errors, the method described in this embodiment sets the payment transaction status to only include six states: unpayable, pending payment, paying, successful payment, payment verification, and payment failure.
[0078] Step 102: The parent account makes a first sub-payment to the sub-account according to the payment transaction information.
[0079] In the method described in this embodiment, the parent account can first submit the payment transaction to the management center for approval based on the payment transaction information, and the payment transaction starts after the approval is passed. The payment transaction information includes conventional transaction information such as the payment transaction amount and the receiving account, which will not be described in detail here.
[0080] In the method described in this embodiment, after the payment transaction starts, the status of the first sub-payment is in payment, and the status of the second sub-payment is unpayable. Subsequently, the status of the first sub-payment can be verified. If the status of the first sub-payment changes from in payment to successful transaction, the status of the second sub-payment is changed from unpayable to pending payment. If the status of the first sub-payment changes from in payment to failed transaction, the status of the second sub-payment is changed from unpayable to failed payment, and the second sub-payment is no longer processed.
[0081] As an optional method, when the payment transaction is a linked payment, the first sub-payment transaction fails, and the money transferred from the parent account to the sub-account needs to be returned to the parent account by the sub-account. At this time, the sub-account conducts a third sub-transaction with the parent account to return the amount of the failed payment. Subsequently, the status of the third sub-payment can be verified. If the status of the third sub-payment changes from payment verification to transaction success, it is determined that the amount of the failed payment has been returned, and the payment transaction ends. If the status of the third sub-payment changes from payment verification to transaction failure, it is determined that the amount of the failed payment has not been returned.
[0082] As another optional method, the automatic payment request service has the characteristic of free disposal of funds, and the funds after the payment request have no fixed use. When the payment transaction is an automatic payment request, the payment request is successful but the first sub-payment transaction fails. The funds requested by the sub-account to the parent account do not need to be returned to the parent account. At this time, the payment transaction can be directly terminated.
[0083] In the method described in this embodiment, some business logics of automatic payment request and manual payment request need to be compatible, so the automatic payment request data and manual payment request data need to be stored in the same database table. For example, the payment request verification timed task can be used for verification of manual payment request and automatic payment request at the same time.
[0084] In the method described in this embodiment, if the amount of failed payment is not returned, the status of the third sub-payment can be verified multiple times at a preset frequency until the verification number reaches the preset number, and an error in the third sub-payment in the payment transaction is reported. Correspondingly, after the transaction verification time reaches the preset time, an error in the third sub-payment in the payment transaction can also be reported. It is also possible to directly report an error in the third sub-payment in the payment transaction, and whether to repeat the transaction verification and how to report can be set according to actual needs. Whether the transaction verification is repeated, the number of repetitions, and the error reporting method are not specifically limited here, and it is sufficient to be able to implement the method described in this embodiment.
[0085] Step 103: Based on the whitelist, the second sub-payment from the sub-account to the account to be paid is triggered at a fixed time to complete the payment transaction.
[0086] In the method described in this embodiment, as an optional method, after the state of the second sub-payment changes to a preset time interval of waiting for payment, it can be determined whether the target group exists in the whitelist. Among them, the parent account and the sub-account belong to the same target group. Correspondingly, after the state of the second sub-payment changes to waiting for payment, it is also possible to wait for a whitelist determination request and then determine whether the target group exists in the whitelist. Here, no specific limitation is made on how to trigger the second sub-payment. The triggering condition of the second sub-payment is not that the state of the first sub-payment changes from payment in progress to transaction success, that is, the second sub-payment does not need to be performed immediately following the first sub-payment.
[0087] Among them, the groups (customers) in the whitelist are customers with special maintenance needs. Whether payment transactions of such customers can be carried out depends on whether the balance is sufficient.
[0088] In the method described in this embodiment, when the target group exists in the whitelist, the balance check of the parent account can be performed. When the balance check fails, the balance check can be repeated at a preset frequency. As an optional method, after the number of balance checks reaches a preset number, an error in the balance check in the payment transaction can be reported. As another optional method, after the balance check time reaches a preset time, an error in the balance check in the payment transaction can also be reported. Whether the balance check is repeated, the number of repetitions, and the error reporting method are not specifically limited here, and it is sufficient to be able to implement the method described in this embodiment.
[0089] When the balance verification passes, the status of the second sub-payment is changed from pending payment to paying. When the target group does not exist in the whitelist, it means that the group (customer) has no special maintenance requirements, and the status of the second sub-payment can be directly changed from pending payment to paying.
[0090] In the method described in this embodiment, the status of the second sub-payment can be verified. If the status of the second sub-payment changes from payment in progress to transaction successful, the payment transaction is judged to be successful. If the status of the second sub-payment changes from payment in progress to transaction failed, the payment transaction is judged to be failed.
[0091] As an optional method, when the payment transaction is a linked payment, the second sub-payment transaction fails, and the money transferred from the parent account to the sub-account needs to be returned to the parent account by the sub-account. At this time, the sub-account conducts a third sub-transaction with the parent account to return the amount of the failed payment. Subsequently, the status of the third sub-payment can be verified. If the status of the third sub-payment changes from payment verification to transaction success, it is determined that the amount of the failed payment has been returned, and the payment transaction ends. If the status of the third sub-payment changes from payment verification to transaction failure, it is determined that the amount of the failed payment has not been returned.
[0092] As another optional method, when the payment transaction is an automatic payment request, the second sub-payment transaction fails, and the money transferred from the parent account to the sub-account does not need to be returned from the sub-account to the parent account. At this time, the payment transaction can be ended directly.
[0093] In the method described in this embodiment, if the amount of failed payment is not returned, the status of the third sub-payment can also be verified multiple times at a preset frequency until the verification times reach the preset times, and an error is reported in the third sub-payment of the payment transaction. Alternatively, an error is directly reported in the third sub-payment of the payment transaction.
[0094] The method described in this embodiment changes the original payment transaction business "all the way to the end" implementation idea, and reduces the complexity but rarely used payment transactions. The multiple payment processes contained in a complex payment transaction are streamlined to only implement the first sub-payment. Using the method of scheduled tasks, based on the whitelist, the second sub-payment made by the sub-account to the account to be paid is triggered regularly, and the second sub-payment is implemented uniformly, making the coding simpler and the process clearer. In the face of complex payment transactions, the risk of fund errors is reduced and the security of the payment process is improved.
[0095] Example 2: This application discloses another method for reducing complex payment risks. Figure 2 The method described in this embodiment introduces the entire process of automatic payment request.
[0096] Step 201: The balance of the sub-account is 50 yuan, and the sub-account needs to pay 100 yuan to the receiving account. Therefore, the sub-account requests 30 yuan from the parent account A and 20 yuan from the parent account B.
[0097] Step 202: The parent account A transfers 30 yuan to the child account, and performs the first child transaction a.
[0098] Step 203: The parent account B transfers 20 yuan to the child account, and performs the first child transaction b.
[0099] Step 204: Verify the first sub-transaction a and the first sub-transaction b to determine whether there is a sub-transaction with payment failure. If yes, proceed to step 205. If no, proceed to step 206.
[0100] Step 205: Change the status of the first sub-transaction a and the first sub-transaction b from payment verification to payment failure. Go to step 212.
[0101] Step 206: Change the status of the second sub-transaction from unpayable to pending payment.
[0102] Step 207: After the status of the second sub-transaction changes to pending payment 1 hour later, determine whether the group described by the sub-account, parent account A, and parent account B exists in the whitelist. If yes, proceed to step 208. If no, proceed to step 210.
[0103] Step 208: Check the balance of the master account A and the master account B to determine whether there is a check result that fails the check. If yes, proceed to step 209. If no, proceed to step 210.
[0104] Step 209: Change the status of the second sub-transaction from pending payment to payment failure. Go to step 212.
[0105] Step 210: The sub-account pays RMB 100 to the receiving account, and a second sub-transaction is performed.
[0106] Step 211: Verify the second sub-transaction to determine whether the status of the second sub-transaction is payment failure. If yes, proceed to step 212. If no, proceed to step 213.
[0107] Step 212: End the payment transaction and report the error.
[0108] Step 213: Complete the payment transaction.
[0109] Based on the method for reducing complex payment risks disclosed in the above embodiment, this embodiment correspondingly discloses a device for reducing complex payment risks. Figure 3 , the device for reducing complex payment risks includes: a binding unit 301, a first payment unit 302 and a second payment unit 303;
[0110] The binding unit 301 is used to bind the sub-account to the parent account; the sub-account is the initiating account of the payment transaction;
[0111] The first payment unit 302 is used for the parent account to make a first sub-payment to the sub-account according to the payment transaction information;
[0112] The second payment unit 303 is used to trigger the second sub-payment from the sub-account to the account to be paid based on the whitelist to complete the payment transaction.
[0113] Optionally, the status of the payment transaction includes unpayable, pending payment, paying, successful payment, payment verification, and payment failure. The first payment unit 302 includes:
[0114] A verification subunit, used to perform transaction verification on the status of the first sub-payment;
[0115] A waiting-for-payment sub-unit, configured to change the status of the second sub-payment from unpayable to waiting-for-payment if the status of the first sub-payment changes from being paid to being successfully traded;
[0116] The failure sub-unit is used to change the status of the second sub-payment from unpayable to payment failure if the status of the first sub-payment changes from payment in progress to transaction failure, and no longer conduct the second sub-payment.
[0117] Optionally, the device further comprises:
[0118] A return unit, used for the sub-account to perform a third sub-transaction with the parent account to return the failed payment amount to the parent account;
[0119] a return verification unit, configured to perform transaction verification on the status of the third sub-payment;
[0120] A return termination unit, configured to determine that the amount of the failed payment has been returned and terminate the payment transaction if the status of the third sub-payment changes from payment verification to successful transaction;
[0121] The return failure unit is used to determine that the amount of the failed payment has not been returned if the status of the third sub-payment changes from payment verification to transaction failure, and report that an error has occurred in the third sub-payment in the payment transaction.
[0122] Optionally, the second payment unit 303 includes:
[0123] A whitelist determination subunit is used to determine whether a target group exists in the whitelist after the state of the second sub-payment changes to a preset time interval to be paid; the parent account and the sub-account belong to the target group;
[0124] A balance verification subunit, used to verify the balance of the parent account when the target group exists in the whitelist;
[0125] A re-check subunit, used for repeating the balance check at a preset frequency when the balance check fails;
[0126] A verification pass subunit, used for changing the status of the second sub-payment from pending payment to paying when the balance verification passes;
[0127] The verification failure sub-unit is used to change the status of the second sub-payment from pending payment to paying when the target group does not exist in the white list.
[0128] Optionally, the re-verification subunit is further used for:
[0129] When the number of balance checks reaches a preset number, an error in the balance check in the payment transaction is reported.
[0130] Optionally, the device further comprises:
[0131] A second verification unit, used for performing transaction verification on the status of the second sub-payment;
[0132] A second success unit, configured to determine that the payment transaction is successful if the state of the second sub-payment changes from payment in progress to transaction successful;
[0133] The second failure unit is used to determine that the payment transaction has failed if the status of the second sub-payment changes from payment in progress to transaction failure.
[0134] Optionally, the second failure unit is further used for:
[0135] The sub-account performs a third sub-transaction with the parent account to return the failed payment amount to the parent account;
[0136] Performing transaction verification on the status of the third sub-payment;
[0137] If the status of the third sub-payment changes from payment verification to transaction success, it is determined that the amount of the failed payment has been returned, and the payment transaction is terminated;
[0138] If the status of the third sub-payment changes from payment verification to transaction failure, it is determined that the amount of the failed payment has not been returned, and an error occurs in the third sub-payment in the payment transaction.
[0139] Optionally, there are multiple parent accounts.
[0140] The embodiments in this specification are described in a progressive manner. As for the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the methods.
[0141] It should also be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.
[0142] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
[0143] The features described in the embodiments of this specification can be replaced or combined with each other, so that professional and technical personnel in this field can implement or use the present application.
[0144] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A method for reducing complex payment risks, characterized in that: include: Bind the sub-account to the parent account; The sub-account is the account number for initiating the payment transaction; The master account makes a first sub-payment to the sub-account according to the payment transaction information; Based on the whitelist, the second sub-payment from the sub-account to the account to be paid is triggered at a fixed time to complete the payment transaction.
2. The method according to claim 1, characterized in that: The status of the payment transaction includes unpayable, pending payment, paying, successful payment, payment verification, and payment failure. The parent account performs a first sub-payment to the sub-account according to the payment transaction information, including: Performing transaction verification on the status of the first sub-payment; If the status of the first sub-payment changes from being paid to being successfully traded, the status of the second sub-payment changes from being unpayable to being paid; If the status of the first sub-payment changes from payment in progress to transaction failure, the status of the second sub-payment is changed from unpayable to payment failure, and the second sub-payment is no longer processed.
3. The method according to claim 2, characterized in that After changing the status of the second sub-payment from unpayable to payment failed, the method further includes: The sub-account performs a third sub-transaction with the parent account to return the failed payment amount to the parent account; Performing transaction verification on the status of the third sub-payment; If the status of the third sub-payment changes from payment verification to transaction success, it is determined that the amount of the failed payment has been returned, and the payment transaction is terminated; If the status of the third sub-payment changes from payment verification to transaction failure, it is determined that the amount of the failed payment has not been returned, and an error occurs in the third sub-payment in the payment transaction.
4. The method according to claim 2, characterized in that: The timing triggering of the second sub-payment by the sub-account to the account to be paid based on the whitelist includes: After the state of the second sub-payment changes to a preset time interval of pending payment, determining whether a target group exists in the whitelist; the parent account and the sub-account belong to the target group; When the target group exists in the whitelist, the balance of the parent account is checked; When the balance check fails, repeating the balance check at a preset frequency; When the balance check passes, the status of the second sub-payment is changed from pending payment to paying; When the target group does not exist in the whitelist, the status of the second sub-payment is changed from pending payment to paying.
5. The method according to claim 4, characterized in that After repeatedly performing the balance check at a preset frequency, the method further includes: When the number of balance checks reaches a preset number, an error in the balance check in the payment transaction is reported.
6. The method according to claim 2, characterized in that After the second sub-payment from the sub-account to the account to be paid is triggered at a fixed time and the payment transaction is completed, the method further includes: Performing transaction verification on the status of the second sub-payment; If the status of the second sub-payment changes from payment in progress to transaction successful, the payment transaction is judged to be successful; If the status of the second sub-payment changes from payment in progress to transaction failure, the payment transaction is determined to have failed.
7. The method according to claim 6, characterized in that After determining that the payment transaction fails, the method further includes: The sub-account performs a third sub-transaction with the parent account to return the failed payment amount to the parent account; Performing transaction verification on the status of the third sub-payment; If the status of the third sub-payment changes from payment verification to transaction success, it is determined that the amount of the failed payment has been returned, and the payment transaction is terminated; If the status of the third sub-payment changes from payment verification to transaction failure, it is determined that the amount of the failed payment has not been returned, and an error occurs in the third sub-payment in the payment transaction.
8. The method according to any one of claims 1 to 7, characterized in that: There are multiple parent accounts.
9. A device for reducing complex payment risks, characterized in that: include: A binding unit, a first payment unit, and a second payment unit; The binding unit is used to bind the sub-account with the parent account; The sub-account is the account number for initiating the payment transaction; The first payment unit is used for the master account to make a first sub-payment to the sub-account according to the payment transaction information; The second payment unit is used to trigger the second sub-payment from the sub-account to the account to be paid based on the whitelist to complete the payment transaction.
10. The device according to claim 9, characterized in that The states of the payment transaction include unpayable, pending payment, paying, successful payment, payment verification, and payment failure. The first payment unit includes: A verification subunit, used to perform transaction verification on the status of the first sub-payment; A waiting-for-payment sub-unit, configured to change the status of the second sub-payment from unpayable to waiting-for-payment if the status of the first sub-payment changes from being paid to being successfully traded; The failure sub-unit is used to change the status of the second sub-payment from unpayable to payment failure if the status of the first sub-payment changes from payment in progress to transaction failure, and no longer conduct the second sub-payment.