Electronic payment processing method and apparatus, electronic device, and computer-readable storage medium

Abstract

The application provides an electronic payment processing method and device, electronic equipment and computer readable storage medium; the method comprises the following steps: a first collection terminal scans a user terminal which needs to perform electronic payment to obtain identity information of the user terminal; a transaction corresponding to the identity information is generated; at least one second collection terminal capable of communicating with the first collection terminal is detected, and the transaction is risk checked in cooperation with the at least one second collection terminal; when the risk check is passed, a completed state of the transaction is presented, and an order corresponding to the transaction is sent to a charging system in a network, so that the charging system performs a recovery operation on the receivables of the order. Through the application, the user transaction efficiency can be improved, and the risk of bad debts of merchants caused by offline overdraft can be reduced.

Description

Technical Field

[0001] This invention relates to electronic payment technology, and more particularly to an electronic payment processing method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] With the rapid development of mobile internet, mobile electronic payment is becoming increasingly common. Point-of-sale (POS) terminals are increasingly popular for users to scan codes to complete electronic payments.

[0003] However, in related technologies, electronic payment relies on POS machines connecting to the network to deduct fees in the background. In special scenarios such as network interruptions, network delays, and limited network access (e.g., confidential scenarios), there are considerable limitations because waiting for network scanning and identification can cause users to wait too long, which detracts from the user's consumption experience. For the above scenarios, related technologies also provide offline electronic payment solutions, but these have potential security risks in terms of transactions. Summary of the Invention

[0004] This invention provides an electronic payment processing method, apparatus, electronic device, and computer-readable storage medium, which enables efficient and secure electronic payments under diverse network conditions.

[0005] The technical solution of this invention is implemented as follows: This invention provides a method for processing electronic payments, including: The first payment terminal scans the user terminal that needs to make an electronic payment to obtain the identity information of the user terminal. Generate a transaction corresponding to the aforementioned identity information; The system detects at least one second payment terminal that can communicate with the first payment terminal, and collaborates with at least one second payment terminal to perform risk verification on the transaction. When the risk verification is passed, the transaction will be displayed as completed. Send an order corresponding to the transaction to the billing system in the network so that the billing system can perform a collection operation for the receivables of the order.

[0006] This invention provides an electronic payment processing device, comprising: The identity information acquisition module is used by the first payment terminal to scan the user terminal that needs to make electronic payment in order to obtain the identity information of the user terminal. The transaction generation module is used to generate transactions corresponding to the identity information. The risk verification module is used to detect at least one second payment terminal that can communicate with the first payment terminal, and to cooperate with at least one second payment terminal to perform risk verification on the transaction. The transaction completion module is used to display the completed status of the transaction when the risk verification passes, and Send an order corresponding to the transaction to the billing system in the network so that the billing system can perform a collection operation for the receivables of the order.

[0007] In the above scheme, the identity information acquisition module is further used for: The first payment terminal scans the identity code displayed on the user terminal that needs to make an electronic payment, and verifies the identity code by signing it. When the signature verification is successful, the identity code is decoded to obtain the identity information of the user terminal; When the identity information is found in the user identity database, it is determined that the identity information has passed the identity verification.

[0008] In the above scheme, the risk verification module is further used for: The transaction is synchronized to at least one of the second payment terminals so that the second payment terminals can perform risk verification on the transaction; The system receives the verification result returned by the second payment terminal and performs risk verification on the transaction again based on the verification result.

[0009] In the above scheme, the risk verification module is further used for: Based on the identity information, query the user terminal's historical orders made through the second payment terminal, and use these as the second payment terminal's historical orders; When both the transaction and the historical orders of the second payment terminal meet the risk control strategy configured on the second payment terminal, the transaction is determined to have passed the risk verification of the second payment terminal, and The verification result from the second payment terminal is returned to the first payment terminal. The system displays the risk verification pass flag for the second payment terminal, as well as the historical orders of the second payment terminal.

[0010] In the above scheme, the risk verification module is further used for: Extract the historical orders of the second payment terminal from the verification result of the second payment terminal; Based on the identity information, query the user terminal's historical orders made through the first payment terminal, and use them as the first payment terminal's historical orders; The transactions, the historical orders of the first payment terminal, and the historical orders of the second payment terminal are aggregated and processed. When the aggregated results satisfy the risk control strategy configured in the first payment terminal, the transaction is determined to have passed the risk verification of the first payment terminal.

[0011] In the above scheme, the risk verification module is further used for: The transaction is synchronized to at least one of the second payment terminals, so that the second payment terminals can query the historical orders of the user terminal made through the second payment terminal based on the identity information, and use them as the historical orders of the second payment terminal; Receive the historical orders returned by the second payment terminal, and perform risk verification on the transaction again based on the historical orders of the second payment terminal.

[0012] In the above scheme, the transaction generation module is further configured to: Receive transaction information corresponding to the identity information, and combine the identity information and the transaction information into a transaction corresponding to the identity information; The risk verification module is also used for: When it is determined that the transaction has passed the risk verification of the first payment terminal, the transaction is shown to be in a risk verification passed state, and a manual confirmation interface is displayed; When a manual confirmation message indicating that the risk verification has passed is received in the manual confirmation interface, an order corresponding to the transaction is created.

[0013] In the above scheme, the risk verification module is further used for: Send probe information within the local area network to which the first payment terminal belongs, so that at least one second payment terminal within the local area network can perform device verification based on the probe information; When the verification pass information returned by the second payment terminal is received, it is determined that the first payment terminal can perform collaborative risk verification of the transaction with the second payment terminal, and The first payment terminal is shown to be in a collaborative verification state.

[0014] In the above scheme, the risk verification module is further used for: When one of the following conditions is met, it is determined that the first payment terminal will independently perform risk verification on the transaction, and the first payment terminal will be in an independent verification state: The first payment terminal did not receive the verification pass information returned by the second payment terminal within the timeout threshold; The first payment terminal receives a verification failure message returned by the second payment terminal.

[0015] In the above scheme, the risk verification module is further used for: Send probe information to the routing device within the local area network to which the first payment terminal belongs, so that... The routing device queries at least one second payment terminal that has a collaborative relationship with the first payment terminal, and returns the query result to the first payment terminal; When the first payment terminal receives the query result, it determines that the first payment terminal can perform collaborative risk verification of the transaction with the second payment terminal, and The first payment terminal is shown to be in a collaborative verification state.

[0016] In the above scheme, the risk verification module is further used for: When one of the following conditions is met, it is determined that the first payment terminal will independently perform risk verification on the transaction, and the first payment terminal will be in an independent verification state: The first payment terminal did not receive the query result returned by the routing device within the timeout threshold; The first payment terminal receives a query result returned by the routing device that contains no content.

[0017] In the above scheme, the risk verification module is further used for: The first payment terminal sends a heartbeat instruction to the billing system, so that the billing system will synchronize the risk control policy configured in the billing system to the first payment terminal and at least one second payment terminal. Receive the risk control strategy and compare it with the existing risk control strategy in the first payment terminal; When the received risk control strategy is inconsistent with the existing risk control strategy, the existing risk control strategy is updated to the received risk control strategy, and the updated status of the risk control strategy is displayed.

[0018] This invention provides a method for processing electronic payments, including: The first payment terminal scans the identity information presented by the user terminal that needs to make an electronic payment, so as to generate a transaction corresponding to the identity information; The first payment terminal displays at least one second payment terminal that has been detected and is capable of communicating with the first payment terminal; Displays the results of risk verification of the transaction in collaboration with the at least one second payment terminal; When the risk verification is passed, the completed status of the transaction and the corresponding order created by the exchange are displayed. The order is sent to the billing system in the network, and a message is displayed showing that the billing system has successfully recovered the receivables for the order.

[0019] This invention provides an electronic payment processing device, comprising: The identity information acquisition module is used by the first payment terminal to scan the identity information presented by the user terminal that needs to make electronic payments, so as to generate a transaction corresponding to the identity information; The risk verification module is used by the first payment terminal to display at least one second payment terminal that has been detected and can communicate with the first payment terminal; to display the result of risk verification of the transaction in collaboration with the at least one second payment terminal; and to present the completed status of the transaction and the corresponding order created by the transaction when the risk verification is passed. The transaction completion module is used to send the order to the billing system in the network and display a message from the billing system indicating that the receivables for the order have been successfully recovered.

[0020] This invention provides an electronic device, comprising: Memory, used to store executable instructions; The processor, when executing executable instructions stored in the memory, implements the electronic payment processing method provided in the embodiments of the present invention.

[0021] This invention provides a computer-readable storage medium storing executable instructions for inducing a processor to execute and implement the electronic payment processing method provided in this invention.

[0022] The embodiments of the present invention have the following beneficial effects: By using multiple payment terminals to collaboratively verify the risk of user spending requests, and responding to the user's spending request after the collaborative risk verification is passed, the transaction completion status is displayed on the payment terminal, and asynchronous collection operations are performed, thereby reducing the user's waiting time and lowering the risk of bad debts caused by offline overdrafts. Attached Figure Description

[0023] Figure 1 This is an optional structural diagram of the electronic payment processing system provided in an embodiment of the present invention; Figure 2 This is an optional structural schematic diagram of the electronic payment processing device provided in an embodiment of the present invention; Figures 3A-3D This is an optional flowchart illustrating the electronic payment processing method provided in an embodiment of the present invention; Figure 4 This is an optional blockchain architecture diagram of the online payment order processing system provided in this embodiment of the invention; Figure 5 This is a diagram of the deployment architecture of the payment terminal in the electronic payment processing method provided in this embodiment of the invention; Figure 6 This is a flowchart of the identity code generation process in the electronic payment processing method provided in this embodiment of the invention; Figure 7 This is a flowchart of the overall payment process of a POS machine in the electronic payment processing method provided in this embodiment of the invention; Figure 8 This is a schematic diagram of the payment process of a single POS machine for the electronic payment processing method provided in this embodiment of the invention; Figure 9 This is a flowchart of the POS machine group verification process in the electronic payment processing method provided in this embodiment of the invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this invention. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0025] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0026] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of the invention described herein can be implemented in an order other than that illustrated or described herein.

[0027] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein is for the purpose of describing embodiments of the invention only and is not intended to limit the invention.

[0028] Before providing a further detailed description of the embodiments of the present invention, the nouns and terms involved in the embodiments of the present invention will be explained, and the nouns and terms involved in the embodiments of the present invention shall be interpreted as follows.

[0029] 1) Payment terminal: A device that settles orders over a network, such as a point-of-sale (POS) machine. It receives orders from user terminals and settles them with the settlement party (such as the user's contracted bank or third-party payment platform) via network communication. For example, it transfers funds from the payment account to the payee's (bank or third-party payment platform) collection account through the settlement party.

[0030] 2) Local Area Network (LAN): refers to the LAN formed by the local POS machine when it cannot connect to the external network.

[0031] 3) Device Identifier: A unique identifier used to identify devices within a local area network.

[0032] 4) Offline scenario: refers to a scenario where the device cannot connect to the public network or is in an environment without a public network.

[0033] 5) Dual offline scenario: This refers to a scenario where the user terminal cannot connect to the public network, and the merchant's POS machine also cannot connect to the public network.

[0034] 6) Identification code: In this article, it refers to the QR code used to identify the user's identity.

[0035] With the rapid development of mobile internet, point-of-sale (POS) payment via QR code is becoming increasingly common. However, most QR code payment scenarios rely on the POS machine connecting to the internet for identification before deducting payment in the background. In certain scenarios, such as cafeterias and parking garages, the large number of customers can easily cause network congestion, and the geographical environment of parking garages can also lead to network congestion. Therefore, relying on a strong network connection for scanning and identification in these unstable network environments can result in excessively long waiting times for users, negatively impacting their experience and increasing the waiting time for other users. In related technologies, online verification by the POS machine requires a strong internet connection, while offline verification does not. However, this does not guarantee transaction security, as risk control strategies across different POS machines cannot be synchronized.

[0036] This invention provides an electronic payment processing method, apparatus, electronic device, and computer-readable storage medium, which can solve the problem of bad debt risk in offline scenarios. The following describes exemplary applications of the electronic device provided in this invention. The electronic device can be implemented as a POS machine, a payment gate, or other types of payment terminal. These payment terminals can be installed in canteens, supermarkets, shopping malls, farmers' markets, utility bill payment counters, vehicles, etc. Exemplary applications when the device is implemented as a terminal will be described below.

[0037] See Figure 1 , Figure 1 This is an optional structural diagram of the electronic payment processing system 100 provided in an embodiment of the present invention. The receiving terminal 400 (terminals 400-1, 400-2 and 400-3 are shown as examples) is connected to the server 200 through the network 300. The user terminal 500 is connected to the server 200 and the receiving terminal 400 through the network 300. The network 300 can be a wide area network or a local area network, or a combination of both.

[0038] User terminal 500 displays a QR code identifying the user. Payment terminal 400-2 scans the QR code displayed on application 510 within user terminal 500. Payment terminal 400-2 decodes the QR code and performs identity verification. Simultaneously, payment terminal 400-2 receives transaction request information, combines the transaction request information with the user's identity information to generate a transaction, and then performs risk verification on the transaction. This risk verification process can involve multiple payment terminals 400-1, 400-2, and 400-3 collaboratively verifying the transaction's risk. After the risk verification is passed, the processes involved in the risk verification... All intermediate and result information can be displayed on the application 410-2 of the payment terminal 400-2. The payment terminal 400-2 creates an order. At this time, the transaction between the payment terminal 400-2 and the user terminal 500 is displayed as completed. The payment terminal 400-2 sends the created order to the billing system in the server 200 so that the billing system can settle the order with the settlement party (such as the bank or third-party payment platform that the user has signed up with). For example, the funds in the payment account are transferred to the payment account of the payee (bank or third-party payment platform) through the settlement party.

[0039] See Figure 2 , Figure 2 This is a schematic diagram of the structure of the payment terminal 400 of the electronic payment processing method provided in this embodiment of the invention. Figure 2 The payment terminal 400 shown includes at least one processor 410, a memory 450, at least one network interface 420, and a user interface 430. The various components in the payment terminal 400 are coupled together via a bus system 440. It is understood that the bus system 440 is used to implement communication between these components. In addition to a data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2 The general labeled all buses as Bus System 440.

[0040] Processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0041] User interface 430 includes one or more output devices 431 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0042] The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 450 may optionally include one or more storage devices physically located away from the processor 410.

[0043] The memory 450 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 450 described in this embodiment is intended to include any suitable type of memory.

[0044] In some embodiments, memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0045] Operating system 451 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks; The network communication module 452 is used to reach other computing devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc. Presentation module 453 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 431 associated with user interface 430 (e.g., a display screen, a speaker, etc.). The input processing module 454 is used to detect and translate one or more user inputs or interactions from one or more input devices 432. In some embodiments, the electronic payment processing apparatus provided in this invention can be implemented in software. Figure 2 An electronic payment processing device 455 stored in memory 450 is shown. It can be software in the form of programs and plug-ins, including the following software modules: identity information acquisition module 4551, transaction generation module 4552, risk verification module 4553, and transaction completion module 4554. These modules are logical and can therefore be arbitrarily combined or further divided according to the functions they implement. The functions of each module will be described below.

[0046] In other embodiments, the electronic payment processing apparatus provided in this invention can be implemented in hardware. As an example, the electronic payment processing apparatus provided in this invention can be a processor in the form of a hardware decoding processor, which is programmed to execute the electronic payment processing method provided in this invention. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0047] The electronic payment processing method provided by the embodiments of the present invention will be described in conjunction with exemplary applications and implementations of the terminals provided in the embodiments of the present invention.

[0048] See Figure 3A , Figure 3A This is an optional flowchart illustrating an electronic payment processing method provided in an embodiment of the present invention, which will be combined with... Figure 3A The steps shown are explained.

[0049] In each processing stage, the working status of each payment terminal, the various results generated by the query, and the information will be displayed on each second payment terminal and the first payment terminal that needs to create an order. The first and second payment terminals involved in this application can be POS machines.

[0050] In step 101, the first payment terminal scans the user terminal that needs to make an electronic payment to obtain the user terminal's identity information.

[0051] The user terminal displays the user's identity code. There are two methods for generating the identity code: online generation and offline generation. First, the mini-program or other application on the user terminal initializes the system. The online code generation process is as follows: the user's identity information is encrypted in the background using a time-sensitive key and then sent to the client. A user password is also sent to the client. The client caches this encrypted identity information (level 1 code) for offline use. The components of the identity information are jointly determined by the backend and the client: X = (encrypted identity information + online / offline flag + timestamp), checksum = CRC32(X + user password), identity code = X + ... The verification code here is a secondary code, presented on the user terminal interface in the form of a QR code or barcode. Both the primary and secondary codes have expiration periods. In online mode, the primary code is updated at fixed time intervals, while the secondary code is generated based on the primary code, with the primary code having a longer validity period than the secondary code. The preferred validity period for the secondary code is 1 minute or 30 seconds, while the preferred validity period for the primary code is 1 hour or even longer. In offline mode or under weak network conditions, the offline code generation process is as follows: the client generates the secondary code using the cached primary code obtained from the most recent online update. The backend for this can be a billing system.

[0052] In some embodiments, the first payment terminal scanning the user terminal that needs to make electronic payments in step 101 to obtain the user terminal's identity information can be achieved through the following technical solution: the first payment terminal scans the identity code presented by the user terminal that needs to make electronic payments and performs signature verification on the identity code; when the signature verification is successful, the identity code is decoded to obtain the user terminal's identity information; after obtaining the user terminal's identity information, the following steps can also be performed: when the identity information is found in the user identity database, it is determined that the identity information has passed the identity verification.

[0053] In some embodiments, the identity code presented on the user terminal is scanned by the camera of the first payment terminal. After the identity code is obtained, it is parsed. The parsing process is as follows: First, the identity code is digitally signed using a decoding software development kit (SDK) integrated in the first payment terminal. The verification uses a public key issued by the backend to verify the digital signature signed with the private key. The backend is a shared backend between the user terminal and the payment terminal, which can be a billing system. Passing the digital signature verification means that the identity information has not been tampered with and is trustworthy. The backend uses a random symmetric key to encrypt the identity information. This random symmetric key is also issued to the payment terminal. After the payment terminal verifies the signature, it uses the symmetric key to decrypt the information to obtain the plaintext of the user's identity information. Then, an identity audit is performed to check whether the identity information is a previously registered valid identity information. When the identity information is found in the user identity database, the identity information is confirmed to have passed the identity audit.

[0054] In step 102, the first receiving terminal generates a transaction corresponding to the identity information.

[0055] In some embodiments, the transaction request information received by the first payment terminal may be transaction request information obtained by scanning with an external barcode scanner. In a canteen scenario, the transaction information may be the name, quantity, and corresponding price of the food. In a transportation scenario, the transaction information received by the first payment terminal may be input by the driver or pre-stored information on various segments and their corresponding prices. The transaction information may be the travel segment and the segment price. Since the transaction information is actually intended to satisfy the consumer's information, there is a corresponding relationship between the transaction information and the identity information. In each consumption process, the identity information can be used as the unique guide. Combining the identity information and the corresponding transaction information, a transaction to be verified is obtained. The simplest transaction can be obtained by combining the identity information and the transaction information. In actual implementation, the order of execution between obtaining the transaction information and obtaining the identity information is not limited.

[0056] In step 103, the first payment terminal detects at least one second payment terminal that can communicate with the first payment terminal.

[0057] See Figure 3B , Figure 3B This is an optional flowchart illustrating an electronic payment processing method provided in an embodiment of the present invention. In step 103, the first receiving terminal detecting at least one second receiving terminal capable of communicating with it can be achieved through the following steps, combining... Figure 3B The steps shown are explained.

[0058] In step 1031, the first receiving terminal sends probe information within its local area network.

[0059] In step 1032, at least one second payment terminal within the local area network performs device verification based on the probe information.

[0060] In step 1033, the first payment terminal receives the verification pass information returned by the second payment terminal.

[0061] In step 1034, it is determined that the first payment terminal can perform collaborative risk verification of the transaction with the second payment terminal, and the first payment terminal is shown to be in a collaborative verification state.

[0062] In some embodiments, the networking method between payment terminals can be a wireless local area network or a wired network. In a wireless local area network, networking can also be achieved via Bluetooth. The detection and discovery method between the first payment terminal and the second payment terminal can be based on an intermediate routing device or can be achieved directly through sensing between the two terminals.

[0063] In some embodiments, the first payment terminal sends probe information within its local area network. This probe information is broadcast over a wide area. At least one second payment terminal within the broadcast area performs device verification based on the probe information. This device verification involves the second payment terminal digitally signing the probe information to confirm the identity of the first payment terminal. If the identity of the first payment terminal is confirmed to be a registered device with a collaborative relationship with the second payment terminal, a verification pass message is returned. When the first payment terminal receives the verification pass message returned by the second payment terminal, it is determined that the first payment terminal can perform collaborative risk verification with the second payment terminal, and the first payment terminal is in a collaborative verification state. The interface of the first payment terminal may display the following information: "The first payment terminal is in a collaborative verification state with the second payment terminal." It may even display the address information, device number, and other specific device information of the second payment terminal on the interface of the first payment terminal.

[0064] In some embodiments, when one of the following conditions is met, it is determined that the first payment terminal will independently perform risk verification on the transaction and the first payment terminal is in an independent verification state: the first payment terminal does not receive verification pass information returned by the second payment terminal within the timeout threshold; the first payment terminal receives verification failure information returned by the second payment terminal.

[0065] In some embodiments, due to network failures, the first payment terminal may be unable to detect the second payment terminal. Therefore, collaborative verification of multiple payment terminals is not possible, and the transaction can only be verified individually by the first payment terminal. The situations in which the transaction cannot be detected include: the first payment terminal does not receive verification pass information from the second payment terminal within the timeout threshold; the first payment terminal receives verification failure information from the second payment terminal. In addition to showing that the first payment terminal is in an independent verification state, the first payment terminal may also show information such as "cannot detect other payment terminals".

[0066] In some embodiments, before performing collaborative verification of a transaction, in order to prevent the second payment terminal from being an impersonating device, it is also necessary to verify the identity of the second payment terminal through the first payment terminal. The first payment terminal performs digital signature verification on the verification pass information or verification failure information returned by the second payment terminal to determine the identity of the second payment terminal. Only when it is confirmed that the identity of the second payment terminal is a registered device with a collaborative relationship with the first payment terminal is the two-way device verification completed, thereby enabling collaborative verification of the transaction.

[0067] In some embodiments, based on the number of times the detected second payment terminal has undergone collaborative verification, the system can further filter the terminals after both parties have verified the information. If the number of collaborative verifications performed by the second payment terminal exceeds the threshold, the second payment terminal can be abandoned for collaborative risk verification, thereby maintaining a balance in the number of verifications performed by each payment terminal overall. This avoids the risk of risk verification being concentrated on a single payment terminal.

[0068] See Figure 3C , Figure 3C This is an optional flowchart illustrating an electronic payment processing method provided in an embodiment of the present invention. In step 103, the first receiving terminal detecting at least one second receiving terminal capable of communicating with it can be achieved through the following steps, combining... Figure 3C The steps shown are explained.

[0069] In step 1035, the first payment terminal sends probe information to the routing device in the local area network to which the first payment terminal belongs.

[0070] In step 1036, the routing device queries at least one second payment terminal that has a collaborative relationship with the first payment terminal.

[0071] In step 1037, the query results are returned to the first payment terminal.

[0072] In step 1038, the first payment terminal receives the query result, determines that the first payment terminal can perform collaborative risk verification of the transaction with the second payment terminal, and displays that the first payment terminal is in a collaborative verification state on the first payment terminal.

[0073] In some embodiments, the networking method between payment terminals can be a wireless local area network or a wired network. In a wireless local area network, networking can also be achieved via Bluetooth. The detection and discovery method between the first payment terminal and the second payment terminal can be based on an intermediate routing device or can be achieved directly through sensing between the two terminals.

[0074] In some embodiments, the first payment terminal sends probe information to a routing device within the local area network to which it belongs. This probe information is sent directly to the routing device. The routing device queries at least one second payment terminal that has a collaborative relationship with the first payment terminal. The routing device stores device information of payment terminals with collaborative verification relationships and returns the query result to the first payment terminal. Upon receiving the query result, the first payment terminal learns the device information of the second payment terminal capable of collaborative risk verification with it. Therefore, it is determined that the first payment terminal can perform collaborative risk verification with the second payment terminal, and the first payment terminal is in a collaborative verification state. The interface of the first payment terminal can display the message "The first payment terminal is in a collaborative verification state with the second payment terminal," and may even display the address information, device number, and other specific device information of the second payment terminal.

[0075] In some embodiments, when one of the following conditions is met, it is determined that the first payment terminal will independently perform risk verification on the transaction and the first payment terminal is in an independent verification state: the first payment terminal does not receive a query result returned by the routing device within the timeout threshold; the first payment terminal receives a query result returned by the routing device with empty content.

[0076] In some embodiments, due to network failures, the first payment terminal may be unable to detect the second payment terminal. Therefore, collaborative verification of multiple payment terminals is not possible, and the transaction can only be verified individually by the first payment terminal. The situations in which the second payment terminal cannot be detected include: the first payment terminal does not receive the query result returned by the routing device within the timeout threshold; the first payment terminal receives a query result returned by the routing device with empty content. In addition to showing that the first payment terminal is in an independent verification state, the first payment terminal may also show information such as "other payment terminals cannot be detected".

[0077] In some embodiments, before performing collaborative verification of a transaction, in order to prevent the second payment terminal from being an impersonating device, it is also necessary to verify the identity of the second payment terminal through the first payment terminal. The first payment terminal performs digital signature verification on the verification pass information or verification failure information returned by the second payment terminal to determine the identity of the second payment terminal. Only when it is confirmed that the identity of the second payment terminal is a registered device with a collaborative relationship with the first payment terminal is the two-way device verification completed, thereby enabling collaborative verification of the transaction.

[0078] In some embodiments, based on the number of times the detected second payment terminal has undergone collaborative verification, the system can further filter the terminals after both parties have verified the information. If the number of collaborative verifications performed by the second payment terminal exceeds the threshold, the second payment terminal can be abandoned for collaborative risk verification, thereby maintaining a balance in the number of verifications performed by each payment terminal overall. This avoids the risk of risk verification being concentrated on a single payment terminal.

[0079] In step 104, the first payment terminal and at least one second payment terminal work together to perform risk verification on the transaction.

[0080] In some embodiments, risk verification is based on risk control strategies. Different risk control strategies are used in different scenarios. When one of the following conditions is met, the first payment terminal and the second payment terminal collaborate to perform single offline risk verification on the order: the first payment terminal sends a payment request to the backend billing system and does not receive a response from the backend billing system for the payment request within the return timeout threshold; the first payment terminal determines that the user terminal is in a weak network state or an offline state. Here, a weak network state refers to a transmission speed lower than the minimum transmission threshold or a 2G network state. The network state of the user terminal can be obtained by scanning the identity code. Here, single offline risk verification refers to risk verification based on the risk control strategy corresponding to the above network state, that is, the risk control strategy corresponding to the single offline state.

[0081] In some embodiments, when the following conditions are met simultaneously, the first payment terminal and the second payment terminal collaborate to perform online risk verification on the order: the first payment terminal sends a payment request to the backend billing system and receives a response from the backend billing system for the payment request within the return timeout threshold; the first payment terminal determines that the user terminal is online, which means that both the first payment terminal and the user terminal are online. The network status of the user terminal can be obtained by scanning the identity code. The online risk verification here refers to the risk verification based on the risk control strategy corresponding to the above network status, that is, the risk control strategy corresponding to the online status.

[0082] When the following conditions are met simultaneously, the first payment terminal and the second payment terminal collaborate to perform dual offline risk verification on the order: the first payment terminal sends a payment request to the backend billing system and does not receive a response from the backend billing system for the payment request within the return timeout threshold; the first payment terminal determines that the user terminal is in a weak network state or an offline state; here, a weak network state refers to a transmission speed lower than the minimum transmission threshold or a 2G network state, which means that both the first payment terminal and the user terminal are offline. The network state of the user terminal can be obtained by scanning the identity code. The dual offline risk verification here refers to the risk verification based on the risk control strategy corresponding to the above network state, that is, the risk control strategy corresponding to the dual offline state.

[0083] In some embodiments, the risk control strategies corresponding to dual offline states, single offline states, and online states are arranged in descending order of their strictness.

[0084] See Figure 3D , Figure 3D This is an optional flowchart illustrating the electronic payment processing method provided in this embodiment of the invention. Step 104, which involves collaborating with at least one second receiving terminal to perform risk verification on transactions initiated by the user terminal, can be achieved through the following steps, combining... Figure 3D The steps shown are explained.

[0085] In step 1041, the first receiving terminal synchronizes the transaction to at least one second receiving terminal.

[0086] As mentioned above, the first and second payment terminals can be POS machines.

[0087] In step 1042, the second payment terminal performs risk verification on the transaction.

[0088] In some embodiments, transactions synchronized to the second payment terminal are used by the second payment terminal to perform the following risk verification operations: querying historical orders made by the user terminal through the second payment terminal based on identity information, and using these as historical orders of the second payment terminal; when both the transaction and the historical orders of the second payment terminal meet the risk control strategy configured on the second payment terminal, determining that the transaction has passed the risk verification of the second payment terminal, and returning the verification result of the second payment terminal to the first payment terminal; after the first payment terminal receives the verification result returned by the second payment terminal, it may also perform the following steps: the first payment terminal presents the risk verification pass identifier corresponding to the second payment terminal, and the historical orders of the second payment terminal.

[0089] In some embodiments, when both the user terminal and the payment terminal are offline, the transactions initiated by the user terminal are risk-verified according to the corresponding risk verification strategy. After the network is restored, the data is asynchronously uploaded to the billing system for collection, thereby improving the user and merchant experience and reducing the risk of bad debts. For example, in a canteen's payment terminal cluster, there are two payment terminals, A and B. If each terminal allows a single user to overdraft 10 times, then if the offline information is not shared within the local area network, the user can actually overdraft 10 times on both machine A and machine B. However, if the information of payment terminals A and B is shared, then the user can only overdraft a total of 10 times on both machines, thus reducing the risk of bad debts. The above process is a typical collaborative risk verification process.

[0090] In some embodiments, the first payment terminal synchronizes the transaction to at least one second payment terminal, enabling the second payment terminal to obtain the transaction request information and, in conjunction with the identity information, query the historical orders of the second payment terminal that made the purchase through the second payment terminal. The transaction includes identity information and transaction request information; for example, the transaction might include information such as "User A, boxed meal, 20 yuan". The second payment terminal then queries the historical orders of the second payment terminal where User A made the purchase through the second payment terminal and finds 10 overdraft transactions. If the maximum overdraft limit configured in the risk control strategy is 10, the second payment terminal will find that User A has already made 10 overdrafts on this terminal, and the current transaction is the 11th, exceeding the maximum overdraft limit. Therefore, it returns a failure flag, and the first payment terminal receives the failure flag returned by the second payment terminal. When the risk control strategies of the first and second payment terminals are consistent, the first payment terminal does not need to perform further verification.

[0091] The transaction information here includes the amount to be paid, and the identity information can indicate whether the user is a registered user, whether they have spending privileges, and even whether the user has been previously marked as a suspicious user. Suspicious users can be users with credit issues. The second payment terminal can verify whether the amount to be paid does not exceed the maximum single payment amount, whether the user is legitimate, and, in conjunction with the second payment terminal's historical orders, determine whether the total overdraft amount exceeds the maximum overdraft threshold. Thus, when both the transaction and the second payment terminal's historical orders meet the risk control strategy configured on the second payment terminal, the transaction is determined to have passed the risk verification of the second payment terminal, and the verification result of the second payment terminal is returned to the first payment terminal. After the first payment terminal receives the verification result returned by the second payment terminal, the method also includes: the first payment terminal presents the corresponding risk verification pass mark of the second payment terminal, as well as the historical orders of the second payment terminal.

[0092] In step 1043, the first payment terminal receives the verification result of the second payment terminal returned by the second payment terminal.

[0093] In some embodiments, after step 1043 is executed, the first payment terminal displays the risk verification pass identifier of the corresponding second payment terminal and the historical orders of the second payment terminal. The verification result of the second payment terminal may include the pass identifier and the historical orders of the second payment terminal. The first payment terminal displays the risk verification pass identifier and the historical orders of the second payment terminal carried in the verification result of the second payment terminal. The historical orders of the second payment terminal may be that the user has 3 overdraft records on the second payment terminal. After receiving these messages, the first payment terminal will visualize the received information.

[0094] In step 1044, the transaction is re-verified for risk based on the verification result of the second payment terminal.

[0095] In some embodiments, the risk verification of the transaction again based on the verification result of the second payment terminal in step 1044 can be achieved through the following technical solution: the first payment terminal extracts the historical orders of the second payment terminal from the verification result of the second payment terminal; queries the historical orders of the user terminal that were consumed through the first payment terminal based on the identity information, and uses them as the historical orders of the first payment terminal; the transaction, the historical orders of the first payment terminal and the historical orders of the second payment terminal are summarized; when the summary result meets the risk control strategy configured in the first payment terminal, it is determined that the transaction has passed the risk verification of the first payment terminal.

[0096] In some embodiments, the historical orders of the second payment terminal can be the number of overdrafts and the amount of overdrafts by the user on the payment terminal, etc. The risk control strategy can be the total amount and the total number of overdrafts that the user can overdraft across all payment terminals. Here, the first payment terminal receives the historical orders returned by each of the second payment terminals and summarizes all the historical orders and the current transaction request information. For example, if other payment terminals report 10 overdrafts, and the transaction generated by the first payment terminal is the 11th transaction, exceeding the maximum overdraft amount, then the risk verification of this transaction fails and the order cannot be created.

[0097] In some embodiments, collaborative risk verification can be achieved solely through data sharing. Specifically, the first payment terminal synchronizes the transaction to at least one second payment terminal, enabling the second payment terminal to obtain the transaction request information and, in conjunction with identity information, query the historical orders of the second payment terminal that made the purchase through it. The historical orders of the second payment terminal are then returned to the first payment terminal. After the first payment terminal receives the collaborative risk verification result returned by the second payment terminal, the method further includes: displaying the historical orders of the second payment terminal on the first payment terminal. The first payment terminal extracts the historical orders of the second payment terminal; the first payment terminal obtains the transaction request information and, in conjunction with identity information, queries the historical orders of the first payment terminal that made the purchase through it; the transaction request information, identity information, the historical orders of the first payment terminal, and the historical orders of the second payment terminal are aggregated; when the aggregated result satisfies the risk control strategy configured on the first payment terminal, the risk verification is deemed successful.

[0098] In some embodiments, the risk verification of the transaction in step 104 in collaboration with at least one second payment terminal can be achieved through the following technical solution: the first payment terminal synchronizes the transaction to at least one second payment terminal, so that the second payment terminal queries the user terminal's historical orders made through the second payment terminal based on the user's identity information, and uses these as the second payment terminal's historical orders; the first payment terminal receives the second payment terminal's historical orders returned by the second payment terminal, and performs risk verification of the transaction again based on the second payment terminal's historical orders.

[0099] Here, the second payment terminal may not perform the verification process. Instead, the role of the second payment terminal is to query the historical orders made through it and synchronize these orders to the first payment terminal, which is the current payment terminal. The first payment terminal then performs risk verification on the current transaction based on the historical orders synchronized from all the second payment terminals. Compared to other collaborative verification methods, this method is the most efficient and can perform risk verification based on records from all terminals, ensuring overdraft security and avoiding overdraft risks.

[0100] In some embodiments, collaborative risk verification can be completed through separate verification on the second payment terminal and the first payment terminal. That is, each second payment terminal queries its own historical orders and combines them with the transactions synchronized from the first payment terminal to complete the verification of the transaction on its own payment terminal. In other words, this verification is performed by each second payment terminal, and the reference data is the data on its own terminal and the current transaction sent by the first payment terminal. If there is an unqualified result among the multiple verification results generated by combining the data from the two terminals, the transaction fails the risk verification. If there is no unqualified result, the transaction passes the risk verification of multiple second payment terminals, and the first payment terminal continues to verify the transaction by combining the data from all the second payment terminals.

[0101] In some embodiments, collaborative risk verification can be completed through separate verifications on the second payment terminal and the first payment terminal. That is, each second payment terminal queries its own historical orders, combines them with transactions synchronized from the first payment terminal and its own historical orders synchronized from other second payment terminals, and completes the verification of the transaction on its own payment terminal. In other words, this verification is performed by each second payment terminal, and the reference data is the data on its own terminal, the historical orders of other second payment terminals, and the current transaction sent by the first payment terminal. If there is an unqualified result among the multiple verification results generated by combining the data from all terminals, then the transaction fails the risk verification. If there is no unqualified result, then the transaction passes the risk verification of multiple second payment terminals. Compared with the above implementation method, it has the highest security level.

[0102] In some embodiments, when the number of detected second payment terminals does not reach the threshold for the number of payment terminals to be collaboratively verified, the risk control strategy configured on the first payment terminal will be modified proportionally. For example, the first payment terminal is required to receive historical orders synchronized from the other 4 payment terminals, but in fact the first payment terminal only receives historical orders synchronized from the other 3 payment terminals. In this case, the original limit of 10 transactions can be converted into 8 transactions, that is, the risk control strategy on the first payment terminal is modified according to the number of payment terminals participating in the collaboration.

[0103] In some embodiments, generating a transaction corresponding to identity information includes: the first payment terminal receiving transaction information corresponding to identity information and combining the identity information and transaction information into a transaction corresponding to identity information; the following technical solution can also be implemented: the first payment terminal presents a transaction in a risk verification passed state and presents a manual confirmation interface; when the manual confirmation interface of the first payment terminal receives manual confirmation information for the risk verification passed state, the first payment terminal creates an order for the corresponding transaction.

[0104] In some embodiments, to minimize the risks of user consumption and environmental impact, a manual confirmation entry point can be provided. When the risk verification is confirmed to be passed, a secondary confirmation instruction from the user is received. When the manual confirmation information for the risk verification status is received in the manual confirmation interface of the first payment terminal, the corresponding transaction order is created. Even if the risk verification fails, a secondary confirmation instruction from the user can still be received, allowing the merchant to provide another overdraft opportunity in special scenarios. The first payment terminal can receive the merchant's manual verification approval instruction, enabling the user's consumption to be completed smoothly.

[0105] In some embodiments, the following technical solution may also be implemented: the first payment terminal sends a heartbeat instruction to the billing system, so that the billing system synchronizes the risk control policy configured in the billing system to the first payment terminal and at least one second payment terminal; the first payment terminal receives the risk control policy and compares the risk control policy with the existing risk control policy in the first payment terminal; when the received risk control policy is inconsistent with the existing risk control policy, the existing risk control policy is updated to the received risk control policy, and the updated status of the risk control policy is displayed in the first payment terminal.

[0106] In some embodiments, the payment terminal needs to send a heartbeat command to the billing system at regular intervals. This heartbeat command can be any custom command. The purpose of the heartbeat is to ensure that the payment terminal and the billing system are in communication to prevent the terminal from being offline for a long time without the user's knowledge. While performing the heartbeat, the billing system sends the latest risk control policy configured by the administrator in the billing system to the payment terminal. This risk control policy includes different risk control policies for various network conditions. Different risk control policies can be set for different payment terminals, but it is preferable to set the same risk control policy. Setting the same risk control policy helps to improve security, while setting different risk control policies makes it more convenient for users to make purchases. For example, for a payment terminal with a certain window, if the price of the goods in that window is much higher than that of other payment terminals, then the maximum amount for a single transaction for that single terminal can be set higher than that for other payment terminals.

[0107] In some embodiments, see Figure 4 , Figure 4This is an optional blockchain architecture diagram of the online payment order processing system provided in this embodiment of the invention. Nodes in the blockchain network need to authenticate their identities at the authentication center 600. The first receiving terminal 700 can be a node in the blockchain network. The collaborative risk verification process can be that the first receiving terminal node 700 submits a transaction for risk verification to multiple second receiving terminal nodes (210-1, 210-2, 210-3) in the blockchain network, which is equivalent to submitting a verification request. Each node performs risk verification, and each node signs its own risk verification result and sends it to other nodes. When the node that initiated the verification request collects enough verification results indicating that the verification has passed, an order will be created. The above process is similar to the consensus process in the blockchain network. In this process, the received verification results are digitally signed to prevent tampering, and the verification record of each transaction request and the created order are synchronized to the blockchain network. When each node performs verification, it queries the record corresponding to the identity information from the blockchain network and then performs risk verification in combination with risk control strategies.

[0108] In step 105, when the risk verification is passed, the first payment terminal displays the transaction as completed.

[0109] In some embodiments, when the risk verification passes, the first payment terminal can display the transaction as completed. This transaction is actually an overdraft transaction between the user terminal and the first payment terminal. Since the risk verification of the transaction has passed, the transaction is considered a safe and low-risk overdraft transaction. Therefore, the first payment terminal will create an order corresponding to the transaction. In addition to the relevant information in the transaction, the order also includes the risk control verification result of the transaction, the time of order generation (collection time), the collection payment platform, and other information required by the billing system to collect from the third-party payment platform. Up to the time the order is created, the transaction is considered completed for the user terminal, and the user can obtain the corresponding goods. The payment terminal will then scan the next user terminal, and the billing system will collect the payment based on the order to complete the transaction payment process.

[0110] In step 106, the first payment terminal sends the corresponding transaction order to the billing system in the network.

[0111] In step 107, the billing system performs the collection of receivables for the order.

[0112] In some embodiments, no actual payment operation is performed up to step 106. The payment operation needs to be performed after the first payment terminal recovers the network environment or the network congestion level is reduced. The order is then asynchronously uploaded to the billing system, and the billing system performs a collection operation on the payer bound to the user based on the identity information. Once the collection operation is successful, a collection success message is returned to the payment terminal so that the payment terminal adds a collection success mark to the order stored locally.

[0113] In some embodiments, the present invention provides an electronic payment processing method, comprising: a first payment terminal scanning the identity information presented by a user terminal that needs to make an electronic payment to generate a transaction corresponding to the identity information; the first payment terminal displaying at least one second payment terminal that has been detected and can communicate with the first payment terminal; displaying the result of risk verification of the transaction in collaboration with at least one second payment terminal; when the risk verification is passed, presenting the completed status of the transaction and the order created by the corresponding transaction; sending the order to the billing system in the network, and displaying a message from the billing system indicating successful collection of receivables for the order.

[0114] In some embodiments, the implementation process of the above-described electronic payment processing method can refer to the specific implementation schemes in the above embodiments, and in each processing stage, the working status of each payment terminal, the various results generated by the query, and the information will be displayed on each second payment terminal and the first payment terminal that needs to create an order.

[0115] The following will describe an exemplary application of the embodiments of the present invention in a practical application scenario.

[0116] The electronic payment processing method provided by this invention can still ensure safe and convenient POS payments for users even in scenarios with poor network signal (transmission speed below the transmission speed threshold), offline (user terminal or payment terminal offline), or dual offline scenarios. A specific application scenario could be in a cafeteria, where the user terminal provides a QR code identifying its identity, which is scanned by the payment terminal (POS machine). When both the user terminal and the payment terminal are offline, the transaction initiated by the user terminal is risk-verified according to the corresponding risk verification strategy. After the network is restored, the transaction is asynchronously uploaded to the billing system for recovery, thereby improving the user and merchant experience and reducing the risk of bad debts. For example, in a POS machine cluster in a cafeteria, there are two POS machines, A and B. If both allow a single user to make 10 offline payments, then if the offline information is not shared within the local area network, the user can actually make 10 offline payments on both machine A and machine B. However, if the information of POS machines A and B is shared, then the user can only make 10 offline payments on both machines, thereby reducing the risk of bad debts caused by offline overdrafts.

[0117] This invention provides an electronic payment processing method that ensures a smooth payment experience even in weak network environments. (See also...) Figure 5 , Figure 5 This is a diagram of the terminal deployment architecture in the electronic payment processing method provided by this invention. Taking a canteen consumption scenario as an example, in the canteen POS machine (payment terminal) consumption scenario, the server with the billing system is on the public network. Before the canteen's POS machine cluster connects to the public network, a local area network (LAN) is first established. All the canteen's POS machines are within this LAN, and then they are uniformly connected to the public network server. The POS machines within the LAN can enjoy the same risk control policies. When the POS machine is deployed and initialized, the server will uniformly send the necessary configuration information to the POS machine, including: risk control configuration and device configuration, etc. The risk control configuration here includes: restrictions on a single POS machine: the maximum offline payment amount allowed for a single machine; the maximum offline single order amount allowed for a single machine. The system allows a single POS terminal to handle a total number of offline orders, a single POS terminal to handle a total offline duration, and restrictions on individual users: maximum offline order amount per user; maximum offline order quantity per user; and total offline order amount per user. Device configurations include: the POS machine's payment key, heartbeat duration, and order upload interval. These configurations are designed to control the risks associated with offline user spending scenarios. When both the POS machine and the user terminal are offline, the POS machine will enter an offline payment process. This ensures fast payment even if there is a delay in the connection to the external network. Orders are uploaded asynchronously in the background to ensure near real-time payment. Here, "asynchronous" means waiting until there are fewer people in the cafeteria, when network bandwidth pressure is lower, to allow order uploads to proceed.

[0118] This is a safer and more efficient POS offline payment solution: In scenarios where offline payment is required due to weak network conditions, local POS machines are grouped into a local area network (LAN). The offline risk control strategies of individual POS machines in the LAN are combined into the overall offline risk control strategy of the POS machine group, which effectively reduces the risk of offline payment, reduces the probability of bad debts for merchants, and ensures the payment speed of users' payment methods such as scanning codes and swiping cards.

[0119] See Figure 6 , Figure 6This is a flowchart of the identity code generation process in the electronic payment processing method provided in this embodiment of the invention. First, network initialization is performed, which must be done with a network connection. Then, the QR code is updated periodically through an asynchronous code generation mechanism. An online code is generated when connected to the network, and an offline code is generated when offline. The online code generation process is as follows: The user terminal client obtains the user's identity information from the server (the same server as the billing system). The user's identity information is encrypted in the background using a set of time-sensitive advanced encryption standard keys and then sent to the client. A user password is also sent simultaneously. The client cannot decrypt the plaintext content and caches this encrypted identity information (level 1 code) for offline use. The components of the identity information are jointly determined by the background and the client, and are as follows: X = (background encrypted data + online / offline flag + timestamp), checksum = CRC32(X + user password), identity information (level 2 code) = X + ... The checksum, primary code, and secondary code all have time limits. In online mode, the primary code is updated periodically, but its validity period is relatively long. The secondary code is generated based on the primary code and has a very short validity period. The secondary code is the QR code displayed to the POS machine that identifies the user. The offline code generation process is as follows: The difference between offline and online generation is that the offline code uses the primary code obtained from the last online update before going offline, rather than the code obtained from automatic updates at regular intervals. The secondary code is then generated from the primary code obtained from the last online update through the client.

[0120] See Figure 7 , Figure 7This is a flowchart of the overall payment process of a POS machine in the electronic payment processing method provided in this embodiment of the invention. The user terminal displays a QR code for consumption. The receiving terminal (POS machine) scans and decodes the displayed QR code for identity verification. After passing the verification of the risk control system, which includes a single offline risk control system, a dual offline risk control system, and an online risk control system, the difference between these three systems lies in their varying levels of strictness. The dual offline risk control system has the strictest risk control strategy. Next, an order is created, and marketing and pricing processes are performed. The marketing system refers to assigning different discount permissions to users with different identities. For example, within a school, teachers receive a discount based on their permissions on top of the original price. Pricing processes determine the actual payment price. During offline payment, no payment is actually deducted; the deduction occurs only after asynchronous upload. Ultimately, regardless of whether the order is online or offline, it is uploaded to the billing middleware gateway. The platform consists of a backend containing the entire payment chain, a middle platform for managing user identities (e.g., whether a user is a teacher or a student), a heartbeat monitoring system where the client sends a heartbeat command to the server, and the heartbeat detection process confirms whether the server returns an updated risk control strategy and updates accordingly, and a computational middle platform controlled by the administrator. Real-time computation and strategy models are used to update risk control strategies and synchronize them to the POS machine during the next heartbeat. The transaction engine within the computational middle platform includes process control and an order center. Process control monitors the processing stages of each order, while the order center receives and manages orders uploaded by the payment terminal. Merchant management connects with various merchants, controls and ensures merchant payment access, and manages contracts between merchants and the billing system. The marketing system features self-service configuration and personalized strategies, which administrators can modify. The settlement system connects with third-party payment providers and is primarily responsible for independent reconciliation and split settlement.

[0121] See Figure 8 , Figure 8 This is a schematic diagram of the payment process of a single POS machine in the electronic payment processing method provided by the embodiment of the present invention. The machine decodes the QR code and verifies the identity. After passing the verification of the risk control system, the order is created. If the network is good, the online consumption process is entered. If the network is weak or offline, the offline payment process is entered. Then, the data is asynchronously uploaded to the billing system. When the heartbeat detection is performed, the updated risk control strategy returned by the server is received to update the risk control strategy in the POS machine.

[0122] See Figure 9 , Figure 9This is a flowchart of the POS machine group verification process in the electronic payment processing method provided by this invention. POS machines deployed locally are connected to a local area network (LAN) to connect to the external billing system. Offline information within the LAN can be shared. Before connecting to the public network server, the POS machines form a local LAN. In poor network conditions, each POS machine performs its own transaction security risk control verification through the overall POS machine group's risk control strategy. The risk control strategy of the POS machine group is more comprehensive than that of a single POS machine. In offline payment scenarios, it can identify the number and amount of offline orders between different POS machines, reducing the risk of offline consumption. Because offline information of the machines within the LAN can be shared, it is better than offline risk control for a single machine.

[0123] This invention provides a safer and more efficient POS machine payment solution. This solution can effectively support POS transactions in places with poor network conditions, such as canteens and basements, helping users to effectively control transaction risks in scenarios where the network is poor and offline payments are required. When the network is good, transactions can proceed as smoothly as before. This is a safer and more efficient POS machine payment solution that makes offline transactions safer for users and reduces the risk of bad debts.

[0124] The following description continues to illustrate the exemplary structure of the electronic payment processing device 455 provided in the embodiments of the present invention as a software module. In some embodiments, such as... Figure 2 As shown, the software modules stored in the electronic payment processing device 455 in the memory 450 may include: an identity information acquisition module 4551, used by a first payment terminal to scan a user terminal that needs to make an electronic payment to obtain the user terminal's identity information; a transaction generation module 4552, used to generate a transaction corresponding to the identity information; a risk verification module 4553, used to detect at least one second payment terminal that can communicate with the first payment terminal, and to cooperate with at least one second payment terminal to perform risk verification on the transaction; and a transaction completion module 4554, used to present the completed status of the transaction when the risk verification is passed, and to send the corresponding transaction order to the billing system in the network so that the billing system can perform the collection operation of the receivables of the order.

[0125] In some embodiments, the identity information acquisition module 4551 is further configured to: scan the identity code presented on the user terminal that needs to make electronic payments, and verify the identity code by signing; when the signature verification is successful, decode the identity code to obtain the identity information of the user terminal; when the identity information is found in the user identity database, determine that the identity information has passed the identity verification.

[0126] In some embodiments, the risk verification module 4553 is further configured to: synchronize the transaction to at least one second payment terminal so that the second payment terminal performs risk verification on the transaction; receive the verification result returned by the second payment terminal, and perform risk verification on the transaction again based on the verification result of the second payment terminal.

[0127] In some embodiments, the risk verification module 4553 is further configured to: query historical orders made by the user terminal through the second payment terminal based on the user's identity information, and use these as historical orders of the second payment terminal; when both the transaction and the historical orders of the second payment terminal meet the risk control strategy configured on the second payment terminal, determine that the transaction has passed the risk verification of the second payment terminal, and return the verification result of the second payment terminal to the first payment terminal; and present the risk verification pass identifier of the corresponding second payment terminal and the historical orders of the second payment terminal.

[0128] In some embodiments, the risk verification module 4553 is further configured to: extract the historical orders of the second payment terminal from the verification result of the second payment terminal; query the historical orders of the user terminal that were consumed through the first payment terminal based on the identity information, and use them as the historical orders of the first payment terminal; summarize the transaction, the historical orders of the first payment terminal and the historical orders of the second payment terminal; and determine that the transaction has passed the risk verification of the first payment terminal when the summary result meets the risk control strategy configured in the first payment terminal.

[0129] In some embodiments, the risk verification module 4553 is further configured to: synchronize the transaction to at least one second payment terminal, so that the second payment terminal can query the user terminal’s historical orders made through the second payment terminal based on the user’s identity information, and use them as the second payment terminal’s historical orders; receive the second payment terminal’s historical orders returned by the second payment terminal, and perform risk verification on the transaction again based on the second payment terminal’s historical orders.

[0130] In some embodiments, the transaction generation module 4552 is further configured to: receive transaction information corresponding to identity information, and combine the identity information and transaction information into a transaction corresponding to the identity information; the risk verification module 4553 is further configured to: when it is determined that the transaction has passed the risk verification of the first payment terminal, present the transaction as being in a risk verification passed state and present a manual confirmation interface; when a manual confirmation message for the risk verification passed state is received in the manual confirmation interface, create an order for the corresponding transaction.

[0131] In some embodiments, the risk verification module 4553 is further configured to: send probe information within the local area network to which the first payment terminal belongs, so that at least one second payment terminal within the local area network performs device verification based on the probe information; when receiving verification pass information returned by the second payment terminal, determine that the first payment terminal can perform collaborative risk verification of the transaction with the second payment terminal, and indicate that the first payment terminal is in a collaborative verification state.

[0132] In some embodiments, the risk verification module 4553 is further configured to: determine that the first payment terminal will independently perform risk verification on the transaction and present the first payment terminal as being in an independent verification state when one of the following conditions is met: the first payment terminal does not receive verification pass information returned by the second payment terminal within the timeout threshold; the first payment terminal receives verification failure information returned by the second payment terminal.

[0133] In some embodiments, the risk verification module 4553 is further configured to: send probe information to a routing device in the local area network to which the first payment terminal belongs, so that the routing device queries at least one second payment terminal that has a collaborative relationship with the first payment terminal and returns the query result to the first payment terminal; when the first payment terminal receives the query result, it determines that the first payment terminal can perform collaborative risk verification of the transaction with the second payment terminal and presents that the first payment terminal is in a collaborative verification state.

[0134] In some embodiments, the risk verification module 4553 is further configured to: determine that the first payment terminal will independently perform risk verification on the transaction and present the first payment terminal as being in an independent verification state when one of the following conditions is met: the first payment terminal does not receive a query result returned by the routing device within the timeout threshold; the first payment terminal receives a query result returned by the routing device with empty content.

[0135] In some embodiments, the risk verification module 4553 is further configured to: send a heartbeat instruction to the billing system so that the billing system synchronizes the risk control strategy configured in the billing system to the first payment terminal and at least one second payment terminal; receive the risk control strategy and compare the risk control strategy with the existing risk control strategy in the first payment terminal; when the received risk control strategy is inconsistent with the existing risk control strategy, update the existing risk control strategy to the received risk control strategy and display the updated status of the risk control strategy.

[0136] This invention provides an electronic payment processing device 455, comprising: an identity information acquisition module 4551, used by a first payment terminal to scan the identity information presented by a user terminal that needs to make electronic payments, so as to generate a transaction corresponding to the identity information; a risk verification module 4553, used by the first payment terminal to display at least one second payment terminal detected that can communicate with the first payment terminal; to display the result of risk verification of the transaction in collaboration with at least one second payment terminal; and when the risk verification is passed, to present the completed status of the transaction and the order created by the corresponding transaction; and a transaction completion module 4554, used to send the order to the billing system in the network and display a message from the billing system that the receivables for the order have been successfully recovered.

[0137] This invention provides a computer-readable storage medium storing executable instructions. When these executable instructions are executed by a processor, they cause the processor to perform the method provided in this invention, for example... Figures 3A-3D The method for processing electronic payments is shown.

[0138] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0139] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0140] As an example, executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0141] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0142] In summary, through the embodiments of the present invention, multiple payment terminals perform collaborative risk verification on users' consumption requests. After the collaborative risk verification is passed, the payment terminals respond to the users' consumption requests, display the order completion status on the payment terminals, and perform asynchronous collection operations. This reduces both the users' waiting time and the risk of bad debts caused by offline overdrafts.

[0143] The above are merely embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of the present invention are included within the scope of protection of the present invention.

Claims

1. A method for processing electronic payments, characterized in that, include: The first payment terminal scans the user terminal that needs to make an electronic payment to obtain the identity information of the user terminal. Generate a transaction corresponding to the aforementioned identity information; The system detects at least one second payment terminal capable of communicating with the first payment terminal and synchronizes the transaction to at least one second payment terminal, so that the second payment terminal can query the user terminal's historical orders made through the second payment terminal based on the identity information, and use these as the second payment terminal's historical orders. Receive the historical orders returned by the second payment terminal, and perform risk verification on the transaction based on the historical orders of the second payment terminal; When the risk verification passes, the transaction is displayed as completed. Send an order corresponding to the transaction to the billing system in the network so that the billing system can perform a collection operation for the receivables of the order.

2. The method according to claim 1, characterized in that, The first payment terminal scans the user terminal that needs to make an electronic payment to obtain the user terminal's identity information, including: The first payment terminal scans the identity code presented by the user terminal that needs to make an electronic payment, and verifies the identity code by signing it. When the signature verification is successful, the identity code is decoded to obtain the identity information of the user terminal; After obtaining the identity information of the user terminal, the method further includes: When the identity information is found in the user identity database, it is determined that the identity information has passed the identity verification.

3. The method according to claim 1, characterized in that, The generation of the transaction corresponding to the identity information includes: Receive transaction information corresponding to the identity information, and combine the identity information and the transaction information into a transaction corresponding to the identity information; The method further includes: When it is determined that the transaction has passed the risk verification of the first payment terminal, the transaction is shown to be in a risk verification passed state, and a manual confirmation interface is displayed; When a manual confirmation message indicating that the risk verification has passed is received in the manual confirmation interface, an order corresponding to the transaction is created.

4. The method according to claim 1, characterized in that, The detection includes at least one second payment terminal capable of communicating with the first payment terminal, comprising: Send probe information within the local area network to which the first payment terminal belongs, so that at least one second payment terminal within the local area network can perform device verification based on the probe information; When the verification pass information returned by the second payment terminal is received, it is determined that the first payment terminal can perform collaborative risk verification of the transaction with the second payment terminal, and The first payment terminal is shown to be in a collaborative verification state.

5. The method according to claim 4, characterized in that, The method further includes: When one of the following conditions is met, it is determined that the first payment terminal will independently perform risk verification on the transaction, and the first payment terminal will be in an independent verification state: The first payment terminal did not receive the verification pass information returned by the second payment terminal within the timeout threshold; The first payment terminal receives a verification failure message returned by the second payment terminal.

6. The method according to claim 1, characterized in that, The detection includes at least one second payment terminal capable of communicating with the first payment terminal, comprising: Send probe information to the routing device within the local area network to which the first payment terminal belongs, so that... The routing device queries at least one second payment terminal that has a collaborative relationship with the first payment terminal, and returns the query result to the first payment terminal; When the first payment terminal receives the query result, it determines that the first payment terminal can perform collaborative risk verification of the transaction with the second payment terminal, and The first payment terminal is shown to be in a collaborative verification state. The method further includes: When one of the following conditions is met, it is determined that the first payment terminal will independently perform risk verification on the transaction, and the first payment terminal will be in an independent verification state: The first payment terminal did not receive the query result returned by the routing device within the timeout period; The first payment terminal receives a query result returned by the routing device that contains no content.

7. The method according to claim 1, characterized in that, The method further includes: The first payment terminal sends a heartbeat instruction to the billing system, so that the billing system will synchronize the risk control policy configured in the billing system to the first payment terminal and at least one second payment terminal. Receive the risk control strategy and compare it with the existing risk control strategy in the first payment terminal; When the received risk control strategy is inconsistent with the existing risk control strategy, the existing risk control strategy is updated to the received risk control strategy, and the updated status of the risk control strategy is displayed.

8. A method for processing electronic payments, characterized in that, include: The first payment terminal scans the identity information presented by the user terminal that needs to make an electronic payment, so as to generate a transaction corresponding to the identity information; The first payment terminal displays at least one second payment terminal that has been detected and is capable of communicating with the first payment terminal; The results of risk verification of the transaction in collaboration with at least one second payment terminal are displayed; wherein, the risk verification of the transaction in collaboration with at least one second payment terminal includes: synchronizing the transaction to at least one second payment terminal, so that the second payment terminal queries the user terminal's historical orders made through the second payment terminal based on the identity information, as the second payment terminal's historical orders; receiving the second payment terminal's historical orders returned by the second payment terminal, and performing risk verification of the transaction based on the second payment terminal's historical orders; When the risk verification is passed, the completed status of the transaction and the corresponding order created by the exchange are displayed. The order is sent to the billing system in the network, and a message is displayed showing that the billing system has successfully recovered the receivables for the order.

9. An electronic payment processing device, characterized in that, include: The identity information acquisition module is used by the first payment terminal to scan the user terminal that needs to make electronic payment in order to obtain the identity information of the user terminal. The transaction generation module is used to generate transactions corresponding to the identity information. The risk verification module is used to detect at least one second payment terminal that can communicate with the first payment terminal, and to synchronize the transaction to at least one second payment terminal, so that the second payment terminal can query the user terminal’s historical orders made through the second payment terminal based on the identity information, and use them as the second payment terminal’s historical orders; Receive the historical orders returned by the second payment terminal, and perform risk verification on the transaction based on the historical orders of the second payment terminal; The transaction completion module is used to display the completed status of the transaction when the risk verification passes, and Send an order corresponding to the transaction to the billing system in the network so that the billing system can perform a collection operation for the receivables of the order.

10. The apparatus according to claim 9, characterized in that, The identity information acquisition module is also used for: The first payment terminal scans the identity code presented by the user terminal that needs to make an electronic payment, and verifies the identity code by signing it. When the signature verification is successful, the identity code is decoded to obtain the identity information of the user terminal; When the identity information is found in the user identity database, it is determined that the identity information has passed the identity verification.

11. The apparatus according to claim 9, characterized in that, The transaction generation module is also used for: Receive transaction information corresponding to the identity information, and combine the identity information and the transaction information into a transaction corresponding to the identity information; The risk verification module is also used for: When it is determined that the transaction has passed the risk verification of the first payment terminal, the transaction is shown to be in a risk verification passed state, and a manual confirmation interface is displayed; When a manual confirmation message indicating that the risk verification has passed is received in the manual confirmation interface, an order corresponding to the transaction is created.

12. The apparatus according to claim 9, characterized in that, The risk verification module is also used for: Send probe information within the local area network to which the first payment terminal belongs, so that at least one second payment terminal within the local area network can perform device verification based on the probe information; When the verification pass information returned by the second payment terminal is received, it is determined that the first payment terminal can perform collaborative risk verification of the transaction with the second payment terminal, and The first payment terminal is shown to be in a collaborative verification state.

13. The apparatus according to claim 12, characterized in that, The risk verification module is also used for: When one of the following conditions is met, it is determined that the first payment terminal will independently perform risk verification on the transaction, and the first payment terminal will be in an independent verification state: The first payment terminal did not receive the verification pass information returned by the second payment terminal within the timeout threshold; The first payment terminal receives a verification failure message returned by the second payment terminal.

14. The apparatus according to claim 9, characterized in that, The risk verification module is also used for: Send probe information to the routing device within the local area network to which the first payment terminal belongs, so that... The routing device queries at least one second payment terminal that has a collaborative relationship with the first payment terminal, and returns the query result to the first payment terminal; When the first payment terminal receives the query result, it determines that the first payment terminal can perform collaborative risk verification of the transaction with the second payment terminal, and The first payment terminal is shown to be in a collaborative verification state. The risk verification module is also used for: When one of the following conditions is met, it is determined that the first payment terminal will independently perform risk verification on the transaction, and the first payment terminal will be in an independent verification state: The first payment terminal did not receive the query result returned by the routing device within the timeout period; The first payment terminal receives a query result returned by the routing device that contains no content.

15. The apparatus according to claim 9, characterized in that, The risk verification module is also used for: The first payment terminal sends a heartbeat instruction to the billing system, so that the billing system will synchronize the risk control policy configured in the billing system to the first payment terminal and at least one second payment terminal. Receive the risk control strategy and compare it with the existing risk control strategy in the first payment terminal; When the received risk control strategy is inconsistent with the existing risk control strategy, the existing risk control strategy is updated to the received risk control strategy, and the updated status of the risk control strategy is displayed.

16. An electronic payment processing device, characterized in that, include: The identity information acquisition module is used by the first payment terminal to scan the identity information presented by the user terminal that needs to make electronic payments, so as to generate a transaction corresponding to the identity information; A risk verification module is used for the first payment terminal to display at least one second payment terminal that has been detected and is capable of communicating with the first payment terminal. The transaction completion module is used to display the result of risk verification of the transaction in collaboration with at least one second payment terminal; wherein, the risk verification of the transaction in collaboration with at least one second payment terminal includes: synchronizing the transaction to at least one second payment terminal, so that the second payment terminal queries the user terminal's historical orders made through the second payment terminal based on the identity information, as the second payment terminal's historical orders; receiving the second payment terminal's historical orders returned by the second payment terminal, and performing risk verification of the transaction based on the second payment terminal's historical orders; when the risk verification passes, presenting the completed status of the transaction and the corresponding order created by the transaction; The transaction completion module is used to send the order to the billing system in the network and display a message from the billing system indicating that the receivables for the order have been successfully recovered.

17. An electronic device, characterized in that, include: Memory, used to store executable instructions; A processor, when executing executable instructions stored in the memory, implements the electronic payment processing method according to any one of claims 1 to 7 or the electronic payment processing method according to claim 8.

18. A computer-readable storage medium, characterized in that, It stores executable instructions for causing a processor to execute, thereby implementing the electronic payment processing method according to any one of claims 1 to 7 or the electronic payment processing method according to claim 8.

Images