Method and device for controlling repeated payments at aggregate payment cashier counter

Abstract

The present invention discloses a method and device for controlling repeated payment at an aggregate payment cashier, and relates to the field of financial technology. The method comprises: when receiving a payment request initiated by a user terminal through a preset payment channel, querying the first processing status of a business order corresponding to the payment request; if the first processing status is unpaid, generating a payment serial number, and processing the payment request through a preset payment channel; when determining that the transaction processing corresponding to the payment serial number is successful, setting the payment status of the payment serial number to payment success, and querying the second processing status of the business order according to the payment serial number; if the second processing status is paid, marking the payment serial number as repeated payment; and performing a refund operation on the transaction corresponding to the payment serial number marked as repeated payment. The present invention can allow the user to pay again when the order payment status is unclear, avoid the user waiting, and improve the user experience.

Description

Technical Field

[0001] The present invention relates to the field of financial technology, and in particular to a method and device for controlling repeated payments at an aggregate payment cashier counter. Background Art

[0002] This section is intended to provide a background or context to the embodiments of the invention recited in the claims. No admission is made that the description herein is prior art by inclusion in this section.

[0003] When a payment application is called up, if the order payment status is unclear due to reasons such as the user not completing the payment or poor network connection, in order to avoid duplicate payments, the user is often not allowed to pay again. The user is allowed to initiate the transaction again only after the order times out, which results in a long waiting time and affects the user experience. Summary of the invention

[0004] The embodiment of the present invention provides a method for controlling repeated payments at a converged payment cashier, which is used to allow a user to pay again when the order payment status is unclear, thereby avoiding the user waiting and improving the user experience. The method includes:

[0005] When receiving a payment request initiated by a user terminal through a preset payment channel, querying a first processing status of a business order corresponding to the payment request;

[0006] If the first processing status is unpaid, a payment serial number is generated and the payment request is processed through a preset payment channel;

[0007] When it is determined that the transaction corresponding to the payment serial number is successfully processed, the payment status of the payment serial number is set to payment successful, and the second processing status of the business order is queried according to the payment serial number;

[0008] If the second processing status is paid, the payment serial number is marked as a duplicate payment;

[0009] Refund transactions corresponding to payment serial numbers marked as duplicate payments.

[0010] The embodiment of the present invention also provides a device for controlling repeated payment at a cashier counter of an aggregate payment, which is used to allow a user to pay again when the payment status of an order is unclear, thereby avoiding the user from waiting and improving the user experience. The device includes:

[0011] A query module, configured to query a first processing status of a business order corresponding to a payment request initiated by a user terminal through a preset payment channel when the communication module receives the payment request;

[0012] A processing module, configured to generate a payment serial number and process the payment request through a preset payment channel when the first processing status is unpaid;

[0013] The query module is further used to set the payment status of the payment serial number to payment success when it is determined that the transaction corresponding to the payment serial number is successfully processed, and query the second processing status of the business order according to the payment serial number;

[0014] A marking module, used for marking the payment serial number as a repeated payment when the second processing status is paid;

[0015] The refund module is used to perform a refund operation on the transaction corresponding to the payment serial number marked as a duplicate payment.

[0016] An embodiment of the present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned method for controlling repeated payments at an aggregate payment checkout counter when executing the computer program.

[0017] An embodiment of the present invention also provides a computer-readable storage medium, which stores a computer program for executing the above-mentioned aggregate payment checkout counter repeated payment control method.

[0018] In the embodiment of the present invention, the user is allowed to initiate payment requests multiple times. When a payment request is received from a user terminal, the first processing status of the business order at this time is queried. If the first processing status is unpaid, it is determined that any payment request for the business order has not been successfully processed, and a payment serial number is generated to process this payment request. When the transaction corresponding to the payment serial number is successfully processed, the second processing status of the business order at this time is queried. If the second processing status is paid, it indicates that in the process of processing the transaction, other transactions corresponding to other payment requests have been successfully paid, and the current successful payment transaction is a repeated payment. The payment serial number is marked as a repeated transaction, and a refund operation is performed. In this way, the user can initiate payment requests multiple times in succession without waiting in between; when a payment request is received, each payment request will be processed when the business order is not paid. When the transaction corresponding to any of the payment requests is successfully processed, a refund operation is performed on other successful payment transactions, which is equivalent to using the fastest channel that can be successfully processed to conduct transactions, speeding up the payment speed, while also avoiding user fund losses caused by repeated transactions, and improving user experience. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0020] Figure 1 This is a flow chart of a method for controlling repeated payments at a cashier counter for aggregated payment according to an embodiment of the present invention;

[0021] Figure 2 Another flow chart of a method for controlling repeated payments at a cashier counter for aggregated payment according to an embodiment of the present invention;

[0022] Figure 3 Another flow chart of a method for controlling repeated payments at a cashier counter for aggregated payment according to an embodiment of the present invention;

[0023] Figure 4 It is a structural schematic diagram of a repeated payment control device for a cashier counter of an aggregate payment according to an embodiment of the present invention;

[0024] Figure 5 The figure is a schematic diagram of the structure of a computer device in an embodiment of the present invention. DETAILED DESCRIPTION

[0025] To make the purpose, technical solution and advantages of the embodiments of the present invention more clear, the embodiments of the present invention are further described in detail below in conjunction with the accompanying drawings. Here, the exemplary embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0026] The technical terms involved in the embodiments of the present invention will be briefly explained below.

[0027] Aggregate payment: refers to the integration of multiple payment methods (such as WeChat, Alipay, etc.) and the provision of payment services with unified standards.

[0028] Cashier: A front-end page that provides multiple payment methods.

[0029] Duplicate payment: For the same business order, multiple successful payments are completed. For example, the user chooses WeChat Pay to submit the payment. When the payment has been submitted, the user calls up the aggregate payment checkout counter and chooses Alipay to pay. If both WeChat and Alipay payments are successful, it will result in duplicate payment. Or, if WeChat Pay is selected twice and both payments are successful, it will also result in duplicate payment.

[0030] The embodiment of the present invention provides a method for controlling repeated payments at a cashier counter of an aggregate payment system. Figure 1 As shown, the method includes steps 101 to 105:

[0031] Step 101: When a payment request initiated by a user terminal through a preset payment channel is received, a first processing status of a business order corresponding to the payment request is queried.

[0032] The preset payment channel may be any payment method provided by the aggregate payment cashier, such as bank card payment, WeChat, Alipay or Cloud QuickPass, etc. The aggregate payment cashier provides multiple preset payment channels, from which the user selects a payment channel to initiate a payment request.

[0033] Before receiving a payment request initiated by a user terminal through a preset payment channel, such as Figure 2 As shown, the following steps 201 and 202 may also be performed:

[0034] Step 201: Receive business order information submitted by the merchant, which includes the order number and payment amount.

[0035] Step 202: Determine the processing status of each business order according to the payment result of the business order.

[0036] The processing status includes paid and unpaid. When the payment is successful, the processing status changes from unpaid to paid.

[0037] The business order information may also include information such as the merchant number. The payment request initiated by the user includes the order number, and the business order information is associated with the user's payment request through the order number in the business order information. The payment amount is used to confirm whether the amount paid by the user is accurate. The merchant number is used to determine the merchant to receive the payment. The business order information may also include other information, which will not be listed here one by one.

[0038] The initial status of each business order is unpaid. Before the payment is successful, its status remains unpaid. Only when the payment is successful, the processing status changes from unpaid to paid. Therefore, it can be determined whether the user has completed the payment based on the processing status.

[0039] It should be noted that, in the embodiment of the present invention, payment failure is classified as an unpaid state.

[0040] Considering the linkage operation between the aggregate payment cashier and the merchant terminal and the user terminal, when the user calls up the aggregate payment cashier, the merchant terminal sends the business order information to the repeated payment control device of the aggregate payment cashier once. If the user calls up the aggregate payment cashier multiple times, the business order information will be sent repeatedly. When receiving the business order information, it can be first determined whether the business order information is saved. If the same business order information is not saved, the business order information is saved; if the same business order information has been saved, it is determined whether the processing status of the business order is paid. If it is paid, it returns to the user terminal that the order has been paid and please do not pay again; if the processing status is unpaid, it is fed back to the user terminal that the business order has been submitted successfully.

[0041] Step 102: If the first processing status is unpaid, a payment serial number is generated and the payment request is processed through a preset payment channel.

[0042] In the embodiment of the present invention, the payment request submitted by the user can be processed before the payment is successful. Therefore, after receiving the payment request from the user, the processing status of the business order is first queried, and the processing status of the business order at this time is used as the first processing status. When the first processing status is unpaid, each payment request submitted by the user is processed.

[0043] In another implementation, after querying the first processing status of the business order corresponding to the payment request, such as Figure 3 As shown, the following step 301 may also be performed:

[0044] Step 301: If the first processing status is paid, a payment success notification is sent to the user terminal and the payment request is rejected.

[0045] That is to say, if the business order has been paid successfully when the user payment request is received, the payment request will no longer be processed to avoid duplicate payments and save processing resources.

[0046] Step 103: When it is determined that the transaction corresponding to the payment serial number is successfully processed, the payment status of the payment serial number is set to payment success, and the second processing status of the business order is queried according to the payment serial number.

[0047] Specifically, if a processing success notification sent by a preset payment channel is received within a specified time, it is determined that the transaction corresponding to the payment serial number is processed successfully.

[0048] Alternatively, if no processing success notification or processing failure notification is received from the preset payment channel within the specified time, the preset payment channel is queried for the processing result of the transaction corresponding to the payment serial number; if the queried processing result is successful, it is determined that the transaction corresponding to the payment serial number is processed successfully.

[0049] The designated time may be manually set, and when setting the time, the historical time at which the preset payment channel feeds back a successful processing notification or a failed processing notification may be referred to. For example, the preset payment channel generally completes the processing process and feeds back a successful processing notification or a failed processing notification within 3 minutes, and the designated time may be set to 3 minutes.

[0050] In an embodiment of the present invention, in addition to querying the preset payment channel for the processing result of the transaction corresponding to the payment serial number when the specified time is reached, the preset payment channel can also be queried for the processing result of the transaction corresponding to the payment serial number when the user actively initiates a refund request.

[0051] Each time a payment request is processed, a payment serial number is generated. The payment serial number is associated with the business order. The payment status of the payment serial number is determined according to the transaction processing result of the preset payment channel. If the preset payment channel feedbacks a successful processing notification, the payment status of the payment serial number is set to payment success; if the preset payment channel feedbacks a processing failure result, the payment status of the payment serial number is set to payment failure; if no feedback is received from the preset payment channel, the payment status of the payment serial number is set to empty, unclear or pending, etc.

[0052] In order to facilitate the determination of the payment status of each payment serial number, the association between the business order, payment serial number and payment status can be stored in a payment serial table and updated in real time.

[0053] Step 104: If the second processing status is paid, the payment serial number is marked as a repeated payment.

[0054] Step 105: Execute a refund operation on the transaction corresponding to the payment serial number marked as duplicate payment.

[0055] That is to say, after each transaction corresponding to a payment serial number is successfully processed, the current processing status of the business order (i.e., the second processing status) is queried. If the second processing status is unpaid, the processing status is changed to paid. If the second processing status queried at this time is paid, it indicates that during the transaction processing, transactions corresponding to other payment serial numbers have been successfully processed and the payment has been completed. In this case, a refund will be made for transactions corresponding to all payment serial numbers after the initial successful processing to avoid financial losses caused by repeated payments by users.

[0056] Considering that due to the failure of the preset payment channel or network failure, it may not be possible to receive feedback from the preset payment channel in time, or no query results are obtained when actively querying the preset payment channel, in this case, the reconciliation file sent by the preset payment channel can be used to confirm whether duplicate transactions have occurred. Specifically, the reconciliation file sent by the preset payment channel is received at each preset time interval; for each business order, the payment status corresponding to the payment serial number associated with the business order is queried; if it is not found, the payment status of the payment serial number is searched from the reconciliation file; when the payment status corresponding to all payment serial numbers associated with a business order is determined, it is determined whether there are at least two payment serial numbers that are not marked as duplicate payments and the payment status corresponding to them is successful; if so, the other payment serial numbers except the earliest payment serial number that succeeded are marked as duplicate payments, and the refund operation is performed on the transaction corresponding to the payment serial number marked as duplicate payment.

[0057] For example, a business order is associated with 4 payment serial numbers. The transaction corresponding to payment serial number A is successfully paid at 8:05, the payment corresponding to payment serial number B fails, the transaction corresponding to payment serial number C is successfully paid at 8:04, and the transaction corresponding to payment serial number D is successfully paid at 8:06. Then, no processing is performed on the transaction corresponding to payment serial number C, payment serial numbers A and D are marked as duplicate transactions, and refund operations are performed on the transactions corresponding to A and D.

[0058] Through reconciliation, duplicate payments can be further avoided, effectively preventing users from incurring financial losses.

[0059] After refunding the duplicate payment transaction, a reconciliation document can also be generated for the merchant to verify the account.

[0060] In the embodiment of the present invention, the user is allowed to initiate payment requests multiple times. When a payment request is received from a user terminal, the first processing status of the business order at this time is queried. If the first processing status is unpaid, it is determined that any payment request for the business order has not been successfully processed, and a payment serial number is generated to process this payment request. When the transaction corresponding to the payment serial number is successfully processed, the second processing status of the business order at this time is queried. If the second processing status is paid, it indicates that in the process of processing the transaction, other transactions corresponding to other payment requests have been successfully paid, and the current successful payment transaction is a repeated payment. The payment serial number is marked as a repeated transaction, and a refund operation is performed. In this way, the user can initiate payment requests multiple times in succession without waiting in between; when a payment request is received, each payment request will be processed when the business order is not paid. When the transaction corresponding to any of the payment requests is successfully processed, a refund operation is performed on other successful payment transactions, which is equivalent to using the fastest channel that can be successfully processed to conduct transactions, speeding up the payment speed, while also avoiding user fund losses caused by repeated transactions, and improving user experience.

[0061] The embodiment of the present invention also provides a device for controlling repeated payments at a cashier counter of an aggregate payment, as described in the following embodiment. Since the principle of solving the problem by the device is similar to that of the method for controlling repeated payments at a cashier counter of an aggregate payment, the implementation of the device can refer to the implementation of the method for controlling repeated payments at a cashier counter of an aggregate payment, and the repeated parts will not be repeated.

[0062] like Figure 4 As shown, the device 400 includes a query module 401, a communication module 402, a processing module 403, a marking module 404 and a refund module 405.

[0063] The query module 401 is used to query the first processing status of the business order corresponding to the payment request when the communication module 402 receives the payment request initiated by the user terminal through the preset payment channel;

[0064] Processing module 403, for generating a payment serial number and processing the payment request through a preset payment channel when the first processing status is unpaid;

[0065] The query module 401 is further used to set the payment status of the payment serial number to payment success when it is determined that the transaction corresponding to the payment serial number is successfully processed, and query the second processing status of the business order according to the payment serial number;

[0066] A marking module 404, configured to mark the payment serial number as a repeated payment when the second processing status is paid;

[0067] The refund module 405 is used to perform a refund operation on the transaction corresponding to the payment serial number marked as repeated payment.

[0068] In one implementation of the embodiment of the present invention,

[0069] The communication module is also used to receive the business order information submitted by the merchant, which includes the order number and payment amount;

[0070] The determination module is used to determine the processing status of each business order according to the payment result of the business order. The processing status includes paid and unpaid. When the payment is successful, the processing status is changed from unpaid to paid.

[0071] In an implementation manner of the embodiment of the present invention, the communication module is further used to:

[0072] If the first processing status is paid, a payment success notification is sent to the user terminal and the payment request is rejected.

[0073] In one implementation of the embodiment of the present invention,

[0074] If the communication module receives a successful processing notification sent by the preset payment channel within the specified time, the determination module determines that the transaction corresponding to the payment serial number is successfully processed; or,

[0075] If the communication module does not receive a processing success notification or a processing failure notification sent by the preset payment channel within the specified time, the communication module queries the preset payment channel for the processing result of the transaction corresponding to the payment serial number; if the processing result queried by the communication module is successful, it is determined that the transaction corresponding to the serial number of the payment confirmation module is successfully processed.

[0076] In one implementation of the embodiment of the present invention,

[0077] The communication module is further used to receive the reconciliation file sent by the preset payment channel at every preset time interval;

[0078] The query module is also used to query the payment status corresponding to the payment serial number associated with each business order;

[0079] The query module is also used to search for the payment status of the payment serial number from the reconciliation file when the payment serial number is not found;

[0080] A judgment module, used for determining the payment statuses corresponding to all payment serial numbers associated with a business order, and judging whether there are at least two payment serial numbers not marked as duplicate payments whose payment statuses are successful;

[0081] The marking module is used to mark other payment serial numbers except the earliest successful payment serial number as repeated payments when necessary, and the refund module performs a refund operation on the transaction corresponding to the payment serial number marked as repeated payment.

[0082] In the embodiment of the present invention, the user is allowed to initiate payment requests multiple times. When a payment request is received from a user terminal, the first processing status of the business order at this time is queried. If the first processing status is unpaid, it is determined that any payment request for the business order has not been successfully processed, and a payment serial number is generated to process this payment request. When the transaction corresponding to the payment serial number is successfully processed, the second processing status of the business order at this time is queried. If the second processing status is paid, it indicates that in the process of processing the transaction, other transactions corresponding to other payment requests have been successfully paid, and the current successful payment transaction is a repeated payment. The payment serial number is marked as a repeated transaction, and a refund operation is performed. In this way, the user can initiate payment requests multiple times in succession without waiting in between; when a payment request is received, each payment request will be processed when the business order is not paid. When the transaction corresponding to any of the payment requests is successfully processed, a refund operation is performed on other successful payment transactions, which is equivalent to using the fastest channel that can be successfully processed to conduct transactions, speeding up the payment speed, while also avoiding user fund losses caused by repeated transactions, and improving user experience.

[0083] An embodiment of the present invention further provides a computer device, Figure 5 Schematic diagram of a computer device in an embodiment of the present invention. The computer device can implement all steps in the method for controlling repeated payments at a cashier at an aggregated payment station in the above embodiment. The computer device specifically includes the following contents:

[0084] Processor (processor) 501, memory (memory) 502, communication interface (CommunicationsInterface) 503 and communication bus 504;

[0085] The processor 501, the memory 502, and the communication interface 503 communicate with each other through the communication bus 504; the communication interface 503 is used to realize information transmission between related devices;

[0086] The processor 501 is used to call the computer program in the memory 502, and when the processor executes the computer program, the method for controlling repeated payments at the aggregate payment cashier in the above embodiment is implemented.

[0087] An embodiment of the present invention also provides a computer-readable storage medium, which stores a computer program for executing the above-mentioned aggregate payment checkout counter repeated payment control method.

[0088] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0089] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0090] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0091] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0092] The specific embodiments described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for controlling repeated payments at a centralized payment cashier, characterized in that: The method comprises: When receiving a payment request initiated by a user terminal through a preset payment channel, querying a first processing status of a business order corresponding to the payment request; If the first processing status is unpaid, a payment serial number is generated and the payment request is processed through a preset payment channel; When it is determined that the transaction corresponding to the payment serial number is successfully processed, the payment status of the payment serial number is set to payment successful, and the second processing status of the business order is queried according to the payment serial number; If the second processing status is paid, the payment serial number is marked as a duplicate payment; Execute a refund operation on the transaction corresponding to the payment serial number marked as duplicate payment; The method further comprises: Receive reconciliation files sent by a preset payment channel at preset time intervals; For each business order, query the payment status corresponding to the payment serial number associated with the business order; If the number is not found, search for the payment status of the payment serial number in the reconciliation file; When determining the payment statuses corresponding to all payment serial numbers associated with a business order, it is determined whether there are at least two payment serial numbers that are not marked as duplicate payments and the payment statuses corresponding to the payment are successful; If there is, the other payment serial numbers except the earliest successful payment serial number will be marked as duplicate payments, and a refund operation will be performed on the transactions corresponding to the payment serial numbers marked as duplicate payments.

2. The method according to claim 1, characterized in that Before receiving a payment request initiated by a user terminal through a preset payment channel, the method further includes: Receive business order information submitted by the merchant, which includes the order number and payment amount; The processing status of each business order is determined according to the payment result of the business order. The processing status includes paid and unpaid. When the payment is successful, the processing status is changed from unpaid to paid.

3. The method according to claim 1 or 2, characterized in that: After querying the first processing status of the business order corresponding to the payment request, the method further includes: If the first processing status is paid, a payment success notification is sent to the user terminal and the payment request is rejected.

4. The method according to claim 1 or 2, characterized in that: When it is determined that the transaction corresponding to the payment serial number is successfully processed, before querying the second processing status of the business order according to the payment serial number, the method further includes: If a successful processing notification is received from a preset payment channel within a specified time, it is determined that the transaction corresponding to the payment serial number is successfully processed; or, If no processing success notification or processing failure notification is received from the preset payment channel within the specified time, the preset payment channel is queried for the processing result of the transaction corresponding to the payment serial number; if the queried processing result is successful, it is determined that the transaction corresponding to the payment serial number has been successfully processed.

5. A device for controlling repeated payments at a cashier counter for aggregated payment, characterized in that: The device comprises: A query module, configured to query a first processing status of a business order corresponding to a payment request initiated by a user terminal through a preset payment channel when the communication module receives the payment request; A processing module, configured to generate a payment serial number and process the payment request through a preset payment channel when the first processing status is unpaid; The query module is further used to set the payment status of the payment serial number to payment success when it is determined that the transaction corresponding to the payment serial number is successfully processed, and query the second processing status of the business order according to the payment serial number; A marking module, used for marking the payment serial number as a repeated payment when the second processing status is paid; A refund module is used to perform a refund operation on transactions corresponding to payment serial numbers marked as duplicate payments; The communication module is further used to receive the reconciliation file sent by the preset payment channel at every preset time interval; The query module is also used to query the payment status corresponding to the payment serial number associated with each business order; The query module is also used to search for the payment status of the payment serial number from the reconciliation file when the payment serial number is not found; A judgment module, used for determining the payment statuses corresponding to all payment serial numbers associated with a business order, and judging whether there are at least two payment serial numbers not marked as duplicate payments whose payment statuses are successful; The marking module is used to mark other payment serial numbers except the earliest successful payment serial number as repeated payments when necessary, and the refund module performs a refund operation on the transaction corresponding to the payment serial number marked as repeated payment.

6. The device according to claim 5, characterized in that The communication module is also used to receive the business order information submitted by the merchant, which includes the order number and payment amount; The determination module is used to determine the processing status of each business order according to the payment result of the business order. The processing status includes paid and unpaid. When the payment is successful, the processing status is changed from unpaid to paid.

7. The device according to claim 5 or 6, characterized in that Communication modules are also used for: If the first processing status is paid, a payment success notification is sent to the user terminal and the payment request is rejected.

8. The device according to claim 5 or 6, characterized in that If the communication module receives a successful processing notification sent by the preset payment channel within the specified time, the determination module determines that the transaction corresponding to the payment serial number is successfully processed; or, If the communication module does not receive a processing success notification or a processing failure notification sent by the preset payment channel within the specified time, the communication module queries the preset payment channel for the processing result of the transaction corresponding to the payment serial number; If the processing result queried by the communication module is successful, it is determined that the transaction corresponding to the serial number of the payment determination module is successfully processed.

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

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

Images