Code scanning payment method, medium, electronic device, and program product

Abstract

This disclosure relates to a QR code payment method, medium, electronic device, and program product, belonging to the field of mobile payment technology. The method records the first payment state of the payment code in the client when the payment code is generated, obtains the second payment state of the payment code from the server, and for each payment code recorded by the client, when the second payment state of the payment code changes relative to the first payment state, the payment code is identified as the first payment code with the changed payment state, and the first payment state corresponding to the first payment code is updated to the second payment state. Then, based on the second payment state of the first payment code, a target interaction action is determined and executed, enabling the client to perceive changes in the payment state of payment codes previously displayed, thereby supporting the scanning of multiple payment codes and ensuring that users can use payment codes for QR code payments under any circumstances.

Description

Technical Field

[0001] This disclosure relates to the field of mobile payment technology, specifically to a QR code payment method, medium, electronic device, and program product. Background Technology

[0002] With the continuous development of payment technology, QR code payment has penetrated into various fields. QR code payment includes the scan-to-pay model, where the user's client displays a payment code, which the merchant then scans to complete the payment.

[0003] In related technologies, if the payment code displayed on the client for the first time is scanned by the merchant, the payment code will be in the payment process. If the payment waiting time is too long and the client does not realize that the initially displayed payment code is in the payment process, the client will periodically refresh the payment code to a new one.

[0004] At this point, in the relevant technology, the client will no longer be aware of the payment status of the payment code displayed for the first time. If the first scan payment requires interactive actions such as identity verification before the payment can be successful, the client will be unable to perform the interactive action, resulting in payment failure. Summary of the Invention

[0005] This summary section is provided to briefly introduce the concepts, which will be described in detail in the detailed description section below. This summary section is not intended to identify key or essential features of the claimed technical solution, nor is it intended to limit the scope of the claimed technical solution.

[0006] Firstly, this disclosure provides a QR code payment method, including: When the payment code is generated on the client side, the first payment status of the payment code is recorded in the client side. Obtain the second payment status of the payment code from the server; For each payment code recorded by the client, when the second payment status of the payment code changes relative to the first payment status, the payment code is identified as the first payment code whose payment status has changed, and the first payment status corresponding to the first payment code is updated to the second payment status. Based on the second payment status of the first payment code, determine the target interactive action; Perform the target interactive action.

[0007] In a second aspect, this disclosure provides a computer-readable medium having a computer program stored thereon, which, when executed by a processing device, implements the steps of the method described in the first aspect.

[0008] Thirdly, this disclosure provides an electronic device, including: A storage device on which computer programs are stored; A processing device for executing the computer program in the storage device to implement the steps of the method described in the first aspect.

[0009] Fourthly, this disclosure provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in the first aspect.

[0010] Based on the above technical solution, when a payment code is generated on the client side, its first payment status is recorded in the client. The second payment status of the payment code is obtained from the server. For each payment code recorded on the client side, when the second payment status of the payment code changes relative to the first payment status, the payment code is identified as the first payment code whose payment status has changed, and the first payment status corresponding to the first payment code is updated to the second payment status. Then, based on the second payment status of the first payment code, the target interaction action is determined and executed. This allows the client to perceive the change in the payment status of the payment code displayed before the currently displayed payment code, thereby supporting the scanning of multiple payment codes and ensuring that users can use payment codes for scanning payments under any circumstances.

[0011] Other features and advantages of this disclosure will be described in detail in the following detailed description section. Attached Figure Description

[0012] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale. In the drawings: Figure 1 This is a flowchart illustrating a QR code payment method according to some embodiments.

[0013] Figure 2 This is a flowchart illustrating a QR code payment method according to other embodiments.

[0014] Figure 3 This is a schematic diagram of the structure of a QR code payment device according to some embodiments.

[0015] Figure 4 This is a schematic diagram of the structure of an electronic device according to some embodiments. Detailed Implementation

[0016] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0017] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0018] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0019] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0020] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0021] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0022] Figure 1 This is a flowchart illustrating a QR code payment method according to some embodiments. For example... Figure 1 As shown, this disclosure provides a QR code payment method, which can be executed by a server, specifically by a QR code payment device, which can be implemented in software and / or hardware. Figure 1 As shown, the method may include the following steps.

[0023] In step 110, when the payment code is generated on the client side, the first payment status of the payment code is recorded in the client side.

[0024] Here, a payment code is a QR code or barcode used for electronic payments. The payment code contains information required for payment, such as the payment amount and recipient identification information. When making a payment by scanning the code, the user displays the payment code, and the merchant or payment terminal completes the transaction by scanning this code.

[0025] During a payment cycle, whenever the client generates a payment code, its initial payment status is recorded in the client's memory. A payment cycle can refer to the period from when the client displays a payment code to when the client exits the display process. In other words, as long as a payment code is displayed on the client, its initial payment status is recorded. When the client exits the display process, it deletes all recorded payment codes.

[0026] A polling manager can be configured in the client to store the first payment status of payment codes and manage the stored payment codes. Whenever the client generates a new payment code, it stores the first payment status of the payment code in the polling manager, using the code value as the key and the first payment status as the value.

[0027] It is worth noting that in this embodiment of the disclosure, the first payment status refers to the payment status recorded in the client by the payment code. Under different circumstances, the first payment status can be different payment statuses.

[0028] In this embodiment, the payment status of the payment code may include an initial state, a processing state, a payment in progress state, a pull to cashier state, a pull to payment success result page state, and a cancellation state. The initial state indicates that the payment code has not yet been scanned by the merchant or payment terminal; the processing state indicates that the server has begun two-stage decoding of the payment code; the payment in progress state indicates that the server has created a payment order for the payment code; the pull to cashier state indicates that the client is notified to display the cashier for payment verification; the pull to payment success result page state indicates that the client is notified to display a result page indicating that the payment order corresponding to the payment code has been successfully paid; and the cancellation state indicates that the transaction corresponding to the payment code has been cancelled. It should be noted that a payment code in the cancellation state means that the server cancels the payment order for the payment code, thereby cancelling the transaction corresponding to the payment code.

[0029] In step 120, the second payment status of the payment code is obtained from the server.

[0030] Here, after the payment terminal scans the payment code, the server performs a series of operations to process the payment request and complete the transaction. For example, the server can perform operations such as verifying the payment request, generating a payment order, performing a risk check on the payment order, deducting the corresponding amount from the account after the risk check passes, sending a payment result notification, and canceling the payment order. When the server performs a specific operation on the payment order corresponding to the payment code, the payment status of that payment code will also change accordingly.

[0031] It's worth noting that the second payment status refers to the payment status of the payment code obtained by the client from the server, which is different from the first payment status of the payment code stored on the client. For example, the first payment status of payment code A stored on the client can be the initial state, while the second payment status of payment code A on the server is the "processing" state.

[0032] The second payment state in which the client obtains the payment code from the server can be either the second payment state in which the client actively pulls the payment code from the server, or the second payment state in which the client passively receives the payment code pushed by the server.

[0033] For example, the client receives the second payment status of the payment code pushed by the server through a long connection with the server.

[0034] It should be understood that after the client receives the second payment status of the payment code, the client's polling manager will determine whether the received payment code has been recorded in the client's polling manager. If the payment code is not recorded in the client's polling manager, it is discarded; if the payment code is recorded in the client's polling manager, subsequent steps are executed. It should be noted that if the payment code is not recorded in the polling manager, it means that the payment code is not a payment code for the current payment cycle, but an expired payment code, and therefore needs to be discarded.

[0035] For example, the client can actively query the second payment status of the payment code from the server based on the code value recorded by the polling manager.

[0036] In step 130, for each payment code recorded by the client, when the second payment status of the payment code changes relative to the first payment status, the payment code is identified as the first payment code whose payment status has changed, and the first payment status corresponding to the first payment code is updated to the second payment status.

[0037] Here, during a payment cycle, the client may record one or more payment codes. Therefore, the second payment status of the payment code obtained from the server can be the second payment status of one or more payment codes.

[0038] For each payment code recorded by the polling manager, the polling manager compares the second payment status of the obtained payment code with the first payment status of the recorded payment code to determine whether the payment status of the payment code has changed.

[0039] When the second payment status of a payment code changes relative to the first payment status, the polling manager can identify the payment code as the first payment code whose payment status has changed, and update the first payment status corresponding to the first payment code to the second payment status.

[0040] For example, if the first payment status of payment code A recorded in the polling manager is "initial," and the second payment status of payment code A obtained from the server is "processing," then payment code A will be the first payment code whose payment status has changed. Simultaneously, the polling manager will update the recorded payment status of payment code A from "initial" to "processing."

[0041] For example, if the first payment status of payment code B recorded in the polling manager is the initial status, and the second payment status of payment code B obtained from the server is also the initial status, then payment code B will not be identified as the first payment code whose payment status has changed, and the payment status of payment code B stored in the polling manager will remain as the initial status.

[0042] It is worth noting that, in this embodiment of the disclosure, the first payment code refers to a type of payment code that indicates a change in payment status, determined by comparing a first payment status and a second payment status. During a single polling process, the number of codes identified as first payment codes can be one or more. Furthermore, by updating the first payment status of the first payment code to a second payment status, after obtaining the second payment status of the payment code the next time, the above steps can still be used to determine whether the payment status of the payment code has changed.

[0043] In step 140, the target interactive action is determined based on the second payment status of the first payment code.

[0044] Here, since the payment status of the first payment code has changed—that is, from the first payment status to the second payment status—the target interactive action to be output by the client can be determined based on the second payment status of the first payment code. For example, different payment statuses can correspond to different interactive actions. For instance, the interactive action corresponding to the "pull cashier" status is to display the cashier. The interactive action corresponding to the "pull payment success result page" status is to display a result page indicating that the payment order corresponding to the payment code has been successfully paid.

[0045] In some embodiments, if there are multiple first payment codes, the target interaction action can be determined based on the second payment state with the highest priority among the multiple first payment codes.

[0046] In this embodiment, the priority of payment status is as follows: payment success result page status > cashier status > order cancellation status > processing status > initial status. If the second payment status of the first payment code A is processing status, the second payment status of the first payment code B is cashier status, and the second payment status of the first payment code C is payment success result page status, then the target interaction action is determined based on the second payment status of the first payment code C.

[0047] It should be understood that determining the target interaction action by considering the second payment state with the highest priority among multiple first payment codes is essentially integrating the multi-dimensional payment states into a one-dimensional interaction action to display to the user.

[0048] It is worth noting that, in this embodiment of the disclosure, the interactive action can be an action in a front-end interface to display a specific page in order to show the user the corresponding payment information and interactive behavior.

[0049] In this embodiment, when the polling manager determines that the payment status of any payment code has changed, it can send a payment status update event to the payment status processor. This payment status update event includes a first payment code and its corresponding second payment status. The payment status processor responds to the payment status update event and determines the target interaction action based on the second payment status with the highest priority among the second payment statuses of the first payment code in the payment status update event. Payment status update events for lower-priority second payment statuses are discarded to ensure that the user always sees the most important information and interaction actions.

[0050] In step 150, the target interactive action is performed.

[0051] Here, after identifying the target interaction action, the client executes that action to display the corresponding page. For example, if the second payment state of the payment code is "pull cashier," and the identified target interaction action is "display cashier," then the client executes the target interaction action to display the cashier.

[0052] Therefore, by recording the first payment status of the payment code in the client when it is generated, and obtaining the second payment status of the payment code from the server, for each payment code recorded by the client, when the second payment status of the payment code changes relative to the first payment status, the payment code is identified as the first payment code whose payment status has changed, and the first payment status corresponding to the first payment code is updated to the second payment status. Then, based on the second payment status of the first payment code, the target interaction action is determined and executed, so that the client can perceive the change in the payment status of the payment code displayed before the currently displayed payment code, thereby supporting the scanning of multiple payment codes and ensuring that users can use payment codes for scanning payments under any circumstances.

[0053] In some scenarios, the first payment code generated by the client is scanned by the payment terminal, and this first payment code is in the payment process. If the waiting time is too long and the client does not realize that the first payment code is in the payment process, the client will periodically refresh and display the second payment code. At this time, in related technologies, the client will no longer perceive the payment status of the first payment code. If the payment order corresponding to the first payment code requires displaying the cashier for identity verification before deduction, the client will not be able to respond to the cashier display operation, resulting in payment failure. Through the QR code payment method provided in this disclosure embodiment, the client can perceive the change in the payment status of the first and second payment codes and execute the corresponding interactive actions, so that users can still use payment codes to make payments normally even in extreme cases, greatly ensuring the user experience of using QR code payment.

[0054] In some feasible implementations, in step 130, when the second payment status of the payment code changes relative to the first payment status, if the second payment status of the payment code is not a cancellation status indicating that the transaction corresponding to the payment code has been cancelled, then the payment code is determined as the first payment code, and the first payment status of the first payment code is updated to the second payment status.

[0055] Here, the polling manager compares the priority of the second payment status of the payment code with the priority of the first payment status. When the priority of the second payment status is greater than the priority of the first payment status, it determines that the payment status of the payment code has changed. Then, the polling manager determines whether the second payment status of the payment code is a cancellation status, indicating that the transaction corresponding to the payment code has been cancelled. If the second payment status of the payment code is not a cancellation status, then the payment code is designated as the first payment code.

[0056] It should be noted that if the second payment status of the payment code obtained from the server is a cancellation status, it means that the payment order corresponding to the payment code has been cancelled. If the second payment status of the payment code obtained from the server is not a cancellation status, it means that the payment order corresponding to the payment code is still being processed.

[0057] If the second payment code whose second payment status has changed relative to the first payment status is not a cancellation status, then the payment code is identified as the first payment code, and the first payment status stored in the polling manager is updated to the second payment status.

[0058] It is worth noting that when the priority of the second payment status is less than or equal to the priority of the first payment status of the payment code, it is determined that the payment status of the payment code has not changed. In this case, the payment code can be left unprocessed, and the polling manager will continue to poll for the next payment code.

[0059] Therefore, through the above implementation method, the client can avoid responding to the interaction of the payment code in the cancellation state, so as to ensure the smooth progress of QR code payment.

[0060] In some feasible implementations, if the second payment status of the payment code is a cancellation status, the payment code is deleted from the client's record, and a second payment code is determined from the payment codes recorded by the client. The second payment code is the payment code with the highest priority corresponding to the first payment status recorded by the client. Accordingly, step 150 may be to determine the target interaction action based on the second payment status of the first payment code and the first payment status of the second payment code.

[0061] Here, the polling manager compares the priority of the second payment status of the payment code with the priority of the first payment status. When the priority of the second payment status is greater than the priority of the first payment status, it determines that the payment status of the payment code has changed. Furthermore, the polling manager determines whether the second payment status of the payment code is a cancellation status, indicating that the transaction corresponding to the payment code has been cancelled. If the second payment status of the payment code is a cancellation status, it means that the payment order corresponding to the payment code has been cancelled, and the lifecycle of the payment code has ended.

[0062] At this point, the payment code in the cancelled state can be deleted from the polling manager's record, and its payment status will no longer be monitored. Furthermore, since the client may continue to display interactive actions related to the cancelled payment code, a second payment code can be determined from the payment codes recorded in the client's polling manager to prevent further display of such actions. The client's interactive actions can then be refreshed based on the first payment status of this second payment code.

[0063] The second payment code is the highest priority payment code corresponding to the first payment status recorded by the client. It's worth noting that since payment codes in a cancelled state have been deleted from the polling manager, the second payment code determined from the polling manager will not be a payment code in a cancelled state.

[0064] For example, if the second payment status of the payment code is a cancellation status, the polling manager deletes the payment code with the cancellation status from the client's records, determines the second payment code from the payment codes recorded by the polling manager, and then generates an end event based on the first payment status of the second payment code. The end event is then passed to the payment status processor. In response to receiving the end event, the payment status processor determines the target interaction action based on the first payment status of the second payment code in the end event and the second payment status of the first payment code in the payment status update event.

[0065] It should be understood that if the payment status processor does not receive a payment status update event, the target interaction action can be determined based on the first payment status of the second payment code in the end event.

[0066] In some embodiments, the payment state with the highest priority among the second payment state of the first payment code and the first payment state of the second payment code can be determined as the target payment state, and then the target interaction action can be determined based on the target payment state.

[0067] In some embodiments, if the target payment state is the second payment state of the first payment code, and the priority corresponding to the target payment state is greater than or equal to the priority of the payment state corresponding to the interaction action being performed by the client, then the target interaction action is determined based on the target payment state; if the target payment state is the first payment state of the second payment code, then the target interaction action is determined based on the target payment state.

[0068] Specifically, if the target payment status is the second payment status of the first payment code, the priority of this second payment status is compared with the priority of the payment status corresponding to the currently executing interaction action of the client. If the priority of the second payment status is greater than or equal to the priority of the payment status corresponding to the currently executing interaction action of the client, the target interaction action is determined based on the second payment status. If the determined target payment status is the first payment status of the second payment code, the target interaction action of the first payment status is executed directly.

[0069] It is worth noting that if the determined target payment status is the first payment status of the second payment code, the priority of the currently executed interaction action of the client may be higher than the priority of the first payment status of the second payment code, and the payment code corresponding to the currently executed interaction action of the client may be in a cancelled state. In order to refresh the client's interaction action, when the determined target payment status is the first payment status of the second payment code, the target interaction action corresponding to the first payment status of the second payment code can be executed directly to ensure that the client can display the interaction action of the payment code that is not in a cancelled state.

[0070] Therefore, through the above implementation method, the corresponding interactive action can be determined according to the different payment statuses of the payment code, thereby ensuring the smooth progress of QR code payment.

[0071] In some feasible implementations, a new payment code is displayed if the payment code currently displayed on the client is in a cancelled state.

[0072] Here, the polling manager compares the priority of the second payment status of the payment code with the priority of the first payment status. When the priority of the second payment status is greater than that of the first payment status, it determines that the payment status of the payment code has changed. Furthermore, the polling manager determines whether the second payment status of the payment code is a cancellation status, indicating that the transaction corresponding to the payment code has been cancelled. If the second payment status is a cancellation status, the payment code in the cancellation status can be deleted from the polling manager's record, and its payment status will no longer be detected. Moreover, since the client may continue to display interactive actions with the payment code in the cancellation status, the second payment code can be determined from the payment codes recorded in the client's polling manager to prevent the client from continuing to display such actions. Additionally, the polling manager can also determine whether the payment code currently displayed by the client is in the cancellation status. If so, the client displays the new payment code.

[0073] It should be understood that if the payment code currently displayed by the client is a payment code in a cancelled state, since the payment code is in a cancelled state, it means that the life cycle of the payment code has ended, and it is meaningless to continue displaying the payment code. Therefore, the client can display a new payment code.

[0074] It is worth noting that the first payment status corresponding to the displayed new payment code will also be recorded in the polling manager so that the payment status of the new payment code can be monitored in subsequent processes.

[0075] Therefore, through the above implementation method, when it is detected that the payment status of the payment code currently displayed on the client is in the order cancellation state, a new payment code can be refreshed and displayed to ensure the smooth progress of QR code payment.

[0076] In some feasible implementations, when the first payment code is the payment code currently displayed by the client and the second payment status of the first payment code indicates that the first payment code has entered the payment processing flow, the periodic display of new payment codes is stopped.

[0077] Here, the polling manager compares the priority of the second payment status of the payment code with the priority of the first payment status. When the priority of the second payment status is greater than the priority of the first payment status, it determines that the payment status of the payment code has changed, and the payment code becomes the first payment code. Then, the polling manager determines whether the first payment code is the payment code currently displayed on the client. If the first payment code is the payment code currently displayed on the client, and the second payment status of the first payment code indicates that the first payment code has entered the payment processing flow, then it controls the client to stop periodically displaying new payment codes.

[0078] The second payment status of the first payment code indicates that the first payment code has entered the payment processing flow. This means that the second payment status of the first payment code is in a state other than the initial state, indicating that the first payment code has generated a payment order and entered the processing stage. For example, the second payment status of the first payment code may be the status of pulling the payment success result page, pulling the cashier, order cancellation, or processing.

[0079] If the first payment code is the payment code currently displayed on the client, and the second payment status of the first payment code indicates that the first payment code has entered the payment processing flow, the payment code currently displayed on the client is actually already in the payment processing flow, and there is no need to display a new payment code. Therefore, the client can be controlled to stop periodically displaying a new payment code to avoid generating multiple payment orders.

[0080] Therefore, by implementing the above methods, multiple payment orders can be avoided, ensuring the orderly conduct of QR code payments and preventing duplicate payments.

[0081] In some feasible implementations, in step 130, it can be determined whether the payment code meets the first preset condition based on the second payment state and the first payment state of the payment code. If the payment code does not meet the first preset condition, if the second payment state of the payment code changes relative to the first payment state, the payment code is determined as the first payment code whose payment state has changed, and the first payment state corresponding to the first payment code is updated to the second payment state.

[0082] Here, after the polling manager obtains the second payment status of the payment code from the server, it determines whether the payment code meets the first preset condition based on the second payment status and the first payment status of the payment code for each payment code. If the payment code does not meet the first preset condition, the second payment status of the payment code is compared with the first payment status. If the second payment status of the payment code changes relative to the first payment status, the payment code is identified as the first payment code whose payment status has changed, and the first payment status corresponding to the first payment code is updated to the second payment status.

[0083] The first preset condition is that the first payment status and the second payment status represent the process where the payment code enters the payment processing flow and the payment code is not updated from the payment processing flow to the page displaying the payment result within the first preset time period.

[0084] The process of updating from the payment processing flow to the payment result display page indicates that the payment code has entered the final payment state and is at the end of its lifecycle. If the payment code does not update from the payment processing flow to the payment result display page within the first preset time period, it indicates that the payment code has encountered a payment timeout error.

[0085] For example, if a payment code's first payment status is "processing" (indicating the payment code has entered the payment processing flow), payment may encounter problems in environments with no network or a weak network. If, within 60 seconds (a first preset timeout), the payment code's second payment status does not reach any of the following states: payment success result page, checkout page, or order cancellation, then the payment code has experienced a payment timeout error. Therefore, a payment code that meets the first preset condition can actually be considered a payment code that has experienced a payment timeout error.

[0086] In other words, judging whether a payment code meets the first preset condition based on its second payment status and first payment status can be understood as judging whether a payment code has encountered a payment timeout error. If a payment timeout error occurs, then the payment code does not need to undergo a further judgment on payment status change.

[0087] If the payment code does not meet the first preset condition, it means that the payment code has not experienced a payment timeout error. Then, the polling manager further determines whether the second payment status of the payment code has changed relative to the first payment status of the payment code.

[0088] In some feasible implementations, if the payment code meets the first preset condition, the payment code is identified as the third payment code. Accordingly, in step 140, the target interactive action is determined based on the second payment status of the first payment code and the third payment status of the third payment code.

[0089] It is worth noting that a third payment code refers to a type of payment code that indicates a payment timeout error, determined based on a first preset condition. During a single polling process, one or more third payment codes can be identified.

[0090] For a payment code that meets the first preset condition, the polling manager identifies the payment code as the third payment code and assigns the third payment status to the third payment code.

[0091] The third payment status is the payment status corresponding to the first preset condition, and the interactive action corresponding to the third payment status is to display the fallback result page.

[0092] It's important to note that the third payment status is not the payment status of the payment code obtained from the server, but rather a payment status assigned by the client to a payment code that meets the first preset condition. For example, the third payment status could be a fallback result page status, and the corresponding interactive action could be displaying a fallback result page to inform the user that the payment code's payment has encountered an error, prompting the user to check whether the payment order for that payment code was successfully completed.

[0093] The payment status processor determines the target interaction action based on the second payment status of the first payment code and the third payment status of the third payment code.

[0094] For example, the payment status processor can determine the target interaction action based on the payment status with the highest priority among the second payment status of the first payment code and the third payment status of the third payment code.

[0095] In this embodiment of the disclosure, the priority of the payment status is as follows: payment success result page status = fallback result page status > cashier status > order cancellation status > processing status > initial status.

[0096] It's worth noting that if no payment status update event exists at this time, the target interaction action can be determined based on the third payment status of the third payment code. Alternatively, if an end event exists, the payment status processor can determine the target interaction action based on the highest priority payment status among the second payment status of the first payment code, the third payment status of the third payment code, and the first payment status of the second payment code, ensuring that the user always sees the most important information and interactions.

[0097] Therefore, through the above implementation method, the client can detect the payment code that meets the first preset condition and display the corresponding target interactive action so that the user can understand the payment order that has timed out.

[0098] In some feasible implementations, the client can also delete payment codes whose first payment status meets the second preset condition from the client's records. The second preset condition includes the first payment status of the payment code representing the process of the payment code entering the payment result display page, or the second preset condition includes the first payment status of the payment code being an initial state and the payment code maintaining the initial state for a second preset duration.

[0099] Here, the process of the payment code entering the payment result page indicates that the payment code has entered the final payment state and is in the end-of-life stage. For example, when the first payment state changes to any of the following states: payment success result page, cashier, or order cancellation, it means that the payment code has entered the process of displaying the payment result page.

[0100] Since the payment code has entered the final payment state, and the final payment result (payment success / payment failure) can be determined by the payment code, there is no need to continue monitoring the payment status of the payment code. Therefore, payment codes whose first payment status meets the second preset condition can be deleted from the payment codes recorded by the polling manager.

[0101] If the first payment status is the initial state and the payment code remains in the initial state for a second preset time, it means that the payment code has been in the initial state for the second preset time. In this case, the payment code has timed out and the client does not need to continue to perceive the payment status of the payment code.

[0102] For example, when the first payment status of the payment code is the initial status, if the second payment status obtained from the server within 120 seconds (the second preset duration) indicates that the payment status of the payment code has remained in the initial status and has not entered a payment status with a priority greater than or equal to that of the processing status, then the payment code satisfies the second preset condition.

[0103] When any payment code meets the second preset condition, the polling manager deletes the payment code whose first payment status meets the second preset condition from the polling manager's records, and will no longer detect any further changes in the payment status of that payment code.

[0104] Therefore, through the above implementation method, the client can be unaware of the payment status of a payment code that has timed out or has reached its final state, which can reduce the client's computational load and ensure that the payment code scanning payment can be carried out smoothly.

[0105] In some feasible implementations, in step 150, if the target interaction action is to display the cashier, the target interaction action is discarded if the client is currently displaying the cashier, and executed if the client is not currently displaying the cashier; if the target interaction action is to display the payment result page, the target interaction action is discarded if the client is currently displaying the cashier, and executed if the client is not currently displaying the cashier.

[0106] Here, when the determined target interaction action is to display the checkout counter, it checks whether the client is currently displaying the checkout counter. If the client is currently displaying the checkout counter, the target interaction action is discarded and not executed. If the client is not currently displaying the checkout counter, the client executes the target interaction action and displays the checkout counter.

[0107] In some embodiments, when the cashier is displayed, in response to a successful payment operation for the cashier, the display of the payment code is exited and the payment code recorded on the client is deleted.

[0108] In this context, a successful payment operation at the checkout counter can refer to the user completing payment verification through the displayed checkout counter, enabling the payment order corresponding to the payment code to be completed.

[0109] In this scenario, once the payment code payment is completed within a payment cycle, the client can exit the user interface displaying the payment code and delete the payment code recorded in the polling manager.

[0110] When the determined target interaction action is to display the payment result page, it checks whether the client is currently displaying the checkout. If the client is currently displaying the checkout, the target interaction action of displaying the payment result page is discarded and will not be executed. If the client is not currently displaying the checkout, the client executes the target interaction action and displays the payment result page.

[0111] It should be noted that the payment result page can be either the fallback result page corresponding to the fallback result page status or the payment success result page corresponding to the payment success result page status.

[0112] In some embodiments, when displaying the payment results page, the display of the payment code can be exited and the payment code recorded on the client can be deleted in response to the end of the display of the payment results page.

[0113] The end of the payment result page display can refer to the payment result page being displayed for a preset duration, or a trigger action to exit the display of the payment result page being detected.

[0114] In this scenario, once the payment code payment is completed within a payment cycle, the client can exit the user interface displaying the payment code and delete the payment code recorded in the polling manager.

[0115] It should be understood that if the target interactive action is not to display the cashier or the payment result page, the target interactive action will be displayed through a preset interactive display logic, which is not specifically limited in this embodiment.

[0116] Therefore, the above implementation method can ensure the orderly execution of interactive actions, so as to ensure that users can always see the most important payment information and interactive actions.

[0117] In some feasible implementations, when the target interaction action is to display the cashier, in step 150, the cashier can be displayed, and in response to the payment cancellation operation for the cashier, the payment code corresponding to the target interaction action is deleted from the client's record. Then, the first payment status with the highest priority is selected from the payment codes recorded by the client, and a new target interaction action is determined based on the selected first payment status and executed.

[0118] Here, when displaying the checkout, if a successful payment operation is detected, the payment code is not displayed, and the payment code is deleted from the client's record. If a payment cancellation operation is detected, the payment code corresponding to the target interaction is deleted from the client's record.

[0119] Specifically, the payment cancellation operation at the checkout can be an action triggered by the user within the displayed checkout area to indicate payment cancellation. For example, the payment cancellation operation could be exiting the displayed checkout area.

[0120] It's important to note that when a payment cancellation operation is detected at the checkout, it means the corresponding payment code's payment order has been cancelled by the user. Subsequent detection of the payment code's payment status has become invalid. Therefore, the payment code corresponding to the target interaction action can be deleted from the polling manager's record, and no further changes to its payment status will be detected. Furthermore, since the payment order for this code has been cancelled, the client still needs to display interactions for other payment codes. Therefore, the client can select the highest priority first payment status from the payment codes recorded in the client's database, determine the new target interaction action based on the selected first payment status, and then execute the new target interaction action. It's worth noting that because the payment code corresponding to the payment cancellation operation has been deleted from the polling manager's record, the highest priority first payment status selected from the polling manager will not be the payment code corresponding to the payment code corresponding to the payment cancellation operation.

[0121] It should be understood that by selecting the highest-priority first payment state from the payment codes recorded by the client, and determining a new target interaction action based on the selected first payment state, the interaction actions executed by the client can be refreshed through the new target interaction action. Moreover, since the selected first payment state is the highest-priority first payment state, it also ensures that the most important information and interaction actions are displayed to the user.

[0122] In some embodiments, in response to a payment cancellation operation at the checkout, the payment code corresponding to the target interaction is deleted from the client's record, and if the payment code corresponding to the target interaction is the payment code currently displayed by the client, a new payment code is displayed.

[0123] If the payment code currently displayed by the client is the payment code corresponding to the payment cancellation operation, it is meaningless to continue displaying the payment code since the payment order of the payment code has been cancelled by the user. Therefore, the client can display a new payment code.

[0124] It should be noted that the first payment status corresponding to the displayed new payment code will also be recorded in the polling manager so that the payment status of the new payment code can be monitored in subsequent processes.

[0125] In this embodiment of the disclosure, the operations for payment codes in the order cancellation state and payment codes corresponding to payment cancellation operations are actually the same: the corresponding payment code is deleted from the client's record, a new payment code is displayed if the corresponding payment code is the payment code currently displayed on the client, and the first payment state with the highest priority is selected from the payment codes recorded on the client, and a new target interaction action is determined based on the selected first payment state.

[0126] Therefore, through the above implementation method, even after the payment order corresponding to the payment code is cancelled by the user, the client can still display other more important interactive actions and refresh to display a new payment code, so as to ensure the smooth progress of QR code payment.

[0127] Figure 2 This is a flowchart illustrating a QR code payment method according to other embodiments. For example... Figure 2 As shown, the QR code payment method may include the following steps.

[0128] When a payment code is generated, its initial payment status is recorded in the polling manager. Subsequently, the client receives the second payment status of the payment code pushed by the server and checks whether the payment code is in the polling manager. If it is, the client processes the payment status for that code. Furthermore, the client retrieves the second payment status of the payment code from the server and processes the retrieved payment status.

[0129] Payment status processing may include the following steps: For each payment code, the polling manager determines whether it meets a first preset condition based on its second and first payment states. If the first preset condition is met, the payment code is designated as the third payment code, and the payment state handler is notified to process the event (the target interaction action is determined based on the third payment state of the third payment code). If the first preset condition is not met, the manager checks whether the payment code meets a second preset condition. If the second preset condition is met, the payment code is deleted from the polling manager. If the second preset condition is not met, the manager checks whether the payment state has changed. If the payment state has not changed, the polling manager processes the next payment code. If the payment state has changed, the manager checks whether the payment code with the changed payment state is the currently displayed payment code and whether the payment code has entered the payment processing flow. If the payment code with the changed payment state is the currently displayed payment code and the payment code has entered the payment processing flow, the periodic display of new payment codes is stopped. Simultaneously, when the payment status changes, it is determined whether the second payment status of the payment code is a cancellation status. If it is a cancellation status, code termination processing is executed; otherwise, a payment status update event is generated, and the first payment status of the payment code is updated. Code termination processing may include the following steps: The system checks if the payment code is the currently displayed payment code. If so, it displays a new payment code. It also deletes the payment code from the polling manager. Furthermore, it generates an end event based on the payment code with the highest payment status and sends it to the payment status processor. The payment status processor handles the event, determining the highest priority payment status from all received payment codes and identifying the target interaction action based on that. It checks if the payment status corresponding to the target interaction action is an end event. If so, it executes the target interaction action directly. If not, it further checks if the priority of the target interaction action's payment status is higher than the priority of the currently executed interaction action's payment status. If not, it discards the event corresponding to the target interaction action; otherwise, it executes the target interaction action.

[0130] When executing the target interaction action, determine if the target interaction action is to display the cashier. If so, determine if the cashier is currently being displayed. If so, discard the target interaction action; otherwise, display the cashier. When displaying the cashier, determine if the payment was successful. If successful, exit the display of the payment code; otherwise, terminate the code processing.

[0131] If the target interaction action is not to display the cashier, then determine whether to display the payment result page. If so, then determine whether the cashier is currently being displayed. If so, discard the target interaction action. If not, display the payment result page and exit the display of the payment code when the display ends.

[0132] Figure 3 This is a schematic diagram of the structure of a QR code payment device according to some embodiments. For example... Figure 3 As shown, this embodiment of the disclosure provides a QR code payment device 300, which may include: The recording module 301 is configured to record the first payment status of the payment code in the client when the client generates the payment code; The acquisition module 302 is configured to obtain the second payment status of the payment code from the server; The first determining module 303 is configured to, for each payment code recorded by the client, when the second payment status of the payment code changes relative to the first payment status, determine the payment code as the first payment code whose payment status has changed, and update the first payment status corresponding to the first payment code to the second payment status; The second determining module 304 is configured to determine the target interactive action based on the second payment status of the first payment code; The execution module 305 is configured to execute the target interactive action.

[0133] Optionally, the first determining module 303 is specifically configured as follows: When the second payment status of the payment code changes relative to the first payment status, if the second payment status of the payment code is not a cancellation status indicating that the transaction corresponding to the payment code has been cancelled, then the payment code is determined as the first payment code, and the first payment status of the first payment code is updated to the second payment status.

[0134] Optionally, the first determining module 303 is further configured to: If the second payment status of the payment code is the order cancellation status, the payment code is deleted from the client's record, and a second payment code is determined from the payment codes recorded by the client. The second payment code is the payment code with the highest priority corresponding to the first payment status recorded by the client. The second determining module 304 is specifically configured as follows: The target interactive action is determined based on the second payment status of the first payment code and the first payment status of the second payment code.

[0135] Optionally, the second determining module 304 is specifically configured as follows: The payment status with the highest priority among the second payment status of the first payment code and the first payment status of the second payment code is determined as the target payment status. The target interaction action is determined based on the target payment status.

[0136] Optionally, the second determining module 304 is specifically configured as follows: If the target payment status is the second payment status of the first payment code, and the priority corresponding to the target payment status is greater than or equal to the priority of the payment status corresponding to the interaction action being performed by the client, then the target interaction action is determined based on the target payment status. If the target payment status is the first payment status of the second payment code, the target interaction action is determined based on the target payment status.

[0137] Optionally, the QR code payment device 300 further includes: The first display module is configured to display a new payment code when the payment code currently displayed on the client is the payment code in the cancelled state.

[0138] Optionally, the QR code payment device 300 further includes: The second display module is configured to stop periodically displaying new payment codes when the first payment code is the payment code currently displayed by the client and the second payment status of the first payment code indicates that the first payment code has entered the payment processing flow.

[0139] Optionally, the first determining module 303 is specifically configured as follows: Based on the second payment status and the first payment status of the payment code, it is determined whether the payment code meets the first preset condition. The first preset condition is that the first payment status and the second payment status represent the process of the payment code entering the payment processing flow and the payment code not being updated from the payment processing flow to the payment result display page within a first preset time period. If the payment code does not meet the first preset condition, and the second payment status of the payment code changes relative to the first payment status, the payment code is identified as the first payment code whose payment status has changed, and the first payment status corresponding to the first payment code is updated to the second payment status.

[0140] Optionally, the first determining module 303 is further configured to: If the payment code meets the first preset condition, the payment code will be identified as the third payment code. The second determining module 304 is specifically configured as follows: Based on the second payment status of the first payment code and the third payment status of the third payment code, a target interactive action is determined, wherein the third payment status is the payment status corresponding to the first preset condition, and the interactive action corresponding to the third payment status is to display the fallback result page.

[0141] Optionally, the QR code payment device 300 further includes: The deletion module is configured to delete payment codes whose first payment status meets a second preset condition from the client's records. The second preset condition includes the first payment status of the payment code representing the process of the payment code entering the payment result display page, or the second preset condition includes the first payment status of the payment code being an initial state and the payment code maintaining the initial state for a second preset duration.

[0142] Optionally, the execution module 305 is specifically configured as follows: If the target interaction action is to display the cashier, and the client is currently displaying the cashier, then the target interaction action is discarded; if the client is not displaying the cashier, then the target interaction action is executed. If the target interaction action is to display the payment result page, and the client is currently displaying the cashier, then the target interaction action is discarded; if the client is not displaying the cashier, then the target interaction action is executed.

[0143] Optionally, the execution module 305 is further configured to: In response to a successful payment at the cashier, the display of the payment code is exited, and the payment code recorded on the client is deleted; or In response to the end of the display of the payment result page, the payment code is displayed and the payment code recorded in the client is deleted.

[0144] Optionally, the target interactive action includes displaying the cash register, and the execution module 305 is specifically configured to: Show the cashier; In response to a payment cancellation operation at the cashier, the payment code corresponding to the target interaction action is deleted from the client's record; Select the highest priority first payment status from the payment codes recorded by the client, and determine a new target interaction action based on the selected first payment status; Perform the new target interaction action.

[0145] Optionally, the execution module 305 is specifically configured as follows: In response to a payment cancellation operation at the cashier, the payment code corresponding to the target interaction action is deleted from the client's record, and if the payment code corresponding to the target interaction action is the payment code currently displayed by the client, a new payment code is displayed.

[0146] The logic of the methods executed by each functional module in the above-mentioned QR code payment device 300 can be referred to the relevant method section of the above embodiment, and will not be repeated here.

[0147] The following is for reference. Figure 4 The diagram illustrates a structural schematic of an electronic device (e.g., a client) 400 suitable for implementing embodiments of the present disclosure. The client in the embodiments of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0148] like Figure 4 As shown, electronic device 400 may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 401, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 402 or a program loaded from storage device 408 into random access memory (RAM) 403. RAM 403 also stores various programs and data required for the operation of electronic device 400. Processing device 401, ROM 402, and RAM 403 are interconnected via bus 404. Input / output (I / O) interface 404 is also connected to bus 404.

[0149] Typically, the following devices can be connected to I / O interface 405: input devices 406 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 408 including, for example, magnetic tapes, hard disks, etc.; and communication devices 409. Communication device 409 allows electronic device 400 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 An electronic device 400 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0150] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 409, or installed from storage device 408, or installed from ROM 402. When the computer program is executed by processing device 401, it performs the functions defined in the methods of embodiments of this disclosure.

[0151] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0152] In some implementations, the client and server can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol), and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0153] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0154] The aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: record a first payment status of the payment code in the client when the payment code is generated on the client side; obtain a second payment status of the payment code from the server; for each payment code recorded on the client side, when the second payment status of the payment code changes relative to the first payment status, determine the payment code as the first payment code whose payment status has changed, and update the first payment status corresponding to the first payment code to the second payment status; determine a target interactive action based on the second payment status of the first payment code; and execute the target interactive action.

[0155] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can 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 can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0156] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0157] The modules described in the embodiments of this disclosure can be implemented in software or hardware. The names of the modules are not, in some cases, intended to limit the functionality of the module itself.

[0158] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0159] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0160] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0161] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0162] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative forms of implementing the claims. Regarding the apparatus in the above embodiments, the specific manner in which the various modules perform their operations has been described in detail in the embodiments relating to the method, and will not be elaborated upon here.

Claims

1. A QR code payment method, characterized in that, include: When the payment code is generated on the client side, the first payment status of the payment code is recorded in the client side. Obtain the second payment status of the payment code from the server; For each payment code recorded by the client, when the second payment status of the payment code changes relative to the first payment status, the payment code is identified as the first payment code whose payment status has changed, and the first payment status corresponding to the first payment code is updated to the second payment status. Based on the second payment status of the first payment code, determine the target interactive action; Perform the target interactive action.

2. The method according to claim 1, characterized in that, When the second payment status of the payment code changes relative to the first payment status, determining the payment code as the first payment code and updating the first payment status corresponding to the first payment code to the second payment status includes: When the second payment status of the payment code changes relative to the first payment status, if the second payment status of the payment code is not a cancellation status indicating that the transaction corresponding to the payment code has been cancelled, then the payment code is determined as the first payment code, and the first payment status of the first payment code is updated to the second payment status.

3. The method according to claim 2, characterized in that, The method further includes: If the second payment status of the payment code is the order cancellation status, the payment code is deleted from the client's record, and a second payment code is determined from the payment codes recorded by the client. The second payment code is the payment code with the highest priority corresponding to the first payment status recorded by the client. The step of determining the target interactive action based on the second payment status of the first payment code includes: The target interactive action is determined based on the second payment status of the first payment code and the first payment status of the second payment code.

4. The method according to claim 3, characterized in that, Determining the target interactive action based on the second payment status of the first payment code and the first payment status of the second payment code includes: The payment status with the highest priority among the second payment status of the first payment code and the first payment status of the second payment code is determined as the target payment status. The target interaction action is determined based on the target payment status.

5. The method according to claim 4, characterized in that, Determining the target interaction action based on the target payment status includes: If the target payment status is the second payment status of the first payment code, and the priority corresponding to the target payment status is greater than or equal to the priority of the payment status corresponding to the interaction action being performed by the client, then the target interaction action is determined based on the target payment status. If the target payment status is the first payment status of the second payment code, the target interaction action is determined based on the target payment status.

6. The method according to claim 3, characterized in that, The method further includes: If the payment code currently displayed on the client is the payment code in the cancelled state, a new payment code will be displayed.

7. The method according to claim 1, characterized in that, The method further includes: When the first payment code is the payment code currently displayed by the client, and the second payment status of the first payment code indicates that the first payment code has entered the payment processing flow, the periodic display of new payment codes shall be stopped.

8. The method according to any one of claims 1 to 7, characterized in that, When the second payment status of the payment code changes relative to the first payment status, determining the payment code as the first payment code whose payment status has changed, and updating the first payment status corresponding to the first payment code to the second payment status, includes: Based on the second payment status and the first payment status of the payment code, it is determined whether the payment code meets the first preset condition. The first preset condition is that the first payment status and the second payment status represent the process of the payment code entering the payment processing flow and the payment code not being updated from the payment processing flow to the payment result display page within a first preset time period. If the payment code does not meet the first preset condition, and the second payment status of the payment code changes relative to the first payment status, the payment code is identified as the first payment code whose payment status has changed, and the first payment status corresponding to the first payment code is updated to the second payment status.

9. The method according to claim 8, characterized in that, The method further includes: If the payment code meets the first preset condition, the payment code will be identified as the third payment code. The step of determining the target interactive action based on the second payment status of the first payment code includes: Based on the second payment status of the first payment code and the third payment status of the third payment code, a target interactive action is determined, wherein the third payment status is the payment status corresponding to the first preset condition, and the interactive action corresponding to the third payment status is to display the fallback result page.

10. The method according to any one of claims 1 to 7, characterized in that, The method further includes: Delete the payment code whose first payment status meets the second preset condition from the client's records, wherein the second preset condition includes the first payment status of the payment code representing the process of the payment code entering the payment result display page, or the second preset condition includes the first payment status of the payment code being an initial state and the payment code maintaining the initial state for a second preset duration.

11. The method according to any one of claims 1 to 7, characterized in that, The execution of the target interactive action includes: If the target interaction action is to display the cashier, and the client is currently displaying the cashier, then the target interaction action is discarded; if the client is not displaying the cashier, then the target interaction action is executed. If the target interaction action is to display the payment result page, and the client is currently displaying the cashier, then the target interaction action is discarded; if the client is not displaying the cashier, then the target interaction action is executed.

12. The method according to claim 11, characterized in that, The method further includes: In response to a successful payment at the cashier, the display of the payment code is exited, and the payment code recorded on the client is deleted; or In response to the end of the display of the payment result page, the payment code is displayed and the payment code recorded in the client is deleted.

13. The method according to any one of claims 1 to 7, characterized in that, The target interactive action includes displaying the cash register, and executing the target interactive action includes: Show the cashier; In response to a payment cancellation operation at the cashier, the payment code corresponding to the target interaction action is deleted from the client's record; Select the highest priority first payment status from the payment codes recorded by the client, and determine a new target interaction action based on the selected first payment status; Perform the new target interaction action.

14. The method according to claim 13, characterized in that, The step of deleting the payment code corresponding to the target interaction action from the client's record in response to a payment cancellation operation at the cashier includes: In response to a payment cancellation operation at the cashier, the payment code corresponding to the target interaction action is deleted from the client's record, and if the payment code corresponding to the target interaction action is the payment code currently displayed by the client, a new payment code is displayed.

15. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processing device, it implements the steps of the method according to any one of claims 1-14.

16. An electronic device, characterized in that, include: A storage device on which computer programs are stored; A processing device for executing the computer program in the storage device to implement the steps of the method according to any one of claims 1-14.

17. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-14.

Images