A payment method, device, equipment, medium and product

Abstract

Embodiments of the present invention relate to the field of smart financial technology, and in particular to a payment method, device, equipment, medium and product. The method comprises: receiving a payment request sent by a client, wherein the payment request comprises: a target payment token, a merchant identification number, customer account identification information and a transaction amount; performing a first accounting according to the customer account identification information and the transaction amount, and obtaining a transaction flow corresponding to the first accounting, wherein the transaction flow comprises: an order number, and sending the order number to the client; receiving a payment confirmation request sent by the client, wherein the payment confirmation request comprises: a target payment token and an order number; performing a second accounting according to the target payment token, the order number and the merchant identification number. Through the technical solution of the present invention, the consistency of data during the payment process can be ensured in a low-latency and high-concurrency environment of the Internet of Things.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of smart financial technology, and in particular, to a payment method, device, equipment, medium and product. Background Art

[0002] With the development of Internet of Things technology, we are entering an era of interconnection of all things. Mobile payment has become popular, and various payment scenarios are being implemented at an accelerated pace. As various payment scenarios change, the payment systems that support their development are also undergoing profound changes.

[0003] From the transition from traditional monolithic architecture to microservice architecture, and then to the implementation of containerization technology today, in the face of the low latency and high concurrency characteristics of the Internet of Things, distributed application technology is being widely used in the payment field. Because it is easily affected by factors such as network latency, jitter, server concurrency pressure, and operation and maintenance, it is easy to cause inconsistent business data, repeated submissions, balance deadlocks, discrepancies between accounts and actuals, etc. From the perspective of payment business, the results of a single request or repeated multiple requests need to be consistent in business, that is, the idempotence of the payment process needs to be guaranteed.

[0004] In the existing technology, the idempotence control of the payment process is generally achieved through database row-level locks. Database row-level locks have unique advantages in traditional single applications or low concurrency situations, but database row-level locks have limited concurrency and are prone to single point failures. Summary of the invention

[0005] The embodiments of the present invention provide a payment method, device, equipment, medium and product to solve the problem of single point failure that is prone to occur due to maintaining the consistency of multiple payment request results through database row-level locks, and can ensure the consistency of data during the payment process in a low-latency and high-concurrency environment of the Internet of Things.

[0006] According to one aspect of the present invention, there is provided a payment method, comprising:

[0007] Receiving a payment request sent by a client, wherein the payment request includes: a target payment token, a merchant identification number, customer account identification information, and a transaction amount;

[0008] Performing a first accounting according to the customer account identification information and the transaction amount, obtaining a transaction flow corresponding to the first accounting, wherein the transaction flow includes: an order number, and sending the order number to the client;

[0009] Receiving a payment confirmation request sent by the client, wherein the payment confirmation request includes: a target payment token and an order number;

[0010] A second accounting is performed according to the target payment token, the order number and the merchant identification number.

[0011] Furthermore, the first accounting is performed according to the customer account identification information and the transaction amount to obtain a transaction flow corresponding to the first accounting, including:

[0012] Determine a customer account according to the customer account identification information, and lock the customer account;

[0013] Obtaining the account status and account balance of the customer account;

[0014] If the account status of the customer account is normal and the account balance is greater than the transaction amount, the transaction amount in the customer account will be transferred to the transition account to generate a transaction flow, wherein the transaction flow includes: serial number, order number, target payment token, customer account identification information, merchant identification number, client identification number and transaction amount.

[0015] Furthermore, if the account status of the customer account is normal and the account balance is greater than the transaction amount, the transaction amount in the customer account is transferred to the transition account, and after the transaction flow is generated, the method further includes:

[0016] If the target confirmation information sent by the client is not received within the preset time, the transaction amount in the transition account will be transferred back to the customer account.

[0017] Furthermore, if the account status of the customer account is normal and the account balance is greater than the transaction amount, the transaction amount in the customer account is transferred to the transition account, and after the transaction flow is generated, the method further includes:

[0018] Unlock the customer account.

[0019] Further, sending the order number to the client includes:

[0020] Sending the order number and the accounting success status code to the client;

[0021] Receive target confirmation information sent by the client.

[0022] Furthermore, before receiving the payment request sent by the client, the following steps are also included:

[0023] Receiving a token acquisition request sent by the client, wherein the token acquisition request includes: a client type and a client identification number;

[0024] At least one payment token is generated according to the client type and the client identification number.

[0025] Further, after generating at least one payment token according to the client type and the client identification number, the method further includes:

[0026] If at least two payment tokens are generated, the at least two payment tokens are stored in a local database.

[0027] Further, generating at least one payment token according to the client type and the client identification number includes:

[0028] Determining a target payment token quantity according to the client type;

[0029] Generate a payment token corresponding to the target payment token quantity according to the client type and the client identification number.

[0030] Further, the second accounting according to the target payment token, the order number and the merchant identification number includes:

[0031] Obtaining the transaction flow corresponding to the target payment token, wherein the transaction flow also includes: the first accounting time;

[0032] If the difference between the current time and the first accounting time is less than the difference threshold, determining the merchant account according to the merchant identification number;

[0033] Locking the merchant account;

[0034] Transferring the transaction amount in the transition account to the merchant account;

[0035] The merchant account is unlocked.

[0036] Further, if the difference between the current time and the first accounting time is less than the difference threshold, determining the merchant account according to the merchant identification number includes:

[0037] If the target confirmation information sent by the client is received and the difference between the current time and the first accounting time is less than the difference threshold, the merchant account is determined according to the merchant identification number, wherein the target confirmation information is information confirming the transfer of transaction information to the transition account.

[0038] Furthermore, it also includes:

[0039] Conducting a delayed account audit on the customer account;

[0040] Conducting a delayed account audit on the merchant account;

[0041] Conduct delayed account audit on the transitional accounts.

[0042] Furthermore, a delayed account audit is conducted on the transition account, including:

[0043] Obtain the account balance of the transition account on the previous day;

[0044] If the account balance of the transition account is non-zero, a prompt message is generated.

[0045] According to another aspect of the present invention, there is provided a payment device, the payment device comprising:

[0046] A first receiving module, configured to receive a payment request sent by a client, wherein the payment request includes: a target payment token, a merchant identification number, customer account identification information, and a transaction amount;

[0047] A first accounting module is used to perform a first accounting according to the customer account identification information and the transaction amount, and obtain a transaction flow corresponding to the first accounting, wherein the transaction flow includes: an order number, and the order number is sent to the client;

[0048] A second receiving module is used to receive a payment confirmation request sent by the client, wherein the payment confirmation request includes: a target payment token and an order number;

[0049] The second accounting module is used to perform a second accounting according to the target payment token, the order number and the merchant identification number.

[0050] Furthermore, the first accounting module is specifically used for:

[0051] Determine a customer account according to the customer account identification information, and lock the customer account;

[0052] Obtaining the account status and account balance of the customer account;

[0053] If the account status of the customer account is normal and the account balance is greater than the transaction amount, the transaction amount in the customer account will be transferred to the transition account to generate a transaction flow, wherein the transaction flow includes: serial number, order number, target payment token, customer account identification information, merchant identification number, client identification number and transaction amount.

[0054] Furthermore, the first accounting module is specifically used for:

[0055] If the target confirmation information sent by the client is not received within the preset time, the transaction amount in the transition account will be transferred back to the customer account.

[0056] Furthermore, the first accounting module is specifically used for:

[0057] Unlock the customer account.

[0058] Furthermore, the first accounting module is specifically used for:

[0059] Sending the order number and the accounting success status code to the client;

[0060] Receive target confirmation information sent by the client.

[0061] Furthermore, it also includes:

[0062] A third receiving module is used to receive a token acquisition request sent by the client before receiving the payment request sent by the client, wherein the token acquisition request includes: a client type and a client identification number;

[0063] A generating module is used to generate at least one payment token according to the client type and the client identification number.

[0064] Furthermore, it also includes:

[0065] The storage module is used for storing the at least two payment tokens in a local database after generating at least one payment token according to the client type and the client identification number, if at least two payment tokens are generated.

[0066] Furthermore, the generation module is specifically used for:

[0067] Determining a target payment token quantity according to the client type;

[0068] Generate a payment token corresponding to the target payment token quantity according to the client type and the client identification number.

[0069] Furthermore, the second accounting module is specifically used for:

[0070] Obtaining the transaction flow corresponding to the target payment token, wherein the transaction flow also includes: the first accounting time;

[0071] If the difference between the current time and the first accounting time is less than the difference threshold, determining the merchant account according to the merchant identification number;

[0072] Locking the merchant account;

[0073] Transferring the transaction amount in the transition account to the merchant account;

[0074] The merchant account is unlocked.

[0075] Furthermore, the second accounting module is specifically used for:

[0076] If the target confirmation information sent by the client is received and the difference between the current time and the first accounting time is less than the difference threshold, the merchant account is determined according to the merchant identification number, wherein the target confirmation information is information confirming the transfer of transaction information to the transition account.

[0077] Furthermore, the second accounting module is specifically used for:

[0078] Conducting a delayed account audit on the customer account;

[0079] Conducting a delayed account audit on the merchant account;

[0080] Conduct delayed account audit on the transitional accounts.

[0081] Furthermore, the second accounting module is specifically used for:

[0082] Obtain the account balance of the transition account on the previous day;

[0083] If the account balance of the transition account is non-zero, a prompt message is generated.

[0084] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0085] at least one processor; and

[0086] a memory communicatively connected to the at least one processor; wherein,

[0087] The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the payment method described in any embodiment of the present invention.

[0088] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the payment method described in any embodiment of the present invention when executed.

[0089] According to another aspect of the present invention, a computer program product is provided. When the computer program is executed by a processor, the computer program implements the payment method as described in any one of the embodiments of the present invention.

[0090] The embodiment of the present invention receives a payment request sent by a client, wherein the payment request includes: a target payment token, a merchant identification number, customer account identification information and a transaction amount; performs a first accounting according to the customer account identification information and the transaction amount, and obtains a transaction flow corresponding to the first accounting, wherein the transaction flow includes: an order number, and sends the order number to the client; receives a payment confirmation request sent by the client, wherein the payment confirmation request includes: a target payment token and an order number; performs a second accounting according to the target payment token, the order number and the merchant identification number, thereby solving the problem of single point failure that is prone to occur due to maintaining consistency of results of multiple payment requests through database row-level locks, and can ensure the consistency of payment data in a low-latency and high-concurrency environment of the Internet of Things.

[0091] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present invention, nor are they intended to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0092] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for use in the embodiments are briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without creative work.

[0093] Figure 1 is a flow chart of a payment method in an embodiment of the present invention;

[0094] Figure 2 This is a flowchart of the first accounting in an embodiment of the present invention;

[0095] Figure 3 is a timing diagram of the delayed automatic reversal processing process in an embodiment of the present invention;

[0096] Figure 4 is a schematic diagram of the timing of the payment method in an embodiment of the present invention;

[0097] Figure 5 This is a flowchart of the second accounting in an embodiment of the present invention;

[0098] Figure 6 is a timing diagram of the asynchronous accounting processing process in an embodiment of the present invention;

[0099] Figure 7 is a time sequence diagram of delayed accounting audit in an embodiment of the present invention;

[0100] Figure 8is a diagram of the daily settlement process in an embodiment of the present invention;

[0101] Fig. 9 is a schematic diagram of the structure of a payment device in an embodiment of the present invention;

[0102] Fig.10 It is a structural schematic diagram of an electronic device in an embodiment of the present invention. DETAILED DESCRIPTION

[0103] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0104] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0105] The acquisition, storage and / or processing of data in the technical solutions involved in this application comply with the relevant provisions of national laws and regulations.

[0106] Embodiment 1

[0107] Figure 1 A flow chart of a payment method provided in an embodiment of the present invention. This embodiment is applicable to payment situations. The method can be executed by a payment device in an embodiment of the present invention. The device can be implemented in software and / or hardware. Figure 1 As shown, the payment method specifically includes the following steps:

[0108] S110, receiving a payment request sent by a client, wherein the payment request includes: a target payment token, a merchant identification number, customer account identification information, and a transaction amount.

[0109] The client is a payment terminal, which may be a POS terminal or other payment devices.

[0110] Among them, the payment token is a token issued by the server to the client for idempotence control. It is globally unique and only one token can be used for a single transaction. After the server receives the payment request sent by the client, it further identifies whether it is the same transaction through the payment token.

[0111] The target payment token may be obtained by: the client sends a token acquisition request to the server, wherein the token acquisition request includes: the client type and the client identification number, the server receives the token acquisition request, the server generates at least one payment token according to the client type and the client identification number, and determines any one of the at least one payment token as the target payment token. The target payment token may also be obtained by: obtaining a payment token from the client local cache, and if the obtained payment token is valid, determining the obtained payment token as the target payment token, which is not limited in this embodiment of the present invention.

[0112] Among them, the merchant account identification information can be obtained according to the merchant identification number.

[0113] The customer account identification information may be payment account identification information, for example, a bank card number corresponding to the payment account.

[0114] S120, performing a first accounting according to the customer account identification information and the transaction amount, and obtaining a transaction flow corresponding to the first accounting, wherein the transaction flow includes: an order number, and sending the order number to the client.

[0115] Specifically, the first accounting is performed according to the customer account identification information and the transaction amount, and a method for obtaining the transaction flow corresponding to the first accounting can be: determining the customer account according to the customer account identification information, and locking the customer account; obtaining the account status and account balance of the customer account; if the account status of the customer account is normal, and the account balance is greater than the transaction amount, transferring the transaction amount in the customer account to a transition account to generate a transaction flow, wherein the transaction flow includes: a serial number, an order number, a target payment token, customer account identification information, a merchant identification number, a client identification number, and a transaction amount. The first accounting is performed according to the customer account identification information and the transaction amount, and the method for obtaining the transaction flow corresponding to the first accounting can also be: determine the customer account according to the customer account identification information, and lock the customer account; obtain the account status and account balance of the customer account; if the account status of the customer account is normal, and the account balance is greater than the transaction amount, then transfer the transaction amount in the customer account to the transition account to generate a transaction flow, wherein the transaction flow includes: serial number, order number, target payment token, customer account identification information, merchant identification number, client identification number and transaction amount. If the target confirmation information sent by the client is not received within the preset time, the transaction amount in the transition account is transferred back to the customer account; unlock the customer account, which is not limited in the embodiment of the present invention.

[0116] Specifically, the order number may be sent to the client in the following manner: when the first accounting is successful, the server sends the order number to the client; the order number may also be sent to the client in the following manner: when the first accounting is successful, the server sends the order number and the accounting success status code to the client. Wherein, accounting success means: successfully transferring the transaction amount in the customer account to the transition account.

[0117] Exemplarily, after storing the transaction flow, the server returns the first accounting result to the client, where if the first accounting fails, the first accounting result is: error information status code; if the first accounting is successful, the first accounting result is: order number and accounting success status code, where accounting failure means: due to customer account abnormalities and / or insufficient customer account balance, the customer account cannot transfer the transaction amount to the transition account.

[0118] S130, receiving a payment confirmation request sent by the client, wherein the payment confirmation request includes: a target payment token and an order number.

[0119] Among them, the target payment token in the payment confirmation request and the target payment token in the payment request are the same, and are determined to be the same transaction.

[0120] Specifically, the method for receiving the payment confirmation request sent by the client may be: after the client receives the first accounting result sent by the server, the client generates a payment confirmation request according to the order number in the first accounting result, the client sends the payment confirmation request to the server, and the server receives the payment confirmation request sent by the client. The method for receiving the payment confirmation request sent by the client may also be: after the server sends the order number to the client and the client feeds back the target confirmation information to the server, the client generates a payment confirmation request according to the order number, and the client sends the payment confirmation request to the server.

[0121] S140, performing a second accounting according to the target payment token, the order number and the merchant identification number.

[0122] Specifically, the method for performing the second accounting according to the target payment token, the order number and the merchant identification number can be: obtaining the transaction flow corresponding to the target payment token, wherein the transaction flow also includes: the first accounting time; if the difference between the current time and the first accounting time is less than the difference threshold, determining the merchant account according to the merchant identification number; locking the merchant account; transferring the transaction amount in the transition account to the merchant account; and unlocking the merchant account.

[0123] It should be noted that since the secondary accounting method is an asynchronous mode, it can further improve the system's responsiveness.

[0124] Optionally, performing a first accounting according to the customer account identification information and the transaction amount to obtain a transaction flow corresponding to the first accounting includes:

[0125] Determine a customer account according to the customer account identification information, and lock the customer account;

[0126] Obtaining the account status and account balance of the customer account;

[0127] If the account status of the customer account is normal and the account balance is greater than the transaction amount, the transaction amount in the customer account will be transferred to the transition account to generate a transaction flow, wherein the transaction flow includes: serial number, order number, target payment token, customer account identification information, merchant identification number, client identification number and transaction amount.

[0128] The account status may be a normal status or an abnormal status. For example, if the customer account is locked or the customer account is cancelled, it is determined that the account status of the customer account is an abnormal status.

[0129] Specifically, the method of determining the customer account according to the customer account identification information may be: pre-establishing a database of the correspondence between the customer account identification information and the customer account, and querying the database according to the customer account identification information to obtain the customer account.

[0130] It should be noted that in the process of transferring the transaction amount in the customer account to the transition account, the customer account needs to be locked through a locking mechanism to prevent account misuse. The customer account is unlocked after the first accounting is completed. The first accounting is the process in which the server further withholds funds from the customer account after receiving the payment request, transfers the transaction amount to the transition account, and generates transaction flow information at the same time.

[0131] The method of locking the customer account may be: locking the customer account, for example, adding a distributed read-write lock to the customer account. During account query and account processing, other threads cannot query and operate the locked customer account until the customer account is unlocked. The customer account is locked to prevent dirty reading and dirty writing.

[0132] Among them, due to the large number of transaction flows, in order to improve the response time, built-in sharding information is used to facilitate quick search of transaction flows and improve parallel processing capabilities.

[0133] In a specific example, Figure 2 As shown, the client sends a payment request to the server. After the server receives the payment request, it first locks the customer account. Before that, if the customer account is locked, it further waits until the lock is successful. After the customer account is successfully locked, the account status and account balance of the customer account are queried, and whether the payment conditions are met is further determined according to the account status and account balance, that is, whether the account is available and whether the balance is sufficient through the account status and account balance. If the payment conditions are not met, an error message is immediately returned to the client. If the payment conditions are met, the customer account is pre-deducted, and the deducted transaction amount is transferred to the transition account. After the customer account is deducted, a payment flow is generated. The payment flow information should at least include: flow number, order number, target payment token, customer account identification information, merchant identification number, client identification number and transaction amount, and the customer account is unlocked. After the first accounting is completed, the server sends the first accounting result to the client, and starts the delayed automatic reversal at the same time.

[0134] Optionally, if the account status of the customer account is normal and the account balance is greater than the transaction amount, the transaction amount in the customer account is transferred to a transition account, and after the transaction flow is generated, the method further includes:

[0135] If the target confirmation information sent by the client is not received within the preset time, the transaction amount in the transition account will be transferred back to the customer account.

[0136] The preset time is a pre-set time, which is not limited in the embodiment of the present invention.

[0137] Specifically, if the target confirmation information sent by the client is not received within the preset time, the transaction amount in the transition account may be transferred back to the customer account as follows: after the client receives the order number and the accounting success status code sent by the server, if the client does not send the target confirmation information to the server within the preset time, the transaction amount in the transition account may be transferred back to the customer account.

[0138] Specifically, after the transaction amount in the customer account is transferred to the transition account and the transaction flow is generated, the delayed automatic reversal is started. The delayed automatic reversal is the first accounting automatic rollback mechanism, that is, if the payment transaction does not receive the target confirmation information fed back by the client within the preset time, the first accounting rollback is automatically started to transfer the transaction amount from the transition account to the customer account.

[0139] In a specific example, Figure 3As shown, the server includes: a first accounting unit, a second accounting unit, a message middleware, a cache middleware and an account processing unit. The message middleware and the cache middleware are general components, which are used for message distribution and distributed locks respectively. The message middleware produces delayed automatic reversal messages, the account processing unit subscribes to delayed automatic reversal messages, the account processing unit consumes delayed automatic reversal messages, and starts delayed reversal. The account processing unit obtains the transaction status in the state lock from the cache middleware, wherein the transaction status in the state lock refers to whether the target confirmation information sent by the client is received. According to the transaction status in the state lock, it is judged whether the reversal conditions are met. If the reversal conditions are met, the transaction status in the transaction flow is obtained. If the transaction status in the transaction flow is to transfer the transaction amount from the customer account to the transition account, the reversal is performed, that is, the transaction amount is transferred from the transition account back to the customer account. If the reversal conditions are not met, no reversal is required. Among them, the reversal conditions are met means that the target confirmation information sent by the client is not received within the preset time, and the reversal conditions are not met means that the target confirmation information sent by the client is received within the preset time. After the first accounting unit completes the accounting process, the first accounting unit sends a delayed automatic reversal message to the message middleware. The delayed reversal is controlled by the message delay. If it is set to 60 seconds, the delayed reversal will be automatically started after 60 seconds. After the second accounting unit receives the payment confirmation request, it further updates the transaction status of the state lock. After the message middleware delays the production of the delayed automatic reversal message, it is consumed by the accounting processing unit, thereby triggering the delayed reversal transaction. After the delayed reversal transaction is started, the transaction status of the state lock is further obtained to determine whether the reversal conditions are met. If the reversal conditions are not met, no reversal is required and the delayed reversal is invalid. In actual applications, the aforementioned verification and reversal conditions can also use other conditions, such as the transition account's payment transaction status, to prevent repeated consumption of the server-side delayed automatic reversal message, resulting in the failure of idempotence control.

[0140] Optionally, if the account status of the customer account is normal and the account balance is greater than the transaction amount, the transaction amount in the customer account is transferred to a transition account, and after the transaction flow is generated, the method further includes:

[0141] Unlock the customer account.

[0142] Specifically, the customer account may be unlocked by releasing a distributed read-write lock, after which the customer account is in a readable and writable state.

[0143] Optionally, sending the order number to the client includes:

[0144] Sending the order number and the accounting success status code to the client;

[0145] Receive target confirmation information sent by the client.

[0146] Specifically, after the server sends the order number and the accounting success status code to the client, if the client detects a user's touch operation on a confirmation control on the current interface, target confirmation information is generated, and the client sends the target confirmation information to the server.

[0147] Optionally, before receiving the payment request sent by the client, the following is also included:

[0148] Receiving a token acquisition request sent by the client, wherein the token acquisition request includes: a client type and a client identification number;

[0149] At least one payment token is generated according to the client type and the client identification number.

[0150] Specifically, the method of generating at least one payment token according to the client type and the client identification number can be: determining the target payment token quantity according to the client type; generating payment tokens corresponding to the target payment token quantity according to the client type and the client identification number. The method of generating at least one payment token according to the client type and the client identification number can also be: after receiving the token acquisition request sent by the client, the server verifies the legitimacy of the client, and after the verification is passed, the server generates at least one payment token according to the client type and the client identification number.

[0151] It should be noted that after the server generates at least one payment token according to the client type and the client identification number, the server sends the at least one payment token to the client, and the client receives the at least one payment token returned by the server, and the client determines whether to cache it locally according to the number of returned payment tokens. For example, if a payment token is generated according to the client type and the client identification number, the generated payment token is determined as the target payment token; if at least two payment tokens are generated according to the client type and the client identification number, the payment token is cached locally on the client.

[0152] The client only uses one payment token in a single transaction. That is, if the server receives multiple requests, as long as the payment tokens are consistent, it will be considered as the same transaction and there will be no repeated payment.

[0153] Optionally, after generating at least one payment token according to the client type and the client identification number, the method further includes:

[0154] If at least two payment tokens are generated, the at least two payment tokens are stored in a local database.

[0155] Specifically, if at least two payment tokens are generated, the at least two payment tokens are stored in a local database, so that the client can directly obtain the payment token from the local database when performing another transaction, thereby saving the time for obtaining the payment token.

[0156] Optionally, generating at least one payment token according to the client type and the client identification number includes:

[0157] Determining a target payment token quantity according to the client type;

[0158] Generate a payment token corresponding to the target payment token quantity according to the client type and the client identification number.

[0159] Specifically, the method of determining the target number of payment tokens according to the client type may be: pre-establishing a database of the correspondence between the client type and the number of payment tokens, querying the database according to the client type, and obtaining the target number of payment tokens.

[0160] It should be noted that different client types may result in different numbers of generated payment tokens, and the number of generated payment tokens is related to the processing capability of the client.

[0161] In a specific example, Figure 4As shown, the client sends a token acquisition request to the server, wherein the token acquisition request includes: client type and client identification number. After receiving the token acquisition request, the server generates at least one payment token according to the client type and client identification number, and sends the generated at least one payment token to the client. After the client obtains at least one payment token, if there is only one payment token, a payment request is generated according to the payment token, and the payment request is sent to the server, wherein the payment request includes: target payment token, merchant identification number, customer account identification information and transaction amount; if there are at least two payment tokens, a payment token is selected from at least two payment tokens to generate a payment request, and the payment request is sent to the server, and the remaining payment tokens are stored in the client local cache. After receiving the payment request, the server determines the customer account according to the customer account identification information, locks the customer account, and performs the first accounting. After the first accounting is completed, the customer account is unlocked, the delayed reversal is started, and the first accounting result is sent to the client, wherein the first accounting result includes: accounting success status code and order number. After receiving the successful accounting status code and order number, the client sends a payment confirmation request to the server, wherein the payment confirmation request includes: the target payment token and the order number. After receiving the payment confirmation request, the server starts the second accounting and initiates a delayed accounting audit at the same time. After the second accounting is completed, the server sends the payment confirmation result to the client. After receiving the payment confirmation result sent by the server, the client feeds back the payment result information to the server.

[0162] Optionally, the second accounting according to the target payment token, the order number and the merchant identification number includes:

[0163] Obtaining the transaction flow corresponding to the target payment token, wherein the transaction flow also includes: the first accounting time;

[0164] If the difference between the current time and the first accounting time is less than the difference threshold, determining the merchant account according to the merchant identification number;

[0165] Locking the merchant account;

[0166] Transferring the transaction amount in the transition account to the merchant account;

[0167] The merchant account is unlocked.

[0168] The method for obtaining the transaction flow corresponding to the target payment token may be: carrying the payment token in the transaction flow, and querying the transaction flow carrying the target payment token according to the target payment token.

[0169] Specifically, if the difference between the current time and the first accounting time is less than the difference threshold, the method of determining the merchant account according to the merchant identification number can be: the transaction flow includes: transaction status and the first accounting time, if the transaction status can be any one of pending transaction, confirmed transaction and invalid transaction. If the transaction status is a confirmed transaction, and the difference between the current time and the first accounting time is less than the difference threshold, the merchant account is determined according to the merchant identification number. Among them, pending transaction means: after the server sends the order number and the accounting success status code to the client, it does not receive the target confirmation information sent by the client; confirmed transaction means: after the server sends the order number and the accounting success status code to the client, it has received the target confirmation information sent by the client. Invalid transaction means: after the server sends the order number and the accounting success status code to the client, the transaction amount in the transition account is transferred back to the customer account.

[0170] It should be noted that in the process of transferring the transaction amount in the transition account to the merchant account, the merchant account needs to be locked through a locking mechanism to prevent account misuse. The merchant account will be unlocked after the second accounting is completed.

[0171] The merchant account may be locked by adding a distributed read-write lock to the merchant account. During account query and account processing, other threads cannot query and operate the locked merchant account until the merchant account is unlocked. The merchant account is locked to prevent dirty reading and dirty writing.

[0172] The merchant account may be unlocked by releasing a distributed read-write lock, after which the merchant account is in a readable and writable state.

[0173] It should be noted that when the server completes the second accounting, it confirms that the payment transaction is officially completed. In order to improve the system processing capability, the accounting processing mode of the second accounting is asynchronous mode, and idempotence control is performed through delayed accounting auditing.

[0174] Optionally, if the difference between the current time and the first accounting time is less than a difference threshold, determining the merchant account according to the merchant identification number includes:

[0175] If the target confirmation information sent by the client is received and the difference between the current time and the first accounting time is less than the difference threshold, the merchant account is determined according to the merchant identification number, wherein the target confirmation information is information confirming the transfer of transaction information to the transition account.

[0176] Specifically, if the target confirmation information sent by the client is received, and the difference between the current time and the first accounting time is less than the difference threshold, the merchant account is determined according to the merchant identification number in the following manner: if the target confirmation information sent by the client is received within a preset time, and the difference between the current time and the first accounting time is less than the difference threshold, the merchant account is determined according to the merchant identification number. For example, after the first accounting is completed, the server sends the order number and the accounting success status code to the client, and after the client receives the order number and the accounting success status code sent by the server, the client sends the target confirmation information to the server, and if the server receives the target confirmation information sent by the client, and the difference between the current time and the first accounting time is less than the difference threshold, the merchant account is determined according to the merchant identification number.

[0177] Specifically, the merchant account may be determined according to the merchant identification number by pre-building a database of the correspondence between the merchant identification number and the merchant account, and querying the database according to the merchant identification number to obtain the merchant account.

[0178] In a specific example, Figure 5 As shown, the client sends a payment confirmation request to the server. After the server receives the payment confirmation request, it first terminates the delayed reversal started after the first accounting. If the delayed reversal uses a delayed distributed message, based on the non-deletable characteristics of the distributed message, a distributed state lock can be used. While starting the aforementioned delayed transaction, a distributed state lock is added. The lock information at least includes the payment transaction token and the transaction status. The delayed reversal transaction can be terminated by setting the transaction status. Querying the first accounting information refers to: querying the transaction flow corresponding to the first accounting, wherein the transaction flow also includes: the first accounting time, which is judged by the transaction token, transaction status and the first accounting time in the aforementioned distributed state lock. When it is determined that the automatic reversal has been completed, it is determined to be timed out, and the payment confirmation failure information is returned to the client. When it is determined that the delayed reversal has been terminated, and the difference between the current time and the first accounting time is less than the difference threshold, it is determined that it has not timed out, and the secondary accounting process is started. The secondary accounting process is an asynchronous accounting process, including customer accounting processing, merchant accounting processing and transition account processing. When secondary accounting is started, delayed account audit is started at the same time, mainly to audit the secondary accounting results to confirm that the accounting information is aligned with the transaction records, and return the payment confirmation result to the client. The confirmation result is the payment success status. After receiving the returned payment result, the customer confirms that the payment is successful.

[0179] Optionally, also include:

[0180] Conducting a delayed account audit on the customer account;

[0181] Conducting a delayed account audit on the merchant account;

[0182] Conduct delayed account audit on the transitional accounts.

[0183] Specifically, delayed accounting audit is initiated, which is mainly a secondary accounting data audit to confirm that the accounting information is aligned with the transaction records.

[0184] Specifically, the method of performing delayed account audit on the customer account may be: while starting the second accounting, initiating a delayed account audit message to perform delayed account audit on the customer account.

[0185] It should be noted that if any abnormality is found during the account audit process, the wrong account will be processed.

[0186] Specifically, the method of performing delayed account audit on the transition account may be: obtaining the account balance of the transition account on the previous day; if the account balance of the transition account is non-zero, generating a prompt message.

[0187] In a specific example, Figure 6 As shown, in order to improve the system processing performance, the second accounting process is an asynchronous processing mode. Based on this, in the accounting processing process, asynchronous accounting processing is performed through a message mechanism. The process involves a second accounting unit, a message middleware, and an accounting processing unit. After the second accounting unit starts the secondary accounting process, the second accounting unit sends a secondary accounting message to the message middleware. Synchronously, the second accounting unit sends a delayed audit message to the message middleware, that is, the start of the secondary accounting process is completed, and the second accounting unit sends a payment confirmation result to the client. The secondary accounting information should at least include: serial number, order number, target payment token, customer account identification information, merchant identification number, client identification number, transaction amount, and first accounting time. The message middleware produces a secondary accounting message, which is consumed by the accounting processing unit to start the secondary accounting. The secondary accounting includes: customer accounting processing, merchant accounting processing, transition account accounting processing, etc.

[0188] In a specific example, Figure 7 As shown, the second accounting data audit is performed to confirm that the accounting information is aligned with the flow record. The process involves the message middleware, the accounting processing unit and the accounting audit unit. After a specified delay, the message middleware produces an audit message, which is consumed by the accounting audit unit and starts the delayed accounting audit process. If an abnormality is found during the accounting audit process, the accounting processing unit will handle the wrong account. After completing the accounting process audit and wrong account handling, the accounting audit unit will perform an accounting integrity check again to complete the accounting audit process.

[0189] Optionally, a delayed account audit is performed on the transition account, including:

[0190] Obtain the account balance of the transition account on the previous day;

[0191] If the account balance of the transition account is non-zero, a prompt message is generated.

[0192] In a specific example, Figure 8 As shown, Figure 8 The following is a time chart of daily settlement processing. The server includes: a daily settlement processing unit, which is used to check the consistency of the final payment transaction data of the first accounting and the second accounting of the day. The daily settlement processing unit is started on time the next day. When started, the data of the previous day is fully checked. The end-of-day transfer includes: customer data aggregation, merchant data aggregation, and transaction data settlement, among which the transaction data settlement includes: transition account balance, and the transition account balance means that the final balance of the day should be zero. If it is not zero, the final manual account processing is required. After checking the balance of the transition account, the end-of-day transfer is completed. The daily settlement processing unit can also be started after the longest validity period of a single business.

[0193] The daily settlement processing unit is used for daily settlement processing and checking the global account processing results of the day. The daily settlement processing unit can prevent the accounting inconsistency caused by various factors such as system downtime, network failure and middleware failure. It is necessary to check the first and second accounting of the day to make the final payment transaction data consistent.

[0194] The technical solution of this embodiment is to receive a payment request sent by a client, wherein the payment request includes: a target payment token, a merchant identification number, a customer account identification information and a transaction amount; perform a first accounting according to the customer account identification information and the transaction amount, and obtain a transaction flow corresponding to the first accounting, wherein the transaction flow includes: an order number, and send the order number to the client; receive a payment confirmation request sent by the client, wherein the payment confirmation request includes: a target payment token and an order number; perform a second accounting according to the target payment token, the order number and the merchant identification number, which solves the problem of single point failure that is prone to occur due to maintaining consistency in the results of multiple payment requests through database row-level locks, can prevent secondary payment and distributed transaction failure in an Internet of Things environment, improve payment capabilities, and effectively solve low latency and high concurrency, and even ensure the consistency of business data in the payment process under extremely high concurrency conditions.

[0195] Embodiment 2

[0196] Fig. 9This is a schematic diagram of the structure of a payment device provided by an embodiment of the present invention. This embodiment is applicable to payment situations. The device can be implemented in software and / or hardware. The device can be integrated in any device that provides payment functions, such as Fig. 9 As shown, the payment device specifically includes: a first receiving module 210, a first accounting module 220, a second receiving module 230 and a second accounting module 240.

[0197] The first receiving module is used to receive a payment request sent by a client, wherein the payment request includes: a target payment token, a merchant identification number, customer account identification information, and a transaction amount;

[0198] A first accounting module is used to perform a first accounting according to the customer account identification information and the transaction amount, and obtain a transaction flow corresponding to the first accounting, wherein the transaction flow includes: an order number, and the order number is sent to the client;

[0199] A second receiving module is used to receive a payment confirmation request sent by the client, wherein the payment confirmation request includes: a target payment token and an order number;

[0200] The second accounting module is used to perform a second accounting according to the target payment token, the order number and the merchant identification number.

[0201] Optionally, the first accounting module is specifically used for:

[0202] Determine a customer account according to the customer account identification information, and lock the customer account;

[0203] Obtaining the account status and account balance of the customer account;

[0204] If the account status of the customer account is normal and the account balance is greater than the transaction amount, the transaction amount in the customer account will be transferred to the transition account to generate a transaction flow, wherein the transaction flow includes: serial number, order number, target payment token, customer account identification information, merchant identification number, client identification number and transaction amount.

[0205] Optionally, the first accounting module is specifically used for:

[0206] If the target confirmation information sent by the client is not received within the preset time, the transaction amount in the transition account will be transferred back to the customer account.

[0207] Optionally, the first accounting module is specifically used for:

[0208] Unlock the customer account.

[0209] Optionally, the first accounting module is specifically used for:

[0210] Sending the order number and the accounting success status code to the client;

[0211] Receive target confirmation information sent by the client.

[0212] Optionally, also include:

[0213] A third receiving module is used to receive a token acquisition request sent by the client before receiving the payment request sent by the client, wherein the token acquisition request includes: a client type and a client identification number;

[0214] A generating module is used to generate at least one payment token according to the client type and the client identification number.

[0215] Optionally, also include:

[0216] The storage module is used for storing the at least two payment tokens in a local database after generating at least one payment token according to the client type and the client identification number, if at least two payment tokens are generated.

[0217] Optionally, the generating module is specifically used for:

[0218] Determining a target payment token quantity according to the client type;

[0219] Generate a payment token corresponding to the target payment token quantity according to the client type and the client identification number.

[0220] Optionally, the second accounting module is specifically used for:

[0221] Obtaining the transaction flow corresponding to the target payment token, wherein the transaction flow also includes: the first accounting time;

[0222] If the difference between the current time and the first accounting time is less than the difference threshold, determining the merchant account according to the merchant identification number;

[0223] Locking the merchant account;

[0224] Transferring the transaction amount in the transition account to the merchant account;

[0225] The merchant account is unlocked.

[0226] Optionally, the second accounting module is specifically used for:

[0227] If the target confirmation information sent by the client is received and the difference between the current time and the first accounting time is less than the difference threshold, the merchant account is determined according to the merchant identification number, wherein the target confirmation information is information confirming the transfer of transaction information to the transition account.

[0228] Optionally, the second accounting module is specifically used for:

[0229] Conducting a delayed account audit on the customer account;

[0230] Conducting a delayed account audit on the merchant account;

[0231] Conduct delayed account audit on the transitional accounts.

[0232] Optionally, the second accounting module is specifically used for:

[0233] Obtain the account balance of the transition account on the previous day;

[0234] If the account balance of the transition account is non-zero, a prompt message is generated.

[0235] The above-mentioned product can execute the payment method provided by any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0236] The technical solution of this embodiment is to receive a payment request sent by a client, wherein the payment request includes: a target payment token, a merchant identification number, a customer account identification information and a transaction amount; perform a first accounting according to the customer account identification information and the transaction amount, and obtain a transaction flow corresponding to the first accounting, wherein the transaction flow includes: an order number, and send the order number to the client; receive a payment confirmation request sent by the client, wherein the payment confirmation request includes: a target payment token and an order number; perform a second accounting according to the target payment token, the order number and the merchant identification number, thereby solving the problem of single point failure that is prone to occur due to maintaining consistency of results of multiple payment requests through database row-level locks, and can ensure the consistency of payment data in a low-latency and high-concurrency environment of the Internet of Things.

[0237] Embodiment 3

[0238] Fig.10A schematic diagram of the structure of an electronic device 10 that can be used to implement an embodiment of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or required herein.

[0239] like Fig.10 As shown, the electronic device 10 includes at least one processor 11, and a memory connected to the at least one processor 11, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., wherein the memory stores a computer program that can be executed by at least one processor, and the processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 to the random access memory (RAM) 13. In the RAM 13, various programs and data required for the operation of the electronic device 10 can also be stored. The processor 11, the ROM 12, and the RAM 13 are connected to each other through a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0240] A number of components in the electronic device 10 are connected to the I / O interface 15, including: an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0241] The processor 11 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 11 executes the various methods and processes described above, such as a payment method.

[0242] In some embodiments, the payment method may be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as a storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the payment method described above may be performed. Alternatively, in other embodiments, the processor 11 may be configured to execute the payment method in any other suitable manner (e.g., by means of firmware).

[0243] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0244] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that when the computer program is executed by the processor, the functions / operations specified in the flow chart and / or block diagram are implemented. The computer program may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.

[0245] In the context of the present invention, a computer-readable storage medium may be a tangible medium that may contain or store a computer program for use by or in combination with an instruction execution system, device or equipment. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0246] To provide interaction with a user, the systems and techniques described herein may be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form (including acoustic input, voice input, or tactile input).

[0247] The systems and techniques described herein may be implemented in a computing system that includes backend components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes frontend components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0248] A computing system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The client and server relationship is generated by computer programs running on the corresponding computers and having a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system to solve the defects of difficult management and weak business scalability in traditional physical hosts and VPS services.

[0249] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps described in the present invention can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solution of the present invention can be achieved, and this document does not limit this.

[0250] An embodiment of the present invention further provides a computer program product, including a computer program, wherein when the computer program is executed by a processor, the payment method according to any embodiment of the present invention is implemented.

[0251] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A payment method, characterized in that: Executed by the server, the payment method includes: Receiving a payment request sent by a client, wherein the payment request includes: a target payment token, a merchant identification number, customer account identification information, and a transaction amount; Performing a first accounting according to the customer account identification information and the transaction amount, obtaining a transaction flow corresponding to the first accounting, wherein the transaction flow includes: an order number, and sending the order number to the client; Receiving a payment confirmation request sent by the client, wherein the payment confirmation request includes: a target payment token and an order number; Performing a second accounting according to the target payment token, the order number and the merchant identification number; The first accounting is performed according to the customer account identification information and the transaction amount to obtain a transaction flow corresponding to the first accounting, including: Determine a customer account according to the customer account identification information, and lock the customer account; Obtaining the account status and account balance of the customer account; If the account status of the customer account is normal and the account balance is greater than the transaction amount, the transaction amount in the customer account is transferred to the transition account to generate a transaction flow, wherein the transaction flow includes: a flow number, an order number, a target payment token, customer account identification information, a merchant identification number, a client identification number and a transaction amount; The second accounting according to the target payment token, the order number and the merchant identification number includes: Obtaining the transaction flow corresponding to the target payment token, wherein the transaction flow also includes: the first accounting time; If the difference between the current time and the first accounting time is less than the difference threshold, determining the merchant account according to the merchant identification number; Locking the merchant account; Transfer the transaction amount in the transition account to the merchant account; The merchant account is unlocked.

2. The method according to claim 1, characterized in that: If the account status of the customer account is normal and the account balance is greater than the transaction amount, the transaction amount in the customer account is transferred to the transition account, and after the transaction flow is generated, the method further includes: If the target confirmation information sent by the client is not received within the preset time, the transaction amount in the transition account will be transferred back to the customer account.

3. The method according to claim 1, characterized in that If the account status of the customer account is normal and the account balance is greater than the transaction amount, the transaction amount in the customer account is transferred to the transition account, and after the transaction flow is generated, the method further includes: Unlock the customer account.

4. The method according to claim 1, characterized in that: Sending the order number to the client includes: Sending the order number and the accounting success status code to the client; Receive target confirmation information sent by the client.

5. The method according to claim 1, characterized in that Before receiving the payment request sent by the client, it also includes: Receiving a token acquisition request sent by the client, wherein the token acquisition request includes: a client type and a client identification number; At least one payment token is generated according to the client type and the client identification number.

6. The method according to claim 5, characterized in that After generating at least one payment token according to the client type and the client identification number, the method further includes: If at least two payment tokens are generated, the at least two payment tokens are stored in a local database.

7. The method according to claim 5, characterized in that Generating at least one payment token according to the client type and the client identification number, comprising: Determining a target payment token quantity according to the client type; Generate a payment token corresponding to the target payment token quantity according to the client type and the client identification number.

8. The method according to claim 1, characterized in that If the difference between the current time and the first accounting time is less than the difference threshold, determining the merchant account according to the merchant identification number includes: If the target confirmation information sent by the client is received and the difference between the current time and the first accounting time is less than the difference threshold, the merchant account is determined according to the merchant identification number, wherein the target confirmation information is information confirming the transfer of transaction information to the transition account.

9. The method according to claim 1, characterized in that: Also includes: Conducting a delayed account audit on the customer account; Conducting a delayed account audit on the merchant account; Conduct delayed account audit on the transitional accounts.

10. The method according to claim 1, characterized in that Conducting delayed account audits on the transitional accounts, including: Obtain the account balance of the transition account on the previous day; If the account balance of the transition account is non-zero, a prompt message is generated.

11. A payment device, characterized in that: The payment device comprises: A first receiving module, configured to receive a payment request sent by a client, wherein the payment request includes: a target payment token, a merchant identification number, customer account identification information, and a transaction amount; A first accounting module is used to perform a first accounting according to the customer account identification information and the transaction amount, and obtain a transaction flow corresponding to the first accounting, wherein the transaction flow includes: an order number, and the order number is sent to the client; A second receiving module is used to receive a payment confirmation request sent by the client, wherein the payment confirmation request includes: a target payment token and an order number; A second accounting module, used for performing a second accounting according to the target payment token, the order number and the merchant identification number; The first accounting module is specifically used for: Determine a customer account according to the customer account identification information, and lock the customer account; Obtaining the account status and account balance of the customer account; If the account status of the customer account is normal and the account balance is greater than the transaction amount, the transaction amount in the customer account is transferred to the transition account to generate a transaction flow, wherein the transaction flow includes: a flow number, an order number, a target payment token, customer account identification information, a merchant identification number, a client identification number and a transaction amount; The second accounting module is specifically used for: Obtaining the transaction flow corresponding to the target payment token, wherein the transaction flow also includes: the first accounting time; If the difference between the current time and the first accounting time is less than the difference threshold, determining the merchant account according to the merchant identification number; Locking the merchant account; Transfer the transaction amount in the transition account to the merchant account; The merchant account is unlocked.

12. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so as to enable the at least one processor to execute the payment method according to any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the payment method according to any one of claims 1 to 10 when executed.

14. A computer program product, characterized in that The computer program product comprises a computer program which, when executed by a processor, implements the payment method according to any one of claims 1-10.

Images