Method, device, electronic device and computer readable medium for processing a payment request

Abstract

The application discloses a method and device for processing a payment request, electronic equipment and a computer readable medium, and relates to the technical field of mobile Internet. A specific embodiment of the method comprises: receiving a payment request sent by a travel system, the payment request carrying order information, the order being generated by the travel system after a user exits a gate, the order information comprising journey information, a payment amount, a payment account, a collection account, an order generation time and an order number; determining whether there is a repeated order in a cache; if so, returning an error message of order repetition or a processing result of successful payment to the travel system; if not, storing the order number in the cache and recording the storage time of the order number, and completing a payment process according to the payment amount, the payment account and the collection account. The embodiment can solve the technical problem of low travel efficiency.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of mobile Internet technology, and in particular to a method and device for processing a payment request, an electronic device and a computer readable medium. BACKGROUND

[0002] Typically, the payment scenarios of subway travel include: buying a subway card or a subway card for travel, or swiping a code for travel. When entering the station, it is checked whether the balance exceeds the minimum fare. If the balance is lower than the minimum fare, it will be prompted to go to the customer service center for processing. When leaving the station, a payment transaction is initiated. If the balance is insufficient, it will be prompted to go to the customer service center for processing. Only after the ticket is completed and the payment is successful, the gate will be opened to let the line go.

[0003] In the process of implementing the present application, the inventors have found that there are at least the following problems in the prior art:

[0004] 1) The traditional travel payment method is to deduct the fee first and then pass through, which leads to slow gate opening, long transaction chain, and is prone to cause the gate to be unable to open due to network failure, signal failure, terminal power failure, etc., thereby leading to low travel efficiency;

[0005] 2) In the payment process, there may be transaction timeout, network jitter, etc., which leads to the subway side being unable to receive, leading to data asynchronization, thereby leading to low travel efficiency;

[0006] 3) Payment must be completed before leaving the gate. If payment cannot be made due to network or service abnormalities, etc., it will affect the passenger's travel. SUMMARY

[0007] Therefore, the embodiments of the present application provide a method and device for processing a payment request, an electronic device and a computer readable medium to solve the technical problem of low travel efficiency.

[0008] To achieve the above object, according to one aspect of the embodiments of the present application, a method for processing a payment request is provided, comprising:

[0009] receiving a payment request sent by a travel system, the payment request carrying order information, the order being generated by the travel system after a user leaves the gate, the order information including travel information, payment amount, payment account, collection account, order generation time and order number;

[0010] determining whether the current processing request volume is greater than or equal to a first request volume threshold; if yes, adding the payment request to a to-be-processed queue; if no, processing the payment request according to the following steps:

[0011] determining whether the order is repeated in the cache; if yes, returning an error message of order repetition or a processing result of successful payment to the travel system; if no, storing the order number in the cache and recording the storage time of the order number, and completing a payment process according to the payment amount, the payment account and the collection account.

[0012] Optionally, the determining whether the order is repeated in the cache includes:

[0013] determining whether the order is repeated in the cache according to the order number;

[0014] if yes, determining whether a difference between a current time and the storage time of the order number is less than a first time threshold; if yes, returning an error message of order repetition to the travel system;

[0015] if no, returning a processing result of successful payment to the travel system.

[0016] Optionally, the returning the processing result of successful payment to the travel system includes:

[0017] determining whether the processing result of the order number is successful payment;

[0018] if yes, performing idempotency processing on the order number, and returning a processing result same as a processing result returned when the payment is successful for the first time to the travel system;

[0019] if no, completing a payment process according to the payment amount, the payment account and the collection account, and storing the processing result of successful payment in the cache.

[0020] Optionally, the completing the payment process according to the payment amount, the payment account and the collection account includes:

[0021] performing payment according to the payment amount, the payment account and the collection account, and determining whether the payment is successful;

[0022] if yes, returning the processing result of successful payment to the travel system;

[0023] if no, performing manual processing or reinitiating payment according to a reason of payment failure.

[0024] Optionally, if the payment is successful, the method further includes:

[0025] determining whether a payment is made in the payment process;

[0026] If yes, the account of the cushioning fund is supplemented, and a payment success processing result is returned to the travel system;

[0027] If no, a payment success processing result is returned to the travel system.

[0028] Optionally, manual processing or reinitiating payment is performed according to the reason for payment failure, including:

[0029] It is judged whether the reason for payment failure is a business error;

[0030] If yes, manual processing is performed;

[0031] If no, payment is reinitiated after a second time threshold, until the number of times of initiating payment is greater than or equal to an abnormal retry number.

[0032] Optionally, manual processing or reinitiating payment is performed according to the reason for payment failure, including:

[0033] It is judged whether the reason for payment failure is a business error;

[0034] If yes, manual processing is performed;

[0035] If no, the payment request is added to the to-be-processed queue, and if a current processing request amount is less than a second request amount threshold, the payment request is taken out from the to-be-processed queue and processed.

[0036] In addition, according to another aspect of an embodiment of the present application, a device for processing a payment request is provided, including:

[0037] A receiving module is configured to receive a payment request sent by a travel system, the payment request carrying order information, the order being generated by the travel system after a user exits, the order information including travel information, a payment amount, a payment account, a collection account, an order generation time and an order number;

[0038] A processing module is configured to judge whether a current processing request amount is greater than or equal to a first request amount threshold; if yes, the payment request is added to a to-be-processed queue; if no, the payment request is processed according to the following steps:

[0039] It is judged whether there is a repeated order in a cache; if yes, an error message of order repetition is returned to the travel system or a payment success processing result is returned to the travel system; if no, the order number is stored in the cache and a storage time of the order number is recorded, and a payment process is completed according to the payment amount, the payment account and the collection account.

[0040] Optionally, the processing module is further configured to:

[0041] determining whether the order number exists in the cache according to the order number;

[0042] If yes, determining whether a difference between a current time and a storage time of the order number is less than a first time threshold, if yes, returning an order repetition error message to the travel system;

[0043] If no, returning a payment success processing result to the travel system.

[0044] Optionally, the processing module is further configured to:

[0045] determining whether the processing result of the order number is a payment success;

[0046] If yes, performing an idempotency processing on the order number, and returning a processing result same as a processing result returned when the payment is successful for the first time to the travel system;

[0047] If no, completing a payment process according to the payment amount, the payment account and the collection account, and storing the payment success processing result into the cache.

[0048] Optionally, the processing module is further configured to:

[0049] performing payment according to the payment amount, the payment account and the collection account, and determining whether the payment is successful;

[0050] If yes, returning a payment success processing result to the travel system;

[0051] If no, performing manual processing or reinitiating payment according to a payment failure reason.

[0052] Optionally, if the payment is successful, the processing module is further configured to:

[0053] determining whether a fund is provided in the payment process;

[0054] If yes, performing a supplement on the account of the fund, and returning a payment success processing result to the travel system;

[0055] If no, returning a payment success processing result to the travel system.

[0056] Optionally, the processing module is further configured to:

[0057] determining whether a payment failure reason is a business error;

[0058] If yes, performing manual processing;

[0059] If no, reinitiating payment after a second time threshold until a number of times of initiating payment is greater than or equal to an abnormal retry number.

[0060] Optionally, the processing module is further configured to:

[0061] determine whether the payment failure is caused by a service error;

[0062] if yes, perform manual processing;

[0063] if no, add the payment request to the to-be-processed queue, and if the current processing request volume is less than a second request volume threshold, take out the payment request from the to-be-processed queue and process the payment request.

[0064] According to another aspect of the embodiments of the present application, an electronic device is also provided, comprising:

[0065] one or more processors;

[0066] a storage device configured to store one or more programs,

[0067] when the one or more programs are executed by the one or more processors, the one or more processors implement the method of any of the above embodiments.

[0068] According to another aspect of the embodiments of the present application, a computer readable medium having a computer program stored thereon is also provided, the program, when executed by a processor, implements the method of any of the above embodiments.

[0069] According to another aspect of the embodiments of the present application, a computer program product is also provided, comprising a computer program, the computer program, when executed by a processor, implements the method of any of the above embodiments.

[0070] One embodiment of the above application has the following advantages or beneficial effects: because the payment request sent by the travel system is received, the order is generated by the travel system after the user exits, it is determined whether the current processing request volume is greater than or equal to a first request volume threshold, if yes, the payment request is added to the to-be-processed queue, and if no, the payment request is processed, so the technical problem of low travel efficiency in the prior art is overcome. The embodiment of the present application reduces the peak and limits the flow, so that the service is more stable. During the travel peak period, the user can pass first, and the order is charged when the business volume is low, which avoids the system crash caused by the charge initiated at the same time, reduces the server pressure, and directly opens the gate after the face recognition or code scanning is successful, without waiting for the charge to be successful before opening the gate, thereby improving the response efficiency and travel speed.

[0071] The further effects of the above non-conventional optional mode will be described in the following with reference to the specific embodiments. BRIEF DESCRIPTION OF DRAWINGS

[0072] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed in the embodiments or prior art description. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Among them:

[0073] Figure 1 is a flow chart of a method for processing a payment request according to an embodiment of the present application;

[0074] Figure 2 is a flow chart of a method for processing a payment request according to an embodiment of the present application;

[0075] Figure 3 is a flow chart of a method for processing a payment request according to an embodiment of the present application;

[0076] Figure 4 is a schematic diagram of peak clipping and flow limiting according to an embodiment of the present application;

[0077] Figure 5 is a schematic diagram of an apparatus for processing a payment request according to an embodiment of the present application;

[0078] Figure 6 is an exemplary system architecture diagram to which embodiments of the present application can be applied;

[0079] Figure 7 is a structural schematic diagram of a computer system of a terminal device or a server suitable for implementing embodiments of the present application. DETAILED DESCRIPTION

[0080] The exemplary embodiments of the present application will be described below with reference to the accompanying drawings, which include various details of the embodiments of the present application to assist in understanding, and should be considered as merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present application. Also, in order to be clear and concise, the description below omits the description of well-known functions and structures.

[0081] It should be noted that in the technical solutions of the present application, the collection, analysis, use, transmission and storage of user personal information comply with relevant laws and regulations and are used for legal and reasonable purposes, and are not shared, disclosed or sold outside these legal uses, and are subject to supervision and management by regulatory authorities. Necessary measures should be taken to prevent illegal access to such personal information data and to ensure that personnel with access to personal information data comply with relevant laws and regulations and ensure the security of user personal information. Once these user personal information data are no longer needed, the risk should be minimized by limiting or even prohibiting data collection and / or deleting data.

[0082] Figure 1 is a flowchart of a method for processing a payment request according to an embodiment of the present application. As shown in Figure 1 the method for processing a payment request can include:

[0083] Step 101, receiving a payment request sent by a travel system, the payment request carrying order information, the order being generated by the travel system after a user exits, the order information including journey information, payment amount, payment account, collection account, order generation time and order number.

[0084] After the user exits by swiping a card, a code or a face, the travel system (such as a subway system or a bus) sends a payment request to the payment system, and the payment system receives and analyzes the payment request sent by the travel system to obtain the order information carried in the payment request. Therefore, the order information of the order is generated by the travel system after the user exits. The order information includes journey information (entry station and exit station), payment amount (calculated by the travel system according to the entry station and the exit station), payment account (i.e. the account of the passenger), collection account, order generation time and order number.

[0085] It should be noted that after the payment system generates the order information, the user can initiate a payment request to the travel system through a terminal APP, the travel system forwards the payment request to the payment system, or the travel system directly sends a payment request to the payment system, and the present application does not limit this.

[0086] Step 102, determining whether the current processing request volume is greater than or equal to a first request volume threshold; if yes, performing step 103; if no, performing step 104.

[0087] The first request volume threshold can be pre-configured, such as 500, 800 or 1000, and after receiving the payment request sent by the travel system, it is determined whether the current processing request volume is greater than or equal to the first request volume threshold.

[0088] Step 103, add the payment request to the to-be-processed queue.

[0089] If the amount of requests currently being processed is greater than or equal to the first request threshold, it means that the current is a travel peak period, and peak clipping is needed to prevent the server from being too stressed, so the payment request is added to the to-be-processed queue, and the payment request is taken out from the to-be-processed queue and the payment is completed according to the first-in first-out principle when the low peak period.

[0090] Step 104, determine whether there is a repeated order in the cache; if yes, execute step 105; if no, execute step 106.

[0091] If the amount of requests currently being processed is less than the first request threshold, it can be directly processed, that is, to determine whether there is a repeated order in the cache according to the order number carried in the payment request.

[0092] Step 105, return an order repeat error message or a payment success processing result to the travel system.

[0093] Optionally, step 104 and step 105 can include: determining whether there is a repeated order in the cache according to the order number; if yes, determining whether the difference between the current time and the storage time of the order number is less than the first time threshold; if yes, returning an order repeat error message to the travel system; if no, returning a payment success processing result to the travel system. If there is a repeated order in the cache, it is further needed to determine whether the difference between the current time and the storage time of the order number is less than the first time threshold (such as 10 seconds or 20 seconds, etc.), and if yes, an order repeat error message is directly returned to the travel system, and the payment process is not continued, so as to avoid repeated deduction and reduce system pressure and improve the performance of the payment system. If not, a payment success processing result is returned to the travel system.

[0094] Optionally, the payment success processing result is returned to the travel system, including: judging whether the processing result of the order number is payment success; if yes, performing idempotency processing on the order number, and returning the same processing result as returned when payment is successful for the first time; if no, completing the payment process according to the payment amount, the payment account and the payment account, and storing the payment success processing result in the cache. The order number stored in the cache may have a processing result of payment success or pending payment. If the processing result of the order number is payment success, idempotency is realized by Redis, the same processing result as returned when payment is successful for the first time is returned, and the payment process is not continued. If the processing result of the order number is pending payment, the payment process is completed according to the payment amount, the payment account and the payment account carried in the payment request, and the payment success processing result is stored in the cache for next time query cache.

[0095] Step 106, storing the order number in the cache and recording the storage time of the order number, and completing the payment process according to the payment amount, the payment account and the payment account.

[0096] If there is no repeated order in the cache, it means that the payment system receives the payment request of the order for the first time, so the order number of the order is stored in the cache and the storage time of the order number is recorded for next time query cache, and then the payment process is completed according to the payment amount, the payment account and the payment account carried in the payment request, and the payment success processing is stored in the cache.

[0097] Optionally, the payment process is completed according to the payment amount, the payment account and the payment account, including: payment is made according to the payment amount, the payment account and the payment account, and it is judged whether the payment is successful; if yes, the payment success processing result is returned to the travel system; if no, manual processing or reinitiating payment is performed according to the reason for payment failure. In the payment process, payment is made according to the payment amount, the payment account and the payment account carried in the payment request, and then it is judged whether the payment is successful. If the payment is successful, the payment success processing result is returned to the travel system, and the payment success processing result is stored in the cache. If the payment fails, manual processing or reinitiating payment is performed according to the reason for payment failure, for example, reinitiating payment after five minutes or more, and the number of reinitiation is not more than five. Optionally, reinitiation can be requested at night when the request volume is low, which can reduce the request pressure during the day and achieve the purpose of peak clipping and flow limiting.

[0098] Optionally, the manual processing or reinitiating payment according to the reason of payment failure comprises: judging whether the reason of payment failure is a business error; if yes, performing manual processing; if no, reinitiating payment after a second time threshold until the number of initiated payments is greater than or equal to an abnormal retry number. In the embodiment of the application, the business error can be account abnormality or expired ID card, etc. If the reason of payment failure is a business error, manual processing is performed. If the reason of payment failure is not a business error, such as payment failure caused by network performance abnormality or system performance abnormality, payment is reinitiated after a second time threshold until the number of initiated payments is greater than or equal to an abnormal retry number. For example, reinitiation is performed after more than ten minutes, and the number of reinitiation is not more than five times.

[0099] Optionally, the manual processing or reinitiating payment according to the reason of payment failure comprises: judging whether the reason of payment failure is a business error; if yes, performing manual processing; if no, adding the payment request to the to-be-processed queue, and if the current processing request amount is less than a second request amount threshold, taking the payment request from the to-be-processed queue and processing the payment request. In another embodiment of the application, if the reason of payment failure is not a business error, the payment request is added to the to-be-processed queue. If the current processing request amount is less than a second request amount threshold, it indicates that the current is a low peak period, and the payment request is taken from the to-be-processed queue according to the first-in first-out principle and payment is completed. Therefore, the embodiment of the application can guarantee correct post-payment under high passenger flow. Because Redis cache and reinitiation mechanism are adopted, payment can be deducted more quickly and accurately. Through peak clipping and flow limiting processing, the payment request to be processed and the payment request to be reinitiated can be put into a queue, and the maximum number of payment requests to be initiated is limited. When the peak period, the payment request to be initiated can be put into the low peak period to initiate transaction, so as to relieve the system pressure bottleneck and achieve efficient use of resources.

[0100] Because the order in the peak period can cause payment abnormality due to timeout or network jitter, etc., the payment request of the payment abnormality is added to the queue to wait for reinitiation. In the low peak period, the request to be initiated in the queue is acquired, and payment is initiated.

[0101] The embodiment of the application adopts the first-pass post-payment mode, can initiate payment slowly after passing, does not cause pressure to the payment system, and does not affect the passing speed, so that the travel speed is significantly improved. Moreover, the real-time return result is returned. If timeout occurs, reinitiation is performed through the reinitiation mechanism. If the successful transaction has been paid, the payment result information saved in Redis is quickly returned, so that data consistency is guaranteed. In various special situations such as bad network signal, no mobile phone charge, and no account balance, the passenger information can be recognized when passing the gate, so that the passenger can travel smoothly, and the passenger travel is greatly facilitated.

[0102] According to various embodiments described above, it can be seen that the embodiments of the present application solve the technical problem of low travel efficiency in the prior art by receiving a payment request sent by a travel system, generating an order by the travel system after a user exits, judging whether the current processing request volume is greater than or equal to a first request volume threshold, if yes, adding the payment request to a to-be-processed queue, and if no, processing the payment request. The technical means of the embodiments of the present application make the service more stable by peak clipping and flow limiting. During a travel peak period, the user can pass first, and the order is charged when the business volume is low, avoiding system collapse caused by initiating a charge at the same time and reducing server pressure; and after face recognition or code scanning is successful, the gate is directly opened, without waiting for the charge to be successful before opening the gate, thereby improving response efficiency and travel speed.

[0103] Figure 2 is a flowchart of a method for processing a payment request according to an embodiment of the present application. As another embodiment of the present application, as shown in Figure 2 , the method for processing a payment request can include:

[0104] Step 201, receiving a payment request sent by a travel system, the payment request carrying order information, the order being generated by the travel system after a user exits, and the order information including travel information, a payment amount, a payment account, a collection account, an order generation time, and an order number.

[0105] Step 202, judging whether the current processing request volume is greater than or equal to a first request volume threshold; if yes, executing step 203; and if no, executing step 204.

[0106] Step 203, adding the payment request to a to-be-processed queue.

[0107] Step 204, judging whether there is a repeated order in the cache according to the order number; if yes, executing step 205; and if no, executing step 208.

[0108] Step 205, judging whether the difference between the current time and the storage time of the order number is less than a first time threshold; if yes, executing step 206; and if no, executing step 207.

[0109] Step 206, returning an order repetition error message to the travel system.

[0110] Step 207, returning a payment success processing result to the travel system.

[0111] Step 208, judging whether there is a repeated order in the cache; if yes, returning an order repetition error message or a payment success processing result to the travel system; if no, storing the order number into the cache and recording the storage time of the order number, and completing a payment process according to the payment amount, the payment account and the collection account.

[0112] The embodiment of the application can reduce media dependence, the travel system can automatically initiate payment deduction and payment according to an order, passengers can also actively initiate payment and payment at leisure, double protection of payment deduction function; due to the use of cache technology, database query is reduced, execution speed is improved, repeated deduction is prevented through deduplication, successful orders are directly returned, system response speed is improved, and system resource invalid occupation is reduced.

[0113] In addition, the specific implementation of the method for processing a payment request in one of the reference embodiments of the application has been described in detail in the above-described method for processing a payment request, and therefore repeated content will not be described here.

[0114] Figure 3 is a flowchart of a method for processing a payment request according to another reference embodiment of the application. As another embodiment of the application, as shown in Figure 3 the method for processing a payment request can include:

[0115] Step 301, receiving a payment request sent by a travel system, the payment request carrying order information, the order being generated by the travel system after a user exits, and the order information including travel information, a payment amount, a payment account, a collection account, an order generation time and an order number.

[0116] Step 302, judging whether a current processing request amount is greater than or equal to a first request amount threshold; if yes, executing step 303; if no, executing step 304.

[0117] The embodiment of the application adopts a first-pass payment mode, which can initiate deduction after passing, does not cause pressure to a payment system, and does not affect passing speed. Assuming that there are 2000 people passing per minute during a peak working period, and the payment system can process about 500 payment requests per minute. Figure 4 As shown in the figure, all generated payment requests are stored in a database, the state is payment pending, a flow limiter counter is set to 500, the travel system initiates payment to the payment system when an order is generated, and the flow limiter is passed to judge whether a current processing request amount (n) is greater than or equal to 500. If less than 500, the payment request is sent to the payment system, and the counter n+1 is counted. If greater than 500, the payment request is added to the payment pending queue.

[0118] Step 303, adding the payment request to a pending processing queue.

[0119] Step 304: Determine if there are duplicate orders in the cache; if yes, proceed to step 305; if no, proceed to step 306.

[0120] Step 305: Return an error message indicating a duplicate order or a successful payment result to the travel system.

[0121] Step 306: Store the order number in the cache and record the storage time of the order number; complete the payment process based on the payment amount, the payment account, and the receiving account.

[0122] Step 307: Determine whether advance payment was made during the payment process; if yes, proceed to step 308; otherwise, proceed to step 308.

[0123] Step 308: Make up the outstanding payment in the account and return a successful payment result to the travel system;

[0124] Step 309: Return the payment success result to the travel system.

[0125] To ensure smooth travel, this invention decouples gate opening and fare deduction, and provides advance payment for deductions. The travel system opens the gate upon recognizing passenger information. During payment, as long as the account is not blacklisted, the payment system does not check for account balance. When initiating a deduction, if the account has sufficient funds, it will attempt to deduct from the linked bank card. If the bank card balance is also insufficient, an advance payment provider (such as a financial institution) will advance the funds. This ensures that the travel system's deductions and reconciliation are normal. When a specified number of advance payments are reached, the passenger is blacklisted and must pay the outstanding amount before being allowed to travel again.

[0126] In addition, the specific implementation details of the method for processing payment requests in another reference embodiment of the present invention have been described in detail in the above-described method for processing payment requests, so the details will not be repeated here.

[0127] Figure 5 This is a schematic diagram of an apparatus for processing payment requests according to an embodiment of the present invention. Figure 5 As shown, the device 500 for processing payment requests includes a receiving module 501 and a processing module 502. The receiving module 501 receives payment requests sent by the travel system. These requests carry order information, generated by the travel system after the user exits the gate. The order information includes trip information, payment amount, payment account, receiving account, order generation time, and order number. The processing module 502 determines whether the current number of processing requests is greater than or equal to a first request volume threshold. If so, the payment request is added to a pending queue. If not, the payment request is processed according to the following steps:

[0128] determining whether there is a repeated order in the cache; if yes, returning an error message of order repetition or a processing result of successful payment to the travel system; if no, storing the order number in the cache and recording a storage time of the order number, and completing a payment process according to the payment amount, the payment account and the collection account.

[0129] Optionally, the processing module 502 is further configured to:

[0130] determining whether there is a repeated order in the cache according to the order number;

[0131] if yes, determining whether a difference between a current time and the storage time of the order number is less than a first time threshold, and if yes, returning an error message of order repetition to the travel system;

[0132] if no, returning a processing result of successful payment to the travel system.

[0133] Optionally, the processing module 502 is further configured to:

[0134] determining whether the processing result of the order number is successful payment;

[0135] if yes, performing idempotency processing on the order number, and returning a processing result same as a processing result returned when payment is successful for the first time to the travel system;

[0136] if no, completing a payment process according to the payment amount, the payment account and the collection account, and storing a processing result of successful payment in the cache.

[0137] Optionally, the processing module 502 is further configured to:

[0138] performing payment according to the payment amount, the payment account and the collection account, and determining whether the payment is successful;

[0139] if yes, returning a processing result of successful payment to the travel system;

[0140] if no, performing manual processing or reinitiating payment according to a reason of payment failure.

[0141] Optionally, if the payment is successful, the processing module 502 is further configured to:

[0142] determining whether a fund is advanced in the payment process;

[0143] if yes, performing a supplementary payment on the account of the advanced fund, and returning a processing result of successful payment to the travel system;

[0144] If not, the system will return a successful payment result.

[0145] Optionally, the processing module 502 is further configured to:

[0146] Determine if the payment failure was due to a business error.

[0147] If so, then manual processing will be performed;

[0148] If not, the payment will be re-initiated after the second time threshold until the number of payment attempts is greater than or equal to the number of abnormal retries.

[0149] Optionally, the processing module 502 is further configured to:

[0150] Determine if the payment failure was due to a business error.

[0151] If so, then manual processing will be performed;

[0152] If not, the payment request is added to the pending queue. If the current number of requests being processed is less than the second request threshold, the payment request is retrieved from the pending queue and processed.

[0153] It should be noted that the specific implementation of the device for processing payment requests described in this invention has been described in detail in the method for processing payment requests described above, so the content will not be repeated here.

[0154] Figure 6 An exemplary system architecture 600 is shown, in which the method or apparatus for processing payment requests can be applied according to embodiments of the present invention.

[0155] like Figure 6 As shown, system architecture 600 may include terminal devices 601, 602, and 603, a network 604, and a server 605. Network 604 serves as the medium for providing communication links between terminal devices 601, 602, and 603 and server 605. Network 604 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0156] Users can use terminal devices 601, 602, and 603 to interact with server 605 via network 604 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 601, 602, and 603, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0157] The terminal devices 601, 602, and 603 can be various electronic devices with display screens and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, desktop computers, and the like.

[0158] The server 605 can be a server providing various services, such as a background management server supporting a shopping website browsed by a user using the terminal device 601, 602, or 603 (only as an example). The background management server can analyze and process received item information query requests and the like, and feed back processing results to the terminal device.

[0159] It should be noted that the method for processing a payment request provided by the embodiments of the present application is generally executed by the server 605, and accordingly, the apparatus for processing a payment request is generally arranged in the server 605.

[0160] It should be understood that, Figure 6 The number of terminal devices, networks, and servers in the above-mentioned system is only illustrative. Any number of terminal devices, networks, and servers can be provided according to implementation needs.

[0161] Reference is made below to Figure 7 which shows a structural schematic diagram of a computer system 700 of a terminal device suitable for implementing the embodiments of the present application. Figure 7 The terminal device shown is only an example, and should not bring any limitation to the functions and use range of the embodiments of the present application.

[0162] As shown in Figure 7 , the computer system 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) 702 or programs loaded from a storage portion 708 into a random access memory (RAM) 703. Various programs and data required for the operation of the system 700 are also stored in the RAM 703. The CPU 701, the ROM 702, and the RAM 703 are connected to each other through a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0163] The following components are connected to the I / O interface 705: an input part 706 including a keyboard, a mouse, etc.; an output part 707 including a display such as a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage part 708 including a hard disk, etc.; and a communication part 709 including a network interface card such as a LAN card, a modem, etc. The communication part 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the I / O interface 705 as necessary. A removable medium 711 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is attached to the drive 710 as necessary, so that a computer program read out therefrom is installed in the storage part 708 as necessary.

[0164] In particular, the processes described above with reference to the flowcharts can be implemented as a computer software program in accordance with the embodiments disclosed herein. For example, the embodiments disclosed herein include a computer program comprising a computer program carried on a computer readable medium, the computer program containing program code for executing the methods illustrated by the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network by the communication part 709, and / or installed from the removable medium 711. When the computer program is executed by the central processing unit (CPU) 701, the above-described functions defined in the system of the present invention are executed.

[0165] It should be noted that the computer-readable medium shown in the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or instrument, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to, an electrical connection with one or more conductive wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device or instrument. In the present application, the computer-readable signal medium can include a data signal propagating in a baseband or as a carrier wave part of a carrier wave, in which computer-readable program code is carried. Such a propagating data signal can take various forms, including but not limited to electromagnetic signals, optical signals or any suitable combination of the above. The computer-readable signal medium can also be any computer-readable medium other than the computer-readable storage medium, which can send, propagate or transmit a program for use by or in conjunction with an instruction execution system, device or instrument. The program code contained on the computer-readable medium can be transmitted by any suitable medium, including but not limited to wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0166] The flowcharts and block diagrams in the drawings illustrate the possible implementation architectures, functions and operations of the systems, methods and computer programs according to various embodiments of the present application. In this regard, each block in the flowchart or block diagram can represent a module, a program segment or a part of code containing one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur in different order than that shown in the drawings. For example, two blocks that are shown in succession can actually be executed substantially in parallel, and they can also be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram or flowchart, and the combination of blocks in the block diagram or flowchart, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0167] The modules described in the embodiments of the present application can be implemented in the form of software or in the form of hardware. The modules described can also be arranged in a processor, for example, a processor can be described as comprising a receiving module and a processing module, wherein the names of the modules do not constitute a limitation on the modules themselves in some cases.

[0168] As another aspect, the present application also provides a computer readable medium, which can be included in the device described in the above embodiments, or can exist independently without being assembled into the device. The computer readable medium carries one or more programs, and when the one or more programs are executed by the device, the device implements the following method: receiving a payment request sent by a travel system, the payment request carrying order information, the order being generated by the travel system after a user exits, the order information including travel information, a payment amount, a payment account, a collection account, an order generation time and an order number; determining whether there is a repeated order in a cache; if yes, returning an error message of order repetition or a processing result of payment success to the travel system; if no, storing the order number into the cache and recording a storage time of the order number, and completing a payment process according to the payment amount, the payment account and the collection account.

[0169] As another aspect, the embodiments of the present application also provide a computer program product, comprising a computer program, which is executed by a processor to implement the method described in any of the above embodiments.

[0170] According to the technical scheme of the embodiments of the present application, the technical means of receiving a payment request sent by a travel system, the order being generated by the travel system after a user exits, determining whether a current processing request amount is greater than or equal to a first request amount threshold, if yes, adding the payment request to a to-be-processed queue, and if no, processing the payment request, overcomes the technical problem of low travel efficiency in the prior art. The embodiments of the present application make the service more stable by peak clipping and flow limiting. In a travel peak period, the user can pass first, and the order can be charged when the business volume is low, avoiding system collapse caused by charging at the same time and reducing server pressure; and after face recognition or code scanning is successful, the gate is directly opened, without waiting for the charging to be successful before opening the gate, thereby improving response efficiency and travel speed.

[0171] The above specific embodiments do not constitute a limitation on the protection scope of the present application. Those skilled in the art should understand that various modifications, combinations, sub-combinations and substitutions can be made depending on design requirements and other factors. Any modification, equivalent replacement and improvement made within the spirit and principles of the present application shall fall within the scope of the present application.

Claims

1. A method for processing payment requests, characterized in that, Applied to payment systems, including: After a user exits the gate by swiping a card, scanning a code, or scanning their face, they receive a payment request from the travel system. The payment request carries order information, which is generated by the travel system after the user exits the gate. The order information includes trip information, payment amount, payment account, receiving account, order generation time, and order number. Determine whether the current number of requests being processed is greater than or equal to the first request threshold; if yes, add the payment request to the pending queue; if no, process the payment request according to the following steps: Determine if there are duplicate orders in the cache; if so, return a duplicate order error message or a successful payment result to the travel system; if not, store the order number in the cache and record the storage time of the order number, and complete the payment process according to the payment amount, the payment account, and the receiving account. Determine if a duplicate order exists in the cache. If so, return a duplicate order error message or a successful payment result to the travel system, including: Determine whether there are duplicate orders in the cache based on the order number; If so, determine whether the difference between the current time and the storage time of the order number is less than the first time threshold. If so, return an error message indicating that the order is duplicated to the travel system. If not, the system will return a successful payment result.

2. The method according to claim 1, characterized in that, Returning a successful payment result to the travel system, including: Determine whether the processing result for the order number is successful payment; If so, then the order number is idempotent, and the same processing result as that returned when the first payment was successful is returned to the travel system; If not, the payment process is completed based on the payment amount, the payment account, and the receiving account, and the successful payment result is stored in the cache.

3. The method according to claim 1, characterized in that, The payment process is completed based on the payment amount, the payment account, and the receiving account, including: The payment is made based on the payment amount, the payment account, and the receiving account, and it is then determined whether the payment was successful. If so, a successful payment result will be returned to the travel system; If not, the payment will be processed manually or re-initiated depending on the reason for the payment failure.

4. The method according to claim 3, characterized in that, If the payment is successful, the method further includes: Determine whether advance payment was made during the payment process; If so, the advance payment will be made up in the account, and a successful payment result will be returned to the travel system. If not, the system will return a successful payment result.

5. The method according to claim 3, characterized in that, Depending on the reason for the payment failure, manual processing or re-initiating the payment will be performed, including: Determine if the payment failure was due to a business error; If so, then manual processing will be performed; If not, the payment will be re-initiated after the second time threshold until the number of payment attempts is greater than or equal to the number of abnormal retries.

6. The method according to claim 3, characterized in that, Depending on the reason for the payment failure, manual processing or re-initiating the payment will be performed, including: Determine if the payment failure was due to a business error; If so, then manual processing will be performed; If not, the payment request is added to the pending queue. If the current number of requests being processed is less than the second request threshold, the payment request is retrieved from the pending queue and processed.

7. An apparatus for processing payment requests, characterized in that, Set up in the payment system, including: The receiving module is used to receive a payment request sent by the travel system after the user exits the gate by swiping a card, scanning a code, or scanning a face. The payment request carries order information. The order is generated by the travel system after the user exits the gate. The order information includes trip information, payment amount, payment account, receiving account, order generation time, and order number. The processing module is used to determine whether the current number of processing requests is greater than or equal to a first request volume threshold; if so, the payment request is added to the pending queue; if not, the payment request is processed according to the following steps: Determine if there are duplicate orders in the cache; if so, return a duplicate order error message or a successful payment result to the travel system; if not, store the order number in the cache and record the storage time of the order number, and complete the payment process according to the payment amount, the payment account, and the receiving account. The processing module is also used for: Determine whether there are duplicate orders in the cache based on the order number; If so, determine whether the difference between the current time and the storage time of the order number is less than the first time threshold. If so, return an error message indicating that the order is duplicated to the travel system. If not, the system will return a successful payment result.

8. The apparatus according to claim 7, characterized in that, The processing module is also used for: Determine whether the processing result for the order number is successful payment; If so, then the order number is idempotent, and the same processing result as that returned when the first payment was successful is returned to the travel system; If not, the payment process is completed based on the payment amount, the payment account, and the receiving account, and the successful payment result is stored in the cache.

9. The apparatus according to claim 7, characterized in that, The processing module is also used for: The payment is made based on the payment amount, the payment account, and the receiving account, and it is then determined whether the payment was successful. If so, a successful payment result will be returned to the travel system; If not, the payment will be processed manually or re-initiated depending on the reason for the payment failure.

10. The apparatus according to claim 9, characterized in that, If the payment is successful, the processing module is further used for: Determine whether advance payment was made during the payment process; If so, the advance payment will be made up in the account, and a successful payment result will be returned to the travel system. If not, the system will return a successful payment result.

11. The apparatus according to claim 9, characterized in that, The processing module is also used for: Determine if the payment failure was due to a business error; If so, then manual processing will be performed; If not, the payment will be re-initiated after the second time threshold until the number of payment attempts is greater than or equal to the number of abnormal retries.

12. The apparatus according to claim 9, characterized in that, The processing module is also used for: Determine if the payment failure was due to a business error; If so, then manual processing will be performed; If not, the payment request is added to the pending queue. If the current number of requests being processed is less than the second request threshold, the payment request is retrieved from the pending queue and processed.

13. An electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-6.

14. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-6.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-6.

Images