Repeated payment management system, method and device based on idempotent principle

Abstract

The invention relates to the field of financial science and technology, in particular to a repeated payment management system, method and device based on the idempotent principle, and the system comprises a front-end module which is used for receiving a payment request and judging whether the payment request is submitted repeatedly or not; the settlement module is used for generating a payment number according to the payment request and monitoring the processing state of the payment request; when the payment request is in the first processing state, a payment bill corresponding to the payment request is locked according to the payment bill number, and the payment bill is sent to a bank-enterprise module; the bank and enterprise module is used for generating a payment instruction serial number according to the payment order after receiving the payment order; whether the payment instruction serial number exists or not is judged, and if yes, repeated processing is not carried out; and if not, sending the instruction to multiple rows. According to the scheme, from the beginning of triggering the transaction by the front-end client to the end of calling multiple lines for payment, control is carried out at multiple positions in the whole process of completing the whole transaction, and repeated payment is avoided.

Description

Technical Field

[0001] This specification relates to the field of financial technology, and in particular to a repeated payment management system, method and device based on the idempotence principle. Background Art

[0002] When the business is busy, payment requests are concurrent, and customers may submit new payables or payment orders repeatedly. In the prior art, fields are generated based on the uniqueness of business data, such as the payment order number, to generate a unique hash value. Based on the unique value, a duplicate submission judgment is created, and a distributed lock annotation is created. By configuring the lock key, a check is made in Redis to see if the same identifier exists. If so, repeated submission is not allowed. If not, a new identifier is generated and the expiration time is set, and then the order is created.

[0003] This method has simple control logic, and it is possible that the same order will be submitted multiple times, resulting in repeated submission and repeated payment. Summary of the invention

[0004] To solve the technical problems in the prior art, the embodiments of this specification provide a repeated payment management system, method and device based on the idempotence principle.

[0005] The embodiment of the present specification provides a repeated payment management system based on the idempotence principle, the system comprising: a front-end module, for receiving a payment request and determining whether the payment request is submitted repeatedly; a settlement module, for generating a payment order number according to the payment request, and monitoring the processing status of the payment request; when the payment request is in a first processing state, locking the payment order corresponding to the payment request according to the payment order number, and caching the payment order locking request to a queue, and sending the payment order to a bank-enterprise module after the queue releases the payment order locking request; determining whether there is a resource release, and if so, obtaining the first lock request in the queue, and determining whether the resource is released. Determine whether the first lock request conflicts with the scope of the existing lock request; if so, provide corresponding resources for the first lock request; if not, determine whether the conflict scope between the first lock request and the existing lock request belongs to the extended scope, and if so, lock the extended scope according to the first lock request, and remove the first lock request from the queue; the bank-enterprise module is used to generate a payment instruction serial number according to the payment slip after receiving the payment slip; determine whether the payment instruction serial number already exists, and if so, do not repeat the processing; wherein the payment instruction serial number is generated by the bank-enterprise module according to the document number; if not, send the instruction to multiple lines.

[0006] According to one aspect of the embodiments of this specification, the settlement module is further used to: generate a unique payment order number for the payment request based on a timestamp and a random number; and obtain and record the processing status corresponding to the payment request from the bank-enterprise module based on the unique payment order number.

[0007] The embodiment of the present specification provides a repeated payment management method based on the idempotence principle, the method comprising: receiving a payment request and determining whether the payment request is submitted repeatedly; generating a payment order number according to the payment request, and monitoring the processing status of the payment request; when the payment request is in a first processing state, locking the payment order corresponding to the payment request according to the payment order number, and caching the payment order locking request to a queue, and sending the payment order to a bank-enterprise module after the queue releases the payment order locking request; determining whether there is a resource release, and if so, obtaining a first lock request in the queue, and determining whether the first lock request whether the first lock request conflicts with the scope of the existing lock request; if so, provide corresponding resources for the first lock request; if not, determine whether the conflicting scope of the first lock request and the existing lock request belongs to the extended scope, and if so, lock the extended scope according to the first lock request, and remove the first lock request from the queue; the bank-enterprise module is used to generate a payment instruction serial number according to the payment slip after receiving the payment slip; determine whether the payment instruction serial number already exists, and if so, do not repeat the processing; wherein the payment instruction serial number is generated by the bank-enterprise module according to the document number; if not, send the instruction to multiple lines.

[0008] According to one aspect of an embodiment of this specification, the method includes: according to an optimistic locking mechanism, locking the extended range according to a first lock request, and removing the first lock request from the queue.

[0009] According to one aspect of the embodiments of the present specification, after sending the instruction to multiple lines, the method further includes: sending the instruction to each payment node, and each payment node determining the order status; regularly querying the order status to determine whether the order status has changed; if so, calling the order status back to the settlement module and updating the processing status of the payment order in the settlement module.

[0010] According to one aspect of an embodiment of the present specification, generating a payment order number based on the payment request and monitoring the processing status of the payment request includes: generating a unique payment order number for the payment request based on a timestamp and a random number; and obtaining and recording the processing status corresponding to the payment request from the bank-enterprise module based on the unique payment order number.

[0011] According to one aspect of an embodiment of the present specification, determining whether the payment request is submitted repeatedly includes: generating and storing a unique token in a user session based on the payment request; after a preset time, receiving a new payment request, and verifying whether the token corresponding to the new payment request is consistent with the token stored in the user session; if they are consistent, the payment request is a repeated request, and the payment request is rejected.

[0012] According to one aspect of the embodiment of this specification, after the instruction is sent to multiple rows, the method further includes: releasing the locked instruction.

[0013] The embodiment of the present specification also provides a repeated payment management device based on the idempotence principle, the device comprising: a repeated submission judgment unit, used to receive a payment request and judge whether the payment request is repeatedly submitted; a monitoring unit, used to generate a payment order number according to the payment request, and monitor the processing status of the payment request; a sending unit, used to lock the payment order corresponding to the payment request according to the payment order number when the payment request is in a first processing state, and send the data of the payment order to the bank-enterprise module, wherein the request for locking the payment order is cached in a queue; a conflict judgment unit, used to judge whether there is a resource release, and if so, obtain the first lock request in the queue, and judge the conflict. whether the first lock request conflicts with the scope of the existing lock request; a resource determination unit, used to provide corresponding resources for the first lock request if so; a resource release acquisition unit, used to determine whether the conflicting scope between the first lock request and the existing lock request belongs to an extended scope if not, and if so, lock the extended scope according to the first lock request, and remove the first lock request from the queue; a serial number determination unit, used to generate a payment instruction serial number according to the payment slip; determine whether the payment instruction serial number already exists, and if so, do not repeat the processing; wherein the payment instruction serial number is generated by the bank-enterprise module according to the document number; an instruction sending unit, used to send the instruction to multiple lines if it does not exist.

[0014] The embodiments of the present specification also provide a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the repeated payment management method based on the idempotence principle when executing the computer program.

[0015] The embodiments of this specification also provide a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the repeated payment management method based on the idempotence principle is implemented.

[0016] This solution starts from the front-end customer triggering the transaction to the final call of multiple lines for payment. It controls multiple points in the entire process of completing the entire transaction to ensure that only one payment can be completed for one document. Compared with the existing traditional control method to avoid duplicate payments, it avoids duplicate payments. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the embodiments of this article or the prior art, the drawings required for use in the embodiments or the prior art descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of this article. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0018] Figure 1 Shown is a schematic diagram of a repeated payment management system based on the idempotence principle according to an embodiment of this specification;

[0019] Figure 2 The figure shows a flow chart of a repeated payment management method based on the idempotence principle in an embodiment of this specification;

[0020] Figure 3 The flowchart of a callback method according to an embodiment of the present specification is shown;

[0021] Figure 4 The figure is a flow chart of a method for monitoring the processing status corresponding to a payment request according to an embodiment of the present specification;

[0022] Figure 5 The figure is a flow chart of a method for verifying a repeated payment request according to an embodiment of the present specification;

[0023] Figure 6 The figure is a schematic diagram of the specific structure of the repeated payment management device based on the idempotent principle in the embodiment of this article;

[0024] Figure 7 Shown is a schematic diagram of the structure of a computer device according to an embodiment of this invention.

[0025] Description of the accompanying symbols:

[0026] 100. Front-end module;

[0027] 200. Settlement module;

[0028] 300, Bank-Enterprise Module;

[0029] 601, repeated submission judgment unit;

[0030] 602, monitoring unit;

[0031] 603, sending unit;

[0032] 604, conflict determination unit;

[0033] 605. Resource determination unit;

[0034] 606. Release the resource acquisition unit;

[0035] 607, serial number determination unit;

[0036] 608, instruction sending unit;

[0037] 702. Computer equipment;

[0038] 704, processor;

[0039] 706. Memory;

[0040] 708, driving mechanism;

[0041] 710, input / output module;

[0042] 712. Input devices;

[0043] 714. Output devices;

[0044] 716. Presentation equipment;

[0045] 718. Graphical user interface;

[0046] 720, network interface;

[0047] 722. Communication link;

[0048] 724. Communication bus. DETAILED DESCRIPTION

[0049] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments of this specification, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this specification.

[0050] It should be noted that the terms "first", "second", etc. in the specification and claims of this article and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of this article described here can be implemented in an order other than those illustrated or described here. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, device, product or equipment that includes 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 equipment.

[0051] This specification provides method operation steps as described in the embodiments or flow charts, but more or fewer operation steps may be included based on routine or non-creative work. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the system or device product is executed in practice, it can be executed in the order of the method shown in the embodiments or the drawings or in parallel.

[0052] It should be noted that the duplicate payment management system, method and device based on the idempotence principle in this specification can be used in the field of financial technology, and this specification does not limit the application field of the duplicate payment management system, method and device based on the idempotence principle. The acquisition, transmission, storage, use and processing of data in the technical solution of this application are in compliance with the relevant provisions of national laws and regulations.

[0053] Figure 1 The diagram is a schematic diagram of a repeated payment management system based on the idempotent principle according to an embodiment of the present specification. The repeated payment management system based on the idempotent principle comprises: a front-end module 100, a settlement module 200 and a bank-enterprise module 300.

[0054] The front-end module 100 is used to receive a payment request and determine whether the payment request is submitted repeatedly.

[0055] The settlement module 200 is used to generate a payment order number according to the payment request and monitor the processing status of the payment request; when the payment request is in the first processing status, the payment order corresponding to the payment request is locked according to the payment order number, and the payment order locking request is cached in a queue, and after the queue releases the payment order locking request, the payment order is sent to the bank-enterprise module; it is determined whether there is a resource release, and if so, a first lock request in the queue is obtained, and it is determined whether the first lock request conflicts with the scope of an existing lock request;

[0056] If yes, provide corresponding resources for the first lock request;

[0057] If not, determine whether the conflicting range between the first lock request and the existing lock request belongs to the extended range, and if so, lock the extended range according to the first lock request, and remove the first lock request from the queue. The settlement module is further used to: generate a unique payment order number for the payment request according to the timestamp and the random number; and obtain and record the processing status corresponding to the payment request from the bank-enterprise module according to the unique payment order number.

[0058] The bank-enterprise module 300 is used to generate a payment instruction serial number based on the payment slip after receiving the payment slip; determine whether the payment instruction serial number already exists, and if so, do not repeat the processing; wherein the payment instruction serial number is generated by the bank-enterprise module based on the document number; if it does not exist, send the instruction to multiple lines.

[0059] Figure 2 The flowchart of a repeated payment management method based on the idempotence principle in an embodiment of this specification is shown, which specifically includes the following steps:

[0060] Step 201, receiving a payment request and determining whether the payment request is submitted repeatedly. When a customer adds a new payable or payment order, once he clicks submit, the order will be moved to the approval process. The submit button is grayed out, and the customer cannot submit again.

[0061] The Controller layer receives the payment request sent by the user from the front end and verifies the uniqueness of the payment request sent by the user. Specifically, the controller has set the ID field in the payment application form as a unique constraint. By applying the annotations @RestController and @RequestMapping in the Controller layer and combining them to use the token mechanism, when the user adds a new payment order, the server generates a unique token and stores it in the user session redis. When the user submits the payment order, the token is passed to the server as a parameter, and the server checks whether the passed token is consistent with the token stored in the session. If they are consistent, the request is processed; if they are inconsistent or the token does not exist in the session, the payment request issued by the current user is considered to be a duplicate submission, and the request is rejected.

[0062] Step 202: Generate a payment order number according to the payment request, and monitor the processing status of the payment request.

[0063] In this step, after the front-end module judges the duplicate submission of the user's payment request in step 201, the settlement module further deduplicates the payment request according to the processing status of the payment request. Specifically, for each payment request, this step generates a unique payment order number corresponding to the payment request based on the timestamp and random number of the payment request, and stores it in the acceptance table corresponding to the settlement module. Furthermore, the settlement module obtains and records the current processing status of the payment request from the bank-enterprise module. Among them, the processing status of a payment request includes but is not limited to: adding a new document, initiating an application, passing the approval flow, generating a payment instruction, payment processing, sending a payment, payment callback, and modifying the order status.

[0064] Step 203, when the payment request is in the first processing state, the payment order corresponding to the payment request is locked according to the payment order number, and the payment order locking request is cached in the queue. After the queue releases the payment order locking request, the payment order is sent to the bank-enterprise module.

[0065] The first status in this step can be any one of "payment processing" and "acceptance form waiting for payment". In this step, the bank-enterprise module queries the documents with the status of "payment processing", locks the documents according to the document number of the document with the status of "payment processing", and sends the locked documents to the bank-enterprise module. Specifically, the document is locked according to the business identifier, document number and batch number.

[0066] Step 204, determine whether there is any resource release.

[0067] Step 205: If yes, obtain the first lock request in the queue, and determine whether the first lock request conflicts with the range of existing lock requests.

[0068] In the embodiment of this specification, the settlement module sends the payment order to the bank-enterprise module as a single-threaded task, that is, the next payment order can only be locked after the previous payment order is unlocked, thereby avoiding the problem that multiple tenants submit payment requests at the same time but cannot send them to the bank-enterprise module in time. Therefore, this step first needs to determine whether there are released resources in the current queue. If there are released resources, it is determined whether the first lock request ranked first in the queue conflicts with the scope of the request for the existing lock. In the embodiment of this specification, the existing lock request is a request in the current request, and the scope of the existing lock request is the scope that the existing lock can currently access or request.

[0069] In the embodiment of this specification, the settlement module opens a thread pool for each tenant to manage multiple threads and a task queue.

[0070] Step 206: If yes, provide corresponding resources for the first lock request.

[0071] If the first lock request does not conflict with the range of the existing lock request, the corresponding resources are directly provided for the first lock request.

[0072] Step 207: If not, determine whether the conflict range between the first lock request and the existing lock request belongs to the extended range. If so, lock the extended range according to the first lock request and remove the first lock request from the queue. In this step, if it is determined that the first lock request has a conflict range with the existing lock request, it is further determined whether the conflict range is in the extended range.

[0073] In the embodiment of this specification, the system is in a high concurrency environment, and multiple payment orders may be locked at the same time, requesting to access and attempt to modify the same data resource at the same time. Therefore, when the first lock request in the queue conflicts with the existing lock request, it is necessary to further determine whether the conflict range belongs to the allowed range allowed by the range lock. The allowed range is expressed as: when receiving an access request, according to the already allocated lock range, the request is given the largest range lock, and the maximum range continuous with the request range is expanded. If the conflict range belongs to the extended range, it means that the conflict range between the first lock request and the existing lock request has already involved the extended range, and the conflict is large. Therefore, when the existing lock request releases the extended range resource, according to the first lock request, the extended range is locked. And the first lock request is removed from the queue. In the embodiment of this specification, in the initial data processing stage, the optimistic lock mechanism is used not to lock the resource immediately. Before the update needs to be submitted or under certain conditions (such as when a possible conflict risk is detected), the extended range of the resource is locked to ensure that these resources can be exclusively occupied when updating data to avoid conflicts.

[0074] Step 208, after receiving the payment slip, generate a payment instruction serial number according to the payment slip; determine whether the payment instruction serial number already exists, if so, do not repeat the process.

[0075] Among them, the payment instruction serial number is generated by the bank-enterprise module according to the document number.

[0076] In this step, the bank-enterprise module generates a payment instruction serial number corresponding to the payment request based on the document number sent by the settlement module. Further, the instruction query table corresponding to the bank-enterprise module is used to query whether the document number already exists. If it does, it means that the payment request has been processed, and the processed payment request will be recorded in the instruction query table.

[0077] Step 209: If it does not exist, send the instruction to multiple lines.

[0078] If it does not exist, it means that the payment request has not been processed, and the instruction is sent to multiple payment receiving nodes. In the embodiment of this specification, multiple payment receiving nodes represent external banks outside the system.

[0079] In the embodiment of this specification, according to the optimistic locking mechanism, the extended range is locked according to the first lock request, and the first lock request is removed from the queue.

[0080] Figure 3 The flowchart of a callback method in an embodiment of the present specification is shown, which specifically includes the following steps:

[0081] Step 301, the instruction is sent to each payment node, and each payment node determines the order payment status. In this step, the instruction is sent to multiple payment nodes according to the data content in the instruction. Among them, the payment node refers to an external bank, and multiple payment nodes determine the status of the order corresponding to the instruction according to the payment instruction. Specifically, it is determined whether the order is currently in the order payment status, and whether the order payment status is payment success or payment failure.

[0082] Step 302, periodically query the order payment status to determine whether the order payment status has changed. In this step, the bank-enterprise module periodically queries the order status corresponding to each instruction from the table according to a preset period (for example, once every 2 minutes). Combined with the order status previously recorded by the bank-enterprise module, determine whether the order status at the current moment has changed.

[0083] Step 303: If yes, call back the order status to the settlement module, and update the payment order processing status in the settlement module. If the order status changes, synchronize the queried order status to the settlement module through the callback mechanism, and update the payment order processing status in the settlement module.

[0084] Figure 4 The flowchart of a method for monitoring the processing status of a payment request according to an embodiment of the present specification is shown. The method specifically includes the following steps:

[0085] Step 401, generating a unique payment order number for the payment request according to the timestamp and the random number.

[0086] Step 402: monitor the processing status of the payment request from the bank-enterprise module according to the unique payment order number.

[0087] In the embodiment of this specification, a unique payment order number corresponding to the payment request is generated according to the timestamp and the random number, and the unique payment order number is recorded in the acceptance table of the settlement module. The bank-enterprise module records the processing status of all payment requests at each stage in the entire process. Therefore, the processing status of each payment request at each stage can be queried from the bank-enterprise module according to the unique payment order number, thereby realizing real-time monitoring of the payment request.

[0088] Figure 5The flowchart of a method for verifying a repeated payment request according to an embodiment of the present specification is shown. The method specifically includes the following steps:

[0089] Step 501: Generate and store a unique token in the user session according to the payment request.

[0090] When a user adds a payment request, the server generates a unique token using the token mechanism and stores it in the user's session by applying the @RestController and @RequestMapping annotations in the Controller layer. Specifically, the information corresponding to the unique token is stored in Redis.

[0091] Step 502, after a preset time, a new payment request is received, and the token corresponding to the new payment request is verified to be consistent with the token stored in the user session. In the embodiment of this specification, the preset time can be 1 minute, 2 minutes, 5 minutes or other time lengths. This step periodically obtains and receives a new payment request, and determines the token data corresponding to the new payment request. Further verify whether the token corresponding to the new payment request after the preset time is consistent with the unique token stored in the user session.

[0092] Step 503: If they are consistent, the payment request is determined to be a duplicate request and the payment request is rejected. If the two tokens are consistent, it means that the two payment requests are the same and are duplicate requests, so the new payment request is no longer processed and is rejected.

[0093] like Figure 6 The figure shows a schematic diagram of the structure of a repeated payment management device based on the idempotence principle in an embodiment of the present specification. In this figure, the basic structure of the repeated payment management device based on the idempotence principle is described. The functional units and modules therein can be implemented in software, or a general chip or a specific chip can be used to implement repeated payment management based on the idempotence principle. The device specifically includes:

[0094] A repeated submission determination unit 601, configured to receive a payment request and determine whether the payment request is submitted repeatedly;

[0095] A monitoring unit 602, configured to generate a payment order number according to the payment request and monitor the processing status of the payment request;

[0096] The sending unit 603 is used for locking the payment order corresponding to the payment request according to the payment order number when the payment request is in the first processing state, and sending the data of the payment order to the bank-enterprise module, wherein the request for locking the payment order is cached in a queue;

[0097] A conflict determination unit 604 is used for determining whether there is a resource release, and if so, obtaining a first lock request in the queue, and determining whether the first lock request conflicts with a range of existing lock requests;

[0098] A resource determining unit 605, configured to provide corresponding resources for the first lock request;

[0099] A release resource acquisition unit 606 is used to determine whether the conflict range between the first lock request and the existing lock request belongs to an extended range, and if so, lock the extended range according to the first lock request and remove the first lock request from the queue;

[0100] The serial number determination unit 607 is used to generate a payment instruction serial number according to the payment slip; determine whether the payment instruction serial number already exists, and if so, do not repeat the process; wherein the payment instruction serial number is generated by the bank-enterprise module according to the document number;

[0101] The instruction sending unit 608 is used to send the instruction to multiple rows if it does not exist.

[0102] This solution starts from the front-end customer triggering the transaction to the final call of multiple lines for payment. It controls multiple points in the entire process of completing the entire transaction to ensure that a document can only be paid once in the end. Compared with the existing traditional control method to avoid duplicate payments, the control logic of this solution runs through the entire life cycle of a document, which more strictly avoids duplicate payments.

[0103] like Figure 7The diagram shows a schematic diagram of a computer device provided by an embodiment of this specification. The repeated payment management method based on the idempotent principle described in this application can be applied to the computer device. The computer device 702 may include one or more processors 704, such as one or more central processing units (CPUs), each of which may implement one or more hardware threads. The computer device 702 may also include any memory 706, which is used to store any kind of information such as code, settings, data, etc. Non-limitingly, for example, the memory 706 may include any one or more combinations of the following: any type of RAM, any type of ROM, flash memory device, hard disk, optical disk, etc. More generally, any memory may use any technology to store information. Further, any memory may provide volatile or non-volatile retention of information. Further, any memory may represent a fixed or removable component of the computer device 702. In one case, when the processor 704 executes an associated instruction stored in any memory or a combination of memories, the computer device 702 may perform any operation of the associated instruction. The computer device 702 also includes one or more drive mechanisms 708 for interacting with any memory, such as a hard disk drive mechanism, an optical disk drive mechanism, etc.

[0104] The computer device 702 may also include an input / output module 710 (I / O) for receiving various inputs (via input devices 712) and for providing various outputs (via output devices 714). A specific output mechanism may include a presentation device 716 and an associated graphical user interface (GUI) 718. In other embodiments, the input / output module 710 (I / O), the input device 712, and the output device 714 may not be included, and the computer device 702 may be used as a computer device in a network. The computer device 702 may also include one or more network interfaces 720 for exchanging data with other devices via one or more communication links 722. One or more communication buses 724 couple the components described above together.

[0105] The communication link 722 may be implemented in any manner, for example, through a local area network, a wide area network (e.g., the Internet), a point-to-point connection, etc., or any combination thereof. The communication link 722 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc. governed by any protocol or combination of protocols.

[0106] Corresponds to Figures 2 to 5 The method in this article also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the above method are executed.

[0107] The embodiment of the present invention also provides a computer readable instruction, wherein when the processor executes the instruction, the program therein causes the processor to execute the following Figures 2 to 5 The method shown.

[0108] The embodiment of the present invention also provides a computer program product, which includes a computer program. When the computer program is executed by a processor, Figures 2 to 5 The method shown.

[0109] It should be understood that in the various embodiments of this document, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this document.

[0110] It should also be understood that in the embodiments of this document, the term "and / or" is only a description of the association relationship of the associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this document generally indicates that the associated objects before and after are in an "or" relationship.

[0111] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this article.

[0112] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0113] In the several embodiments provided herein, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of the units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, or can be electrical, mechanical or other forms of connection.

[0114] 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 embodiments of this article.

[0115] In addition, each functional unit in each embodiment of this invention 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 integrated unit may be implemented in the form of hardware or in the form of software functional unit.

[0116] 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 this article is essentially 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 this article. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0117] Specific embodiments are used in this article to illustrate the principles and implementation methods of this article. The description of the above embodiments is only used to help understand the methods and core ideas of this article. At the same time, for general technicians in this field, according to the ideas of this article, there will be changes in the specific implementation methods and application scopes. In summary, the content of this specification should not be understood as a limitation on this article.

Claims

1. A repeated payment management system based on the idempotence principle, characterized in that: The system comprises: A front-end module, used for receiving a payment request and determining whether the payment request is submitted repeatedly; a settlement module, configured to generate a payment order number according to the payment request and monitor the processing status of the payment request; and When the payment request is in the first processing state, the payment slip corresponding to the payment request is locked according to the payment slip number, and the payment slip locking request is cached in a queue, and after the queue releases the payment slip locking request, the payment slip is sent to the bank-enterprise module; Determine whether there is a resource release, and if so, obtain a first lock request in the queue, and determine whether the first lock request conflicts with a range of existing lock requests; If yes, provide corresponding resources for the first lock request; If not, determine whether the conflict range between the first lock request and the existing lock request belongs to an extended range, and if so, lock the extended range according to the first lock request, and remove the first lock request from the queue; The bank-enterprise module is used to generate a payment instruction serial number according to the payment order after receiving the payment order; determine whether the payment instruction serial number already exists, and if so, do not repeat the processing; wherein the payment instruction serial number is generated by the bank-enterprise module according to the document number; If not present, send the command to multiple lines.

2. The system according to claim 1, characterized in that The settlement module is further configured to: generate a unique payment order number for the payment request according to a timestamp and a random number; and obtain and record a processing status corresponding to the payment request from the bank-enterprise module according to the unique payment order number.

3. A repeated payment management method based on the idempotence principle, characterized in that: The method comprises: Used to receive a payment request and determine whether the payment request is submitted repeatedly; Generate a payment order number according to the payment request, and monitor the processing status of the payment request; When the payment request is in the first processing state, the payment slip corresponding to the payment request is locked according to the payment slip number, and the payment slip locking request is cached in a queue, and after the queue releases the payment slip locking request, the payment slip is sent to the bank-enterprise module; Determine whether there is a resource release, and if so, obtain a first lock request in the queue, and determine whether the first lock request conflicts with a range of existing lock requests; If yes, provide corresponding resources for the first lock request; If not, determine whether the conflict range between the first lock request and the existing lock request belongs to an extended range, and if so, lock the extended range according to the first lock request, and remove the first lock request from the queue; After receiving the payment slip, generating a payment instruction serial number according to the payment slip; determining whether the payment instruction serial number already exists, and if so, not repeating the processing; wherein the payment instruction serial number is generated by the bank-enterprise module according to the document number; If not present, send the command to multiple lines.

4. The method according to claim 3, characterized in that The method comprises: according to an optimistic locking mechanism, locking the extended range according to a first lock request, and removing the first lock request from the queue.

5. The method according to claim 3, characterized in that: After sending the instruction to the plurality of rows, the method further comprises: Send the instruction to each payment receiving node, and each payment receiving node determines the order status; Regularly query the order status to determine whether the order status has changed; If so, the order status is called back to the settlement module, and the processing status of the payment order in the settlement module is updated.

6. The method according to claim 3, characterized in that Generating a payment order number according to the payment request and monitoring the processing status of the payment request includes: Generate a unique payment order number for the payment request based on the timestamp and the random number; According to the unique payment order number, the processing status corresponding to the payment request is obtained and recorded from the bank-enterprise module.

7. The method according to claim 3, characterized in that Determining whether the payment request is submitted repeatedly includes: Based on the payment request, generate and store a unique token in the user session; After a preset time, receive a new payment request and verify whether the token corresponding to the new payment request is consistent with the token stored in the user session; If they are consistent, the payment request is a duplicate request and is rejected.

8. The method according to claim 3, characterized in that After the instructions are sent to the multiple rows, the method further includes: releasing the locked instructions.

9. A repeated payment management device based on the idempotence principle, characterized in that: The device comprises: A repeated submission determination unit, used for receiving a payment request and determining whether the payment request is submitted repeatedly; A monitoring unit, configured to generate a payment order number according to the payment request and monitor the processing status of the payment request; A sending unit, configured to lock the payment slip corresponding to the payment request according to the payment slip number when the payment request is in the first processing state, cache the payment slip locking request to a queue, and send the payment slip to the bank-enterprise module after the queue releases the payment slip locking request; a conflict determination unit, configured to determine whether there is a resource release, and if so, obtain a first lock request in the queue, and determine whether the first lock request conflicts with a range of existing lock requests; A resource determining unit, configured to, if yes, provide corresponding resources for the first lock request; a release resource acquisition unit, configured to, if not, determine whether the conflicting range between the first lock request and the existing lock request belongs to an extended range, and if so, lock the extended range according to the first lock request, and remove the first lock request from the queue; A serial number determination unit, used to generate a payment instruction serial number according to the payment slip; determine whether the payment instruction serial number already exists, and if so, do not repeat the process; wherein the payment instruction serial number is generated by the bank-enterprise module according to the document number; The instruction sending unit is used for sending the instruction to multiple rows if it does not exist.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 3 to 8 is implemented.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 3 to 8 is implemented.

12. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the method according to any one of claims 3 to 8 is implemented.

Images