A method, apparatus, device, medium and product of payment processing

Abstract

This specification provides a method, apparatus, device, medium, and product for payment processing. The solution may include: obtaining a payment processing request; extracting key information from the payment processing request; the key information including payer information, payee information, and transaction amount information; determining, based on the key information and known transaction information, whether the payment processing request carries a risk of duplicate payment; the known transaction information including transaction information acquired within a preset time period prior to obtaining the payment processing request; and if a risk of duplicate payment exists, sending a payment reminder message to the payer's terminal to prompt whether to continue the transaction.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device, medium and product for payment processing. Background Technology

[0002] With the development of smart terminals and the popularization of network applications, more and more payment scenarios have emerged. Users can perform various payment operations through payment-enabled applications installed on their terminals. However, duplicate payments are inevitable in these scenarios. Duplicate payments often result in financial losses for users, making it crucial to accurately handle them. Summary of the Invention

[0003] In view of the above, one or more embodiments of this specification provide a method for payment processing, an apparatus for payment processing, a computing device, a computer-readable storage medium, and a computer program product for accurately identifying duplicate payment transactions.

[0004] According to a first aspect of one or more embodiments of this specification, a payment processing method is provided, applied to a server, comprising: Get the payment processing request; Extract key information from the payment processing request; the key information includes payer information, payee information, and transaction amount information; Based on the key information and known transaction information, it is determined whether the payment processing request carries the risk of duplicate payment; the known transaction information includes transaction information acquired within a preset time period prior to acquiring the payment processing request; If there is a risk of duplicate payment, a payment reminder message will be sent to the payer's terminal to prompt whether to continue the transaction.

[0005] According to a second aspect of one or more embodiments of this specification, a payment processing method is provided, applied to a payer terminal, comprising: Based on the user's payment trigger operation, a payment processing request is sent to the server. The server determines whether the payment processing request poses a risk of duplicate payment. The payment processing request includes payer information, payee information, and transaction amount information. If the payment processing request carries the risk of duplicate payment, a payment reminder message will be displayed to prompt whether to continue the transaction.

[0006] According to a third aspect of one or more embodiments of this specification, a payment processing apparatus is provided, applied to a server, comprising: The request retrieval module is used to retrieve payment processing requests; The information extraction module is used to extract key information from the payment processing request; the key information includes payer information, payee information, and transaction amount information. The risk assessment module is used to determine whether the payment processing request carries the risk of duplicate payment based on the key information and known transaction information; the known transaction information includes transaction information acquired within a preset time period prior to acquiring the payment processing request; The sending module is used to send a payment reminder message to the payer's terminal, prompting them whether to continue the transaction, if there is a risk of duplicate payment.

[0007] According to a fourth aspect of one or more embodiments of this specification, a payment processing apparatus is provided, applied to a first terminal, comprising: The request sending module is used to send a payment processing request to the server based on the user's payment trigger operation. The server determines whether the payment processing request has the risk of duplicate payment. The payment processing request includes payer information, payee information, and transaction amount information. The information display module is used to display payment reminder information to prompt whether to continue the transaction if there is a risk of duplicate payment in the payment processing request.

[0008] According to a fifth aspect of one or more embodiments of this specification, a computing device is provided, including a memory and a processor; the memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the above-described method.

[0009] According to a sixth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions which, when executed by a processor, implement the steps of the method described above.

[0010] According to a seventh aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0011] One embodiment of this specification can achieve at least the following beneficial effects: After receiving a payment processing request, the server can extract key information from the request. Based on the payer information, payee information, transaction amount information, and known transaction information within this key information, it can determine whether there is a risk of duplicate payment. If such a risk exists, the payer can be alerted. In this way, the key information contained in the payment processing request can effectively distinguish between consecutive different payments made by a user to the same merchant and genuine duplicate payments, thereby accurately identifying the risk of duplicate payment. Furthermore, it can alert the payer when a risk exists, not only avoiding interrupting the user's normal payment process and improving the user's payment experience, but also improving payment processing efficiency. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a schematic diagram illustrating an application scenario of a payment processing method provided in one embodiment of this specification; Figure 2 This is a flowchart illustrating a payment processing method provided in one embodiment of this specification; Figure 3 This is a flowchart illustrating a payment processing method provided in one embodiment of this specification; Figure 4 This is a flowchart illustrating a payment processing method provided in one embodiment of this specification; Figure 5 This is a flowchart illustrating a payment processing method provided in one embodiment of this specification; Figure 6 This is a schematic diagram of a reminder page for displaying payment reminder information provided in one embodiment of this specification; Figure 7 This is a schematic diagram of a reminder page for displaying payment reminder information provided in one embodiment of this specification; Figure 8 This is a flowchart illustrating a payment processing method provided in one embodiment of this specification; Figure 9 This is a schematic diagram of the structure of a payment processing device provided in one embodiment of this specification; Figure 10 This is a schematic diagram of the structure of a payment processing device provided in one embodiment of this specification; Figure 11 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0014] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0015] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0016] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “an,” “an,” “the,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification includes any or all possible combinations of one or more associated listed items.

[0017] The terms “comprising,” “including,” or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded.

[0018] Although the terms "first," "second," etc., may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, "first" may also be referred to as "second," and similarly, "second" may also be referred to as "first," without departing from the scope of one or more embodiments of this specification. Ordinal numbers such as "first," "second," etc., do not necessarily indicate order; often they are used to facilitate the distinction of objects. For example, "first server" and "second server" usually refer to two servers. To distinguish these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0019] Depending on the context, the word "if" as used here can be interpreted as "when," "when," or "in response to determination."

[0020] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0021] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0022] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0023] With the development of smart terminals and the popularization of network applications, more and more payment scenarios have emerged, allowing users to perform various payment operations through payment-enabled applications installed on their terminals. However, in these various payment scenarios, duplicate payments are inevitable.

[0024] In related technologies, a fixed-time period reminder method is typically used to handle duplicate payments. For example, within a fixed time period, such as one minute, if a user successfully pays at a merchant and then makes another payment at the same merchant within one minute, a reminder is sent to the user so they can confirm whether it's a duplicate payment. However, in practical applications, users may use separate payments for multiple items. For instance, if a user pays for one item and then wants to purchase the same item again, they need to make another payment. Or, if a user has multiple coupons, but each payment can only use one coupon, they might make separate payments for multiple items to use those coupons. In these situations, related technologies may send duplicate payment confirmation reminders to the user, which not only inconveniences the user but also reduces payment processing efficiency.

[0025] To address the shortcomings of existing technologies, this solution provides the following embodiments: Figure 1 This is a schematic diagram illustrating an application scenario of a payment processing method provided in one embodiment of this specification. For example... Figure 1 As shown, this application scenario includes terminal 1 and server 2.

[0026] In this embodiment, terminal 1 can be a smartphone. In one specific embodiment, terminal 1 can also be one or more of a desktop computer, laptop computer, tablet computer, IoT device, portable wearable device, or immersive image display device. The IoT device can be one or more of a smart speaker, smart TV, smart air conditioner, or smart in-vehicle device. The portable wearable device can be one or more of a smartwatch, smart bracelet, or head-mounted device. The immersive image display device includes, but is not limited to, augmented reality (AR) devices and virtual reality (VR) devices.

[0027] Server 2 can be a standalone physical server, a server cluster consisting of multiple physical servers, or a distributed file system. It can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0028] In the embodiments described in this specification, terminal 1 and server 2 can be directly or indirectly connected via wired or wireless communication.

[0029] Terminal 1 can be the terminal used by the payer. The payer can use Terminal 1 to make payments, such as scanning a merchant's payment code and initiating a payment. Terminal 1 can send a payment processing request to Server 2, which then receives the payment processing request.

[0030] Alternatively, terminal 1 can also be the terminal used by the payee. For example, the payer can present a payment code, which the merchant can scan using terminal 1, or obtain payment identification information representing the payer's payment account via near-field communication, and then initiate payment. Terminal 1 can then send the payment processing request to server 2, which will then receive the payment processing request.

[0031] Server 2 can extract key information from the payment processing request and, based on the key information and known transaction information, determine whether there is a risk of duplicate payment in the payment processing request. If there is a risk of duplicate payment, it sends a payment reminder message to terminal 1 to prompt whether to continue the transaction.

[0032] The payment processing method provided in the embodiments of this specification will be described below with reference to the accompanying drawings.

[0033] Figure 2 This is a flowchart illustrating a payment processing method according to an embodiment of this specification. From a programming perspective, the entity executing the process can be a program hosted on a terminal server. From a hardware perspective, the entity executing the process can be any device, equipment, platform, or cluster of devices with computing and processing capabilities. The payment processing method of this embodiment can be applied to a server. Figure 2 As shown, the method may include the following steps.

[0034] Step 202: Obtain payment processing request.

[0035] In one embodiment of this specification, a user can initiate a payment processing request through a terminal, and the terminal sends the user's payment processing request to the server, so that the server can obtain the user's payment processing request.

[0036] In one specific implementation, a payment processing request can be a user's request to make an electronic payment. In practical applications, there can be various payment scenarios where a user initiates a payment processing request through a terminal. Optionally, the payment scenario can be a scanning payment code scenario, such as a user scanning a merchant's payment code to make a payment, or a user showing their payment code to a merchant to make a payment. Optionally, the payment scenario can be a near-field communication (NFC) based payment scenario, such as a user touching a merchant's NFC-enabled terminal. Optionally, the payment scenario can also be an order placed on an online trading platform, such as a user purchasing goods on a shopping platform and then paying by entering a password or through fingerprint, facial recognition, or password-free payment.

[0037] In one specific implementation, the payment processing request can be initiated by the payer. Optionally, the payer can initiate the payment processing request through their terminal, which then sends the request to the server, allowing the server to receive the payment processing request.

[0038] In one specific implementation, the payment processing request can be initiated by the payee. Optionally, the payee can initiate the payment processing request through their terminal, which then sends the request to the server, allowing the server to receive the payment processing request.

[0039] Step 204: Extract key information from the payment processing request. This key information includes payer information, payee information, and transaction amount information.

[0040] In one embodiment of this specification, the payment processing request may include at least one of the following: payer information, payee information, and transaction amount information.

[0041] Optionally, the payer information can be a unique identifier for the payer. For example, the payer information could be the payer's payment account identifier, the payer's identity identifier, or the payer's terminal identifier. Optionally, the payee information can be a unique identifier for the payee. For example, the payee information could be the payee's receiving account identifier or the payee's identity identifier. Optionally, the transaction amount information can be the amount paid by the payer to the payee.

[0042] In one specific implementation, the payment processing request may further include at least one of transaction type information, transaction time information, and transaction identification information. Optionally, the transaction type information may include transaction type information categorized by transaction amount, such as transaction type information representing large transactions, transaction type information representing small transactions, etc. Transaction type information may also include transaction type information categorized by transaction scenario, such as transaction type information representing consumer payments, transaction type information representing money transfers, transaction type information representing top-ups, etc. Optionally, the transaction time information may be information indicating the time of this transaction. The transaction time information may be the time information when the terminal initiates the payment processing request, or it may be the time information when the server obtains the payment processing request. Optionally, the transaction identification information may be identification information that uniquely identifies this payment.

[0043] In one embodiment of this specification, in order to identify whether the current payment is a duplicate payment, key information can be extracted from the payment processing request, and then the extracted key information can be compared with previous transaction information to determine whether the current payment is a duplicate payment.

[0044] In one embodiment of this specification, the extracted key information may include at least one of payer information, payee information, and transaction amount information. In practical applications, various methods can be used to extract key information. As a specific implementation, field mapping rules can be used to extract key information. For example, a mapping table between fields and key information can be pre-defined, and key information can be extracted from the payment processing request based on this mapping table. For instance, the "uid" field can correspond to payer information, so the value of the "uid" field in the payment processing request can be used as the payer information. Similarly, the "smid" field can correspond to payee information, so the value of the "smid" field in the payment processing request can be used as the payee information. Likewise, the "amount" field can correspond to transaction amount information, so the value of the "amount" field in the payment processing request can be used as the transaction amount information. As another specific implementation, a rule engine can be used to extract key information. For example, parsing rules can be pre-defined, and these rules can include the path information of key information in the payment request processing, allowing the key information in the payment processing request to be parsed according to the parsing rules. As another specific implementation, regular expressions can be used to extract key information. For example, you can write regular expressions for key information such as payer information, payee information, and transaction amount information, and then use the written regular expressions to match the payment processing request to extract the key information in the payment processing request.

[0045] As one specific implementation method, the extracted key information may also include at least one of transaction type information, transaction time information, and transaction identifier information. Optionally, the transaction type information, transaction time information, and transaction identifier information can be extracted using at least one of the field mapping rules, rule engines, and regular expressions described above.

[0046] Step 206: Based on the key information and known transaction information, determine whether the payment processing request carries the risk of duplicate payment. The known transaction information includes transaction information acquired within a preset time period prior to obtaining the payment processing request.

[0047] In one embodiment of this specification, the known transaction information may be information obtained before the payment processing procedure is executed. Optionally, the known transaction information may include other payment processing requests, such as historical payment processing requests. Alternatively, the known transaction information may include historical payment result information. As one specific implementation, the known transaction information may include at least one of the following: payer information, payee information, transaction amount information, transaction type information, transaction time information, and transaction identifier information.

[0048] In one embodiment of this specification, the preset duration can be 1 second, 5 seconds, 10 seconds, etc., or it can be determined according to actual needs, and is not limited here.

[0049] One specific implementation method is to compare the key information with known transaction information to determine whether there is a risk of duplicate payment in the payment processing request. Optionally, it can be determined whether there is known transaction information containing the key information. If known transaction information containing the key information exists, then it can be determined that there is a risk of duplicate payment. If known transaction information containing the key information does not exist, then it can be determined that there is no risk of duplicate payment.

[0050] Step 208: If there is a risk of duplicate payment, a payment reminder message is sent to the payer's terminal to prompt whether to continue the transaction.

[0051] In one embodiment of this specification, to avoid user financial loss, a payment reminder message can be sent to the payer's terminal to prompt whether to continue the transaction when there is a risk of duplicate payment. As a specific implementation, the payment reminder message could be "You have just initiated the same payment; do you wish to continue?" or "You have just completed the same payment; do you wish to continue?".

[0052] Optionally, the payer's terminal may display payment reminder information to prompt the user whether to continue the transaction.

[0053] In one specific implementation, the payment reminder information may include controls for the user to confirm continuing the payment and controls for the user to confirm not to continue the payment. Optionally, the user can confirm to continue the payment by selecting the "continue payment" control, and the server can then process the transaction corresponding to the payment processing request. Alternatively, the user can confirm not to continue the payment by selecting the "not to continue payment" control, and the server can then not process the transaction corresponding to the payment processing request.

[0054] The various technical features in the above embodiments can be combined arbitrarily, as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they have not been described one by one. Therefore, the arbitrary combination of various technical features in the above embodiments is also within the scope of this specification.

[0055] In one embodiment of this specification, key information can be extracted from the payment processing request. Based on the payer information, payee information, transaction amount information, and known transaction information in the key information, it can be determined whether there is a risk of duplicate payment. Compared with the duplicate payment reminder method using a fixed time period in related technologies, this method can effectively distinguish between consecutive different payments made by a user to the same merchant and genuine duplicate payments, thereby accurately identifying the risk of duplicate payment. This not only avoids disturbing the user during normal payment, improving the user payment experience, but also improves payment processing efficiency.

[0056] based on Figure 2 In addition to the method described herein, this specification also provides some implementation methods of the method, which will be described below.

[0057] In one embodiment of this specification, if, based on key information and known transaction information, it is determined that the payment processing request does not pose a risk of duplicate payment, the server may process the payment processing request. Optionally, the payment processing method in one embodiment of this specification may further include: If there is no risk of duplicate payment, then a resource transfer process is executed based on the payment processing request.

[0058] Optionally, if the server determines that there is no risk of duplicate payment, it is not necessary to send a payment reminder message to the payer's terminal. Optionally, a resource transfer process can be executed based on the payer information, payee information, and transaction amount information in the payment processing request. As a specific implementation, the resource transfer process can transfer the quantity of resources represented by the transaction amount information from the payer's account corresponding to the payer information to the payee's account corresponding to the payee information.

[0059] As one specific implementation, the known transaction information may include historical payment result information. By determining whether historical payment result information containing the key information exists, the risk of duplicate payment in the payment processing request can be assessed. Optionally, the payment processing method of one embodiment of this specification may further include: If any payment processing request is successfully processed, the payment result information corresponding to the payment processing request is cached in the result information database.

[0060] The step of determining whether the payment processing request carries a risk of duplicate payment based on the key information and known transaction information may include: Based on the key information, it is determined whether there is target payment result information in the result information database that matches the payment processing request. The target payment result information and the payment processing request are for the same payee and payer, and the transaction amount is the same. Furthermore, the difference between the transaction result time of the target payment result information and the request time of the payment processing request is less than or equal to a first preset duration.

[0061] If the result information database contains target payment result information that matches the payment processing request, then it is determined that the payment processing request carries the risk of duplicate payment.

[0062] If the result information database does not contain any target payment result information that matches the payment processing request, then it is determined that the payment processing request does not pose a risk of duplicate payment.

[0063] In one embodiment of this specification, after processing a transaction request, the server can store the payment result information corresponding to the successfully processed payment request in a result information database. The information in this result information database can be continuously updated. A successfully processed payment request can refer to a payment request for which the resource transfer process has been successfully executed. Optionally, the payment result information may include at least one of the following: payer information, payee information, transaction amount information, transaction type information, transaction time information, and transaction identifier information. As a specific implementation, the result information database can be the server's database or a database that the server has access to; specifically, it can be a cached database or a database in memory.

[0064] In practical applications, the risk of duplicate payment can be determined by checking if a target payment result matching the payment processing request exists in the result information database. If it does, the risk of duplicate payment is confirmed; if not, the risk of duplicate payment is not confirmed.

[0065] In one embodiment of this specification, the target payment result information matching the payment processing request may refer to payment result information that contains the same payer information, payee information, transaction amount information as the key information, and the difference between the transaction result time and the request time of the payment processing request is less than or equal to a first preset duration.

[0066] Optionally, the transaction time information in the payment result information may include information indicating the transaction start time and information indicating the transaction end time. As one specific implementation, the information indicating the transaction start time may be the time information when the payer's terminal or the payee's terminal initiates the payment processing request, or it may be the time information when the server receives the payment processing request. As one specific implementation, the information indicating the transaction result time may be the time information when the resource transfer process is successfully executed.

[0067] Optionally, the request time for the payment processing request can be the time information when the payer's terminal or the payee's terminal initiates the payment processing request, or it can be the time information when the server obtains the payment processing request.

[0068] In one embodiment of this specification, the first preset duration can be determined based on the time taken by the server to process historical payment processing requests. Optionally, the average time taken to process historical payment processing requests can be used as the preset duration. Alternatively, the maximum time taken to process historical payment processing requests can be used as the preset duration. The time taken by the server to process historical payment processing requests can refer to the time between the request time of the historical payment processing request and the transaction end time corresponding to the historical payment processing request. Optionally, the preset duration can be 1 second, 5 seconds, 10 seconds, etc., and can be determined according to actual needs, without limitation herein.

[0069] As one specific implementation, if the result information database contains target payment result information matching the payment processing request, the payment reminder information includes a prompt indicating that the user has already paid the same amount. Optionally, a specific payment reminder message could be, "You have already paid for an order of the same amount at this merchant; please confirm whether you need to pay again."

[0070] In practical applications, different payees may have different transaction frequencies. For example, within a unit of time, some payees may complete one transaction, while others may complete five transactions. To avoid affecting transaction processing for payees and to ensure the accuracy of duplicate payment identification, a first preset duration can be determined based on the payee's transaction frequency. One embodiment of the payment processing method in this specification may include: Obtain transaction time information for multiple historical transactions of the recipient.

[0071] Based on the transaction time information, the time interval between adjacent transactions is determined.

[0072] The first preset duration is determined based on the time interval.

[0073] In one embodiment of this specification, before sending a payment processing request to the server, the terminal first obtains information such as payee information and transaction amount information. The payment processing request sent by the terminal to the server may include time information when the payee information was obtained. Optionally, the transaction time information of the payee's historical transactions may include the time information when the terminal obtained the payee information. Alternatively, the transaction time information of the payee's historical transactions may include the time information when the server obtained the payment processing request containing the payee information.

[0074] As one specific implementation, the transaction time information of the payee's historical transactions may include the time information when the resource transfer process was successfully executed, specifically the time information when the payee received the payment amount.

[0075] Optionally, the multiple historical transactions can be historical transactions within a preset time period prior to receiving the payment processing request. This preset time period can be 3 days, 10 days, 30 days, etc., or can be determined according to actual needs, and is not limited here.

[0076] In practical applications, the time interval between adjacent transactions can be determined based on their transaction time information. For example, the time difference represented by the transaction time information of adjacent transactions can be used to determine the time interval between adjacent transactions.

[0077] In one embodiment of this specification, the average time interval between adjacent transactions can be determined as a first preset duration. Optionally, the minimum time interval between adjacent transactions can be determined as the first preset duration. Alternatively, the maximum time interval between adjacent transactions can be determined as the first preset duration.

[0078] In one specific implementation, the known transaction information may include other payment processing requests. By determining whether other payment processing requests containing the key information exist, the risk of duplicate payments can be assessed. Optionally, a payment processing method according to one embodiment of this specification may further include: Other payment processing requests are cached in the request database. These other payment processing requests include those obtained before the current payment processing request was obtained.

[0079] The step of determining whether the payment processing request carries a risk of duplicate payment based on the key information and known transaction information may include: Based on the key information, it is determined whether a target payment processing request matching the payment processing request exists in the request database. The target payment processing request and the payment processing request have the same payee, payer, and transaction amount, and the difference between the request time of the target payment processing request and the request time of the payment processing request is less than or equal to a second preset duration.

[0080] If a target payment processing request matching the payment processing request exists in the request database, then it is determined that the payment processing request carries the risk of duplicate payment.

[0081] If no target payment processing request matching the payment processing request exists in the request database, then it is determined that the payment processing request does not pose a risk of duplicate payment.

[0082] In one embodiment of this specification, the payment processing request obtained by the server can be stored in a request database. For example, the obtained payment processing request can be stored as soon as the server obtains it. As a specific implementation, the request database may contain other payment processing requests obtained before the obtained payment processing request.

[0083] Optionally, the results database can be a server database. As one specific implementation, the request database can be the same as the aforementioned results database, or it can be a different database.

[0084] In practical applications, the risk of duplicate payment can be determined by checking if a matching target payment request exists in the request database. If a matching request exists, the risk of duplicate payment is confirmed; otherwise, the risk of duplicate payment is not confirmed.

[0085] In one embodiment of this specification, a target payment processing request that matches a payment processing request may refer to a target payment processing request that contains the same payer information, payee information, and transaction amount information as the key information, and whose request time is less than or equal to the request time of the payment processing request, and whose request time is less than or equal to a second preset duration.

[0086] Optionally, the second preset duration can be 0 seconds, 1 second, 3 seconds, 5 seconds, etc., or it can be determined according to actual needs, without any restrictions here.

[0087] Figure 3 This is a flowchart illustrating a payment processing method provided in one embodiment of this specification. Figure 3As shown, suppose a merchant initiates a payment processing request. After receiving the payment processing request, the server can extract key information from it. Then, the server can retrieve historical payment processing requests from the request database. Based on the key information and historical payment processing requests, the server determines whether there is a risk of duplicate payment. If there is a risk of duplicate payment, the server can send a payment reminder message to the payer's terminal. Furthermore, if the user chooses not to continue the payment, the server can terminate the transaction. If the user chooses to continue the payment, the server can process the payment and obtain the payment result. Optionally, the server can also store the payment result in the request database. This method of determining whether duplicate payment occurs through historical payment processing requests can be called a request-based processing method.

[0088] In one embodiment of this specification, if a target payment processing request matching the payment processing request exists in the request database, the payment reminder information includes a notification indicating that the user has already submitted a payment of the same amount. Optionally, a specific payment reminder message could be, "You have already submitted a payment of the same amount to this merchant, and the merchant is receiving the payment result. Please confirm whether you need to pay again."

[0089] As a specific implementation method, to accurately identify whether a payment is duplicated, historical payment result information and historical payment processing requests can be combined to identify whether a payment is duplicated. For example, if the target payment result information does not exist in the result information database, it is further determined whether the target payment processing request exists in the request database. In one embodiment of this specification, if the result information database does not contain target payment result information matching the payment processing request, the method may further include: Based on the aforementioned key information, it is determined whether a target payment processing request matching the payment processing request exists in the request database. The target payment processing request and the payment processing request share the same payee, payer, and transaction amount, and the difference between the request time of the target payment processing request and the request time of the payment processing request is less than or equal to a second preset duration. The request database is used to cache other payment processing requests. These other payment processing requests include those obtained before the payment processing request was obtained.

[0090] If a target payment processing request matching the payment processing request exists in the request database, then it is determined that the payment processing request carries the risk of duplicate payment.

[0091] If no target payment result information matching the payment processing request is found in the result information database, then determining that the payment processing request does not pose a risk of duplicate payment may include: If there is no target payment result information matching the payment processing request in the result information database, and there is no target payment processing request matching the payment processing request in the request database, then it is determined that there is no risk of duplicate payment in the payment processing request.

[0092] As a specific implementation, it can be done by first determining whether a target payment processing request exists in the request database, and then determining whether target payment result information exists in the result information database to identify whether it is a duplicate payment. Optionally, if no target payment processing request matching the payment processing request exists in the request database, then based on the key information, it can be determined whether target payment result information matching the payment processing request exists in the result information database; the target payment result information and the payment processing request target the same payee and payer, and the transaction amount is the same, and the difference between the transaction result time of the target payment result information and the request time of the payment processing request is less than or equal to a first preset duration; If the result information database contains target payment result information that matches the payment processing request, then it is determined that the payment processing request carries the risk of duplicate payment. If the result information database does not contain any target payment result information that matches the payment processing request, then it is determined that the payment processing request does not pose a risk of duplicate payment.

[0093] In practical applications, due to issues with user terminals or merchant equipment, or network latency, although a user may make multiple payments at different times, the server may receive multiple payment processing requests simultaneously. In this case of concurrent payment requests, existing technologies may not alert the user to duplicate payments, leading to the risk of duplicate payments. In one embodiment of this specification, a lock caching mechanism can be used to address the issue of not alerting the user to duplicate payments during concurrent payment requests. The payment processing method in one embodiment of this specification may further include: The request database is a database based on a lock caching storage mechanism. The request database allows payment processing requests with the same transaction amount and the same transacting party to be stored once within a preset time window.

[0094] The step of determining whether a target payment processing request matching the payment processing request exists in the request database based on the key information may include: The payment processing request is stored in the request database.

[0095] Obtain the storage feedback information from the requested database.

[0096] If the storage feedback information indicates successful storage, then it is determined that there is no target payment processing request matching the payment processing request in the request database.

[0097] If the storage feedback information indicates a storage failure or a concurrent lock conflict, then it is determined that a target payment processing request matching the payment processing request exists in the request database.

[0098] Among them, the lock caching storage mechanism is a concurrency control technology that reduces the overhead of accessing shared lock variables in main memory and ensures cache consistency by storing the frequently accessed lock states in the cache.

[0099] In one embodiment of this specification, the request database is a database based on a lock cache storage mechanism, which performs mutually exclusive storage for payment processing requests with the same transaction amount and the same transacting party within a preset time window.

[0100] Optionally, the payment processing request can be stored in a request database based on a lock caching mechanism, and the storage feedback information from the request database can be obtained. This storage feedback information can indicate successful storage, storage failure, or concurrent lock conflict.

[0101] In one specific implementation, the existence of a target payment processing request in the request database can be determined by storing feedback information. Optionally, if the stored feedback information indicates successful storage, it can be determined that no target payment processing request exists. If the stored feedback information indicates storage failure or concurrent lock conflict, it can be determined that a target payment processing request exists.

[0102] As a specific implementation method, the way of determining whether a payment is made repeatedly through a database based on a lock cache storage mechanism can be called a processing method using the concurrent lock mode in the request pattern. In one embodiment of this specification, the payment processing method can be applied to a near-field communication (NFC)-based payment scenario. In this payment scenario, the time taken for the server to obtain the payment processing request is generally within a preset duration. To accurately identify whether it is a duplicate payment, the time taken to obtain the payment processing request can also be used to identify whether it is a duplicate payment. Optionally, the payment processing method may further include: The request time for obtaining the payment processing request. The request time represents the duration from when the transaction is triggered to when the payment processing request is obtained.

[0103] Determine whether the time taken for the request is greater than or equal to a third preset time.

[0104] Sending a payment reminder message to the payer's terminal to prompt whether to continue the transaction may include: If the request takes longer than or equal to a third preset time, a payment reminder message is sent to the payer's terminal to prompt whether to continue the transaction.

[0105] Optionally, in a payment scenario based on near-field communication (NFC) payment, a transaction trigger may refer to the NFC device associated with the merchant reporting a touch event of the payer's terminal, or it may refer to the server sending the payer's payment code to the NFC device associated with the merchant, or it may refer to the NFC device associated with the merchant sending the payer's payment code to the merchant's cashier.

[0106] In one embodiment of this specification, the third preset duration can be determined based on the historical request duration. Optionally, the third preset duration can be determined based on the historical request duration of payment processing requests for the payee. For example, the historical payment processing requests of the payee in the current payment processing request can be obtained, and the third preset duration can be determined based on the historical request duration of the payee's historical processing requests. Specifically, the average historical request duration of the payee's historical processing requests can be used as the third preset duration. As a specific implementation, the third preset duration can also be determined based on the historical request duration of payment processing requests for the payer. For example, the historical processing requests of the payer in the current payment processing request can be obtained, and the third preset duration can be determined based on the historical request duration of the payer's historical processing requests. Specifically, the average historical request duration of the payer's historical processing requests can be used as the third preset duration. In practical applications, the third preset duration can be 3 seconds, 6 seconds, 10 seconds, etc., and can be determined according to actual needs, without limitation here.

[0107] Figure 4 This is a flowchart illustrating a payment processing method provided in one embodiment of this specification. Figure 4 As shown, assume a merchant can initiate a payment processing request. After receiving the request, the server can extract key information from it. Then, the server can retrieve historical payment result information from a result database. Based on the key information and historical payment result information, the server determines whether there is a risk of duplicate payment. If there is a risk of duplicate payment, the server can send a payment reminder to the payer's terminal. Furthermore, if the user chooses not to continue the payment, the server can terminate the transaction. If the user chooses to continue the payment, the server can process the payment, thus obtaining the payment result. Optionally, the server can also store the payment result in a result database. This method of determining whether duplicate payment has occurred based on historical payment result information can be called a success-based processing method. In one embodiment of this specification, based on the above judgment process, the server can also use a method of superimposing request time to determine whether duplicate payment exists. Specifically, the server can obtain the request time of the payment processing request and determine whether the request time is greater than or equal to a third preset time. If the request time is greater than or equal to the third preset time, and the result information database contains target payment result information matching the payment processing request, then it can be determined that there is a risk of duplicate payment; otherwise, it can be determined that there is no risk of duplicate payment. This method of judging by superimposing request time can be called the processing method of using the strict mode in the success mode.

[0108] In one embodiment of this specification, to improve payment security, the user's identity can be verified when the user confirms to continue the payment, and the transaction is processed if the verification is successful. Optionally, the payment processing method may further include: If a confirmation message indicating continued payment is received from the payer's terminal, an identity verification page is sent back to the payer's terminal.

[0109] If the identity verification information provided by the payment terminal based on the identity verification page is obtained, the identity verification information is verified.

[0110] If the verification passes, a resource transfer process is executed for the payment processing request.

[0111] Optionally, the identity verification page is used for the payer to enter identity verification information. In practical applications, various verification methods can be used to verify the payer's identity, such as at least one of password verification, fingerprint verification, facial recognition verification, and iris verification.

[0112] As one specific implementation, different security levels can be set for various verification methods. For example, there can be high-security verification methods and low-security verification methods. Optionally, high-security verification methods can be fingerprint verification, facial recognition verification, and iris verification. Medium-to-low security verification methods can be password verification. Optionally, the corresponding level of security verification method can be adopted based on the payer's risk level. For example, if the payer's risk level is high, a high-security verification method can be used; if the payer's risk level is low, a low-security verification method can be used. As one specific implementation, the payer's risk level can be determined based on the frequency of payment reminder information displayed on the payer's terminal. For example, if the frequency is greater than a preset frequency threshold, the payer's risk level can be determined to be high; conversely, if the frequency is less than a preset threshold, the payer's risk level can be determined to be low. As one specific implementation, the payer's risk level can be determined based on the transaction amount information in the payment processing request. For example, if the transaction amount information indicates an amount greater than a preset amount threshold, the payer's risk level can be determined to be high; conversely, if the transaction amount information indicates an amount less than a preset amount threshold, the payer's risk level can be determined to be low.

[0113] The various technical features in the above embodiments can be combined arbitrarily, as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they have not been described one by one. Therefore, the arbitrary combination of various technical features in the above embodiments is also within the scope of this specification.

[0114] Based on the same idea, this specification also provides a payment processing method applied to the payer's terminal, corresponding to the above-described payment processing method.

[0115] Figure 5 This is a flowchart illustrating a payment processing method provided in one embodiment of this specification. This payment processing method is applied to the payer's terminal. Figure 5 As shown, the method may include the following steps.

[0116] Step 502: Based on the user's payment trigger operation, a payment processing request is sent to the server. The server determines whether the payment processing request poses a risk of duplicate payment. The payment processing request includes payer information, payee information, and transaction amount information.

[0117] In one embodiment of this specification, the user's payment triggering operation can be an electronic payment triggering operation. As a specific implementation, the payment scenario for the user's payment triggering operation can be various. Optionally, the payment scenario can be a scenario of scanning a payment code, a scenario of near-field communication-based payment, or a scenario of placing an order on a trading platform.

[0118] In one embodiment of this specification, the user's payment triggering operation can be the payment triggering operation of the payer. For example, in a scenario of scanning a payment code, the payment triggering operation can be the payer scanning the merchant's payment code. For example, in a near-field communication (NFC) based payment scenario, the payment triggering operation can be the payer touching a terminal with NFC functionality to the merchant's NFC device. For example, in a scenario of placing an order on a trading platform, the payment triggering operation can be the payer purchasing goods on the trading platform and then making payment without a password, by entering a password, or through fingerprint or facial recognition.

[0119] Optionally, the user's payment trigger action can be the payment trigger action of the payee user. For example, in a scenario of scanning a payment code, the payment trigger action could be the payee user scanning the payer user's payment code. Similarly, in a near-field communication (NFC) based payment scenario, the payment trigger action could be the payee user obtaining the payer user's payment code via NFC.

[0120] The payment processing request can be sent to the server by either the payee's terminal or the payer's device. In one specific implementation, the payer's terminal can send a payment processing request to the server based on a payment trigger operation initiated by either the payer or the payee. Alternatively, the payee's terminal can send a payment processing request to the server based on a payment trigger operation initiated by either the payer or the payee.

[0121] Optionally, the payment processing request may include payer information, payee information, and transaction amount information. As one specific implementation, the payment processing request may also include at least one of transaction type information, transaction time information, and transaction identifier information. For details regarding payer information, payee information, transaction amount information, transaction type information, transaction time information, and transaction identifier information, please refer to the preceding description; they will not be repeated here.

[0122] In one implementation of this specification, the server can determine whether a payment processing request carries the risk of duplicate payment. Optionally, the server can extract key information from the payment processing request, including payer information, payee information, and transaction amount information. Based on this key information and known transaction information, the server can determine whether the payment processing request carries the risk of duplicate payment. Known transaction information includes transaction information acquired within a preset time period prior to obtaining the payment processing request. For a detailed explanation of how the server determines whether a payment processing request carries the risk of duplicate payment, please refer to the preceding description; it will not be repeated here.

[0123] Step 504: If the payment processing request carries the risk of duplicate payment, a payment reminder message is displayed to prompt whether to continue the transaction.

[0124] In one embodiment of this specification, if there is a risk of duplicate payment in the payment processing request, the server can send a payment reminder message to the payer terminal to prompt whether to continue the transaction. The payer terminal can receive and display the payment reminder message.

[0125] As one specific implementation, the payer's terminal can pre-store or cache payment reminder information. If there is a risk of duplicate payment in the payment processing request, the server can send a payment reminder information display instruction to the payer's terminal so that the payer's terminal can display the payment reminder information.

[0126] Figure 6 This is a schematic diagram of a notification page for displaying payment reminder information, provided in one embodiment of this specification. If the server determines that there is a risk of duplicate payment in the payment processing request by finding a target payment result information matching the payment processing request in the result information database, the payer's terminal can display, as shown below... Figure 6 The reminder page shown. Figure 6 As shown, the reminder page may include payment reminder information 601. The content of this payment reminder information 601 may specifically be "You have already paid for an order of the same amount at this merchant. Please confirm whether you need to pay again." The reminder page may include a duplicate payment reminder icon 602. The duplicate payment reminder icon 602 can be used to inform the user that this page is a duplicate payment reminder page. The reminder page may include warning information 603. The warning information 603 is used to alert the user to pay attention to the reminder page information. Further, the reminder page may include operation controls 604 for the user to choose to continue the transaction and operation controls 605 for the user to choose not to continue the transaction. The user can confirm to continue the transaction by selecting operation control 604, or confirm not to continue the transaction by selecting operation control 605. Optionally, the reminder page may include a viewing control 606 for the user to view the target payment result information. The user can view the target payment result information matching the payment processing request by selecting viewing control 606.

[0127] Figure 7 This is a schematic diagram of a notification page for displaying payment reminder information, provided in one embodiment of this specification. If the server determines that there is a risk of duplicate payment in the payment processing request by determining that a target payment processing request matching the payment processing request exists in the request database, the payer's terminal can display, as shown below... Figure 7 The reminder page shown. Figure 7As shown, the reminder page may include a payment reminder 701. The content of this payment reminder 701 may specifically be, "You have already submitted a payment of the same amount to this merchant. The merchant is receiving the payment result. Please confirm whether you need to pay again." Optionally, the reminder page may also include a duplicate payment reminder icon 702, a warning message 703, an operation control 704 for the user to choose to continue the transaction, and an operation control 705 for the user to choose not to continue the transaction. For details regarding the duplicate payment reminder icon 702, warning message 703, operation control 704 for the user to choose to continue the transaction, and operation control 705 for the user to choose not to continue the transaction, please refer to the previous descriptions of the duplicate payment reminder icon 602, warning message 603, operation control 604 for the user to choose to continue the transaction, and operation control 605 for the user to choose not to continue the transaction; these details will not be repeated here.

[0128] In one specific implementation, if there is no risk of duplicate payment in the payment processing request, the server may not send payment reminder information to the payer's terminal, and the terminal may not need to display payment reminder information. The server can execute a resource transfer process based on the payment processing request.

[0129] In practical applications, the payer can choose to continue the transaction or not, based on the payment notification information. To improve payment security, when the payer chooses to continue, identity verification can be performed, and the transaction is executed only after successful verification. Optionally, the payment processing method may also include: If the system receives a first action from the user based on the payment reminder information indicating that the transaction should continue, then the identity verification page will be displayed.

[0130] In one embodiment of this specification, the payment reminder information may include operation controls for the user to confirm continuing the transaction. Optionally, the user can confirm continuing the payment by selecting a first operation of the operation controls to continue the transaction.

[0131] In one embodiment of this specification, the identity verification page is used by the payer to input identity verification information. The payer can enter identity verification information on the identity verification page for verification. Specific verification methods are described above and will not be repeated here.

[0132] Optionally, upon successful verification, the payer terminal can send a verification success message to the server, allowing the server to execute a resource transfer process. As a specific implementation, upon failed verification, the payer terminal can send a payment termination message to the server, causing the server to terminate processing the payment request.

[0133] In one embodiment of this specification, if a second operation indicating that the user will not continue the transaction is obtained based on the payment reminder information, a message indicating payment termination is sent to the server so that the server terminates the processing of the payment processing request.

[0134] In one specific implementation, the payment reminder message may include a control for the user to confirm that they will not continue the transaction. The user can confirm that they will not continue the payment by selecting the second action of the control.

[0135] In practical applications, to avoid disturbing users, the reminder page displaying the notification information can be closed and the previous page displayed when the user decides not to continue the transaction. The payment processing method in one embodiment of this specification may further include: If a second action indicating that the user will not continue the transaction is obtained based on the payment reminder information, then the reminder page used to display the payment reminder information is closed.

[0136] Display the initial page. The initial page is the page displayed on the payer's terminal before the notification page is displayed.

[0137] In one embodiment of this specification, the initial page may be the page displayed on the payer's terminal before the notification page is displayed. As a specific implementation, the initial page may be a page indicating payment processing. For example, the initial page may be a page indicating that payment processing is in progress.

[0138] In one specific implementation, after closing the notification page, a page indicating the payment result can also be displayed. This payment result can be the payment result of a previous transaction. Optionally, the page indicating the payment result can be a page indicating successful payment or a page indicating payment failure.

[0139] The various technical features in the above embodiments can be combined arbitrarily, as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they have not been described one by one. Therefore, the arbitrary combination of various technical features in the above embodiments is also within the scope of this specification.

[0140] Figure 8 This is a flowchart of a payment processing method provided in one embodiment of this specification, such as... Figure 8 As shown, a payment processing method according to an embodiment of this specification may include the following steps.

[0141] In one embodiment of this specification, a terminal can initiate a payment processing request to a server. Upon receiving the payment processing request, the server can extract key information and then query the result information database to see if there is any target payment processing result information matching the key information. If target payment result information exists, the server can send a payment reminder message to the paying terminal, prompting whether to continue the transaction. The paying terminal then displays the payment reminder message. In practical applications, the paying user can choose to continue the payment or not. Optionally, if the server receives a message from the paying terminal indicating that the user does not want to continue the payment, it can terminate the processing of the payment processing request. If the server receives a message from the paying terminal indicating that the user wants to continue the payment, it can execute a resource transfer process.

[0142] As one specific implementation, if the target payment processing result information is not found in the result information database, the server can also query the request database to see if a target payment processing request matching the key information exists. If a target payment processing request exists, the subsequent process of sending payment reminder information can be executed. If no target payment processing request exists, the resource transfer process can be executed.

[0143] In one embodiment of this specification, a success mode, a request mode, a lenient mode, and a strict mode are set to meet the payment security requirements of various complex scenarios. This not only improves the accuracy of duplicate payment reminders and reduces disturbance to users, but also improves payment processing efficiency.

[0144] Based on the same idea, this specification also provides a payment processing apparatus corresponding to the above-described payment processing method.

[0145] Figure 9 This is a schematic diagram of a payment processing device according to an embodiment of this specification, which can be used as a server. Figure 9 As shown, the payment processing apparatus may include: The request retrieval module 902 is used to retrieve payment processing requests.

[0146] The information extraction module 904 is used to extract key information from the payment processing request; the key information includes payer information, payee information, and transaction amount information.

[0147] The risk assessment module 906 is used to determine, based on the key information and known transaction information, whether the payment processing request carries the risk of duplicate payment. The known transaction information includes transaction information acquired within a preset time period prior to obtaining the payment processing request.

[0148] The sending module 908 is used to send a payment reminder message to the payer's terminal to prompt whether to continue the transaction if there is a risk of duplicate payment.

[0149] Optionally, the payment processing device may also include: The resource transfer module is used to execute a resource transfer process based on the payment processing request if there is no risk of duplicate payment.

[0150] Optionally, the payment processing device may also include: The result information caching module is used to cache the payment result information corresponding to any payment processing request to the result information database if any payment processing request is successfully processed.

[0151] Risk assessment module 906 may specifically include: Based on the key information, it is determined whether there is target payment result information in the result information database that matches the payment processing request. The target payment result information and the payment processing request are for the same payee and payer, and the transaction amount is the same. Furthermore, the difference between the transaction result time of the target payment result information and the request time of the payment processing request is less than or equal to a first preset duration.

[0152] If the result information database contains target payment result information that matches the payment processing request, then it is determined that the payment processing request carries the risk of duplicate payment.

[0153] If the result information database does not contain any target payment result information that matches the payment processing request, then it is determined that the payment processing request does not pose a risk of duplicate payment.

[0154] Optionally, the payment processing device may also include: The request caching module is used to cache other payment processing requests to the request database. These other payment processing requests include those obtained before the current payment processing request was obtained.

[0155] Risk assessment module 906 may specifically include: Based on the key information, it is determined whether a target payment processing request matching the payment processing request exists in the request database. The target payment processing request and the payment processing request have the same payee, payer, and transaction amount, and the difference between the request time of the target payment processing request and the request time of the payment processing request is less than or equal to a second preset duration.

[0156] If a target payment processing request matching the payment processing request exists in the request database, then it is determined that the payment processing request carries the risk of duplicate payment.

[0157] If no target payment processing request matching the payment processing request exists in the request database, then it is determined that the payment processing request does not pose a risk of duplicate payment.

[0158] Optionally, if the result information database does not contain target payment result information matching the payment processing request, the payment processing device may further include: The payment processing request determination module is used to determine, based on the key information, whether a target payment processing request matching the payment processing request exists in the request database. The target payment processing request and the payment processing request have the same payee, payer, and transaction amount, and the difference between the request time of the target payment processing request and the request time of the payment processing request is less than or equal to a second preset duration. The request database is a database used to cache other payment processing requests. These other payment processing requests include those obtained before the payment processing request was obtained. The risk assessment module 906 can also be used to determine that the payment processing request has the risk of duplicate payment if there is a target payment processing request in the request database that matches the payment processing request.

[0159] If no target payment result information matching the payment processing request is found in the result information database, then determining that the payment processing request does not pose a risk of duplicate payment may include: If there is no target payment result information matching the payment processing request in the result information database, and there is no target payment processing request matching the payment processing request in the request database, then it is determined that there is no risk of duplicate payment in the payment processing request.

[0160] Optionally, the payment processing device may also include: The request database is a database based on a lock cache storage mechanism; the request database allows one entry within a preset time window for payment processing requests with the same transaction amount and the same transacting party; The step of determining whether a target payment processing request matching the payment processing request exists in the request database based on the key information may include: The payment processing request is stored in the request database.

[0161] Obtain the storage feedback information from the requested database.

[0162] If the storage feedback information indicates successful storage, then it is determined that there is no target payment processing request matching the payment processing request in the request database.

[0163] If the storage feedback information indicates a storage failure or a concurrent lock conflict, then it is determined that a target payment processing request matching the payment processing request exists in the request database.

[0164] Optionally, the payment processing device may also include: The request time acquisition module is used to acquire the request time of the payment processing request; the request time represents the duration from the triggering of the transaction to the acquisition of the payment processing request; The duration determination module is used to determine whether the request duration is greater than or equal to a third preset duration; The sending module 908 can be used specifically for: If the request takes longer than or equal to a third preset time, a payment reminder message is sent to the payer's terminal to prompt whether to continue the transaction.

[0165] Optionally, the payment processing device may also include: The time information acquisition module is used to acquire the transaction time information of multiple historical transactions of the payee; The time interval determination module is used to determine the time interval between adjacent transactions based on the transaction time information. The first preset time determination module is used to determine the first preset duration based on the time interval.

[0166] Optionally, the payment processing device may also include: The page feedback module is used to send an identity verification page to the payer terminal if it receives a confirmation message from the payer terminal indicating that payment should continue.

[0167] The verification module is used to verify the identity verification information if it obtains the identity verification information provided by the payment terminal based on the identity verification page.

[0168] The process execution module is used to execute a resource transfer process for the payment processing request if the verification passes.

[0169] Optionally, if the result information database contains target payment result information that matches the payment processing request, the payment reminder information includes a prompt indicating that the user has already paid the same amount.

[0170] Optionally, if a target payment processing request matching the payment processing request exists in the request database, the payment reminder information includes a prompt indicating that the user has already submitted a payment of the same amount.

[0171] The various technical features in the above embodiments can be combined arbitrarily, as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they have not been described one by one. Therefore, the arbitrary combination of various technical features in the above embodiments is also within the scope of this specification.

[0172] Based on the same idea, this specification also provides a payment processing apparatus corresponding to the above-described payment processing method.

[0173] Figure 10 This is a schematic diagram of a payment processing device according to an embodiment of this specification, which can be used as a server. Figure 10 As shown, the payment processing apparatus may include: The request sending module 1002 is used to send a payment processing request to the server based on the user's payment trigger operation. The server determines whether the payment processing request has the risk of duplicate payment. The payment processing request includes payer information, payee information, and transaction amount information.

[0174] The information display module 1004 is used to display payment reminder information to prompt whether to continue the transaction if there is a risk of duplicate payment in the payment processing request.

[0175] Optionally, the payment processing device may also include: The page display module is used to display the identity verification page if it receives a first operation from the user based on the payment reminder information indicating that the transaction should continue.

[0176] Optionally, the payment processing device may also include: The information sending module is used to send a payment termination message to the server if it receives a second operation from the user based on the payment reminder information indicating that the transaction will not continue, so that the server will terminate the processing of the payment processing request.

[0177] Optionally, the payment processing device may also include: The page closing module is used to close the reminder page that displays the payment reminder information if it receives a second operation from the user based on the payment reminder information indicating that the transaction will not continue.

[0178] An initial page display module is used to display an initial page. The initial page is the page displayed on the payer's terminal before the reminder page is displayed.

[0179] The various technical features in the above embodiments can be combined arbitrarily, as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they have not been described one by one. Therefore, the arbitrary combination of various technical features in the above embodiments is also within the scope of this specification.

[0180] Based on the same idea, this specification also provides devices corresponding to the above methods in its embodiments.

[0181] Figure 11 A structural block diagram of a computing device 1100 provided according to an embodiment of this specification is shown.

[0182] The computing device 1100 includes: Memory 1110 and processor 1120; The memory 1110 is used to store computer programs / instructions, and the processor 1120 is used to execute the computer programs / instructions, which implement the steps of the above method when executed by the processor 1120.

[0183] Specifically, the components of the computing device 1100 include, but are not limited to, a memory 1110 and a processor 1120. The processor 1120 is connected to the memory 1110 via a bus 1130, and the database 1150 is used to store data.

[0184] The computing device 1100 also includes an access device 1140, which enables the computing device 1100 to communicate via one or more networks 1160. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 1140 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0185] In one embodiment of this specification, the above-described components of the computing device 1100 and Figure 11 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 11 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can add or replace other components as needed.

[0186] The computing device 1100 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 1100 can also be a mobile or stationary server.

[0187] The processor 1120 implements the steps of the above method when executing the computer instructions.

[0188] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the payment processing method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the method described above.

[0189] An embodiment of this specification also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of the above-described method.

[0190] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the payment processing method belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the above method.

[0191] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0192] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the payment processing method belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the above method.

[0193] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the apparatus and device embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The apparatus, device and method provided in the embodiments of this specification are corresponding to each other, and therefore the apparatus and device also have similar beneficial technical effects as the corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the corresponding apparatus and device will not be repeated here.

[0194] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0195] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0196] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0197] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0198] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0199] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, the invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0200] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0201] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0202] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0203] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0204] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0205] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital character versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0206] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0207] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A payment processing method, applied to a server, comprising: Get the payment processing request; Extract the key information from the payment processing request; The key information includes payer information, payee information, and transaction amount information; Based on the key information and known transaction information, it is determined whether the payment processing request carries the risk of duplicate payment; the known transaction information includes transaction information acquired within a preset time period prior to acquiring the payment processing request; If there is a risk of duplicate payment, a payment reminder message will be sent to the payer's terminal to prompt whether to continue the transaction.

2. The method of claim 1, further comprising: If there is no risk of duplicate payment, then a resource transfer process is executed based on the payment processing request.

3. The method of claim 1, further comprising: If any payment processing request is successfully processed, the payment result information corresponding to the arbitrary payment processing request is cached in the result information database; The step of determining whether the payment processing request carries the risk of duplicate payment based on the key information and known transaction information includes: Based on the key information, it is determined whether there is target payment result information in the result information database that matches the payment processing request; the target payment result information and the payment processing request are for the same payee and payer, and the transaction amount is the same, and the difference between the transaction result time of the target payment result information and the request time of the payment processing request is less than or equal to a first preset duration. If the result information database contains target payment result information that matches the payment processing request, then it is determined that the payment processing request carries the risk of duplicate payment. If the result information database does not contain any target payment result information that matches the payment processing request, then it is determined that the payment processing request does not pose a risk of duplicate payment.

4. The method of claim 1, further comprising: Cache other payment processing requests to the request database; The other payment processing requests include payment processing requests obtained before the payment processing request was obtained; The step of determining whether the payment processing request carries the risk of duplicate payment based on the key information and known transaction information includes: Based on the key information, it is determined whether there is a target payment processing request in the request database that matches the payment processing request; the target payment processing request and the payment processing request have the same payee, payer and transaction amount, and the difference between the request time of the target payment processing request and the request time of the payment processing request is less than or equal to a second preset duration. If a target payment processing request matching the payment processing request exists in the request database, then it is determined that the payment processing request carries the risk of duplicate payment. If no target payment processing request matching the payment processing request exists in the request database, then it is determined that the payment processing request does not pose a risk of duplicate payment.

5. The method of claim 3, further comprising: If the result information database does not contain target payment result information matching the payment processing request, the method further includes: Based on the key information, it is determined whether there is a target payment processing request in the request database that matches the payment processing request; the target payment processing request and the payment processing request have the same payee, payer, and transaction amount, and the difference between the request time of the target payment processing request and the request time of the payment processing request is less than or equal to a second preset duration; the request database is a database used to cache other payment processing requests; the other payment processing requests include payment processing requests obtained before the payment processing request was obtained; If a target payment processing request matching the payment processing request exists in the request database, then it is determined that the payment processing request carries the risk of duplicate payment. If no target payment result information matching the payment processing request is found in the result information database, then determining that the payment processing request does not pose a risk of duplicate payment includes: If there is no target payment result information matching the payment processing request in the result information database, and there is no target payment processing request matching the payment processing request in the request database, then it is determined that there is no risk of duplicate payment in the payment processing request.

6. The method of claim 4 or 5, further comprising: The requested database is a database based on a lock cache storage mechanism; The request database allows one entry per preset time window for payment processing requests with the same transaction amount and the same transacting party. The step of determining whether a target payment processing request matching the payment processing request exists in the request database based on the key information includes: The payment processing request is stored in the request database; Obtain the storage feedback information from the requested database; If the storage feedback information indicates successful storage, then it is determined that there is no target payment processing request matching the payment processing request in the request database. If the storage feedback information indicates a storage failure or a concurrent lock conflict, then it is determined that a target payment processing request matching the payment processing request exists in the request database.

7. The method of claim 1, further comprising: Obtain the request time for the payment processing request; The request time represents the time between the triggering of a transaction and the receipt of the payment processing request. Determine whether the request time is greater than or equal to a third preset time. Sending a payment reminder message to the payer's terminal to prompt whether to continue the transaction includes: If the request takes longer than or equal to a third preset time, a payment reminder message is sent to the payer's terminal to prompt whether to continue the transaction.

8. The method of claim 3, further comprising: Obtain transaction time information for multiple historical transactions of the payee; Based on the transaction time information, the time interval between adjacent transactions is determined; The first preset duration is determined based on the time interval.

9. The method according to any one of claims 1 to 5 and 7 to 8, further comprising: If a confirmation message indicating continued payment is received from the payer's terminal, an identity verification page is sent back to the payer's terminal. If the identity verification information provided by the payment terminal based on the identity verification page is obtained, then the identity verification information is verified. If the verification passes, a resource transfer process is executed for the payment processing request.

10. The method as described in claim 3, wherein if the result information database contains target payment result information that matches the payment processing request, the payment reminder information includes a prompt indicating that the user has already paid the same amount.

11. The method as described in claim 4, wherein if a target payment processing request matching the payment processing request exists in the request database, the payment reminder information includes a prompt indicating that the user has already submitted a payment of the same amount.

12. A payment processing method applied to a payer terminal, comprising: Based on the user's payment trigger operation, a payment processing request is sent to the server, and the server determines whether the payment processing request poses a risk of duplicate payment; The payment processing request includes payer information, payee information, and transaction amount information; If the payment processing request carries the risk of duplicate payment, a payment reminder message will be displayed to prompt whether to continue the transaction.

13. The method of claim 12, further comprising: If the system receives a first action from the user based on the payment reminder information indicating that the transaction should continue, then the identity verification page will be displayed.

14. The method of claim 12, further comprising: If a second operation indicating that the user will not continue the transaction is obtained based on the payment reminder information, then a message indicating payment termination is sent to the server so that the server terminates the processing of the payment processing request.

15. The method of claim 12, further comprising: If a second action indicating that the user will not continue the transaction is obtained based on the payment reminder information, then the reminder page used to display the payment reminder information is closed; Display the initial page; the initial page is the page displayed on the payer's terminal before the reminder page is displayed.

16. A payment processing apparatus, comprising: The request retrieval module is used to retrieve payment processing requests; The information extraction module is used to extract key information from the payment processing request; The key information includes payer information, payee information, and transaction amount information; The risk assessment module is used to determine whether the payment processing request carries the risk of duplicate payment based on the key information and known transaction information; the known transaction information includes transaction information acquired within a preset time period prior to acquiring the payment processing request; The sending module is used to send a payment reminder message to the payer's terminal, prompting them whether to continue the transaction, if there is a risk of duplicate payment.

17. A payment processing apparatus, comprising: The request sending module is used to send a payment processing request to the server based on the user's payment trigger operation. The server determines whether the payment processing request has the risk of duplicate payment. The payment processing request includes payer information, payee information, and transaction amount information. The information display module is used to display payment reminder information to prompt whether to continue the transaction if there is a risk of duplicate payment in the payment processing request.

18. A computing device, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 15.

19. A computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 15.

20. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 15.

Images