Method and device for preventing duplicate payment based on direct payment scenario

Abstract

The present disclosure belongs to the technical field of nuclear power and specifically relates to a method and device for preventing repeated payment based on a direct payment scene. The present disclosure automatically generates a unique payment identification code through an extension mechanism of a UI event before a user initiates a payment operation. The identification code is bound with payment initiator information and core data of a payment order, effectively preventing repeated payment caused by multiple clicks or operation errors, and ensuring the uniqueness and security of the payment process. Before the user actually initiates payment, the status of the payment order is first queried to the backend interface. Only in the case that the payment order status is 'unpaid' or 'payment failed', the user is allowed to initiate a payment request. This measure reduces the risk of repeated payment caused by user operation errors and improves the security of payment. In addition, the present disclosure uses an asynchronous mechanism to send payment request information to an MQ, improves the flexibility of payment request processing, and reduces the risk of information loss caused by network fluctuations.

Description

TECHNICAL FIELD

[0001] The present disclosure belongs to the field of information technology, and particularly relates to a method and device for preventing repeated payment based on a direct payment scenario. BACKGROUND

[0002] In the related art, MetaERP system has a risk of repeated payment when a business applicant initiates a direct payment to a treasurysystem. In the payment initiation page, the user may perform improper operations, such as quickly and continuously clicking the payment button, or multiple payment initiators simultaneously perform payment requests for the same payment order. These situations may lead to the issuance of multiple payment requests, and thus cause the problem of repeated payment, which brings confusion and loss risk to the enterprise in the process of fund circulation.

[0003] Network fluctuations during the payment initiation process also often lead to abnormal payment requests. During the transmission of payment requests between the MetaERP system and the treasurysystem, network fluctuations may cause the payment requests to fail to be successfully transmitted. For example, the MetaERP system has issued a payment request but the treasurysystem has not received it, or the treasurysystem has completed the payment but the callback information is lost during transmission to the MetaERP system. Both of these situations may cause the payment status between the MetaERP system and the treasurysystem to be out of sync, resulting in inconsistent payment information, and ultimately causing account reconciliation problems, affecting the accuracy of enterprise fund management.

[0004] In addition, the independence of the two systems will also lead to data consistency problems. Since the MetaERP and the treasurysystem are independent system architectures, there is a lack of consistency verification mechanism for fund circulation data. This independence, combined with the possible loss of payment request log information, makes it difficult for the enterprise to effectively trace the source of the problem when an abnormal payment occurs, affecting the efficiency of subsequent fund verification and abnormal processing. SUMMARY

[0005] To overcome the problems in the related art, a method and device for preventing repeated payment based on a direct payment scenario are provided.

[0006] According to an aspect of an embodiment of the present disclosure, a method for preventing repeated payment based on a direct payment scenario is provided, which comprises:

[0007] Step 101, after the payment button of the payment interface is triggered, and when the U key is signed, a payment identification code uniquely corresponding to the current payment order is generated, and the payment identification code is bound with the information of the payment initiator of the payment order and the core data of the payment order;

[0008] Step 102, after the payment button is triggered, and before the actual payment is initiated, the status of the current payment order is queried; when it is judged that the status of the payment order is unpaid or payment fails, the payment button can still be triggered; when it is judged that the status of the payment order is in payment, the payment button is disabled;

[0009] Step 103, the payment request information corresponding to the payment order is sent to the treasurer system by using the message queue MQ mechanism, and in the process of processing the payment request information by the MQ, and before the payment request information is sent, the payment identification code bound to the payment request information is checked multiple times whether it is associated with the core data of other payment orders, if the payment identification code is not associated with the core data of other payment orders in the multiple times, the payment request information is sent, if the payment identification code is detected to be associated with the core data of other payment orders in any time, the processing of the payment request message is terminated;

[0010] Step 104, after the payment order corresponding to the payment is successfully initiated, the status of the payment order is updated to in payment, and the status and information of the payment order are recorded in the payment log list;

[0011] Step 105, by providing a payment state callback interface, the latest state of the payment order in the treasurer system is updated to the payment log table in real time.

[0012] In a possible implementation, step 103 includes:

[0013] Step 1031, the payment request information corresponding to the payment order is sent to the treasurer system by using the MQ mechanism, and when the payment request information in the MQ is subscribed and consumed, if it is detected that the payment identification code is not associated with the core data of other payment orders, step 1032 is executed, if it is detected that the payment identification code is associated with the core data of other payment orders, the processing of the payment request message is terminated;

[0014] Step 1032, after the payment instruction is assembled according to the parameters of the payment request information, if it is detected that the payment identification code is not associated with the core data of other payment orders, step 105 is executed, if it is detected that the payment identification code is associated with the core data of other payment orders, the processing of the payment request message is terminated.

[0015] In a possible implementation, in step 1031, in the process of sending the payment request information of the payment order to the treasurer system by using the MQ mechanism, when it is detected that the copy of the payment request information has been stored in the MQ, the payment request information is sent to the treasurer system.

[0016] In a possible implementation, the method further includes:

[0017] Step 106, configure a background timing task to poll the payment order in the MetaERP system and the corresponding payment result in the treasurer system according to the payment identification code of each payment order at a preset frequency; if it is detected that the state of the payment order is in payment, and the treasurer has not received the payment request of the payment order, then reinitiate payment for the payment order; if it is detected that the state of the payment order is in payment, and the treasurer has successfully processed payment for the payment order, then update the state of the payment order in the MetaERP system to payment success.

[0018] In a possible implementation, the method further includes:

[0019] Step 107, establish a data consistency checking and exception handling mechanism, poll and compare the payment order in the MetaERP system and the corresponding payment result in the treasurer system at a network idle period; if inconsistent data is found in the comparison process, then record the exception data in a data exception table.

[0020] According to another aspect of the embodiments of the present disclosure, a device for preventing duplicate payment in a direct payment scenario is provided, and the device includes:

[0021] A generation module is configured to generate a payment identification code uniquely corresponding to a current payment order after a payment button of a payment interface is triggered, and bind the payment identification code with information of a payment initiator of the payment order and core data of the payment order when U-key signing is performed.

[0022] A query module is configured to query a state of the current payment order after the payment button is triggered and before actual payment is initiated; when the state of the payment order is determined to be unpaid or payment failure, the payment button can still be triggered; when the state of the payment order is determined to be in payment, the payment button is disabled.

[0023] A checking module is configured to send payment request information corresponding to a payment order to a treasurer system by using a message queue (MQ) mechanism; during MQ processing of the payment request information and before the payment request information is sent, the checking module checks whether the payment identification code bound to the payment request information is associated with core data of other payment orders multiple times; if the payment identification code is determined not to be associated with the core data of other payment orders in the multiple times, the payment request information is sent; if the payment identification code is detected to be associated with the core data of other payment orders in any one of the multiple times, the processing of the payment request information is terminated.

[0024] A first updating module is configured to update the state of the payment order to in payment after payment initiation corresponding to the payment order is successful, and record the state and information of the payment order in a payment log list.

[0025] The second updating module is configured to update the latest state of the payment order in the treasury system into the payment log table in real time by providing a payment state callback interface.

[0026] In a possible implementation, the checking module comprises:

[0027] The first checking submodule is configured to send the payment request information corresponding to the payment order to the treasury system by using the MQ mechanism, and if it is detected that the payment identification code is not associated with the core data of other payment orders, execute step 1032, and if it is detected that the payment identification code is already associated with the core data of other payment orders, terminate the processing of the payment request message.

[0028] The second checking submodule is configured to, after assembling the payment instruction according to the parameters of the payment request information, if it is detected that the payment identification code is not associated with the core data of other payment orders, execute step 105, and if it is detected that the payment identification code is already associated with the core data of other payment orders, terminate the processing of the payment request message.

[0029] In a possible implementation, in the first checking submodule, in the process of sending the payment request information of the payment order to the treasury system by using the MQ mechanism, if it is detected that the copy of the payment request information has been stored in the MQ, the payment request information is sent to the treasury system.

[0030] In a possible implementation, the apparatus further comprises:

[0031] The real-time polling module is configured to configure a background timing task to poll, according to the payment identification code of each payment order, the payment order in the payment state in the MetaERP system and the corresponding payment result in the treasury system at a preset frequency; if it is detected that the state of the payment order is in payment and the treasury has not received the payment request of the payment order, reinitiate payment for the payment order; and if it is detected that the state of the payment order is in payment and the treasury has successfully processed payment for the payment order, update the state of the payment order in the MetaERP system to payment success.

[0032] In a possible implementation, the apparatus further comprises:

[0033] The periodic polling module is configured to establish a data consistency checking and exception handling mechanism, and poll, in a network idle period, whether the payment order in the MetaERP system and the corresponding payment result in the treasury system are consistent; if it is found in the comparison process that the data are inconsistent, the exception data are added to a data exception table.

[0034] According to another aspect of the embodiments of the present disclosure, a device for preventing duplicate payment based on a direct payment scenario is provided, and the device comprises:

[0035] a processor;

[0036] a memory for storing processor-executable instructions;

[0037] wherein the processor is configured to perform the above method.

[0038] According to another aspect of the embodiments of the present disclosure, a non-volatile computer readable storage medium is provided, which stores computer program instructions, and the computer program instructions are executed by a processor to implement the above method.

[0039] The present disclosure has the following advantages: 1. Generation of unique payment identification code: The present disclosure automatically generates a unique payment identification code before the user initiates a payment operation through the extension mechanism of the UI event. This identification code is bound with the payment initiator information and the core data of the payment order, effectively preventing repeated payments caused by multiple clicks or operation errors, and ensuring the uniqueness and security of the payment process.

[0040] 2. Front-end payment state prediction mechanism: Before the user actually initiates a payment, the present disclosure first queries the state of the payment order to the back-end interface. Only in the case that the payment order state is “unpaid” or “payment failed”, the user is allowed to initiate a payment request. This measure reduces the risk of repeated payments caused by user operation errors and improves the security of payment.

[0041] 3. Asynchronous payment request processing mechanism: The present disclosure uses an asynchronous mechanism to send payment request information to MQ, ensuring that only when the server successfully receives the message can the payment request be considered as valid initiation. This design reduces the coupling between systems, improves the flexibility of payment request processing, and reduces the risk of information loss caused by network fluctuations.

[0042] 4. Dual verification of payment state and unique identification: The present disclosure checks the consistency of the unique identification code of the payment request and the payment order number, ensuring that only the latest payment request is processed. This mechanism prevents the misprocessing of old requests, improves the accuracy and reliability of the payment process.

[0043] 5. Payment log and state change mechanism: After the payment request is successfully initiated, the system updates the payment state to “in payment”, and records the key information to the payment log table within a transaction. This design ensures the traceability of each payment operation and provides detailed record basis for subsequent problem handling, enhancing the transparency of the system.

[0044] 6. Timed task polling and data consistency check: the disclosure designs a timed task mechanism, periodically polling the payment status, checking the payment records of MetaERP and the treasurer system, to ensure the consistency of the data. Further effectively deal with the data transmission problem caused by network fluctuation, improve the reliability and stability of the payment system. BRIEF DESCRIPTION OF DRAWINGS

[0045] Figure 1 is a flowchart of a method for preventing duplicate payments based on a direct payment scenario, as illustrated in an embodiment of the disclosure.

[0046] Figure 2 is a block diagram of an apparatus for preventing duplicate payments based on a direct payment scenario, as illustrated in an embodiment of the disclosure. DETAILED DESCRIPTION

[0047] The disclosure will be described in further detail below with reference to the accompanying drawings and specific embodiments.

[0048] Unless otherwise defined, technical and scientific terms used in the disclosure have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs; the terminology used in the disclosure is for the purpose of describing the specific embodiments only and is not intended to be limiting of the disclosure; the term "comprising" and any variation thereof in the disclosure is intended to cover non-exclusive inclusion. Obviously, the embodiments described in the disclosure are only a part of the embodiments of the disclosure, not all the embodiments. Based on the embodiments in the disclosure, all other embodiments obtained by those of ordinary skill in the art without creative labor are within the scope of protection of the disclosure.

[0049] In the disclosure, "embodiment" means that the specific features, structures or characteristics described in conjunction with the embodiment can be included in at least one embodiment of the disclosure. The appearance of this phrase in various places in the specification does not necessarily mean the same embodiment, nor is it an independent or alternative embodiment to other embodiments. Those skilled in the art explicitly and implicitly understand that the embodiments described herein can be combined with other embodiments.

[0050] Figure 1 is a flowchart of a method for preventing duplicate payments based on a direct payment scenario, as illustrated in an embodiment of the disclosure. The method can be executed by a terminal device, where the terminal device can be a server, a desktop computer, a notebook computer, a tablet computer, etc., and the terminal device can also be, for example, a user device, a vehicle-mounted device, or a wearable device, etc., and the type of terminal device is not limited by the embodiments of the disclosure. As shown in Figure 1 , the method comprises steps 101 to 105.

[0051] Step 101, after the payment button of the payment interface is triggered by the user, and when the U key is signed, the terminal device generates a payment identification code corresponding to the current payment order uniquely, and binds the payment identification code with the information of the payment initiator of the payment order and the core data of the payment order (such as the order number and the payment amount of the payment order), so as to ensure the uniqueness of each payment operation, and to prevent the problem of repeated payment caused by multiple clicks or operation errors at the source of the payment operation, ensure the safety and consistency of the payment process, and effectively prevent the repeated flow of funds.

[0052] Step 102, after the payment button is triggered by the user, and before the payment is actually initiated, the terminal device also requests the database of the back-end interface to query the state of the payment order corresponding to the current payment to be initiated. When the terminal device judges that the state of the payment order indicates that the payment order is not paid or the payment fails, the payment button can still be triggered, so as to allow the user to continue to initiate a payment request. When the terminal device judges that the state of the payment order indicates that the payment order is being paid, the payment button is disabled (for example, a graphic text prompt is used in the payment interface to indicate that the payment button is unavailable, so that the payment button has no triggering interaction, and the specific form of button disable in the embodiment of the present disclosure is not limited), so as to prohibit the user from continuing to initiate a payment request. This process effectively prevents the user from repeatedly submitting a request in the case of incomplete payment, and prevents the loss of funds caused by operation errors.

[0053] It should be noted that steps 101 and 102 can be executed simultaneously or in sequence, and the execution order between steps 101 and 102 is not limited in the present disclosure.

[0054] Step 103, the payment request information corresponding to the payment order is sent to the treasurers system by using the message queue MQ mechanism. In the process of processing the payment request information by the MQ, and before the payment request information is sent, the payment identification code bound to the payment request information is checked multiple times to determine whether it is associated with the core data of other payment orders. If the payment identification code is not associated with the core data of other payment orders in the multiple checks, the payment request information is sent. If the payment identification code is detected to be associated with the core data of other payment orders in any check, the processing of the payment request message is terminated.

[0055] As an example of the embodiment, step 103 can include steps 1031 and 1032.

[0056] In step 1031, the terminal device subscribes and consumes the payment request information in the MQ, and performs consistency check on the payment identifier code and the core data of the payment order in each piece of payment request information. If it is detected that the payment identifier code is not associated with the core data of other payment orders, step 1032 is performed; if it is detected that the payment identifier code is already associated with the core data of other payment orders, it is determined that the payment request information has been updated or repeated, and the processing of the payment request message is terminated, thereby ensuring that only the latest payment request is processed in the payment process through the double check of the payment state and the unique identifier.

[0057] In a possible implementation, in step 1031, in the process in which the terminal device sends the payment request information of the payment order to the treasurersystem by using the message queue MQ mechanism, the payment request information is sent to the treasurer system in the case where it is detected that the copy of the payment request information has been stored in the message queue (for example, the message acknowledgement state ACK of the payment request is 1). In this way, the payment information is initiated by using an asynchronous mechanism. The coupling between systems is further reduced, and error processing in a concurrent scenario is prevented, and only when the payment request information is successfully received by the master node of the message queue, it can be considered that the payment request is successfully sent. This design improves the flexibility of the system, while ensuring the integrity of the payment request, and reducing the risk of loss of payment information caused by network fluctuations or system delay.

[0058] In step 1032, the terminal device performs consistency check on the payment identifier code corresponding to the payment instruction and the core data of the payment order again after the payment instruction is assembled according to the parameters of the payment request information. If it is detected that the payment identifier code is already associated with the core data of other payment orders, it is determined that the payment request information has been updated or repeated, and the processing of the payment request message is terminated, thereby ensuring that no update or repeated operation of the payment information occurs in the payment initiation process, so as to prevent the concurrent repeated payment problem caused by parameter assembly delay.

[0059] In step 104, after the payment initiation corresponding to the payment order succeeds, the terminal device updates the state of the payment order to payment in progress, and records the payment request information of the payment order and the state at each moment in the payment log table, thereby ensuring the traceability of each payment operation. After the payment state of the payment order becomes payment in progress, the business corresponding to the payment order cannot initiate payment again until the treasurer returns the final processing result. Through such a design, even if problems occur subsequently, the system can provide detailed payment initiation records, thereby providing a basis for rapid troubleshooting and processing.

[0060] Step 105, since the payment interface of the treasurer is asynchronous, the terminal device ensures that the treasurer can update the payment status in MetaERP in time after processing is completed by providing a payment status callback interface. If the payment is successful, the payment status is updated to payment success; if the payment fails, the payment status is updated to payment failure, and is recorded in the payment log table. The callback mechanism not only ensures real-time update of the payment status, but also synchronizes the payment result to the payment log table, facilitating subsequent auditing and tracing.

[0061] In a possible implementation, the method further includes step 106, since the MetaERP system and the treasurer system are two independent systems, network fluctuations can cause data transmission failure, therefore, the terminal device is configured with a background timing task to poll and check the payment order in the payment state in the MetaERP system and the corresponding payment result in the treasurer system according to the payment identification code of each payment order at a preset frequency (for example, polling every hour). If it is found that the state of the payment order is in payment, and the treasurer has not received the request, the terminal device will automatically reinitiate payment; if it is detected that the state of the payment order is in payment, and the treasurer has successfully processed payment for the payment order, the state of the payment order in the MetaERP system is updated to payment success. Through the monitoring and retry mechanism, the risk of payment request data loss caused by network instability is effectively reduced, the consistency of the payment status is ensured, and the reliability and accuracy of the payment process are improved, so that the timing task polling mechanism effectively deals with network fluctuations.

[0062] In a possible implementation, the method further includes step 107, the terminal device establishes a data consistency checking and exception handling mechanism, in order to further ensure the data consistency between the MetaERP system and the treasurer system, the terminal device designs a data checking mechanism. The mechanism sets a timing task to poll and check the payment order in the MetaERP and the corresponding payment result in the treasurer system during the network idle period (for example, the early morning period every day) to confirm whether the payment records in the two systems are consistent. If inconsistent data is found in the comparison process, the system will automatically record the abnormal data in a specially designed data exception table for subsequent manual intervention for processing.

[0063] The advantages of the present disclosure compared with the prior art are as follows:

[0064] 1. Generation of unique payment identification code: the present disclosure automatically generates a unique payment identification code before the user initiates a payment operation through the extension mechanism of the UI event. The identification code is bound with the payment initiator information and the core data of the payment order, effectively preventing repeated payments caused by multiple clicks or operation errors, and ensuring the uniqueness and security of the payment process.

[0065] 2. Front-end payment state prediction mechanism: Before the user actually initiates payment, the system first queries the state of the payment order to the back-end interface. Only in the case of the payment order state being "unpaid" or "payment failure", the user is allowed to initiate a payment request. This measure reduces the risk of repeated payment due to user operation errors and improves the security of payment.

[0066] 3. Asynchronous payment request processing mechanism: The present disclosure uses an asynchronous mechanism to send payment request information to MQ, ensuring that only when the server successfully receives the message can the payment request be considered valid. This design reduces the coupling between systems, improves the flexibility of payment request processing, and reduces the risk of information loss due to network fluctuations.

[0067] 4. Dual verification of payment state and unique identifier: Through the integrated development tool LiveFlow, the present disclosure checks the consistency of the unique identifier of the payment request and the payment order number, ensuring that only the latest payment request is processed. This mechanism prevents the misprocessing of old requests, improving the accuracy and reliability of the payment process.

[0068] 5. Payment log and state change mechanism: After the payment request is successfully initiated, the system updates the payment state to "in payment" and records key information to the payment log table within a transaction. This design ensures the traceability of each payment operation and provides detailed records for subsequent problem handling, enhancing the transparency of the system.

[0069] 6. Timed task polling and data consistency check: The present disclosure designs a timed task mechanism to periodically poll payment states and check payment records in MetaERP and the treasurer system to ensure data consistency. If abnormalities are found, the system will automatically record them in the data exception table for subsequent manual processing. This measure effectively addresses data transmission problems caused by network fluctuations, improving the reliability and stability of the payment system.

[0070] In one possible implementation, a device for preventing repeated payment in a direct payment scenario is provided, the device comprising:

[0071] A generation module for generating a payment identifier uniquely corresponding to the current payment order after the payment button of the payment interface is triggered and during U-shield signing, and binding the payment identifier with the information of the payment initiator of the payment order and the core data of the payment order;

[0072] A query module for querying the state of the current payment order after the payment button is triggered and before the actual payment is initiated; in the case of determining that the state of the payment order is unpaid or payment failure, the payment button can still be triggered; in the case of determining that the state of the payment order is in payment, the payment button is disabled;

[0073] The collation module is configured to send the payment request information corresponding to the payment order to the treasurer system by using the message queue (MQ) mechanism. During the process of processing the payment request information by the MQ, and before the payment request information is sent, the collation module collates whether the payment identification code bound to the payment request information is associated with the core data of other payment orders multiple times. If the payment identification code is determined not to be associated with the core data of other payment orders in the multiple times of collation, the payment request information is sent. If the payment identification code is detected to be associated with the core data of other payment orders in any time of collation, the processing of the payment request message is terminated.

[0074] The first updating module is configured to update the state of the payment order to payment in progress after the payment order corresponding to the payment initiation succeeds, and record the state and information of the payment order in the payment log list.

[0075] The second updating module is configured to update the latest state of the payment order in the treasurer system to the payment log table in real time by providing a payment state callback interface.

[0076] In a possible implementation, the collation module includes:

[0077] The first collation submodule is configured to send the payment request information corresponding to the payment order to the treasurer system by using the MQ mechanism. When subscribing and consuming the payment request information in the MQ, if it is detected that the payment identification code is not associated with the core data of other payment orders, step 1032 is performed. If it is detected that the payment identification code is associated with the core data of other payment orders, the processing of the payment request message is terminated.

[0078] The second collation submodule is configured to, after assembling the payment instruction according to the parameters of the payment request information, if it is detected that the payment identification code is not associated with the core data of other payment orders, step 105 is performed. If it is detected that the payment identification code is associated with the core data of other payment orders, the processing of the payment request message is terminated.

[0079] In a possible implementation, in the first collation submodule, during the process of sending the payment request information of the payment order to the treasurer system by using the MQ mechanism, if it is detected that the copy of the payment request information has been stored in the MQ, the payment request information is sent to the treasurer system.

[0080] In a possible implementation, the apparatus further includes:

[0081] The real-time polling module is configured to set a background timing task to poll and check the payment order in the MetaERP system and the corresponding payment result in the treasurer system according to the payment identification code of each payment order at a preset frequency; if it is detected that the state of the payment order is in payment and the treasurer has not received the payment request of the payment order, the payment for the payment order is reinitiated; if it is detected that the state of the payment order is in payment and the treasurer has successfully processed the payment for the payment order, the state of the payment order in the MetaERP system is updated to payment success.

[0082] In a possible implementation, the apparatus further comprises:

[0083] The periodic polling module is configured to establish a data consistency checking and exception handling mechanism, and poll and check whether the payment order in the MetaERP system and the corresponding payment result in the treasurer system are consistent during a network idle period; if it is found that the data are inconsistent during the comparison, the exception data are added to a data exception table.

[0084] The description of the apparatus has been described in detail in the description of the method, and thus is not described herein again.

[0085] Figure 2 is a block diagram of an apparatus for preventing duplicate payment based on a direct payment scenario according to an embodiment of the present disclosure. For example, the apparatus 1900 can be provided as a server. Referring to Figure 2 , the apparatus 1900 comprises a processing component 1922, which further comprises one or more processors, and a memory resource represented by a memory 1932, for storing instructions, such as an application program, executable by the processing component 1922. The application program stored in the memory 1932 can comprise one or more than one module each corresponding to a set of instructions. In addition, the processing component 1922 is configured to execute the instructions to perform the method described above.

[0086] The apparatus 1900 can further comprise a power supply component 1926 configured to perform power management of the apparatus 1900, a wired or wireless network interface 1950 configured to connect the apparatus 1900 to a network, and an input / output (I / O) interface 1958. The apparatus 1900 can operate based on an operating system stored in the memory 1932, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM or the like.

[0087] In an exemplary embodiment, a non-volatile computer readable storage medium, such as the memory 1932 comprising computer program instructions executable by the processing component 1922 of the apparatus 1900 to perform the method described above, is also provided.

[0088] The present disclosure can be a system, a method, and / or a computer program product. The computer program product can include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present disclosure.

[0089] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium include the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or punched tape, a

[0090] The computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device.

[0091] Computer readable program instructions for carrying out operations of the present disclosure can be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate array (FPGA), or programmable logic array (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

[0092] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0093] These computer readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions can also be stored in a computer readable storage medium that can include random access memory (RAM), read only memory (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other data storage device. When the computer readable program instructions are loaded into the computer and other programmable data processing apparatus, a series of operational steps are implemented that provide processes such that the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0094] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer, other programmable data processing apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0095] The flow diagrams and the block diagrams in the drawings are presented to illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flow diagrams and the block diagrams can represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logic functions. In some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flow diagrams, and combinations thereof, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and

[0096] Embodiments of the present disclosure have been described above, and the description is intended to be illustrative of the embodiments and not restrictive. Many modifications and variations of the described embodiments are possible and are within the scope of the disclosure. The selection of terms is intended to best describe the principles of the embodiments, practical application, or improvement over the technology in the art, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for preventing duplicate payment based on a direct payment scenario, characterized in that, The method comprises: Step 101, after the payment button of the payment interface is triggered, and when the U disk is signed, a payment identification code uniquely corresponding to the current payment order is generated, and the payment identification code is bound with the information of the payment initiator of the payment order and the core data of the payment order; Step 102, after the payment button is triggered, and before the payment is actually initiated, the state of the current payment order is queried; when it is judged that the state of the payment order is not paid or payment fails, the payment button can still be triggered; when it is judged that the state of the payment order is in payment, the payment button is disabled; Step 103, the payment request information corresponding to the payment order is sent to the treasurer system by using the message queue MQ mechanism, and in the process of processing the payment request information by MQ, and before the payment request information is sent, the payment identification code bound with the payment request information is checked multiple times whether it is associated with the core data of other payment orders, if the multiple checks all judge that the payment identification code is not associated with the core data of other payment orders, the payment request information is sent, and if the payment identification code is detected to have been associated with the core data of other payment orders in any one check, the processing of the payment request information is terminated; Step 104, after the payment initiator corresponding to the payment order is successfully provided, the state of the payment order is updated to in payment, and the state and information of the payment order are recorded in the payment log list; Step 105, by providing a payment state callback interface, the latest state of the payment order in the treasurer system is updated to the payment log list in real time.

2. The method of claim 1, wherein, Step 103 comprises: Step 1031, the payment request information corresponding to the payment order is sent to the treasurer system by using the MQ mechanism, and when the payment request information in the MQ is subscribed and consumed, if it is detected that the payment identification code is not associated with the core data of other payment orders, step 1032 is executed, and if it is detected that the payment identification code has been associated with the core data of other payment orders, the processing of the payment request information is terminated; Step 1032, after the payment instruction is assembled according to the parameters of the payment request information, if it is detected that the payment identification code is not associated with the core data of other payment orders, step 105 is executed, and if it is detected that the payment identification code has been associated with the core data of other payment orders, the processing of the payment request information is terminated.

3. The method of claim 2, wherein, In step 1031, in the process of sending the payment request information of the payment order to the treasurer system by using the MQ mechanism, when it is detected that the copy of the payment request information has been stored in the MQ, the payment request information is sent to the treasurer system.

4. The method of claim 1, wherein, The method further comprises: Step 106, a background timing task is configured to poll and check the payment order in the MetaERP system in the payment state and the corresponding payment result in the treasurer system according to the payment identification code of each payment order at a preset frequency; if it is detected that the state of the payment order is in payment, and the treasurer has not received the payment request of the payment order, the payment of the payment order is reinitiated; if it is detected that the state of the payment order is in payment, and the treasurer has successfully processed the payment for the payment order, the state of the payment order in the MetaERP system is updated to payment success.

5. The method of claim 1, wherein, The method further comprises: Step 107, a data consistency check and exception handling mechanism is established, and payment orders in the MetaERP system and corresponding payment results in the treasurer system are compared in a network idle period; if inconsistent data is found in the comparison process, the inconsistent data is stored in a data exception table.

6. A device for preventing duplicate payment based on a direct payment scenario, characterized by, The device comprises: A generation module is configured to generate a payment identification code uniquely corresponding to a current payment order after a payment button of a payment interface is triggered and during U-key signing, and bind the payment identification code with information of a payment initiator of the payment order and core data of the payment order; A query module is configured to query a state of the current payment order after the payment button is triggered and before actual payment is initiated; the payment button can still be triggered when the state of the payment order is determined to be unpaid or payment failed; the payment button is disabled when the state of the payment order is determined to be in payment; A comparison module is configured to send payment request information corresponding to the payment order to a treasurer system by using a message queue MQ mechanism; the payment identification code bound to the payment request information is compared with core data of other payment orders multiple times during processing of the payment request information by the MQ and before the payment request information is sent; if the payment identification code is determined not to be associated with the core data of other payment orders in the multiple comparisons, the payment request information is sent; if the payment identification code is detected to be associated with the core data of other payment orders in any one comparison, processing of the payment request information is terminated; A first update module is configured to update the state of the payment order to in payment after the payment initiator corresponding to the payment order succeeds, and record the state and information of the payment order in a payment log list; A second update module is configured to update the latest state of the payment order in the treasurer system to the payment log list in real time by providing a payment state callback interface.

7. A device for preventing duplicate payment based on a direct payment scenario, characterized by, The device comprises: A processor; A memory for storing processor-executable instructions; The processor is configured to execute the method of any one of claims 1 to 5.

8. A non-transitory computer readable storage medium having stored thereon computer program instructions, wherein, The computer program instructions are executed by the processor to implement the method of any one of claims 1 to 5. The computer program instructions are executed by the processor to implement the method of any one of claims 1 to 5.

Images