Payment method and device, electronic equipment and readable medium

Abstract

The embodiment of the invention discloses a payment method and device, electronic equipment and a readable medium, and the method comprises the steps: receiving a payment instruction sent by a first user through scanning an order two-dimensional code; the order two-dimensional code is generated according to a first order corresponding to a target product; the first order is generated based on a purchase operation of a second user on the target product; setting the first order to be in an occupied state; wherein when the first order is in the occupied state, payment instructions of users except the first user are refused to be executed; creating a second order of the first user according to the order identifier of the first order in the occupation state; and payment operation is executed based on the second order.

Description

[0001] This application is a divisional application of "A Payment Method, Device, Electronic Device and Readable Medium (Application Date: September 8, 2021, Application No. 202111051331.4)". Technical Field

[0002] This application relates to the field of Internet of Things technology, and particularly to a payment method, device, electronic device and readable medium. Background Art

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

[0004] If, when the target user purchases a product, payment cannot be made for various reasons, the order QR code corresponding to the order of the product can be sent to other users, and the other users can scan the order QR code to pay on behalf of the target user.

[0005] At this time, if there are multiple other users, they may pay for the order repeatedly at the same time. The other users who make repeated payments need to wait for the system to complete the order processing and then execute the refund process. Or, when the payment of the user who first completes the payment for the order fails, the target user needs to perform a refresh operation. After the system refreshes the order QR code, other users can use the new order QR code to make a payment on behalf of the target user.

[0006] It can be seen that in the existing payment method, before the order is successfully paid when other users make a payment on behalf of the target user, the order QR code cannot be reused and the order QR code cannot avoid repeated payments. Summary of the Invention

[0007] Embodiments of this specification provide a payment method, device, electronic device and readable medium, so as to provide a payment method that can reuse the order QR code before the order is successfully paid and avoid repeated payments when other users need to pay on behalf of the target user, reduce the system pressure, and improve the user experience.

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

[0009] A payment method includes:

[0010] 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 a second user for the target product;

[0011] 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 rejected;

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

[0013] Perform a payment operation based on the second order.

[0014] An embodiment of the present invention also discloses a payment device, including:

[0015] A payment device, including:

[0016] 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 a second user for the target product;

[0017] A setting module, configured to set the first order to an occupied state; wherein, when the first order is in the occupied state, payment instructions from users other than the first user are rejected;

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

[0019] A payment-on-behalf module, configured to perform a payment operation based on the second order.

[0020] An embodiment of the present specification achieves the following beneficial effects:

[0021] In the embodiment of the present invention, first, a payment instruction sent by a first user by scanning an order QR code is received; 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 a second user for the target product; then the first order is set to an occupied state; wherein, when the first order is in the occupied state, payment instructions from users other than the first user are rejected; then a second order for 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 order is locked after the payment instruction is received in the embodiment of the present invention, when the first user makes a payment for the first order, other users cannot make a payment, and since the payment operation is performed based on the second order created based on the first order, the first order is not directly processed. Even if the first user's payment fails, only the second order payment fails, which does not affect the first order. Therefore, the order QR code can be reused, achieving the technical effect of being able to reuse the order QR code before the first order of the target product is successfully paid while avoiding duplicate payments. Description of the Drawings

[0022] To more clearly illustrate the technical solutions in the embodiments of this specification or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments recorded in this application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0023] Figure 1 Schematic structural diagram of a payment method system shown in an embodiment of this specification.

[0024] Figure 2 Schematic flowchart of a payment method shown in an embodiment of this specification.

[0025] Figure 3 Another schematic flowchart of a payment method shown in an embodiment of this specification.

[0026] Figure 4 Another schematic flowchart of a payment method shown in an embodiment of this specification.

[0027] Figure 5 Another schematic flowchart of a payment method shown in an embodiment of this specification.

[0028] Figure 6 Another schematic flowchart of a payment method shown in an embodiment of this specification.

[0029] Figure 7 Swimlane diagram of a payment method shown in an embodiment of the present invention.

[0030] Figure 8 Schematic structural diagram of a payment device shown in an embodiment of this specification.

[0031] Figure 9 Schematic structural diagram of an electronic device shown in an embodiment of this specification. Detailed implementation manners

[0032] To make the objectives, technical solutions, and advantages of one or more embodiments of this specification clearer, the following will clearly and completely describe the technical solutions of one or more embodiments of this specification in conjunction with the specific embodiments of this specification and the corresponding drawings. Obviously, the described embodiments are only some of the embodiments of this specification, rather than all of them. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope protected by one or more embodiments of this specification.

[0033] The following will, in conjunction with the drawings, elaborate on the technical solutions provided by each embodiment of this specification.

[0034] In the prior art, when a purchaser buys a product, such as when shopping online or consuming at an offline store, after a payment system or a related system such as a code platform determines that the purchaser has bought 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 operation, the order can be paid without the user entering the amount. When the purchaser needs someone else to pay on their behalf, the order QR code can be forwarded to other users, and the other users can scan the order QR code to pay on behalf of the purchaser.

[0035] 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 purchaser. At this time, if user A in the group chat takes too long to pay and user B also makes a payment at the same time, it may happen that after user B pays successfully, user A also pays successfully, that is, the order of the product is paid repeatedly.

[0036] Currently, if a repeated payment occurs and the payment system needs to perform a unified settlement, a refund operation is initiated 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, wasting system resources. And since both user A and user B have paid successfully, they may initiate refund applications at the same time, which also requires manual coordination to complete an accurate refund. Obviously, due to repeated payments, there will be additional overhead in the system and it will increase the labor cost, and the user experience is also very poor.

[0037] Moreover, if user A fails to pay due to insufficient balance or other factors earlier than the payment operations of other users, due to the uniqueness of the transaction, the order QR code corresponding to the order of the product will become invalid at this time. When other users want to pay on behalf of the purchaser, they can no longer use this order QR code to complete the payment on behalf of the purchaser, and the purchaser needs to actively refresh the order QR code and resend it to the person paying on their behalf. Regenerating the order QR code will bring additional overhead to related systems such as the payment system and the code platform, and the order QR code used to pay for the order of the product cannot be reused.

[0038] In view of this, a payment method should be provided that can reuse the order QR code while avoiding the occurrence of repeated payment situations, so as to reduce the system overhead, reduce the additional operations of users, and improve the user experience.

[0039] Figure 1 It is a schematic diagram of the system structure of a payment method shown in the embodiments of this specification.

[0040] Among them, user 20 can communicate with the code platform 10 by scanning the order QR code 30. Of course, there can be multiple user 20s, 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.

[0041] Figure 2 It is a schematic flowchart of a payment method shown in an embodiment of this specification.

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

[0043] An embodiment of the present invention discloses a payment method, including:

[0044] Step 200: Receive 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 a second user for the target product.

[0045] In an embodiment of the present invention, the order QR code may correspond to the first order. When a purchase operation of a second user for a target product is obtained, it will trigger the process of generating a first order according to the target product and generating an order QR code corresponding to the first order according to the first order. Among them, the second user may purchase the target product online, for example, by logging in to a shopping website through a browser. Of course, it may also be purchased offline, for example, by operating a self-service purchase method. It can be understood that the target product may be a physical product such as an electronic device, home furnishing, household appliance, daily necessities, fuel, etc., or a virtual product such as a game time card, prop, equipment, value-added service, etc. It is not limited here, as long as a first order can be generated based on the target product and then an order QR code can be generated according to the first order.

[0046] In some embodiments, the order QR code is generated by a code platform. The code platform may be a part of the payment system or a separate platform system.

[0047] The order QR code may include information of 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.

[0048] The first user can use applications of different payment platforms to scan the order QR code to realize payment on behalf of the second user. Of course, if the applications for scanning the order QR code are different, the payment platforms corresponding to the applications may also be different.

[0049] Step 202: Set the first order to an occupied state; wherein, when the first order is in an occupied state, payment instructions from users other than the first user are rejected.

[0050] In an embodiment of the present invention, after receiving a payment instruction, the first order can be set to an occupied state. Among them, the first order in the occupied state can only be paid by the occupier, and when the first order is in the occupied state, the payment instructions of users other than the first user are rejected. For example, after the first user locks the first order, during the locking process of the first order, only the first user can perform payment operations. At this time, if another user, such as the third user, attempts to pay for the first order, since the first order is in the occupied state, the payment operation of the third user is not executed.

[0051] In an embodiment of the present invention, setting the order to the occupied state can be achieved through a row lock of the database data row, or by setting parameters, such as setting a non-occupiable time point.

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

[0053] Locking the data row of the database where the first order is located.

[0054] Setting the first order to the occupied state includes:

[0055] Setting the non-occupiable time point to the sum of the current time point and a preset non-occupiable time parameter.

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

[0057] In some embodiments, the data row of the database where the first order is located can be locked. For example, a database row lock is used to lock the data row. Among them, 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 the operation of locking the data row, that is, they cannot set the first order to the occupied state. This method can achieve exclusivity when the concurrency is high and the time interval is very short.

[0058] For example, in the payment-on-behalf scenario in the embodiment of the present application, the first user and the third user obtain the database row lock respectively 50 ms apart to lock the data row of the first order in the database and complete the operation of setting the first order to the 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 attempts to obtain the database row lock, the third user can be allowed to wait, or an error message can be directly returned to prevent the third user's payment-on-behalf operation.

[0059] This method requires accessing the database. However, due to the short response time of the database, as long as the database row lock is not in use, locking can be performed without other settings and algorithms, and there is no need to worry about network fluctuations.

[0060] Another implementation method is not to access the database, but to set an inoccupiable time point. The inoccupiable time point is used to represent the time point at which a payment instruction of a user other than the first user can be executed. Among them, the inoccupiable time point indicates that there may be other users setting occupancy time and performing payment operations currently. For example, the inoccupiable time point is defaulted to be empty or a zero value. When the time point when the payment instruction sent by the first user is received is not earlier than the inoccupiable time point, it can be set to the sum of the current time point and a preset inoccupiable time parameter. For example, if the current time point is 12:00:00 and the preset inoccupiable time parameter is 2 seconds, then the inoccupiable time point is set to 12:00:02. Among them, the inoccupiable time parameter can be set according to actual needs. The preset inoccupiable time parameter is used to represent the duration for processing the payment instruction. Of course, the preset inoccupiable time parameter can be set with reference to the usage duration of the database row lock, can be set according to the actual duration, or can be updated according to subsequent needs.

[0061] The method of setting the inoccupiable time point does not require accessing the database, which can save the resources of the database. However, since setting parameters requires algorithm operations, it may fail due to network fluctuations. But with the continuous improvement of hardware performance and network performance, the setting speed can be accelerated to avoid setting failures.

[0062] In the embodiments of the present invention, regardless of which method is used, the order can be set to an occupied state, so that other users cannot perform payment operations, preparing data to avoid duplicate payments.

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

[0064] In the embodiments 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 the occupied state. Among them, the order identifier can be obtained by matching the order code in the payment instruction, and this order code can make the first user, the first order, and the second order have an associated relationship.

[0065] In the embodiments of the present invention, for different users, the corresponding second orders can be different. A first order can correspond to multiple second orders. Even if the payment for a second order fails or an error occurs, it does not affect the status of the first order, and thus does not affect the status of the order QR code corresponding to the first order, enabling the order QR code to be reused before the payment for the first order is completed, without the need to actively or passively refresh the order QR code corresponding to the first order.

[0066] After creating a second order, a data table corresponding to the second order can be created in the database. The data table of the first order can correspond to multiple data tables of the second order, and there is an association relationship between the data table of the first order and the data tables of the second order. For example, they have the same order code. The user identifier corresponding to each second order can be different to distinguish different users. Of course, the data table of the second order can also have other information related to the first order and the user, which is not specifically limited herein.

[0067] Step 206: Perform a payment operation based on the second order.

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

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

[0070] In the foregoing embodiments, the process of setting the first order to the occupied state was introduced. In the embodiments of the present invention, before setting the first order to the occupied state, it can first be determined whether the first order is in the occupied state.

[0071] Figure 3 It is another schematic flowchart of a payment method shown in the embodiments of this specification.

[0072] Based on the foregoing embodiments, before step 202 of setting the first order to the occupied state, it further includes:

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

[0074] Step 302: Determine that the first order is not in the occupied state.

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

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

[0077] Step 308: Perform a payment operation based on the second order.

[0078] Step 300 and steps 304, 306 and 308 may refer to steps 200, 202, 204 and 206 introduced in the foregoing embodiments, and will not be elaborated herein.

[0079] Among them, the determination of whether the first order is in the occupied state may specifically include:

[0080] Determine whether the data row of the database where the first order is located is locked;

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

[0082] Among them, the determination of whether the first order is in the occupied state may specifically include:

[0083] Determine whether the current time point is earlier than the non-occupiable time point; the non-occupiable time point is used to represent the time point set when the previous payment instruction was received;

[0084] If it is determined that the current time point is not earlier than the non-occupiable time point, it is determined that the first order is not in the occupied state.

[0085] In the embodiment of the present invention, to determine whether the first order is in the occupied state, it may be to determine whether the data row of the database where the first order is located is locked, or it may also be to determine whether the current time point is earlier than the non-occupiable time point.

[0086] In the embodiment of the present invention, the non-occupiable time point is the time point set when the previous payment instruction was received. It can be known from the foregoing embodiments that the non-occupiable time point can be set according to the time point when the previous payment instruction was received to represent the process that the user has occupied the first order and is performing a payment operation for the first order.

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

[0088] In an embodiment of the present invention, before setting the first order to the occupied state, it is possible to determine whether the first order has already been set to the occupied state. If it has not been set to the occupied state, then set the first order to the occupied state.

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

[0090] In an embodiment of the present invention, if the first order is in the occupied state, then it is possible to send a prompt message indicating that the first order is being processed to the first user. For example, send a prompt message of "being processed". At the same time, block the subsequent operation process for making a payment for the first order.

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

[0092] If it is determined that the data row is locked, then determine whether the data row of the database where the first order is located is locked after a preset waiting time interval;

[0093] If the data row of the database where the first order is located is locked after the preset waiting time interval, then determine that the first order is in the occupied state.

[0094] In an embodiment of the present invention, if the first order is in the occupied state, it is also possible to first 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 the time period occupied by calculating from receiving the payment instruction, generating the payment code corresponding to the second order and sending it to the unified payment platform, and receiving a message such as an acceptance message returned by the unified payment platform. It can be adjusted according to actual needs.

[0095] If it is still locked after waiting for the preset time interval, it means that there may be, for example, system problems or network fluctuations that cause the payment processing of the previous user not to be completed, and it is determined that the first order is still in the occupied state.

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

[0097] Figure 4 It is another process schematic diagram of a payment method shown in an embodiment of this specification.

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

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

[0100] Step 404: Determine whether the current time point is not earlier than the non-payment time point. If it is not earlier than the non-payment time point, step 406 can be executed.

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

[0102] Step 408: Perform a payment operation based on the second order.

[0103] In the embodiments of the present invention, steps 400, 402, 406, and 408 can respectively refer to steps 200, 202, 204, and 206 in the foregoing embodiments, and will not be elaborated herein.

[0104] In the embodiments of the present invention, in order to further avoid duplicate payments, before creating the second order for 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 other users' payment operations.

[0105] In the embodiments of the present invention, step 404 can be a judgment process executed after the database row lock is unlocked. Therefore, in step 404, before determining whether the current time point is earlier than the non-payment time point, it can also be determined whether the data row of the database corresponding to the first order at the current time point has been unlocked. If it has been unlocked, step 404 is executed; otherwise, wait until it is unlocked and then execute step 404, or return an error prompt message to the first user, such as a prompt message indicating that the order is being processed, etc.

[0106] In the embodiments of the present invention, extreme cases during 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, for example, when the third user pulls up the cashier to perform a payment operation, 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 step of creating the second order should not be executed. The second order can only be created when the current time point is not earlier than the non-payment time point.

[0107] It can be understood that the user cannot be in the payment state for a long time. Therefore, the non-payment time point can also prevent the situation where other users cannot make payments due to the user hanging up the payment operation for a long time.

[0108] Based on this, in the embodiments of the present invention, it is also possible to determine whether the current time point is earlier than the non-payment time point. In the embodiments of the present invention, the non-payment time point can be the time point after a preset payment time interval from the time point when the payment instruction is received. It can also be the time point after a preset payment time interval from the time point when an acceptance message sent by, for example, a unified payment platform is received. Of course, it can also be the time point after a preset payment time interval from the time point when step 404 is triggered.

[0109] Among them, the non-payment time point can be set according to actual needs. For example, in the normal situation of users, the payment operation duration from jumping to the payment page to completing the payment usually does not exceed 3 minutes. Therefore, the non-payment time point can be set as the 3rd minute after the time point when the payment instruction is received, so as to enable the user to successfully execute the payment operation. For example, after 12:00, the preset payment time interval is 3 minutes, then the non-payment time point is 12:03.

[0110] Of course, if it is necessary to change the non-payment time point subsequently, the preset payment time interval can also be modified. For example, if it is modified to 1 minute, then the aforementioned non-payment time point can be 12:01. That is, the non-payment time point in the embodiments of the present invention can be set and updated according to actual needs, and it is a parameter that can reflect the payment operation duration of the user.

[0111] In the embodiments of the present invention, when it is determined that the current time point is not earlier than the non-payment time point, it is determined that the first order is in the payment process. The process of step 406 can be executed.

[0112] It can be understood that step 404 can also be a process executed before step 402, and the execution order of step 404 can be adjusted according to actual needs.

[0113] Based on the above embodiments, if it is determined that the first order is in the payment process, a prompt message can be returned to the first user.

[0114] The embodiments of the present invention also include:

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

[0116] Send a prompt message indicating that the first order is being paid to the first user.

[0117] 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 on the unified payment platform, a prompt message, such as a prompt message indicating 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.

[0118] In an embodiment of the present invention, in order to further avoid duplicate payments, it can also be determined whether the first order is in the payment process and a prompt is given to the user.

[0119] In an 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.

[0120] Figure 5 It is another schematic flowchart of a payment method shown in an embodiment of this specification.

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

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

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

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

[0125] Step 508: Perform a payment operation based on the second order.

[0126] Among them, it further includes:

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

[0128] In an embodiment of the present invention, step 500, step 504, step 506, and step 508 can refer to steps 200, step 202, step 204, and step 206 in the foregoing embodiments, and will not be elaborated herein.

[0129] In an embodiment of the present invention, it can also be determined whether the first order is in a payable state. Among them, the payable state can indicate that the first order can be subjected to a payment operation. If it is determined that the first order has not been paid, it is determined that the first order is in a payable state; if it is determined that the first order has been paid, it is determined that the first order is not in a payable state; among them, 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.

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

[0131] When the first order has been paid, a prompt message indicating that it has been paid can be sent to the user. Among them, to determine whether the first order has been paid, it can be judged through the field indicating whether it has been paid in the data row where the first order is located. For example, it can be determined whether the first order has been paid by judging whether there is a field indicating whether it has been paid. It can also be judged through the order status of the first order. The order status can be an attribute parameter corresponding to the order in this application, and it can be determined whether the first order has been successfully paid through this attribute parameter.

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

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

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

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

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

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

[0138] Among them, it further includes:

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

[0140] In an 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 fails. For example, a certain flash sale activity has expired, then the transaction corresponding to the first order is in a closed state. Or, the second user actively cancels the transaction of the first order, then the transaction corresponding to the first order should also be in a closed state. It can also be other situations that cause changes in the transaction state, which are not enumerated here.

[0141] In an 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, etc.

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

[0143] In the foregoing embodiment, the process of performing a payment operation based on the second order is introduced. The following will introduce this in detail.

[0144] Figure 6 It is another schematic flowchart of a payment method shown in an embodiment of this specification.

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

[0146] Step 602: Determine that the first order is not in an occupied state.

[0147] Step 604: Set the first order to an occupied state.

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

[0149] Step 608: 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 performs a payment operation in the payment interface popped up by the application according to the payment jump page address information.

[0150] In an embodiment of the present invention, the execution processes of step 600, step 604, and step 606 can refer to the execution processes of step 200, step 202, and step 204 in the foregoing embodiment, and will not be elaborated here.

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

[0152] 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. Among them, 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 identifier of the first user.

[0153] 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, generate a payment jump page corresponding to the payment platform according to the platform information of the payment platform of the application, so that the first user uses the application to perform payment operations according to the address information of the payment adjustment page, such as pulling up the payment cashier desk, etc., and then in the popped-up interface, perform operations such as entering the payment confirmation password.

[0154] In the embodiments of the present invention, different payment jump pages can be generated according to different payment platforms to implement payments on different payment platforms.

[0155] Of course, the function of the unified payment platform can also be implemented as a module of the execution subject in the embodiments of the present application.

[0156] In the embodiments of the present invention, it may further include:

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

[0158] Unlocking the data row of the database where the first order is located.

[0159] In the embodiments of the present invention, the timing of unlocking the data row can be set to after the unified platform accepts. Due to the limitations of the database itself, if the data row lock is occupied for a long time, problems such as slow database operation, redundant operation logs, and database crashes may occur. Therefore, the locking time should not be too long, such as 3 seconds, 50 milliseconds, etc. And in order to ensure the payment operation for the first order, the data row can be unlocked after the unified platform receives the payment code.

[0160] In the embodiments of the present invention, it may further include:

[0161] If after receiving the acceptance message returned by the unified payment platform, updating the non-payable time point according to the preset payment time parameter.

[0162] In the embodiments of the present invention, when receiving the acceptance message returned by the unified payment platform, the non-payable time point can be updated, where the preset payment time parameter can be set by referring to the preset payment time interval setting method in the foregoing embodiments. It can represent the payment operation duration of the user for the order.

[0163] In the embodiments of the present invention, it may further include:

[0164] When it is determined that the first user's payment is successful, setting the first order to the paid state.

[0165] In an embodiment of the present invention, it is also possible to asynchronously query the payment status of the unified payment platform. If it is determined that the payment for the second order is successful, the payment status of the second order is modified to paid, and at the same time, the first order is set to the paid status to complete the payment for 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 entity of the present invention, such as the code platform, and then determines whether the first user has successfully paid according to the received payment result.

[0166] In an embodiment of the present invention, it may further include:

[0167] If it is determined that the first user cancels the payment operation, obtain the cancellation time point corresponding to the first user when the cancellation payment operation is performed;

[0168] If it is determined that the cancellation time point is earlier than the non-payment time point, set the non-payment time point to the cancellation time point.

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

[0170] Figure 7 It is a swimlane diagram of a payment method shown in an embodiment of the present invention.

[0171] See Figure 7 , based on the payment method provided in the embodiments of the present application, the following process may be included in actual use:

[0172] The execution entity of the embodiment of the present invention, such as the code platform, receives the payment instruction of the first order sent by the first user scanning the order two-dimensional code of the target product at 10:00:00;

[0173] Obtain the database row lock and lock the order row;

[0174] Create a second payment form corresponding to the first order; generate the payment code of the second order and send it to the unified payment platform;

[0175] Receive the acceptance notice returned by the unified payment platform at 10:00:30, adjust the non-payment time point to 10:02; and unlock the order row.

[0176] The unified payment platform returns the payment jump page address according to the application of the first user, and the first user performs the payment operation according to the redirected interface.

[0177] After successful payment, the unified payment platform saves the payment result. After determining that the payment result is successful, the payment status of the second order is modified to "paid", and the payment status of the first order is modified to "paid", and the first user completes the payment.

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

[0179] If the database row lock of the first order cannot be obtained, a prompt message indicating that the payment is in progress is fed back to the third user.

[0180] At 10:03, the third user sends a payment instruction. After determining that the data row of the first order is not locked, it is further determined that the first order is in a paid state, and a prompt message indicating that the order has been paid is returned to the third user.

[0181] It can be seen that in the embodiments of the present invention, the order QR code can be reused while avoiding duplicate payments.

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

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

[0184] A receiving module 81, 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;

[0185] A setting module 82, configured to set the first order to an occupied state; wherein, when the first order is in the occupied state, payment instructions from users other than the first user are rejected;

[0186] 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;

[0187] A payment-on-behalf module 84, configured to perform a payment operation based on the second order.

[0188] Figure 9 For the embodiments of this specification to provide the corresponding Figure 2 structural schematic diagram of an electronic device. As Figure 9 shown, the electronic device 900 may include:

[0189] At least one processor 910; and,

[0190] A memory 930 communicatively connected to the at least one processor; wherein,

[0191] The memory 930 stores instructions 920 executable by the at least one processor 910, and when the instructions are executed by the at least one processor 910, the at least one processor 910 is enabled to:

[0192] Receive 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 a second user for the target product;

[0193] Set the first order to an occupied state; wherein, when the first order is in the occupied state, payment instructions from users other than the first user are refused to be executed;

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

[0195] Perform a payment operation based on the second order.

[0196] Each embodiment in this specification is described in a progressive manner. For parts that are the same or similar among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for Figure 9 the device shown, since it is basically similar to the method embodiment, the description is relatively simple. For related parts, reference can be made to the partial description of the method embodiment.

[0197] In the 1990s, it was obvious to distinguish whether an improvement in a technology was an improvement in hardware (e.g., improvement in circuit structures such as diodes, transistors, switches, etc.) or an improvement in software (improvement in method processes). However, with the development of technology, many improvements in method processes today can be regarded as direct improvements in hardware circuit structures. Almost all designers obtain the corresponding hardware circuit structures by programming the improved method processes into the hardware circuits. Therefore, it cannot be said that an improvement in a method process cannot be implemented with a hardware entity module. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logical function is determined by a user's programming of the device. Designers can program by themselves to "integrate" a digital character system on a piece of PLD without having to ask a chip manufacturer to design and fabricate a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in program development and writing. The original code before compilation also has to be written in a specific programming language, which is called a Hardware Description Language (HDL). And there is not only one kind of 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 currently are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also be clear that as long as the method process is slightly logically programmed with the above-mentioned several hardware description languages and programmed into the integrated circuit, it is easy to obtain the hardware circuit that implements the logical method process.

[0198] The controller can be implemented in any suitable manner. For example, the controller can take the form of, for example, a microprocessor or a processor and a computer-readable medium storing computer-readable program code (such as software or firmware) executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of the controller include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, 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 the form of pure computer-readable program code, it is entirely possible to make the controller implement the same function in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be regarded as the structures within the hardware component. Or even, the devices for implementing various functions can be regarded as either software modules for implementing the method or the structures within the hardware component.

[0199] The systems, devices, modules, or units illustrated in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer can 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 any combination of these devices.

[0200] For the convenience of description, the above devices are described by dividing them into 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.

[0201] Those skilled in the art should understand that the embodiments of the present invention can be provided as a method, a system, or a computer program product. Therefore, the present invention can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memories, CD-ROMs, optical memories, etc.) containing computer-usable program code.

[0202] The present invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each flow and / or block in the flowchart illustrations and / or block diagrams, and combinations of flows and / or blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to the processors of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions executed by the processors of the computer or other programmable data processing apparatus create means for implementing the functions specified in the flow Figure 1 one flow or multiple flows and / or blocks Figure 1 or means for implementing the functions specified in one block or multiple blocks.

[0203] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce a manufacture including instruction means that implement the functions specified in the flow Figure 1 one flow or multiple flows and / or blocks Figure 1 or means for implementing the functions specified in one block or multiple blocks.

[0204] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus, such that a series of operational steps are performed on the computer or other programmable apparatus to produce a computer-implemented process, and thus the instructions executed on the computer or other programmable apparatus provide steps for implementing the functions specified in the flow Figure 1 one flow or multiple flows and / or blocks Figure 1 or means for implementing the functions specified in one block or multiple blocks.

[0205] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and memory.

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

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

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

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

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

[0211] The above are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, various changes and modifications can be made to the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within 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 a second user for the target product; Setting the first order to an occupied state; wherein, when the first order is in the occupied state, payment instructions from users other than the first user are rejected; Creating a second order for the first user according to the order identifier of the first order in the occupied state; Performing a payment operation based on the second order.

2. The payment method according to claim 1, when the payment of the second order fails, it does not affect the state of the first order and the order QR code.

3. The payment method according to claim 1, before setting the first order to the occupied state, further comprising: Judging whether the first order is in the occupied state; If it is determined that the first order is not in the occupied state, then perform the step of setting the first order to the occupied state.

4. The payment method according to claim 3, the judging whether the first order is in the occupied state specifically includes: Judging whether the data row of 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 the occupied state.

5. The payment method according to claim 3, the judging whether the first order is in the occupied state specifically includes: Judging whether the current time point is earlier than the non-occupiable time point; The non-occupiable time point is used to represent the time point set when receiving the previous payment instruction; If it is determined that the current time point is not earlier than the non-occupiable time point, it is determined that the first order is not in the occupied state.

6. The payment method according to claim 1, setting the first order to the occupied state includes: Locking the data row of the database where the first order is located.

7. The payment method according to claim 1, setting the first order to the occupied state includes: Setting the non-occupiable time point to the sum of the current time point and a preset non-occupiable time parameter; The non-occupiable time point is used to represent the time point when payment instructions from users other than the first user can be executed; The preset non-occupiable time parameter is used to represent the duration of processing the payment instruction.

8. The payment method according to claim 3, if it is determined that the first order is in the occupied state, then sending a prompt message indicating that the first order is being processed to the first user.

9. The payment method according to claim 4, the method further includes: If it is determined that the data row is locked, then judging whether the data row of the database where the first order is located is locked after a preset waiting time interval; The determining that the first order is in the occupied state specifically includes: If the data row of the database where the first order is located is locked after a preset waiting time interval, then it is determined that the first order is in the occupied state.

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

11. The payment method according to claim 10, before determining whether the current time point is earlier than the non-payment time point, further includes: Determining whether the data row corresponding to the first order at the current time point has been unlocked; If it is determined that the data row has been unlocked, then execute the step of determining whether the current time point is earlier than the non-payment time point.

12. The payment method according to claim 10, the method further includes: If it is determined that the current time point is earlier than the non-payment time point, determining that the first order is in the payment process; Sending a prompt message indicating that the first order is being paid to the first user.

13. 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 includes: If it is determined that the first order has not been paid, determining that the first order is in a payable state; If it is determined that the first order has been paid, determining that the first order is not in a payable state; or, 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, determining that the first order is not in a payable state; Wherein, when the first order is in a payable state, the second order of the first user can be created according to the order identifier of the first order in the occupied state.

14. The payment method according to claim 13, the method further includes: If it is determined that the first order is not in a payable state, then sending a prompt message indicating that the first order has been paid to the first user; Or, If it is determined that the first order is not in a payable state, then sending a prompt message indicating that the first order cannot be paid to the first user.

15. The payment method according to claim 1, the performing a payment operation based on the second order specifically includes: Sending the payment code of the second order to the unified payment platform; the unified payment platform can generate payment jump page address information according to 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 a payment operation 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, the method further includes: Receiving the acceptance message returned by the unified payment platform; Unlock the data row of the database where the first order is located.

17. The payment method according to claim 10, the method further comprising: If an acceptance message returned by the unified payment platform is received, update the non-payment time point according to a preset payment time parameter.

18. The payment method according to claim 1, the method further comprising: When it is determined that the first user's payment is successful, set the first order to the paid state.

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

20. The payment method according to claim 1, the order identifier of the first order has a corresponding relationship with the order identifier of the second order; Or, there is an association relationship between the data table of the first order and the data table of the second order; Or, the first order can correspond to multiple second orders; Or, the payment instruction includes an order code, and the data tables of the first order and the second order have the same order code.

21. The payment method according to claim 1, the order QR code includes at least one of information of the target product, the amount of the target product, and the order number of the order corresponding to the target product.

22. The payment method according to claim 1, the first user is used to pay on behalf of the second user; Or, if the second order payment is successful, it means that the first order payment is completed.

23. 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 a second user for the target product; A setting module, configured to set the first order to an occupied state; wherein, when the first order is in the occupied state, the payment instruction of a user other than the first user is refused to be executed; A creating module, configured to create a second order of the first user according to the order identifier of the first order in the occupied state; A payment-on-behalf module, configured to perform a payment operation based on the second order.

24. An electronic device, comprising: At least one processor; And, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can: 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 a second user for the target product; Set the first order to an occupied state; wherein, when the first order is in the occupied state, the payment instruction of a user other than the first user is refused to be executed; Create a second order for the first user according to the order identifier of the first order in the occupied state; Perform a payment operation based on the second order.

25. A computer-readable medium having computer-readable instructions stored thereon, the computer-readable instructions being executable by a processor to implement a payment method according to any one of claims 1 to 22.

Images