CN116503059A

CN116503059A - Concurrent payment method and device, electronic equipment and storage medium

Info

Publication number: CN116503059A
Application number: CN202310492753.8A
Authority: CN
Inventors: 牛丽敏
Original assignee: Bank of China Financial Technology Co Ltd
Current assignee: Bank of China Financial Technology Co Ltd
Priority date: 2023-04-28
Filing date: 2023-04-28
Publication date: 2023-07-28

Abstract

The invention provides a concurrent payment method, a concurrent payment device, electronic equipment and a storage medium, which can be applied to the financial field or other fields. According to the method, batch payment transfer messages of the same payment account request are split into transaction records, when transfer payment corresponding to the current transaction record is executed, a payment account corresponding to the transaction record is locked, the payment account is released after the expiration time of the lock is reached, namely, the next transaction record in the payment account can be executed, and the transfer payment of the same payment account is prevented from being accumulated and processed through a Redis distributed lock; avoiding the problem of a large number of transaction failures due to account locking. Furthermore, the transfer payment is executed in an asynchronous calling mode, so that multiple transfer payments of different payment accounts can be processed simultaneously, and the processing efficiency of the transfer payment is improved.

Description

Concurrent payment method and device, electronic equipment and storage medium

Technical Field

The present invention relates to the field of financial data processing technologies, and in particular, to a concurrent payment method, apparatus, electronic device, and storage medium.

Background

The bank payment system is used as a core system of the bank, and receives a large number of payment requests sent by the peripheral system in the daily operation process, and can simultaneously process a plurality of payment instructions.

In the process of specifically processing the payment request, the bank payment system needs to update the payment account and the amount of the collection account in the account table, and the updating operation locks the account record. Once the bank payment system receives the transfer request of the same account at the same time, a large number of transactions fail due to account locking.

Disclosure of Invention

In view of the above, the embodiments of the present invention provide a concurrent payment method, apparatus, electronic device, and storage medium, so as to solve the problem that when the existing bank payment system receives the transfer request of the same account at the same time, a large number of transactions fail due to account locking.

In order to solve the above problems, the embodiment of the present invention provides the following technical solutions:

the embodiment of the invention discloses a concurrent payment method, which comprises the following steps:

acquiring a transaction record to be paid currently in a payment list, wherein the payment list stores split batch payment transfer messages;

connecting a Redis distributed lock, and inquiring whether a lock named by the lock name exists or not by taking a payment account number recorded in the transaction record to be paid currently as the lock name;

if so, acquiring a transaction record of the next state to be paid as a current transaction record to be paid, and returning to execute the operation of connecting the Redis distributed lock;

if the transaction record to be paid does not exist, a lock named by the lock name and the expiration time of the lock are established based on the Redis distributed lock, and a payment interface is asynchronously called to execute transfer payment indicated by the transaction record to be paid currently.

Preferably, after executing the transfer payment indicated by the transaction record to be paid currently, the method further comprises:

and acquiring a payment result, and updating the payment state in the transaction record to be paid currently in the payment detail table according to the payment result.

Preferably, executing the transfer payment indicated by the transaction record to be paid currently includes:

carrying out format processing on the transaction record to be paid currently to obtain a fixed-length message with a fixed length in a field;

analyzing the fixed-length message from the fixed position to obtain a payment ID, a payment account, a collection account and a transfer payment amount;

and performing payment based on the payment account, the collection account and the transfer payment amount.

Preferably, the method further comprises:

receiving payment transfer messages sent in batches;

splitting the payment transfer message according to table items in a payment list to obtain a plurality of transaction records, inserting the transaction records into the payment list for storage, wherein the preset table items at least comprise enterprise numbers, payment IDs, payment accounts, collection accounts, transfer payment amounts, insertion table time and payment states, each row of the payment list records a transaction record, and each transaction record corresponds to a unique payment ID.

Preferably, before obtaining the transaction record to be paid currently in the payment list, the method further includes:

inquiring transaction records in a payment state in a payment detail table, and arranging the transaction records in the payment state in positive sequence according to the insertion time in each transaction record;

judging whether the current count of the counter is a preset value or not;

if not, taking the transaction record in the state to be paid, which is currently ranked first, as the transaction record to be paid currently;

if yes, resetting the counter, and returning to execute the step of inquiring the transaction record in the payment list in the state to be paid;

correspondingly, after the transaction record of the next state to be paid is obtained as the transaction record of the current state to be paid, the counter counts a variable.

Preferably, if the preset value is 0, the counter counts a variable, including: the counter decrements by 1;

if the preset value is N, the counter counts a variable including: the counter is incremented by 1; n is larger than 1.

The second aspect of the embodiment of the invention discloses a concurrent payment device, which comprises:

the splitting module is used for splitting the received batch payment transfer messages and storing the split batch payment transfer messages in a payment list;

the main control module is used for acquiring a transaction record to be paid currently in the payment list, connecting with a Redis distributed lock, taking a payment account number recorded in the transaction record to be paid currently as a lock name, and inquiring whether a lock named by the lock name exists or not; if so, acquiring a transaction record of the next state to be paid as a current transaction record to be paid, and returning to execute the connected Redis distributed lock; if the lock does not exist, establishing a lock named by the lock name and the expiration time of the lock based on the Redis distributed lock, and asynchronously calling a payment processing module;

and the payment processing module is used for executing the transfer payment indicated by the transaction record to be paid currently.

Preferably, before the current transaction record to be paid in the payment list is obtained, the main control module is further configured to query the transaction record in the payment list in a state to be paid, and perform positive sequence arrangement on the transaction record in the state to be paid according to the insertion time in each transaction record; judging whether the current count of the counter is a preset value or not; if not, taking the transaction record in the state to be paid, which is currently ranked first, as the transaction record to be paid currently; if yes, resetting the counter and re-inquiring the transaction record in the payment list in the state to be paid;

correspondingly, the main control module is further configured to count a variable by the counter after the transaction record of the next state to be paid is obtained as the transaction record to be paid currently.

A third aspect of the embodiment of the present invention discloses an electronic device, where the electronic device is configured to execute a program, where the program executes a concurrent payment method as disclosed in the first aspect of the embodiment of the present invention.

The fourth aspect of the embodiment of the invention discloses a storage medium, which comprises a storage program, wherein the device where the storage medium is located is controlled to execute the concurrent payment method disclosed in the first aspect of the embodiment of the invention when the program runs.

Based on the concurrent payment method, the concurrent payment device, the electronic equipment and the storage medium provided by the embodiment of the invention, the current transaction record to be paid in the payment list is obtained, and the split batch payment transfer message is stored in the payment list; connecting a Redis distributed lock, taking a payment account number recorded in a transaction record to be paid currently as a lock name, and inquiring whether a lock named by the lock name exists or not; if so, acquiring a transaction record of the next state to be paid as a current transaction record to be paid, and returning to execute the operation of connecting the Redis distributed lock; if the transaction record does not exist, a lock named by the lock name and the expiration time of the lock are established based on the Redis distributed lock, and the payment interface is asynchronously called to execute transfer payment indicated by the transaction record to be paid currently. In the embodiment of the invention, batch payment transfer messages of the same payment account request are split into one transaction record, when transfer payment corresponding to the current transaction record is executed, a payment account corresponding to the transaction record is locked, and the payment account is released after the expiration time of the lock is reached, namely, the next transaction record in the payment account can be executed, and the transfer payment of the same payment account is prevented from being accumulated and processed through a Redis distributed lock; avoiding the problem of a large number of transaction failures due to account locking. Furthermore, the transfer payment is executed in an asynchronous calling mode, so that multiple transfer payments of different payment accounts can be processed simultaneously, and the processing efficiency of the transfer payment is improved.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings that are required to be used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only embodiments of the present invention, and that other drawings can be obtained according to the provided drawings without inventive effort for a person skilled in the art.

Fig. 1 is a schematic flow chart of a concurrent payment method disclosed in the embodiment of the present invention;

FIG. 2 is a schematic flow chart of a method for splitting batch payment transfer messages according to an embodiment of the present invention;

FIG. 3 is a schematic diagram of a transfer payment process according to an embodiment of the present invention;

FIG. 4 is a flow chart of another concurrent payment method disclosed in an embodiment of the present invention;

fig. 5 is a schematic diagram of an effect of executing a concurrent payment method according to an embodiment of the present invention;

fig. 6 is a schematic structural diagram of a concurrent payment apparatus according to an embodiment of the present invention;

fig. 7 is an exemplary diagram of an application concurrent payment apparatus according to an embodiment of the present invention.

Detailed Description

The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

In this application, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

As known from the background art, the existing bank payment system receives the transfer request of the same account at the same time, which causes a problem of a large number of transaction failures due to account locking. Therefore, the embodiment of the invention discloses a concurrent payment method, a device, electronic equipment and a storage medium, which are used for splitting batch payment transfer messages of the same payment account request into transaction records, locking a payment account corresponding to the transaction record when the transfer payment corresponding to the current transaction record is executed, and releasing the payment account after the expiration time of the lock is reached, namely, the next transaction record in the payment account can be executed, and the transfer payment of the same payment account is prevented from being accumulated and processed through redis lock, so that the problem of a large number of transaction failures caused by account locking is avoided.

As shown in fig. 1, a flow chart of a concurrent payment method disclosed in the embodiment of the present invention mainly includes the following steps:

s101: and acquiring a transaction record to be paid currently in the payment list.

In S101, the payment details table stores the split batch payment transfer message.

In an embodiment of the present invention, a process for splitting batch payment transfer messages is shown in fig. 2, and includes:

s201: and receiving the payment transfer messages sent in batches.

S202: splitting the payment transfer message according to the table items in the payment detail table to obtain a plurality of transaction records, and inserting the transaction records into the payment detail table for storage.

In S202, the preset entries include at least a corporation number (merchNo), a payment ID (UUID), a payment account (OutAct), a collection account (InAct), a transfer payment amount (PayAmt), a break time (CreateTime, format: YYYYMMDDHH mmSS), and a payment status (PayState).

The payment ID is generated by the enterprise request system and, to avoid duplication, each transaction record corresponds to a unique payment ID.

The payment status includes three status of to-be-paid, successful payment and failed payment. The payment status is updated in real time according to the specific payment result.

In a specific stored procedure, a transaction record is recorded for each line in the payment statement.

For example, the enterprise P sends a batch payment transfer message, splits the batch payment transfer message according to preset entries and inserts a payment list as shown in table 1.

Table 1:

merchNo

UUID

OutAct

InAct

PayAmt

CreateTime

PayState

P

T1

A

X1

Y1

20230101082310

unpaid (not shown)

P

T2

A

X2

Y2

20230101082315

Unpaid (not shown)

In the specific execution S101, the payment status of each line of transaction records in the payment list is sequentially queried, and when the payment status of a transaction record is queried to be an unpaid status, it is determined that the transaction record is not currently to be paid.

S102: connecting a Redis distributed lock, taking a payment account number recorded in a transaction record to be paid currently as a lock name, and inquiring whether a lock named by the lock name exists or not; if so, S103 is executed; if not, executing S104;

in S102, the Redis distributed lock is a single-threaded program, and thread security may be naturally guaranteed. The distributed locking operation is implemented by the setnx key value command provided in the dis (which indicates that when there is no key pair in the dis, a value of the key pair is created, and if the key pair value already exists, no operation is performed), and an expiration time can be set for the lock, and the lock is released after the expiration time.

In the process of executing S102 specifically, the Redis distributed lock is connected, and whether there is a lock with the payment account number recorded in the transaction record to be paid currently as the lock name is searched in the Redis distributed lock.

S103: and acquiring a transaction record of the next state to be paid as a transaction record of the current state to be paid, and returning to execute S102.

In the process of executing S103 specifically, it is determined that there is a lock with the payment account number recorded in the transaction record to be paid currently as the lock name in the Redis distributed lock, that is, it indicates that the payment account number is locked, and it is required to release the lock after the expiration time of the lock has arrived. That is, there may be a transfer payment currently being performed under the payment account. At this time, the transaction record of the next state to be paid is obtained as the transaction record to be paid currently, S102 is executed again, and the inquiry is continued as to whether the locking condition exists.

S104: and establishing a lock named by the lock name based on the Redis distributed lock, and the expiration time of the lock, and asynchronously calling a payment interface to execute the transfer payment indicated by the transaction record to be paid currently.

In the process of specifically executing S104, if it is determined that there is no lock with the payment account number recorded in the transaction record to be paid currently as the lock name, it is indicated that the transaction record can be executed. Also, to avoid stacking transfer payments processing the same payment account, a lock with the payment account recorded in the transaction record to be paid currently as a lock name is established based on the Redis distributed lock, and an expiration time of the lock is set.

It should be noted that, in general, the expiration time of the lock may be flexibly set according to the duration of processing a single transaction detail by the payment core system of the bank.

After locking and setting the expiration time of the lock, the payment interface is asynchronously invoked to perform the transfer payment indicated by the transaction record currently to be paid.

In an embodiment of the present invention, a specific process of executing the transfer payment indicated by the transaction record to be paid is shown in fig. 3, and a schematic flow chart of the transfer payment is disclosed, which mainly includes the following steps:

s301: and carrying out format processing on the transaction record to be paid currently to obtain a fixed-length message with a fixed length in the field.

In the specific execution S301, format processing is performed on the transaction record to be paid currently, so that each field is fixed-length, and a fixed-length message with fixed-length fields is obtained.

Based on the description of table 1, each item of the transaction record in the first row in table 1 is extracted, each item is taken as a field, each field is fixed in length, the content of the corresponding item record of the transaction record is stored in each field, and a fixed-length message with fixed length of the field is formed based on the content.

S302: and resolving the fixed-length message from the fixed position to obtain a payment ID, a payment account, a collection account and a transfer payment amount.

S303: and performing transfer payment based on the payment account, the collection account and the transfer payment amount.

In one embodiment of the present invention, after executing the transfer payment indicated by the transaction record currently to be paid, the method further comprises: and acquiring a payment result, and updating the payment state in the transaction record to be paid currently in the payment list according to the payment result.

Specifically, the payment state of the transaction record to be updated in the payment detail table is determined according to the unique corresponding payment ID obtained by analyzing the transaction record to be paid currently, and the payment state is updated according to the payment result.

If the payment result is successful, updating the payment state to be successful.

If the payment result is a payment failure, updating the payment state to be the payment failure.

The embodiment of the invention discloses a concurrent payment method, which is characterized in that batch payment transfer messages of the same payment account request are split into transaction records, when transfer payment corresponding to the current transaction record is executed, a payment account corresponding to the transaction record is locked, and the payment account is released after the expiration time of the lock is reached, namely, the next transaction record in the payment account can be executed, and the transfer payment of the same payment account is prevented from being accumulated and processed through Redis locks; avoiding the problem of a large number of transaction failures due to account locking. Furthermore, the transfer payment is executed in an asynchronous calling mode, so that multiple transfer payments of different payment accounts can be processed simultaneously, and the processing efficiency of the transfer payment is improved.

As shown in fig. 4, a flow chart of another concurrent payment method disclosed in the embodiment of the present invention mainly includes the following steps:

s401: inquiring the transaction records in the payment list in the state to be paid, and arranging the transaction records in the state to be paid in positive sequence according to the insertion time in each transaction record.

In the process of specifically executing S401, the transaction records in the state to be paid in the current payment statement are queried, and the transaction records in the state to be paid are arranged in a positive sequence according to the insertion time in each transaction record.

For example, the enterprises P and Q send batch payment transfer messages, split according to preset list items and insert payment details as shown in table 2.

Table 2:

merchNo

UUID

OutAct

InAct

PayAmt

CreateTime

PayState

P

T1

A

X1

Y1

20230101082310

unpaid (not shown)

P

T2

A

X2

Y2

20230101082315

Unpaid (not shown)

Q

T3

B

X3

Y3

20230101082312

Unpaid (not shown)

Q

T4

B

X4

Y4

20230101082317

Unpaid (not shown)

Q

T5

B

X5

Y5

20230101082207

Successful payment

Q

T6

B

X6

Y6

20230101082101

Successful payment

Table 3 is obtained after the transaction records in the unpaid state are arranged in positive order based on table 2 in the concrete execution S401.

Table 3:

merchNo

UUID

OutAct

InAct

PayAmt

createTime

PayState

P

T1

A

X1

Y1

20230101082310

unpaid (not shown)

Q

T3

B

X3

Y3

20230101082312

Unpaid (not shown)

P

T2

A

X2

Y2

20230101082315

Unpaid (not shown)

Q

T4

B

X4

Y4

20230101082317

Unpaid (not shown)

Q

T5

B

X5

Y5

20230101082207

Successful payment

Q

T6

B

X6

Y6

20230101082101

Successful payment

S402: and judging whether the current count of the counter is a preset value. If yes, executing S403; if not, S404 is performed.

In S402, the preset value may be 0 or N, where N is greater than 1. The number of rounds is determined by setting the count value of the counter.

S403: reset the counter and return to execution S401.

S404: and taking the transaction record in the state to be paid, which is currently ranked first, as the transaction record to be paid currently.

S405: and acquiring a transaction record to be paid currently in the payment list.

S406: connecting a Redis distributed lock, taking a payment account number recorded in a transaction record to be paid currently as a lock name, and inquiring whether a lock named by the lock name exists or not; if so, S407 is performed; if not, S408 is performed.

S407: the transaction record of the next state to be paid is acquired as the transaction record of the current state to be paid, the counter counts a variable, and the execution returns to S406.

S408: and establishing a lock named by the lock name based on the Redis distributed lock, and the expiration time of the lock, and asynchronously calling a payment interface to execute the transfer payment indicated by the transaction record to be paid currently.

The specific execution of S405 to S408 described above is substantially identical to S101 to S104 disclosed in fig. 1 described above, and can be seen. The difference is that the counter counts a variable after the execution S407 acquires the transaction record of the next state to be paid as the transaction record to be paid currently.

It should be noted that, if the preset value is 0, the counter counts a variable, including: the counter is decremented by 1.

Based on the concurrent payment method disclosed in the above embodiment of the present invention, the effect of executing the concurrent payment method is described with table 3 as a reference, as shown in fig. 5.

The enterprise (peripheral system) sends 1 payment account a (T1) and 1 payment account B request (T3) first, and after releasing the Redis distributed lock, sends T2 and T4.

The core payment system firstly receives the requests of T1 and T3, locks A and B, and receives T2 and T4 for processing after the transfer payment processing of the requests is successful.

The embodiment of the invention discloses a concurrent payment method, which is characterized in that batch payment transfer messages are split and stored in a payment list, and the payment list is processed. And (3) polling transaction records in the unpaid state in the payment list, and if the queried transaction records in the unpaid state are locked, continuously querying whether the next transaction record in the unpaid state is locked or not. And if the transaction record in the current unpaid state is inquired, locking a payment account corresponding to the transaction record, and executing asynchronous calling to execute transfer payment corresponding to the transaction record. And releasing after the lock added by the payment account number expires. In the scheme, the problem of a large number of transaction failures caused by account locking is avoided based on the Redis distributed lock while the batch payment transfer messages are processed according to the time of sending the batch payment transfer messages by the enterprise. Furthermore, the transfer payment is executed in an asynchronous calling mode, so that multiple transfer payments of different payment accounts can be processed simultaneously, and the processing efficiency of the transfer payment is improved.

Based on the above-mentioned concurrent payment method disclosed in the embodiment of the present invention, the embodiment of the present invention correspondingly discloses a concurrent payment device, as shown in fig. 6, where the concurrent payment device includes: a splitting module 60, a main control module 61 and a payment processing module 62.

The splitting module 60 is configured to split the received batch payment transfer message and store the split batch payment transfer message in the payment list.

The splitting module 60 is specifically configured to: receiving payment transfer messages sent in batches; splitting the payment transfer message according to table items in a payment list to obtain a plurality of transaction records, inserting the transaction records into the payment list for storage, wherein the preset table items at least comprise enterprise numbers, payment IDs, payment accounts, collection accounts, transfer payment amounts, insertion table time and payment states, each row of the payment list records a transaction record, and each transaction record corresponds to a unique payment ID.

The main control module 61 is configured to obtain a transaction record to be paid currently in the payment list, connect with the Redis distributed lock, use a payment account number recorded in the transaction record to be paid currently as a lock name, and query whether there is a lock named by the lock name; if so, acquiring a transaction record of the next state to be paid as a current transaction record to be paid, and returning to the execution connection Redis distributed type; if not, a lock named by the lock name is established based on the Redis distributed lock, and the expiration time of the lock, and the payment processing module 62 is asynchronously invoked.

The payment processing module 62 is used for executing the transfer payment indicated by the transaction record to be paid currently.

The payment processing module 62 is specifically configured to perform format processing on a transaction record to be paid currently, so as to obtain a fixed-length message with a fixed length in a field; analyzing the fixed-length message from the fixed position to obtain a payment ID, a payment account, a collection account and a transfer payment amount; a payment is performed based on the payment account, the collection account, and the transfer payment amount.

In an embodiment of the present invention, the main control module 61 is further configured to obtain a payment result, and update the payment status in the transaction record to be paid currently in the payment list according to the payment result.

In an embodiment of the present invention, before obtaining the transaction record to be paid currently in the payment list, the main control module 61 is further configured to query the transaction record to be paid in the payment list, and perform positive sequence arrangement on the transaction record to be paid according to the insertion time in each transaction record; judging whether the current count of the counter is a preset value or not; if not, taking the transaction record in the state to be paid, which is currently ranked first, as the transaction record to be paid currently; if yes, resetting the counter and re-inquiring the transaction records in the payment list in the state to be paid.

Correspondingly, the main control module 61 is further configured to count a variable by the counter after acquiring the transaction record of the next state to be paid as the transaction record to be paid currently.

It should be noted that, if the preset value is 0, the counter counts a variable including decrementing the counter by 1.

If the preset value is N, the counter counts a variable including the increment of 1; n is larger than 1.

Based on the above-mentioned concurrent payment device disclosed in the embodiment of the present invention, the process of the concurrent payment device when specifically executing concurrent payment is shown in fig. 7 in combination with table 2 and table 3.

S0-splitting module: and receiving batch payment transfer messages sent by enterprises P and Q, splitting the batch payment transfer messages, and storing the batch payment transfer messages in a payment list, wherein the payment list comprises an enterprise number, a UUID, a payment account number, a collection account number, a payment amount and a payment state (to be paid at the moment). The payment details shown in fig. 7 are only part of the contents of tables 2 and 3.

S1-a main control module: as a daemon, the payment list is iterated, all transaction records to be paid (4) are queried, and sorted positively by plug-in time (order T1, T3, T2, T4). The following operations are performed on the 4 searched transaction records: starting from T1 in sequence, connecting with a Redis distributed lock, inquiring whether a lock with a lock name of OutAct exists or not, if not, establishing the lock with the lock name of OutAct, and formatting a payment ID, a payment account, a collection account, a payment amount and the like into a fixed-length message with expiration time of 5 seconds, and calling an S2-payment processing module asynchronously; if the lock is already present, processing continues with the next transaction record, T3. The order of asynchronous calls is shown in fig. 7 as: t1, T3, T2, T4.

S2-payment processing module: after receiving the transfer payment request of the S1-main control module, resolving the fields of the payment ID, the payment account, the collection account, the payment amount and the like from the fixed position according to the fixed-length message, calling a payment core system interface to transfer payment, and updating a table record corresponding to the payment ID in the payment detail table after the payment core system returns.

The embodiment of the invention discloses a concurrent payment device, which is characterized in that batch payment transfer messages requested by the same payment account are split into transaction records, when transfer payment corresponding to the current transaction record is executed, a payment account corresponding to the transaction record is locked, and the payment account is released after the expiration time of the lock is reached, namely, the next transaction record in the payment account can be executed, and the transfer payment of the same payment account is prevented from being accumulated and processed through Redis locks; avoiding the problem of a large number of transaction failures due to account locking. Furthermore, the transfer payment is executed in an asynchronous calling mode, so that multiple transfer payments of different payment accounts can be processed simultaneously, and the processing efficiency of the transfer payment is improved. Meanwhile, the concurrent payment device is lightweight, and the reconstruction and deployment cost required in the application process is low. Meanwhile, the coupling is small, and the portability is strong.

The embodiment of the invention provides electronic equipment which is used for running a program, wherein the concurrent payment method disclosed by the embodiment is executed when the program runs.

The embodiment of the invention provides a storage medium, which comprises a storage program, wherein the device where the storage medium is controlled to execute the concurrent payment method disclosed by the embodiment of the invention when the program runs.

The concurrent payment method, the concurrent payment device, the electronic equipment and the storage medium provided by the invention can be used in the financial field or other fields. The foregoing is merely an example, and the application fields of the concurrent payment method, the apparatus, the electronic device and the storage medium provided by the present invention are not limited.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for a system or system embodiment, since it is substantially similar to a method embodiment, the description is relatively simple, with reference to the description of the method embodiment being made in part. The systems and system embodiments described above are merely illustrative, wherein the elements illustrated as separate elements may or may not be physically separate, and the elements shown as elements may or may not be physical elements, may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art will understand and implement the present invention without undue burden.

Those of skill would further appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative elements and steps are described above generally in terms of functionality in order to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A concurrent payment method, the method comprising:

2. The method of claim 1, wherein after performing the transfer payment indicated by the transaction record currently to be paid, further comprising:

3. The method of claim 1, wherein performing the transfer payment indicated by the transaction record currently to be paid comprises:

4. A method according to any one of claims 1 to 3, further comprising:

receiving payment transfer messages sent in batches;

5. A method according to any one of claims 1 to 3, further comprising, prior to obtaining the transaction record currently to be paid in the payment statement:

judging whether the current count of the counter is a preset value or not;

6. The method of claim 5, wherein if the preset value is 0, the counter counts a variable comprising: the counter decrements by 1;

7. A concurrent payment apparatus, the apparatus comprising:

8. The apparatus of claim 7, wherein the master control module is further configured to query transaction records in the payment statement in a state to be paid and to arrange the transaction records in the state to be paid in a positive order according to a time of insertion in each transaction record before obtaining a transaction record in the payment statement to be paid currently; judging whether the current count of the counter is a preset value or not; if not, taking the transaction record in the state to be paid, which is currently ranked first, as the transaction record to be paid currently; if yes, resetting the counter and re-inquiring the transaction record in the payment list in the state to be paid;

9. An electronic device, characterized in that the electronic device is configured to run a program, wherein the program, when run, performs the concurrent payment method according to any one of claims 1 to 6.

10. A storage medium comprising a stored program, wherein the program, when run, controls a device in which the storage medium resides to perform the concurrent payment method according to any one of claims 1 to 6.