Trusted payment refund method and system based on distributed system

Abstract

The embodiment of the invention provides a trusted payment refund method and system based on a distributed system. The method comprises the following steps: receiving a refund request; preliminary verification and information verification are carried out on the received refund request, the refund request passing the verification is persisted to a database refund information record table, the refund request passing the verification is marked as a to-be-processed refund request, the input interface supports idempotent operation, and distributed lock locking processing is carried out on a refund original order number field; and obtaining the refund request marked as the to-be-processed state in the refund record table by adopting timed task scanning, marking the refund request as in-processing, and executing a refund service on the to-be-processed refund order based on the distributed transaction processing mechanism and the capital flow of the trusted payment service. According to the application, the efficiency, security and consistency of the refund operation are realized by introducing the distributed lock, the distributed transaction processing mechanism and the intelligent contract technology.

Description

Technical Field

[0001] The present application relates to the field of supply chain finance technology, and in particular to a method and system for entrusted payment refund based on a distributed system. Background Art

[0002] With the rapid development of supply chain finance business, supply chain finance management systems are transforming from traditional single applications to distributed systems. Distributed systems split the supply chain finance system into multiple subsystems, such as order center, account center, etc., and all subsystems form a mesh structure. Distributed systems have been widely used in the field of Internet finance due to their advantages such as high concurrency, high availability and scalability. Entrusted payment is a payment method for loan funds, in which the lender pays the loan funds to the borrower's transaction counterparty that meets the contractual purpose based on the borrower's withdrawal application and payment entrustment. The main purpose of this payment method is to reduce the risk of loan misappropriation.

[0003] In the supply chain finance business, due to the participation of core enterprises, entrusted payment means that the lender (a banking financial institution established in accordance with the law) pays the loan funds to the borrower based on the borrower's withdrawal application and payment entrustment, and immediately transfers the loan funds from the borrower's account to the borrower's transaction counterparty that meets the purpose agreed in the contract. The purpose is to reduce the risk of loan misappropriation. It is a common payment method in supply chain finance.

[0004] Refund function: after the borrower purchases goods from the core enterprise in the form of entrusted loan payment, for some reason, he does not want the goods and initiates a return application, similar to an e-commerce mall. However, due to the background of supply chain finance business, the amount of goods purchased by the borrower is large and the interest is high, so the refund will not occur until a few days after the loan, and in most cases only part of the amount may be refunded. In actual operation, the borrower and the core enterprise negotiate a refund, rather than the traditional e-commerce full refund and full correction of the loan. Therefore, in most cases, this refund is a refund of the specified principal and specified interest. Combined with the background of supply chain finance, we can also call this entrusted payment refund a return refund.

[0005] However, as the business develops, borrowers are increasingly seeking returns and refunds after purchasing goods with loans on core enterprise platforms. Currently, the return and refund process usually relies on manual review, which has problems such as low processing efficiency, high cost, and easy errors.

[0006] In the prior art, refund operations usually require complex data interactions and transaction processing between multiple services. How to ensure rapid response, data consistency and security in the refund process has become an urgent problem to be solved. Summary of the invention

[0007] The present application provides a method and system for entrusted payment refund based on a distributed system, which can solve the problem that the supply chain financial business in the prior art lacks a mature automated solution for processing returns and refunds after entrusted payment. For businesses that require returns and refunds after entrusted payment, offline manual approval is often used, which has technical problems such as low processing efficiency, high cost, and easy errors.

[0008] In a first aspect, the present application provides a distributed system-based entrusted payment refund method, comprising the following steps:

[0009] Receive a refund request, the refund request including the refund serial number, the original order number, the refund principal, and the refund interest;

[0010] Perform preliminary verification and information verification on the refund request received, persist the verified refund request to the refund information record table in the database, and mark the verified refund request as pending. The input interface supports idempotent operations and performs distributed lock processing on the refund order number field;

[0011] Use scheduled task scanning to obtain refund requests marked as pending in the refund record table, and mark them as being processed. Based on the distributed transaction processing mechanism and entrusted payment business fund flow, the refund business is executed for the refund orders to be processed, and the refund processing information is issued simultaneously;

[0012] When an error compensation message thrown during the refund service execution operation is received, error compensation is performed on the refund service being processed based on the error compensation mechanism.

[0013] In combination with the first aspect, in one implementation, the preliminary verification and information verification of the received refund request are performed, the refund request that passes the verification is persisted to the refund information record table of the database, and the refund request that passes the verification is marked as pending, which specifically includes the following steps:

[0014] Control the refund entry interface of the business middle office order center to verify the refund information of the refund request that has passed the preliminary verification;

[0015] If the verification is successful, the refund information will be persisted to the refund information record table in the database and the status will be marked as pending;

[0016] If the verification fails, an error message is returned to the user.

[0017] In combination with the first aspect, in one implementation, in the step of performing a distributed lock processing on the refund order number field, a distributed lock based on Redis is used.

[0018] In combination with the first aspect, in one implementation, the refund service for the refund order to be processed based on the distributed transaction processing mechanism and the entrusted payment service fund flow specifically includes the following steps:

[0019] Call the core system principal refund interface to refund the principal from the platform account to the customer account and freeze it;

[0020] Call the core system transfer interface to transfer the interest from the platform account to the customer account and freeze it;

[0021] Call the repayment interface of the account center and send the unfreezing serial number to repay the money in the customer account to the bank account to offset the part of the loan note information corresponding to the order.

[0022] In combination with the first aspect, in one implementation, the synchronously sending refund processing information specifically includes the following steps:

[0023] When the return status of calling the core system principal refund interface, transfer interface and account center repayment interface are all successful, the refund record in the refund information record table is updated as successful, and the refund request interface caller is asynchronously notified of the successful refund processing in the form of a message queue;

[0024] When the return status of calling any of the core system principal refund interface, transfer interface, and account center repayment interface is failed, a unified error handling is performed and an error compensation message signal is issued.

[0025] In combination with the first aspect, in one implementation, after receiving the error compensation message thrown during the refund service execution operation, performing error compensation on the refund service being processed based on the error compensation mechanism specifically includes the following steps:

[0026] When an error compensation message thrown during the refund business execution operation is received, the refund error compensation mechanism is executed based on a recursive algorithm and a message queue is used to perform error compensation on the refund business being executed.

[0027] In combination with the first aspect, in one implementation, after receiving the error compensation message signal thrown during the refund execution operation, based on a recursive algorithm, a refund error compensation mechanism is executed in a message queue manner to perform error compensation on the refund business being executed, specifically including the following steps:

[0028] In the step of the order center calling the repayment interface of the account center in the error compensation mechanism, for refund orders whose repayment transaction status is in process or timeout, in the error compensation mechanism, the order center polls the repayment status of the repayment result query interface of the account center to obtain the repayment result, and controls the execution of different error compensation strategies according to the repayment result;

[0029] In the step of the order center calling the principal refund interface of the core system in the error compensation mechanism, for the refund order whose principal refund transaction status is in processing, in the error compensation mechanism, the order center continues to call the principal refund interface of the core system to obtain the refund result, and controls the execution of different error compensation strategies according to the refund result;

[0030] In other steps of the error compensation mechanism, when the specific interface transaction status is in process, the interface is continued to be sent in the error compensation mechanism to obtain feedback results, and different error compensation strategies are controlled to be executed according to the feedback results.

[0031] In a second aspect, the present application provides a distributed system-based entrusted payment refund system, including:

[0032] A refund request receiving module, used to receive a refund request, wherein the refund request includes a refund serial number, an original order number, a refund principal, and a refund interest;

[0033] The refund request verification module is connected to the refund request receiving module for preliminary verification and information verification of the refund request received, persisting the verified refund request to the refund information record table in the database, and marking the verified refund request as pending. The input interface supports idempotent operations and performs distributed lock processing on the refund original order number field.

[0034] The refund processing module is connected to the refund request verification module, uses a scheduled task scan to obtain the refund request marked as pending in the refund record table, and marks it as being processed, executes the refund business for the refund order to be processed based on the distributed transaction processing mechanism and the entrusted payment business capital flow, and simultaneously sends out the business processing result information;

[0035] The error compensation module is connected to the refund processing module for executing error compensation for the refund business being processed based on the error compensation mechanism after receiving the error compensation message thrown during the execution of the refund business.

[0036] In conjunction with the second aspect, in one implementation, the refund request verification module includes:

[0037] A preliminary verification unit is used to control the business front-end system to perform preliminary verification on the refund request;

[0038] A refund information verification unit, which is in communication with the preliminary verification unit and is used to control the refund entry interface of the business middle station order center to verify the refund information of the refund request that has passed the preliminary verification;

[0039] A first verification processing unit is connected to the refund information verification unit for persisting the refund information to a refund information record table in a database and marking the status as pending if the verification is passed;

[0040] The second verification processing unit is connected to the refund information verification unit for returning error information to the user if the verification fails.

[0041] In a third aspect, the present application provides a computer-readable storage medium, on which a distributed system-based entrusted payment refund program is stored, wherein when the distributed system-based entrusted payment refund program is executed by a processor, the steps of the distributed system-based entrusted payment refund method as described above are implemented.

[0042] The beneficial effects brought by the technical solution provided by the embodiment of the present application include at least:

[0043] By introducing distributed locks, distributed transaction processing mechanisms and smart contract technology, the efficiency, security and consistency of refund operations are achieved. This method not only improves the concurrent processing capability and stability of refund operations, but also reduces the risk of human intervention and errors, providing a more reliable and efficient solution for payment refunds in the field of Internet finance.

[0044] By splitting the entrusted payment refund function into three parts at the software design level: refund processing, refund main process timing tasks, and refund error compensation mechanism, the coupling of various functional modules is released, better adapting to the rapid development of supply chain financial business and the development direction of distributed systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 The refund main process system interaction sequence diagram provided for the embodiment of the present application;

[0046] Figure 2 A method flow chart of a distributed system-based entrusted payment refund method provided in an embodiment of the present application;

[0047] Figure 3 A schematic diagram of entrusted payment funds flow provided for an embodiment of the present application;

[0048] Figure 4 A schematic diagram of the entrusted payment refund fund flow provided in the embodiment of the present application;

[0049] Figure 5 An overview of the refund error compensation mechanism provided in an embodiment of the present application. DETAILED DESCRIPTION

[0050] 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 are within the scope of protection of this application.

[0051] The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally includes steps or units that are not listed, or optionally includes other steps or units inherent to these processes, methods, products or devices. The terms "first", "second" and "third" are used to distinguish different objects, etc., and do not represent a sequence, nor do they limit "first", "second" and "third" to different types.

[0052] In the description of the embodiments of the present application, "exemplary", "for example" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary", "for example" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary", "for example" or "for example" is intended to present related concepts in a specific way.

[0053] In the description of the embodiments of the present application, unless otherwise specified, “ / ” means or, for example, A / B can mean A or B; the “and / or” in the text is merely a description of the association relationship of associated objects, indicating that three relationships may exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, “multiple” refers to two or more than two.

[0054] In some processes described in the embodiments of the present application, multiple operations or steps that appear in a specific order are included, but it should be understood that these operations or steps may not be executed in the order in which they appear in the embodiments of the present application or in parallel, and the sequence number of the operation is only used to distinguish the different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed in sequence or in parallel, and these operations or steps may be combined.

[0055] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0056] First, the refund main process system interaction sequence diagram provided by this application is as follows Figure 1 As shown, a distributed system includes a platform system, a business front-end system, a business middle-end system (order center, account center), and a core system;

[0057] Based on the above distributed system, the following entrusted payment refund method is executed, please refer to Figure 2 , including the following steps:

[0058] Step S1: receiving a refund request, wherein the refund request includes a refund serial number, an original order number, a refund principal, a refund interest, etc.;

[0059] Step S2: Perform preliminary verification and information verification on the refund request received, persist the refund request that has passed the verification to the refund information record table in the database, and mark the refund request that has passed the verification as pending. The input interface supports idempotent operations, and performs distributed lock processing on the refund original order number field;

[0060] Step S3: Use a scheduled task to scan and obtain the refund requests marked as pending in the refund record table, and mark them as being processed. Based on the distributed transaction processing mechanism and the entrusted payment business capital flow, the refund business is executed for the pending refund orders, and the refund processing information is issued simultaneously;

[0061] Step S4: after receiving the error compensation message thrown out during the refund service execution operation, error compensation is performed on the refund service being processed based on the error compensation mechanism.

[0062] This application proposes a delegated payment refund method based on a distributed system. By introducing distributed locks, distributed transaction processing mechanisms and smart contract technology, the efficiency, security and consistency of the refund operation are achieved. This method not only improves the concurrent processing capability and stability of the refund operation, but also reduces the risk of human intervention and errors, providing a more reliable and efficient solution for payment refunds in the field of Internet finance.

[0063] In one embodiment, step S1: receiving a refund request, wherein the refund request includes a refund serial number, an order number, a refund principal, and a refund interest, and specifically includes the following steps:

[0064] The user submits a refund request through the platform's front-end interface. The refund request includes the refund serial number, order number, refund principal, refund interest, etc.;

[0065] After receiving the refund request, the business front-end system will conduct preliminary verification, such as verifying the user identity, order status, etc., and then transmit it to the business middle-end order center.

[0066] In one embodiment, the step S2: performing preliminary verification and information verification on the received refund request, persisting the verified refund request to the refund information record table of the database, and marking the verified refund request as pending, specifically includes the following steps:

[0067] Step S21: Control the refund entry interface of the business middle station order center to verify the refund information of the refund request that has passed the preliminary verification, specifically, verify whether the refund amount exceeds the order amount, whether the order is completed, whether it is a refund order being processed or pending, etc.;

[0068] Step S22A: If the verification is successful, the refund information is persisted in the refund information record table in the database; the refund information record table only records the overall refund information and status, and does not record the status of specific steps. The status field is divided into four types: pending, in progress, successful, and failed; pending and in progress are intermediate states, and successful and failed are final states. After the application information is persisted in the refund information record table in the database, the status is marked as pending;

[0069] Step S22B: If the verification fails, an error message is returned to the user.

[0070] In one embodiment, the idempotence of the interface in step S2 means that requesting a resource once or multiple times should have the same result on the resource itself, that is, when the interface is repeatedly called, the impact on the system is the same, which is idempotence. Idempotence is especially important for developers to consider in scenarios involving monetary transactions such as transfers and payments.

[0071] In one embodiment, the distributed lock in step S2 is a lock in a distributed system. In a single application, we use locks to solve the problem of controlling access to shared resources, and distributed locks solve the problem of controlling access to shared resources in a distributed system. Unlike single applications, the minimum granularity of competing for shared resources in a distributed system has been upgraded from threads to processes; there are three common ways to implement distributed locks: based on databases (including table additions and deletions and exclusive locks), based on Zookeeper, and based on Redis; based on performance considerations, this application uses distributed locks based on Redis.

[0072] In one embodiment, the application interface in step S2 refers to the situation where a customer purchases goods from the platform by applying for a loan from a bank, and then decides to apply for a return from the platform due to some reasons of the customer's own. After receiving the return application, the platform negotiates with the customer about the specific refund amount. After the negotiation is completed, the bank refund application interface is called to initiate a refund application for the specified principal and specified interest to the bank. In consideration of fund security, the bank will perform more business logic checks when applying for a refund. For the sake of customer experience, the application interface does not perform business logic on fund flow.

[0073] In one embodiment, the scheduled task in step S3 is a task scheduling method commonly used in computer programs. It allows the program to automatically perform certain operations or tasks at a specified time interval or a specific time point. Scheduled tasks are widely used in various fields, such as system management, data processing, log recording, etc.; in this application, scheduled tasks are used to process the business logic of the refund function fund flow.

[0074] In one embodiment, in step S3, the entrusted payment service fund flow is as follows: Figure 3 As shown, including:

[0075] Bank accounts, bank general ledger accounts, accounts used by banks to issue loans;

[0076] Customer account, the borrower's own bank account, used to receive loans from financial institutions;

[0077] Platform accounts, in-house accounts of core enterprises, entrusted payment accounts in entrusted payment businesses, and counterparty accounts of borrowers, are used to receive entrusted payment funds from borrowers;

[0078] The fund flow of entrusted payment business is: bank account → customer account → platform account.

[0079] In one embodiment, the entrusted payment refund business fund flow, such as Figure 4 As shown, including:

[0080] Platform account, the bank account of the core enterprise, the payer account in the entrusted payment refund business, in order to ensure the consistency principle of fund flow account, this account is Figure 1 Keep the accounts consistent;

[0081] Customer account, the borrower's bank account, the temporary recipient account in the entrusted payment refund business, in order to ensure the consistency of the fund flow account principle, this account is Figure 1 Keep the accounts consistent;

[0082] Bank accounts, bank general ledger accounts, accounts used by banks to issue loans and receive repayments from customers;

[0083] The fund flow of entrusted payment business is: platform account → customer account → bank account.

[0084] In one embodiment, in step S3, the refund service is executed on the refund order to be processed based on the distributed transaction processing mechanism and the entrusted payment service fund flow, specifically including the following steps:

[0085] Call the core system principal refund interface to refund the principal from the platform account to the customer account and freeze it;

[0086] Call the core system transfer interface to transfer the interest from the platform account to the customer account and freeze it;

[0087] Call the repayment interface of the account center and send the unfreezing serial number to repay the money in the customer account to the bank account to offset the part of the loan note information corresponding to the order.

[0088] In one embodiment, the order center calls the principal refund interface and transfer interface of the core system in three states: success, failure, and timeout. The repayment interface of the account center calls the repayment interface in four states: success, failure in process, and timeout. Figure 4 shown.

[0089] In one embodiment, the refund processing information is sent synchronously in step S3, which specifically includes the following steps:

[0090] When the status of the core system principal refund interface, the core system transfer interface and the account center repayment interface all return a successful status, the refund process is considered to be successfully completed, the refund record in the refund information record table is updated as successful, and the refund request interface caller is asynchronously notified of the successful refund process in the form of a message queue;

[0091] When the principal refund interface fails, the refund record in the refund information record table is updated as failed, and the refund request interface caller is asynchronously notified of the refund processing failure in the form of a message queue;

[0092] In other cases, the refund information record table status remains unchanged and is still being processed.

[0093] In step S3 of the present application, a distributed transaction refers to a transaction initiator, resources and resource managers, and a transaction coordinator, which are located on different nodes of a distributed system and communicate with each other through a network. A distributed transaction also complies with the ACID principle, namely atomicity, consistency, isolation, and persistence; a distributed transaction has four scenarios: two-phase commit (2PC), three-phase commit (3PC), compensating transaction (TCC), and local message table (asynchronous ensure); the present application adopts a local message table solution.

[0094] In one embodiment, since the present application adopts distributed transaction processing implemented by local message table, the transaction status of the interface is recorded in sequence in the refund local message table before the three interfaces are called. When the three interfaces are called successfully, the transaction status of the corresponding interface is updated to success; when the transaction status of the three interfaces is abnormal or timed out, the transaction status of the corresponding interface is updated to failure or timed out, and the error is thrown uniformly, and an error compensation information signal is issued. After the exception is captured in the outermost layer of the scheduled task code, it is handed over to the refund error compensation mechanism for unified processing.

[0095] In one embodiment, the step S4: after receiving the error compensation message thrown during the refund service execution operation, performing error compensation on the refund service being processed based on the error compensation mechanism, specifically includes the following steps:

[0096] Step S40: after receiving the error compensation message signal thrown out during the refund execution operation, based on the recursive algorithm, the refund error compensation mechanism is executed in the form of a message queue to perform error compensation on the refund business being executed.

[0097] In one embodiment, in step S40, please refer to Figure 5 , Message Queue, namely MQ, Message Queue, in a broad sense, is a message queue service middleware, which provides a complete software system for information production, transmission and consumption. There are many scenarios, but there are three core ones: decoupling, asynchrony, and peak shaving. In the error compensation mechanism, MQ is mainly used in decoupling scenarios. The mainstream message middlewares include Kafka, ActiveMQ, RabbitMQ, and RocketMQ. RocketMQ message queue is used in this application; specifically, in the error compensation mechanism, the interface calls involved are: the principal refund interface of the core system, the principal refund reversal interface of the core system, the (interest) transfer interface, the transfer reversal interface, and the repayment interface of the account center. These interfaces will have success, failure, timeout or intermediate processing status, such as Figure 4 To facilitate the implementation of system functions, these called interfaces all support idempotent operations. Figure 5 The interface interaction grid lines shown in the detailed flow chart of the refund error compensation mechanism provided by this application, in the error compensation mechanism, the calling sequence of these interfaces is quite complicated. This application combines the characteristics of the message queue and creatively uses a recursive algorithm to optimize the inter-program calling logic, greatly simplifying the system development workload.

[0098] In one embodiment, according to the recursive algorithm in step S40, in mathematics and computer science, a method or function has a method that directly or indirectly calls itself in its definition or description. It generally converts a large and complex problem layer by layer into a smaller-scale problem similar to the original problem to solve. The recursive strategy only needs a small number of programs to describe the repeated calculations required for the problem-solving process, which greatly reduces the amount of program code and makes the program more concise.

[0099] In one embodiment, although the flowchart of the error compensation mechanism in step S40 is very complex, after sorting out the business process under the guidance of the recursive idea, we can focus on three major business logics:

[0100] The order center calls the repayment interface of the account center. This step is the last step of the refund main process and error compensation mechanism. Therefore, for refund orders whose repayment transaction status is in process or timeout, the error compensation mechanism polls and queries the repayment status. If successful, the repayment status in the local transaction table is updated as successful, and the refund information record table records the refund order status as successful; if failed, the subsequent (interest) transfer reversal and principal refund reversal operations are performed, and the transaction information of the interface is recorded in the local transaction table; if in process, an exception is thrown, and MQ will re-consume the message after the verification message fails to be captured, and the process is repeated.

[0101] The order center calls the principal refund interface of the core system. This step is the first step of the refund main process and error compensation mechanism. For refund orders whose principal refund transaction status is in progress, since the interface supports idempotence, we continue to send the interface in the error compensation mechanism. If it fails, the principal refund transaction status in the local transaction table is updated as failed, and the refund information record table shows that the refund order status is failed. If it succeeds, the principal refund transaction status in the local transaction table is updated as successful, and the principal refund reversal interface is called to perform the reversal operation.

[0102] Other steps in the error compensation mechanism: When the specific interface transaction status is in progress, the interface supports idempotence, so the interface is sent in the error compensation mechanism. If it fails, the principal refund transaction status in the local transaction table is updated to failure, and the previous transaction is reversed. If it succeeds, the principal refund transaction status in the local transaction table is updated to success, and the previous transaction is reversed after the current transaction is reversed. In particular, for the reversal transaction, we only allow success, otherwise we keep retrying and issuing an alarm.

[0103] In one embodiment, another scenario of message queue application - asynchronous, a refund result notification is sent to the platform in the form of a message queue; specifically, if the refund is successful, the platform is notified that the refund amount has been received; if the refund fails, the platform is notified of the reason for the failure and subsequent processing suggestions are given.

[0104] In a second aspect, the present application provides a distributed system-based entrusted payment refund system, including:

[0105] A refund request receiving module, used to receive a refund request, wherein the refund request includes a refund serial number, an original order number, a refund principal, and a refund interest;

[0106] A refund request verification module is connected to the refund request receiving module for preliminary verification and information verification of the refund request received, and the refund request that has passed the verification is persisted to the refund information record table of the database, and the refund request that has passed the verification is marked as pending, and an input interface that supports idempotent operations is set, and the refund order number field is locked with a distributed lock, and the refund request that is persisted to the refund information record table is obtained based on the input interface;

[0107] The refund processing module is connected to the refund request verification module, uses a scheduled task scan to obtain the refund request marked as pending in the refund record table, and marks it as being processed, executes the refund business for the refund order to be processed based on the distributed transaction processing mechanism and the entrusted payment business capital flow, and simultaneously sends out the business processing result information;

[0108] The error compensation module is connected to the refund processing module for executing error compensation for the refund business being processed based on the error compensation mechanism after receiving the error compensation message thrown during the execution of the refund business.

[0109] In one embodiment, the refund request verification module includes:

[0110] A preliminary verification unit is used to control the business front-end system to perform preliminary verification on the refund request;

[0111] A refund information verification unit, which is in communication with the preliminary verification unit and is used to control the refund entry interface of the business middle station order center to verify the refund information of the refund request that has passed the preliminary verification;

[0112] A first verification processing unit is connected to the refund information verification unit for persisting the refund information to a refund information record table in a database and marking the status as pending if the verification is passed;

[0113] The second verification processing unit is connected to the refund information verification unit for returning error information to the user if the verification fails.

[0114] Among them, the functional implementation of each module in the above-mentioned entrusted payment refund system based on a distributed system corresponds to the steps in the above-mentioned entrusted payment refund method embodiment based on a distributed system, and its functions and implementation processes will not be repeated here one by one.

[0115] On the third aspect, an embodiment of the present application provides a trustee payment refund device based on a distributed system. The trustee payment refund device based on a distributed system can be a personal computer (PC), a laptop computer, a server, or other device with data processing capabilities.

[0116] The communication interface includes input / output (I / O) interface, physical interface and logical interface, etc., which are used to realize the interconnection of devices inside the entrusted payment refund device based on the distributed system, and the interface used to realize the interconnection between the entrusted payment refund device based on the distributed system and other devices (such as other computing devices or user devices). The physical interface can be an Ethernet interface, a fiber optic interface, an ATM interface, etc.; the user device can be a display, a keyboard, etc.

[0117] The memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0118] The processor may be a general-purpose processor, which may call the distributed system-based entrusted payment refund program stored in the memory and execute the distributed system-based entrusted payment refund method provided in the embodiment of the present application. For example, the general-purpose processor may be a central processing unit (CPU). The method executed when the distributed system-based entrusted payment refund program is called may refer to the various embodiments of the distributed system-based entrusted payment refund method of the present application, which will not be described in detail here.

[0119] In a fourth aspect, an embodiment of the present application also provides a readable storage medium.

[0120] The readable storage medium of the present application stores a distributed system-based entrusted payment refund program, wherein when the distributed system-based entrusted payment refund program is executed by a processor, the steps of the distributed system-based entrusted payment refund method as described above are implemented.

[0121] Among them, the method implemented when the entrusted payment refund program based on the distributed system is executed can refer to the various embodiments of the entrusted payment refund method based on the distributed system of this application, and will not be repeated here.

[0122] It should be noted that the serial numbers of the above-mentioned embodiments of the present application are only for description and do not represent the advantages or disadvantages of the embodiments.

[0123] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, disk, CD) as described above, and includes a number of instructions for a terminal device to execute the methods described in each embodiment of the present application.

[0124] The above are only preferred embodiments of the present application, and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A method for entrusted payment refund based on a distributed system, characterized in that: The following steps are involved: Receive a refund request, the refund request including the refund serial number, the original order number, the refund principal, and the refund interest; Perform preliminary verification and information verification on the refund request received, persist the verified refund request to the refund information record table in the database, and mark the verified refund request as pending. The input interface supports idempotent operations and performs distributed lock processing on the refund original order number field; Use scheduled task scanning to obtain refund requests marked as pending in the refund record table, and mark them as being processed. Based on the distributed transaction processing mechanism and entrusted payment business fund flow, the refund business is executed for the refund orders to be processed, and the refund processing information is issued simultaneously; When an error compensation message thrown during the refund service execution operation is received, error compensation is performed on the refund service being processed based on the error compensation mechanism.

2. The method for entrusted payment and refund based on a distributed system as claimed in claim 1, characterized in that: The method of performing preliminary verification and information verification on the received refund request, persisting the verified refund request to the refund information record table of the database, and marking the verified refund request as pending, specifically includes the following steps: Control the business front-end system to conduct preliminary verification of refund requests; Control the refund entry interface of the business middle office order center to verify the refund information of the refund request that has passed the preliminary verification; If the verification is successful, the refund information will be persisted to the refund information record table in the database and the status will be marked as pending; If the verification fails, an error message is returned to the user.

3. The distributed system-based entrusted payment refund method according to claim 1, characterized in that: In the step of performing a distributed lock on the refund original order number field, a distributed lock based on Redis is used.

4. The distributed system-based entrusted payment refund method according to claim 1, characterized in that: The refund service for the refund order to be processed based on the distributed transaction processing mechanism and the entrusted payment service fund flow specifically includes the following steps: Call the core system principal refund interface to refund the principal from the platform account to the customer account and freeze it; Call the core system transfer interface to transfer the interest from the platform account to the customer account and freeze it; Call the repayment interface of the account center and send the unfreezing serial number to repay the money in the customer account to the bank account to offset the part of the loan note information corresponding to the order.

5. The distributed system-based entrusted payment refund method according to claim 1, characterized in that: The synchronously sending of refund processing information specifically includes the following steps: When the return status of calling the core system principal refund interface, transfer interface and account center repayment interface are all successful, the refund record in the refund information record table is updated as successful, and the refund request interface caller is asynchronously notified of the successful refund processing in the form of a message queue; When the return status of calling any of the core system principal refund interface, transfer interface, and account center repayment interface is failed, a unified error handling is performed and an error compensation message signal is issued.

6. The distributed system-based entrusted payment refund method according to claim 5, characterized in that: After receiving the error compensation message thrown during the refund service execution operation, error compensation is performed on the refund service being processed based on the error compensation mechanism, specifically including the following steps: When an error compensation message thrown during the refund business execution operation is received, the refund error compensation mechanism is executed based on a recursive algorithm and a message queue is used to perform error compensation on the refund business being executed.

7. The distributed system-based entrusted payment refund method according to claim 6, characterized in that: After receiving the error compensation message signal thrown during the refund execution operation, the refund error compensation mechanism is executed in a message queue based on a recursive algorithm to perform error compensation on the refund business being executed, which specifically includes the following steps: In the step of the order center calling the repayment interface of the account center in the error compensation mechanism, for refund orders whose repayment transaction status is in process or timeout, in the error compensation mechanism, the order center polls the repayment status of the repayment result query interface of the account center to obtain the repayment result, and controls the execution of different error compensation strategies according to the repayment result; In the step of the order center calling the principal refund interface of the core system in the error compensation mechanism, for the refund order whose principal refund transaction status is in processing, in the error compensation mechanism, the order center continues to call the principal refund interface of the core system to obtain the refund result, and controls the execution of different error compensation strategies according to the refund result; In other steps of the error compensation mechanism, when the specific interface transaction status is in process, the interface is continued to be sent in the error compensation mechanism to obtain feedback results, and different error compensation strategies are controlled to be executed according to the feedback results.

8. A distributed system-based entrusted payment refund system, characterized in that: include: A refund request receiving module, used to receive a refund request, wherein the refund request fields include a refund serial number, an original order number, a refund principal, and a refund interest; A refund request verification module is connected to the refund request receiving module for preliminary verification and information verification of the refund request received, persisting the verified refund request to the refund information record table of the database, and marking the verified refund request as pending. The input interface supports idempotent operations and performs distributed lock processing on the refund original order number field; The refund processing module is connected to the refund request verification module, uses a scheduled task scan to obtain the refund request marked as pending in the refund record table, and marks it as being processed, executes the refund business for the refund order to be processed based on the distributed transaction processing mechanism and the entrusted payment business capital flow, and simultaneously sends out the business processing result information; The error compensation module is in communication with the refund processing module and is used to perform error compensation on the refund business being processed based on the error compensation mechanism after receiving an error compensation message thrown during the execution of the refund business.

9. The distributed system-based entrusted payment refund system as claimed in claim 8, characterized in that: The refund request verification module includes: A preliminary verification unit is used to control the business front-end system to perform preliminary verification on the refund request; A refund information verification unit, which is in communication with the preliminary verification unit and is used to control the refund entry interface of the business middle station order center to verify the refund information of the refund request that has passed the preliminary verification; A first verification processing unit is connected to the refund information verification unit for persisting the refund information to a refund information record table in a database and marking the status as pending if the verification is passed; The second verification processing unit is connected to the refund information verification unit for returning error information to the user if the verification fails.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a distributed system-based entrusted payment refund program, wherein when the distributed system-based entrusted payment refund program is executed by a processor, the steps of the distributed system-based entrusted payment refund method as described in any one of claims 1 to 7 are implemented.

Images