A payment method, device, electronic device and readable medium

Abstract

The embodiments of this specification disclose a payment method, device, electronic device and readable medium, wherein a payment method comprises: receiving a payment instruction sent by a first user by scanning an order QR code; the order QR code is generated according to a first order corresponding to a target product; the first order is generated based on a purchase operation of the target product by a second user; the first order is set to an occupied state; wherein the first order refuses to execute payment instructions of users other than the first user when the first order is in the occupied state; a second order of the first user is created according to the order identifier of the first order in the occupied state; and a payment operation is performed based on the second order.

Description

Technical Field

[0001] The present application relates to the technical field of Internet of Things, and in particular to a payment method, device, electronic device and readable medium. Background Art

[0002] Currently, if a target user generates an order QR code after purchasing a product, the target user can scan the order QR code to pay for the product order.

[0003] If the target user is unable to pay for a product due to various reasons, the order QR code corresponding to the product order can be sent to other users, and other users can scan the order QR code to make payment on behalf of the target user.

[0004] At this time, if there are multiple other users, they may pay for the order repeatedly at the same time. The other users who paid repeatedly need to wait for the system to complete the order processing and then execute the refund process. Or, when the order fails to be paid by the first user who completed the payment, the target user needs to refresh the operation. After the system refreshes the order QR code, other users can use the new order QR code to pay on their behalf.

[0005] It can be seen that with the existing payment methods, when a user makes payment on behalf of another user, before the order is successfully paid, the order QR code cannot be reused and the order QR code cannot avoid repeated payment. Summary of the invention

[0006] The embodiments of this specification provide a payment method, device, electronic device and readable medium, so as to provide a payment method that can enable the order QR code to be reused before the order is successfully paid and avoid duplicate payment when other users are required to pay for the order on behalf of the target user, thereby reducing system pressure and improving user experience.

[0007] To achieve the above purpose, the embodiments of this specification are implemented as follows:

[0008] A payment method comprising:

[0009] Receiving a payment instruction sent by a first user by scanning an order QR code; the order QR code is generated according to a first order corresponding to a target product; the first order is generated based on a purchase operation of the target product by a second user;

[0010] Setting the first order to an occupied state; wherein, when the first order is in the occupied state, refusing to execute payment instructions of users other than the first user;

[0011] creating a second order for the first user according to the order identifier of the first order in the occupied state;

[0012] A payment operation is performed based on the second order.

[0013] The embodiment of the present invention further discloses a payment device, including:

[0014] A payment device, comprising:

[0015] A receiving module, configured to receive a payment instruction sent by a first user by scanning an order QR code; the order QR code is a QR code generated according to a first order corresponding to a target product; the first order is generated based on a purchase operation of the target product by a second user;

[0016] A setting module, used to set the first order to an occupied state; wherein, when the first order is in the occupied state, payment instructions of users other than the first user are refused to be executed;

[0017] a creation module, configured to create a second order for the first user according to the order identifier of the first order in the occupied state;

[0018] A payment module is used to perform a payment operation based on the second order.

[0019] An embodiment of this specification can achieve the following beneficial effects:

[0020] In the embodiment of the present invention, firstly, a payment instruction sent by a first user by scanning an order QR code is received; the order QR code is generated according to the first order corresponding to the target product; the first order is generated based on the purchase operation of the target product by the second user; then the first order is set to an occupied state; wherein, when the first order is in the occupied state, payment instructions of users other than the first user are refused to be executed; then, a second order of the first user is created according to the order identifier of the first order in the occupied state; finally, a payment operation is performed based on the second order. It can be seen that, since the embodiment of the present invention locks the order after receiving the payment instruction, when the first user pays for the first order, other users cannot pay, and since the payment operation is performed on the second order created based on the first order, the first order is not directly processed, even if the first user fails to pay, only the second order fails to pay, and the first order is not affected, so that the order QR code can be reused, achieving the technical effect of avoiding repeated payment while ensuring that the order QR code can be reused before the first order of the target product is successfully paid. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0022] Figure 1 This is a schematic diagram of the system structure of a payment method shown in an embodiment of this specification.

[0023] Figure 2 It is a flow chart of a payment method shown in an embodiment of this specification.

[0024] Figure 3 It is another flow chart of a payment method shown in the embodiment of this specification.

[0025] Figure 4 This is another flow chart of a payment method shown in the embodiment of this specification.

[0026] Figure 5 This is another flow chart of a payment method shown in the embodiment of this specification.

[0027] Figure 6 This is another flow chart of a payment method shown in the embodiment of this specification.

[0028] Figure 7 A swim lane diagram of a payment method according to an embodiment of the present invention.

[0029] Figure 8 This is a schematic diagram of the structure of a payment device shown in an embodiment of this specification.

[0030] Fig. 9 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this specification. DETAILED DESCRIPTION

[0031] In order to make the purpose, technical solutions and advantages of one or more embodiments of this specification clearer, the technical solutions of one or more embodiments of this specification will be clearly and completely described below in combination with the specific embodiments of this specification and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this description, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of one or more embodiments of this specification.

[0032] The technical solutions provided by the embodiments of this specification are described in detail below in conjunction with the accompanying drawings.

[0033] In the prior art, when a buyer purchases a product, such as online shopping, or when consuming in an offline store, after the payment system or code platform and other related systems determine that the buyer has purchased the product, an order QR code can be generated according to the order of the product. The order QR code is a form of QR code, which can include the amount and product information. When scanning the order QR code for payment, the order can be paid without the user entering the amount. When the buyer needs to pay on behalf of others, the order QR code can be forwarded to other users, who can scan the order QR code to pay on behalf of others.

[0034] For example, the order QR code is sent to a group chat so that other users in the group chat can pay on behalf of the user. At this time, if user A in the group chat takes too long to pay and user B also pays at the same time, it is possible that after user B pays successfully, user A also pays successfully, i.e., duplicate payment is made for the order of the product.

[0035] Currently, if duplicate payments occur, the payment system needs to perform a unified settlement and initiate a refund operation for user A or user B. Not only does the payment system need to execute additional processes, but it also needs to determine which user is the target of the refund, which wastes system resources. In addition, since both user A and user B have successfully paid, they may initiate a refund application at the same time, which requires manual coordination to complete an accurate refund. Obviously, duplicate payments will bring additional system overhead and increase labor costs, and the user experience is also poor.

[0036] Furthermore, if user A fails to pay before other users due to insufficient balance or other factors, the order QR code corresponding to the order of the product will become invalid due to the uniqueness of the transaction. When other users want to pay on their behalf, they cannot continue to use the order QR code to complete the payment. The buyer needs to actively refresh the order QR code and resend it to the payee. Regenerating the order QR code will bring additional overhead to related systems such as the payment system and code platform, and the order QR code used to pay for the product order cannot be reused.

[0037] In view of this, a payment method should be provided that can reuse the order QR code while avoiding duplicate payments, so as to reduce system overhead, reduce users' extra operations, and improve user experience.

[0038] Figure 1 This is a schematic diagram of the system structure of a payment method shown in an embodiment of this specification.

[0039] The user 20 can communicate with the code platform 10 by scanning the order QR code 30. Of course, there can be multiple users 20, and the code platform 10 can also be connected to a unified payment system. The unified payment system can be a system that can use multiple payment platforms for payment.

[0040] Figure 2 It is a flow chart of a payment method shown in an embodiment of this specification.

[0041] like Figure 2 As shown, a payment method provided by an embodiment of the present invention may include the following steps:

[0042] The embodiment of the present invention discloses a payment method, including:

[0043] Step 200: receiving a payment instruction sent by a first user by scanning an order QR code; the order QR code is generated according to a first order corresponding to a target product; the first order is generated based on a purchase operation of the target product by a second user;

[0044] In an embodiment of the present invention, the order QR code may correspond to the first order. When the purchase operation of the second user to purchase the target product is obtained, the process of generating the first order according to the target product and generating the order QR code corresponding to the first order according to the first order will be triggered. Among them, the second user can purchase the target product online, for example, by logging into the shopping website through a browser, and of course, it can also purchase the target product offline, for example, by operating a self-service purchase method. It is understandable that the target product can be a physical product such as electronic equipment, home furnishings, household appliances, daily necessities, fuel, etc., or a virtual product such as game point cards, props, equipment, value-added services, etc., which is not limited here. It only needs to be able to generate the first order based on the target product and then generate the order QR code according to the first order.

[0045] In some embodiments, the order QR code is generated by a code platform, which can be part of a payment system or a separate platform system.

[0046] The order QR code may include information about the target product, the amount of the target product, the order number of the order corresponding to the target product, etc. The specific information carried can be set according to actual needs.

[0047] The first user can use different payment platform applications to scan the order QR code to make payment for the second user. Of course, different applications for scanning the order QR code may correspond to different payment platforms.

[0048] Step 202: setting the first order to an occupied state; wherein, when the first order is in the occupied state, payment instructions of users other than the first user are refused to be executed;

[0049] In an embodiment of the present invention, after receiving a payment instruction, the first order can be set to an occupied state. The first order in the occupied state can only be paid by the occupant, and the payment instructions of users other than the first user are rejected when the first order is in the occupied state. For example, after the first user locks the first order, the first order can only be paid by the first user during the locking process. At this time, if other users, such as a third user, try to pay for the first order, the payment operation of the third user will not be executed because the first order is in the occupied state.

[0050] In the embodiment of the present invention, setting the order to the occupied state can be achieved by locking the data row of the database, or by setting parameters, such as setting a time point that cannot be occupied.

[0051] In the embodiment of the present invention, setting the first order to an occupied state includes:

[0052] The data row of the database where the first order is located is locked.

[0053] The step of setting the first order to an occupied state comprises:

[0054] Set the unavailable time point to the sum of the current time point and the preset unavailable time parameter.

[0055] In the embodiment of the present invention, setting the first order to an occupied state may include at least two different methods.

[0056] In some embodiments, the data row of the database where the first order is located can be locked, for example, by using a database row lock. The database row lock only allows one user to operate at the same time. When the first user obtains the database row lock to lock the data row, other users cannot obtain the database row lock and cannot perform operations on the data row lock, that is, they cannot set the first order to an occupied state. This method can achieve exclusivity when there are many concurrent users and the time interval is very short.

[0057] For example, in the payment on behalf of another user in the embodiment of the present application, the first user and the third user acquire the database row lock 50 ms apart respectively to lock the data row of the first order in the database and complete the operation of setting the first order to an occupied state. Since the time point when the first user sends the payment instruction is earlier than the time point when the third user sends the payment instruction, when the third user tries to acquire the database row lock, the third user can be asked to wait, or an error message can be directly returned to prevent the third user's payment operation.

[0058] This method requires occupying the database, but because the database response time is short, it can be locked as long as the database row lock is not in use, without the need for other settings and algorithms, and without worrying about network fluctuations.

[0059] Another implementation method is to set an unoccupiable time point instead of occupying the database. The unoccupiable time point is used to characterize the time point at which the payment instruction of users other than the first user can be executed. Among them, the unoccupiable time point indicates that other users may have set the occupied time and are currently performing payment operations. For example, the unoccupiable time point defaults to null or zero value. When the time point at which the payment instruction sent by the first user is received is not earlier than the unoccupiable time point, it can be set to the sum of the current time point and the preset unoccupiable time parameter. For example, the current time point is 12:00:00, and the preset unoccupiable time parameter is 2 seconds, then the unoccupiable time point is set to 12:00:2. Among them, the unoccupiable time parameter can be set according to actual needs. The preset unoccupiable time parameter is used to characterize the length of time that the payment instruction can be processed. Of course, the preset unoccupiable time parameter can be set with reference to the usage time of the database row lock, can be set according to the actual duration, and can also be updated according to subsequent needs.

[0060] The method of setting unoccupiable time points does not require the use of the database and can save database resources. However, since setting parameters requires the execution of algorithm operations, the setting may fail due to network fluctuations. However, as hardware and network performance continue to improve, the setting speed can be accelerated to avoid setting failures.

[0061] In the embodiment of the present invention, no matter which method is used, the order can be set to an occupied state, so that other users cannot perform payment operations, and data preparation is performed to avoid duplicate payments.

[0062] Step 204: creating a second order of the first user according to the order identifier of the first order in the occupied state;

[0063] In an embodiment of the present invention, a second order of the first user can be created according to the order identifier of the first order set to an occupied state. The order identifier can be obtained by matching the order code in the payment instruction, and the order code can associate the first user, the first order, and the second order.

[0064] In the embodiment of the present invention, different users may have corresponding second orders, and a first order may correspond to multiple second orders. Even if the payment of the second order fails or an error occurs, it will not affect the status of the first order, thereby not affecting the status of the order QR code corresponding to the first order. This allows the order QR code to be reused before the payment of the first order is completed, without the need to actively or passively refresh the order QR code corresponding to the first order.

[0065] After the second order is created, a data table for the second order may be created in the database. The data table for the first order may correspond to multiple data tables for the second order. The data table for the first order and the data table for the second order are associated with each other, for example, they have the same order code. The user ID corresponding to each second order may be different to distinguish different users. Of course, the data table for the second order may also contain other information related to the first order and the user, which is not specifically limited here.

[0066] Step 206: Execute a payment operation based on the second order.

[0067] In the embodiment of the present invention, when the second order is generated, a payment operation can be performed based on the second order to complete the payment operation of the first user on behalf of the second user.

[0068] In an embodiment of the present invention, a payment operation can be completed based on a second order created based on a first order identifier that is in an occupied state. When the first order is in an occupied state, even if payment of the second order fails, the order QR code corresponding to the first order can be reused. Since only one user can successfully pay for the first order in the occupied state, duplicate payment can be avoided while ensuring that the order QR code can be reused.

[0069] In the above-mentioned embodiment, the process of setting the first order to the occupied state is introduced. In the embodiment of the present invention, before setting the first order to the occupied state, it is also possible to first determine whether the first order is in the occupied state.

[0070] Figure 3 It is another flow chart of a payment method shown in the embodiment of this specification.

[0071] Based on the above embodiment, before setting the first order to the occupied state in step 202, the following steps may be further included:

[0072] Step 300: Receive a payment instruction sent by the first user by scanning an order QR code.

[0073] Step 302: Determine whether the first order is in an occupied state; if it is determined that the first order is not in an occupied state, execute step 304.

[0074] Step 304: Set the first order to an occupied state.

[0075] Step 306: Create a second order for the first user according to the order identifier of the first order in the occupied state.

[0076] Step 308: Execute a payment operation based on the second order.

[0077] Step 300, step 304, step 306 and step 308 may refer to step 200, step 202, step 204 and step 206 introduced in the above embodiment, and will not be described in detail here.

[0078] The determining whether the first order is in an occupied state may specifically include:

[0079] Determine whether the data row in the database where the first order is located is locked;

[0080] If it is determined that the data row is not locked, it is determined that the first order is not in an occupied state.

[0081] The determining whether the first order is in an occupied state may specifically include:

[0082] Determine whether the current time point is earlier than the unavailable time point; the unavailable time point is used to represent the set time point when the payment instruction was received last time;

[0083] If it is determined that the current time point is not earlier than the unoccupiable time point, it is determined that the first order is not in an occupied state.

[0084] In the embodiment of the present invention, judging whether the first order is in an occupied state may be judging whether the data row of the database where the first order is located is locked, or judging whether the current time is earlier than the unoccupiable time point.

[0085] In the embodiment of the present invention, the unavailable time point is the time point set when the payment instruction was received last time. It can be known from the above embodiment that the unavailable time point can be set according to the time point when the payment instruction was received last time, to indicate that the user has occupied the first order and is in the process of performing the payment operation for the first order.

[0086] In the embodiment of the present invention, if the data row is locked, that is, the database row lock has been acquired by a user, it means that a user is performing a payment operation for the first order, and therefore, it should be determined that the first order is in an occupied state. Otherwise, if the data row of the database is not locked, it is determined that the first order is not in an occupied state, and subsequent operations can be performed.

[0087] In the embodiment of the present invention, before setting the first order to the occupied state, it can be determined whether the first order has been set to the occupied state. If it has not been set to the occupied state, the first order is set to the occupied state.

[0088] In the embodiment of the present invention, if it is determined that the first order is in an occupied state, a prompt message indicating that the first order is being processed is sent to the first user.

[0089] In an embodiment of the present invention, if the first order is in an occupied state, a prompt message indicating that the first order is being processed can be sent to the first user, for example, a prompt message of "being processed" is sent, and at the same time, the subsequent operation process of paying for the first order is blocked.

[0090] In the embodiment of the present invention, determining that the first order is in an occupied state may specifically include:

[0091] If it is determined that the data row is locked, determining whether the data row in the database where the first order is located is locked after a preset waiting time interval;

[0092] If the data row of the database where the first order is located is locked after a preset waiting time interval, it is determined that the first order is in an occupied state.

[0093] In the embodiment of the present invention, if the first order is in an occupied state, you can also wait for a preset interval time. The preset interval time can be set according to actual needs, for example, 2 seconds. The preset interval time can be calculated from receiving the payment instruction, generating the payment code corresponding to the second order, sending it to the unified payment platform, and receiving the acceptance message returned by the unified payment platform. It can be adjusted according to actual needs.

[0094] If it is still locked after waiting for the preset time interval, it means that there may be a system problem or network fluctuation that causes the previous user's payment processing to be incomplete, and it is determined that the first order is still in the occupied state.

[0095] In the embodiment of the present invention, in order to further avoid duplicate payment, it is also possible to determine whether the current time point is earlier than the non-payable time point.

[0096] Figure 4 This is another flow chart of a payment method shown in the embodiment of this specification.

[0097] Step 400: Receive a payment instruction sent by the first user by scanning an order QR code.

[0098] Step 402: Set the first order to an occupied state.

[0099] Step 404: Determine whether the current time point is earlier than the non-payable time point. If it is not earlier than the non-payable time point, then execute step 406.

[0100] Step 406: Create a second order for the first user according to the order identifier of the first order in the occupied state.

[0101] Step 408: Execute a payment operation based on the second order.

[0102] In the embodiment of the present invention, step 400, step 402, step 406, and step 408 may refer to step 200, step 202, step 204, and step 206 in the aforementioned embodiment, respectively, and will not be described in detail here.

[0103] In an embodiment of the present invention, in order to further avoid duplicate payments, before creating the second order of the first user according to the order identifier of the first order in the occupied state, it can also be determined whether the current time point is within the time period of payment operations of other users.

[0104] In an embodiment of the present invention, step 404 may be a judgment process executed after the database row lock is unlocked. Therefore, in step 404, it is determined whether the current time point is earlier than the unpayable time point, and it is also determined whether the data row of the database corresponding to the first order at the current time point has been unlocked. If unlocked, step 404 is executed; otherwise, step 404 is executed after waiting to be unlocked, or an error prompt message is returned to the first user, such as a prompt message that the order is being processed.

[0105] In the embodiments of the present invention, extreme situations in the payment process also need to be considered. For example, after the first user locks the data row of the database of the first order, if the first order is being paid by other users, such as when the third user pulls up the cashier to make a payment, at this time, although the data row of the database of the first order has been unlocked, that is, the database row lock has been released, the subsequent steps of creating the second order should not be performed, and the second order can only be created when the current time point is not earlier than the non-payable time point.

[0106] It is understandable that a user cannot be in a payment state for a long time. Therefore, the non-payable time point can also ensure that when a user suspends a payment operation for a long time, other users will be unable to make payments.

[0107] Based on this, in the embodiment of the present invention, it can also be determined whether the current time point is earlier than the non-payable time point. In the embodiment of the present invention, the non-payable time point can be a time point of a preset payment time interval after the time point when the payment instruction is received. It can also be a time point of a preset payment time interval after the time point when the acceptance message sent by the unified payment platform is received. Of course, it can also be a time point of a preset payment time interval after the time point when step 404 is triggered.

[0108] The unpayable time point can be set according to actual needs. For example, the payment operation time from jumping to the payment page to completing the payment is usually no more than 3 minutes. Therefore, the unpayable time point can be set to the 3rd minute after the time of receiving the payment instruction as the unpayable time point, so that the user can successfully perform the payment operation. For example, after 12:00, the preset payment time interval is 3 minutes, and the unpayable time point is 12:03.

[0109] Of course, if the unpayable time point needs to be changed later, the preset payment time interval can also be modified. For example, if it is changed to 1 minute, the aforementioned unpayable time point can be 12:01. That is, the unpayable time point in the embodiment of the present invention can be set and updated according to actual needs, and is a parameter that can reflect the duration of the user's payment operation.

[0110] In the embodiment of the present invention, when it is determined that the current time point is not earlier than the non-payable time point, the first order is determined to be in the payment process, and the process of step 406 may be executed.

[0111] It is understandable that step 404 may also be a process executed before step 402, and the execution order of step 404 may be adjusted according to actual needs.

[0112] On the basis of the above embodiment, if it is determined that the first order is in the payment process, prompt information can be returned to the first user.

[0113] In the embodiment of the present invention, it also includes:

[0114] If it is determined that the current time point is earlier than the unpayable time point, it is determined that the first order is in the payment process;

[0115] A prompt message indicating that the first order is being paid is sent to the first user.

[0116] In an embodiment of the present invention, if it is determined that the first order is in the payment process, that is, the second order corresponding to the first order is being processed by the unified payment platform, a prompt message, such as a prompt message that the order is being paid, can be sent to the first user and the subsequent process can be interrupted, for example, the process of generating the second order of the first user is not executed.

[0117] In the embodiment of the present invention, in order to further avoid duplicate payment, it is also possible to determine whether the first order is in the payment process and give the user a prompt.

[0118] In the embodiment of the present invention, it can also be determined whether the first order is in a payable state, for example, whether it has been paid.

[0119] Figure 5 This is another flow chart of a payment method shown in the embodiment of this specification.

[0120] Step 500: Receive a payment instruction sent by the first user by scanning an order QR code.

[0121] Step 502: Determine whether the first order is in a payable state. If so, step 504 can be executed.

[0122] Step 504: Set the first order to an occupied state.

[0123] Step 506: Create a second order for the first user according to the order identifier of the first order in the occupied state.

[0124] Step 508: Execute a payment operation based on the second order.

[0125] Among them, it also includes:

[0126] If it is determined that the first order is not in a payable state, a prompt message indicating that the first order has been paid is sent to the first user.

[0127] In the embodiment of the present invention, step 500, step 504, step 506, and step 508 may refer to step 200, step 202, step 204, and step 206 in the aforementioned embodiment, and will not be described in detail here.

[0128] In the embodiment of the present invention, it can also be determined whether the first order is in a payable state. The payable state can indicate that the first order can be paid. If it is determined that the first order has been paid, it is determined that the first order is in a payable state; if it is determined that the first order has not been paid, it is determined that the first order is not in a payable state; when the first order is in a payable state, a second order of the first user can be created according to the order identifier of the first order in the occupied state.

[0129] If it is determined that the first order is not in a payable state, a prompt message indicating that the first order has been paid is sent to the first user.

[0130] When the first order has been paid, a prompt message indicating that the order has been paid can be sent to the user. Whether the first order has been paid can be determined by judging whether the first order has been paid in the data row where the first order is located, and whether the first order has been paid can be determined by judging, for example, whether the first order has been paid. It can also be determined by the order status of the first order, and the order status can be an attribute parameter corresponding to the order application, and the attribute parameter can be used to determine whether the first order has been successfully paid.

[0131] In the embodiment of the present invention, if the first order has been paid, it is determined that the first order is in a payable state, and the first order that is not in a payable state cannot execute the subsequent payment process of step 504 to step 508. The first order that is in a payable state can execute the subsequent payment process of step 504 to step 508.

[0132] In the embodiment of the present invention, in order to save system resources, it is also possible to determine whether the first order is in a payable state.

[0133] Of course, judging whether the first order is in a payable state can also be achieved in the following way.

[0134] Before creating the second order of the first user according to the order identifier of the first order in the occupied state, the method further includes:

[0135] If it is determined that the transaction corresponding to the first order is in an unclosed state, determining that the first order is in a payable state;

[0136] If it is determined that the transaction corresponding to the first order is in a closed state, it is determined that the first order is not in a payable state.

[0137] Among them, it also includes:

[0138] If it is determined that the first order is not in a payable state, a prompt message indicating that the first order cannot be paid is sent to the first user.

[0139] In the embodiment of the present invention, if the transaction corresponding to the first order is in a closed state, it means that the transaction of the first order is invalid. For example, if a flash sale activity has expired, the transaction corresponding to the first order is in a closed state. Alternatively, if the second user actively cancels the transaction of the first order, the transaction corresponding to the first order should also be in a closed state. There may also be other situations that lead to changes in transaction status, which are not enumerated here.

[0140] In the embodiment of the present invention, if it is determined that the transaction of the first order is in a closed state, a prompt message indicating that payment cannot be made may be sent to the first user, for example, the order cannot be paid, or the order transaction has been closed.

[0141] In the embodiment of the present invention, the execution order of step 502 can be set according to actual needs, so as to reduce unnecessary system overhead.

[0142] The above embodiment introduces the process of performing payment operation based on the second order, which will be described in detail below.

[0143] Figure 6 This is another flow chart of a payment method shown in the embodiment of this specification.

[0144] Step 600: Receive a payment instruction sent by the first user by scanning an order QR code.

[0145] Step 602: Set the first order to an occupied state.

[0146] Step 604: Create a second order for the first user according to the order identifier of the first order in the occupied state.

[0147] Step 606: Send the payment code of the second order to the unified payment platform; the unified payment platform can generate payment jump page address information based on the payment code of the second order and the payment platform information of the application used by the first user to scan the order QR code, and send it to the application, so that the first user can perform payment operations in the payment interface popped up by the application according to the payment jump page address information.

[0148] In the embodiment of the present invention, the execution process of step 600, step 602, and step 604 may refer to the execution process of step 200, step 202, and step 204 in the aforementioned embodiment, and will not be described in detail here.

[0149] In the embodiment of the present invention, payment operations of multiple payment platforms can be supported.

[0150] In order to implement payment operations on multiple payment platforms, in an embodiment of the present invention, the payment code of the second order can be sent to the unified payment platform. The payment code can be generated based on the second order and can include relevant payment information such as the amount of the target product and the identification of the first user.

[0151] After the payment code is sent to the unified payment platform, the unified payment platform can establish a communication connection with the application used by the first user to scan the order QR code, and generate a payment jump page corresponding to the payment platform based on the platform information of the payment platform of the application, so that the first user uses the application to adjust the page address information of the payment to perform payment operations, such as pulling up the payment checkout counter, etc., and then performing operations such as entering the payment confirmation password in the pop-up interface.

[0152] In the embodiment of the present invention, different payment jump pages can be generated according to different payment platforms to realize payment on different payment platforms.

[0153] Of course, the function of the unified payment platform can also be implemented as a module of the execution entity in the embodiment of the present application.

[0154] In the embodiment of the present invention, the following may also be included:

[0155] Receiving an acceptance message returned by the unified payment platform;

[0156] Unlock the data row in the database where the first order is located.

[0157] In the embodiment of the present invention, the timing of unlocking the data row can be set to when the unified platform accepts the order. Due to the limitation of the database itself, if the data row lock is occupied for a long time, it may cause problems such as slow database operation, redundant operation logs, and database crash. Therefore, the locking time should not be too long. For example, 3 seconds, 50 milliseconds, etc. In order to ensure the payment operation of the first order, the data row can be unlocked after the unified platform receives the payment code.

[0158] In the embodiment of the present invention, the following may also be included:

[0159] After receiving the acceptance message returned by the unified payment platform, the non-payable time point is updated according to the preset payment time parameters.

[0160] In the embodiment of the present invention, when receiving the acceptance message returned by the unified payment platform, the non-payable time point can be updated, wherein the preset payment time parameter can refer to the preset payment time interval setting method in the above embodiment, which can represent the payment operation time length of the user for the order.

[0161] In the embodiment of the present invention, the following may also be included:

[0162] When it is determined that the first user has paid successfully, the first order is set to a paid status.

[0163] In the embodiment of the present invention, the payment status of the unified payment platform can also be asynchronously queried. If it is determined that the payment of the second order is successful, the payment status of the second order is modified to paid, and the first order is set to paid status. To complete the payment of the first order. Of course, it is also possible that after the payment is completed, the unified payment platform actively sends the payment result to the execution subject of the present invention, such as the code platform, and then determines whether the first user has successfully paid based on the received payment result.

[0164] In the embodiment of the present invention, the following may also be included:

[0165] If it is determined that the first user cancels the payment operation, obtaining a cancellation time point corresponding to when the first user cancels the payment operation;

[0166] If it is determined that the cancellation time point is earlier than the non-payable time point, the non-payable time point is set as the cancellation time point.

[0167] In the embodiment of the present invention, if the first user cancels the payment operation, in order to enable other users to perform payment operations on the first order as soon as possible, the payment-unavailable time point can be updated according to the cancellation time point of the first user's cancellation of the payment operation, so that other users can pay for the first order as soon as possible after the first user's payment fails.

[0168] Figure 7 A swim lane diagram of a payment method according to an embodiment of the present invention.

[0169] See also Figure 7 Based on the payment method provided in the embodiment of the present application, the actual use may include the following process:

[0170] The execution subject of the embodiment of the present invention, for example, the code platform receives the payment instruction of the first order sent by the first user scanning the order QR code of the target product at 10:00:00;

[0171] Obtain a database row lock and lock the order row;

[0172] Create a second payment order corresponding to the first order; generate a payment code for the second order and send it to the unified payment platform;

[0173] At 10:00:30, the unified payment platform returns the acceptance notification, and the non-payable time point is adjusted to 10:02; and the order line is unlocked.

[0174] The unified payment platform returns the payment jump page address according to the first user's application, and the first user performs payment operations according to the redirected interface.

[0175] When the payment is successful, the unified payment platform saves the payment result. When the payment result is determined to be successful, the payment status of the second order is modified to paid, the payment status of the first order is modified to paid, and the first user completes the payment.

[0176] If a third user scans the order QR code and sends a payment instruction at 10:01;

[0177] If the database row lock of the first order cannot be obtained, a prompt message indicating that the third user is paying is fed back.

[0178] At 10:03, the third user sends a payment instruction, confirms that the data row of the first order is not locked, further determines that the first order is in a paid state, and returns a prompt message to the third user that the order has been paid.

[0179] It can be seen that in the embodiment of the present invention, the order QR code can be reused while avoiding repeated payment.

[0180] Based on the same idea, the embodiments of this specification also provide a device corresponding to the above method. Figure 8 The embodiments of this specification provide corresponding to Figure 2 A structural diagram of a payment device.

[0181] like Figure 8 As shown, the payment device may include:

[0182] The receiving module 81 is used to receive a payment instruction sent by the first user by scanning an order QR code; the order QR code is a QR code generated according to a first order corresponding to the target product; the first order is generated based on a purchase operation of the target product by the second user;

[0183] A setting module 82 is used to set the first order to an occupied state; wherein when the first order is in the occupied state, payment instructions of users other than the first user are refused to be executed;

[0184] A creation module 83, configured to create a second order of the first user according to the order identifier of the first order in the occupied state;

[0185] The payment module 84 is used to perform a payment operation based on the second order.

[0186] Fig. 9 The embodiments of this specification provide corresponding to Figure 2 A schematic diagram of the structure of an electronic device. Figure 8 As shown, the electronic device 900 may include:

[0187] at least one processor 910; and,

[0188] A memory 930 in communication with the at least one processor; wherein,

[0189] The memory 930 stores instructions 920 that can be executed by the at least one processor 910. The instructions are executed by the at least one processor 910 to enable the at least one processor 910 to:

[0190] Receiving a payment instruction sent by a first user by scanning an order QR code; the order QR code is generated according to a first order corresponding to a target product; the first order is generated based on a purchase operation of the target product by a second user;

[0191] Setting the first order to an occupied state; wherein, when the first order is in the occupied state, refusing to execute payment instructions of users other than the first user;

[0192] creating a second order for the first user according to the order identifier of the first order in the occupied state;

[0193] A payment operation is performed based on the second order.

[0194] Each embodiment in this specification is described in a progressive manner. The same or similar parts between the embodiments can be referred to each other. Each embodiment focuses on the differences from other embodiments. Figure 7 As for the payment device shown, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0195] In the 1990s, improvements to a technology could be clearly distinguished as hardware improvements (for example, improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the method flow). However, with the development of technology, many improvements to the method flow today can be regarded as direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0196] The controller can be implemented in any appropriate manner, for example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (such as software or firmware) that can be executed by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of controllers include, but are not limited to, the following microcontrollers: ARC625D, AtmelAT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that in addition to implementing the controller in a purely computer-readable program code manner, the controller can be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be regarded as structures within the hardware component. Or even, the devices for implementing various functions can be regarded as both software modules for implementing the method and structures within the hardware component.

[0197] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0198] For the convenience of description, the above device is described in various units according to their functions. Of course, when implementing the present application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0199] 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.

[0200] 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.

[0201] 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.

[0202] 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.

[0203] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0204] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0205] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0206] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0207] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment or an embodiment in combination with software and hardware. Moreover, the present application may adopt 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.) that contain computer-usable program code.

[0208] The present application may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The present application may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0209] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A payment method comprising: Receiving a payment instruction sent by a first user by scanning an order QR code; the order QR code is generated according to a first order corresponding to a target product; The first order is generated based on a purchase operation of the target product by the second user; Determine whether the current time point is earlier than the unavailable time point; The unavailable time point is used to represent the time point set when the payment instruction was received last time; If it is determined that the current time point is not earlier than the unavailable time point, it is determined that the first order is not in an occupied state; Setting the first order to an occupied state; wherein, when the first order is in the occupied state, refusing to execute payment instructions of users other than the first user; Determining whether the first order is in a payable state; If the first order is in the payable state, a second order of the first user is created according to the order identifier of the first order in the occupied state; when the payment of the second order fails, the state of the first order and the order QR code is not affected; A payment operation is performed based on the second order.

2. The payment method according to claim 1, before setting the first order to an occupied state, further comprising: Determining whether the first order is in an occupied state; If it is determined that the first order is not in an occupied state, the step of setting the first order to an occupied state is performed.

3. According to the payment method of claim 2, the step of determining whether the first order is in an occupied state specifically comprises: Determine whether the data row in the database where the first order is located is locked; If it is determined that the data row is not locked, it is determined that the first order is not in an occupied state.

4. According to the payment method of claim 2, the step of determining whether the first order is in an occupied state specifically comprises: Determine whether the current time point is earlier than the unavailable time point; The unavailable time point is used to represent the set time point when the payment instruction was received last time; If it is determined that the current time point is not earlier than the unoccupiable time point, it is determined that the first order is not in an occupied state.

5. The payment method according to claim 1, wherein setting the first order to an occupied state comprises: The data row of the database where the first order is located is locked.

6. The payment method according to claim 1, wherein setting the first order to an occupied state comprises: The unoccupiable time point is set to the sum of the current time point and the preset unoccupiable time parameter; The unavailable time point is used to represent a time point at which payment instructions of users other than the first user can be executed.

7. According to the payment method of claim 3, if it is determined that the first order is in an occupied state, a prompt message indicating that the first order is being processed is sent to the first user.

8. The payment method according to claim 7, wherein determining that the first order is in an occupied state specifically comprises: If it is determined that the data row is locked, determining whether the data row in the database where the first order is located is locked after a preset waiting time interval; If the data row of the database where the first order is located is locked after a preset waiting time interval, it is determined that the first order is in an occupied state.

9. The payment method according to any one of claims 1 to 8, before creating the second order of the first user according to the order identifier of the first order in the occupied state, further comprising: Determining whether the current time point is earlier than the unpayable time point; If it is determined that the current time point is not earlier than the non-payable time point, it is determined that the first order is not in the payment process; Wherein, when the first order is not in the payment process, an operation of creating a second order of the first user according to the order identifier of the first order in the occupied state can be performed.

10. The payment method according to claim 9, further comprising: If it is determined that the current time point is earlier than the unpayable time point, it is determined that the first order is in the payment process; A prompt message indicating that the first order is being paid is sent to the first user.

11. The payment method according to claim 1, before creating the second order of the first user according to the order identifier of the first order in the occupied state, further comprising: If it is determined that the first order has been paid, determining that the first order is in a payable state; If it is determined that the first order has not been paid, determining that the first order is not in a payable state; When the first order is in a payable state, a second order of the first user can be created according to the order identifier of the first order in the occupied state.

12. The payment method according to claim 1, before creating the second order of the first user according to the order identifier of the first order in the occupied state, further comprising: If it is determined that the transaction corresponding to the first order is in an unclosed state, determining that the first order is in a payable state; If it is determined that the transaction corresponding to the first order is in a closed state, it is determined that the first order is not in a payable state.

13. The payment method according to claim 11, further comprising: If it is determined that the first order is not in a payable state, a prompt message indicating that the first order has been paid is sent to the first user.

14. The payment method according to claim 12, further comprising: If it is determined that the first order is not in a payable state, a prompt message indicating that the first order cannot be paid is sent to the first user.

15. The payment method according to claim 1, wherein the performing a payment operation based on the second order specifically comprises: The payment code of the second order is sent to a unified payment platform; the unified payment platform can generate payment jump page address information based on the payment code of the second order and the payment platform information of the application used by the first user to scan the order QR code, and send it to the application, so that the first user performs payment operations in the payment interface popped up by the application according to the payment jump page address information.

16. The payment method according to claim 15, further comprising: Receiving an acceptance message returned by the unified payment platform; Unlock the data row in the database where the first order is located.

17. The payment method according to claim 9, further comprising: After receiving the acceptance message returned by the unified payment platform, the non-payable time point is updated according to the preset payment time parameters.

18. The payment method according to claim 1, further comprising: When it is determined that the first user has paid successfully, the first order is set to a paid status.

19. The payment method according to claim 1, further comprising: If it is determined that the first user cancels the payment operation, obtaining a cancellation time point corresponding to when the first user cancels the payment operation; If it is determined that the cancellation time point is earlier than the non-payable time point, the non-payable time point is set as the cancellation time point.

20. According to the payment method of claim 1, the order identifier of the first order and the order identifier of the second order have a corresponding relationship.

21. A payment device, comprising: A receiving module, configured to receive a payment instruction sent by a first user by scanning an order QR code; the order QR code is a QR code generated according to a first order corresponding to a target product; The first order is generated based on a purchase operation of the target product by the second user; The first judgment module is used to judge whether the current time point is earlier than the unoccupiable time point; The unavailable time point is used to represent the time point set when the payment instruction was received last time; A determination module, configured to determine that the first order is not in an occupied state if it is determined that the current time point is not earlier than the unoccupiable time point; A setting module, used to set the first order to an occupied state; wherein, when the first order is in the occupied state, payment instructions of users other than the first user are refused to be executed; A second judgment module is used to judge whether the first order is in a payable state; A creation module, configured to create a second order of the first user according to the order identifier of the first order in the occupied state if the first order is in the payable state; when payment of the second order fails, the state of the first order and the order QR code is not affected; A payment module is used to perform a payment operation based on the second order.

22. An electronic device, comprising: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to: Receiving a payment instruction sent by the first user by scanning an order QR code; the order QR code is a QR code generated according to a first order corresponding to the target product; the first order is generated based on a purchase operation of the target product by the second user; Determine whether the current time point is earlier than the unavailable time point; the unavailable time point is used to represent the time point set when the payment instruction was received last time; If it is determined that the current time point is not earlier than the unavailable time point, it is determined that the first order is not in an occupied state; Setting the first order to an occupied state; wherein, when the first order is in the occupied state, refusing to execute payment instructions of users other than the first user; Determining whether the first order is in a payable state; If the first order is in the payable state, a second order of the first user is created according to the order identifier of the first order in the occupied state; when the payment of the second order fails, the state of the first order and the order QR code is not affected; A payment operation is performed based on the second order.

23. A computer-readable medium having computer-readable instructions stored thereon, wherein the computer-readable instructions can be executed by a processor to implement a payment method according to any one of claims 1 to 20.

Images