Payment code generation method and device, payment method and device, storage medium and equipment

Abstract

The invention discloses a payment code generation method and device, a payment method and device, a storage medium and equipment, and the method comprises the steps: responding to a temporary payment code generation request of a second terminal, and displaying a temporary payment code confirmation page on a first terminal; wherein the generation request comprises identity information of a second terminal user and a request amount; receiving confirmation generation information input on a confirmation page by a first terminal user with payment code payment capability, wherein the confirmation generation information comprises identity information of a second terminal user, identity information of the first terminal user and payment authorization information used by the second terminal user; and generating a temporary payment code according to the generation confirmation information, and sending the temporary payment code to the second terminal to enable the second terminal to use the temporary payment code, the temporary payment code including the unique identifier and payment authorization information. According to the invention, the temporary payment code can be generated through the first terminal and sent to the second terminal for use, so that payment convenience is realized.

Description

Technical Field

[0001] This application relates to the field of mobile payment technology, specifically to a payment code generation method, payment method, device, storage medium, and equipment. Background Technology

[0002] With the widespread adoption of mobile payment technology, QR code payment has become a common payment method in daily life. Users can generate their own payment codes through mobile applications for merchants to scan and complete payments, or use their phones to scan merchants' QR codes for payment. However, in some situations, users may be unable to generate or display their payment codes due to various reasons (such as account restrictions, application malfunctions, etc.), which can cause difficulties if they need to complete a payment urgently.

[0003] Traditional solutions might include using cash, bank cards, or other payment methods, but these methods are either inconvenient or rely on additional equipment or services. Therefore, a new solution is needed that can quickly and securely resolve the issue of not being able to generate payment codes without increasing the burden on users. Summary of the Invention

[0004] This application provides a payment code generation method, payment method, apparatus, storage medium, and device, which can generate a temporary payment code by a first terminal user with payment code payment capability and send the temporary payment code to a second terminal user for use, thereby realizing payment convenience.

[0005] On one hand, embodiments of this application provide a payment code generation method, the method comprising: responding to a temporary payment code generation request from a second terminal, displaying a temporary payment code confirmation page on a first terminal; wherein the generation request includes the identity information of the second terminal user and the requested amount; receiving confirmation generation information input by a first terminal user with payment code payment capability on the confirmation page, the confirmation generation information including the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user; generating the temporary payment code according to the confirmation generation information, and sending the temporary payment code to the second terminal so that the second terminal can use the temporary payment code, the temporary payment code containing a unique identifier and the payment authorization information.

[0006] On the other hand, embodiments of this application provide a payment method, the method comprising: obtaining a temporary payment code generation request input by a second terminal user, the generation request including the identity information of the second terminal user and the requested amount; sending the generation request to a first terminal, causing the first terminal to display a temporary payment code confirmation page in response to the generation request, and causing the first terminal to receive confirmation generation information input by the first terminal user with payment code payment capability on the confirmation page, and generating the temporary payment code according to the confirmation generation information; wherein, the confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user; the temporary payment code includes a unique identifier and the payment authorization information; obtaining the temporary payment code sent by the first terminal for the second terminal user to perform payment operations.

[0007] On the other hand, embodiments of this application provide a payment code generation method, the method comprising: obtaining confirmation generation information of a temporary payment code sent by a first terminal user with payment code payment capability through a first terminal, the confirmation generation information being generated by the first terminal based on a temporary payment code generation request from a second terminal user, the confirmation generation information including the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user; the generation request including the identity information of the second terminal user and the requested amount; generating the temporary payment code associated with the second terminal user based on the confirmation generation information, the temporary payment code including a unique identifier and the payment authorization information; and sending the temporary payment code to the first terminal, so that the first terminal can send the temporary payment code to the second terminal, so that the second terminal can use the temporary payment code.

[0008] On the other hand, embodiments of this application provide a payment code generation device, the device comprising:

[0009] The display unit is configured to respond to a temporary payment code generation request from the second terminal and display the temporary payment code confirmation page on the first terminal; wherein the generation request includes the identity information of the second terminal user and the requested amount;

[0010] The receiving unit is configured to receive confirmation generation information input by a first terminal user with payment code payment capability on the confirmation page. The confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user.

[0011] The processing unit is configured to generate the temporary payment code based on the confirmation generation information and send the temporary payment code to the second terminal so that the second terminal can use the temporary payment code, wherein the temporary payment code contains a unique identifier and the payment authorization information.

[0012] On the other hand, embodiments of this application provide a payment device, the device comprising:

[0013] The first acquisition unit is used to acquire a temporary payment code generation request input by the second terminal user, wherein the generation request includes the identity information of the second terminal user and the requested amount;

[0014] A sending unit is configured to send the generation request to a first terminal, so that the first terminal displays the temporary payment code confirmation page in response to the generation request, and the first terminal receives confirmation generation information entered by a first terminal user with payment code payment capability on the confirmation page, and generates the temporary payment code based on the confirmation generation information; wherein, the confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user; the temporary payment code includes a unique identifier and the payment authorization information;

[0015] The second acquisition unit is used to acquire the temporary payment code sent by the first terminal, so that the second terminal user can perform payment operations.

[0016] On the other hand, embodiments of this application provide a payment code generation device, the device comprising:

[0017] The third acquisition unit is used to acquire confirmation generation information of a temporary payment code sent by a first terminal user with payment code payment capability through the first terminal. The confirmation generation information is generated by the first terminal based on a generation request from a second terminal user. The confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user. The generation request includes the identity information of the second terminal user and the requested amount.

[0018] The generation unit is configured to generate a temporary payment code associated with the second terminal user based on the confirmation generation information, wherein the temporary payment code contains a unique identifier and the payment authorization information;

[0019] The issuing unit is used to issue the temporary payment code to the first terminal, so that the first terminal sends the temporary payment code to the second terminal, so that the second terminal can use the temporary payment code.

[0020] On the other hand, embodiments of this application provide a computer-readable storage medium storing a computer program adapted for loading by a processor to perform the methods described in any of the above embodiments.

[0021] On the other hand, embodiments of this application provide a computer device, the computer device including a processor and a memory, the memory storing a computer program, and the processor executing the method described in any of the above embodiments by calling the computer program stored in the memory.

[0022] On the other hand, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the methods described in any of the above embodiments.

[0023] This application embodiment responds to a temporary payment code generation request from a second terminal via a first terminal, displaying a temporary payment code confirmation page on the first terminal. The generation request includes the identity information of the second terminal user and the requested amount. The first terminal user, capable of using payment codes, receives confirmation information entered on the confirmation page. This confirmation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user. A temporary payment code is generated based on the confirmation information and sent to the second terminal, enabling the second terminal to use the temporary payment code. The temporary payment code contains a unique identifier and payment authorization information. This application embodiment expands the flexibility and applicability of payment methods by allowing a first terminal user capable of using payment codes to generate temporary payment codes for a second terminal user. It solves the problem that second terminal users cannot directly use payment codes due to technical or equipment limitations, simplifies the payment process, and improves payment convenience. The generated temporary payment code contains a unique identifier and payment authorization information, ensuring the authenticity, validity, and security of the payment. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the structure of the payment system provided in an embodiment of this application.

[0025] Figure 2 This is a flowchart illustrating the payment code generation method provided in an embodiment of this application.

[0026] Figure 3 This is a flowchart illustrating the payment method provided in an embodiment of this application.

[0027] Figure 4 This is another flowchart illustrating the payment code generation method provided in an embodiment of this application.

[0028] Figure 5This is a schematic diagram of the interaction process of the payment system provided in the embodiments of this application.

[0029] Figure 6 This is a schematic diagram of the payment code generation device provided in an embodiment of this application.

[0030] Figure 7 This is a schematic diagram of the payment device provided in an embodiment of this application.

[0031] Figure 8 Another schematic diagram of the payment code generation device provided in the embodiments of this application.

[0032] Figure 9 A schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0033] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0034] This application provides a payment code generation method, payment method, apparatus, storage medium, and device. Specifically, the payment code generation method and payment method of this application can be executed by a terminal device or a server. The computer device can be a terminal device or a server. The terminal device can be a smartphone, tablet, laptop, desktop computer, smart TV, smart speaker, wearable smart device, smart vehicle terminal, etc. The terminal device can also include a client, which can be a client of an application capable of making payments. For example, the client includes at least one of a program client and a web client. For example, the application can be a social application, a chatbot application, a customer service application, etc. For example, the application can also be other applications with chat functionality, such as reading, shopping, video, music, game, financial management, office, etc., applications with chat functionality. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0035] The embodiments of this application can be applied to various application scenarios such as payment and payment code generation.

[0036] Please refer to Figure 1 , Figure 1 This is a schematic diagram of the structure of a payment system provided in an embodiment of this application. The payment system includes a first terminal 10, a second terminal 20, a payment server 30, and a scanning device 40, etc. The first terminal 10 and the second terminal 20, the first terminal 10 and the payment server 30, the second terminal 20 and the payment server 30, and the payment server 30 and the scanning device 40 are connected via a network, such as a wired or wireless network.

[0037] Among them, the first terminal 10 is the terminal used by the first terminal user who has the ability to pay with payment code.

[0038] Among them, the second terminal 20 is the terminal used by a second terminal user who does not have the ability to pay with a payment code.

[0039] Among them, a second terminal user who does not have the ability to pay with a payment code can use the payment application configured in the second terminal 20 to generate a temporary payment code generation request, and then send the generation request to the first terminal 10 through the second terminal 20. The generation request includes the identity information of the second terminal user and the requested amount.

[0040] After receiving a generation request from the second terminal user, the first terminal 10 responds to the second terminal's temporary payment code generation request by displaying a temporary payment code confirmation page on the first terminal 10. The generation request includes the second terminal user's identity information and the requested amount. The first terminal 10 receives confirmation generation information entered by the first terminal user, who has payment code payment capabilities, on the confirmation page. The confirmation generation information includes the second terminal user's identity information, the first terminal user's identity information, and payment authorization information for use by the second terminal user. Then, the first terminal 10 sends the confirmation generation information to the payment server 30.

[0041] Payment server 30 obtains confirmation generation information of a temporary payment code sent by a first terminal user with payment code payment capability through the first terminal 10; based on the confirmation generation information, payment server 30 generates a temporary payment code associated with the second terminal user, the temporary payment code containing a unique identifier and payment authorization information; payment server 30 sends the temporary payment code to the first terminal 10.

[0042] The first terminal 10 sends the received temporary payment code to the second terminal 20, so that the second terminal user can show the temporary payment code to the scanning device 40 when making a payment.

[0043] After scanning the temporary payment code, the scanning device 40 generates a payment request and sends the payment request to the payment server 30. The payment request includes the payment request time, the amount to be paid, the unique identifier corresponding to the temporary payment code, and the payment authorization information.

[0044] When the payment server 30 determines that the payment request is valid based on the unique identifier and payment authorization information, it deducts the amount to be paid from the payment account of the first terminal user according to the amount to be paid in the payment request; the payment server 30 sends the deduction success information corresponding to the deduction processing back to the first terminal 10, the second terminal 20 and the scanning device 40.

[0045] The following sections provide detailed descriptions of each example. It should be noted that the order in which the embodiments are described is not intended to limit the priority of the embodiments.

[0046] It is understood that in the specific implementation of this application, data such as the identity information and basic profile information of the user (second terminal user or first terminal user) are involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0047] Please see Figure 2 , Figure 2 This is a flowchart illustrating the payment code generation method provided in an embodiment of this application. This method can be applied to... Figure 1 The first terminal 10 in the payment system shown. The method includes, but is not limited to, the following steps 110 to 130:

[0048] Step 110: In response to the temporary payment code generation request from the second terminal, the temporary payment code confirmation page is displayed on the first terminal; wherein, the generation request includes the identity information of the second terminal user and the requested amount;

[0049] Step 120: Receive confirmation generation information input by a first terminal user with payment code payment capability on the confirmation page. The confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user.

[0050] Step 130: Generate the temporary payment code based on the confirmation generation information, and send the temporary payment code to the second terminal so that the second terminal can use the temporary payment code. The temporary payment code contains a unique identifier and the payment authorization information.

[0051] In step 110, the first terminal 10 (such as a smartphone, tablet, or other device with payment functionality) first receives a request to generate a temporary payment code from a second terminal user (via the second terminal 20, such as another mobile phone) who does not have payment code payment capabilities. This request is sent from the second terminal 20 via a communication method (such as Bluetooth, Wi-Fi Direct, NFC, instant messaging applications, etc.) and includes the second terminal user's identity information (such as name, mobile phone number, account number, ID card number, or a specific user ID) and the requested amount. The second terminal user's identity information is encrypted or anonymized. Simultaneously, the second terminal user can also inform the first terminal user with payment code payment capabilities of the amount they need to pay through some means (such as face-to-face interaction, instant messaging software, etc.).

[0052] When the first terminal 10 receives the temporary payment code generation request, it displays a temporary payment code confirmation page. This confirmation page not only displays the requested amount but may also display a portion of the second terminal user's identity information (such as nickname and avatar, to comply with privacy policies), allowing the first terminal user to confirm whether they are willing to pay for the request. The confirmation page may also display an authorization information editing interface, where the first terminal user can input payment authorization information for use by the second terminal user.

[0053] In step 120, the first end user (i.e., a user with payment code payment capability) needs to enter confirmation generation information on the confirmation page. This information typically includes:

[0054] The identity information of the second end user: This can be partial or complete information, used to reconfirm the transaction partner.

[0055] The identity information of the first end user: This is usually automatically filled in and is used to verify the identity and permissions of the first end user.

[0056] Payment authorization information: This is the specific instruction from the first end user to agree to the payment, which may include the authorized amount, authorized payment method (such as balance, bank card, etc.), authorization validity period, authorized recipient, etc.

[0057] After confirming that all information is correct, the first end user will enter the corresponding confirmation information (such as password, biometric information, etc.) to complete the confirmation process.

[0058] A first terminal user with payment code payment capability operates on the first terminal 10, selecting the function to generate a temporary payment code, and inputting or confirming the identity information of a second terminal user and payment authorization information for the second terminal user's use (such as one or more of the following: authorized amount, authorization validity period, authorized recipient for the second terminal user, authorized usage count, authorized usage location range, etc.). Based on the second terminal user's identity information and requested amount in the generation request, together with the first terminal user's identity information (usually automatically obtained, such as the currently logged-in payment account information) and the payment authorization information confirmed by the first terminal user, a confirmation generation message is constituted. The first terminal 10 encapsulates this information into a complete confirmation generation message, ready to send it to the payment server 30.

[0059] In step 130, the system generates a temporary payment code based on the confirmation information entered by the first terminal user. This temporary payment code is unique and contains a unique identifier for the transaction and payment authorization information. The unique identifier ensures that each payment code is unique, thus preventing reuse or fraud. The payment authorization information includes one or more of the following: authorized amount, authorization validity period, authorized recipient for the second terminal user, authorized usage count, and authorized usage location range, ensuring that the second terminal 20 can correctly make the payment. Once the temporary payment code is generated, the first terminal 10 sends it to the second terminal 20. The second terminal user can use the temporary payment code to complete the payment within a specified time range. Because the payment code contains payment authorization information, the second terminal 20 does not need to re-enter complex payment information; it only needs to present the temporary payment code to the merchant or payment system to complete the payment process.

[0060] In some embodiments, the second end user is a user who does not have the ability to pay with a payment code.

[0061] For example, when a second end-user lacks the ability to use a payment code, they may not be able to directly generate or use their own payment code for payment. This could be due to various reasons, such as their device not supporting the relevant payment technology or their account not having payment code functionality enabled. Although the second end-user cannot generate their own payment code, they can still trigger the entire transaction process by sending a temporary payment code generation request to the first end-user.

[0062] In some embodiments, generating the temporary payment code based on the confirmation generation information and sending the temporary payment code to the second terminal includes:

[0063] The confirmation generation information is sent to the payment server, so that the payment server generates the temporary payment code associated with the second terminal user based on the confirmation generation information. The temporary payment code contains a unique identifier and the payment authorization information.

[0064] Obtain the temporary payment code issued by the payment server and send the temporary payment code to the second terminal so that the second terminal can use the temporary payment code to perform payment operations.

[0065] In step 130, the first terminal 10 sends the confirmation generation information of the temporary payment code to the payment server 30 via a network (such as the Internet, mobile communication network, etc.). During this process, the first terminal 10 can use secure communication protocols (such as HTTPS, TLS, etc.) to encrypt the transmitted data, preventing information from being stolen or tampered with during transmission. This confirmation generation information contains all the key information mentioned in step 120, ensuring that the payment server 30 can accurately understand the needs of the second terminal user and generate a suitable temporary payment code accordingly. Before sending the request, the first terminal 10 may perform some basic verification work, such as checking whether the network connection is stable and whether the payment account balance is sufficient, to ensure the smooth progress of subsequent processes.

[0066] Upon receiving the confirmation information, payment server 30 performs a series of security and validity verifications to ensure the authenticity and legality of the confirmation information. These verification steps may include verifying whether the identity information of the second terminal user and the first terminal user matches, whether the payment authorization information is valid, and whether the requested amount is within a reasonable range. Once payment server 30 successfully verifies the authenticity and legality of the confirmation information and successfully generates a temporary payment code associated with the second terminal user, payment server 30 will send the temporary payment code to the first terminal 10 via the network.

[0067] Then, the first terminal 10 receives a temporary payment code issued by the payment server 30. The temporary payment code is a QR code or encrypted string containing a unique identifier and payment authorization information, used to identify a specific payment transaction.

[0068] After receiving the temporary payment code, the first terminal 10 can save it locally or immediately display it on the user interface in an appropriate manner (such as directly displaying a QR code image) and prompt the first or second terminal user to proceed to the next step. Simultaneously, the first terminal 10 also provides the function of sending the temporary payment code to the second terminal 20. It can send the code to the second terminal 20 in some way (such as displaying a QR code, generating an encrypted link, etc.) so that the second terminal user can conveniently obtain the temporary payment code and perform payment operations through the second terminal 20. The sending method can be sending a screenshot via instant messaging software, direct transmission via Bluetooth or NFC technology, or generating an encrypted link for the second terminal user to access through a browser. Regardless of the method used, the security and privacy of the payment code during transmission must be ensured.

[0069] After sending the payment code, the first terminal 10 can record the operation log for this sending, for later query or auditing purposes. Simultaneously, the first terminal 10 can continuously monitor the payment result to provide timely feedback to both the first and second terminal users after the payment is completed.

[0070] After receiving the temporary payment code from the first terminal 10 via the second terminal 20, the second terminal user can display it to the scanning device 40 (such as a merchant's POS system, self-checkout machine, or the second terminal 20 itself) to make a payment. Upon scanning the temporary payment code, the scanning device 40 generates a payment request containing the payment request time, the amount to be paid, a unique identifier corresponding to the temporary payment code, and payment authorization information. The payment request is then sent to the payment server 30 for payment deduction processing.

[0071] During the payment process, the first terminal 10 is not only responsible for receiving the temporary payment code generation request from the second terminal user and generating confirmation information for the temporary payment code to send to the payment server, but also for receiving the temporary payment code issued by the payment server and sending it to the second terminal user, thereby facilitating payment interaction between the second terminal user and the first terminal user.

[0072] In some embodiments, receiving confirmation generation information input by a first terminal user with payment code payment capability on the confirmation page includes: obtaining payment authorization information input by the first terminal user based on the authorization information editing interface displayed on the confirmation page for use by a second terminal user, wherein the payment authorization information includes at least the authorization amount, the authorization validity period, and the authorization object for the second terminal user, and the authorization amount is greater than or equal to the requested amount;

[0073] The first terminal generates confirmation information for a temporary payment code based on the identity information of the second terminal user, the identity information of the first terminal user, and the payment authorization information.

[0074] For example, the first terminal 10 (such as a smartphone, tablet, or other device with mobile payment capabilities) executes the following process to generate confirmation information for the temporary payment code based on a temporary payment code generation request from a second terminal user (such as user B) who does not have the ability to pay with a payment code:

[0075] (1) Displaying the Authorization Information Editing Interface: When the first terminal 10 (the first terminal user, such as user A) receives a temporary payment code generation request sent by the second terminal user (such as user B) through the second terminal 20, the first terminal 10 will first display a temporary payment code confirmation page, on which the authorization information editing interface is displayed. This interface contains the necessary input fields and instructions to ensure that the first terminal user can accurately fill in the required information. This interface allows the first terminal user (user A) to customize and input a series of payment authorization information, which will be used to restrict and define the scope and conditions of use of the temporary payment code.

[0076] (2) Obtaining Payment Authorization Information: The first terminal user (User A) enters the required payment authorization information on the authorization information editing interface. This payment authorization information includes at least:

[0077] Authorized Amount: The maximum amount that the first terminal user is willing to authorize the second terminal user (User B) to use. This amount should be greater than or equal to the payment amount requested by the second terminal user.

[0078] Authorization validity period: The valid time range for the temporary payment code. After this time range, the temporary payment code will expire.

[0079] For authorized users of the second terminal: explicitly specify that the temporary payment code can only be used by a specific second terminal user (User B) to enhance security.

[0080] After obtaining this input information, the first terminal 10 stores it as payment authorization information.

[0081] (3) Generating Confirmation Information: After obtaining complete payment authorization information, the first terminal 10 combines the identity information of the second terminal user (such as user ID, mobile phone number, etc., which can be obtained in advance or entered on-site), the identity information of the first terminal user, and the payment authorization information to jointly constitute a confirmation information for a temporary payment code. This confirmation information will be sent to the payment server 30 so that a unique temporary payment code can be created and assigned to the second terminal user (user B) in the backend payment system.

[0082] Through the above process, the first terminal 10 not only meets the needs of second terminal users who lack payment code capabilities, but also ensures the flexibility and security of payments through the authorization information editing interface. Furthermore, by clearly specifying the authorized recipient and validity period, potential risks are further reduced.

[0083] In some embodiments, the payment authorization information may also include the number of authorized uses and / or the range of authorized use locations.

[0084] When the first terminal 10 receives a request from the second terminal user (such as user B) to obtain a temporary payment code, it will display a detailed authorization information editing interface. In addition to basic information such as the authorization amount, authorization validity period, and the authorized recipient for the second terminal user, this interface can also provide additional options, allowing the first terminal user (user A) to set the number of authorized uses and / or the authorized location range.

[0085] The first end user (User A) enters the required payment authorization information on the authorization information editing interface. This information includes, but is not limited to:

[0086] Authorization amount: The maximum amount that the first end user is willing to authorize for use by the second end user.

[0087] Authorization validity period: The valid time range for the temporary payment code.

[0088] Authorization target for the second terminal user: Specifies the user of the temporary payment code.

[0089] Authorized Usage Limits: Clearly limits the number of times this temporary payment code can be used. This helps prevent the abuse of temporary payment codes, especially in scenarios involving large sums of money or high security requirements.

[0090] Authorized Location Range: Defines the geographic locations or areas where the temporary payment code can be used. This can be achieved through GPS location, a specific merchant list, or other methods to improve payment security and accuracy.

[0091] After obtaining complete payment authorization information, including the number of authorized uses and / or the authorized location range, the first terminal 10 combines the identity information of the second terminal user, the identity information of the first terminal user, and this payment authorization information to form a detailed temporary payment code confirmation generation message. This confirmation generation message will be sent to the payment server 30, which will process this additional authorization information to ensure that all set conditions are met during the payment process.

[0092] By including payment authorization information such as the number of authorized uses and / or the authorized location range, the first end user can more precisely control the use of temporary payment codes, further improving payment security and efficiency. This can be applied to handling large transactions, restricting payment scope, or meeting payment needs in specific scenarios.

[0093] In some embodiments, the method further includes: obtaining payment success information corresponding to the payment processing returned by the payment server; wherein the payment processing is implemented by the payment server performing the following operations: the payment server obtains a payment request sent by the scanning device generated by scanning the temporary payment code, the payment request including payment request time, amount to be paid, the unique identifier corresponding to the temporary payment code, and payment authorization information; when the payment server determines that the payment request is valid based on the unique identifier and payment authorization information, it performs payment processing on the payment account corresponding to the first terminal user based on the amount to be paid in the payment request.

[0094] For example, after sending the temporary payment code, the first terminal 10 will continue to monitor feedback from the payment server 30. In particular, after the payment server 30 completes the deduction process, it will send a successful deduction message to the first terminal 10 and / or the second terminal 20.

[0095] After verifying the validity of the payment request and executing the deduction operation, the payment server 30 records the transaction information and generates a successful deduction message. This successful deduction message includes key transaction information, such as the deduction time, deduction amount, and transaction status. The payment server 30 then sends the successful deduction message to the first terminal via the network.

[0096] After receiving the successful deduction notification, the first terminal 10 will update its user interface to display the payment completion status and provide timely notification to the first terminal user. This helps improve the user experience, allowing the first terminal user to understand the transaction status in real time.

[0097] While the payment server 30 is primarily responsible for notifying the second terminal user (via the second terminal 20) of successful deductions, in some embodiments, the first terminal 10 may also selectively notify the second terminal user of the payment status. For example, when the first terminal 10 receives a successful deduction message, it can choose to send a notification that the payment has been completed to the second terminal user via instant messaging software, SMS, or other communication methods through the second terminal 20. This notification may include brief transaction information, such as the deduction amount and transaction time. Directly notifying the second terminal user of the payment status via the first terminal 10 further enhances the transparency and trustworthiness of the transaction. Simultaneously, this also facilitates communication between the first and second terminal users.

[0098] To facilitate subsequent inquiries and audits, the first terminal 10 can also record transaction logs. After sending the temporary payment code and receiving a successful deduction notification, the first terminal 10 records relevant transaction information in its local storage, such as transaction time, transaction amount, identity information of the second and first terminal users, and the unique identifier of the temporary payment code. Recording transaction logs helps the first terminal user review their transaction history at any time, ensuring the accuracy and security of transactions. Simultaneously, it provides strong evidentiary support for resolving potential disputes.

[0099] In the payment process, the first terminal 10 is not only responsible for generating and sending temporary payment codes, but also participates in key steps such as receiving successful deduction information, notifying the second terminal user of the payment status, and recording transaction logs, thereby ensuring the smooth progress of the entire payment process.

[0100] In some embodiments, before obtaining the deduction success information corresponding to the deduction processing fed back by the payment server, the method further includes: obtaining a deduction verification request sent by the payment server, the deduction verification request being used for the first terminal user to perform deduction verification; generating deduction verification information in response to the deduction verification request within a preset time period, and sending the deduction verification information to the payment server, so that the payment server performs deduction processing on the payment account corresponding to the first terminal user according to the deduction verification information and the amount to be paid in the payment request.

[0101] To ensure the safety of funds for the first end user and improve the payment experience during the payment process, the payment system adds a deduction verification step on the first terminal 10. This step occurs after the payment server 30 receives the payment request and performs preliminary verification, but before the actual deduction operation is executed.

[0102] First, the payment server 30 sends a deduction verification request to the first terminal 10. This request typically contains key information about the payment request, such as the merchant name, description of the goods or services, and the amount to be paid. This information is presented to the first terminal user in a clear and easy-to-understand manner so that the first terminal user can accurately understand the details of the upcoming transaction.

[0103] When the first terminal 10 receives a payment verification request, a verification interface or notification will immediately pop up, prompting the first terminal user to verify the payment. This interface or notification will display key information from the request and ask the first terminal user whether they agree to the payment. The first terminal user needs to respond to the payment verification request by authenticating their identity within a preset time period (e.g., a few seconds to a few minutes). Authentication methods may include various methods, such as entering a password, fingerprint verification, or facial recognition. The choice of these methods depends on the payment system's security policy and the first terminal user's personal preferences and settings. Once the first terminal user successfully authenticates, the first terminal 10 will generate a payment verification message. This message is an encrypted or algorithmically processed signal indicating that the first terminal user has agreed to the payment. The first terminal 10 will then send the payment verification message back to the payment server 30.

[0104] Upon receiving the payment verification information, payment server 30 will immediately verify it. If the verification is successful, confirming that the payment verification information is valid and originates from a legitimate first-end user, payment server 30 will execute the payment deduction operation. The deduction operation will deduct the corresponding amount from the payment account corresponding to the first-end user based on the amount to be paid in the payment request.

[0105] After successful deduction, the payment server 30 will generate a deduction success message and send it to the first terminal 10 via the network. Upon receiving the message, the first terminal 10 will immediately update the payment interface or pop up a notification to inform the user that the payment has been successfully completed.

[0106] This payment verification process not only enhances the security of the payment process and reduces the risk of unauthorized payments, but also improves the user experience through reasonable preset time periods and diverse identity verification methods. The end user can actively participate in the verification process, ensuring that every payment is made with their explicit consent, thereby effectively protecting the security of the payment process and the user's funds.

[0107] In the payment verification process, the first terminal 10 not only receives and displays the payment verification request, but also performs identity verification and generates payment verification information, which is then sent to the payment server 30 to complete the payment process. This process fully considers the security and convenience needs of the first terminal user, providing strong support for the efficient operation of the payment system.

[0108] In some embodiments, the method further includes: sending a modification request from the first terminal user to the payment server for the generated temporary payment code, so that the payment server updates the temporary payment code according to the modification request when it determines that the generated temporary payment code is not in use; obtaining the updated temporary payment code issued by the payment server, and sending the new temporary payment code to the second terminal.

[0109] To improve payment flexibility and security, the first-end user may need to modify the generated temporary payment code. For example, the first-end user may find that the original payment code's validity period is too short, or the payment limit does not meet the needs of the current transaction. For instance, the first-end user may initiate a request to modify the temporary payment code through the payment application or related interface on the first terminal 10, and input or select the modifications to be made, such as a new authorized amount, a new authorization validity period, or a new payment account. The first terminal 10 generates a modification request containing the modifications based on the user's input and sends the request to the payment server. This modification request must explicitly specify the temporary payment code identifier to be modified (such as the QR code number, payment account, etc.) and the new payment authorization information (such as a new authorized amount, a new authorization validity period, or a new authorized recipient, etc.).

[0110] The first terminal 10 sends a modification request to the payment server 30. Upon receiving the modification request, the payment server 30 first checks whether the specified temporary payment code has not yet been used. This is to avoid allowing modifications after a transaction has already occurred, which could lead to payment disputes or security issues. If the payment server 30 confirms that the temporary payment code is not used, it will update the temporary payment code according to the modifications in the modification request. Modifications may include adjusting the authorized amount, authorization validity period, associating a new payment account, and associating authorized objects. After completing the modifications, the payment server 30 sends the updated temporary payment code to the first terminal 10. This updated temporary payment code contains the latest payment terms and a unique identifier, ensuring the accuracy and security of the payment process.

[0111] After receiving the updated temporary payment code, the first terminal 10 needs to send it to the second terminal 20. For example, after receiving the updated temporary payment code, the first terminal 10 displays it to the first terminal user through a payment application or related interface. Simultaneously, a sending option is provided, allowing the first terminal user to send the payment code to other devices or platforms. After selecting the sending option, the first terminal user can choose to send the payment code to the second terminal 20 via various methods such as Bluetooth, Wi-Fi Direct, QR code sending, or social applications. The specific sending method depends on the hardware support of the first terminal 10 and the user's operating habits.

[0112] After receiving the payment code, the second terminal 20 can verify it to ensure its validity and accuracy. This typically includes checking the unique identifier of the payment code, payment terms, and whether it has expired. Once verification is successful, the second terminal 20 can begin the payment process.

[0113] The first terminal 10 can not only receive and respond to the deduction verification request from the payment server 30 during the payment process, but also proactively initiate a request to modify the temporary payment code, and send the updated payment code to the second terminal 20 after obtaining it. This process further enhances the flexibility and security of payments and improves the user experience.

[0114] In some embodiments, the method further includes: sending a cancellation request from the first terminal user to the payment server for the generated temporary payment code, so that the payment server, upon determining that the generated temporary payment code is not in use, cancels the temporary payment code according to the cancellation request; obtaining a cancellation notification of the temporary payment code issued by the payment server, and sending the cancellation notification to the second terminal.

[0115] To enhance the flexibility and security of the payment process, the first terminal 10 provides a function to cancel the generated temporary payment code. When a user of the first terminal decides not to use a generated temporary payment code (e.g., due to a change in payment plan, incorrect payee information, etc.), they can send a cancellation request to the payment server 30 through the first terminal 10.

[0116] For example, a first terminal user initiates a request to cancel a temporary payment code on the first terminal 10 through a payment application or related interface, and confirms the cancellation operation. Based on the user's action, the first terminal 10 generates a cancellation request and sends it to the payment server 30. The cancellation request should contain sufficient information to uniquely identify the temporary payment code to be cancelled.

[0117] After receiving the revocation request from the first terminal 10, the payment server 30 first verifies the validity of the request and checks whether the generated temporary payment code is in an unused state. For example, it queries the database to check the status of generated temporary payment codes to confirm whether they are unused. If the temporary payment code has been used, it cannot be revoked, and the corresponding error message is returned to the first terminal 10. If the verification passes and the temporary payment code is unused, the payment server 30 will perform the revocation operation, mark the temporary payment code as revoked, and record the reason and time of the revocation.

[0118] After the payment server 30 cancels the temporary payment code, it will send a cancellation notification to the first terminal 10 so that the first terminal user is aware of the result of the cancellation operation. For example, the payment server 30 generates a cancellation notification containing the cancellation result, which may include information such as cancellation success, cancellation failure, and the reason. Then, the cancellation notification is sent to the first terminal 10 to ensure that the first terminal user can receive feedback information about the cancellation operation in a timely manner.

[0119] After receiving the revocation notice, the first terminal 10 may choose to send the revocation notice to the second terminal 20 (the second terminal user terminal) or other relevant parties to ensure that the payee is also aware of the change in payment status.

[0120] The first terminal 10 can display the content of the cancellation notification on the payment application or related interface.

[0121] The first terminal 10 provides a sending function, allowing users to send revocation notifications to the second terminal 20 or other devices via various methods such as scanning a QR code, copying a link, sending an SMS, or sending it to social media. Sending revocation notifications helps avoid potential payment misunderstandings or disputes.

[0122] The first terminal 10 not only supports the generation and sending of temporary payment codes, but also allows for the revocation of these codes when necessary, ensuring the flexibility and security of the payment process. The revocation function is crucial for reducing payment errors and mitigating payment risks.

[0123] All of the above technical solutions can be combined in any way to form optional embodiments of this application, and will not be described in detail here.

[0124] This application embodiment responds to a temporary payment code generation request from a second terminal via a first terminal, displaying a temporary payment code confirmation page on the first terminal. The generation request includes the identity information of the second terminal user and the requested amount. The first terminal user, capable of using payment codes, receives confirmation information entered on the confirmation page. This confirmation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user. A temporary payment code is generated based on the confirmation information and sent to the second terminal, enabling the second terminal to use the temporary payment code. The temporary payment code contains a unique identifier and payment authorization information. This application embodiment expands the flexibility and applicability of payment methods by allowing a first terminal user capable of using payment codes to generate temporary payment codes for a second terminal user. It solves the problem that second terminal users cannot directly use payment codes due to technical or equipment limitations, simplifies the payment process, and improves payment convenience. The generated temporary payment code contains a unique identifier and payment authorization information, ensuring the authenticity, validity, and security of the payment.

[0125] Please see Figure 3 , Figure 3 This is a flowchart illustrating the payment method provided in an embodiment of this application. This method can be applied to... Figure 1 The second terminal 20 in the payment system shown. The method includes, but is not limited to, the following steps 210 to 230:

[0126] Step 210: Obtain the temporary payment code generation request input by the second terminal user, wherein the generation request includes the identity information of the second terminal user and the requested amount;

[0127] Step 220: Send the generation request to the first terminal, so that the first terminal displays the temporary payment code confirmation page in response to the generation request, and the first terminal receives confirmation generation information entered by the first terminal user with payment code payment capability on the confirmation page, and generates the temporary payment code according to the confirmation generation information; wherein, the confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user; the temporary payment code contains a unique identifier and the payment authorization information;

[0128] Step 230: Obtain the temporary payment code sent by the first terminal for the second terminal user to perform payment operations.

[0129] In step 210, the second terminal 20 serves as the starting point for the interaction between the second terminal user and the temporary payment code, and receives a temporary payment code generation request input by the second terminal user (such as user B) who does not have the ability to pay with a payment code.

[0130] The second terminal user generates a request by entering a temporary payment code on the second terminal 20 through a payment application, webpage, or other interface. The generated request must include the second terminal user's identity information (such as mobile phone number, ID card number, or account ID) and the requested amount.

[0131] The second terminal 20 can perform preliminary verification of the input identity information to ensure its accuracy and legality. This step may include comparing it with pre-stored information and sending a verification code for verification. After successful verification, the second terminal 20 can generate a request based on the input of the second terminal user. This request includes necessary information such as the second terminal user's identity information and the requested amount.

[0132] In step 220, after successful verification, the second terminal 20 sends a temporary payment code generation request to the first terminal 10 (such as the terminal of a first terminal user with payment code payment capability). In response to the generation request, the first terminal 10 displays a temporary payment code confirmation page and receives confirmation generation information entered by the first terminal user with payment code payment capability on the confirmation page. Based on this confirmation generation information, the first terminal 10 generates a temporary payment code associated with the second terminal user.

[0133] Specifically, the second terminal 20 sends a generation request to the first terminal 10 via a network (such as Wi-Fi or a mobile network). Upon receiving the generation request, the first terminal 10 parses the request content to obtain information such as the second terminal user's identity information and the requested amount. Then, in response to the generation request, the first terminal 10 displays a temporary payment code confirmation page and receives confirmation generation information entered by the first terminal user with payment code payment capabilities on the confirmation page. This confirmation generation information includes the second terminal user's identity information, the first terminal user's identity information, and payment authorization information. The first terminal 10 sends the confirmation generation information to the payment server 30. The payment server 30 verifies the identities of the first and second terminal users based on the content of the confirmation generation information and generates a temporary payment code. This temporary payment code contains a unique identifier and payment authorization information for subsequent payment operations. The payment server 30 then sends the generated temporary payment code to the first terminal 10. Upon receiving it, the first terminal 10 can perform further processing (such as saving or displaying).

[0134] In step 230, the first terminal 10 sends the received temporary payment code to the second terminal 20 so that the second terminal user (user B) can obtain the temporary payment code and perform the payment operation through the second terminal 20.

[0135] Specifically, the first terminal 10 displays a temporary payment code on its local device, which can be in the form of a QR code or other identifiable formats. The first terminal 10 provides a sending function, allowing users to send the temporary payment code to the second terminal 20 via various methods such as scanning the code, copying a link, or sending an SMS.

[0136] The second terminal 20 obtains the temporary payment code through a corresponding receiving method (such as scanning a QR code, receiving an SMS, etc.) and displays it to the second terminal user (user B). The second terminal user uses the temporary payment code to make a payment by scanning a QR code or other means.

[0137] This process ensures that temporary payment codes can be generated and used securely and conveniently between a second end-user who lacks payment code capabilities and a first end-user who does. It also improves the flexibility and security of payments.

[0138] In some embodiments, obtaining the temporary payment code generation request input by the second terminal user includes: displaying a request editing interface for the temporary payment code; obtaining the temporary payment code generation request input by the second terminal user based on the request editing interface, wherein the generation request includes the identity information of the second terminal user and the requested amount.

[0139] In order to collect input from second-terminal users (such as user B) who do not have the ability to pay with payment codes in a more intuitive and convenient way, the second terminal 2 will display a request editing interface specifically for temporary payment codes.

[0140] For example, the second terminal 20 will first display a clear and easy-to-use request editing interface on its user interface. This interface should include the necessary input boxes and prompts to guide the second terminal user to correctly input the relevant information.

[0141] For example, the input box is set as follows:

[0142] Identity Information Input Field: Provides one or more input fields for second-end users to enter their identity information. This information may include mobile phone number, ID card number, account ID, etc., depending on the system's verification requirements and privacy policy.

[0143] Request Amount Input Field: Provides a numeric input field, allowing a second end user to enter the amount they wish to pay. To improve user experience, you can add validation of the amount format to ensure that the entered amount is a valid value.

[0144] For example, clear prompts can be provided next to or below the input box to inform the second-end user of the content to be entered, the format requirements, and possible restrictions.

[0145] Then, the second end user, following the instructions on the request editing interface, fills in their identity information and the requested amount in the corresponding input boxes. After completing the input, some additional steps may be required (such as clicking the "Confirm" button) to submit the request.

[0146] For example, after the second terminal user submits input, the second terminal 20 can perform preliminary verification of the input data. This includes checking whether the identity information is complete and whether the requested amount is within a reasonable range. If the verification fails, a corresponding error message will be given, requiring the second terminal user to re-enter the information. After successful verification, the second terminal 20 will generate a formal request based on the second terminal user's input. This request includes key information such as the second terminal user's identity information and the requested amount, as well as other possible necessary parameters (such as the request timestamp and request source).

[0147] The generated request is stored in the local database or memory of the second terminal 20 and prepared to be sent to the first terminal 10 (such as the terminal of the first terminal user A with payment code payment capability). Depending on the specific implementation of the system, this sending process may be carried out immediately or only after certain conditions are met (such as user confirmation, network connection, etc.).

[0148] Through the above steps, the second terminal 20 can effectively obtain the temporary payment code generation request from the second terminal user who does not have the ability to pay with a payment code, providing the necessary information basis for the subsequent temporary payment code generation and sending process.

[0149] In some embodiments, the method further includes: displaying a candidate first terminal user list on the request editing interface, the candidate first terminal user list being used by the second terminal user to select a first terminal user matching the temporary payment code from the candidate first terminal user list; obtaining a temporary payment code generation request input by the second terminal user based on the request editing interface, the generation request including the identity information of the second terminal user, the requested amount, and the identity information of the first terminal user.

[0150] To enhance user experience and ensure payment flexibility, the second terminal 20 not only provides input options for identity information and requested amount on the request editing interface, but also displays a list of candidate first terminal users.

[0151] For example, when the request to edit the interface loads, the second terminal 20 will generate a candidate list of first terminal users based on the first terminal user data within the system. This candidate list of first terminal users may be automatically generated based on the second terminal user's historical transaction records, frequently used contacts, payment account binding relationships, etc.

[0152] For example, the list of candidate primary end users should include essential information for each candidate, such as name (or nickname), account ID, payment method identifier (e.g., Alipay, WeChat Pay), possible credit rating or recommendation level, level of intimacy, and frequency of interaction. This information can help secondary end users quickly understand and select suitable primary end users.

[0153] The list of candidate first-end users can be displayed on the request editing interface in the form of a drop-down list, scrolling list, or grid layout. To improve readability, there should be appropriate spacing and separators between list items, and key information should be highlighted (e.g., bold, highlight).

[0154] To improve selection efficiency, the second terminal 20 can also provide filtering and sorting functions. Second terminal users can filter and sort candidate first terminal users based on payment method, payment amount, credit rating, and other conditions to quickly find first terminal users that meet their needs.

[0155] After browsing the list of candidate primary users, the second end user can select one or more primary end users based on their needs and preferences. This is typically done by clicking a selection box or button next to a list item, or by performing other interactive actions.

[0156] After the first terminal user is selected, the second terminal will update its interface in real time, displaying the selected first terminal user information, and may include this first terminal user information in the generated request. Simultaneously, to ensure the accuracy of the selection, the second terminal 20 can also provide a confirmation prompt, requiring the second terminal user to confirm the selected first terminal user again.

[0157] After the second terminal user completes the selection by the first terminal user, the second terminal 20 will generate a final request based on the user's input and selection. This request includes not only the identity information of the second terminal user and the requested amount, but also the identity information of the selected first terminal user (such as account ID).

[0158] After generating the request, the second terminal 20 can perform necessary data verification to ensure the accuracy and completeness of all information. Once verification is successful, the second terminal 20 will send the request to the first terminal 10 (i.e., the selected first terminal user's terminal) to generate the corresponding temporary payment code.

[0159] Through the above steps, the second terminal 20 displays a list of candidate first terminal users on the request editing interface, which not only increases the user's freedom of choice but also ensures the accuracy and security of the payment. At the same time, this also provides a more comprehensive information foundation for the subsequent generation and sending of temporary payment codes.

[0160] In some embodiments, the method further includes: generating a list of candidate first terminal users based on the degree of intimacy between the second terminal user and the candidate first terminal user; or generating the list of candidate first terminal users based on the frequency of interaction between the second terminal user and the candidate first terminal user in a historical period.

[0161] In order to further enhance the user experience and payment convenience, the second terminal 20 will consider the specific relationship or interaction frequency between the second terminal users and the candidate first terminal users when generating the candidate first terminal user list.

[0162] For example, a candidate list of primary terminal users can be generated based on their level of intimacy. Intimacy can be calculated based on various factors, such as the number of historical transactions between the two parties, transaction amounts, communication records (e.g., SMS, voice calls, video calls), social media interactions (likes, comments, private messages), and user-defined groups or tags. The secondary terminal 20 will have a built-in algorithm that comprehensively evaluates the secondary terminal user and each candidate primary terminal user based on the above factors, deriving a numerical value or level representing the level of intimacy. This algorithm may employ weighted averages, machine learning models, or other complex data analysis methods. Then, based on the calculated level of intimacy, the secondary terminal 20 can sort the candidate primary terminal users in descending order (or descending order, depending on user needs) and generate the final candidate primary terminal user list. In this way, the secondary terminal user can see the primary terminal user with whom they have the closest relationship at the top of the list.

[0163] For example, a candidate first-terminal user list is generated based on interaction frequency. The second terminal 20 records the interaction frequency between the second terminal user and each candidate first-terminal user within a historical time period. This interaction includes, but is not limited to, any form of user-to-user interaction such as transactions, communication, and social media interactions. For example, the historical time period can be set according to actual needs, such as the most recent week, month, three months, or a longer time range. The selection of the time period should consider the characteristics of the payment scenario and user needs. Then, based on the recorded interaction frequency, the second terminal 20 can sort the candidate first-terminal users according to their interaction frequency from high to low (or from low to high) and generate a candidate first-terminal user list. In this way, the second terminal user can intuitively see the first-terminal users with whom they have recently interacted frequently in the list.

[0164] In practical applications, the second terminal 20 can generate a candidate list of first-terminal users by comprehensively considering both the degree of intimacy and the frequency of interaction. For example, it can first perform preliminary screening and sorting of candidate first-terminal users based on the degree of intimacy, and then further sort them based on the frequency of interaction among first-terminal users with the same degree of intimacy. This ensures both the accuracy and relevance of the list and improves the efficiency of user selection.

[0165] The candidate first-terminal user list generated through the above methods not only better meets the actual needs and preferences of second-terminal users, but also improves the convenience and security of payments to a certain extent. At the same time, this also provides payment platforms with more personalized services and optimization opportunities.

[0166] In some embodiments, the method further includes: displaying the temporary payment code to a scanning device, allowing the scanning device to scan the temporary payment code to generate a payment request, and sending the payment request to the payment server, wherein the payment request includes a payment request time, an amount to be paid, the unique identifier corresponding to the temporary payment code, and the payment authorization information; obtaining payment success information corresponding to the deduction processing fed back by the payment server; wherein the deduction processing is performed by the payment server deducting funds from the payment account corresponding to the first terminal user based on the amount to be paid in the payment request when the payment server determines that the payment request is valid according to the unique identifier and the payment authorization information.

[0167] The payment system includes not only a first terminal 10 (first terminal user), a second terminal 20 (second terminal user), and a payment server 30, but also a scanning device 40 (such as a POS machine, self-checkout terminal, or camera on a mobile device). In this payment system, the second terminal 20 plays a crucial role in the payment process, not only initiating the request to generate a temporary payment code, but also participating in the generation of the payment request and the feedback process for successful deduction.

[0168] For example, after successfully obtaining a temporary payment code (which may be sent via the first terminal 10 or directly issued by the payment server 30 to the second terminal 20), the second terminal 20 will display the temporary payment code on its user interface. This is usually a QR code or barcode containing all the necessary information for payment, such as a unique identifier and payment authorization information.

[0169] Then, the second end user (such as a consumer) or relevant operator will use the scanning device 40 to scan the temporary payment code displayed on the second terminal 20. The scanning function built into the scanning device 40 will read and parse the information in the QR code to generate a payment request containing the payment request time, the amount to be paid, the unique identifier corresponding to the temporary payment code, and payment authorization information.

[0170] After generating a payment request, the scanning device 40 sends the request to the payment server 30 via a network (such as Wi-Fi or mobile network). The payment server 30 is the core processing unit of the payment system, responsible for verifying the validity of the payment request and executing the deduction operation.

[0171] Upon receiving a payment request, payment server 30 verifies its validity based on the unique identifier and payment authorization information. If the verification is successful, payment server 30 deducts the amount from the payment account of the first terminal user according to the amount to be paid in the payment request. This process involves interaction with the bank or payment platform where the payment account is located. After successfully completing the deduction, payment server 30 generates a deduction success message and sends this message back to the second terminal 20. The feedback can be sent via SMS, push notification, or by updating the payment status on the second terminal.

[0172] After receiving the successful deduction information, the second terminal 20 will update its user interface to display the payment completion status and provide timely notification to the second terminal user.

[0173] The second terminal 20 acts as a bridge in the payment system, connecting the second terminal user, the scanning device 40, and the payment server 30. It not only simplifies the payment process and improves convenience but also ensures the security and accuracy of the payment process. Furthermore, by receiving feedback on successful deductions, the second terminal 20 can provide users with a more comprehensive payment experience and service.

[0174] In some embodiments, the method further includes: receiving expiration information of the temporary payment code after the scanning device scans the temporary payment code; regenerating a new generation request for the temporary payment code based on the expiration information; sending the new generation request for the temporary payment code to the first terminal, so that the first terminal displays a confirmation page for the temporary payment code in response to the new generation request, and the first terminal receives new confirmation generation information entered by a first terminal user with payment code payment capability on the confirmation page, and generates a new temporary payment code based on the new confirmation generation information; wherein the new confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user with payment code payment capability, and new payment authorization information for use by the second terminal user; the new temporary payment code includes a unique identifier and the new payment authorization information; and obtaining the new temporary payment code sent by the first terminal for the second terminal user to perform a payment operation.

[0175] In order to address the situation where temporary payment codes may become invalid due to various reasons (such as expiration, misuse, payment server failure, etc.), the payment system provides the function of regenerating temporary payment codes.

[0176] For example, when scanning device 40 attempts to scan a temporary payment code to generate a payment request, if payment server 30 detects that the payment code has expired (e.g., the payment code has expired, has been used, or the payment server cannot verify its validity), payment server 30 will send a temporary payment code expiration message to second terminal 20 (and / or scanning device 40).

[0177] After receiving the invalidation information, the second terminal 20 (and / or scanning device 40) will display the corresponding prompt information on its user interface, informing the user that the payment code has expired and the payment operation cannot be completed.

[0178] After seeing the notification that the payment code has expired, the second terminal user can choose to generate a new temporary payment code. To do this, the second terminal user may perform a series of operations through the second terminal 20 (such as a mobile application).

[0179] Based on the operation of the second terminal user, the second terminal 20 regenerates a new request for generating a temporary payment code. This request includes the second terminal user's identity information, the requested amount, and any other necessary information (such as the first terminal user's preferences, payment channel, etc.). Unlike the initial generation request, this new generation request may also include identifiers or parameters instructing the payment server 30 to generate a new payment code.

[0180] The second terminal 20 sends a new generation request to the first terminal 10. Upon receiving the new generation request, the first terminal 10 displays a temporary payment code confirmation page in response, and allows the first terminal to receive new confirmation generation information entered by the first terminal user with payment code payment capabilities on the confirmation page. This new confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user, and new payment authorization information for use by the second terminal user. Then, the first terminal sends this new confirmation generation information to the payment server 30.

[0181] After receiving the new confirmation information, payment server 30 verifies the information in the new confirmation information and regenerates a new temporary payment code based on this information. This new payment code contains a new unique identifier and new payment authorization information. After successful generation, payment server 30 issues the new temporary payment code to the first terminal 10 or the second terminal 20.

[0182] After receiving the new temporary payment code, the first terminal 10 will send it to the second terminal 20. This can be done in various ways, such as scanning the code, copying a link, or sending it via instant messaging software.

[0183] After receiving the new temporary payment code, the second terminal 20 will display the new temporary payment code on its user interface and prompt the second terminal user to perform a payment operation (such as scanning the payment code again). After the second terminal user follows the prompts, the scanning device will scan the new payment code and generate a new payment request, thus completing the payment process.

[0184] This process ensures that even if a temporary payment code expires for any reason, the second end-user can easily obtain a new payment code, thus guaranteeing a smooth payment process. This feature improves the flexibility of the payment system and the user experience.

[0185] All of the above technical solutions can be combined in any way to form optional embodiments of this application, and will not be described in detail here.

[0186] This application embodiment obtains a temporary payment code generation request input by a second terminal user via a second terminal. The generation request includes the second terminal user's identity information and the requested amount. The second terminal then sends the generation request to a first terminal, causing the first terminal to display a temporary payment code confirmation page in response. The first terminal receives confirmation information input by the first terminal user (who has payment code payment capabilities) on the confirmation page and generates a temporary payment code based on this information. The confirmation information includes the second terminal user's identity information, the first terminal user's identity information, and payment authorization information for the second terminal user's use. The temporary payment code contains a unique identifier and payment authorization information. The temporary payment code sent by the first terminal is then obtained for the second terminal user to perform payment operations. This application embodiment expands the flexibility and applicability of payment methods by allowing first terminal users with payment code payment capabilities to generate temporary payment codes for second terminal users. It solves the problem that second terminal users cannot directly use payment codes due to technical or equipment limitations, simplifies the payment process, and improves payment convenience. The generated temporary payment code contains a unique identifier and payment authorization information, ensuring the authenticity, validity, and security of the payment.

[0187] Please see Figure 4 , Figure 4 This is another flowchart illustrating the payment code generation method provided in an embodiment of this application. This method can be applied to... Figure 1 The payment server 30 in the payment system shown. The method includes, but is not limited to, the following steps 310 to 330:

[0188] Step 310: Obtain confirmation generation information of a temporary payment code sent by a first terminal user with payment code payment capability through the first terminal. The confirmation generation information is generated by the first terminal based on a temporary payment code generation request from a second terminal user. The confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user. The generation request includes the identity information of the second terminal user and the requested amount.

[0189] In step 310, the payment server 30, as the core processing unit of the entire payment process, is responsible for receiving and processing the temporary payment code confirmation generation information from the first terminal 10. This confirmation generation information is generated by the first terminal 10 based on a generation request previously received from the second terminal 20. The second terminal 20 is used by a second terminal user who does not have the ability to pay with a payment code. It sends a generation request to the first terminal 10 containing the second terminal user's identity information and the requested amount. This request indicates that the second terminal user wishes to generate a temporary payment code through the first terminal 10 (used by the first terminal user who has the ability to pay with a payment code) for subsequent payment operations. After receiving the generation request, the first terminal 10 combines its own identity information (i.e., the first terminal user's identity information) with the payment authorization information entered by the first terminal user (which may be the result of verification methods such as password, fingerprint, or facial recognition) to form a complete confirmation generation information, which is then sent to the payment server 30. Through this step, the payment server 30 indirectly receives dual information from both the second and first terminal users, ensuring the authenticity and security of the transaction.

[0190] Step 320: Based on the confirmation generation information, generate the temporary payment code associated with the second terminal user. The temporary payment code contains a unique identifier and the payment authorization information.

[0191] In step 320, after receiving the confirmation information, the payment server 30 performs a series of security and validity verifications. These verifications include, but are not limited to: checking whether the identity information of the second terminal user and the first terminal user matches, whether the payment authorization information is valid, and whether the requested amount is within a reasonable range. Once all verifications pass, the payment server 30 generates a temporary payment code closely associated with the second terminal user based on this information. This payment code is unique, containing a unique identifier for this transaction and payment authorization information for verifying payment permissions. This design ensures transaction security and facilitates subsequent payment verification processes.

[0192] Step 330: The temporary payment code is sent to the first terminal, so that the first terminal sends the temporary payment code to the second terminal, so that the second terminal can use the temporary payment code.

[0193] In step 330, after successfully generating the temporary payment code, the payment server 30 immediately sends the payment code to the first terminal 10. Upon receiving the payment code, the first terminal 10 sends it to the second terminal 20 in a secure and convenient manner (such as displaying a QR code or sending an encrypted link). This allows the second terminal user to view the temporary payment code on the second terminal 20 and display it to the scanning device 40 during payment. After scanning the payment code, the scanning device 40 generates a payment request containing the payment request time, the amount to be paid, a unique identifier corresponding to the temporary payment code, and payment authorization information, and sends this request to the payment server 30 for final payment processing. Through this step, the payment server 30 not only completes the generation and issuance of the temporary payment code but also indirectly facilitates payment interaction between the second and first terminal users, laying a solid foundation for subsequent payment verification and deduction processing.

[0194] In some embodiments, generating the temporary payment code associated with the second terminal user based on the confirmation generation information includes: obtaining the identity information of the second terminal user, the identity information of the first terminal user, and the payment authorization information based on the confirmation generation information, wherein the payment authorization information includes an authorization amount, an authorization validity period, and an authorization object for the second terminal user, and the authorization amount is greater than or equal to the requested amount; and generating the temporary payment code associated with the second terminal user based on the identity information of the second terminal user, the identity information of the first terminal user, and the payment authorization information.

[0195] For example, payment server 30 first receives confirmation information for a temporary payment code from first terminal 10. This confirmation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information. Payment server 30 parses this confirmation information and extracts necessary information for subsequent processing.

[0196] Then, the payment server 30 will verify the identity information.

[0197] For example, the payment server 30 will check whether the identity information provided by the second terminal user is valid, which may include the second terminal user's name, ID card number, mobile phone number, etc., and may confirm its authenticity by calling a third-party identity verification service.

[0198] At the same time, the payment server 30 also verifies the identity information of the first end user to ensure that they have the corresponding payment ability and credit status. This usually involves interaction with the bank or payment platform where the first end user's payment account is located.

[0199] Then, payment server 30 will carefully review the payment authorization information, specifically including:

[0200] Authorized Amount: Ensure that the authorized amount is greater than or equal to the requested amount to meet the payment needs of the second end user.

[0201] Authorization Validity Period: Set a reasonable time range within which a second-terminal user can use the temporary payment code to make payments. After the validity period expires, the payment code will become invalid to prevent misuse.

[0202] Authorized User: Specifies that this temporary payment code is only applicable to the second end user, preventing it from being used by other unauthorized third parties.

[0203] After verifying and reviewing all necessary information, payment server 30 begins generating a temporary payment code. This process typically involves the following steps:

[0204] Data Encryption: To ensure data security, the payment server 30 encrypts the identity information of the second terminal user, the identity information of the first terminal user, and the payment authorization information. The encrypted data will be used as part of the temporary payment code.

[0205] Generate a unique identifier: To ensure the uniqueness of each temporary payment code, the payment server 30 generates a unique identifier (such as a UUID). This identifier will serve as a core part of the temporary payment code for subsequent payment verification and tracking.

[0206] Constructing a temporary payment code: Payment server 30 combines encrypted data, a unique identifier, payment authorization information, and other potentially needed information (such as payment channel identifiers, discount codes, etc.) in a predetermined format to generate a temporary payment code associated with the second end user. This payment code can be presented in the form of a QR code, barcode, or string of numbers.

[0207] After generating a temporary payment code, the payment server 30 will send the temporary payment code to the first terminal 10. After receiving the temporary payment code, the first terminal 10 will send it to the second terminal 20 so that the second terminal user can show the temporary payment code to the scanning device 40 when making a payment.

[0208] Throughout the process, payment server 30 strictly adheres to relevant security standards and regulations to ensure the security, compliance, and traceability of the transaction process. Simultaneously, payment server 30 records detailed transaction logs for auditing and investigation when necessary.

[0209] In some embodiments, the method further includes: obtaining a payment request sent by the scanning device that is generated by scanning the temporary payment code, the payment request including a payment request time, an amount to be paid, the unique identifier corresponding to the temporary payment code, and the payment authorization information; when the payment request is determined to be valid based on the unique identifier and the payment authorization information, deducting funds from the payment account corresponding to the first terminal user based on the amount to be paid in the payment request; and feeding back the deduction success information corresponding to the deduction to the first terminal, the second terminal, and the scanning device.

[0210] In the further operation of the payment system, when the scanning device 40 (such as a POS machine, self-checkout terminal, or mobile payment device camera) scans the temporary payment code, a payment request is generated and sent to the payment server 30.

[0211] The scanning device 40 can read the information in the temporary payment code using its built-in scanning function (such as a QR code scanner). This information typically includes encrypted data, a unique identifier (such as a UUID), payment authorization information, and possibly other metadata. The scanning device 40 parses the data in the temporary payment code and generates a payment request accordingly. This payment request contains several key pieces of information, such as the payment request time (i.e., the specific time the request was scanned and sent), the amount to be paid (determined according to transaction requirements), the unique identifier corresponding to the temporary payment code (used to verify the validity of the payment code), and payment authorization information (such as the authorized amount, authorization validity period, etc.). Then, the scanning device 40 sends the generated payment request to the payment server 30 via the network for further processing.

[0212] Upon receiving a payment request, the payment server 30 first verifies the unique identifier and payment authorization information contained within it. This step aims to confirm whether the payment request was initiated by a valid temporary payment code, whether the amount to be paid in the payment request is within the authorized amount range, and whether the payment request is within the authorization validity period.

[0213] If the payment request is verified as valid, the payment server 30 will execute the deduction operation. This step involves deducting the amount to be paid from the payment account corresponding to the first end user. The payment server 30 will interact with the bank or payment platform where the first end user's account is located to ensure the successful execution of the deduction operation.

[0214] The payment server 30 records all relevant information for this transaction, including the payment request time, first terminal user information, second terminal user information, deduction amount, and transaction status. These records can be used for subsequent auditing, reconciliation, and other business operations.

[0215] The payment server 30 sends a notification of successful payment to the first terminal 10, allowing the user to track the payment status. This is typically achieved by sending a notification message, updating the payment page, or triggering a specific in-app prompt.

[0216] Although the payment request is not directly initiated by the second terminal user, the payment server 30 will also notify the second terminal 20 of the successful deduction, so that the second terminal user can confirm that the payment has been completed and receive the corresponding service or goods.

[0217] As the physical location or tool where the transaction takes place, the scanning device 40 also needs to receive feedback that the deduction was successful. This helps ensure the integrity of the transaction process and provides data support for subsequent transaction statistics, report generation, etc.

[0218] Through the above steps, the payment system can efficiently process payment requests initiated by scanning temporary payment codes, ensuring the security and timeliness of transactions. Simultaneously, through a timely information feedback mechanism, the first terminal user, the second terminal user, and the scanning device 40 can all promptly understand the transaction status, improving the user experience.

[0219] In some embodiments, determining the validity of a payment request based on the unique identifier and the payment authorization information includes: when the payment request time is within the authorization validity period, the amount to be paid is less than or equal to the authorized amount, and the unique identifier carried by the payment request matches the unique identifier contained in the temporary payment code in the payment server, the payment server determines that the payment request is valid.

[0220] This includes verifying whether the payment request time is within the authorization validity period.

[0221] The authorization validity period refers to the valid time period during which a temporary payment code is authorized for payment. Payment requests will only be accepted and processed within this period.

[0222] Payment server 30 checks the timestamp carried in the payment request (i.e., the time of the payment request) and compares it with the authorization validity period recorded in payment server 30 for the temporary payment code. If the payment request time is within the authorization validity period, the request is considered valid in terms of time.

[0223] This includes verifying whether the amount to be paid is less than or equal to the authorized amount.

[0224] The authorized amount refers to the maximum amount that a temporary payment code is authorized to be used for payment. The amount to be paid in a payment request should not exceed this limit.

[0225] Payment server 30 extracts the amount to be paid from the payment request and compares it with the authorized amount recorded in payment server 30 for the temporary payment code. If the amount to be paid is less than or equal to the authorized amount, the request is considered valid in terms of amount.

[0226] This involves verifying whether the unique identifier carried in the payment request matches the unique identifier contained in the temporary payment code on the payment server. The unique identifier is a unique identifier for the temporary payment code, used to ensure that the payment request was initiated by a valid payment code.

[0227] Payment server 30 extracts the unique identifier carried in the payment request and searches its database for the corresponding temporary payment code record. If a matching unique identifier is found, and the payment code is valid (e.g., unused, not expired, etc.), the request is considered valid in terms of identity.

[0228] If all three verification steps above are successful, the payment server 30 will comprehensively determine that the payment request is valid. This means that the payment request meets the requirements of the payment system in terms of time, amount, and identity, and can proceed with the subsequent deduction processing.

[0229] Once the payment request is deemed valid, the payment server 30 will execute the deduction operation, deducting the amount to be paid from the payment account corresponding to the first terminal user. After successful deduction, the payment server 30 will generate a deduction success message and send it to the first terminal 10 (first terminal user terminal), the second terminal 20 (second terminal user terminal), and the scanning device 40 respectively to notify the relevant parties of the payment result.

[0230] Through these rigorous verification steps, the payment system can ensure the authenticity and validity of payment requests, thereby protecting the funds and transaction order of both parties.

[0231] If any condition is not met, the payment server will reject the payment request and may return a corresponding error message to the first terminal 10 or the scanning device 40, explaining the reason for the rejection. This verification mechanism ensures the security and accuracy of the payment process and prevents unauthorized payment activities.

[0232] In some embodiments, before deducting funds from the payment account corresponding to the first terminal user based on the amount to be paid in the payment request, the method further includes: sending a deduction verification request to the first terminal, the deduction verification request being used for the first terminal user to perform deduction verification; and when obtaining the deduction verification information fed back by the first terminal in response to the deduction verification request within a preset time period, deducting funds from the payment account corresponding to the first terminal user based on the amount to be paid in the payment request.

[0233] To further enhance the security and user experience of the payment process, the payment system has added a deduction verification step before executing the transaction. This step aims to ensure that the first end user has clear awareness and consent to the upcoming deduction.

[0234] For example, after receiving a payment request and performing preliminary verification (such as payment request time, amount, unique identifier, etc.), the payment server 30 will send a deduction verification request to the first terminal (such as a smartphone, tablet, etc.) used by the first terminal user before actually deducting the payment from the payment account.

[0235] Payment verification requests typically include basic information about the payment request, such as the merchant name, product description, and amount to be paid, so that the end user understands the details of the upcoming transaction. The main purpose is to allow the end user to confirm whether they authorize the payment, preventing accidental or unauthorized payments.

[0236] After receiving a payment verification request, the first terminal user can respond through the payment application or related interface on the first terminal 10. The response method may include various identity verification methods such as entering a password, fingerprint verification, and facial recognition, depending on the security policy of the payment system and the user's settings.

[0237] The payment server 30 sets a preset time period (such as a few seconds to a few minutes) to wait for the first end user to provide verification information regarding the deduction. This time period gives the first end user enough time to complete the verification process while avoiding excessively long waiting times that could affect payment efficiency.

[0238] The payment verification message refers to the payment confirmation message sent by the first end-user to the payment server 30 after successful authentication. This is usually an encrypted signal or a signal processed by a specific algorithm, indicating that the first end-user agrees to make the payment.

[0239] Payment server 30 will only perform the deduction operation after successfully obtaining the deduction verification information from the first terminal 10 in response to the deduction verification request within a preset time period and verifying that the information is valid.

[0240] The payment server 30 will deduct the corresponding amount from the payment account of the first terminal user based on the amount to be paid in the payment request. After the deduction is successful, the payment server 30 will generate a deduction success message and notify the relevant parties (such as the first terminal 10 used by the first terminal user, the second terminal 20 used by the second terminal user, the scanning device 30, etc.).

[0241] By adding a verification step, the payment system can improve the security of the payment process and reduce the risk of unauthorized payments. At the same time, reasonable preset time periods and diverse identity verification methods also help improve the user experience, making the payment process more convenient and efficient. This verification process effectively safeguards the security of the payment process and the safety of users' funds by enhancing the active participation and identity verification of the first-end user.

[0242] In some embodiments, the method further includes: generating deduction failure information when no deduction verification information is received from the first terminal in response to the deduction verification request within a preset time period; and feeding back the deduction failure information to the first terminal, the second terminal, and the scanning device.

[0243] To ensure the integrity of the payment process and the continuity of the user experience, the payment server 30 pays special attention to whether it can successfully obtain payment verification information from the first terminal 10 within a preset time period when processing payment verification requests. If effective feedback is not obtained in a timely manner within this preset time period, the system will take a series of measures to properly handle the situation and send corresponding notifications to relevant parties.

[0244] For example, after issuing a deduction verification request, the payment server 30 starts a timer to monitor the end of a preset period. If the payment server 30 fails to receive any response from the first terminal 10 within the preset period, or if the received response is not as expected (such as verification failure, incomplete verification information, etc.), the deduction verification is considered to have timed out.

[0245] Once the payment verification timeout is confirmed, the payment server 30 will immediately generate a payment failure message. This message includes the reason for the transaction failure (such as verification timeout), the transaction identifier (such as order number, transaction time, etc.), and other necessary information so that relevant parties can understand the specific circumstances of the transaction failure.

[0246] For example, payment server 30 will send a payment failure message back to the first terminal 10, i.e., the device used by the first terminal user. In this way, the first terminal user can immediately know that the transaction has failed to be completed.

[0247] In some scenarios, a second terminal 20 may exist, which is used to display a temporary payment code, ready to perform a payment operation using the temporary payment code. The payment server 30 will also send a payment failure message to the second terminal 20 so that the second terminal user, who does not have the ability to pay with the payment code, can understand the transaction status and promptly request necessary assistance from the first terminal user.

[0248] For example, payment server 30 may also send a payment failure message to scanning device 40 so that scanning device 40 can rescan the temporary payment code to re-initiate the payment request.

[0249] In some embodiments, the method further includes: if the temporary payment code is a one-time payment code, the payment server marks the usage status of the temporary payment code as deactivated based on the successful deduction information; or if the temporary payment code is a non-one-time payment code, the payment server updates the remaining amount of the temporary payment code based on the successful deduction information, the remaining amount being used for the next payment; until the remaining amount is zero, the usage status of the temporary payment code is marked as deactivated.

[0250] Specifically, regarding the processing mechanism for temporary payment codes, the payment server 30 will perform different follow-up operations based on the type of the temporary payment code (one-time payment code or non-one-time payment code) to ensure the security and efficiency of the payment process.

[0251] A one-time payment code is a code that can only be used once. Once a payment is successfully deducted, the code becomes invalid and cannot be used again. When the payment server 30 receives a successful deduction notification from the payment channel, it first verifies that the notification corresponds to a transaction using a one-time payment code. Once the deduction is confirmed, the payment server 30 immediately marks the one-time payment code as "deactivated." This step prevents the temporary payment code from being maliciously reused, thereby ensuring the authenticity and security of the transaction.

[0252] For example, the payment server 30 will also record relevant logs of this change operation, including payment code information, transaction time, transaction amount, operation type (disabled), etc., for subsequent auditing and querying.

[0253] Non-one-time payment codes, such as prepayment codes or reusable codes, typically have a preset balance or a limit on the number of uses. Payment server 30 first confirms that the successful deduction corresponds to a non-one-time payment code transaction. After confirming successful deduction, payment server 30 deducts the corresponding amount from the current balance of the payment code based on the transaction amount and updates its remaining balance. This step ensures the real-time nature and accuracy of the payment code balance. This remaining amount will serve as the available balance for the next payment until the balance is completely depleted. As transactions proceed, payment server 30 continuously checks the remaining balance of the payment code. When the remaining balance drops to zero, payment server 30 automatically marks the payment code's usage status as "deactivated." This prevents payment failures due to insufficient balance and also avoids users unknowingly attempting to use invalid payment codes.

[0254] In some embodiments, the payment server 30 may also send a balance reminder notification to the user when the payment code balance is close to a preset threshold, so that the user can recharge or adjust the payment method in time.

[0255] For example, the payment server 30 also records all key operation logs during non-one-time payment code transactions, including top-up, deduction, balance update, and deactivation, to facilitate subsequent querying and auditing.

[0256] Through the above processing procedure, the payment server 30 can flexibly handle transactions of different types of temporary payment codes, which not only ensures the authenticity and security of the transaction, but also improves the user experience and payment efficiency.

[0257] In some embodiments, the method further includes: the payment server obtaining a modification request for the generated temporary payment code sent by the first terminal user through the first terminal; if the generated temporary payment code is not used, the payment server updates the temporary payment code according to the modification request; the payment server sends the updated temporary payment code to the first terminal, so that the first terminal sends the updated temporary payment code to the second terminal.

[0258] To improve payment flexibility and user experience, the payment server 30 supports the ability to modify generated temporary payment codes. This feature allows the first end user to adjust the relevant information of the payment code under specific conditions (such as when the temporary payment code has not yet been used).

[0259] For example, a first-terminal user initiates a request to modify the generated temporary payment code through their first-terminal 10 (such as a smartphone, tablet, smartwatch, etc.). This request may be triggered by the user clicking the "Modify Temporary Payment Code" button or selecting a similar option directly on the payment application interface.

[0260] The modification request includes the specific details to be changed, such as modifying the validity period of the payment code, the payment limit, and the encoding of the payment code itself (while maintaining certain rules or security). This information is entered or selected by the first terminal user and sent to the payment server 30 through the first terminal 10.

[0261] Upon receiving a modification request, payment server 30 first verifies the status of the temporary payment code, i.e., confirms whether the payment code has already been used. If the payment code has already been used for payment and the deduction was successful, payment server 30 will reject the modification request, because once the payment code has been used, its security and integrity cannot be modified.

[0262] If the payment code is not used, the payment server 30 will update the temporary payment code accordingly based on the specific content of the modification request. This may include updating the validity period of the payment code, the payment limit, or regenerating a new payment code (while maintaining some association with the original payment code for tracking and management).

[0263] During the modification process, the payment server 30 also performs a series of security checks to ensure that the modification operation does not introduce any security risks. For example, if the request includes a new payment code, the payment server 30 will verify whether the generation of the code complies with established security standards and rules.

[0264] Once the modification is complete and passes all necessary checks, the payment server 30 sends the updated temporary payment code information to the first terminal 10. This is typically achieved via network transmission (such as HTTP request / response) to ensure rapid and accurate information delivery.

[0265] After receiving the updated payment code, the first terminal 10 will display this change to the first terminal user through its user interface. Simultaneously, the first terminal user can choose to send the updated payment code to the second terminal 20. Sending methods can include QR code scanning, NFC contact, copying and pasting a link, and other formats.

[0266] Payment server 30 supports the modification of generated temporary payment codes, providing greater flexibility and convenience for end users. Through rigorous verification and security checks, this feature enhances user experience while ensuring the security and reliability of the payment process.

[0267] In some embodiments, the method further includes: obtaining a cancellation request sent by the first terminal user through the first terminal for the generated temporary payment code; if the generated temporary payment code is not used, canceling the temporary payment code according to the cancellation request; and sending a cancellation notification of the temporary payment code to the first terminal so that the first terminal sends the cancellation notification to the second terminal.

[0268] To ensure the flexibility and security of the payment process, the payment server 30 also provides the function of revoking the generated temporary payment code. This function allows the first terminal user to send a revocation request to the payment server 30 through the first terminal 10 under specific circumstances (such as when the payment code is no longer needed or there is a potential security risk) to cancel the validity of the payment code.

[0269] For example, a first-terminal user initiates a request to cancel a generated temporary payment code through their first-terminal 10 (such as a smartphone, tablet, smartwatch, etc.). This request may be triggered by the user clicking the "Cancel Temporary Payment Code" button or selecting a similar option directly on the payment application interface.

[0270] The revocation request typically includes a unique identifier for the temporary payment code that needs to be revoked, so that the payment server 30 can accurately identify and process the request. This information is part of the temporary payment code itself.

[0271] Upon receiving a reversal request, payment server 30 first verifies the status of the temporary payment code. Crucially, it confirms whether the payment code has already been used. If the payment code has been used for payment and the deduction was successful, payment server 30 may not be able to directly reverse it (because the transaction has already been completed). However, if the temporary payment code has not yet been used, payment server 30 will be able to continue processing the reversal request.

[0272] Once it is confirmed that the temporary payment code has not been used, the payment server 30 will mark the temporary payment code as "revoked" based on the information in the revocation request. This means that the temporary payment code will no longer be accepted in subsequent transactions, thereby ensuring the security and accuracy of the transaction.

[0273] The payment server 30 will record relevant information about the cancellation operation, including the cancellation time, the source of the cancellation request, and the identifier of the cancelled payment code, for subsequent auditing and tracking.

[0274] After the cancellation operation is completed, the payment server 30 will send a cancellation notification to the first terminal 10. This notification may include confirmation of successful cancellation, the identifier of the cancelled payment code, and other relevant information.

[0275] Upon receiving the revocation notification, the first terminal 10 will display this information to its user interface. The first terminal user can choose to send the revocation notification to the second terminal 20 so that relevant parties are aware that the payment code has been revoked. The sending method may include various forms such as QR code scanning, SMS notification, or instant messaging application messages, depending on the preferences of both the first and second terminal users and the available communication channels.

[0276] In some embodiments, the method further includes: when the temporary payment code expires based on the current time and the payment authorization information, invalidating the temporary payment code.

[0277] To enhance the security and controllability of the payment process, the payment server 30 monitors and manages the validity period of the temporary payment code. When certain conditions are met, such as the current time exceeding the validity period of the temporary payment code specified in the payment authorization information, the payment server 30 will automatically invalidate the payment code.

[0278] For example, when generating a temporary payment code, the payment server 30 sets an authorization validity period in the payment authorization information based on the request of the first end user or system rules. The authorization validity period can be a fixed time period (such as 5 minutes, 10 minutes, 1 day, etc.).

[0279] Payment server 30 maintains an accurate time system to ensure that all time-related operations are performed based on a unified time benchmark. This helps avoid errors in determining validity periods due to time discrepancies.

[0280] The payment server 30 periodically or in real-time checks the relationship between the current time and the authorization validity period of the temporary payment code specified in the payment authorization information. This is typically achieved by comparing the current time with the end time of the authorization validity period.

[0281] If the current time exceeds the authorization expiration date, the payment server 30 will determine that the temporary payment code has expired. At this point, the payment server 30 will no longer accept payment requests initiated using that temporary payment code to ensure the security and accuracy of the transaction.

[0282] Once the temporary payment code is confirmed to have expired, the payment server 30 will invalidate the payment code. This typically includes marking the payment code as "expired" or "invalid" and removing or archiving all sensitive information associated with the temporary payment code from the system to prevent its misuse or disclosure.

[0283] Payment server 30 may send a notification to the first end user informing them that the temporary payment code has expired and suggesting that they regenerate a new payment code. Simultaneously, payment server 30 will also record relevant information regarding the expiration process, including the expiration time, reason for expiration, and payment code identifier, for subsequent auditing and tracking.

[0284] By automatically invalidating expired temporary payment codes, payment server 30 can effectively prevent potential security risks, such as the payment codes being maliciously used or leaked.

[0285] For a better illustration of the payment system provided in the embodiments of this application, please refer to [link / reference]. Figure 5 The payment method provided in this application can be summarized into the following steps:

[0286] S1. A second terminal user who does not have the ability to pay with a payment code generates a temporary payment code request using the payment application configured in the second terminal; wherein, the generation request includes the identity information of the second terminal user and the requested amount.

[0287] S2. The second terminal sends the generation request to the first terminal.

[0288] S3. In response to the temporary payment code generation request from the second terminal, the first terminal displays a temporary payment code confirmation page on the first terminal and receives confirmation generation information entered by the first terminal user with payment code payment capability on the confirmation page. The confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user.

[0289] S4. The first terminal sends the confirmation information to the payment server.

[0290] S5. Based on the confirmation information, the payment server generates a temporary payment code associated with the second terminal user. The temporary payment code contains a unique identifier and payment authorization information.

[0291] S6. The payment server sends the temporary payment code to the first terminal.

[0292] S7. The first terminal sends the received temporary payment code to the second terminal.

[0293] S8. When the second terminal performs a payment operation, it displays the temporary payment code to the scanning device.

[0294] S9. After scanning the temporary payment code, the scanning device generates a payment request and sends the payment request to the payment server. The payment request includes the payment request time, the amount to be paid, the unique identifier corresponding to the temporary payment code, and the payment authorization information.

[0295] S10. The payment server determines whether the payment request is valid based on the unique identifier and payment authorization information.

[0296] S11. When the payment server determines that the payment request is valid, it sends a deduction verification request to the first terminal. The deduction verification request is used for the first terminal user to verify the deduction.

[0297] S12. The first terminal responds to the deduction verification request and sends deduction verification information to the payment server;

[0298] S13. When the payment server obtains the deduction verification information from the first terminal in response to the deduction verification request within a preset time period, it deducts the amount to be paid from the payment account corresponding to the first terminal user according to the amount to be paid in the payment request.

[0299] S14. The payment server sends the corresponding successful deduction information to the first terminal, the second terminal, and the scanning device.

[0300] The implementation methods of each step in the embodiments of this application can refer to the specific implementation methods of any of the above method embodiments, and will not be repeated here.

[0301] All of the above technical solutions can be combined in any way to form optional embodiments of this application, and will not be described in detail here.

[0302] This application embodiment obtains confirmation generation information of a temporary payment code sent by a first terminal user with payment code payment capability through a payment server. This confirmation generation information is generated by the first terminal based on a generation request from a second terminal user. The confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user. The generation request is a request for the generation of a temporary payment code sent by a second terminal user without payment code payment capability to the first terminal through the second terminal. The generation request includes the identity information of the second terminal user and the requested amount. Based on the confirmation generation information, a temporary payment code associated with the second terminal user is generated. The temporary payment code contains a unique identifier and payment authorization information. The temporary payment code is then sent to the first terminal, enabling the first terminal to send the temporary payment code to the second terminal user for payment operation. This application embodiment expands the flexibility and applicability of payment methods by allowing first terminal users with payment code payment capability to generate temporary payment codes for second terminal users. It solves the problem that second terminal users cannot directly use payment codes for payment due to technical or equipment limitations, simplifies the payment process, and improves payment convenience. The generated temporary payment code contains a unique identifier and payment authorization information, ensuring the authenticity, validity, and security of the payment.

[0303] To facilitate better implementation of the payment method of this application embodiment, this application embodiment also provides a payment device. Please refer to... Figure 6 , Figure 6 This is a first structural schematic diagram of a payment device provided in an embodiment of this application. The payment device 400 can be applied to... Figure 1 The first terminal 10 in the payment system shown may include the payment device 400, which may include:

[0304] Display unit 410 is configured to display a temporary payment code confirmation page on a first terminal in response to a temporary payment code generation request from a second terminal; wherein the generation request includes the identity information of the second terminal user and the requested amount;

[0305] The receiving unit 420 is used to receive confirmation generation information entered by a first terminal user with payment code payment capability on the confirmation page. The confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user.

[0306] Processing unit 430 is configured to generate the temporary payment code based on the confirmation generation information and send the temporary payment code to the second terminal so that the second terminal can use the temporary payment code, wherein the temporary payment code contains a unique identifier and the payment authorization information.

[0307] In some embodiments, the receiving unit 420 may be configured to: obtain payment authorization information for use by the second terminal user, which is input by the first terminal user based on the authorization information editing interface displayed on the confirmation page; the payment authorization information includes at least the authorization amount, the authorization validity period, and the authorization object for the second terminal user; and the authorization amount is greater than or equal to the requested amount; and generate confirmation generation information for a temporary payment code based on the identity information of the second terminal user, the identity information of the first terminal user, and the payment authorization information.

[0308] In some embodiments, the payment authorization information may also include the number of authorized uses and / or the range of authorized use locations.

[0309] In some embodiments, the processing unit 430 may be configured to: send the confirmation generation information to a payment server, so that the payment server generates a temporary payment code associated with the second terminal user based on the confirmation generation information, the temporary payment code containing a unique identifier and the payment authorization information; obtain the temporary payment code issued by the payment server, and send the temporary payment code to the second terminal, so that the second terminal can use the temporary payment code to perform a payment operation.

[0310] In some embodiments, the processing unit 430 can also be used to: obtain payment success information corresponding to the payment processing returned by the payment server; wherein the payment processing is implemented by the payment server performing the following operations: the payment server obtains a payment request sent by the scanning device generated by scanning the temporary payment code, the payment request including the payment request time, the amount to be paid, the unique identifier corresponding to the temporary payment code, and the payment authorization information; when the payment server determines that the payment request is valid based on the unique identifier and the payment authorization information, it performs payment processing on the payment account corresponding to the first terminal user based on the amount to be paid in the payment request.

[0311] In some embodiments, before obtaining the deduction success information corresponding to the deduction processing returned by the payment server, the processing unit 430 may further be used to: obtain a deduction verification request sent by the payment server, the deduction verification request being used for the first terminal user to perform deduction verification; generate deduction verification information in response to the deduction verification request within a preset time period, and send the deduction verification information to the payment server, so that the payment server performs deduction processing on the payment account corresponding to the first terminal user according to the deduction verification information and the amount to be paid in the payment request.

[0312] In some embodiments, the processing unit 430 may further be used to: send a modification request from the first terminal user to the payment server for the generated temporary payment code, so that the payment server updates the temporary payment code according to the modification request when it determines that the generated temporary payment code is not in use; obtain the updated temporary payment code issued by the payment server, and send the new temporary payment code to the second terminal.

[0313] In some embodiments, the processing unit 430 may further be used to: send a cancellation request from the first terminal user to the payment server for the generated temporary payment code, so that the payment server, when determining that the generated temporary payment code is not used, cancels the temporary payment code according to the cancellation request; obtain a cancellation notification of the temporary payment code issued by the payment server, and send the cancellation notification to the second terminal.

[0314] In some embodiments, the second end user is a user who does not have the ability to pay with a payment code.

[0315] Please see Figure 7 , Figure 7 This is a schematic diagram of a second structure of a payment device provided in an embodiment of this application. The payment device 500 can be applied to... Figure 1The second terminal 20 in the payment system shown may include the payment device 500, which may include:

[0316] The first acquisition unit 510 is used to acquire a temporary payment code generation request input by the second terminal user, wherein the generation request includes the identity information of the second terminal user and the requested amount;

[0317] The sending unit 520 is configured to send the generation request to the first terminal, so that the first terminal displays the temporary payment code confirmation page in response to the generation request, and the first terminal receives confirmation generation information entered by the first terminal user with payment code payment capability on the confirmation page, and generates the temporary payment code according to the confirmation generation information; wherein, the confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user; the temporary payment code includes a unique identifier and the payment authorization information;

[0318] The second acquisition unit 530 is used to acquire the temporary payment code sent by the first terminal, so that the second terminal user can perform payment operations.

[0319] In some embodiments, the first acquisition unit 510 may be used to: display a request editing interface for a temporary payment code; acquire a temporary payment code generation request input by the second terminal user based on the request editing interface, wherein the generation request includes the identity information of the second terminal user and the requested amount.

[0320] In some embodiments, the first acquisition unit 510 may further be used to: display a candidate first terminal user list on the request editing interface, the candidate first terminal user list being used for the second terminal user to select a first terminal user matching the temporary payment code from the candidate first terminal user list; and acquire a temporary payment code generation request input by the second terminal user based on the request editing interface, the generation request including the identity information of the second terminal user, the requested amount, and the identity information of the first terminal user.

[0321] In some embodiments, the first acquisition unit 510 may also be used to: generate the candidate first terminal user list based on the intimacy between the second terminal user and the candidate first terminal user; or generate the candidate first terminal user list based on the interaction frequency between the second terminal user and the candidate first terminal user in a historical period.

[0322] In some embodiments, the payment device 500 can also be used to: display the temporary payment code to a scanning device, so that the scanning device can scan the temporary payment code to generate a payment request, and send the payment request to the payment server, wherein the payment request includes a payment request time, an amount to be paid, the unique identifier corresponding to the temporary payment code, and the payment authorization information; the second terminal obtains the deduction success information corresponding to the deduction processing fed back by the payment server; wherein the deduction processing is performed by the payment server deducting funds from the payment account corresponding to the first terminal user based on the amount to be paid in the payment request when the payment server determines that the payment request is valid based on the unique identifier and the payment authorization information.

[0323] In some embodiments, the payment device 500 can also be used to: receive expiration information of the temporary payment code after the scanning device scans the temporary payment code; regenerate a new generation request for the temporary payment code based on the expiration information; send the new generation request for the temporary payment code to the first terminal, so that the first terminal displays a confirmation page for the temporary payment code in response to the new generation request, and the first terminal receives new confirmation generation information entered by a first terminal user with payment code payment capability on the confirmation page, and generates a new temporary payment code based on the new confirmation generation information; wherein the new confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user with payment code payment capability, and new payment authorization information for use by the second terminal user; the new temporary payment code contains a unique identifier and the new payment authorization information; and obtain the new temporary payment code sent by the first terminal for the second terminal user to perform payment operations.

[0324] Please see Figure 8 , Figure 8 This is a schematic diagram of a third structure of a payment device provided in an embodiment of this application. The payment device 600 can be applied to... Figure 1 The payment server 30 in the payment system shown may include the payment device 600, which may include:

[0325] The third acquisition unit 610 is used to acquire confirmation generation information of a temporary payment code sent by a first terminal user with payment code payment capability through the first terminal. The confirmation generation information is generated by the first terminal based on a generation request from a second terminal user. The confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user. The generation request includes the identity information of the second terminal user and the requested amount.

[0326] The generation unit 620 is configured to generate a temporary payment code associated with the second terminal user based on the confirmation generation information, wherein the temporary payment code includes a unique identifier and the payment authorization information;

[0327] The issuing unit 630 is used to issue the temporary payment code to the first terminal, so that the first terminal can send the temporary payment code to the second terminal for the second terminal user to perform payment operations.

[0328] In some embodiments, the second generation unit 620 may be used to: obtain the identity information of the second terminal user, the identity information of the first terminal user, and the payment authorization information according to the confirmation generation information, wherein the payment authorization information includes an authorization amount, an authorization validity period, and an authorization object for the second terminal user, and the authorization amount is greater than or equal to the requested amount; and generate the temporary payment code associated with the second terminal user according to the identity information of the second terminal user, the identity information of the first terminal user, and the payment authorization information.

[0329] In some embodiments, the payment device 600 is further configured to: acquire a payment request sent by a scanning device that is generated by scanning the temporary payment code, the payment request including a payment request time, an amount to be paid, the unique identifier corresponding to the temporary payment code, and the payment authorization information; when the payment request is determined to be valid based on the unique identifier and the payment authorization information, deduct funds from the payment account corresponding to the first terminal user based on the amount to be paid in the payment request; and send the deduction success information corresponding to the deduction process back to the first terminal, the second terminal, and the scanning device.

[0330] In some embodiments, when the payment device 600 determines that the payment request is valid based on the unique identifier and the payment authorization information, it may be used to: determine that the payment request is valid when the payment request time is within the authorization validity period, the amount to be paid is less than or equal to the authorized amount, and the unique identifier carried by the payment request matches the unique identifier contained in the temporary payment code in the payment server.

[0331] In some embodiments, before deducting funds from the payment account corresponding to the first terminal user according to the amount to be paid in the payment request, the payment device 600 may also be used to: send a deduction verification request to the first terminal, the deduction verification request being used for the first terminal user to perform deduction verification; and when obtaining the deduction verification information fed back by the first terminal in response to the deduction verification request within a preset time period, deducting funds from the payment account corresponding to the first terminal user according to the amount to be paid in the payment request.

[0332] In some embodiments, the payment device 600 can also be used to: generate deduction failure information when no deduction verification information is received from the first terminal in response to the deduction verification request within a preset time period; and send the deduction failure information back to the first terminal, the second terminal and the scanning device.

[0333] In some embodiments, the payment device 600 can also be used to: if the temporary payment code is a one-time payment code, mark the usage status of the temporary payment code as deactivated based on the successful deduction information; or if the temporary payment code is a non-one-time payment code, update the remaining amount of the temporary payment code based on the successful deduction information, the remaining amount being used for the next payment; until the remaining amount is zero, mark the usage status of the temporary payment code as deactivated.

[0334] In some embodiments, the payment device 600 may further be used to: obtain a modification request for the generated temporary payment code sent by the first terminal user through the first terminal; if the generated temporary payment code is not used, update the temporary payment code according to the modification request; and send the updated temporary payment code to the first terminal so that the first terminal sends the updated temporary payment code to the second terminal.

[0335] In some embodiments, the payment device 600 may also be used to: obtain a cancellation request sent by the first terminal user through the first terminal for the generated temporary payment code; if the generated temporary payment code is not used, cancel the temporary payment code according to the cancellation request; and send a cancellation notification of the temporary payment code to the first terminal so that the first terminal sends the cancellation notification to the second terminal.

[0336] In some embodiments, the payment device 600 can also be used to: invalidate the temporary payment code when it is determined that the temporary payment code has expired based on the current time and the payment authorization information.

[0337] Payment device 400, payment device 500 or payment device 600 may be integrated into a terminal device or server that has storage and a processor and thus computing power, or the payment device 400, payment device 500 or payment device 600 may be the terminal device or server.

[0338] In some embodiments, this application also provides a computer device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0339] In some embodiments, such as Figure 9 As shown, Figure 9 This is another schematic diagram of the structure of a computer device provided in an embodiment of this application. The computer device 700 further includes a processor 701 with one or more processing cores, a memory 702 with one or more computer-readable storage media, and a computer program stored on the memory 702 and executable on the processor. The processor 701 and the memory 702 are electrically connected. Those skilled in the art will understand that the computer device structure shown in the figures does not constitute a limitation on the computer device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0340] The processor 701 is the control center of the computer device 700. It connects various parts of the computer device 700 through various interfaces and lines. By running or loading software programs and / or modules stored in the memory 702, and calling data stored in the memory 702, it performs various functions of the computer device 700 and processes data, thereby monitoring the computer device 700 as a whole.

[0341] Optionally, the computer device 700 can be a first terminal, and the processor 701 can call software programs and modules stored in the memory 702 to perform the following operations:

[0342] In response to a temporary payment code generation request from a second terminal, a temporary payment code confirmation page is displayed on a first terminal; wherein the generation request includes the identity information of the second terminal user and the requested amount; confirmation generation information is received from the first terminal user, who has payment code payment capability, inputting on the confirmation page, the confirmation generation information including the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user; the temporary payment code is generated based on the confirmation generation information and sent to the second terminal so that the second terminal can use the temporary payment code, the temporary payment code containing a unique identifier and the payment authorization information.

[0343] Optionally, the computer device 700 can be a second terminal, and the processor 701 can call software programs and modules stored in the memory 702 to perform the following operations:

[0344] The system retrieves a temporary payment code generation request input by a second terminal user, the request including the second terminal user's identity information and the requested amount; sends the generation request to a first terminal, causing the first terminal to display a temporary payment code confirmation page in response to the request, and receiving confirmation generation information input by the first terminal user with payment code payment capability on the confirmation page, and generating the temporary payment code based on the confirmation generation information; wherein the confirmation generation information includes the second terminal user's identity information, the first terminal user's identity information, and payment authorization information for use by the second terminal user; the temporary payment code includes a unique identifier and the payment authorization information; and retrieves the temporary payment code sent by the first terminal for the second terminal user to perform a payment operation.

[0345] Optionally, the computer device 700 can be a payment server, and the processor 701 can call software programs and modules stored in the memory 702 to perform the following operations:

[0346] The system obtains confirmation generation information for a temporary payment code sent by a first terminal user with payment code payment capability via a first terminal. This confirmation generation information is generated by the first terminal based on a temporary payment code generation request from a second terminal user. The confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user. The generation request includes the identity information of the second terminal user and the requested amount. Based on the confirmation generation information, a temporary payment code associated with the second terminal user is generated. This temporary payment code contains a unique identifier and the payment authorization information. The temporary payment code is then sent to the first terminal, enabling the first terminal to send the temporary payment code to the second terminal, allowing the second terminal to use the temporary payment code.

[0347] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0348] In some embodiments, such as Figure 9 As shown, the computer device 700 further includes: a display unit 703, a radio frequency circuit 704, an audio circuit 705, an input unit 706, and a power supply 707. The processor 701 is electrically connected to the display unit 703, the radio frequency circuit 704, the audio circuit 705, the input unit 706, and the power supply 707. Those skilled in the art will understand that... Figure 9 The computer device structure shown does not constitute a limitation on the computer device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0349] Display unit 703 can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of computer devices. These graphical user interfaces can be composed of graphics, text, icons, video, and any combination thereof. Display unit 703 may include a display panel and a touch panel.

[0350] The radio frequency circuit 704 can be used to transmit and receive radio frequency signals to establish wireless communication with network devices or other computer devices, and to transmit and receive signals with network devices or other computer devices.

[0351] Audio circuitry 705 can be used to provide an audio interface between a user and a computer device via a speaker and a microphone. Audio circuitry 705 converts received audio data into electrical signals, transmits them to the speaker, and the speaker converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by audio circuitry 705, converted back into audio data, and then processed by processor 701 before being transmitted via radio frequency circuitry 704 to, for example, another computer device, or output to memory for further processing. Audio circuitry 705 may also include an earphone jack to facilitate communication between peripheral headphones and computer devices.

[0352] The input unit 706 can be used to receive input numbers, character information or object feature information (such as fingerprints, iris, facial information, etc.), and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0353] Power supply 707 is used to supply power to the various components of computer device 700.

[0354] although Figure 9 As not shown in the diagram, the computer device 700 may also include a camera, sensors, a wireless fidelity module, a Bluetooth module, etc., which will not be described in detail here.

[0355] In some embodiments, this application also provides a computer-readable storage medium for storing a computer program. This computer-readable storage medium can be applied to a terminal device or a server, and the computer program causes the terminal device or server to execute the corresponding processes in the methods of the embodiments of this application; for brevity, further details are omitted here.

[0356] In some embodiments, this application also provides a computer program product comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the corresponding processes in the methods of the embodiments of this application. For brevity, these details are not elaborated here.

[0357] This application also provides a computer program, which includes a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the corresponding processes in the methods of the embodiments of this application. For the sake of brevity, these will not be elaborated further here.

[0358] It should be understood that the processor in the embodiments of this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0359] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0360] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0361] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0362] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for generating a payment code, characterized in that, The method includes: In response to a temporary payment code generation request from a second terminal, a temporary payment code confirmation page is displayed on a first terminal; wherein the generation request includes the identity information of the second terminal user and the requested amount; The system receives confirmation generation information input by a first terminal user with payment code payment capability on the confirmation page. The confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user. The temporary payment code is generated based on the confirmation information and sent to the second terminal so that the second terminal can use the temporary payment code, which contains a unique identifier and the payment authorization information.

2. The payment code generation method as described in claim 1, characterized in that, The confirmation generation information received by the first terminal user with payment code payment capability on the confirmation page includes: The payment authorization information input by the first terminal user based on the authorization information editing interface displayed on the confirmation page is used by the second terminal user. The payment authorization information includes at least the authorization amount, the authorization validity period, and the authorization object for the second terminal user. The authorization amount is greater than or equal to the requested amount. Confirmation information for generating a temporary payment code is generated based on the identity information of the second terminal user, the identity information of the first terminal user, and the payment authorization information.

3. The payment code generation method as described in claim 2, characterized in that, The payment authorization information also includes the number of authorized uses and / or the authorized location range.

4. The payment code generation method as described in claim 1, characterized in that, The step of generating the temporary payment code based on the confirmation information and sending the temporary payment code to the second terminal includes: The confirmation generation information is sent to the payment server, so that the payment server generates a temporary payment code associated with the second terminal user based on the confirmation generation information. The temporary payment code contains a unique identifier and the payment authorization information. Obtain the temporary payment code issued by the payment server and send the temporary payment code to the second terminal so that the second terminal can use the temporary payment code to perform payment operations.

5. The payment code generation method as described in claim 4, characterized in that, The method further includes: Obtain the payment success information corresponding to the payment processing returned by the payment server; The deduction process is implemented by the payment server performing the following operations: the payment server obtains a payment request sent by the scanning device, generated by scanning the temporary payment code. The payment request includes the payment request time, the amount to be paid, the unique identifier corresponding to the temporary payment code, and the payment authorization information. When the payment server determines that the payment request is valid based on the unique identifier and the payment authorization information, it deducts the amount to be paid from the payment account corresponding to the first terminal user based on the amount to be paid in the payment request.

6. The payment code generation method as described in claim 5, characterized in that, Before obtaining the successful deduction information corresponding to the deduction processing returned by the payment server, the method further includes: Obtain the deduction verification request sent by the payment server, which is used by the first terminal user to verify the deduction. Within a preset time period, in response to the deduction verification request, deduction verification information is generated and sent to the payment server, so that the payment server can deduct the amount from the payment account corresponding to the first terminal user based on the deduction verification information and the amount to be paid in the payment request.

7. The payment code generation method according to any one of claims 1-6, characterized in that, The method further includes: The first terminal user sends a modification request for the generated temporary payment code to the payment server, so that the payment server updates the temporary payment code according to the modification request when it determines that the generated temporary payment code is not in use; Obtain the updated temporary payment code issued by the payment server and send the updated temporary payment code to the second terminal.

8. The payment code generation method according to any one of claims 1-6, characterized in that, The method further includes: Send a cancellation request from the first terminal user for the generated temporary payment code to the payment server, so that the payment server can cancel the temporary payment code according to the cancellation request when it determines that the generated temporary payment code is not used; Obtain the cancellation notification of the temporary payment code issued by the payment server, and send the cancellation notification to the second terminal.

9. The payment code generation method as described in claim 1, characterized in that, The second terminal user is a user who does not have the ability to pay with a payment code.

10. A payment method, characterized in that, The method includes: Obtain a temporary payment code generation request input by a second terminal user, wherein the generation request includes the identity information of the second terminal user and the requested amount; The generation request is sent to the first terminal, causing the first terminal to display the temporary payment code confirmation page in response to the generation request. The first terminal then receives confirmation generation information input by a first terminal user with payment code payment capabilities on the confirmation page, and generates the temporary payment code based on the confirmation generation information. The confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user. The temporary payment code contains a unique identifier and the payment authorization information. The temporary payment code sent by the first terminal is obtained so that the second terminal user can perform a payment operation.

11. The payment method as described in claim 10, characterized in that, Obtain the temporary payment code generation request input by the second terminal user, including: Displays the request editing interface for temporary payment codes; Obtain the temporary payment code generation request input by the second terminal user based on the request editing interface. The generation request includes the identity information of the second terminal user and the requested amount.

12. The payment method as described in claim 10, characterized in that, The method further includes: The request editing interface displays a list of candidate first terminal users, which is used by the second terminal user to select a first terminal user that matches the temporary payment code from the list of candidate first terminal users. The system obtains a temporary payment code generation request from the second terminal user based on the request editing interface. The generation request includes the identity information of the second terminal user, the requested amount, and the identity information of the first terminal user.

13. The payment method as described in claim 12, characterized in that, The method further includes: The candidate first terminal user list is generated based on the closeness between the second terminal user and the candidate first terminal user; or The candidate first terminal user list is generated based on the interaction frequency between the second terminal user and the candidate first terminal user within a historical period.

14. The payment method as described in claim 10, characterized in that, The method further includes: The temporary payment code is displayed to the scanning device so that the scanning device can scan the temporary payment code to generate a payment request and send the payment request to the payment server. The payment request includes the payment request time, the amount to be paid, the unique identifier corresponding to the temporary payment code, and the payment authorization information. Obtain the payment success information corresponding to the payment processing returned by the payment server; The deduction process involves the payment server determining the validity of the payment request based on the unique identifier and the payment authorization information, and then deducting the amount to be paid from the payment account corresponding to the first terminal user according to the amount to be paid in the payment request.

15. The payment method as described in claim 14, characterized in that, The method further includes: After the scanning device scans the temporary payment code, it receives a message indicating that the temporary payment code has expired. Based on the failure information, a new generation request for the temporary payment code is regenerated; A new generation request for the temporary payment code is sent to the first terminal, causing the first terminal to display a temporary payment code confirmation page in response to the new generation request. The first terminal then receives new confirmation generation information entered by a first terminal user with payment code payment capabilities on the confirmation page, and generates a new temporary payment code based on the new confirmation generation information. The new confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user with payment code payment capabilities, and new payment authorization information for use by the second terminal user. The new temporary payment code contains a unique identifier and the new payment authorization information. The new temporary payment code sent by the first terminal is obtained so that the second terminal user can perform payment operations.

16. A method for generating a payment code, characterized in that, The method includes: The system obtains confirmation generation information for a temporary payment code sent by a first terminal user with payment code payment capability via the first terminal. The confirmation generation information is generated by the first terminal based on a temporary payment code generation request from a second terminal user. The confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user. The generation request includes the identity information of the second terminal user and the requested amount. Based on the confirmation information, a temporary payment code associated with the second terminal user is generated, the temporary payment code containing a unique identifier and the payment authorization information; The temporary payment code is sent to the first terminal, so that the first terminal sends the temporary payment code to the second terminal, so that the second terminal can use the temporary payment code.

17. The payment code generation method as described in claim 16, characterized in that, The method further includes; The system obtains a payment request sent by the scanning device, generated by scanning the temporary payment code. The payment request includes the payment request time, the amount to be paid, the unique identifier corresponding to the temporary payment code, and the payment authorization information. When the payment request is determined to be valid based on the unique identifier and the payment authorization information, the payment account corresponding to the first terminal user is deducted according to the amount to be paid in the payment request. The successful deduction information corresponding to the deduction process is fed back to the first terminal, the second terminal, and the scanning device.

18. A payment code generation device, characterized in that, The device includes: The display unit is configured to respond to a temporary payment code generation request from the second terminal and display the temporary payment code confirmation page on the first terminal; wherein the generation request includes the identity information of the second terminal user and the requested amount; The receiving unit is configured to receive confirmation generation information input by a first terminal user with payment code payment capability on the confirmation page. The confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user. The processing unit is configured to generate the temporary payment code based on the confirmation generation information and send the temporary payment code to the second terminal so that the second terminal can use the temporary payment code, wherein the temporary payment code contains a unique identifier and the payment authorization information.

19. A payment device, characterized in that, The device includes: The first acquisition unit is used to acquire a temporary payment code generation request input by the second terminal user, wherein the generation request includes the identity information of the second terminal user and the requested amount; A sending unit is configured to send the generation request to a first terminal, so that the first terminal displays the temporary payment code confirmation page in response to the generation request, and the first terminal receives confirmation generation information entered by a first terminal user with payment code payment capability on the confirmation page, and generates the temporary payment code based on the confirmation generation information; wherein, the confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user; the temporary payment code includes a unique identifier and the payment authorization information; The second acquisition unit is used to acquire the temporary payment code sent by the first terminal, so that the second terminal user can perform payment operations.

20. A payment code generation device, characterized in that, The device includes: The third acquisition unit is used to acquire confirmation generation information of a temporary payment code sent by a first terminal user with payment code payment capability through the first terminal. The confirmation generation information is generated by the first terminal based on a generation request from a second terminal user. The confirmation generation information includes the identity information of the second terminal user, the identity information of the first terminal user, and payment authorization information for use by the second terminal user. The generation request includes the identity information of the second terminal user and the requested amount. The generation unit is configured to generate a temporary payment code associated with the second terminal user based on the confirmation generation information, wherein the temporary payment code contains a unique identifier and the payment authorization information; The issuing unit is used to issue the temporary payment code to the first terminal, so that the first terminal sends the temporary payment code to the second terminal, so that the second terminal can use the temporary payment code.

21. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted for loading by a processor to perform the method as described in any one of claims 1-17.

22. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program, and the processor executing the method according to any one of claims 1-17 by calling the computer program stored in the memory.

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

Images