Transaction delay payment processing method and device, storage medium and electronic equipment

Abstract

The invention discloses a transaction delayed payment processing method and device, a storage medium and electronic equipment. The method relates to the field of financial science and technology, and comprises the following steps: receiving a transaction request between a payer and a payee, and extracting a transaction file from the transaction request; verifying the transaction file through the third-party mechanism to obtain a verification result of the transaction file; under the condition that the verification result of the transaction file represents that verification is passed, payment parameters are determined based on the transaction file; controlling a payment account of the payer to transfer accounts to a collection account of the payee according to the payment parameters, monitoring a payment behavior of the payer to the payee in a preset period, and judging whether the payment behavior has a payment delay risk or not; and when it is monitored that the payment behavior has the delayed payment risk, early warning information is sent to a third-party mechanism. Through application of the method and the device, the problem that payment is delayed when a transaction is carried out between a payer and a payee in the prior art is solved.

Description

Technical Field

[0001] The present application relates to the field of financial technology, and specifically, to a method, device, storage medium and electronic device for processing deferred payment of a transaction. Background Art

[0002] For some transactions that require third-party supervision, such as payment of alimony, maintenance, and installment repayment of debts, there is no hard constraint on the payer to pay on time during the actual execution process. Therefore, in the actual performance of the transaction, the payer may delay or refuse to pay due to his or her subjective will, or fail to pay in time due to objective conditions, which may lead to conflicts and disputes between the payer and the payee.

[0003] In the related art, the above-mentioned transaction payment is implemented in that the payee signs an agreement with the payee through a third-party institution, and the payee uses the account designated by the payee as a reserved account. After the third-party institution provides the transaction documents, the payee signs an agreement with the payee through the third-party institution, stipulating that the payee's collection account is used to receive the payment. The payee specifies the payee's collection account by signing an agreement with the third-party institution and the payee. When executing the transaction, the payee directly remits the amount specified in the transaction document to the payee's collection account. However, this method is easily affected by human factors, and the payer is at risk of delayed payment.

[0004] Regarding the problem of delayed payment when conducting transactions between payers and payees in related technologies, no effective solution has been proposed yet. Summary of the invention

[0005] The main purpose of this application is to provide a method, device, storage medium and electronic device for processing deferred payment of transactions, so as to solve the problem of deferred payment when conducting transactions between a payer and a payee in the related technology.

[0006] In order to achieve the above-mentioned purpose, according to one aspect of the present application, a method for processing deferred payment of a transaction is provided. The method includes: receiving a transaction request between a payer and a payee, and extracting a transaction file from the transaction request, wherein the transaction request restricts the payer from transferring money to the payee within a preset period; verifying the transaction file through a third-party institution to obtain a verification result of the transaction file; when the verification result of the transaction file indicates that the verification is passed, determining payment parameters based on the transaction file, wherein the payment parameters include at least one of the following: payment period, payment amount, payment date and payment account; controlling the payment account of the payer to transfer money to the payment account of the payee according to the payment parameters, monitoring the payment behavior of the payer to the payee within a preset period, and judging whether the payment behavior has a risk of deferred payment; when it is detected that the payment behavior has a risk of deferred payment, sending an early warning message to the third-party institution.

[0007] Optionally, after receiving the transaction request between the payer and the payee, the method also includes: obtaining the payer's first account opening information and the payee's second account opening information, performing identity verification on the payee through the first account opening information, and performing identity verification on the payee through the second account opening information; if the identity verification of the payer and the payee is passed, establishing the payer's payment account and the payee's receiving account, and adding the payment account and the receiving account to the transaction file of the transaction request, wherein the payment account and the receiving account cannot be cancelled or changed within a preset period.

[0008] Optionally, the third-party institution verifies the transaction document in the following manner: determining a target number for the transaction document, and obtaining the target file from the third-party institution through the target number; obtaining identity information of the payer and the payee, and performing identity verification on the identity information of the payer and the payee through the third-party institution; if the identity verification fails, determining that the verification result of the transaction document is verification failure; if the identity verification passes, comparing and verifying the transaction document and the target file; if the transaction information in the transaction document and the target file are different, determining that the verification result of the transaction document is verification failure; if the transaction information in the transaction document and the target file are the same, determining that the verification result of the transaction document is verification success.

[0009] Optionally, monitoring the payer's payment behavior to the payee within a preset period includes: sending a first prompt message to the payer on a first preset date before each payment date, wherein the first prompt message is used to prompt the payer to transfer money to the payee on the payment date; determining the account balance of the payment account on a second preset date before each payment date, and sending the account balance to a third-party institution, wherein the first preset date is the same as or different from the second preset date; determining the payment result of the payer to the payee on each payment date, and sending the payment result to the third-party institution.

[0010] Optionally, determining whether a payment behavior has a risk of delayed payment includes: determining whether the account balance is less than the payment amount on each payment date; if the account balance is less than the payment amount, determining that the payment behavior has a risk of delayed payment, and sending a second prompt message to the payee, wherein the second prompt message is used to prompt the payee to deposit a preset amount into the payment account, wherein the preset amount is greater than or equal to the payment amount; if the account balance is greater than or equal to the payment amount, determining whether the transfer from the payee to the payee is successful; if the transfer is successful, determining that the payment behavior does not have a risk of delayed payment; if the transfer fails, controlling the payee to re-initiate the transfer to the payee after a preset period of time; if the re-initiated transfer is successful, determining that the payment behavior does not have a risk of delayed payment; if the re-initiated transfer fails, determining that the payment behavior has a risk of delayed payment.

[0011] Optionally, the method also includes: receiving a payment record query instruction, extracting historical payment records of the payer to the payee from the database through the payment record query instruction; sending the historical payment records to a target user, wherein the target user includes at least one of the following: a payer, a payee and a third-party institution.

[0012] Optionally, the method also includes: determining the payment behavior of the payer within a preset period at intervals of a preset period, and obtaining the credit status of the payer; inputting the payment behavior and the credit status into a risk prediction model to obtain an account risk prediction result of the payer, wherein the risk prediction model is trained by multiple groups of training samples, and each group of training samples includes historical payment behavior, historical credit status, and historical account risk prediction results; when the account risk prediction results indicate that the payer has an account risk, sending an early warning message to a third-party institution.

[0013] In order to achieve the above-mentioned purpose, according to another aspect of the present application, a processing device for transaction deferred payment is provided. The device includes: a receiving unit, which is used to receive a transaction request between a payer and a payee, and extract a transaction file from the transaction request, wherein the transaction request restricts the payer from transferring money to the payee within a preset period; a verification unit, which is used to verify the transaction file through a third-party institution and obtain a verification result of the transaction file; a first determination unit, which is used to determine the payment parameters based on the transaction file when the verification result of the transaction file indicates that the verification is passed, wherein the payment parameters include at least one of the following: payment period, payment amount, payment date and payment account; a control unit, which is used to control the payment account of the payer to transfer money to the payment account of the payee according to the payment parameters, monitor the payment behavior of the payer to the payee within a preset period, and determine whether the payment behavior has a risk of deferred payment; an early warning unit, which is used to send an early warning message to the third-party institution when it is detected that the payment behavior has a risk of deferred payment.

[0014] In order to achieve the above-mentioned purpose, according to another aspect of the present application, a computer program product is provided, including a computer program, which, when executed by a processor, implements the steps of the method for processing deferred transaction payment described in each embodiment of the present application.

[0015] Through this application, the following steps are adopted: receiving a transaction request between a payer and a payee, and extracting a transaction file from the transaction request, wherein the transaction request restricts the payer from transferring money to the payee within a preset period; verifying the transaction file through a third-party institution to obtain a verification result of the transaction file; in the case where the verification result of the transaction file indicates that the verification is passed, determining the payment parameters based on the transaction file, wherein the payment parameters include at least one of the following: payment period, payment amount, payment date and payment account; controlling the payment account of the payer to transfer money to the payment account of the payee according to the payment parameters, monitoring the payment behavior of the payer to the payee within a preset period, and judging whether the payment behavior has a risk of delayed payment; in the case of monitoring the risk of delayed payment in the payment behavior, sending an early warning message to the third-party institution. By introducing a third-party institution to verify the transaction file in the transaction between the payer and the payee, and setting the payment parameters, monitoring the payment behavior of the payer to the payee according to the payment parameters, and sending an early warning message to the third-party institution when monitoring the risk of delayed payment in the payment behavior, the transparency and security of the transaction are enhanced, and a more reliable and convenient payment guarantee is provided for the payer and the payee. This achieves the effect of avoiding the risk of delayed payment of transactions, thereby solving the problem of delayed payment in transactions between payers and payees in related technologies. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The drawings constituting a part of the present application are used to provide a further understanding of the present application. The illustrative embodiments and descriptions of the present application are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0017] Figure 1 It is a flowchart of a method for processing transaction deferred payment provided in an embodiment of the present application;

[0018] Figure 2 is a structural diagram of a transaction processing system provided according to an embodiment of the present application;

[0019] Figure 3 It is a structural diagram of an account opening subsystem provided according to an embodiment of the present application;

[0020] Figure 4 is a schematic diagram of the structure of a transaction file subsystem provided according to an embodiment of the present application;

[0021] Figure 5 It is a structural diagram of a transfer management subsystem provided according to an embodiment of the present application;

[0022] Figure 6 It is a structural diagram of a host transaction subsystem provided according to an embodiment of the present application;

[0023] Figure 7is a schematic diagram of the structure of a third-party institution subsystem provided according to an embodiment of the present application;

[0024] Figure 8 is a schematic diagram of a processing device for transaction deferred payment provided in accordance with an embodiment of the present application;

[0025] Fig. 9 It is a structural block diagram of an electronic device provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0026] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0027] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings 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 should fall within the scope of protection of the present application.

[0028] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present application described here. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0029] It should be noted that the collected information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for display, data for analysis, etc.) involved in this application are information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of relevant data are in compliance with relevant laws, regulations and standards, necessary confidentiality measures are taken, and public order and good customs are not violated, and corresponding operation entrances are provided for users to choose to authorize or refuse. For example, an interface is set up between this system and relevant users or institutions to provide users with corresponding operation entrances for users to choose to agree or refuse the results of automated decision-making; if the user chooses to refuse, the expert decision-making process will be entered.

[0030] It should be noted that the information collected is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of relevant data comply with the relevant laws, regulations and standards of the relevant regions, take necessary confidentiality measures, do not violate public order and good customs, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0031] Example 1

[0032] According to an embodiment of the present application, an embodiment of a method for processing deferred payment of a transaction is also provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0033] The present invention is described below in conjunction with preferred implementation steps. Figure 1 is a flowchart of a method for processing transaction deferred payment provided in an embodiment of the present application, such as Figure 1 As shown, the method comprises the following steps:

[0034] Step S101, receiving a transaction request between a payer and a payee, and extracting a transaction file from the transaction request, wherein the transaction request restricts the payer from transferring money to the payee within a preset period.

[0035] In step S101, the transaction processing system using the method for processing deferred payment of a transaction provided in this embodiment receives a transaction request initiated by a payer and a payee, and the request contains detailed information of the transaction, such as the account information of the payer and the payee, the payment amount, the payment cycle, etc. The transaction processing system extracts key transaction documents from the transaction request, and these transaction documents include but are not limited to contracts, agreements, legal documents, etc.

[0036] Payment conditions and constraints can be specified in the transaction document. For example, for a transaction initiated by a third party to the payer and the payee, the transaction document can be a judgment document, including key information such as the legal basis for payment, payment cycle, amount and deadline. The preset period can be a time period specified by the third party or agreed upon by the payer and the payee, such as one month or one year. The transaction request indicates that the payer needs to transfer money to the payee's collection account within the preset period.

[0037] Step S102: Verify the transaction document through a third-party organization to obtain a verification result of the transaction document.

[0038] In step S102, the transaction processing system may include a third-party institution subsystem, and the transaction processing system uploads the transaction document to the third-party institution subsystem for verification. The transaction document may be a legal agreement, contract, identity certificate, account information, etc. The transaction document describes the conditions of the transaction, the responsibilities and obligations of both the payer and the payee, and the relevant details of the payment. The third-party institution may be a relevant institution, or other reputable financial institution or independent third-party service provider with corresponding verification capabilities.

[0039] The third-party institution subsystem verifies the submitted transaction documents, including but not limited to verifying the authenticity of the documents, confirming the identities of both the payer and the payee, the validity of the account information, the legitimacy of the payment conditions, etc. The verification can be carried out through cross-verification with the original document source, online verification of identity information, real-time query of account status, etc. After the third-party institution completes the verification, it will provide a verification result, clearly indicating whether the transaction document has passed the verification. If the verification result is passed, it indicates that the transaction document is authentic and valid, and the next payment parameter determination and transfer operation can be carried out based on these documents. If the verification result is not passed, the transaction processing system will stop the subsequent payment process, and the payer and the payee will need to resubmit the transaction document.

[0040] Step S103, when the verification result of the transaction document indicates that the verification is passed, determining payment parameters based on the transaction document, wherein the payment parameters include at least one of the following: payment cycle, payment amount, payment date and payment account.

[0041] In step S103, the payment cycle can be the frequency at which the payer needs to transfer money to the payee within a preset period, such as monthly, weekly, annually, etc. For example, in the payment of family support, the payment cycle can be set to be paid once a month. The payment amount refers to the specific amount that needs to be transferred for each payment. The payment date is the specific date when the payment behavior occurs. For example, the transaction document stipulates that the support must be paid before the 15th of each month. The payment account can be the payer's debit card or credit card, etc. In the case where the payment account contains multiple accounts, the priority deduction account can also be set in the payment parameters.

[0042] Step S104, controlling the payment account of the payer to transfer money to the payment account of the payee according to the payment parameters, monitoring the payment behavior of the payer to the payee within a preset period, and determining whether there is a risk of delayed payment in the payment behavior.

[0043] In step S104, after determining the payment parameters, the transaction processing system will automatically control the payer's payment account to transfer money to the payee's payment account according to the set rules. For example, if the payment cycle is once a month, the payment date is the 15th of each month, and the payment amount is 2,000 yuan, the transaction processing system will automatically transfer 2,000 yuan from the payer's account to the payee's account on the 15th of each month, without the payer having to manually operate each time the payment is made.

[0044] In addition, the transaction processing system will monitor payment behavior within a preset period based on payment parameters to check whether the payer completes payment on time and in full. If the risk of delayed payment is detected, the transaction processing system can send early warning information to a third-party institution to take corresponding preventive or remedial measures to ensure the smooth progress of the transaction and protect the legitimate rights and interests of the payer and the payee.

[0045] It should be noted that for scenarios where a third-party institution enforces on-time payment, the transaction processing system is supported to be initiated directly by the third-party institution to the financial institution. The financial institution obtains the customer information of the payer and the payee and obtains the authorization of the payer and the payee by connecting with the subsystem of the third-party institution.

[0046] Step S105: When it is detected that there is a risk of delayed payment in the payment behavior, a warning message is sent to a third-party institution.

[0047] In step S105, the transaction processing system will continuously monitor the payment behavior of the payee to check whether the payment behavior meets the requirements of the payment parameters. For example, the transaction processing system will check whether the payee's account has made corresponding transfer operations on each preset payment date, or monitor whether the account balance is sufficient to cover the upcoming payment. If the transaction processing system monitors that the balance of the payment account is insufficient to pay the agreed payment amount on the payment date, or the payee fails to complete the transfer within the specified time, the transaction processing system will determine that this payment behavior constitutes a risk of deferred payment. In addition, the transaction processing system can also use more complex risk assessment models, combined with factors such as the payee's credit history, account activities, and market conditions, to more comprehensively assess the risk of deferred payment.

[0048] After determining that the payment behavior has the risk of delayed payment, the transaction processing system will automatically generate an early warning message. The early warning message can include the identity of the payer and the payee, the account information involved, the expected payment amount, the payment date, and a detailed description of the risk. The transaction processing system sends the early warning message to the third-party institution, allowing the third-party institution to take appropriate measures, such as contacting the payer to confirm the situation, adjusting the credit rating, initiating legal proceedings, etc., to reduce or eliminate the risk of delayed payment. After receiving the early warning message, the third-party institution will carry out subsequent processing according to its functions and authority. For example, if the third-party institution is a financial institution, it can directly contact the payer and ask the payer to make up the account balance or take other remedial measures; if the third-party institution is a relevant institution, it can send a reminder notice to the payer, and even restart the enforcement procedure if necessary.

[0049] The processing method of transaction deferred payment provided by the embodiment of the present application receives a transaction request between a payer and a payee, and extracts a transaction file from the transaction request, wherein the transaction request restricts the payer from transferring money to the payee within a preset period; verifies the transaction file through a third-party institution, and obtains the verification result of the transaction file; when the verification result of the transaction file indicates that the verification is passed, determines the payment parameters based on the transaction file, wherein the payment parameters include at least one of the following: payment period, payment amount, payment date and payment account; controls the payment account of the payer to transfer money to the payment account of the payee according to the payment parameters, monitors the payment behavior of the payer to the payee within a preset period, and determines whether the payment behavior has a risk of deferred payment; sends an early warning message to the third-party institution when it is monitored that the payment behavior has a risk of deferred payment. By introducing a third-party institution to verify the transaction file in the transaction between the payer and the payee, and setting the payment parameters, monitoring the payment behavior of the payer to the payee according to the payment parameters, and sending an early warning message to the third-party institution when it is monitored that the payment behavior has a risk of deferred payment, the transparency and security of the transaction are enhanced, and a more reliable and convenient payment guarantee is provided for the payer and the payee. This achieves the effect of avoiding the risk of delayed payment of transactions, thereby solving the problem of delayed payment in transactions between payers and payees in related technologies.

[0050] In order to facilitate the monitoring of payment behavior, it is necessary to add the payment account and the receiving account to the transaction file of the transaction request. Optionally, in the method for processing deferred payment of a transaction provided in an embodiment of the present application, after receiving the transaction request between the payer and the payee, the method further includes: obtaining the first account opening information of the payer and the second account opening information of the payee, performing identity verification on the payee through the first account opening information, and performing identity verification on the payee through the second account opening information; if the identity verification of the payer and the payee is passed, establishing the payment account of the payer and the receiving account of the payee, and adding the payment account and the receiving account to the transaction file of the transaction request, wherein the payment account and the receiving account cannot be cancelled or changed within a preset period.

[0051] In some examples, the transaction processing system needs to obtain the first account opening information of the payer and the second account opening information of the payee. The first account opening information and the second account opening information may include, but are not limited to, the name, ID number, account type, account opening bank, contact information, etc. of the account holder. After obtaining the first account opening information and the second account opening information, the transaction processing system will verify the identity of the payer through the first account opening information, and verify the identity of the payee through the second account opening information. The identity verification can be performed by comparing the provided first account opening information and the second account opening information with the database of the financial institution or the third-party verification agency to ensure that the identity of the account holder is authentic.

[0052] After the identity verification of the payer and the payee is passed, the transaction processing system establishes the payer's payment account and the payee's receiving account. The payment account is used to deduct money from the payer, while the receiving account is used to receive money. At the same time, these account information is added to the transaction file of the transaction request as the basis for subsequent payment operations. It should be noted that in order to maintain the stability of the transaction and prevent the payer from evading payment obligations by canceling or changing the account, the transaction processing system will set the payment account and the receiving account to be unable to be cancelled or changed within a preset period.

[0053] After the payment account and the receiving account are established, the detailed information of the payment account and the receiving account will be recorded in the transaction file and filed in the transaction processing system. Once a payment problem occurs, such as delayed payment, the transaction processing system can quickly locate the relevant account information, which is convenient for sending early warning information and solving subsequent problems.

[0054] This embodiment not only ensures the authenticity of the identities of both parties to the transaction and the accuracy of the accounts by adding the payment account and the payment recipient account to the transaction file of the transaction request, but also prevents the possible circumvention behavior of the payee through the account locking mechanism, thereby effectively reducing the risk of delayed payment during the transaction. This is especially important for long-term installment payment scenarios such as divorce alimony, maintenance, and compensation. It provides additional protection for the payee, while also constraining the payment behavior of the payee, ensuring the fairness and stability of the transaction.

[0055] In order to ensure the authenticity of the transaction documents, it is necessary to verify the transaction documents through a third-party organization. Optionally, in the method for processing deferred payment of transactions provided in the embodiment of the present application, the third-party organization verifies the transaction documents in the following ways: determining the target number of the transaction document, and obtaining the target file from the third-party organization through the target number; obtaining the identity information of the payer and the payee, and performing identity verification on the identity information of the payer and the payee through the third-party organization; if the identity verification fails, determining that the verification result of the transaction document is verification failure; if the identity verification passes, comparing and verifying the transaction document and the target document; if the transaction information in the transaction document and the target document are different, determining that the verification result of the transaction document is verification failure; if the transaction information in the transaction document and the target document are the same, determining that the verification result of the transaction document is verification success.

[0056] In some examples, the third-party institution needs to determine the target number of the transaction document, which can be a unique identifier of the transaction document, such as the case number of a legal document, the number of a contract, etc. The third-party institution then uses this target number to retrieve the corresponding target document in its system or database. The target document can be a verified version issued by an authoritative institution. For example, if the transaction document is a legal document, the target document can be a copy of the legal document obtained directly from the system of the relevant institution.

[0057] The third-party agency obtains the identity information of the payer and the payee from the transaction request, including but not limited to name, ID number, contact information, etc. This identity information is verified through an authoritative identity verification system or database to ensure that the identities of the payer and the payee are authentic. If the identity information of the payer or the payee is found to be inconsistent or incorrect during the verification process, the third-party agency will determine the verification result of the transaction document as "verification failed". If the identity information involved in the transaction document is incorrect, the transaction cannot continue, and the payer and the payee are required to resubmit the correct information or documents.

[0058] If the identity information verification is passed, the third-party agency will further compare the transaction information in the transaction file and the target file. This includes consistency checks on key data points such as payment amount, payment cycle, payment date, and payment account. This comparison is based on the target file as the standard to check whether the information in the transaction file is completely consistent with the target file. If there is a difference between the information in the transaction file and the information in the target file, the third-party agency will determine the verification result of the transaction file as "failed verification". This means that the transaction file has been tampered with or is wrong, and further investigation or resubmission of the correct file is required.

[0059] If the information in the transaction file is completely consistent with the information in the target file, and the identity information of the payer and the payee is verified correctly, the third-party agency will determine the verification result of the transaction file as "verified". This means that all key information in the transaction file has been verified, and the transaction can proceed to the next step based on this file, such as determining payment parameters and controlling account transfers.

[0060] This embodiment can effectively prevent payment activities based on erroneous or forged transaction documents through strict verification of transaction documents by a third-party institution, and maintain the fairness and legality of the transaction. In addition, this verification process also provides additional trust guarantee for the payer and the payee, ensuring that the transaction between the payer and the payee is conducted under a transparent and compliant framework, thereby improving the security and efficiency of transactions.

[0061] In order to avoid the risk of deferred payment, it is necessary to monitor the payment behavior of the payer to the payee within a preset period. Optionally, in the method for processing deferred payment of transactions provided in an embodiment of the present application, monitoring the payment behavior of the payer to the payee within a preset period includes: sending a first prompt message to the payer on a first preset date before each payment date, wherein the first prompt message is used to prompt the payer to transfer money to the payee on the payment date; determining the account balance of the payment account on a second preset date before each payment date, and sending the account balance to a third-party institution, wherein the first preset date is the same as or different from the second preset date; determining the payment result of the payer to the payee on each payment date, and sending the payment result to the third-party institution.

[0062] In some examples, a first preset date is set before the payment date of each payment cycle. For example, the first preset date is set five days before the payment date, and the transaction processing system sends a first reminder message to the payee on the first preset date. The payee can be reminded to transfer money to the payee on the upcoming payment date through SMS, email, in-app message or phone notification. The first reminder message can indicate the amount, date and possible account information that the payee needs to transfer, so as to ensure that the payee has enough time to prepare for payment.

[0063] The second preset date can be the same as or different from the first preset date. For example, the second preset date is set to the day before the payment date. On the second preset date, the transaction processing system will check the balance of the payee's payment account to ensure that there are sufficient funds in the account to complete the scheduled payment amount. If the account balance is sufficient, the payment process can proceed as planned; if the account balance is insufficient, the transaction processing system will take corresponding measures, such as reminding the payee to make up the amount again or marking the account as a potential risk account.

[0064] In the process of determining the account balance, the transaction processing system will send the account balance information to the third party institution, which can use this information to further evaluate the payer's credit status or payment ability to prevent potential delayed payment risks. On each preset payment date, the transaction processing system will automatically confirm whether the payer has transferred the money to the payee's collection account according to the payment parameters. The confirmation of the payment result includes checking whether the transfer amount is correct, whether the transfer is successful, and whether there are any abnormalities. If the payment is successful, the transaction processing system will record this result; if the payment fails or is delayed, the transaction processing system will take measures such as sending an early warning message to the third party institution or trying to re-initiate the payment. After determining the payment result, the transaction processing system will send the payment result to the third party institution so that they can monitor the payment in real time or regularly. Feedback on the payment result helps the third party institution to understand the transaction status in a timely manner.

[0065] This embodiment can prevent or promptly discover the risk of delayed payment by monitoring the payment behavior of the payer to the payee, and ensure that the payee can receive the payment on time, thereby improving the efficiency of payment and enhancing the security and reliability of transactions.

[0066] When monitoring payment behavior, it is necessary to determine whether the payment behavior has a risk of delayed payment. Optionally, in the method for processing delayed payment of transactions provided in the embodiment of the present application, determining whether the payment behavior has a risk of delayed payment includes: determining whether the account balance is less than the payment amount on each payment date; when the account balance is less than the payment amount, determining that the payment behavior has a risk of delayed payment, and sending a second prompt message to the payee, wherein the second prompt message is used to prompt the payee to deposit a preset amount into the payment account, wherein the preset amount is greater than or equal to the payment amount; when the account balance is greater than or equal to the payment amount, determining whether the transfer from the payee to the payee is successful; when the transfer is successful, determining that the payment behavior does not have a risk of delayed payment; when the transfer fails, controlling the payee to re-initiate the transfer to the payee after a preset period of time; when the re-initiated transfer is successful, determining that the payment behavior does not have a risk of delayed payment; when the re-initiated transfer fails, determining that the payment behavior has a risk of delayed payment.

[0067] In some examples, on the payment date of each payment cycle, the transaction processing system automatically checks whether the balance of the payer's payment account is greater than or equal to the payment amount. If the account balance is less than the payment amount, the transaction processing system will immediately determine that the payment behavior is at risk of delayed payment. This indicates that the payer may not be able to complete the payment on the payment date and needs to take preventive measures. If the balance is found to be insufficient, the transaction processing system will send a second reminder message to the payer to remind the payer to deposit the preset amount in time. This preset amount is at least equal to the payment amount to ensure that the payer can complete the payment and avoid default. If the payer still fails to make up the balance after receiving the second reminder message, it is determined that there is a risk of delayed payment in this payment behavior. The transaction processing system will take further measures, such as sending an early warning message to a third-party agency so that the third-party agency can intervene and take corresponding risk control measures.

[0068] When the account balance is greater than or equal to the payment amount, the transaction processing system will transfer the money from the payer's payment account to the payee's collection account. If the transfer is successful, the transaction processing system will immediately confirm that there is no risk of delayed payment for this payment. If the transfer fails, the transaction processing system will automatically re-initiate the transfer after a preset period of time (such as a delay to give the payer time to resolve possible technical or financial problems). If the second transfer is successful, it is determined that there is no risk of delayed payment for the payment. However, if the second transfer still fails, the transaction processing system will ultimately determine that there is a risk of delayed payment for the payment. This indicates that the payer has funding problems, account problems or other technical obstacles, and requires the intervention of a third-party agency.

[0069] This embodiment can monitor the payee's account status and payment behavior in real time by judging whether there is a risk of delayed payment, and promptly identify and respond to possible delayed payment risks. This protects the rights and interests of the payee and maintains the stability of the transaction. By sending a second reminder message to the payee and retrying the transfer, the transaction processing system also gives the payee an opportunity to correct the error or solve the funding problem, thereby avoiding a formal record of default and protecting the payee's credit.

[0070] In order to ensure the transparency and openness of transactions, a payment record query function is provided to the target user. Optionally, in the method for processing deferred payment of transactions provided in the embodiment of the present application, the method also includes: receiving a payment record query instruction, extracting the historical payment record of the payer to the payee from the database through the payment record query instruction; sending the historical payment record to the target user, wherein the target user includes at least one of the following: the payer, the payee and the third-party institution.

[0071] In some examples, the payment record query instruction may include query parameters, such as identity information of the payer and the payee, a specific transaction time period, or a transaction type. The payment record query instruction may be submitted in a variety of ways, such as through an application interface, an email request, or an application program interface call. After receiving the payment record query instruction from the payer, the payee, or a third-party institution, the transaction processing system extracts the historical payment records of the payer to the payee from the database. The database stores detailed information on each transaction, including payment date, payment amount, transfer status (successful or failed), payment account information, payment account information, etc. The queried historical payment records will be sent to the target user, that is, the user who issued the query instruction. The target user can be the payer, used to check his or her payment history or prepare financial reports; the target user can also be the payee, used to track whether the payment has been received on time; the target user can also be a third-party institution, used to monitor payment behavior, assess credit risk, or handle legal affairs. Sending historical payment records can be done by email, SMS, system message, or directly providing online access rights.

[0072] During the entire query and sending process, the transaction processing system sets strict permission control for database queries, and only authorized users can access payment records. Encryption technology is used during the sending process to ensure that information is not intercepted or tampered with during transmission. Ensure data security and user privacy. In addition, the transaction processing system complies with relevant laws, regulations and standards to protect users' personal information and transaction data.

[0073] This embodiment provides accurate and timely payment history information by providing a historical payment record query function to help all parties understand transaction dynamics, while ensuring data privacy and security through a secure transmission method.

[0074] In order to ensure the completion of the transaction, risk prediction is performed on the payer regularly. Optionally, in the method for processing deferred payment of transactions provided in the embodiment of the present application, the method also includes: determining the payment behavior of the payer within a preset period at intervals of a preset period, and obtaining the credit status of the payer; inputting the payment behavior and the credit status into a risk prediction model to obtain the account risk prediction result of the payer, wherein the risk prediction model is trained by multiple groups of training samples, and each group of training samples includes historical payment behavior, historical credit status and historical account risk prediction results; when the account risk prediction result indicates that the payer has an account risk, sending an early warning message to a third-party institution.

[0075] In some examples, the transaction processing system may collect and analyze the payment behavior data of the payer within a preset period (e.g., one month). Payment behavior data includes, but is not limited to, payment frequency, payment amount, punctuality of payment date, whether there is a record of delayed payment or non-payment, etc. These data can reflect the financial status and payment habits of the payer, and are an important basis for assessing its account risk. The transaction processing system can also obtain the payer's latest credit status after obtaining the payer's authorization. The credit status may include the payer's credit score, historical debt record, whether there are any bad credit events, etc. This information can reflect the payer's overall credit status, which is crucial for predicting its future ability and willingness to pay.

[0076] The collected payment behavior and credit status data are input into the risk prediction model. The risk prediction model can be developed based on machine learning technology and trained with a large number of training samples to identify patterns and trends related to account risk. Each set of training samples contains historical payment behavior, historical credit status, and corresponding account risk prediction results. The goal of the model is to learn the relationship between these inputs and outputs so that future account risks can be predicted based on current payment behavior and credit status data. The risk prediction model outputs the payer's account risk prediction results based on the input data. The account risk prediction result can be a risk score or risk level to quantify the level of account risk. If the model predicts that the account is high risk, the transaction processing system will mark the account as a potential risk account.

[0077] If the account risk prediction results show that the payer has account risk, the transaction processing system will send an early warning message to the third-party institution, allowing the third-party institution to take corresponding measures to deal with the risk, such as contacting the payer to confirm the situation, adjusting payment conditions, increasing monitoring frequency or taking legal action.

[0078] This embodiment manages payment risks more effectively and protects the rights and interests of payees by regularly predicting risks for payers. At the same time, it provides credit management and risk warning services for payers, thereby promoting the health and stability of the entire payment ecosystem.

[0079] Example 2

[0080] According to another embodiment of the present application, a transaction processing system is also provided. Figure 2 Schematic diagram of the structure of the transaction processing system provided according to the embodiment of the present application. Figure 2 As shown, the system includes: an account opening subsystem 201, a transaction file subsystem 202, a transfer management subsystem 203, a host transaction subsystem 204 and a third-party institution subsystem 205.

[0081] Among them, the account opening subsystem 201 is used for pre-examination of personal account opening elements, opening of personal financial accounts (including debit card and credit card account opening), and pushing account opening information, payer's debit card account balance, credit card remaining balance and other information to the transfer management subsystem. The main implementation scenarios include: uploading the account opening elements required for the account opening card types of both parties; online verification of account opening elements and verification of personal information stored in the bank host; pushing account opening information, account balance information, etc. to the transfer management subsystem 203; regularly querying and pushing product-related account status warning information to the transfer management subsystem 203; returning account opening results, information push and other results; before the total payment amount is completed, the two parties cannot cancel or change the account unless it is force majeure.

[0082] For example, Figure 3 Schematic diagram of the structure of the account opening subsystem provided according to the embodiment of the present application. Figure 3 As shown, the account opening subsystem 201 includes: an account opening information uploading module 301, an account opening information pre-review module 302, an account opening module 303, a transfer management subsystem information interaction module 304, an account early warning information query module 305, and an account cancellation determination module 306.

[0083] Among them, the account opening information upload module 301: (If an account is required) If both parties apply to use the product, the bank staff will enter the account opening information provided by the party customer into the account opening. If the use of the product is initiated by a third-party institution, the system will enter the account opening based on the party information transmitted by the third-party institution subsystem 205;

[0084] Account opening information pre-examination module 302: (if account opening is required) conduct online identity verification and credit inquiry for account opening information according to the account opening card type, automatically calculate the overdraft limit for credit card applications, and mark the risk if the overdraft limit is lower than the deducted amount;

[0085] Account opening module 303: For applications that have passed the account opening review, the account will be opened according to the type of card applied for. If the payment amount of the personal debit card meets the restrictions of the second type of account, the second type of account can be opened.

[0086] Transfer management subsystem information interaction module 304: account opening results, account status, account balance, account transaction behavior, and deduction amount information transmission and interaction.

[0087] Account warning information query module 305: for withholding agreements that do not require new account opening, query the status of the submitted account; regularly query the status of the account associated with the withholding agreement;

[0088] Account cancellation determination module 306: The account that has applied for account cancellation is checked to see whether there is any unfinished judgment withholding agreement. If so, the account cancellation operation is not allowed.

[0089] The transaction file subsystem 202 is used to store transaction files, generate withholding agreement numbers, verify submitted transaction files, and ensure the authenticity of the files. The main scenarios include: for files from third-party institutions, call the interface to transmit file case numbers, party ID numbers and other information to the third-party institution subsystem 205 for authenticity verification; for personal agreement files, upload personal authenticity commitment files to the system, and uniquely bind the uploaded agreement files and commitment files to the withholding agreement code and financial account.

[0090] For example, Figure 4 Schematic diagram of the structure of the transaction file subsystem provided according to the embodiment of the present application. Figure 4 As shown, the transaction file subsystem 202 includes a protocol uploading module 401 , a protocol storage module 402 , a transaction file verification module 403 , and a protocol and financial account binding protocol management module 404 .

[0091] Wherein, the withholding agreement uploading module 401: inputs the scanned agreement uploaded by the bank staff or the scanned agreement transmitted by the third-party institution, and automatically generates a unique withholding agreement number according to the agreement;

[0092] Agreement storage module 402: storing the received transaction documents, commitment documents, personal agreements and other documents according to the withholding agreement number for future reference;

[0093] Transaction document verification module 403: For parties who apply to use the withholding product on their own, the submitted transaction document information is pushed to the third-party institution subsystem 205, and the authenticity is verified based on the case number, the party’s ID number and other information, and the verification result is recorded;

[0094] The agreement management module 404 for binding the agreement with the financial account is to uniquely bind the withholding agreement number with the financial account for payment and collection, and establish a relationship file.

[0095] The transfer management subsystem 203 is used to set payment parameters, push account prompt information, account transaction information to each stakeholder (via SMS notification or system data push, etc.), mainly including the following scenarios: set the stakeholder account bound for direct debit transfer according to the transaction file, and set the account transfer rules, for example, the payer deducts the payment in the order of debit card first and credit card later, the transfer frequency cycle is the 25th of each month, and the transfer amount is 2,000 yuan; according to the set deduction date, send a SMS reminder before each deduction date (such as T-5 days) to remind the payer to transfer enough deduction amount to the bound debit card, Or adjust the available credit limit of the credit card to a balance sufficient for deduction, such as sending a text message reminder to the payer on the 20th of each month; push the account numbers and deduction amounts to be deducted the next day to the host transaction subsystem 204 in batches at a fixed time every day (such as 18:00 every day), and receive the returned processing results; sort out the deduction results of the day, and transmit the deduction results to the third-party institution subsystem 205 through the interface transmission method, and notify the payer and the payee through text messages; regularly push the account status and bank flow bound to the deduction agreement of the transaction processing system enforced by the third-party institution to the third-party institution subsystem 205. Perform transaction model risk assessment on the payer account associated with the enforcement, and push the assessment results to the third-party institution subsystem 205 for high-risk accounts.

[0096] For example, Figure 5 Schematic diagram of the structure of the transfer management subsystem provided according to the embodiment of the present application. Figure 5 As shown, the transfer management subsystem 203 includes a payment withholding rule module 501, a historical withholding detail query module 502, a polling reminder content module 503, a batch withholding information host interaction module 504, a withholding transaction result notification module 505, a risk model judgment module 506, and a withholding agreement adjustment module 507.

[0097] Among them, the payment withholding rule module 501: the bank staff sets the withholding transfer related rules, including the cycle, time, amount, and order of withholding, according to the transaction documents and supplementary agreements and other documents;

[0098] Historical withholding details query module 502: The bank provides an interface, and the third-party institution can initiate a query request through the third-party institution subsystem 205 to query the historical payment details and payment results of the withholding account;

[0099] Polling reminder content module 503: polling the deduction date of each deduction agreement, generating corresponding special reminder content according to the transfer rules for the agreement with deduction on day T, and sending SMS reminders on days TN, where N is set by the bank staff;

[0100] Batch deduction information host interaction module 504: for the agreement of deduction on day T, generate batch deduction file details, send the batch deduction file to the host transaction subsystem on day T-1, and receive the processing result data returned by the host transaction on day T, parse and store it in the warehouse;

[0101] Withholding transaction result notification module 505: generates a data stream in a specified format by combining the above processing results with the judgment number and the agreement number every day, and pushes them to the transaction stakeholders and third-party institutions respectively;

[0102] Risk model judgment module 506: Periodic query of the payer's transaction behavior, credit status, etc., automatically feeds the account risk judgment model, and pushes warning information to third-party institutions for payment accounts subject to mandatory execution;

[0103] Deduction agreement adjustment module 507: The payer or a third-party institution initiates an application for adjustment of the deduction rules, and the bank staff determines whether to implement the adjustment based on the application documents and actual conditions.

[0104] The host transaction subsystem 204 is used to process fund deductions in batches, and its main implementation scenarios are: receiving batch deduction information sent by the transfer management subsystem 203 and making deductions; for transactions where transfers fail, making a second transfer after a specified time interval on the same day, and if the second transfer fails, no supplementary transfer will be made; and returning the transfer processing results to the deduction product management subsystem according to the sent batch number.

[0105] For example, Figure 6 Schematic diagram of the structure of the host transaction subsystem provided according to the embodiment of the present application. Figure 6 As shown, the host transaction subsystem 204 includes a fund deduction processing module 601 and an information interaction module 602.

[0106] The module 601 for processing fund deductions: processes the account transfer transactions one by one according to the batch deduction files, and records the transactions in the accounts;

[0107] Information interaction module 602: receives the file sent by the judgment payment withholding product management subsystem and returns the processing result file.

[0108] The third-party institution subsystem 205 is used to transmit the relevant information of the enforcer to the transfer management subsystem 230, and receive the relevant account warning and transaction processing information transmitted by the bank. The main implementation scenarios are: data interaction with the bank system, including initiating compulsory execution instructions for the use of withholding products, verifying the information of both parties, receiving transaction processing result information, etc.; managing payment personnel information and file information.

[0109] For example, Figure 7 Schematic diagram of the structure of the third-party institution subsystem provided according to the embodiment of the present application. Figure 7As shown, the third-party institution subsystem 205 includes a file management module 701, a file verification module 702, a deduction request execution module 703, and a payment account data query module 704.

[0110] Document management module 701: The third-party institution enters transaction documents and other information into the system platform;

[0111] Document verification module 702: comparing the authenticity of transaction documents according to bank request parameters;

[0112] Withholding request execution module 703: the party agrees to be initiated by a third-party institution, or the third-party institution enforces the use of the withholding product scenario, and the third-party institution initiates a request to the bank to use the product and transmits relevant information to the bank;

[0113] Payment account data query module 704: supports third-party institutions to query the account performance information of the bank's deduction and transfer, including historical payment details, etc.

[0114] This embodiment binds the transaction documents, deduction and transfer agreements, and personal financial accounts of third-party institutions through the transaction processing system, and combines fund supervision products and credit card products to solve problems such as untimely and non-performance of transactions, and can help the development of savings and credit card businesses.

[0115] It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and that, although a logical order is shown in the flowcharts, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0116] Example 3

[0117] The embodiment of the present application also provides a processing device for transaction deferred payment. It should be noted that the processing device for transaction deferred payment in the embodiment of the present application can be used to execute the processing method for transaction deferred payment provided in the embodiment of the present application. The processing device for transaction deferred payment provided in the embodiment of the present application is introduced below.

[0118] Figure 8 Schematic diagram of a processing device for transaction deferred payment provided in accordance with an embodiment of the present application. Figure 8 As shown, the device comprises:

[0119] The receiving unit 801 is used to receive a transaction request between a payer and a payee, and extract a transaction file from the transaction request, wherein the transaction request restricts the payer from transferring money to the payee within a preset period;

[0120] A verification unit 802 is used to verify the transaction document through a third-party organization to obtain a verification result of the transaction document;

[0121] A first determining unit 803 is configured to determine a payment parameter based on the transaction document when the verification result of the transaction document indicates that the verification is passed, wherein the payment parameter includes at least one of the following: a payment cycle, a payment amount, a payment date, and a payment account;

[0122] The control unit 804 is used to control the payment account of the payer to transfer money to the payment account of the payee according to the payment parameters, monitor the payment behavior of the payer to the payee within a preset period, and determine whether the payment behavior has a risk of delayed payment;

[0123] The early warning unit 805 is used to send early warning information to a third-party institution when it is detected that there is a risk of delayed payment in the payment behavior.

[0124] The processing device for deferred payment of a transaction provided in an embodiment of the present application receives a transaction request between a payer and a payee through a receiving unit 801, and extracts a transaction file from the transaction request, wherein the transaction request restricts the payer from transferring money to the payee within a preset period; a verification unit 802 verifies the transaction file through a third-party institution to obtain a verification result of the transaction file; a first determination unit 803 determines payment parameters based on the transaction file when the verification result of the transaction file indicates that the verification is passed, wherein the payment parameters include at least one of the following: payment period, payment amount, payment date and payment account; a control unit 804 controls the payment account of the payee to transfer money to the payment account of the payee according to the payment parameters, monitors the payment behavior of the payer to the payee within a preset period, and determines whether the payment behavior has a risk of deferred payment; an early warning unit 805 sends an early warning message to a third-party institution when it is monitored that the payment behavior has a risk of deferred payment. By introducing a third party to verify the transaction documents and set payment parameters in the transaction between the payer and the payee, the payment behavior of the payer to the payee is monitored according to the payment parameters, and when the payment behavior is monitored to have a risk of delayed payment, an early warning message is sent to the third party, thereby enhancing the transparency and security of the transaction and providing a more reliable and convenient payment guarantee for the payer and the payee. Thus, the effect of avoiding the risk of delayed payment of the transaction is achieved. In turn, the problem of delayed payment in transactions between the payer and the payee in the related technology is solved.

[0125] Optionally, in the transaction deferred payment processing device provided in the embodiment of the present application, the device also includes: a first acquisition unit, used to obtain the first account opening information of the payer and the second account opening information of the payee, perform identity verification on the payee through the first account opening information, and perform identity verification on the payee through the second account opening information; an adding unit, used to establish the payer's payment account and the payee's receiving account when the identity verification of the payer and the payee is passed, and add the payment account and the receiving account to the transaction file of the transaction request, wherein the payment account and the receiving account cannot be cancelled or changed within a preset period.

[0126] Optionally, in the transaction deferred payment processing device provided in the embodiment of the present application, the device also includes: a second acquisition unit, used to determine the target number of the transaction file, and obtain the target file from a third-party institution through the target number; a third acquisition unit, used to obtain the identity information of the payer and the payee, and perform identity verification on the identity information of the payer and the payee through the third-party institution; a second determination unit, used to determine that the verification result of the transaction file is verification failure if the identity verification fails; a comparison unit, used to compare and verify the transaction file and the target file if the identity verification passes; a third determination unit, used to determine that the verification result of the transaction file is verification failure if the transaction information in the transaction file and the target file are different; and a fourth determination unit, used to determine that the verification result of the transaction file is verification success if the transaction information in the transaction file and the target file are the same.

[0127] Optionally, in the transaction deferred payment processing device provided in the embodiment of the present application, the control unit 804 includes: a first prompt module, used to send a first prompt message to the payee on a first preset date before each payment date, wherein the first prompt message is used to prompt the payee to transfer money to the payee on the payment date; a first determination module, used to determine the account balance of the payment account on a second preset date before each payment date, and send the account balance to a third-party institution, wherein the first preset date is the same as or different from the second preset date; a second determination module, used to determine the payment result of the payee to the payee on each payment date, and send the payment result to the third-party institution.

[0128] Optionally, in the transaction deferred payment processing device provided in the embodiment of the present application, the control unit 804 includes: a first judgment module, used to judge whether the account balance is less than the payment amount on each payment date; a third determination module, used to determine that the payment behavior has a risk of deferred payment when the account balance is less than the payment amount, and send a second prompt message to the payee, wherein the second prompt message is used to prompt the payee to deposit a preset amount into the payment account, wherein the preset amount is greater than or equal to the payment amount; a second judgment module, used to judge whether the transfer from the payee to the payee is successful when the account balance is greater than or equal to the payment amount; a fourth determination module, used to determine that the payment behavior does not have a risk of deferred payment when the transfer is successful; an initiation module, used to control the payee to re-initiate the transfer to the payee after a preset period of time when the transfer fails; a fifth determination module, used to determine that the payment behavior does not have a risk of deferred payment when the re-initiated transfer is successful; a sixth determination module, used to determine that the payment behavior has a risk of deferred payment when the re-initiated transfer fails.

[0129] Optionally, in the transaction deferred payment processing device provided in the embodiment of the present application, the device also includes: an extraction unit, used to receive a payment record query instruction, and extract historical payment records of the payer to the payee from the database through the payment record query instruction; a first sending unit, used to send the historical payment records to a target user, wherein the target user includes at least one of the following: a payer, a payee and a third-party institution.

[0130] Optionally, in the transaction deferred payment processing device provided in the embodiment of the present application, the device also includes: a fifth determination unit, used to determine the payment behavior of the payer within a preset period every preset period, and obtain the credit status of the payer; an input unit, used to input the payment behavior and credit status into a risk prediction model to obtain the account risk prediction result of the payer, wherein the risk prediction model is trained by multiple groups of training samples, and each group of training samples includes historical payment behavior, historical credit status and historical account risk prediction results; a second sending unit, used to send early warning information to a third-party institution when the account risk prediction result indicates that the payer has an account risk.

[0131] It should be noted here that the above-mentioned receiving unit 801, verification unit 802, first determination unit 803, control unit 804 and early warning unit 805 correspond to steps S101 to S105 in Example 1, and the two modules and the corresponding steps implement the same instances and application scenarios, but are not limited to the contents disclosed in the above-mentioned embodiments.

[0132] The processing device for transaction deferred payment includes a processor and a memory. The above-mentioned receiving unit 801, verification unit 802, first determination unit 803, control unit 804 and early warning unit 805 are all stored in the memory as program units, and the processor executes the above-mentioned program units stored in the memory to realize corresponding functions.

[0133] Example 4

[0134] An embodiment of the present application may provide an electronic device, Fig. 9 is a structural block diagram of an electronic device provided according to an embodiment of the present application. Fig. 9 As shown, the electronic device may include: one or more ( Fig. 9 (only one is shown) processor 902, memory 904, storage controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0135] Among them, the memory can be used to store software programs and modules, such as program instructions / modules corresponding to the methods and devices in the embodiments of the present application, and the processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, realizing the above-mentioned method. The memory may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include a memory remotely arranged relative to the processor, and these remote memories may be connected to the terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0136] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: receive a transaction request between a payer and a payee, and extract a transaction file from the transaction request, wherein the transaction request restricts the payer from transferring money to the payee within a preset period; verify the transaction file through a third-party agency to obtain a verification result of the transaction file; when the verification result of the transaction file indicates that the verification is passed, determine the payment parameters based on the transaction file, wherein the payment parameters include at least one of the following: payment cycle, payment amount, payment date and payment account; control the payer's payment account to transfer money to the payee's collection account according to the payment parameters, monitor the payer's payment behavior to the payee within a preset period, and determine whether the payment behavior has a risk of delayed payment; when it is monitored that the payment behavior has a risk of delayed payment, send an early warning message to the third-party agency.

[0137] The processor can also call the information and application stored in the memory through the transmission device to perform the following steps: obtain the first account opening information of the payer and the second account opening information of the payee, verify the identity of the payee through the first account opening information, and verify the identity of the payee through the second account opening information; if the identity verification of the payer and the payee is passed, establish the payer's payment account and the payee's receiving account, and add the payment account and the receiving account to the transaction file of the transaction request, wherein the payment account and the receiving account cannot be cancelled or changed within a preset period.

[0138] The processor can also call the information and application stored in the memory through the transmission device to perform the following steps: determine the target number of the transaction file, and obtain the target file from a third-party institution through the target number; obtain the identity information of the payer and the payee, and perform identity verification on the identity information of the payer and the payee through a third-party institution; if the identity verification fails, determine that the verification result of the transaction file is verification failure; if the identity verification passes, compare and verify the transaction file and the target file; if the transaction information in the transaction file and the target file is different, determine that the verification result of the transaction file is verification failure; if the transaction information in the transaction file and the target file is the same, determine that the verification result of the transaction file is verification passed.

[0139] The processor can also call the information and application stored in the memory through the transmission device to perform the following steps: sending a first prompt message to the payer on a first preset date before each payment date, wherein the first prompt message is used to prompt the payer to transfer money to the payee on the payment date; determining the account balance of the payment account on a second preset date before each payment date, and sending the account balance to a third-party institution, wherein the first preset date is the same as or different from the second preset date; determining the payment result of the payer to the payee on each payment date, and sending the payment result to the third-party institution.

[0140] The processor can also call the information and application stored in the memory through the transmission device to perform the following steps: determine whether the account balance is less than the payment amount on each payment date; if the account balance is less than the payment amount, determine that the payment behavior has a risk of delayed payment, and send a second prompt message to the payee, wherein the second prompt message is used to prompt the payee to deposit a preset amount into the payment account, wherein the preset amount is greater than or equal to the payment amount; if the account balance is greater than or equal to the payment amount, determine whether the transfer from the payee to the payee is successful; if the transfer is successful, determine that the payment behavior does not have a risk of delayed payment; if the transfer fails, control the payee to re-initiate the transfer to the payee after a preset period of time; if the re-initiated transfer is successful, determine that the payment behavior does not have a risk of delayed payment; if the re-initiated transfer fails, determine that the payment behavior has a risk of delayed payment.

[0141] The processor can also call the information and application programs stored in the memory through the transmission device to perform the following steps: receive a payment record query instruction, and extract the historical payment records of the payer to the payee from the database through the payment record query instruction; send the historical payment records to the target user, wherein the target user includes at least one of the following: the payer, the payee and the third-party institution.

[0142] The processor can also call the information and application programs stored in the memory through the transmission device to perform the following steps: determine the payment behavior of the payer within a preset period at intervals of a preset period, and obtain the credit status of the payer; input the payment behavior and credit status into the risk prediction model to obtain the account risk prediction result of the payer, wherein the risk prediction model is trained by multiple groups of training samples, and each group of training samples includes historical payment behavior, historical credit status and historical account risk prediction results; when the account risk prediction results indicate that the payer has an account risk, send an early warning message to a third-party institution.

[0143] It can be understood by those skilled in the art that Fig. 9 The structure shown is for illustration only, and the electronic device may also be a smart phone, a tablet computer, a PDA, a mobile Internet device (MID), a PAD or other terminal device. Fig. 9 The structure of the electronic device is not limited. Fig. 9 More or fewer components (such as network interfaces, display devices, etc.) shown in, or having Fig. 9 Different configurations are shown.

[0144] A person of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a computer-readable storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0145] Example 5

[0146] The embodiment of the present application further provides a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the method for processing transaction deferred payment provided in the first embodiment.

[0147] Optionally, in this embodiment, the above storage medium may be located in any computer terminal in a computer terminal group in a computer network, or in any mobile terminal in a mobile terminal group.

[0148] The present application also provides a computer program product, which, when executed on a data processing device, is suitable for executing the program steps of the method for processing transaction deferred payment.

[0149] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0150] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0151] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0152] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0153] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0154] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or optical disk and other media that can store program codes.

[0155] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for processing deferred payment of a transaction, characterized in that: include: Receiving a transaction request between a payer and a payee, and extracting a transaction file from the transaction request, wherein the transaction request restricts the payer from transferring money to the payee within a preset period; Verify the transaction documents through a third-party organization to obtain verification results of the transaction documents; If the verification result of the transaction document indicates that the verification is passed, determining payment parameters based on the transaction document, wherein the payment parameters include at least one of the following: payment cycle, payment amount, payment date and payment account; Controlling the payment account of the payer to transfer funds to the payment account of the payee according to the payment parameters, monitoring the payment behavior of the payer to the payee within the preset period, and determining whether the payment behavior has a risk of delayed payment; When it is detected that there is a risk of delayed payment in the payment behavior, an early warning message is sent to the third-party institution.

2. The method according to claim 1, characterized in that After receiving the transaction request between the payer and the payee, the method further includes: Acquire the first account opening information of the payer and the second account opening information of the payee, perform identity verification on the payer through the first account opening information, and perform identity verification on the payee through the second account opening information; When the identity verification of the payer and the payee is passed, a payment account of the payer and a receiving account of the payee are established, and the payment account and the receiving account are added to the transaction file of the transaction request, wherein the payment account and the receiving account cannot be cancelled or changed within the preset period.

3. The method according to claim 1, characterized in that The third party institution verifies the transaction documents in the following ways: Determine the target number of the transaction file, and obtain the target file from the third-party institution through the target number; Obtaining identity information of the payer and the payee, and performing identity verification on the identity information of the payer and the payee through the third-party institution; If the identity verification fails, determining the verification result of the transaction document as verification failure; If the identity verification is passed, comparing and verifying the transaction file and the target file; In the case where the transaction information in the transaction file and the transaction information in the target file are different, determining that the verification result of the transaction file is verification failure; In the case where the transaction information in the transaction file is identical to the transaction information in the target file, the verification result of the transaction file is determined to be verification passed.

4. The method according to claim 1, characterized in that: Monitoring the payment behavior of the payer to the payee within the preset period includes: Sending a first reminder message to the payee on a first preset date before each payment date, wherein the first reminder message is used to remind the payee to transfer money to the payee on the payment date; Determining the account balance of the payment account on a second preset date before each payment date, and sending the account balance to the third-party institution, wherein the first preset date is the same as or different from the second preset date; The payment result of the payer to the payee is determined on each payment date, and the payment result is sent to the third-party institution.

5. The method according to claim 4, characterized in that Judging whether the payment behavior has a risk of delayed payment includes: Determining on each payment date whether the account balance is less than the payment amount; In the case where the account balance is less than the payment amount, determining that the payment behavior has a risk of delayed payment, and sending a second prompt message to the payer, wherein the second prompt message is used to prompt the payer to deposit a preset amount into the payment account, wherein the preset amount is greater than or equal to the payment amount; If the account balance is greater than or equal to the payment amount, determining whether the transfer from the payer to the payee is successful; In the case of a successful transfer, it is determined that there is no risk of delayed payment in the payment behavior; In the event of a transfer failure, controlling the payer to re-initiate a transfer to the payee after a preset period of time; In the event that the re-initiated transfer is successful, it is determined that there is no risk of delayed payment in the payment behavior; In the event that the re-initiated transfer fails, it is determined that the payment behavior has a risk of delayed payment.

6. The method according to claim 1, characterized in that The method further comprises: receiving a payment record query instruction, and extracting historical payment records of the payer to the payee from a database through the payment record query instruction; The historical payment record is sent to a target user, wherein the target user includes at least one of the following: the payer, the payee and the third-party institution.

7. The method according to claim 1, characterized in that The method further comprises: Determine the payment behavior of the payer within the preset period at every preset period, and obtain the credit status of the payer; Inputting the payment behavior and the credit status into a risk prediction model to obtain the account risk prediction result of the payer, wherein the risk prediction model is trained by multiple groups of training samples, each group of training samples includes historical payment behavior, historical credit status and historical account risk prediction results; When the account risk prediction result indicates that the payer has account risk, the warning information is sent to the third-party institution.

8. A device for processing transaction deferred payment, characterized in that: include: A receiving unit, configured to receive a transaction request between a payer and a payee, and extract a transaction file from the transaction request, wherein the transaction request restricts the payer from transferring money to the payee within a preset period; A verification unit, used to verify the transaction document through a third-party organization to obtain a verification result of the transaction document; A first determining unit, configured to determine a payment parameter based on the transaction document if the verification result of the transaction document indicates that the verification is passed, wherein the payment parameter includes at least one of the following: a payment cycle, a payment amount, a payment date, and a payment account; A control unit, configured to control the payment account of the payer to transfer funds to the payment account of the payee according to the payment parameters, monitor the payment behavior of the payer to the payee within the preset period, and determine whether there is a risk of delayed payment in the payment behavior; The early warning unit is used to send early warning information to the third-party institution when it is detected that there is a risk of delayed payment in the payment behavior.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored executable program, wherein when the executable program is run, the device where the computer-readable storage medium is located is controlled to execute the transaction deferred payment processing method described in any one of claims 1 to 7.

10. An electronic device, characterized in that: It includes one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the transaction deferred payment processing method described in any one of claims 1 to 7.

11. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the method for processing deferred payment of a transaction as described in any one of claims 1 to 7 is implemented.

Images