CN111833034A

CN111833034A - Batch deduction method, payment server, computer equipment and storage medium

Info

Publication number: CN111833034A
Application number: CN202010626436.7A
Authority: CN
Inventors: 张秋稳
Original assignee: Taikang Insurance Group Co Ltd; Taikang Online Property Insurance Co Ltd
Current assignee: Taikang Insurance Group Co Ltd; Taikang Online Property Insurance Co Ltd
Priority date: 2020-07-02
Filing date: 2020-07-02
Publication date: 2020-10-27
Anticipated expiration: 2040-07-02
Also published as: CN111833034B

Abstract

The present disclosure relates to the field of network communication technologies, and in particular, to a method for making a batch deduction, a payment server, a computer device, and a storage medium. In order to solve the problem that errors are easy to occur in high-concurrency batch deduction in the prior art, the method of the embodiment of the invention receives batch deduction request messages sent by different service servers; generating a batch deduction form corresponding to the batch deduction request message sent by each service server; when the locking state position of the deduction request is not in a locking state and the payment state is not in a payment completion state, modifying the locking state position of the deduction request into the locking state; and executing the deduction request in the locking state, finishing deduction, and modifying the payment state of the deduction request into a payment completion state. By the adoption of the embodiment, the problem that repeated execution of the deduction request causes service failure or user account data errors when the deduction application is highly concurrent is avoided.

Description

Batch deduction method, payment server, computer equipment and storage medium

Technical Field

The present disclosure relates to the field of network communication technologies, and in particular, to a method for making a batch deduction, a payment server, a computer device, and a storage medium.

Background

In the existing insurance payment service, the problems of insurance invalidation and the like caused by the fact that a user forgets a payment period are avoided due to the fact that regular investment (fixed investment) and automatic renewal service are convenient to operate, and the automatic renewal service is increasingly favored by the user, wherein the automatic renewal service is the service of completing automatic payment through close payment such as bank accounts or WeChat payment, Payment Baoexemption and the like.

In the prior art, the fixed-delivery and automatic renewal business uniformly initiates payment for an account designated by a user at a fixed time or a fixed date every month, for example, the payment is uniformly initiated from a bank card account reserved by the user or a first payment and micro-letter payment account, the number of orders in each batch of payment application is large, and payment cannot be submitted by adopting a single order. In the process of the large-batch deduction business, the problems of repeated submission of requests and repeated deduction are very likely to occur, which is a problem to be solved urgently in the prior art.

Disclosure of Invention

In order to solve the problems in the prior art, embodiments herein provide a batch deduction method, a payment server, a computer device, and a storage medium, which are used to solve the problem in the prior art that highly concurrent batch deduction is prone to errors.

There is provided a method of making a batch debit, comprising,

receiving batch deduction request messages sent by different service servers;

generating a batch deduction form corresponding to the batch deduction request message sent by each service server;

judging whether the locking state position of the deduction request in the batch deduction request message is a locking state or not and whether the payment state of the deduction request is a payment completion state or not;

if the judgment result is negative, modifying the lock state bit of the deduction request into a lock state;

and executing the deduction request in the locking state, completing the deduction, modifying the payment state of the deduction request into a payment completion state, and modifying the payment state of the deduction request in the batch deduction form.

There is also provided a payment server, comprising,

the receiving unit is used for receiving batch deduction request messages sent by the service server;

the batch form generating unit is used for generating batch deduction forms corresponding to the batch deduction request messages sent by each service server;

the judging unit is used for judging whether the locking state position of the deduction request in the batch deduction request message is a locking state or not and whether the payment state of the deduction request is a payment completion state or not;

the locking unit is used for modifying the locking state bit of the deduction request into a locking state when the judgment result is negative;

and the deduction unit is used for executing the deduction request in the locking state, completing the deduction, modifying the payment state of the deduction request into a payment completion state, and modifying the payment state of the deduction request in the batch deduction form.

Embodiments herein also provide a computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the above-mentioned method when executing the computer program.

Embodiments herein also provide a computer-readable storage medium having stored thereon computer instructions, which when executed by a processor, implement the above-described method.

By using the embodiment, the payment server locks the deduction request meeting the requirement by judging the locking state position and the payment state of the received high-concurrency large-amount deduction requests, so that the deduction processing of the deduction request is completed, and the problem that the deduction request is repeatedly executed to cause service failure or user account data error when high-concurrency deduction application is performed is solved.

Drawings

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

FIG. 1 is a schematic diagram illustrating a periodic batch deduction system according to an embodiment of the present disclosure;

FIG. 2 is a flow chart illustrating a method for periodic batch deduction according to an embodiment of the present disclosure;

FIG. 3 is a schematic structural diagram of a payment server according to an embodiment of the present disclosure;

FIG. 4 is a flowchart illustrating a method for periodic batch deduction according to an embodiment of the present disclosure;

FIG. 5 illustrates a process flow for deducting an order according to an embodiment of the disclosure;

FIG. 6 is a flow chart illustrating a WeChat payment method according to an embodiment of the present disclosure;

fig. 7 is a schematic structural diagram of a payment server corresponding to fig. 4 to 6 in the embodiment of the present disclosure;

fig. 8 is a schematic structural diagram of a wechat payment interface in the present embodiment;

fig. 9 is a schematic structural diagram of a computing device according to an embodiment of the present disclosure.

[ description of reference ]

101. A service server;

102. a payment server;

301. a receiving unit;

302. a batch table generating unit;

303. a judgment unit;

304. a locking unit;

305. a deduction unit;

701. a receiving unit;

702. a verification unit;

703. a batch table generating unit;

704. a judgment unit;

705. a locking unit;

706. an order generating unit;

707. processing the queue;

708. a deduction unit;

7081. a reading module;

7082. a payment routing module;

7083. a plurality of payment interfaces;

7084. a payment status modification module;

709. a batch deduction form modification unit;

710. an order form clearing unit; 801. a query component;

802. a judgment section;

803. a payment component;

804. a feedback component;

902. a computing device;

904. a processing device;

906. a storage resource;

908. a drive mechanism;

910. an input/output module;

912. an input device;

914. an output device;

916. a presentation device;

918. a graphical user interface;

920. a network interface;

922. a communication link;

924. a communication bus.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments herein without making any creative effort, shall fall within the scope of protection.

Fig. 1 is a schematic structural diagram of a periodic batch deduction system according to an embodiment of the present disclosure, in the embodiment of the present disclosure, a plurality of service servers 101 initiate a deduction request to one or more payment servers 102 at the same time (within a few milliseconds) at a specified period, the payment servers 102 receive a large amount of deduction requests at the same time (within an extremely short time interval), when a first deduction request is not yet processed and a second deduction request arrives, a repeated deduction phenomenon is very likely to occur when the deduction requests are concurrently processed, so that a service processing error is caused, and a service processing failure, a data error and the like are caused. In the embodiment, a plurality of service servers 101 are included, and the service servers 101 initiate a deduction request to the payment server 102, where the deduction request is initiated from a bank card account or an account reserved by a user after a fixed-investment service or an automatic renewal service of the user reaches a predetermined time (for example, a predetermined time is periodically reached), or from a payment treasure, a WeChat, or the like, and the bank card account or the payment treasure, or the WeChat account opens a company authorized to be specified, or from the account thereof, a deduction is initiated. A large number of timed deduction request tasks are configured on a plurality of service servers 101, and at the same time, a plurality of service servers 101 may send deduction requests of the same user to a payment server 102, in the embodiment of the method and apparatus, by determining whether a deduction request is in a locked state and whether the deduction request has a corresponding record in a flow water meter, and if both are not, locking the deduction request being processed in a manner such as Redis distributed locking, performing deduction processing, and releasing the locking of the deduction request, thereby avoiding the problem of repeated deduction in a distributed system under a high-concurrency batch payment condition.

Fig. 2 is a flowchart of a periodic batch deduction method according to an embodiment herein, in this embodiment, a process of processing a high-concurrency deduction request in an application of periodic batch deduction is described, and the method may be applied to a service operated by a large number of user accounts at high concurrency, for example, an automatic renewal service in insurance renewal, or an automatic renewal service such as cable television, telephone, etc., and run in a payment server to process the high-concurrency deduction request, and specifically includes the following steps:

step 201, receiving batch deduction request messages sent by different service servers.

Step 202, generating a batch deduction form corresponding to the batch deduction request message sent by each service server.

Step 203, determining whether the lock status position of the deduction request in the batch deduction request message is a lock status and whether the payment status of the deduction request is a payment completion status.

And 204, when the judgment results are negative, modifying the lock state bit of the deduction request into a lock state.

Step 205, executing the deduction request in the locking state, completing the deduction, modifying the payment state of the deduction request into a payment completion state, and modifying the payment state of the deduction request in the batch deduction form.

When the determination in step 202 is negative, the deduction request is not processed.

As an aspect of the embodiments herein, after receiving batch deduction request messages sent from different service servers, the method further includes verifying a deduction request in the received batch deduction request messages.

In this step, the service server encrypts the deduction request in the batch deduction request or adds a check bit, or signs the deduction request, and when the payment server receives the batch deduction request message, the check bit can be calculated through the inverse process of encryption with the service server, or through the same check algorithm, or checks the deduction request in the batch deduction request message, so as to judge whether the received deduction request is wrong.

As an aspect of the embodiments herein, generating a batch deduction table corresponding to the batch deduction request message sent by each service server further includes adding a payment status bit and a deduction failure description to each deduction request in the batch deduction table.

In this step, each batch deduction table corresponds to a batch deduction request message sent by one service server, that is, one batch deduction request message corresponds to one batch deduction table, so that the service server can conveniently inquire all deduction processing results of deduction requests of a certain batch, whether the deduction is successful or not is reflected through the payment status bit, and a deduction failure description is used for reflecting a deduction failure reason.

As an aspect of the embodiments herein, in determining whether the lock status bit of the deduction request in the batch deduction request message is in a locked state, the method further includes determining whether the deduction request in the batch deduction request message is in an order table, and when the deduction request in the batch deduction request message is not in the order table, the lock status bit of the deduction request in the batch deduction request message is in an unlocked state.

In this step, the order form is empty in the initial state, and when the order form has a deduction request identical to the deduction request in the batch deduction request message, the lock state bit of the deduction request in the batch deduction request message is a lock state.

As an aspect of the embodiments herein, determining whether the payment status of the deduction request is a payment completed status further includes determining whether the deduction request in the batch deduction request message is in a running table, and when the deduction request in the batch deduction request message is not in the running table, determining that the deduction request in the batch deduction request message is a payment incomplete status.

In this step, the flow table is empty in the initial state, and when the flow table has a deduction request identical to the deduction request in the batch deduction request message, the payment status bit of the deduction request in the batch deduction request message is a payment completion status.

As an aspect of the embodiment herein, when the determination result is no, modifying the lock status bit of the deduction request to be in a lock status further includes modifying the value of the lock status bit of the deduction request in the batch deduction request message to be in the lock status.

In this step, the lock status bit of the deduction request in the batch deduction request message may be added, the initial value is 0, or the lock status bit is empty, and after the determination in the above steps, if the determination result is no, the value of the lock status bit is changed to 1, which represents that the deduction request is locked, and the deduction process is not performed on the same deduction request.

As an aspect of the embodiment herein, when the determination result is no, after modifying the lock status bit of the deduction request to be a lock status, generating an order according to the deduction request in the lock status, and writing the order into an order table.

In this step, each order is also assigned a unique identifier, forming an order number for the order, which is used to query the order.

As an aspect of embodiments herein, executing the deduction request, and completing the deduction further comprises placing all orders in the order form in a queue for deduction processing.

As an aspect of the embodiments herein, placing all orders in the order form into a queue for deduction further includes obtaining deduction related information in the orders; carrying out payment mode routing according to the deduction related information; and obtaining a payment mode according to the payment mode route, and carrying out deduction processing on the order in the payment mode.

In this step, the information related to the deduction in the order includes a deduction mode and a deduction amount in the deduction request, or may further include information in other deduction requests, such as a policy number or an insurance contract number, account information of the deducted user, and the like.

As an aspect of the embodiment herein, the routing the payment method according to the information related to deduction further includes, when the payment method in the information related to deduction cannot complete the deduction process of the order, searching a historical payment method in a historical payment record according to the information related to deduction, and inquiring whether the deducted user agrees to complete the deduction process of the order by using the historical payment method.

In this step, a historical payment record may be searched for according to information related to a deduction such as a policy or insurance contract number in an order, a record identical to the policy or insurance contract number is found from the historical payment record, a historical payment method in the record is extracted, and a short message or an email is sent to a deducted user to inquire whether a payment method for a previous payment of a policy or a renewal service is agreed to be converted into a payment method for a previous payment of a policy or renewal service, because the reserved deduction method cannot complete the policy or renewal service. Or whether the historical payment records have the same record can be searched according to the information of the deducted money user in the order, such as the information of the identity card number, the mobile phone number and the like, if so, the historical payment mode of the deducted money user can be extracted, and therefore, whether the deducted money user converts the payment mode is informed.

As an aspect of the embodiment herein, in the processing of deducting the order in the payment manner, when the payment manner is a secret-free payment manner, querying whether an account of a deducted user at a secret-free payment service providing terminal supports secret-free payment according to the deduction related information, and if the account of the deducted user does not support the secret-free payment manner according to a result fed back by the secret-free payment server providing terminal, failing to deduct the payment, otherwise, performing deduction.

In this step, the secret-free payment method may include a WeChat secret-free payment method, a Payment treasure secret-free payment method, or another secret-free payment method.

As an aspect of embodiments herein, modifying the payment status of the deduction request to a complete payment status further comprises generating a flow sheet from orders in the order sheet and the deduction processing results.

In this step, the flow chart includes, in addition to all the order labels and the deduction requests, deduction processing results obtained after deduction processing is performed on the deduction requests, and when the deduction processing results indicate a deduction failure, the flow chart further includes a description of the deduction request deduction failure.

As an aspect of embodiments herein, the method further includes modifying the payment status of the deduction requests in the bulk deduction form according to the payment status of the deduction requests in the flow form.

Through the embodiment of the invention, the payment server locks the deduction request meeting the requirement by judging the locking state position and the payment state of a large number of received high-concurrency deduction requests, so that the deduction processing of the deduction request is completed, the problem of service failure or user account data error caused by repeated execution of the deduction request when the high-concurrency deduction application occurs is solved, the state of each service can be conveniently determined through the matching of various forms and documents, and each deduction processing result is accurately notified to the service server in real time.

Fig. 3 is a schematic structural diagram of a payment server according to an embodiment herein, in this embodiment, a payment server for processing a highly concurrent deduction request in a periodic batch deduction application is described, where the payment server may be implemented by a desktop computer, a mainframe computer, or a cluster of computers, each functional unit or module, or component may be implemented by a computer software program, or implemented by a general-purpose chip configured by programming, and the payment server is in a network, and receives the deduction request sent by each service server to perform deduction processing, and specifically includes:

the receiving unit 301 is configured to receive a batch deduction request message sent by a service server.

A batch form generating unit 302, configured to generate a batch deduction form corresponding to the batch deduction request message sent by each service server.

The determining unit 303 is configured to determine whether the lock status bit of the deduction request in the batch deduction request message is a lock status and whether the payment status of the deduction request is a payment completion status.

And the locking unit 304 is configured to modify the lock status bit of the deduction request to be a locked status if the determination result is negative.

And a deduction unit 305, configured to execute a deduction request in a locked state, complete deduction, modify a payment state of the deduction request to a payment completed state, and modify a payment state of the deduction request in the batch deduction form.

As an aspect of the embodiments herein, the system further includes a verification unit, configured to verify the deduction request in the received batch deduction request message.

As an aspect of embodiments herein, a payment status bit and a deduction failure description are added to the batch deduction table for each deduction request.

As an aspect of the embodiment herein, the determining unit 303 is further configured to determine whether the deduction request in the batch deduction request message is in an order table, and when the deduction request in the batch deduction request message is not in the order table, the lock status bit of the deduction request in the batch deduction request message is an unlocked status.

As an aspect of the embodiment herein, the determining unit 303 is further configured to determine whether the deduction request in the batch deduction request message is in a running table, and when the deduction request in the batch deduction request message is not in the running table, the deduction request in the batch deduction request message is in an unfinished payment state.

As an aspect of the embodiment herein, the locking unit 304 is further configured to modify a value of a lock status bit of the deduction request in the batch deduction request message to be a value of a lock status.

As an aspect of the embodiment herein, the electronic device further includes an order generating unit, configured to generate an order according to the deduction request of the locked state, and write the order into an order form.

As an aspect of the embodiment herein, the deduction unit 305 is further configured to put all orders in the order table into a queue for deduction processing.

As an aspect of the embodiments herein, the deduction unit 305 further comprises,

the reading module is used for acquiring related information of deduction in the order;

the payment routing module is used for routing a payment mode according to the deduction related information to obtain a payment mode corresponding to the order;

the payment interfaces are used for deducting the payment of the order according to the payment mode;

and the payment state modification module is used for modifying the payment state of the deduction request into a payment completion state according to the deduction processing result.

As an aspect of the embodiment herein, the payment routing module is further configured to, when the payment method in the deduction related information cannot complete the deduction process of the order, search a historical payment method in a historical payment record according to the deduction related information, and ask whether the deducted user agrees to complete the deduction process of the order using the historical payment method.

As an aspect of embodiments herein, the plurality of payment interfaces includes a privacy-exempt payment interface,

the password-free payment interface further comprises a query component, a payment processing component and a payment processing component, wherein the query component is used for querying whether the account of the user who is deducted from the payment-free service providing end supports the password-free payment or not according to the information related to the deduction; and the judging component is used for judging whether the account of the deducted user supports the password-free payment mode according to the result fed back by the password-free payment server providing end, if so, calling the payment component to deduct money, and otherwise, calling the feedback component to feed back the deduction processing result.

As an aspect of the embodiments herein, the payment status modification module is further configured to generate a flow chart according to the orders in the order table and the deduction processing result.

As an aspect of the embodiments herein, the payment processing system further includes a batch deduction form modification unit, configured to modify a payment status of a deduction request in the batch deduction form according to a payment status of the deduction request in the flow form.

Fig. 4 is a specific flowchart of a periodic batch deduction method in an embodiment of the present disclosure, and in this embodiment, an application scenario for implementing automatic deduction in a fixed-investment service or a renewal service of an insurance is described, which specifically includes:

step 401, the service server sends a batch deduction request.

In this step, a plurality of service servers, for example, 10 service servers, are configured to send deduction requests to the payment server in batch at the same time, for example, a batch deduction request is initiated every 12 months at 9:30 am according to a set time, and the deduction requests sent by each service server may or may not be identical, for example, more than 90% identical. Due to different geographic locations and network environments of the service servers, it is possible that the time for the batch deduction requests sent by different service servers to reach the payment server is different, for example, in a time interval of 2-3 milliseconds (ms) (or in other time intervals, for example, 1 second), the batch deduction requests sent by all the service servers will reach the payment server successively.

The service server may package a batch deduction request message in a json format, where the message includes an orderList list, and for optimality of subsequent calculation and network transmission, the orderList list stores no more than 500 deduction requests, where the deduction requests may include a policy number, an insurance contract number, account information of a deducted user, a deduction amount, and may further include other information, such as a deduction mode, a user identity card number, a telephone number, and the like, where the account information may be a WeChat account in this example.

The service server checks the batch deduction request, for example, a CRC (cyclic redundancy check) check mode or an MD5 (message summary) check mode may be adopted, after calculating the batch deduction request message, the value of the calculation result is put into the check bit of the batch deduction request message, and is encapsulated into the batch deduction request message. When the receiving party (in this example, the payment server) receives the batch deduction request message, the batch deduction request message is verified.

Or, the service server may also sign the batch deduction request, and the signature includes the unique identifier of the service server and the time for sending the batch deduction request, and encapsulates the signed batch deduction request into a batch deduction request message, and sends the batch deduction request message to the payment server.

Step 402, the payment server checks the received batch deduction request message.

In this step, the payment server verifies the received batch deduction request message, that is, the batch deduction request message (not including the check bits) is calculated by using the same check algorithm as that of the service server, for example, the CRC check or the MD5 check in step 401, and the calculation result is compared with the check bits in the batch deduction request message, if the calculation result is the same as the check bits in the batch deduction request message, the check is proved to be passed, otherwise, the batch deduction request message is wrong.

Step 403, the payment server establishes a batch deduction form corresponding to the received batch deduction request message.

In this step, the payment server generates a corresponding batch deduction form according to the batch deduction request messages sent by different service servers, as shown in table 1 below,

TABLE 1 batch deduction form

The name of the batch deduction form can be used to indicate the source of the batch deduction request message, and is used to record which batch deduction request message sent by which service server the batch deduction form belongs to.

In an initial state, the batch deduction form is empty, after a payment server receives batch deduction request messages sent by different service servers, a batch deduction form is generated for each batch deduction request message sent by each service server, wherein all deduction requests in the batch deduction request messages are recorded, the batch deduction form further comprises a payment state position used for recording whether the deduction request completes deduction, wherein 0 represents deduction failure, and 1 represents deduction success; and the deduction failure explanation can be further included for recording the reason of the deduction request deduction failure.

In step 404, the payment server determines whether the lock status bit of the deduction request in the received batch deduction request message is in a lock status, if so, the payment server returns to the step 404 to process the next deduction request, otherwise, the payment server enters step 405.

In this step, the payment server compares the received deduction request with an order form in the payment server, for example, compares the received deduction request with a policy number or an insurance contract number of the deduction request, if the deduction request is the same as the deduction request in the order form, the lock status bit of the deduction request is in a locked status, and if the deduction request in the order form is different from the received deduction request, the lock status bit of the deduction request is in an unlocked status.

That is, it is determined whether the received deduction request exists in the order form, if so, the lock status bit of the deduction request is in a locked status, and if not, the lock status bit of the deduction request is in an unlocked status.

When the payment server receives batch deduction requests sent by a plurality of service servers in preset time, initializing a local order form, and emptying records of the order form in the cache of the payment server. The order form is described in detail in step 407.

In step 405, the payment server determines whether the deduction request in the received batch deduction request message appears in the flow table, if the deduction request exists in the flow table, the payment server proceeds to step 404 to process the next deduction request, otherwise, the payment server proceeds to step 406.

In this step, the deduction request for completing the deduction process is recorded in the flow table, and the flow table is described as step 409 described later.

Step 406, the payment server locks unrepeated deduction requests in batch deduction request messages sent by the plurality of service servers received in a preset time interval.

In this step, 10 batch deduction request messages may be received within a predetermined time period, or other quantities of batch deduction request messages, wherein the predetermined time interval may be 2ms or 3ms, or other time periods, the 10 batch deduction request messages are sorted according to the received sequence, each batch deduction request message includes a plurality of deduction requests, the deduction request in the first received batch deduction request message of the payment server does not overlap with the previous deduction request message, the deduction request in the second received batch deduction request message may overlap with the deduction request in the first received batch deduction request message, whether the deduction request is repeated or not may be distinguished by comparing the insurance policy number or the insurance contract policy number in the deduction request, and the deduction request occurring for the first time is added with a lock status bit, the lock status bit of the first occurring debit request is modified to indicate that the debit request is locked and subsequent identical debit requests will not be processed by the lock.

When the payment server receives a plurality of batch deduction request messages at the same time, sequencing the batch deduction request messages according to a random sequence, and judging whether the deduction request is repeated.

In this embodiment, a Redis shared lock technique may be used to write the status bits of all deduction requests in the batch deduction table into the locked status representing the deduction being performed.

For example, setting a certain deduction request in a batch deduction table to be in a lock state can be realized through an INCR lock command, initializing the state bits (key) of all deduction requests in all batch deduction tables to be 0 in advance, adding 1 to the state bit of the deduction request after executing the INCR lock command for one deduction request in a certain batch deduction table, and if an INCR locking operation is to be performed on the deduction request, a numerical value greater than 1 is returned, which indicates that the deduction request is being processed and cannot be reused.

The method can also realize that a certain deduction request in a batch deduction table is set to be in a lock state through an SETNX lock command, after the SETNX lock command is executed for the deduction request in the batch deduction table, the value in the state bit of the deduction request is the value set by the SETNX lock command, if the SETNX lock operation is carried out on the deduction request, failure information is returned due to the value of the state bit of the deduction request, and the deduction request cannot be reused in the processing process.

The method can also realize that a certain deduction request in a batch deduction table is SET to be in a lock state through an SET lock command, after the SET lock command is executed for the deduction request in the batch deduction table, the value in the state bit of the deduction request is the value SET by the SET lock command, the SET lock command also has a parameter for setting lock expiration time, if the SET lock operation is to be carried out on the deduction request, due to the value of the state bit of the deduction request, failure information is returned, and the deduction request cannot be reused in the processing process.

In other embodiments, a certain deduction request in a batch deduction table can be set to be in a lock state through a Zookeeper (distributed system coordination) mode, a persistent node is set for the deduction request in the certain batch deduction table, a temporary node is created through each locking command, the temporary node belongs to the persistent node, a new parallel temporary node is generated when the deduction request is locked for multiple times, a first temporary node is generated after the deduction request is locked, and other locking commands are not executed, which indicates that the deduction request cannot be reused in the process of being processed.

Other techniques for distributed system data locking may also be used in embodiments herein, and are not exhaustive but may be included in embodiments herein.

Step 407, the payment server generates a corresponding order according to the locked deduction request, and writes the order into an order form.

In this step, the payment server generates an order number according to the locked deduction request, where the order number is a unique identifier of the locked deduction request, and the unique identifier may be a numeric string, or a character string of a combination of characters and numbers.

The order form can be as shown in table 2 below, wherein the deposit list number, the insurance contract number, the account information of the deducted user, the deduction amount, the deduction mode are compatible with the content written in the deduction request, and the order form further includes an order number and a locking status bit. The order form is located in the cache of the payment server.

Table 2: order form

In the above-mentioned order form, the account information and the deduction mode of the deducted user may not be included, and since the account information and the deduction mode of the deducted user for each period of the fixed-deposit or automatic renewal service are fixed, the account information and the deduction mode of the deducted user may be obtained in the payment history of the payment server according to the deposit policy number or the insurance contract number.

In other embodiments, the deduction amount may not be included in the order form, and since the deduction amount per cycle of the fixed-delivery or automatic renewal service is fixed, even if the deduction amount periodically increases or decreases, a fixed calculation manner is provided, so that the deduction amount may be obtained through the payment history record of the payment server.

Step 408, the payment server puts all orders in the order form into a queue for deduction processing.

In this step, the payment server may further place all orders in the order form into a thread pool for deduction processing.

In this step, reference may be made to fig. 5, which is a flowchart illustrating a process of deducting a money from an order according to an embodiment of the present disclosure, where in the embodiment of fig. 5, a payment route based on the content of the order is described, so as to complete the money deduction, specifically including:

step 501, reading order information to obtain information related to deduction of the order.

In this step, the order information includes all information in the deduction request, and the deduction related information of the order may include account information of the deducted user, a deduction amount and deduction mode information.

Taking the data in table 2 as an example, the deduction related information with the order number 1234 is obtained in this embodiment, where the information includes account information of the deducted user: WX _11223344, deduction amount: 500, deduction mode: wechat and password-free payment.

Step 502, payment mode routing is performed according to the information related to the deduction.

In this step, the payment mode routing may be performed according to a deduction mode, in this example, if the deduction mode is a wechat password-free payment, the payment server may call a corresponding wechat password-free payment interface to deduct money.

Or, in other embodiments, the payment method routing may also be performed according to the deduction amount, for example, according to the account information of the deducted user, in this case, WX _11223344, the secret-free payment limit of the account provided by the wechat payment server is queried through the wechat payment interface, when the deduction amount exceeds the secret-free payment limit of the wechat (for example, the secret-free payment limit of the account is 200, the deduction amount of this time is 500), the deduction is failed, the historical payment record on the payment server is queried, other historical payment methods with the same policy number or insurance contract number record are queried, for example, there is also a bank card payment method, the user is notified of the wechat secret-free payment that the deduction amount of the service (for example, a renewal service) exceeds the secret-free payment limit, the deduction request fails, whether the historical payment method in the historical payment record is agreed to proceed with the deduction of the service, the historical payment means may be a bank card in this example.

Or, the historical payment record of the payment server can be inquired according to the insurance application guarantee or the insurance contract number in the order, the payment mode in the historical payment record with the same insurance application guarantee or insurance contract number is obtained, and the corresponding payment interface is called according to the payment mode to carry out subsequent deduction processing.

Or, it may also be determined whether the deducted amount exceeds a threshold corresponding to the deducted amount according to the deduction mode and the deducted amount in the order, for example, if the deducted amount is a bank card, the deducted amount is 60000 yuan, and the transfer limit of the bank card is 50000 yuan, it is necessary to call other financial payment interfaces to complete the deduction processing of the deduction request.

The payment method routing may also be composed of a plurality of different conditions, all of which are stored in the database, and when a payment method routing is performed on an order, all of the payment methods in the deduction method are obtained according to the deduction method in the deduction information, for example, when the deduction method is a bank type (bank _ code), all of the payment methods of the type are obtained. The conditions may include: the conditions of the available range of the guarantee amount (whether the amount of the deduction is in the allowed range), the range of the underwriting (whether the service capable of automatic deduction is in the allowed range), the available range of the service type (whether the service type for generating the deduction request is in the allowed range), the available range of the tenant (the deduction mode allowed by the deduction user), the available range of the certificate type (whether the identity information type of the deduction user is in the allowed range), the available range of the region (whether the geographic position of the deduction user is in the allowed range), the available range of the source system (whether the service server capable of initiating the batch deduction request is in the allowed range), the available range of the IP (whether the IP address of the service server initiating the batch deduction request is in the allowed range), and the like, of course, the parameters judged according to the conditions here can be from the deduction related information (at this time, all the routing for payment mode are required to be carried in the deduction request) Parameters needed) or searching the related database according to the order information, for example, searching the user database to obtain related information about the user, or searching the service database to obtain related information about the related service.

For example: when the deduction mode in the deduction related information of one order information is WeChat secret-free payment, a WeChat secret-free payment interface acquires all corresponding conditions from a database, then compares the corresponding conditions according to the income parameters transmitted by the deduction related information, firstly judges whether the guarantee amount is in the guarantee amount available range, acquires the secret-free payment mode of a corresponding tenant according to the income parameters, judges whether the secret-free payment mode of the tenant is configured in the tenant available range or not, and the like, and finally forms a chain rule. And forming the whole chain rule into a rule character string, and returning the payment mode when all conditions are true according to the operation rule. And when any one condition is not met, the payment mode is not returned, and the service party is informed of the payment failure and the corresponding payment failure reason.

And step 503, carrying out deduction processing of the order according to the determined payment mode.

In this embodiment, a wechat payment method may refer to a flowchart of the wechat payment method shown in fig. 6, in the embodiment shown in this figure, a wechat payment is taken as an example for description, and other secret-free payment methods supported by the wechat payment method, such as secret-free payment methods of a pay pal, a kyoto, and the like, may be described, specifically including:

step 601, the WeChat payment interface sends an inquiry instruction to the WeChat payment service provider to inquire whether the account of the deducted fee user in the order supports WeChat secret-free support.

In this step, the query instruction may include wechat account information, such as WX _11223344 described above. In an actual application scenario, information whether to open the password-free payment is recorded in the wechat account, and a deducted user can open or close (realized by setting a password-free payment flag bit) the password-free payment function at any time, if the password-free payment function of the wechat account is opened, normal deduction can be performed, otherwise, deduction cannot be performed.

Step 602, the wechat payment interface judges the result fed back by the wechat payment service provider, if the account supports wechat password-free payment, step 603 is entered, otherwise, the deduction is failed, and step 605 is entered.

Step 603, the wechat payment interface sends a wechat password-free payment request to the wechat payment service provider.

In this step, the request for the WeChat password-free payment may include account information and a deduction amount, or may further include a policy number or an insurance contract number.

And step 604, the WeChat payment interface receives the deduction processing result sent by the WeChat payment service providing end.

In this step, the result of the deduction process may have two types, one is the deduction success, the other is the deduction failure, and the failure reason.

Step 605, the WeChat payment interface obtains the deduction processing result of the deduction success or deduction failure and the failure reason.

And ending the process of the WeChat deduction.

In other embodiments, when the deduction mode obtained through the payment routing is a bank card deduction, the bank payment interface sends the bank account information of the deducted user, for example, 6226123345656 described above, and the deduction amount to the bank payment service provider, and the bank payment interface receives the deduction processing result of the deduction success or the deduction failure and the failure reason, in this case, the deduction processing result is a deduction failure, and the deduction failure reason is an account balance deficiency.

After completing step 503, the deduction process for the order is completed.

And step 409, the payment server generates a flow table according to the deduction processing result to record the deduction processing results of all the orders.

The flow chart is shown in table 3 below, in which the deduction processing results for all orders are recorded.

TABLE 3 flow chart

In this flow chart, the payment status 1 indicates a successful deduction, and the payment status 0 indicates a failed deduction, and at this time, the deduction failure description is written with a deduction failure cause included in the deduction processing result.

And step 410, modifying the payment state bits and deduction failure descriptions in the batch deduction form according to the contents in the flow form.

In this step, the insurance policy number or the insurance contract number in the batch deduction table can be matched according to the insurance policy number or the insurance contract number in the running table, and the payment status bit of the deduction request and the corresponding deduction failure description in the batch deduction table with the same insurance policy number or insurance contract number are updated.

The modified batch deduction form is shown in the following table 4,

table 4 shows the modified batch deduction form

Therefore, when a certain service server inquires the processing result of a certain batch deduction request message, the payment server can feed the batch deduction table back to the service server, the service server can obtain the processing condition of the batch deduction request message sent by the service server according to the batch deduction table, wherein the deduction requests complete deduction, and the deduction requests do not complete deduction due to any reason, so that the service server can send prompt information to corresponding users, the real-time tracking and analyzing effect on account data can be achieved, and economic loss caused by the fact that the users do not regularly pay for renewal or fixed payment on time can be prevented.

In step 411, the payment server empties the order in the order form.

In this step, the lock status bit of the order in the order table may be rewritten by the technical means such as Redis described above, and the lock status in the lock status bit may be deleted.

Or, a timer may also be started, and when the locking state of the lock state bit of the order is not modified within a predetermined time, the value in the lock state bit of the order is deleted, so as to perform an unlocking operation on the order, where the predetermined time may be, for example, 100 seconds.

When the payment server receives the batch deduction request message sent by the service server or continues to process another batch deduction request message received in a preset time interval, the process returns to the step 402 to repeat the process of the steps.

Through the embodiment of the invention, a large amount of operations related to account data, such as deduction operations, can be processed at high concurrency, and particularly for services such as periodic fixed investment and renewal, the operation of triggering a large amount of accounts by an operator periodically is not required, so that the labor cost is saved; moreover, the problem of repeated operation on the same task is avoided by locking the task, and the problem of repeated money deduction on the same policy is avoided for the periodic money deduction service; through the automatic selection of the payment route, a proper payment mode can be automatically matched according to the deduction request, and a plurality of payment modes can be routed, particularly, support is provided for a password-free payment mode, a system is integrated, and the service processing efficiency is improved; through the cooperation of various form documents, the state of each service can be conveniently determined, and each deduction processing result is accurately notified to the service server in real time.

For the above embodiments, the service server in step 401 may not calculate the check bit, and does not need to perform step 402, so that the processing efficiency of the payment server may be further improved.

The step of establishing the batch deduction table in the step 403 may be performed in or after any step of the

step

403 and 409, or the step 403 may be omitted, and the payment status and the deduction failure description of each deduction request in the batch deduction request message are directly added according to the contents of the flow table in the step 410 to form a batch deduction processing result message, and when the corresponding service server inquires the processing result of the batch deduction request message, the modified batch deduction processing result message is sent to the service server.

The order of the

steps

404 and 405 may be reversed, for example, the step 405 is executed first, and then the step 404 is executed according to the judgment result, and of course, the jump order is also adjusted.

The order of

steps

406 and 407 may be reversed, for example, an order may be generated according to the deduction request, and then a value may be written into the lock status bit of the order to lock the deduction request.

The execution sequence of the method in the embodiments of the present disclosure may be changed in many ways, and is not described herein again.

Fig. 7 is a schematic structural diagram of a payment server corresponding to fig. 4 to 6 in this embodiment, where the method in fig. 4 to 6 may be understood with reference to the structure in fig. 7, where the payment server may be a desktop computing device, or a mainframe computer, or a computer cluster, where each functional unit or module may be implemented by a software program, or implemented by a general-purpose programmable logic device through a burning program, and specifically includes:

the receiving unit 701 is configured to receive a batch deduction request message sent by a service server. And the checking unit 702 is configured to check the received batch deduction request messages. The batch form generating unit 703 is configured to establish a batch deduction form corresponding to the received batch deduction request message. The determining unit 704 is configured to determine whether the lock status bit of the deduction request in the received batch deduction request message is a lock status, and determine whether the deduction request in the received batch deduction request message appears in the running table. When both the two determination results of the determining unit 704 are negative, the locking unit 705 is configured to lock non-repeated deduction requests in batch deduction request messages sent by multiple service servers received within a predetermined time interval. The order generating unit 706 is configured to generate a corresponding order according to the locked deduction request, and write the corresponding order into an order form. A process queue 707 for holding all orders in the order table. And a deduction unit 708, configured to perform deduction processing on the orders in the queue.

The deduction unit 708 further includes a reading module 7081 configured to read information of the order to obtain deduction related information of the order. And the payment routing module 7082 is configured to perform payment mode routing according to the deduction related information, and find a payment mode of the order. And the plurality of payment interfaces 7083 are used for carrying out deduction processing on the order according to the determined payment mode. A payment status modification module 7084, configured to modify the payment status of the deduction request according to the deduction processing result, for example, to change to a payment completion status in this example.

In the above-mentioned embodiment in fig. 6, the payment interface 7083 may include a wechat payment interface, and the structure of the wechat payment interface may refer to fig. 8, specifically including,

and the query unit 801 is configured to send a query instruction to the wechat payment service provider, and query whether the account of the deducted fee user in the order supports wechat privacy-free support.

A judging part 802, configured to receive a query result fed back by a providing end of the wechat payment server, and if the account supports wechat password-free payment, invoke a payment part 803 to perform wechat payment; if the account does not support WeChat password-free payment, then a feedback component 804 is invoked to feed back deduction processing results of deduction failure and the reason for the failure.

When the payment component 803 deducts money successfully or loses money, the feedback component 804 is invoked to feed back the result of the money deduction process.

As another example, when the payment interface 7083 is a bank card payment interface, it may only include the above-mentioned payment component and feedback component, and the deduction processing result of the bank card account, which is the deduction success or deduction failure, is fed back through the feedback component.

The deduction processing results fed back by the wechat payment interface and the bank payment interface are fed back to the deduction unit 708, and the payment state modification module 7084 of the deduction unit 708 generates a running table of the deduction processing results to record the deduction processing results of all orders.

The aforementioned fig. 7 further includes a batch deduction form modifying unit 709, configured to modify a payment state in the batch deduction form according to a deduction processing result of the order.

The system further comprises an order form emptying unit 710, configured to empty the order in the order form after the order completes the deduction process.

Fig. 9 is a schematic structural diagram of a computing device in this embodiment, where a payment server in this embodiment may be the computing device in this embodiment, and executes the method in this embodiment. Computing device 902 may include one or more processing devices 904, such as one or more Central Processing Units (CPUs), each of which may implement one or more hardware threads. Computing device 902 may also include any storage resources 906 for storing any kind of information, such as code, settings, data, and the like. For example, without limitation, storage resources 906 may include any one or more of the following in combination: any type of RAM, any type of ROM, flash memory devices, hard disks, optical disks, etc. More generally, any storage resource may use any technology to store information. Further, any storage resource may provide volatile or non-volatile reservation of information. Further, any storage resources may represent fixed or removable components of computing device 902. In one case, when processing device 904 executes associated instructions that are stored in any storage resource or combination of storage resources, computing device 902 can perform any of the operations of the associated instructions. The computing device 902 also includes one or more drive mechanisms 908, such as a hard disk drive mechanism, an optical disk drive mechanism, or the like, for interacting with any storage resource.

Computing device 902 may also include input/output module 910(I/O) for receiving various inputs (via input device 912) and for providing various outputs (via output device 914)). One particular output mechanism may include a presentation device 916 and an associated Graphical User Interface (GUI) 918. In other embodiments, input/output module 910(I/O), input device 912, and output device 914 may also be excluded, acting as only one computing device in a network. Computing device 902 may also include one or more network interfaces 920 for exchanging data with other devices via one or more communication links 922. One or more communication buses 924 couple the above-described components together.

Communication link 922 may be implemented in any manner, such as over a local area network, a wide area network (e.g., the Internet), a point-to-point connection, etc., or any combination thereof. Communication link 922 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc., governed by any protocol or combination of protocols.

Embodiments herein also provide a computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor implementing the following steps when executing the computer program:

receiving batch deduction request messages sent by different service servers;

and executing the deduction request, completing the deduction, and modifying the payment state of the deduction request into a payment completion state.

The computer device provided by the embodiment can also implement the methods in fig. 2, 4-6.

Corresponding to the methods in fig. 2, 4-6, embodiments herein also provide a computer-readable storage medium having stored thereon a computer program, which, when executed by a processor, performs the steps of the above-described method.

Embodiments herein also provide computer readable instructions, wherein when executed by a processor, a program thereof causes the processor to perform the methods as shown in fig. 2, 4-6.

It should be understood that, in various embodiments herein, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments herein.

It should also be understood that, in the embodiments herein, the term "and/or" is only one kind of association relation describing an associated object, meaning that three kinds of relations may exist. For example, a and/or B, may represent: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" herein generally indicates that the former and latter related objects are in an "or" relationship.

Those of ordinary skill in the art will appreciate that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be embodied in electronic hardware, computer software, or combinations of both, and that the components and steps of the examples have been described in a functional general in the foregoing description for the purpose of illustrating clearly 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 implementation. 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 disclosure.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided herein, it should be understood that the disclosed system, apparatus, and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may also be an electric, mechanical or other form of connection.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purposes of the embodiments herein.

In addition, functional units in the embodiments herein may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present invention may be implemented in a form of a software product, which is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the methods described in the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

The principles and embodiments of this document are explained herein using specific examples, which are presented only to aid in understanding the methods and their core concepts; meanwhile, for the general technical personnel in the field, according to the idea of this document, there may be changes in the concrete implementation and the application scope, in summary, this description should not be understood as the limitation of this document.

Claims

1. A method for deducting money in batches is characterized by comprising the following steps,

receiving batch deduction request messages sent by different service servers;

2. The method according to claim 1, wherein the determining whether the lock status bit of the deduction request in the batch deduction request message is in a locked status further comprises determining whether the deduction request in the batch deduction request message is in an order form, and when the deduction request in the batch deduction request message is not in the order form, the lock status bit of the deduction request in the batch deduction request message is in an unlocked status.

3. The method of claim 2, wherein determining whether the payment status of the deduction request is a complete payment status further comprises determining whether the deduction request in the batch deduction request message is in a running form, and when the deduction request in the batch deduction request message is not in the running form, determining that the deduction request in the batch deduction request message is a complete payment status.

4. The method according to claim 3, wherein when the determination result is no, modifying the lock status bit of the deduction request to be in a lock status further comprises generating an order according to the deduction request in the lock status and writing the order into an order form.

5. The method of claim 4, wherein said executing the deduction request and completing the deduction further comprises obtaining information related to the deduction in the order; carrying out payment mode routing according to the deduction related information; and obtaining a payment mode according to the payment mode route, and carrying out deduction processing on the order in the payment mode.

6. The method as claimed in claim 5, wherein the processing of deducting the order in the payment manner further includes, when the payment manner is a password-free payment manner, querying whether the account of the user who is deducted from the password-free payment service provider supports password-free payment according to the information related to deduction, and if the account of the user who is deducted from the password-free payment service provider does not support the password-free payment manner, failing to deduct the payment according to the result fed back by the password-free payment server provider, otherwise, carrying out deduction processing.

7. The method of claim 3, wherein performing a locked state deduction request, completing a deduction, and modifying the payment status of the deduction request to a completed payment status, and modifying the payment status of the deduction request in the batch deduction form further comprises modifying the payment status of the deduction request in the running form, and modifying the payment status of the deduction request in the batch deduction form based on the payment status of the deduction request in the running form.

8. A payment server, comprising,

9. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the processor implements the method of any of the preceding claims 1-7 when executing the computer program.

10. A computer-readable storage medium, characterized in that a computer program is stored on the computer-readable storage medium, which computer program, when being executed by a processor, is adapted to carry out the method of any of the preceding claims 1-7.