Transaction payment processing method, client, server and readable storage medium

Abstract

The present application relates to the field of base frame operation and maintenance, and can realize staggering of the number of payment transaction requests sent to the server at the same time, thereby reducing the traffic pressure of the server, and effectively improving the concurrency performance of the overall payment link. Relates to a transaction payment processing method, a client, a server and a medium, and the method comprises the steps: receiving a plurality of payment transaction requests triggered by a user on a front-end page, executing an anti-swiping operation on the plurality of payment transaction requests, and sending the plurality of payment transaction requests to the server, so that the server carries out transaction processing on the plurality of payment transaction requests; in the process of sending the plurality of payment transaction requests to the server, if a random delay request sent by the server is received or a transaction processing result returned by the server comprises a random delay mark, carrying out delay sending processing on the plurality of payment transaction requests to be sent; and sending the plurality of payment transaction requests completing the time delay to a server, so that the server performs transaction processing on the plurality of payment transaction requests completing the time delay.

Description

Technical Field

[0001] The present application relates to the field of infrastructure operation and maintenance technology, and in particular to a transaction payment processing method, a client, a server and a readable storage medium. Background Art

[0002] With the development of network technology and e-commerce, electronic payment has become an indispensable part of people's daily life. Food, clothing, housing and transportation are inseparable from electronic payment. At present, there are many scenarios for online payment, such as purchasing goods / car service products / insurance and other financial technology scenarios; when encountering some holiday promotions, such as rush buying on time, a large number of users will make online payments at the same time. In related technologies, multiple payment transaction requests in the front-end page are usually sent to the server for transaction processing. When the number of payment transaction requests is too large, the excessive traffic pressure on the server will cause concurrency problems in the payment link, reducing the concurrency performance of the entire payment link.

[0003] Therefore, how to improve the concurrent performance of the payment link has become an urgent problem to be solved. Summary of the invention

[0004] The present application provides a transaction payment processing method, a client, a server and a readable storage medium, which can effectively improve the concurrent performance of the payment link.

[0005] In a first aspect, the present application provides a transaction payment processing method, the method comprising:

[0006] Receive multiple payment transaction requests triggered by the user on the front-end page, perform anti-swiping operations on the multiple payment transaction requests, and send the multiple payment transaction requests to the server so that the server can perform transaction processing on the multiple payment transaction requests;

[0007] In the process of sending the plurality of payment transaction requests to the server, if a random delay request sent by the server is received or the transaction processing result returned by the server includes a random delay mark, delaying the sending of the plurality of payment transaction requests to be sent;

[0008] The delayed multiple payment transaction requests are sent to the server, so that the server performs transaction processing on the delayed multiple payment transaction requests.

[0009] In a second aspect, the present application also provides a transaction payment processing method, comprising:

[0010] When receiving multiple payment transaction requests sent by the client, performing transaction processing on the multiple payment transaction requests, starting a timer for timing, and counting the number of the multiple payment transaction requests;

[0011] If the number of transaction payment requests within the preset time period is greater than the preset threshold, a random delay request is generated;

[0012] The random delay request is sent to the client, where the random delay request is used to instruct the client to perform delayed sending processing on multiple payment transaction requests to be sent.

[0013] In a third aspect, the present application further provides a client, the client comprising a memory and a processor;

[0014] The memory is used to store computer programs;

[0015] The processor is used to execute the computer program and implement the transaction payment processing method corresponding to the above-mentioned client when executing the computer program.

[0016] In a fourth aspect, the present application further provides a server, the server comprising a memory and a processor;

[0017] The memory is used to store computer programs;

[0018] The processor is used to execute the computer program and implement the transaction payment processing method corresponding to the above-mentioned server when executing the computer program.

[0019] In a fifth aspect, the present application also provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the processor implements the transaction payment processing method as described above.

[0020] The present application discloses a transaction payment processing method, a client, a server and a readable storage medium, the method comprising: receiving multiple payment transaction requests triggered by a user on a front-end page, performing anti-swiping operations on the multiple payment transaction requests, and sending the multiple payment transaction requests to a server so that the server can perform transaction processing on the multiple payment transaction requests; in the process of sending the multiple payment transaction requests to the server, if a random delay request sent by the server is received or a transaction processing result returned by the server includes a random delay mark, then delay sending processing is performed on the multiple payment transaction requests to be sent; and the multiple payment transaction requests that have completed the delay are sent to the server so that the server can perform transaction processing on the multiple payment transaction requests that have completed the delay. The above-mentioned transaction payment processing method, through the process of sending multiple payment transaction requests to the server, if a random delay request sent by the server is received or the transaction processing result returned by the server includes a random delay mark, then the multiple payment transaction requests to be sent are delayed and sent to the server for transaction processing. The number of payment transaction requests sent to the server at the same time can be staggered, thereby reducing the traffic pressure of the server, and then effectively improving the concurrency performance of the overall payment link, while also providing users with a faster and smoother payment experience. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0022] Figure 1 is a schematic diagram of a transaction payment processing system provided in an embodiment of the present application;

[0023] Figure 2 It is a schematic diagram of the structure of a client provided in an embodiment of the present application;

[0024] Figure 3 It is a structural diagram of a server provided in an embodiment of the present application;

[0025] Figure 4 It is a schematic flow chart of a transaction payment processing method provided in an embodiment of the present application;

[0026] Figure 5 is a schematic flowchart of the sub-steps of delayed sending processing provided in an embodiment of the present application;

[0027] Figure 6 is a schematic flowchart of another sub-step of delayed sending processing provided in an embodiment of the present application;

[0028] Figure 7 is a schematic flow chart of another transaction payment processing method provided in an embodiment of the present application;

[0029] Figure 8 This is a schematic flow chart of another transaction payment processing method provided in an embodiment of the present application.

[0030] Fig. 9 It is a schematic flow chart of a transaction payment concurrent processing solution in the prior art;

[0031] Fig.10 It is a schematic flow chart of a transaction payment concurrency performance optimization solution provided by an embodiment of the present application;

[0032] Fig.11 An embodiment of the present application also provides a schematic block diagram of a transaction payment processing device. DETAILED DESCRIPTION

[0033] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0034] The flowcharts shown in the accompanying drawings are only examples and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps may also be decomposed, combined or partially merged, so the actual execution order may change according to actual conditions.

[0035] It should be understood that the terms used in this application specification are only for the purpose of describing specific embodiments and are not intended to limit the application. As used in this application specification and the appended claims, unless the context clearly indicates otherwise, the singular forms "a", "an" and "the" are intended to include plural forms.

[0036] It should also be understood that the term “and / or” used in the specification and appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0037] In the related art, multiple payment transaction requests in the front-end page are usually sent to the server for transaction processing. When the number of payment transaction requests is too large, the excessive traffic pressure on the server will cause concurrency problems in the payment link, thereby reducing the concurrency performance of the entire payment link.

[0038] To this end, the embodiments of the present application provide a transaction payment processing method, a client, a server, and a readable storage medium. The transaction payment processing method can be applied to a client or a server. In the process of sending multiple payment transaction requests to the server, if a random delay request sent by the server is received or the transaction processing result returned by the server includes a random delay mark, the multiple payment transaction requests to be sent are delayed and sent to the server for transaction processing. The number of payment transaction requests sent to the server at the same time can be staggered, thereby reducing the traffic pressure of the server, and then the concurrency performance of the overall payment link can be effectively improved, and a faster and smoother payment experience can be provided to users.

[0039] Exemplarily, the client may be an electronic device such as a smartphone, tablet computer, laptop computer, and desktop computer. The server may be an independent server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0040] See also Figure 1 , Figure 1 1 is a schematic diagram of a transaction payment processing system 10 provided in an embodiment of the present application. Figure 1 As shown, a user can initiate a payment transaction request through the front-end page in the client 100 (also called the front end), and the client 100 sends multiple payment transaction requests to the server 200 (also called the back end), so that the server 200 can process the multiple payment transaction requests; after completing the transaction processing of each payment transaction request, the server 200 returns the transaction processing result corresponding to each payment transaction request to the client 100, so that the client 100 can display the transaction processing result on the front-end page. Among them, the server 200 can call the UnionPay system to process the transaction. The specific process of the transaction processing can refer to the relevant technology and is not limited here.

[0041] Exemplarily, a payment transaction request may be initiated by multiple users in multiple clients 100. For ease of description, the present application embodiment is described using one client 100 as an example.

[0042] See also Figure 2 , Figure 21 is a schematic diagram of a client provided in an embodiment of the present application. The client may include a processor and a memory, wherein the processor and the memory may be connected via a bus, and the bus may be any applicable bus such as an Inter-integrated Circuit (I2C) bus.

[0043] The memory may include a storage medium and an internal memory. The storage medium may be a non-volatile storage medium or a volatile storage medium. The storage medium may store an operating system and a computer program, and the internal memory provides an environment for the operation of the computer program in the storage medium. The computer program includes program instructions, and when the program instructions are executed, the processor may execute the transaction payment processing method described in any embodiment.

[0044] The processor is used to provide computing and control capabilities to support the operation of the entire client.

[0045] The processor may be a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor, or any conventional processor.

[0046] In one embodiment, the processor is used to run a computer program stored in the memory to implement the following steps:

[0047] Receive multiple payment transaction requests triggered by the user on the front-end page, perform anti-swiping operations on the multiple payment transaction requests, and send the multiple payment transaction requests to the server so that the server can process the multiple payment transaction requests; in the process of sending the multiple payment transaction requests to the server, if a random delay request is received from the server or the transaction processing result returned by the server includes a random delay mark, delay the sending of the multiple payment transaction requests to be sent; send the multiple payment transaction requests that have completed the delay to the server so that the server can process the multiple payment transaction requests that have completed the delay.

[0048] In one embodiment, when implementing delayed sending processing for multiple payment transaction requests to be sent, the processor is used to implement:

[0049] Determine a delay duration corresponding to each payment transaction request to be sent, wherein the delay durations corresponding to different payment transaction requests are the same or different; and delay each corresponding payment transaction request according to the delay duration corresponding to each payment transaction request.

[0050] In one embodiment, when implementing delayed sending processing for multiple payment transaction requests to be sent, the processor is used to implement:

[0051] According to a preset extraction ratio, multiple payment transaction requests to be sent are extracted to obtain a target payment transaction request; a delay duration corresponding to the target payment transaction request is determined; and according to the delay duration corresponding to the target payment transaction request, the target payment transaction request is delayed.

[0052] In one embodiment, after implementing sending multiple payment transaction requests to the server, the processor is further configured to implement:

[0053] Receive transaction identification information corresponding to each payment transaction request returned by the server and store the transaction identification information; when receiving multiple payment transaction requests triggered by the user on the front-end page, perform idempotence check on the multiple payment transaction requests based on the transaction identification information.

[0054] In one embodiment, the transaction identification information includes a first order number, and the payment transaction request includes a second order number; when the processor implements idempotence checking on multiple payment transaction requests according to the transaction identification information, it is configured to implement:

[0055] The corresponding payment transaction request with the same second order number as the first order number is determined as a payment transaction request for repeated payment; and the payment transaction request for repeated payment is intercepted and processed.

[0056] See also Figure 3 , Figure 3 1 is a schematic diagram of a server structure provided by an embodiment of the present application. The server may include a processor and a memory, wherein the processor and the memory may be connected via a bus, and the bus may be any applicable bus such as an Inter-integrated Circuit (I2C) bus.

[0057] The memory may include a storage medium and an internal memory. The storage medium may be a non-volatile storage medium or a volatile storage medium. The storage medium may store an operating system and a computer program, and the internal memory provides an environment for the operation of the computer program in the storage medium. The computer program includes program instructions, and when the program instructions are executed, the processor may execute the transaction payment processing method described in any embodiment.

[0058] The processor is used to provide computing and control capabilities to support the operation of the entire server.

[0059] The processor may be a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor, or any conventional processor.

[0060] In one embodiment, the processor is used to run a computer program stored in the memory to implement the following steps:

[0061] When multiple payment transaction requests are received from a client, the multiple payment transaction requests are processed, a timer is started for timing, and the number of the multiple payment transaction requests is counted; if the number of transaction payment requests is greater than a preset threshold within a preset time period, a random delay request is generated; and a random delay request is sent to the client, the random delay request is used to instruct the client to perform delayed sending processing on the multiple payment transaction requests to be sent.

[0062] In one embodiment, after implementing transaction processing for multiple payment transaction requests, the processor is further configured to implement:

[0063] Generate transaction identification information corresponding to each payment transaction request; send the transaction identification information to the client, so that the client can perform idempotence check on the received payment transaction request according to the transaction identification information.

[0064] Some embodiments of the present application are described in detail below in conjunction with the accompanying drawings. In the absence of conflict, the following embodiments and features of the embodiments can be combined with each other. Figure 4 , Figure 4 is a schematic flow chart of a transaction payment processing method provided in an embodiment of the present application. Figure 4 As shown, the transaction payment processing method may include steps S101 to S103.

[0065] Step S101, receiving multiple payment transaction requests triggered by the user on the front-end page, performing anti-swiping operations on the multiple payment transaction requests, and sending the multiple payment transaction requests to the server, so that the server performs transaction processing on the multiple payment transaction requests.

[0066] Exemplarily, after receiving multiple payment transaction requests triggered by the user on the front-end page, the client performs anti-swiping operations on the multiple payment transaction requests and sends the multiple payment transaction requests to the server for the server to process the multiple payment transaction requests.

[0067] It should be noted that the anti-swiping operation refers to limiting the number of times a user requests to call the payment interface of the server within a preset time. The preset time can be set according to actual conditions, and the specific value is not limited here. For example, the number of times a user requests to call the payment interface of the server within 1 second is 1.

[0068] By performing anti-swiping operations on multiple payment transaction requests, it is possible to prevent users from making multiple requests to call the server's payment interface in a short period of time, thereby reducing the server's traffic pressure.

[0069] Step S102: in the process of sending multiple payment transaction requests to the server, if a random delay request sent by the server is received or the transaction processing result returned by the server includes a random delay mark, a delayed sending process is performed on the multiple payment transaction requests to be sent.

[0070] In some embodiments, in the process of sending multiple payment transaction requests to the server, if a random delay request sent by the server is received, the client performs a delayed sending process on the multiple payment transaction requests to be sent. The multiple payment transaction requests to be sent refer to payment transaction requests that have been cached in the client but have not been sent to the server.

[0071] It should be noted that delayed sending processing refers to delaying the payment transaction request for a period of time before sending it to the server. The delay time can be randomly set, for example, 10 to 20 milliseconds, or other time lengths.

[0072] In an embodiment of the present application, the server is provided with a timer. When the server receives a payment transaction request sent by the client, the server starts the timer to count and counts the number of multiple payment transaction requests. If the number of transaction payment requests within the preset time period is greater than the preset threshold, the server generates a random delay request, sends the random delay request to the client, and controls the timer to re-count. Among them, the preset time period and the preset threshold can be set according to actual conditions, and the specific values ​​are not limited here. Exemplarily, the preset time period can be 5 seconds, and the preset threshold can be 10000. For example, if the number of transaction payment requests within 5 seconds is greater than 10000, the server generates a random delay request and sends the random delay request to the client. The random delay request is used to instruct the client to delay the sending of multiple payment transaction requests to be sent.

[0073] In the above embodiment, by receiving a random delay request sent by the server, a plurality of payment transaction requests to be sent are delayed in sending. This can achieve that when the number of payment transaction requests is too large, the number of payment transaction requests sent to the server at the same time can be staggered, thereby reducing the traffic pressure of the server, and further effectively improving the concurrency performance of the overall payment link, while also providing users with a faster and smoother payment experience.

[0074] In other embodiments, in the process of sending multiple payment transaction requests to the server, if the transaction processing result returned by the server includes a random delay mark, the client performs delayed sending processing on the multiple payment transaction requests to be sent.

[0075] It should be noted that, in addition to sending a random delay request to the client alone, the server can also send a random delay tag through the transaction processing result.

[0076] In an embodiment of the present application, when the server receives a payment transaction request sent by the client, it starts a timer to count and counts the number of multiple payment transaction requests. If the number of transaction payment requests within a preset time period is greater than a preset threshold, the server adds a random delay mark to the transaction processing result, returns the transaction processing result carrying the random delay mark to the client, and controls the timer to re-count. Among them, the preset time period and the preset threshold can be set according to actual conditions, and the specific values ​​are not limited here. The specific form of the random delay mark is not limited in this application.

[0077] For example, the preset time length may be 5 seconds, and the preset threshold may be 10,000. For example, if the number of transaction payment requests within 5 seconds is greater than 10,000, the server adds a random delay mark to the current transaction processing result, and returns the transaction processing result carrying the random delay mark to the client. The random delay mark is used to instruct the client to perform delayed sending processing on multiple payment transaction requests to be sent.

[0078] Exemplarily, when the client receives the transaction processing result returned by the server, it can parse the transaction processing result to determine whether the transaction processing result carries a random delay mark. When the transaction processing result does not carry a random delay mark, the client continues to send a payment transaction request to the server. When the transaction processing result carries a random delay mark, the client performs delayed sending processing on multiple payment transaction requests to be sent.

[0079] In the above embodiment, when the transaction processing result returned by the server includes a random delay mark, the multiple payment transaction requests to be sent are delayed in sending processing. This can achieve that when the number of payment transaction requests is too large, the number of payment transaction requests sent to the server at the same time can be staggered, thereby reducing the traffic pressure of the server, and further effectively improving the concurrency performance of the overall payment link, while also providing users with a faster and smoother payment experience.

[0080] Step S103: sending the delayed multiple payment transaction requests to the server, so that the server can process the delayed multiple payment transaction requests.

[0081] Exemplarily, after delaying the sending of the multiple payment transaction requests to be sent, the multiple payment transaction requests that have completed the delay may be sent to the server, so that the server can perform transaction processing on the multiple payment transaction requests that have completed the delay.

[0082] See also Figure 5 , Figure 5 is a schematic flow chart of the sub-steps of a delayed sending process provided by an embodiment of the present application. Figure 5 As shown, in step S102, delayed sending processing is performed on multiple payment transaction requests to be sent, which may include step S1021 and step S1022.

[0083] Step S1021: Determine a delay time corresponding to each payment transaction request to be sent, wherein the delay times corresponding to different payment transaction requests are the same or different.

[0084] Exemplarily, the delay time corresponding to each payment transaction request to be sent can be randomly set within a preset delay time range. The preset time range can be set according to actual conditions, and the specific value is not limited to this.

[0085] In one embodiment, the preset delay time range may be 10 to 20 milliseconds, and the delay time corresponding to each payment transaction request to be sent may be randomly set within 10 to 20 milliseconds. For example, for payment transaction request A, the delay time of payment transaction request A may be set to 10 milliseconds; for payment transaction request B, the delay time of payment transaction request B may be set to 12 milliseconds.

[0086] Exemplarily, the delay durations corresponding to different payment transaction requests are the same or different. In one embodiment, the delay duration of 10% of the payment transaction requests can be set to a millisecond, the delay duration of 10% of the payment transaction requests can be set to b milliseconds, the delay duration of 10% of the payment transaction requests can be set to c milliseconds, and so on, wherein a, b, and c are all different.

[0087] Step S1022: Delay each corresponding payment transaction request according to the delay duration corresponding to each payment transaction request.

[0088] Exemplarily, after determining the delay time corresponding to each payment transaction request to be sent, each corresponding payment transaction request may be delayed according to the delay time corresponding to each payment transaction request.

[0089] Specifically, the delay may be performed based on the payment time in each payment transaction request. For example, for payment transaction request A, if the payment time of payment transaction request A is 10:01:02.560, the payment transaction request A may be sent to the server after a delay of 10 milliseconds based on the payment time of 10:01:02.560.

[0090] The above embodiment, by determining the delay duration corresponding to each payment transaction request to be sent, and delaying each corresponding payment transaction request according to the delay duration corresponding to each payment transaction request, can achieve the goal of staggering the number of payment transaction requests sent to the server at the same time, thereby reducing the traffic pressure of the server, and further effectively improving the concurrency performance of the overall payment link, while also providing users with a faster and smoother payment experience.

[0091] See also Figure 6 , Figure 6 FIG. 1 is a schematic flow chart of another sub-step of delayed sending processing provided by an embodiment of the present application. Figure 6 As shown, in step S102, delayed sending processing is performed on multiple payment transaction requests to be sent, and steps S1023 to S1025 may also be included.

[0092] Step S1023: extract the multiple payment transaction requests to be sent according to a preset extraction ratio to obtain a target payment transaction request.

[0093] The preset extraction ratio can be set according to actual conditions, and the specific value is not limited here. For example, when the extraction ratio is 50%, 50% of the multiple payment transaction requests to be sent can be determined as target payment transaction requests.

[0094] Step S1024: Determine the delay duration corresponding to the target payment transaction request.

[0095] Exemplarily, the delay time corresponding to the target payment transaction request can be randomly set within a preset delay time range. The preset time range can be set according to actual conditions, and the specific value is not limited to this.

[0096] In one embodiment, the preset delay duration range may be 10 to 20 milliseconds, and the delay duration corresponding to the target payment transaction request may be randomly set within 10 to 20 milliseconds.

[0097] Step S1025: delay the target payment transaction request according to the delay duration corresponding to the target payment transaction request.

[0098] Exemplarily, after determining the delay time corresponding to the target payment transaction request, the target payment transaction request may be delayed according to the delay time corresponding to the target payment transaction request. For other payment transaction requests, no delay is performed and they are directly sent to the server.

[0099] Specifically, the delay can be performed based on the payment time in each target payment transaction request. For example, for B's payment transaction request, if the payment time of B's ​​payment transaction request is 11:01:02.560, the B payment transaction request can be sent to the server after a delay of 12 milliseconds based on the payment time of 11:01:02.560.

[0100] The above embodiment, by extracting multiple payment transaction requests to be sent, randomly setting the delay duration corresponding to the extracted target payment transaction request, and delaying the target payment transaction request according to the delay duration corresponding to the target payment transaction request, can achieve the number of payment transaction requests sent to the server at the same time being staggered, thereby reducing the traffic pressure of the server, and further effectively improving the concurrency performance of the overall payment link, while also providing users with a faster and smoother payment experience.

[0101] See also Figure 7 , Figure 7 FIG. 1 is a schematic flow chart of another transaction payment processing method provided in an embodiment of the present application. Figure 7 As shown, it may include steps S201 to S203.

[0102] Step S201: receiving multiple payment transaction requests triggered by the user on the front-end page, performing anti-swiping operations on the multiple payment transaction requests, and sending the multiple payment transaction requests to the server so that the server can process the multiple payment transaction requests.

[0103] It can be understood that step S201 is the same as the above step S101 and will not be described in detail here.

[0104] Step S202: Receive transaction identification information corresponding to each payment transaction request returned by the server, and store the transaction identification information.

[0105] Exemplarily, the client receives the transaction identification information corresponding to each payment transaction request returned by the server and stores the transaction identification information. For example, the transaction identification information can be stored in a local database or a local disk.

[0106] It should be noted that after processing each payment transaction request, the server can generate transaction identification information corresponding to each payment transaction request, and then send the transaction identification information corresponding to each payment transaction request to the client. The transaction identification information can be sent to the client alone or together with the transaction processing result.

[0107] Exemplarily, the transaction identification information is used to identify the uniqueness of the payment transaction request, and may be an order number or other information used to identify the uniqueness of the payment transaction request. The transaction identification information corresponding to the payment transaction request generated for the same payment order of the user is the same, so that when the user repeatedly pays for the same payment order, the payment transaction request for repeated payment can be intercepted.

[0108] Step S203: When receiving multiple payment transaction requests triggered by the user on the front-end page, perform idempotence check on the multiple payment transaction requests according to the transaction identification information.

[0109] Exemplarily, when receiving multiple payment transaction requests triggered by the user on the front-end page, the client can perform idempotency check on the multiple payment transaction requests based on the transaction identification information. The transaction identification information includes the first order number, and the payment transaction request includes the second order number. It should be noted that for a payment transaction request for repeated payment, it includes an order number, such as the second order number. Idempotency check refers to determining whether a payment transaction request for repeated payment is received.

[0110] In some embodiments, performing idempotence checks on multiple payment transaction requests based on transaction identification information may include: determining a payment transaction request whose corresponding second order number is the same as the first order number as a payment transaction request for duplicate payment; and intercepting and processing the payment transaction request for duplicate payment.

[0111] Exemplarily, when there is a payment transaction request with the same second order number as the first order number, the payment transaction request can be determined as a payment transaction request for repeated payment, and the payment transaction request for repeated payment is intercepted. Interception means not sending the payment transaction request for repeated payment to the server.

[0112] The above embodiment, by performing idempotence check on multiple payment transaction requests according to transaction identification information, can implement payment transaction requests for repeated payments, whereby the client directly intercepts them at the cache level, and there is no need to send the payment transaction requests for repeated payments to the server, thereby reducing the number of payment transaction requests processed by the server, and further improving the concurrency performance of the overall payment link.

[0113] See also Figure 8 , Figure 8 FIG. 1 is a schematic flow chart of another transaction payment processing method provided in an embodiment of the present application. Figure 8 As shown, it may include steps S301 to S303.

[0114] Step S301: upon receiving multiple payment transaction requests sent by a client, perform transaction processing on the multiple payment transaction requests, start a timer for timing, and count the number of the multiple payment transaction requests.

[0115] For example, when receiving multiple payment transaction requests sent by the client, the server can start a timer to count, count the number of multiple payment transaction requests, and perform transaction processing on the multiple payment transaction requests. The application does not limit the execution order of starting the timer to count and performing transaction processing on the payment transaction requests.

[0116] In some embodiments, after performing transaction processing on multiple payment transaction requests, it may also include: generating transaction identification information corresponding to each payment transaction request; sending the transaction identification information to the client, so that the client can perform idempotence check on the received payment transaction request according to the transaction identification information.

[0117] The transaction identification information may include the first order number, and of course, may also be other information for uniquely identifying the payment transaction request.

[0118] Exemplarily, after generating the transaction identification information corresponding to each payment transaction request, the server may send the transaction identification information to the client alone, or may send the transaction identification information together with the transaction processing result corresponding to the payment transaction request to the client. After receiving the transaction identification information, the client may perform an idempotency check on the received payment transaction request according to the transaction identification information. The specific process of the idempotency check can be found in the detailed description of the above embodiment, which will not be elaborated here.

[0119] The above embodiment generates transaction identification information corresponding to each payment transaction request and sends the transaction identification information to the client, so that the client performs idempotence check on the received payment transaction request according to the transaction identification information. It can achieve that for repeated payment transaction requests, the client directly intercepts them at the cache level, and there is no need to send the repeated payment transaction requests to the server, thereby reducing the number of payment transaction requests processed by the server, and further improving the concurrency performance of the overall payment link.

[0120] Step S302: If the number of transaction payment requests within a preset time period is greater than a preset threshold, a random delay request is generated.

[0121] In one embodiment, if the number of transaction payment requests received within the preset time length when the timer reaches the preset time length is greater than the preset threshold, the server generates a random delay request and controls the timer to re-time. Among them, the preset time length and the preset threshold value can be set according to actual conditions, and the specific values ​​are not limited here. Exemplarily, the preset time length can be 5 seconds, and the preset threshold value can be 10000. For example, when the timer counts to 5 seconds, if the number of transaction payment requests within 5 seconds is greater than 10000, the server generates a random delay request and sends the random delay request to the client. The random delay request is used to instruct the client to delay the sending of multiple payment transaction requests to be sent.

[0122] In another embodiment, if the number of transaction payment requests within a preset time period is greater than a preset threshold, the server adds a random delay mark to the transaction processing result, returns the transaction processing result carrying the random delay mark to the client, and controls the timer to restart.

[0123] Exemplarily, when the client receives the transaction processing result returned by the server, it can parse the transaction processing result to determine whether the transaction processing result carries a random delay mark. When the transaction processing result does not carry a random delay mark, the client sends a payment transaction request to the server normally. When the transaction processing result carries a random delay mark, the client performs delayed sending processing on multiple payment transaction requests to be sent.

[0124] Step S303: Send a random delay request to the client, where the random delay request is used to instruct the client to delay sending of multiple payment transaction requests to be sent.

[0125] Exemplarily, after generating the random delay request, the random delay request may be sent to the client. When receiving the random delay request, the client may perform delayed sending processing on the multiple payment transaction requests to be sent. The specific process of delay processing may refer to the detailed description of the above embodiment, and the specific process is not limited here.

[0126] In the above embodiment, a timing function is added to the server to count the number of multiple payment transaction requests. When the number of payment transaction requests within a preset time period is greater than a preset threshold, a random delay request is sent to the client. When the number of payment transaction requests is too large, the number of payment transaction requests sent to the server at the same time can be staggered, thereby reducing the traffic pressure of the server, and further effectively improving the concurrency performance of the overall payment link, while also providing users with a faster and smoother payment experience.

[0127] See also Fig. 9 , Fig. 9 This is a schematic flow chart of a transaction payment concurrent processing solution in the prior art. Fig. 9 As shown, when a user pays an order through the front-end page of the client, the client can receive a payment transaction request and perform a front-end verification on the payment transaction request. The front-end verification process includes anti-brushing operations and other inventory verifications. Among them, other inventory verifications may include payment amount verification, order verification, payment channel verification, etc. After completing the front-end verification of the payment transaction request, the client can send the payment transaction request to the server for transaction processing. The server can perform a back-end verification on the payment transaction request. The back-end verification process includes anti-brushing operations, idempotence verification and other inventory verifications. Among them, the specific process of anti-brushing operations and idempotence verification can refer to the detailed description of the above embodiment, which will not be repeated here. After completing the back-end verification of the payment transaction request, the server can call other payment links based on MQ (Message Queue, message queue) to perform transaction processing on the payment transaction request, and receive the transaction processing results returned by other payment links, and send the transaction processing results to the client. When the number of payment transaction requests is too large, the excessive flow pressure of the server will cause concurrency problems in the payment link, reducing the concurrency performance of the entire payment link.

[0128] See also Fig.10 , Fig.10 : is a schematic flow chart of a transaction payment concurrency performance optimization solution provided by an embodiment of the present application. Fig.10As shown, when the user pays the order through the front-end page of the client, the client can receive the payment transaction request and perform front-end verification on the payment transaction request. The front-end verification process includes anti-brushing operation, idempotence verification, delayed sending processing and other inventory verification. Among them, the specific process of anti-brushing operation, idempotence verification and delayed sending processing can refer to the detailed description of the above embodiment, which will not be repeated here. Other inventory verifications may include payment amount verification, order verification, payment channel verification, etc. After completing the front-end verification of the payment transaction request, the client can send the payment transaction request to the server for transaction processing. The server can perform back-end verification on the payment transaction request. The back-end verification process includes anti-brushing operation, idempotence verification, starting the timer for timing and other inventory verification. Among them, the specific process of anti-brushing operation, idempotence verification and starting the timer for timing can refer to the detailed description of the above embodiment, which will not be repeated here. After completing the back-end verification of the payment transaction request, the server can call other payment links based on MQ to perform transaction processing on the payment transaction request, receive the transaction processing results returned by other payment links, and send the transaction processing results to the client. Among them, other payment links may include UnionPay system, payment institutions, merchant platforms, etc.

[0129] It should be noted that, compared with the transaction payment concurrent processing scheme in the prior art, the transaction payment concurrent performance optimization scheme provided by the embodiment of the present application can realize the payment transaction request for repeated payment by adding idempotence check in the front-end verification process of the client, and the client directly intercepts it at the cache level, and does not need to send the payment transaction request for repeated payment to the server, thereby reducing the number of payment transaction requests processed by the server; by adding delayed sending processing in the front-end verification process of the client, the number of payment transaction requests sent to the server at the same time can be staggered, thereby reducing the traffic pressure of the server, and thus effectively improving the concurrency performance of the overall payment link, and at the same time, it can also provide users with a faster and smoother payment experience. By adding a timing function to the back-end verification process of the server, when the number of transaction payment requests within the preset time is greater than the preset threshold, a random delay request is sent to the client, which can achieve when the number of payment transaction requests is too large, staggering the number of payment transaction requests sent to the server at the same time, thereby reducing the traffic pressure of the server, and thus effectively improving the concurrency performance of the overall payment link. In addition, by adding idempotence verification and delayed sending processing to the client's front-end verification process on the basis of the transaction payment concurrent processing solution in the existing technology, and adding a timing function to the server's back-end verification process, it is possible to greatly improve the concurrent performance of the overall payment link at a low transformation cost, and provide users with a faster and smoother payment experience.

[0130] See also Fig.11, Fig.11 The embodiment of the present application also provides a schematic block diagram of a transaction payment processing device 1000, which is used to execute the transaction payment processing method described above. The transaction payment processing device 1000 can be configured in a client.

[0131] like Fig.11 As shown, the transaction payment processing device 1000 includes: a first sending module 1001, a delayed sending module 1002 and a second sending module 1003.

[0132] The first sending module 1001 is used to receive multiple payment transaction requests triggered by the user on the front-end page, perform anti-swiping operations on the multiple payment transaction requests, and send the multiple payment transaction requests to the server so that the server performs transaction processing on the multiple payment transaction requests;

[0133] The delayed sending module 1002 is used for performing delayed sending processing on the multiple payment transaction requests to be sent if a random delay request sent by the server is received or the transaction processing result returned by the server includes a random delay mark during the process of sending multiple payment transaction requests to the server;

[0134] The second sending module 1003 is used to send the delayed multiple payment transaction requests to the server, so that the server can perform transaction processing on the delayed multiple payment transaction requests.

[0135] It should be noted that those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the above-described device and each module can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0136] A computer-readable storage medium is also provided in an embodiment of the present application. The computer-readable storage medium stores a computer program. The computer program includes program instructions. The processor executes the program instructions to implement any transaction payment processing method provided in the embodiment of the present application.

[0137] For example, the program is loaded by the processor and may execute the following steps:

[0138] Receive multiple payment transaction requests triggered by the user on the front-end page, perform anti-swiping operations on the multiple payment transaction requests, and send the multiple payment transaction requests to the server so that the server can process the multiple payment transaction requests; in the process of sending the multiple payment transaction requests to the server, if a random delay request is received from the server or the transaction processing result returned by the server includes a random delay mark, delay the sending of the multiple payment transaction requests to be sent; send the multiple payment transaction requests that have completed the delay to the server so that the server can process the multiple payment transaction requests that have completed the delay.

[0139] For another example, when the program is loaded by the processor, the following steps may be executed:

[0140] When multiple payment transaction requests are received from a client, the multiple payment transaction requests are processed, a timer is started for timing, and the number of the multiple payment transaction requests is counted; if the number of transaction payment requests is greater than a preset threshold within a preset time period, a random delay request is generated; and a random delay request is sent to the client, the random delay request is used to instruct the client to perform delayed sending processing on the multiple payment transaction requests to be sent.

[0141] The computer-readable storage medium may be an internal storage unit of the client or server of the aforementioned embodiment, such as a hard disk or memory of the client or server. The computer-readable storage medium may also be an external storage device of the client or server, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital card (Secure Digital Card, SD Card), a flash card (Flash Card), etc., provided on the client or server.

[0142] Furthermore, the computer-readable storage medium may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function, etc.; the data storage area may store data created according to the use of the blockchain node, etc.

[0143] The blockchain referred to in this application is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains a batch of network transaction information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, platform product service layer, and application service layer.

[0144] The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in the present application, and these modifications or replacements should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.

Claims

1. A transaction payment processing method, characterized in that: include: Receive multiple payment transaction requests triggered by the user on the front-end page, perform anti-swiping operations on the multiple payment transaction requests, and send the multiple payment transaction requests to the server so that the server can perform transaction processing on the multiple payment transaction requests; In the process of sending the plurality of payment transaction requests to the server, if a random delay request sent by the server is received or the transaction processing result returned by the server includes a random delay mark, delaying the sending of the plurality of payment transaction requests to be sent; The delayed multiple payment transaction requests are sent to the server, so that the server performs transaction processing on the delayed multiple payment transaction requests.

2. The transaction payment processing method according to claim 1, characterized in that: The delayed sending process of the multiple payment transaction requests to be sent includes: Determine a delay time corresponding to each payment transaction request to be sent, wherein the delay times corresponding to different payment transaction requests are the same or different; According to the delay duration corresponding to each payment transaction request, each corresponding payment transaction request is delayed.

3. The transaction payment processing method according to claim 1, characterized in that: The delayed sending process of the multiple payment transaction requests to be sent includes: Extracting the plurality of payment transaction requests to be sent according to a preset extraction ratio to obtain a target payment transaction request; Determine the delay duration corresponding to the target payment transaction request; The target payment transaction request is delayed according to the delay duration corresponding to the target payment transaction request.

4. The transaction payment processing method according to claim 1, characterized in that: After sending the plurality of payment transaction requests to the server, the method further includes: receiving transaction identification information corresponding to each payment transaction request returned by the server, and storing the transaction identification information; When receiving multiple payment transaction requests triggered by the user on the front-end page, idempotence checks are performed on the multiple payment transaction requests according to the transaction identification information.

5. The transaction payment processing method according to claim 4, characterized in that: The transaction identification information includes a first order number, and the payment transaction request includes a second order number; and performing idempotence check on the plurality of payment transaction requests according to the transaction identification information includes: Determine the payment transaction request with the same second order number as the first order number as a payment transaction request for repeated payment; The payment transaction request for repeated payment is intercepted and processed.

6. A transaction payment processing method, characterized in that: include: When receiving multiple payment transaction requests sent by the client, performing transaction processing on the multiple payment transaction requests, starting a timer for timing, and counting the number of the multiple payment transaction requests; If the number of transaction payment requests within the preset time period is greater than the preset threshold, a random delay request is generated; The random delay request is sent to the client, where the random delay request is used to instruct the client to perform delayed sending processing on multiple payment transaction requests to be sent.

7. The transaction payment processing method according to claim 6, characterized in that: After the transaction processing is performed on the plurality of payment transaction requests, the method further includes: Generate transaction identification information corresponding to each payment transaction request; The transaction identification information is sent to the client, so that the client can perform idempotence check on the received payment transaction request according to the transaction identification information.

8. A client, characterized in that: The client includes a memory and a processor; The memory is used to store computer programs; The processor is used to execute the computer program and implement the transaction payment processing method as described in any one of claims 1 to 5 when executing the computer program.

9. A server, characterized in that: The server includes a memory and a processor; The memory is used to store computer programs; The processor is used to execute the computer program and implement the transaction payment processing method as described in any one of claims 6 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that: The computer readable storage medium stores a computer program, and when the computer program is executed by a processor, the processor implements the following: The transaction payment processing method according to any one of claims 1 to 5; or A transaction payment processing method as described in any one of claims 6 to 7.

Images