Repeated payment prevention method and device based on direct connection payment scene

Abstract

The invention belongs to the technical field of nuclear power, and particularly relates to a repeated payment prevention method and device based on a direct connection payment scene. According to the invention, through an extension mechanism of the UI event, the unique payment identification code is automatically generated before the user initiates the payment operation. The identification code is bound with information of a payment initiator and core data of a payment bill, so that repeated payment caused by repeated clicking or misoperation is effectively prevented, and uniqueness and safety of a payment process are ensured. Before a user actually initiates payment, the state of a payment bill is inquired from a back-end interface; and the user is allowed to initiate the payment request only when the payment order state is "non-payment" or "payment failure". According to the measure, the repeated payment risk caused by misoperation of the user is reduced, and the payment safety is improved. Besides, an asynchronous mechanism is adopted, the payment request information is sent to the MQ, the payment request processing flexibility is improved, and the information loss risk caused by network fluctuation is reduced.

Description

Technical Field

[0001] The present disclosure belongs to the field of information technology, and specifically relates to a method and device for preventing duplicate payment based on a direct payment scenario. Background Art

[0002] In the related art, when the business applicant initiates a direct payment to the treasury system in the MetaERP system, there is a risk of duplicate payment during the payment initiation process. On the payment initiation page, users may perform improper operations, such as clicking the payment button quickly and continuously, or multiple payment initiators may make payment requests for the same payment order at the same time. These situations may lead to multiple payment requests being issued, which in turn leads to the problem of duplicate payments, causing confusion in the flow of funds and the risk of losses for the enterprise.

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

[0004] In addition, the independence of the two systems will also lead to data consistency issues. Since MetaERP and the treasury system are independent system architectures, there is a lack of consistency verification mechanism for fund flow data. This independence, coupled with the possible loss of payment request log information, makes it difficult for companies to effectively trace the source of problems when abnormal payments occur, affecting the efficiency of subsequent fund verification and abnormal handling. Summary of the invention

[0005] In order to overcome the problems existing in the related art, a method and device for preventing duplicate payment based on a direct payment scenario are provided.

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

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

[0008] Step 102, after the payment button is triggered and before the payment is actually initiated, query the status of the current payment order; when it is determined that the status of the payment order is unpaid or payment failed, the payment button can still be triggered; when it is determined that the status of the payment order is in payment, the payment button is disabled;

[0009] Step 103, using the message queue MQ mechanism to send the payment request information corresponding to the payment order to the treasury system. During the process of MQ processing the payment request information and before sending the payment request information, multiple checks are performed to determine whether the payment identification code bound to the payment request information is associated with the core data of other payment orders. If the multiple checks all determine that the payment identification code is not associated with the core data of other payment orders, the payment request information is sent. If it is detected in any check that the payment identification code has been associated with the core data of other payment orders, the processing of the payment request message is terminated.

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

[0011] Step 105: By providing a payment status callback interface, the latest status of the payment order in the treasury system is updated to the payment log table in real time.

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

[0013] Step 1031, using the MQ mechanism to send the payment request information corresponding to the payment order to the treasury system. 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, then step 1032 is executed. If it is detected that the payment identification code has been associated with the core data of other payment orders, then the processing of the payment request message is terminated.

[0014] Step 1032, 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; if it is detected that the payment identification code has been associated with the core data of other payment orders, terminate the processing of the payment request message.

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

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

[0017] Step 106, configure the background scheduled task to poll and check the payment order in the payment status in the MetaERP system and the corresponding payment result in the treasury system according to the payment identification code of each payment order at a preset frequency; if it is detected that the status of the payment order is paying and the treasurer has not received the payment request for the payment order, re-initiate payment for the payment order; if it is detected that the status of the payment order is paying and the treasurer has successfully processed the payment for the payment order, update the status of the payment order in the MetaERP system to payment successful.

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

[0019] Step 107, establish a data consistency check and exception handling mechanism, and poll and check whether the MetaERP payment order is consistent with the corresponding payment result in the treasury system during the network idle period; if data inconsistency is found during the comparison process, the abnormal data will be added to the data exception table.

[0020] According to another aspect of an embodiment of the present disclosure, a device for preventing duplicate payment based on a direct payment scenario is provided, the device comprising:

[0021] A generation module is used to generate a payment identification code uniquely corresponding to the current payment order after the payment button on the payment interface is triggered and when the U-shield is signed, and to bind the payment identification code with the payment initiator information of the payment order and the core data of the payment order;

[0022] A query module, used to query the status of the current payment order after the payment button is triggered and before the payment is actually initiated; when the status of the payment order is judged to be unpaid or payment failed, the payment button can still be triggered; when the status of the payment order is judged to be in payment, the payment button is invalid;

[0023] A verification module is used to send the payment request information corresponding to the payment order to the treasury system by using the message queue MQ mechanism. During the process of MQ processing the payment request information and before sending the payment request information, it is verified multiple times whether the payment identification code bound to the payment request information is associated with the core data of other payment orders. If the multiple verifications all determine that the payment identification code is not associated with the core data of other payment orders, the payment request information is sent. If it is detected in any verification that the payment identification code has been associated with the core data of other payment orders, the processing of the payment request message is terminated.

[0024] A first updating module, configured to update the status of the payment order to being paid after the payment corresponding to the payment order is successfully initiated, and record the status and information of the payment order in a payment log list;

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

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

[0027] The first checking submodule is used to send the payment request information corresponding to the payment order to the treasury system by using the MQ mechanism, and when subscribing to 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, then execute step 1032; if it is detected that the payment identification code is already associated with the core data of other payment orders, then terminate the processing of the payment request message;

[0028] The second checking submodule is used to assemble 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 executed. If it is detected that the payment identification code is already associated with the core data of other payment orders, the processing of the payment request message is terminated.

[0029] In one possible implementation, in the first checking submodule, when the payment request information of the payment order is sent to the treasury system using the MQ mechanism, if it is detected that a 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 manner, the device further includes:

[0031] The real-time polling module is used to configure the background scheduled tasks, and poll the payment identification code of each payment order at a preset frequency to check the payment order in the MetaERP system with the corresponding payment result in the treasury system; if it is detected that the status of the payment order is paying and the treasurer has not received the payment request for the payment order, the payment will be re-initiated for the payment order; if it is detected that the status of the payment order is paying and the treasurer has successfully processed the payment for the payment order, the status of the payment order in the MetaERP system will be updated to payment success.

[0032] In a possible implementation manner, the device further includes:

[0033] The periodic polling module is used to establish a data consistency check and exception handling mechanism. During the network idle period, the MetaERP payment order is polled to check whether the corresponding payment result in the treasury system is consistent; if data inconsistency is found during the comparison process, the abnormal data will be added to the data exception table.

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

[0035] processor;

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

[0037] Wherein, the processor is configured to execute the above method.

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

[0039] The beneficial effects of the present disclosure are: 1. Generation of a unique payment identification code: The present disclosure automatically generates a unique payment identification code before the user initiates a payment operation through the extended mechanism of UI events. This identification code is bound to the payment initiator information and the core data of the payment order, effectively preventing duplicate payments caused by multiple clicks or operational errors, and ensuring the uniqueness and security of the payment process.

[0040] 2. Front-end payment status prediction mechanism: Before the user actually initiates payment, the present disclosure first queries the status of the payment order from the back-end interface. Only when 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 payments caused by user operation errors and improves the security of payment.

[0041] 3. Asynchronous payment request processing mechanism: This disclosure adopts an asynchronous mechanism to send payment request information to MQ, ensuring that only after the server successfully receives the message can the payment request be considered to be effectively initiated. 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.

[0042] 4. Double verification of payment status and unique identification: The present disclosure performs consistency check on the unique identification code of the payment request and the payment order number to ensure that only the latest payment request is processed. This mechanism prevents the misprocessing of old requests and improves the accuracy and reliability of the payment process.

[0043] 5. Payment log and status change mechanism: After the payment request is successfully initiated, the system updates the payment status to "paying" and records key information in 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. Scheduled task polling and data consistency check: This paper designs a scheduled task mechanism to regularly poll the payment status and check the payment records of MetaERP and the treasury system to ensure data consistency. This further effectively responds to data transmission problems caused by network fluctuations and improves the reliability and stability of the payment system. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 It is a flow chart of an anti-duplicate payment method based on a direct payment scenario shown in an embodiment of the present disclosure.

[0046] Figure 2 It is a block diagram of an anti-duplicate payment device based on a direct payment scenario shown in an embodiment of the present disclosure. DETAILED DESCRIPTION

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

[0048] Unless otherwise defined, the technical and scientific terms used in the present disclosure have the same meanings as those generally understood by those skilled in the art to which the present disclosure belongs; the terms used in the present disclosure are only for the purpose of describing specific embodiments and are not intended to limit the present disclosure; the term "including" and any variations thereof in the present disclosure are intended to cover non-exclusive inclusions. Obviously, the embodiments described in the present disclosure are only part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in the field without making creative efforts are within the scope of protection of the present disclosure.

[0049] Reference to "embodiments" in this disclosure means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the disclosure. The appearance of the phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0050] Figure 1 This is a flowchart of a method for preventing duplicate payments based on a direct payment scenario shown in an embodiment of the present disclosure. The method can be executed by a terminal device, wherein the terminal device can be a server, a desktop computer, a laptop computer, a tablet computer, etc. The terminal device can also be, for example, a user device, a vehicle-mounted device, or a wearable device, etc. The embodiment of the present disclosure does not limit the type of terminal device. Figure 1 As shown, the method includes: step 101 to step 105.

[0051] Step 101, after the payment button on the payment interface of the terminal device is triggered by the user, and when the U-shield is signed, a payment identification code uniquely corresponding to the current payment order is generated, and the payment identification code is bound to the payment initiator information of the payment order and the core data of the payment order (such as the order number and payment amount of the payment order), thereby ensuring the uniqueness of each payment operation, eliminating the problem of repeated payment caused by multiple clicks or operational errors at the source of the payment operation, ensuring the security and consistency of the payment process, and effectively preventing the repeated circulation 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 from the back-end interface to query the status of the payment order corresponding to the payment to be initiated. When the terminal device determines that the status of the payment order indicates that the payment order has not been paid or the payment has failed, the payment button can still be triggered, thereby allowing the user to continue to initiate a payment request. When the terminal device determines that the status of the payment order indicates that the payment order is being paid, the payment button is disabled (for example, a graphic prompt is used in the payment interface to indicate that the payment button is unavailable, so that the payment button has no trigger interaction. The embodiment of the present disclosure does not limit the specific form of button failure), thereby prohibiting the user from continuing to initiate payment requests. This process effectively prevents users from submitting requests repeatedly when the payment is not completed, and prevents the loss of funds due to operational errors.

[0053] It should be noted that step 101 and step 102 may be executed simultaneously or in sequence, and the present disclosure does not limit the execution order of step 101 and step 102.

[0054] Step 103, using the message queue MQ mechanism to send the payment request information corresponding to the payment order to the treasury system. During the process of MQ processing the payment request information and before sending the payment request information, multiple checks are performed to see whether the payment identification code bound to the payment request information is associated with the core data of other payment orders. If the multiple checks all determine that the payment identification code is not associated with the core data of other payment orders, the payment request information is sent. If it is detected in any check that the payment identification code has been associated with the core data of other payment orders, the processing of the payment request message is terminated.

[0055] As an example of this embodiment, step 103 may include step 1031 and step 1032 .

[0056] Step 1031, the terminal device subscribes to and consumes the payment request information in the MQ, and performs a consistency check on the payment identification code and the core data of the payment order in each payment request information. 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 has been 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 always processed in the payment process through the double verification of the payment status and the unique identifier.

[0057] In one possible implementation, in step 1031, when the terminal device uses the message queue MQ mechanism to send the payment request information of the payment slip to the treasury system, if it is detected that a copy of the payment request information has been stored in the message queue (for example, the message confirmation status ACK of the payment request is 1), the payment request information is sent to the treasury system. In this way, an asynchronous mechanism is adopted to initiate payment information. The coupling between systems is further reduced and error handling in concurrent scenarios is prevented, and the payment request is considered to be successfully sent only after the master node of the message queue successfully receives the payment request information. This design improves the flexibility of the system, while ensuring the integrity of the payment request and reducing the risk of payment information loss due to network fluctuations or system delays.

[0058] Step 1032: After the terminal device assembles the payment instruction according to the parameters of the payment request information, it performs a consistency check again on the payment identification code corresponding to the payment instruction and the core data of the payment order. If it is detected that the payment identification code has been 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 to ensure that no update or duplication of payment information occurs during the payment initiation process, thereby preventing the problem of concurrent repeated payments caused by parameter assembly delays.

[0059] Step 104, after the payment corresponding to the payment order is successfully initiated, the terminal device updates the status of the payment order to "paying", and records the payment request information of the payment order and the status at each moment in the payment log table, thereby ensuring the traceability of each payment operation. After the payment status of the payment order changes to "paying", the business corresponding to the payment order will not be able to initiate payment again until the treasurer returns the final processing result. Through such a design, even if problems arise later, the system can provide detailed payment initiation records, thereby providing a basis for rapid investigation and processing.

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

[0061] In a possible implementation, the method further includes step 106. In view of the fact that the MetaERP system and the treasury system are two independent systems, network fluctuations may cause data transmission failures. For this reason, the terminal device is configured with a background timer task, which polls and checks the payment order in the MetaERP system with the corresponding payment result in the treasury 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 status of the payment order is in payment and the treasury has not received the request, the terminal device will automatically re-initiate the payment; if it is detected that the status of the payment order is in payment and the treasury has successfully processed the payment for the payment order, the status of the payment order in the MetaERP system is updated to payment success. The monitoring and retry mechanism effectively reduces the risk of payment request data loss caused by network instability, ensures the consistency of payment status, and improves the reliability and accuracy of the payment process. Therefore, the timed task polling mechanism effectively responds to network fluctuations.

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

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

[0064] 1. Generation of unique payment identification code: This disclosure uses the extended mechanism of UI events to automatically generate a unique payment identification code before the user initiates a payment operation. This identification code is bound to the payment initiator information and the core data of the payment order, effectively preventing duplicate payments caused by multiple clicks or operational errors, and ensuring the uniqueness and security of the payment process.

[0065] 2. Front-end payment status prediction mechanism: Before the user actually initiates payment, the system first queries the status of the payment order from the back-end interface. Only when the payment order status is "unpaid" or "payment failed" will the user be allowed to initiate a payment request. This measure reduces the risk of repeated payments caused by user errors and improves payment security.

[0066] 3. Asynchronous payment request processing mechanism: This disclosure adopts an asynchronous mechanism to send payment request information to MQ, ensuring that only after the server successfully receives the message can the payment request be considered to be effectively initiated. 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. Double verification of payment status and unique identification: Through the integrated development tool LiveFlow, the present disclosure performs consistency check on the unique identification code of the payment request and the payment order number to ensure that only the latest payment request is processed. This mechanism prevents the misprocessing of old requests and improves the accuracy and reliability of the payment process.

[0068] 5. Payment log and status change mechanism: After the payment request is successfully initiated, the system updates the payment status to "paying" and records key information in 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.

[0069] 6. Scheduled task polling and data consistency check: This disclosure has designed a scheduled task mechanism to regularly poll the payment status and check the payment records of MetaERP and the treasury system to ensure data consistency. If an abnormality is found, the system will automatically record it in the data abnormality table for subsequent manual processing. This measure effectively addresses data transmission problems caused by network fluctuations and improves the reliability and stability of the payment system.

[0070] In a possible implementation, a device for preventing duplicate payment based on a direct payment scenario is provided, the device comprising:

[0071] A generation module is used to generate a payment identification code uniquely corresponding to the current payment order after the payment button on the payment interface is triggered and when the U-shield is signed, and to bind the payment identification code with the payment initiator information of the payment order and the core data of the payment order;

[0072] A query module, used to query the status of the current payment order after the payment button is triggered and before the payment is actually initiated; when the status of the payment order is judged to be unpaid or payment failed, the payment button can still be triggered; when the status of the payment order is judged to be in payment, the payment button is invalid;

[0073] A verification module is used to send the payment request information corresponding to the payment order to the treasury system by using the message queue MQ mechanism. During the process of MQ processing the payment request information and before sending the payment request information, it is verified multiple times whether the payment identification code bound to the payment request information is associated with the core data of other payment orders. If the multiple verifications all determine that the payment identification code is not associated with the core data of other payment orders, the payment request information is sent. If it is detected in any verification that the payment identification code has been associated with the core data of other payment orders, the processing of the payment request message is terminated.

[0074] A first updating module, configured to update the status of the payment order to being paid after the payment corresponding to the payment order is successfully initiated, and record the status and information of the payment order in a payment log list;

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

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

[0077] The first checking submodule is used to send the payment request information corresponding to the payment order to the treasury system by using the MQ mechanism, and when subscribing to 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, then execute step 1032; if it is detected that the payment identification code is already associated with the core data of other payment orders, then terminate the processing of the payment request message;

[0078] The second checking submodule is used to assemble 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 executed. If it is detected that the payment identification code is already associated with the core data of other payment orders, the processing of the payment request message is terminated.

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

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

[0081] The real-time polling module is used to configure the background scheduled tasks, and poll the payment identification code of each payment order at a preset frequency to check the payment order in the MetaERP system with the corresponding payment result in the treasury system; if it is detected that the status of the payment order is paying and the treasurer has not received the payment request for the payment order, the payment will be re-initiated for the payment order; if it is detected that the status of the payment order is paying and the treasurer has successfully processed the payment for the payment order, the status of the payment order in the MetaERP system will be updated to payment success.

[0082] In a possible implementation manner, the device further includes:

[0083] The periodic polling module is used to establish a data consistency check and exception handling mechanism. During the network idle period, the MetaERP payment order is polled to check whether the corresponding payment result in the treasury system is consistent; if data inconsistency is found during the comparison process, the abnormal data will be added to the data exception table.

[0084] The description of the above-mentioned device has been explained in detail in the description of the above-mentioned method, and will not be repeated here.

[0085] Figure 2 1900 is a block diagram of an anti-duplicate payment device based on a direct payment scenario shown in an embodiment of the present disclosure. For example, the device 1900 may be provided as a server. Figure 2 , the apparatus 1900 includes a processing component 1922, which further includes one or more processors, and a memory resource represented by a memory 1932 for storing instructions, such as an application, that can be executed by the processing component 1922. The application stored in the memory 1932 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 1922 is configured to execute instructions to perform the above method.

[0086] The device 1900 may also include a power supply component 1926 configured to perform power management of the device 1900, a wired or wireless network interface 1950 configured to connect the device 1900 to a network, and an input / output (I / O) interface 1958. The device 1900 may operate based on an operating system stored in the memory 1932, such as Windows Server™, MacOS X™, Unix™, Linux™, FreeBSD™, or the like.

[0087] In an exemplary embodiment, a non-volatile computer-readable storage medium is also provided, such as a memory 1932 including computer program instructions, which can be executed by the processing component 1922 of the device 1900 to perform the above method.

[0088] The present disclosure may be a system, a method and / or a computer program product. The computer program product may include a computer-readable storage medium carrying computer-readable program instructions for causing a processor to implement various aspects of the present disclosure.

[0089] A computer-readable storage medium may be a tangible device that can hold and store instructions used by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electrical 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 of computer-readable storage media (a non-exhaustive list) include: a portable computer disk, 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 disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device, such as a punch card or a raised structure in a groove on which instructions are stored, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium is not to be interpreted as a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse through a fiber optic cable), or an electrical signal transmitted through a wire.

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

[0091] The computer program instructions for performing the operation of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages, such as Smalltalk, C++, etc., and conventional procedural programming languages, such as "C" language or similar programming languages. Computer-readable program instructions may be executed completely on a user's computer, partially on a user's computer, as an independent software package, partially on a user's computer, partially on a remote computer, or completely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., using an Internet service provider to connect via the Internet). In some embodiments, an electronic circuit, such as a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may be customized by utilizing the state information of the computer-readable program instructions, and the electronic circuit may execute the computer-readable program instructions, thereby realizing various aspects of the present disclosure.

[0092] Various aspects of the present disclosure are described herein with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to the embodiments of the present disclosure. It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer-readable program instructions.

[0093] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, thereby producing a machine, so that when these instructions are executed by the processor of the computer or other programmable data processing device, a device that implements the functions / actions specified in one or more boxes in the flowchart and / or block diagram is generated. These computer-readable program instructions can also be stored in a computer-readable storage medium, and these instructions cause the computer, programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable medium storing the instructions includes a manufactured product, which includes instructions for implementing various aspects of the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0094] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operating steps are performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to implement the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0095] The flow chart and block diagram in the accompanying drawings show the possible architecture, function and operation of the system, method and computer program product according to multiple embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a part of a module, program segment or instruction, and a part of the module, program segment or instruction includes one or more executable instructions for realizing the specified logical function. In some alternative implementations, the function marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two continuous square boxes can actually be executed substantially in parallel, and they can sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs the specified function or action, or can be implemented with a combination of special hardware and computer instructions.

[0096] The embodiments of the present disclosure have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or improvements to the technology in the market, or to enable other persons of ordinary skill 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 on the payment interface is triggered and when the U-Shield is signed, a payment identification code uniquely corresponding to the current payment order is generated, and the payment identification code is bound to the payment initiator information 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, query the status of the current payment order; when it is determined that the status of the payment order is unpaid or payment failed, the payment button can still be triggered; when it is determined that the status of the payment order is in payment, the payment button is disabled; Step 103, using the message queue MQ mechanism to send the payment request information corresponding to the payment order to the treasury system. During the process of MQ processing the payment request information and before sending the payment request information, multiple checks are performed to determine whether the payment identification code bound to the payment request information is associated with the core data of other payment orders. If the multiple checks all determine that the payment identification code is not associated with the core data of other payment orders, the payment request information is sent. If it is detected in any check that the payment identification code has been associated with the core data of other payment orders, the processing of the payment request message is terminated. Step 104: after the payment corresponding to the payment order is successfully initiated, the status of the payment order is updated to being paid, and the status and information of the payment order are recorded in the payment log list; Step 105: By providing a payment status callback interface, the latest status of the payment order in the treasury system is updated to the payment log table in real time.

2. The method according to claim 1, characterized in that: Step 103 includes: Step 1031, using the MQ mechanism to send the payment request information corresponding to the payment order to the treasury system. 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, then step 1032 is executed. If it is detected that the payment identification code has been associated with the core data of other payment orders, then the processing of the payment request message is terminated. Step 1032, 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; if it is detected that the payment identification code has been associated with the core data of other payment orders, terminate the processing of the payment request message.

3. The method according to claim 2, characterized in that In step 1031, in the process of sending the payment request information of the payment order to the treasury system using the MQ mechanism, if it is detected that a copy of the payment request information has been stored in the MQ, the payment request information is sent to the treasury system.

4. The method according to claim 1, characterized in that The method further comprises: Step 106, configure the background scheduled task to poll and check the payment order in the payment status in the MetaERP system and the corresponding payment result in the treasury system according to the payment identification code of each payment order at a preset frequency; if it is detected that the status of the payment order is paying and the treasurer has not received the payment request for the payment order, re-initiate payment for the payment order; if it is detected that the status of the payment order is paying and the treasurer has successfully processed the payment for the payment order, update the status of the payment order in the MetaERP system to payment successful.

5. The method according to claim 1, characterized in that The method further comprises: Step 107, establish a data consistency check and exception handling mechanism, and poll and check whether the MetaERP payment order is consistent with the corresponding payment result in the treasury system during the network idle period; if data inconsistency is found during the comparison process, the abnormal data will be added to the data exception table.

6. An anti-duplicate payment device based on a direct payment scenario, characterized in that: The device comprises: A generation module is used to generate a payment identification code uniquely corresponding to the current payment order after the payment button on the payment interface is triggered and when the U-shield is signed, and to bind the payment identification code with the payment initiator information of the payment order and the core data of the payment order; A query module, used to query the status of the current payment order after the payment button is triggered and before the payment is actually initiated; when the status of the payment order is judged to be unpaid or payment failed, the payment button can still be triggered; when the status of the payment order is judged to be in payment, the payment button is invalid; A verification module is used to send the payment request information corresponding to the payment order to the treasury system by using the message queue MQ mechanism. During the process of MQ processing the payment request information and before sending the payment request information, it is verified multiple times whether the payment identification code bound to the payment request information is associated with the core data of other payment orders. If the multiple verifications all determine that the payment identification code is not associated with the core data of other payment orders, the payment request information is sent. If it is detected in any verification that the payment identification code has been associated with the core data of other payment orders, the processing of the payment request message is terminated. A first updating module, configured to update the status of the payment order to being paid after the payment corresponding to the payment order is successfully initiated, and record the status and information of the payment order in a payment log list; The second updating module is used to update the latest status of the payment order in the treasury system to the payment log table in real time by providing a payment status callback interface.

7. The device according to claim 1, characterized in that The verification modules include: The first checking submodule is used to send the payment request information corresponding to the payment order to the treasury system by using the MQ mechanism, and when subscribing to 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, then execute step 1032; if it is detected that the payment identification code is already associated with the core data of other payment orders, then terminate the processing of the payment request message; The second checking submodule is used to assemble 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 executed. If it is detected that the payment identification code is already associated with the core data of other payment orders, the processing of the payment request message is terminated.

8. The device according to claim 2, characterized in that In the first checking submodule, in the process of sending the payment request information of the payment order to the treasury system using the MQ mechanism, if it is detected that a copy of the payment request information has been stored in the MQ, the payment request information is sent to the treasury system.

9. The device according to claim 1, characterized in that The device also includes: The real-time polling module is used to configure the background scheduled tasks, and poll the payment identification code of each payment order at a preset frequency to check the payment order in the MetaERP system with the corresponding payment result in the treasury system; if it is detected that the status of the payment order is paying and the treasurer has not received the payment request for the payment order, the payment will be re-initiated for the payment order; if it is detected that the status of the payment order is paying and the treasurer has successfully processed the payment for the payment order, the status of the payment order in the MetaERP system will be updated to payment success.

10. The device according to claim 1, characterized in that The device also includes: The periodic polling module is used to establish a data consistency check and exception handling mechanism. During the network idle period, the MetaERP payment order is polled to check whether the corresponding payment result in the treasury system is consistent; if data inconsistency is found during the comparison process, the abnormal data will be added to the data exception table.

11. An anti-duplicate payment device based on a direct payment scenario, characterized in that: The device comprises: processor; a memory for storing processor-executable instructions; The processor is configured to execute the method according to any one of claims 1 to 5.

12. A non-volatile computer-readable storage medium having computer program instructions stored thereon, characterized in that: When the computer program instructions are executed by a processor, the method according to any one of claims 1 to 5 is implemented.

Images