A payment method, apparatus, device and medium

Abstract

The embodiment of the specification discloses a payment method, device, equipment and medium. The scheme comprises: obtaining payment link information provided by a near field communication device through a near field communication mode; based on the payment link information, starting a payment application in the user terminal; based on the started payment application, generating payment identification information by using pre-stored seed information; the seed information is information that has been stored in the user terminal locally before the user terminal obtains the payment link information; and sending the payment identification information to the near field communication device, so that the near field communication device triggers a payment process based on the payment identification information.

Description

[0001] This application claims priority to Chinese patent application No. 202510829141.2, filed on June 19, 2025, entitled "A Payment Method, Apparatus, Device and Medium". Technical Field

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

[0003] As offline consumption increasingly replaces cash payments with digital payments, various digital payment capabilities are constantly evolving and upgrading. For example, "tap-to-pay," facial recognition, and palm print payment methods are emerging. Among these, "tap-to-pay," with its advantages of zero barriers to entry, no prior preparation, and no information input, is gradually expanding in the market. It allows users to pay with a simple tap, providing a more comfortable and convenient payment experience than scanning a QR code. However, in offline payment scenarios, factors such as signal fluctuations may cause users to be in a state of no or weak network connection, affecting payment success rates and the overall payment experience.

[0004] Therefore, ensuring the success rate of user payments is a technical problem that urgently needs to be solved. Summary of the Invention

[0005] This specification provides a payment method, apparatus, device, and medium to improve payment success rate.

[0006] This specification provides a payment method applied to a user terminal, comprising: obtaining payment link information provided by a near-field communication device via near-field communication; launching a payment application on the user terminal based on the payment link information; generating payment identification information using pre-stored seed information based on the launched payment application; the seed information being information already stored locally on the user terminal before the user terminal obtained the payment link information; the payment identification information including identification information representing the user's payment account; and sending the payment identification information to the near-field communication device so that the near-field communication device triggers the execution of a payment process based on the payment identification information.

[0007] This specification provides a payment method applied to a near-field communication device, comprising: sending payment link information to a user terminal via near-field communication, so that the user terminal generates payment identifier information using locally pre-stored seed information; the payment identifier information includes account identifier information representing the user's payment account; acquiring the payment identifier information sent by the user terminal; and triggering the execution of a payment process based on the payment identifier information.

[0008] This specification provides a payment method applied to a server, comprising: obtaining a payment process trigger request, wherein the payment process trigger request is triggered after a near-field communication device obtains payment identification information provided by a user terminal; the payment identification information is generated by the user terminal based on seed information pre-stored locally on the user terminal; and executing a payment process based on the payment process trigger request to process the transaction of the user terminal.

[0009] This specification provides an embodiment of a payment device, comprising: an information acquisition module for acquiring payment link information provided by a near-field communication device via near-field communication; an application launch module for launching a payment application in the device based on the payment link information; an identifier generation module for generating payment identifier information based on the launched payment application using pre-stored seed information; the seed information being information already stored locally in the device before the device acquires the payment link information; the payment identifier information including identifier information representing a user's payment account; and an identifier sending module for sending the payment identifier information to the near-field communication device, so that the near-field communication device triggers the execution of a payment process based on the payment identifier information.

[0010] This specification provides a payment device comprising: an information sending module for sending payment link information to a user terminal via near-field communication, so that the user terminal generates payment identifier information using locally pre-stored seed information; the payment identifier information including account identifier information representing a user's payment account; an identifier acquisition module for acquiring the payment identifier information sent by the user terminal; and a process triggering module for triggering the execution of a payment process based on the payment identifier information.

[0011] This specification provides an embodiment of a payment device, comprising: a request acquisition module, configured to acquire a payment process trigger request, wherein the payment process trigger request is triggered after a near-field communication device acquires payment identification information provided by a user terminal; the payment identification information is generated by the user terminal based on seed information pre-stored locally on the user terminal; and a process execution module, configured to execute a payment process based on the payment process trigger request, and process the transaction of the user terminal.

[0012] This specification provides an embodiment of a payment device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform at least one of the above-described payment methods.

[0013] This specification provides an embodiment of a computer-readable medium storing computer-readable instructions that can be executed by a processor to implement at least one of the above-described payment methods.

[0014] At least one embodiment of this specification achieves the following beneficial effects: The user terminal can pre-store seed information for generating payment identification information locally. When payment is required, the user terminal can generate payment identification information for processing the payment transaction based on the pre-stored seed information and provide it to the near-field communication device (NFC), enabling the NFC to trigger the payment process based on the acquired payment identification information. By generating payment identification information from the pre-stored seed information locally, even in a network-free or weak network environment, the user terminal can still obtain payment identification information for payment and provide it to the NFC to trigger the payment process, thereby effectively ensuring payment success rate and improving user experience. Attached Figure Description

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

[0016] Figure 1 This is a schematic diagram illustrating an application scenario of a payment method provided in the embodiments of this specification; Figure 2 A flowchart illustrating a payment method provided in an embodiment of this specification; Figure 3 A flowchart illustrating a payment method provided in an embodiment of this specification; Figure 4 A flowchart illustrating a payment method provided in an embodiment of this specification; Figure 5 Swimlane diagram of a payment method provided in the embodiments of this specification; Figure 6 The embodiments provided in this specification correspond to Figure 2 A schematic diagram of the structure of a payment device; Figure 7 The embodiments provided in this specification correspond to Figure 3 A schematic diagram of the structure of a payment device; Figure 8 The embodiments provided in this specification correspond to Figure 4 A schematic diagram of the structure of a payment device; Figure 9This is a schematic diagram of the structure of a payment device provided in an embodiment of this specification. Detailed Implementation

[0017] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

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

[0019] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

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

[0021] To clearly illustrate the implementation methods of the various embodiments in this specification, some terms are explained below.

[0022] Digital payments refer to transactions made electronically. This includes making payments using mobile devices, computers, or other electronic devices instead of cash or traditional bank transfers.

[0023] Near Field Communication (NFC) is a short-range wireless communication technology that allows devices to exchange data in very close proximity (typically within 4 centimeters). NFC technology is based on Radio Frequency Identification (RFID) technology and can provide various functions such as data transmission, communication, and near-field payment.

[0024] NFC technology mainly includes three communication modes: Reader / Writer Mode, Card Emulation Mode, and Peer-to-Peer Mode.

[0025] Reader / Writer Mode is a working mode. In this mode, NFC devices can read or write information to NFC tags or devices containing NFC tags. For example, in a payment scenario, a mobile phone can be in Reader / Writer Mode to obtain payment information from the payment device for payment, or it can write information obtained or generated by the phone to the tag-side device. A device in this mode can be called a card reader device, capable of reading or writing information back to the tag-side device.

[0026] In Card Emulation Mode, an NFC device can emulate a smart card, allowing it to be used as a payment card, access card, or other type of card. The device can interact with existing contactless infrastructure, such as POS machines or access control systems. For example, a mobile phone can be used as a bank card for payments in stores; as an access card in offices or residences; or as a transit card for public transportation. Devices in this mode can be referred to as slave devices.

[0027] In Peer-to-Peer Mode, two NFC-enabled devices can exchange data. Both devices must be active and capable of sending and receiving data. This mode is primarily used for file transfer, social networking, and interactive games. Examples include quickly pairing Bluetooth or Wi-Fi connections via NFC to transfer files or photos; exchanging business cards, contact information, or social media links by tapping two phones; and swapping characters or sharing items in multiplayer games.

[0028] An NFC tag is a small electronic chip with a built-in antenna that enables short-range communication with NFC-enabled devices, such as smartphones, via radio waves. These tags are typically very thin and can be embedded in various items, such as posters, business cards, product packaging, and devices.

[0029] In some embodiments, the NFC tag can also be software, such as a device in card emulation mode. When the NFC tag is software, it can be installed in a physical card or terminal device. It can be implemented as multiple software programs or software modules (e.g., to provide distributed service authentication services) or as a single software program or software module.

[0030] Currently, there are two main types of payment solutions based on near-field communication (NFC). One involves the user terminal acting as a smart card or NFC tag. For example, the user terminal (such as a mobile phone) is in card emulation mode, and the merchant device (such as a POS terminal) acts as a card reader, reading information from the user terminal to complete the transaction. The other involves the user terminal acting as a card reader, and the merchant acting as a smart card or NFC tag. After reading the tag information provided by the merchant, the user terminal requests the server to send information representing the user terminal to the merchant. The merchant then executes the transaction process; for example, the POS terminal sends a payment request to the server, which processes the transaction between the merchant and the user. In this second type of NFC-based payment solution, before the server processes the transaction, the user terminal needs to request information representing the user terminal, such as a payment code, from the server and send it to the merchant. Only then can the merchant submit a processing request to the server. This can lead to payment failure if the user terminal is offline or has a weak network connection, as the user terminal may be unable to request the payment code from the server, preventing the merchant from initiating the payment.

[0031] To improve payment success rate and enhance user experience, this solution provides the following implementation examples: Figure 1 This is a schematic diagram illustrating an application scenario of a payment method provided in an embodiment of this specification. For example... Figure 1As shown, this solution may include a user terminal 1, a near-field communication (NFC) device 2, a cash register 3, and a server 4. The user terminal 1 can be in NFC reader mode, sending a NFC trigger signal. The NFC device 2 may contain an NFC tag or be in card emulation mode, also known as a tap-to-pay device. When the user terminal 1 and the NFC device 2 are close together, for example, when the user touches or approaches the NFC device, the NFC device 2 can respond to the NFC trigger signal from the user terminal 1. The user terminal can then read tag information from the NFC device 2. This tag information may contain payment link information or other forms or content of information. Taking payment link information as an example, this payment link information can be used to trigger the user terminal 1 to execute a payment. After obtaining the payment link information, the user terminal 1 can launch a payment application. Based on the launched payment application, it uses pre-stored seed information on the user terminal 1 to generate payment identification information containing the user's payment account. This payment identification information can be recognized by the NFC device or the cash register, triggering the payment process. For example, the payment identification information can have the same format as the payment code number, such as a string starting with "28". User terminal 1 provides the locally generated payment identification information to near-field communication device 2, which in turn provides the payment identification information to cash register device 3, thereby triggering cash register device 3 to execute the payment process. For example, cash register device 3 can send a payment processing request to server 4 based on the payment identification information to request the server to process the transaction between cash register device 3 and user terminal 1.

[0032] For example, the payment identification information generated locally by the user terminal may be generated using some information in the payment link information. After generating the payment identification information, the user terminal may write the information to the near-field communication device, or it may provide at least some information in the payment link and the payment identification information to the near-field communication device through short-range communication (such as NFC, Bluetooth, etc.).

[0033] Alternatively, after obtaining the payment link information, the user terminal can execute a program to generate a payment identifier. The generation logic may or may not use the content in the payment link information, depending on the generation logic. This is not limited here.

[0034] For example, some merchant devices (POS devices) need to obtain user-related information in order to trigger the payment process normally. In order to facilitate the payment process, the user terminal can send user information (such as user ID) and generated payment identification information to the POS device through a near-field communication device, or the POS device can obtain user information from the server, or the near-field communication device can obtain user information from the server and then send it to the POS device.

[0035] In the embodiments of this specification, before the user terminal 1 interacts with the near-field communication device 2, the user terminal 1 can pre-store seed information for generating payment identification information. The user terminal 1 can use the seed information to generate payment identification information locally without requesting it from the server. In this way, even if the user terminal 1 is in an environment without network or with weak network when it needs to make a payment, the user terminal can still obtain payment identification information and trigger the payment process, thereby improving the payment success rate.

[0036] In some embodiments, user terminal 1 can be one or more of a smartphone, laptop, tablet, IoT device, portable wearable device, or immersive image display device. Specifically, IoT device can be one or more of a smart speaker, smart TV, smart air conditioner, or smart in-vehicle device. Portable wearable device can be one or more of a smartwatch, smart bracelet, or head-mounted device. Immersive image display device includes, but is not limited to, augmented reality (AR) device, virtual reality (VR) device, etc.

[0037] The near-field communication device 2 can be a device with near-field communication functionality or a device with an NFC tag. It can be a standalone electronic device or a component integrated into other devices. For example, it can be an electronic device fixed to or movable and placed at the checkout counter, such as a manual checkout device or a self-checkout device, which can be connected to the near-field communication device via wired or wireless means. Alternatively, the near-field communication device can be a component located within the checkout device, integrated with it; for example, the near-field communication device can be a component within a manual checkout device or a self-checkout device.

[0038] The cash register device 3 can be a device capable of processing transactions, or a device with cash register functions, such as a cash register, POS machine, self-service checkout device, smart vending machine, etc.

[0039] In some embodiments, the near-field communication device 2 and the POS device 3 can be connected via wired or wireless means, or a binding or corresponding relationship can be established between the near-field communication device and the POS device, all of which can associate the near-field communication device 2 and the POS device 3. From a hardware perspective, the near-field communication device 2 and the POS device 3 can be two independent devices or an integrated device; no specific limitation is made here. The near-field communication device 2 can be provided to the merchant by a service provider other than the merchant, or it can be the merchant's own device; no limitation is made here either.

[0040] Near Field Communication (NFC) devices can be devices with NFC functionality associated with POS devices. They can function as auxiliary devices to help the cashier complete transactions; they can also be called auxiliary payment devices or auxiliary transaction devices. This allows merchants who previously did not support NFC-based transactions to also conduct transactions via NFC. For the merchant, no modifications to their existing equipment are required, enabling them to conduct transactions via NFC at a low cost, or even without additional costs. As one implementation method, NFC devices can be associated with POS devices via wired or wireless means. For example, the NFC device can be connected to the merchant's device via a USB cable or other type of cable; or the NFC device and the merchant's device can be on the same wired or wireless network. Another implementation method is to establish a binding relationship between the NFC device and the POS device. For example, the merchant service provider or the near-field communication (NFC) device service provider can establish a binding relationship between the NFC device and the merchant's device through mobile terminals such as smartphones in applications, mini-programs, or web pages used to establish the binding relationship. Alternatively, if the NFC device has an operable interface or screen, it can also access the application, mini-program, or web page used to establish the binding relationship, thus establishing a binding relationship between the NFC device and the POS device. Similarly, if the POS device has an operable interface or screen, it can also access the application, mini-program, or web page used to establish the binding relationship, thus establishing a binding relationship between the NFC device and the merchant's device. The server can record this binding relationship. Furthermore, a merchant can apply to use the NFC device, and after the application is approved, the server can record the correspondence between the NFC device and the merchant's device. Or, after the NFC device is distributed to or provided to a merchant, the installer or other personnel can provide the server with information indicating the correspondence between the NFC device and the merchant's device. For specific details, please refer to the relevant technology descriptions. The specific method is not limited here, as long as it enables the NFC device and the merchant's device to be associated. Of course, near-field communication devices can also be integrated into the vendor's equipment as a component. The specific distribution of the devices is not limited here.

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

[0042] Next, a payment method provided in the embodiments of the specification will be described in detail with reference to the accompanying drawings.

[0043] Figure 2 This is a flowchart illustrating a payment method provided in an embodiment of this specification. From a programming perspective, the entity executing the process can be a program or application client installed on a user terminal. From a hardware perspective, the entity executing the process can be the user terminal. For example... Figure 2 As shown, the process may include the following steps.

[0044] Step 202: Obtain the payment link information provided by the near-field communication device via near-field communication.

[0045] In this system, the user terminal can act as a near-field communication (NFC) card reader, sending NFC trigger information to initiate NFC communication. The NFC device contains an NFC tag or can be in card emulation mode, responding to the trigger information sent by the user terminal. The user terminal can obtain payment link information provided by the NFC device through NFC. The payment link information can be information already stored in the NFC device before the interaction between the NFC device and the user terminal. As a tag device, the NFC device can represent the payment link information as tag information. The user terminal can obtain the tag information after touching the NFC device, and this tag information may contain the payment link information. Alternatively, if the user terminal can recognize other forms of information, it can trigger the corresponding process through these other forms of information; the tag information can also contain other forms of information. In some embodiments, the user terminal can typically recognize link-based information. Using link-based information here allows various types or models of user terminals to successfully respond to NFC interactions with the NFC device, making it universally applicable to a wide range of users and providing convenience.

[0046] In some embodiments, the near-field communication (NFC) function of the user terminal can be enabled and can be in card reader mode, sending electromagnetic signals to establish NFC communication. For example, the user terminal can be in card detection mode, transmitting a card detection signal to detect whether an NFC tag or NFC card is nearby. After confirming the presence of an NFC tag or NFC card, it can perform NFC NFC NFC communication with the NFC tag or NFC card to obtain information from it. Specific processes can be found in related technologies and will not be elaborated here.

[0047] Once the user terminal is unlocked or has successfully collected and verified the user's facial or fingerprint biometric features, it can activate NFC reader mode. For example, when making a payment, the user unlocks their phone or smartwatch, and the terminal can then activate NFC reader mode, sending a near-field communication (NFC) trigger message. Alternatively, before making a payment, if the user is using their phone or smartwatch, the terminal can remain in NFC reader mode, sending NFC trigger messages through either low-power or normal card detection modes. The user can bring the terminal close to or touch the NFC device, allowing the terminal to detect the NFC tag or card and read the tag information via NFC. In some embodiments, the timing of activating NFC reader mode is not specifically limited here.

[0048] Step 204: Based on the payment link information, launch the payment application in the user terminal.

[0049] The payment link information can be a string in the form of a link, such as a URL (Uniform Resource Locator) that starts with characters like http or https.

[0050] The payment link information can include application identification information of the payment application with payment functionality. This payment application can be a terminal application with payment functionality, such as an app or mini-program, a system application on the user's terminal, or a third-party application downloaded and installed on the user's terminal. The application identification information can be information that uniquely identifies the payment application, such as the application's name, abbreviation, or package name. Different user terminals or user terminals on different systems can be identified as belonging to the same payment application based on this application identification information. After obtaining the payment link information, the user terminal can launch the payment application specified in the link information. This eliminates the need for the user to manually launch the payment application on their terminal. Furthermore, if the user is using the user terminal to perform other tasks before conducting a transaction near the near-field communication device, such as browsing e-books, watching videos, or making phone calls, the user does not need to exit the currently active task, further improving the user experience.

[0051] As another implementation, the payment link information may contain information for triggering the launch of various payment applications with payment functions on the user terminal. After the user terminal obtains the payment link information, it can display a selection page containing information such as the icons or names of various available payment applications, and the user can manually select the payment application to be launched.

[0052] Launching the payment application can be done in the foreground on the user's terminal, where the application page can be displayed, such as a page indicating application startup or payment in progress. Alternatively, launching the payment application can mean starting it in the background on the user's terminal, where the application page may not be displayed. The key is that the payment application is running and can generate payment identification information. If the payment application corresponding to the payment link is already running on the user's terminal before or during the acquisition of the payment link information, the user does not need to launch the payment application again.

[0053] Step 206: Based on the launched payment application, generate payment identifier information using the pre-stored seed information.

[0054] The seed information is information already stored locally on the user terminal before it obtains the payment link information (i.e., tag information); alternatively, the seed information can be included in the payment link information (tag information) and transmitted to the user terminal by the near-field communication device (NFC); ​​or, the seed information can be obtained by the NFC device from a server or other party during or after contact between the user terminal and the NFC device, and then provided to the user terminal via short-range communication methods such as NFC, Bluetooth, Wi-Fi, or sound waves. After obtaining the payment link information, the user terminal can generate payment identification information locally. For example, the seed information can be processed using the information in the payment link information to obtain the payment identification information.

[0055] The payment identification information may include identification information representing the user's payment account. The server can determine the payment account corresponding to the user terminal using the payment identification information. The payment identification information may include seed information or information obtained by processing the seed information. The server may maintain a mapping between seed information and the payment account corresponding to the user terminal. Thus, upon receiving a payment processing request containing the payment identification information from a near-field communication device or a cash register, the server can determine the payment account and process the payment.

[0056] Seed information can be a fixed string or a variable string. For example, seed information can be a server-managed string that manages the correspondence between seed information and user terminals. Alternatively, seed information can be user information from the user terminal, such as user ID or device identifier. It can also be a timestamp. Furthermore, seed information can be a portion of the acquired tag information, and so on. The specific form of seed information is not limited here; it can be determined according to the generation rules. As one implementation method, seed information can be seed information capable of generating a payment code for display. For example, the application page of a payment application (such as the homepage or other pages, or a prominent position on the page) includes an operation control for displaying the payment code. When the user clicks on this operation control, or triggers the user terminal to display the payment code by pressing the volume or power buttons, the user terminal can generate a payment code locally based on the seed information, such as a collection code, payment code, or transit code. The user terminal can then display this payment code, and the counterparty device (such as a cash register, POS machine, subway gate, or bus card reader) can obtain the payment code information by scanning or inputting it for transaction. Payment codes can be in the form of QR codes, 3D codes, barcodes, or payment code numbers. In this case, the seed information pre-stored on the user terminal can be understood as a universal seed information that can be used to generate payment identification information or payment codes in various payment scenarios. If the user terminal conducts a transaction via near-field communication (NFC), such as obtaining payment link information provided by the NFC device through NFC as mentioned above, the user terminal can generate payment identification information that does not need to be displayed on the user terminal based on the seed information. If the user performs an operation on the user terminal to display a payment code, the user terminal can also generate a displayable payment code based on the seed information.

[0057] As another implementation, the seed information can be specifically designed for scenarios involving payments via near-field communication (NFC). Before or after providing this seed information to the user terminal, the server can record the application scenario corresponding to the seed information, for example, recording the correspondence between the seed information and NFC payment scenarios. If the user terminal is conducting a transaction via NFC, such as obtaining payment link information from a NFC device as described above, the user terminal can generate payment identifier information based on the seed information, eliminating the need for the user terminal to display it. If the server subsequently receives a processing request containing payment identifier information or seed information, the server can determine whether the request is for a NFC payment scenario based on the recorded correspondence. Conversely, if, as mentioned above, the user performs operations on the user terminal to display a payment code, the user terminal, upon receiving the user's operation, cannot use the seed information specifically designed for NFC payment scenarios to generate and display the payment code. In some embodiments, the user terminal may also pre-store seed information for generating a displayable payment code. This seed information for generating a displayable payment code may be different from the seed information pre-stored by the user terminal in step 206. In this case, if the user terminal has both the function of displaying a payment code manually by the user and the function of making a payment via near-field communication, the user terminal can pre-store seed information for both payment scenarios.

[0058] In the embodiments of this specification, the payment identifier information can be generated by the payment application launched by the user terminal after obtaining the payment link information. If the user terminal does not obtain the payment link information, that is, if the user terminal does not make a payment via Near Field Communication (NFC), the user terminal may not use the aforementioned pre-stored seed information to generate the payment identifier information.

[0059] It's important to note that seed information can exist on the user terminal regardless of whether the user terminal uses it for payment via near-field communication (NFC). For example, the server can provide seed information to the user terminal upon its first login to the payment application; alternatively, the seed information can be included in the payment application's installation package, becoming available to the user terminal after downloading and installing the application; or, the server can provide seed information to the user terminal after enabling NFC payment functionality within the application, and so on. There is no specific timeframe for when the user terminal acquires seed information, as long as it does so before engaging in NFC communication with the NFC device.

[0060] In one implementation, the payment identification information can be a string of a preset length. For example, it can contain one or more characters such as numbers, letters, and symbols of a preset length. The payment identification information can trigger the near-field communication device or a cash register associated with the near-field communication device to execute the payment process. After obtaining the payment identification information, the near-field communication device or the cash register can trigger the execution of the payment-related process. The payment identification information may contain specific characters that conform to the payment communication protocol, such as a string starting with "28". After obtaining the payment identification information, the near-field communication device or the cash register can determine that the payment identification information is used for payment and can execute the corresponding payment process.

[0061] In one implementation, the payment identification information may have the same starting character as the payment code number, and / or the number of characters in the payment identification information may be the same as the number of characters in the payment code number.

[0062] The starting character can represent the first character or a character at a predetermined position starting from the first character. For example, the first character of the payment identifier and the payment code numbers are the same; or the first two, three, or four characters of the payment identifier and the payment code numbers are the same. For instance, both the payment identifier and the payment code numbers are strings starting with "28", or both are strings starting with "13", etc.

[0063] The number of characters in a payment code can refer to the total number of characters it contains, such as 18 characters, 17 characters, etc. Alternatively, it can also refer to the number of characters in various formats, such as the number of numeric characters, alphabetic characters, or symbolic characters.

[0064] In the embodiments of this specification, the number of characters contained in the payment identifier information can be the same as the number of characters contained in the payment code. For example, the payment identifier information can be 18 characters, 17 characters, or 13 characters, etc. Alternatively, the payment identifier information can be an 18-, 17-, or 13-digit string of pure numbers. Or, the payment identifier information can contain a portion that consists of 5 consecutive numbers, or a portion that consists of 3 consecutive letters, etc.

[0065] In some related technologies, a POS device needs to obtain payment code information representing the user's terminal account information before sending a payment request to the server to execute the corresponding payment process. This allows the server to identify the two parties involved in the transaction and process it. The specific meaning of the payment code information is not understood by the POS device; the meaning of the payment code information or the corresponding user account is maintained by the server processing the payment. For the POS device, if it obtains information that conforms to a preset format, such as an 18-character string starting with "28", it can trigger the payment process. The specific information format can be pre-agreed upon between the POS and the server.

[0066] In the embodiments of this specification, the payment identification information can have the same format as the payment code number, which can reduce or even eliminate the need for modifications to the merchant side (such as POS equipment), allowing merchants to continue using existing programs or hardware. For example, for the widely used QR code payment, the merchant can trigger the payment process after obtaining the information representing the payment code. The merchant device can trigger the payment process after obtaining a 28-digit code or an 18-digit pure number. The payment identification information in the embodiments of this specification can also be a string conforming to the 28-digit code format, but this string is generated locally on the user terminal, and the generation process does not require server-side involvement, allowing the user terminal to make payments even in environments with no or weak network connectivity.

[0067] Of course, in some embodiments, the POS device has a dedicated processing flow for payments made via near-field communication. The payment identification information may also have a different format than the payment code number. It can be a format negotiated between the server administrator and the POS device owner, as long as it can be recognized by the merchant's device and the server to trigger the corresponding business process. The specific format of the payment identification information is not limited here.

[0068] Step 208: Send the payment identifier information to the near-field communication device so that the near-field communication device can trigger the execution of the payment process based on the payment identifier information.

[0069] In this system, the user terminal can send payment identification information to the near-field communication device via short-range communication, without the need for a server. For example, the user terminal can send payment identification information to the near-field communication device via NFC or Bluetooth.

[0070] As one implementation method, sending the payment identification information to the near-field communication device may specifically include: sending the payment identification information to the near-field communication device via near-field communication; or sending the payment identification information to the near-field communication device via Bluetooth communication; or sending the payment identification information to the near-field communication device via sound waves.

[0071] In this configuration, the user terminal is in NFC reader mode, also known as read-write mode, which allows for both information reading and writing. After obtaining payment link information from the near-field communication (NFC) device via NFC, the user terminal launches a payment application, such as a client application. This client can locally generate payment identification information and then provide this information to the NFC device via NFC. For example, the payment identification information can be written into the NFC tag or NFC module of the NFC device, or it can be transparently transmitted to the storage space of the NFC device using NFC, without needing to be stored in the NFC tag. In some embodiments, since the time required for the user terminal to locally generate the payment identification information is in the milliseconds or even nanoseconds, the time required is extremely short. From the user's perspective, the payment can be completed by simply touching the user terminal to the NFC device once.

[0072] If both the user terminal and the near-field communication device have Bluetooth communication capabilities, the user terminal can send payment identification information to the near-field communication device via Bluetooth. In some embodiments, if the user terminal has authorized the payment application to use Bluetooth, the user terminal can send payment identification information to the near-field communication device via Bluetooth without the user's knowledge, i.e., without any additional user operation.

[0073] If, due to system requirements or other factors, the user terminal displays a notification requiring confirmation to use or activate Bluetooth, and the user is required to perform a confirmation operation (e.g., an iOS user terminal might display a clip prompt card indicating that Bluetooth has been activated or that a payment application is requesting Bluetooth access), the user needs to click a confirmation button. In this case, after receiving the user's confirmation, the user terminal can send payment identification information to the near-field communication (NFC) device via Bluetooth. From the user's perspective, after touching the NFC device, a prompt appears on the user terminal. The user can then pick up the user terminal, move it away from the NFC device, and perform the confirmation operation. The user terminal can then send payment identification information via Bluetooth. During this process, the NFC communication between the user terminal and the NFC device can be disconnected, allowing the user terminal to send payment identification information to the NFC device even when it is moved away from the device. Alternatively, the user can place the user terminal on top of or near the NFC device to perform the confirmation operation. In this case, the NFC communication between the user terminal and the NFC device can remain active during the Bluetooth payment identification information transmission. This document does not specify whether the user terminal and the near-field communication device have an NFC near-field communication connection or whether they are within the range of NFC near-field communication during the process of sending payment identification information via Bluetooth.

[0074] Sound wave transmission can be a method of transmitting information using sound waves at a preset frequency. This preset frequency can be a frequency outside the range of human voice recognition and that poses no harm to other devices or living organisms. For example, it could be an ultrasonic frequency between 18.5 and 20 kHz.

[0075] The user terminal can have a program or processing module that converts string information into sound wave signals and sends them. The near-field communication device can have a program or processing module that receives sound wave signals and converts them back into string signals. Thus, after generating payment identification information locally, the user terminal can convert the payment identification information into sound wave form and transmit it externally via sound wave transmission. The near-field communication device can receive this sound wave information and parse it to obtain the payment identification information. For details on the specific principles of sound wave transmission, please refer to relevant technical introductions; they will not be elaborated upon here.

[0076] Similar to the Bluetooth communication transmission method described above, if the user terminal sends payment identification information via sound wave transmission, the NFC near-field communication connection between the user terminal and the near-field communication device can be disconnected or present during the transmission process, without specific limitations.

[0077] In some embodiments, if the user terminal and the near-field communication device are in the same Wi-Fi wireless network environment, the user terminal can also send payment identification information via Wi-Fi communication. Similar to the above-mentioned transmission methods such as Bluetooth communication and acoustic wave transmission, if the user terminal sends payment identification information via Wi-Fi communication, the NFC near-field communication connection between the user terminal and the near-field communication device may be disconnected or present during the transmission process, without specific limitations.

[0078] From the user's perspective, regardless of whether the user terminal uses one or more of the above four methods to transmit payment identification information, the user only needs to touch the user terminal with the near-field communication device once, without requiring overly complicated operations from the user.

[0079] To improve payment efficiency, after generating payment identification information, the user terminal can simultaneously trigger one or more of the four transmission methods mentioned above, or execute one or more of the four transmission methods in a preset order. The near-field communication device can trigger the payment process as soon as it obtains the payment identification information using any of the four methods. For example, if the user terminal sends payment identification information using one or three of the four methods, and the near-field communication device first obtains the payment identification information via NFC, it can trigger the payment process immediately without waiting for the other two methods to transmit the payment identification information.

[0080] Of course, to ensure the accuracy of the information, near-field communication devices can also verify the consistency of the payment identifier information after obtaining it through at least two of the four methods mentioned above before triggering the payment process. The specific timing of the process triggering can be set according to actual needs, and no specific limitations are made here.

[0081] In some embodiments, if the user terminal's network status is good, the method of the user terminal generating payment identification information locally and the method of the user terminal requesting the server to issue voucher information, as described above, can be executed in parallel. To further improve payment efficiency, both the method of the user terminal generating payment identification information locally and the method of the user terminal requesting the server to issue voucher information can be executed. This allows for the provision of information to trigger transactions through more paths, enabling the near-field communication device or the cash register to send payment requests to the server more quickly. Regardless of which path enables the near-field communication device or the cash register to obtain the payment voucher, the near-field communication device or the cash register can trigger payment. This avoids the problem of long transaction times or failures due to delays or malfunctions in a certain path, further improving payment efficiency.

[0082] For example, when a user terminal touches a near-field communication (NFC) device, it can be understood that the NFC device receives the card detection signal emitted by the user terminal. The NFC device can then send payment link information to the user terminal, which launches the payment application and generates payment identification information locally. This generated payment identification information can also be provided to the NFC device via short-range communication. Simultaneously, after launching the payment application, the user terminal can send an identification generation request to the server, requesting the server to generate target payment identification information representing the user's payment account. The identification generation request can include the user terminal's identification information. The server can then send the target payment identification information back to the user terminal, which can then provide this information to the NFC device via short-range communication methods such as NFC, Bluetooth, Wi-Fi, or sound waves. Alternatively, if the user terminal has obtained the NFC device's identification information, the identification generation request can also include the NFC device's identification information, allowing the server to send the target payment identification information to the NFC device. If the NFC device is associated with a POS terminal, and the server can obtain the POS terminal's identification information, the server can also send the generated target payment identification information to the POS terminal. The target payment identifier information can also be information that triggers the payment process. After obtaining the target payment identifier information, the near-field communication device or the point-of-sale device can execute the payment process.

[0083] As one implementation method, the near-field communication device can trigger the execution of a payment process using the target payment identifier information and the payment identifier information respectively. For example, it can send a payment request to a server, which can then process the previously obtained payment request. Alternatively, after obtaining the target payment identifier information, the near-field communication device can send this information to the cash register. It can also send locally generated payment identifier information to the cash register. The cash register can then execute the payment process based on the previously obtained identifier information; for example, the cash register can use the previously obtained identifier information to send a payment request to the server.

[0084] As another implementation, the near-field communication (NFC) device can also execute a payment process using either the payment identifier information or the target payment identifier information. For example, if the NFC device obtains the payment identifier information first, it can execute the payment process based on that payment identifier information; if the NFC device obtains the target payment identifier information first, it can execute the payment process based on that target payment identifier information. For instance, the NFC device might send the identifier information it obtains first to the cash register, and then discontinue processing the identifier information obtained later. Alternatively, the NFC device could use the identifier information it obtains first to send a payment processing request to the server, and then discontinue processing the identifier information obtained later, and so on.

[0085] To improve the accuracy of triggering the payment process, the target payment identifier information and the payment identifier information can have the same string format. However, the specific string content of the target payment identifier information and the payment identifier information can be different or the same.

[0086] In the embodiments described in this specification, the user terminal can pre-store seed information locally for generating payment identification information. When payment is required, the user terminal can generate payment identification information for processing the payment transaction based on the pre-stored seed information and provide it to the near-field communication device (NFC). This allows the NFC to trigger the payment process based on the acquired payment identification information. By generating payment identification information from the pre-stored seed information on the user terminal, even in environments with no or weak network connectivity, the user terminal can still obtain the payment identification information for payment and provide it to the NFC to trigger the payment process, thereby effectively ensuring a high payment success rate and improving the user experience.

[0087] As one implementation, the user terminal may have a local identifier generation rule for generating payment identifier information. Specifically, the user terminal generates payment identifier information using pre-stored seed information, which may include processing the seed information using the identifier generation rule to obtain the payment identifier information.

[0088] The identifier generation rules can generate payment identifier information that conforms to preset rules from seed information. In the embodiments of this specification, the user terminal can have its own identifier generation rules, allowing the user terminal to generate payment identifier information locally. This eliminates the need for the user terminal to request payment identifier information from a server via the network, enabling payment to be made even in weak or no network conditions. This improves the payment success rate. Of course, when the user terminal has a good network connection, the method of generating payment identifier information locally on the user terminal as described in this specification can also be used for transactions.

[0089] The seed information and identification information generation rules can be provided to the user terminal by the server when the user terminal has a network connection during the download, update, or use of payment applications. The server can send the seed information and identification information generation rules to the user terminal at the same time, or it can send them to the user terminal separately, as long as the user terminal obtains them before engaging in near-field communication with the near-field communication device.

[0090] The seed information itself may not contain any information related to the user terminal, such as user information, device information, etc. This way, even if the seed information is leaked for some reason, unauthorized users who obtain the seed information cannot extract the account information of the user terminal from it.

[0091] In some embodiments, the identification information generation rules may include algorithmic rules such as encryption algorithms and obfuscation algorithms, or may also include parameters for generating payment identification information. Payment identification information that meets the requirements can be obtained by encrypting and obfuscating the seed information. As one implementation, the identification information generation rules include an index string and an encryption algorithm. When the network connection is good, the server can provide the user terminal with the seed information and the identification information generation rules containing the index string and encryption algorithm. Thus, after obtaining the payment link information provided by the near-field communication device, the user terminal can generate payment identification information based on the locally existing seed information and identification information generation rules. Since the user terminal already has the seed information and identification information generation rules locally, the process of generating payment identification information does not require server intervention; the user terminal can complete it locally.

[0092] To further enhance security, the user terminal can store at least some of the seed information, encryption algorithm, and index string in its trusted execution environment (TEE). The index string can be a number of predetermined lengths, such as 10 digits or 8 digits; different seed information can correspond to different index strings. The seed information can be a string that includes at least one of the following formats: numbers, letters, and special characters; it can also be an encrypted string. Different seed information can correspond to the same encryption algorithm, or different seed information can correspond to different encryption algorithms.

[0093] To enhance information security, payment identification information can be encrypted before transmission. For example, a user terminal can encrypt the payment identification information before transmitting it to a near-field communication (NFC) device, which can then decrypt it to recover the payment identification information. The user terminal can execute the encryption process according to preset encryption rules, and the NFC device can have corresponding decryption rules. For instance, the NFC device can use token strings from the payment link information to encrypt the payment identification information, and then perform the corresponding encryption.

[0094] User terminals can interact with near-field communication devices through short-range communication, and the transmitted information can be processed by encryption, obfuscation, compression, etc.

[0095] Optionally, the above-mentioned processing of the seed information using the identification information generation rule to obtain the payment identification information may specifically include: processing the seed information using the encryption algorithm to obtain a first string; concatenating a preset starting character with the index string and the first string to obtain the payment identification information.

[0096] The preset starting character can be one or more characters, and different payment identification information can have the same preset starting character. For example, it can be a character that matches the starting character of the payment code digits, such as two digits like "28", "13", or "30", or it can be a letter. It can be set according to actual needs.

[0097] The encryption algorithm can be used to generate a string of a preset length, such as the encryption algorithm for a one-time pad (OTP), or other encryption algorithms such as symmetric encryption or asymmetric encryption, which can be set according to actual needs.

[0098] In some embodiments, to ensure information security, the seed information obtained by the user terminal may be encrypted information. The user terminal has corresponding decryption rules or algorithms. The user can first decrypt the obtained encrypted seed information to obtain the original seed information, and then use encryption algorithms such as OTP to process the first string of the obtained original seed information.

[0099] Before or after sending seed information and identification information generation rules to the user terminal, the server may also record the correspondence between at least a portion of the seed information and / or identification information generation rules and the user terminal. Specifically, the server may record the correspondence between the seed information and / or identification information generation rules and the device identifier (such as device number, device ID, etc.) of the user terminal, or it may record the correspondence between the seed information and / or identification information generation rules and the user information logged into the payment application on the user terminal. The user information may be at least one of the following: the user's UID (User Identification) in the payment application, the user's ID card number, mobile phone number, email address, bank card number, or payment account information in the payment application.

[0100] The index string can be used by the server to quickly determine the payment account after receiving a payment processing request containing payment identification information from a near-field communication device or a cash register device. For example, the index string can be generated based on user information (such as device ID or user ID). After obtaining the payment identification information, the server can parse the index string and obtain the user information based on it, thus quickly determining the user's payment account.

[0101] Concatenating the preset start character with the index string and the first string can be done by concatenating these three elements in the order of preset start character, index string, and first string, or in the order of preset start character, first string, and index string, or by interleaving the index string into the first string or the first string into the index string, or by interleaving the index string and the first string together. There is no limitation on the specific concatenation method here.

[0102] Assuming the seed information is 123456, the first string obtained after encryption is 020406. Alternatively, if the seed information is 123, the first string obtained after encryption is 020406. Assuming the index string is 1122334455 and the default starting character is 28, the resulting payment identifier information could be 281122334455020406. It should be noted that the length of the seed information and the length of the first string obtained can be the same or different, depending on the specific requirements and the algorithm.

[0103] In some embodiments, the payment identification information can be generated by the user terminal based on seed information and the user terminal's time information. Specifically, an encryption algorithm can be used to combine the user terminal's current time information to generate a first string. In this way, the payment identification information can include time information indicating when the user terminal generated the payment identification information. After the server obtains the payment identification information, it can verify the validity of the payment identification information and also provide transaction security.

[0104] For example, a user terminal can use the OTP encryption algorithm combined with its current time to generate a first string, and then generate payment identification information. The user terminal's current time could be the moment it obtains the payment link information, the moment it launches the payment application, the moment it calls the seed information, or the moment it executes the step to generate the payment identification information, etc. The user terminal's current time can represent the generation time of the payment identification information. After the user terminal provides this payment identification information to a near-field communication device or a cash register, the near-field communication device or cash register can send a payment trigger request containing the payment identification information to the server. Upon receiving the request, the server can parse the payment identification information from the request and, according to a preset parsing method, parse the seed information from the payment identification information. Then, the server can use the OTP encryption algorithm combined with its current time and times within a preset time period before the current time (e.g., the current moment and times within the previous two minutes) to generate a set of reference strings. This set of reference strings includes multiple reference strings, and each reference string can be a string generated by the server combining its current time with a specific time within the preset time period before the current time. The server's current time can be the time it received the payment identifier information, the time it parsed the seed information, or the time it received the request, etc. The server can determine if the first string in the payment identifier information exists in the set of reference strings generated by the server. If it does, it indicates that the payment identifier information was generated within a relatively short period and is therefore valid. The server can then execute subsequent transaction processing steps based on this payment identifier information. If the first string in the payment identifier information does not exist in the set of reference strings generated by the server, it indicates that the payment identifier information poses a risk, and the server can terminate the transaction processing steps. This prevents unauthorized users from obtaining payment identifier information generated by legitimate user terminals and using it for illegal transactions, such as stealing funds from legitimate user accounts.

[0105] In some embodiments, other encryption algorithms that can combine time information to generate payment identification information may also be used. This is only an example of using the OTP algorithm, and no specific limitation is made.

[0106] To further ensure information security, the payment identification information may be obtained after obfuscation. Optionally, the above identification information generation rules also include an obfuscation algorithm, and the method further includes: based on the obfuscation algorithm, using the first string to obfuscate the index string to obtain a second string.

[0107] Correspondingly, the above-mentioned concatenation of the preset starting character with the index string and the first string to obtain the payment identification information may specifically include: concatenating the preset starting character with the second string and the first string to obtain the payment identification information.

[0108] Continuing with the previous example, suppose the index string is 1122334455, the first string is 020406, and the second string obtained by obfuscating the index string using the first string is 5678901234. In this case, the payment identifier information can be 285678901234020406.

[0109] The obfuscation algorithm can have a corresponding deobfuscation algorithm. The deobfuscation algorithm can reside on the server. After obtaining the payment identifier information, the server can use the deobfuscation algorithm to obtain the original index string, and then query the payment account that made the transaction. The obfuscation algorithm can change the character values ​​of the index string, but it can remain unchanged in length. The length of the second string can be the same as the index string. Alternatively, the obfuscation algorithm can also change the length of the index string. A suitable obfuscation algorithm can be selected according to actual needs; no specific limitations are imposed here.

[0110] To enhance data security, after generating payment identification information locally on the user terminal, the information can be compressed, encrypted, or obfuscated before being sent to the near-field communication device. Alternatively, it can be processed according to the format requirements of the communication protocol corresponding to the desired transmission method before being sent.

[0111] For example, payment identification information can be encrypted using at least a portion of the string in the tag information or payment link information (which can be called an encryption factor). Alternatively, at least a portion of the string in the tag information or payment link information can be concatenated with the payment identification information and then encrypted using an encryption algorithm. Obfuscation or compression can also be performed. Near-field communication devices have corresponding decryption programs that can decrypt the payment identification information or the string in the payment link information to determine whether the acquired data has been tampered with. The specific encryption and decryption logic is not limited here.

[0112] In the embodiments of this specification, the seed information in the user terminal can be seed information that is used multiple times, and the index string can also be reused, but the payment identifier information can be used only once. The encryption algorithm for encrypting the seed information can be an algorithm that generates different encryption results for the seed information. For example, when the user terminal executes this transaction, the user terminal locally processes the seed information using the OTP encryption algorithm to obtain a first string. When the user terminal executes the next transaction, the user terminal locally processes the same seed information using the OTP encryption algorithm to obtain another first string. In this way, the payment identifier information generated for different transactions can be different.

[0113] Optionally, the aforementioned near-field communication device can be a first near-field communication device, the aforementioned payment link information is first payment link information, and the aforementioned payment identifier information is first payment identifier information. After sending the payment identifier information to the near-field communication device, the method may further include: obtaining second payment link information provided by a second near-field communication device via near-field communication; launching the payment application in the user terminal based on the second payment link information; generating second payment identifier information using the pre-stored seed information based on the launched payment application; and sending the second payment identifier information to the second near-field communication device so that the second near-field communication device triggers the execution of the payment process based on the second payment identifier information.

[0114] The second near-field communication device is a near-field communication device that has conducted other transactions with the user terminal. It may be the same device as the first near-field communication device or it may be a different device. The second payment identification information is different from the first payment identification information.

[0115] For example, if a user performs two or more transactions in the same store or different stores using NFC near-field communication, the payment identification information generated by the user terminal for these two or two transactions will be different, but they can be generated using the same seed information.

[0116] Optionally, the aforementioned index string can be reused, and there can be a one-to-one correspondence between the seed information and the index string. As one implementation, the first payment identifier information and the second payment identifier information can have the same preset starting character and index string, but different first strings obtained after encrypting the seed information. For example, the first payment identifier information is 281122334455020406, and the second payment identifier information is 28112233445567890.

[0117] As another implementation, the payment identification information mentioned above can be information obtained after obfuscation. Different first strings can be used to obfuscate the same index string to obtain different second strings. In this way, the first and second payment identification information can have the same preset starting character, but other parts can be different. For example, the first and second payment identification information can be generated by the user terminal based on the same seed information. Both are strings that start with the preset starting character, and the first and second payment identification information have the same length, such as containing 18 digits. For example, continuing the previous example, assuming the seed information is 123456, after the user terminal obtains the second payment link information, the user terminal processes the seed information according to the encryption algorithm in the identification information generation rule to obtain a new first string of 567890. Assuming the index string is 1122334455, the new first string is used to obfuscate the index string, assuming the new second string is 5678901234. Thus, the second payment identification information is 285678901234567890.

[0118] For different transactions, the user terminal can generate different payment identifier information based on the locally stored seed information, which can also improve payment security.

[0119] In the embodiments of this specification, the seed information may be actively pushed to the user terminal by the server, or it may be requested by the user terminal from the server. Optionally, the method in the embodiments of this specification may further include: the user terminal obtaining the seed information provided by the server.

[0120] In some embodiments, the determination of whether to obtain seed information from the server can also be based on the status of seed information already stored on the user terminal. Optionally, before generating payment identification information using pre-stored seed information, the method in the embodiments of this specification may further include: determining whether the number of usable seed information stored locally on the user terminal is less than or equal to a preset threshold; if the number of usable seed information stored locally on the user terminal is less than or equal to the preset threshold, sending a seed acquisition request to the server; and obtaining the seed information returned by the server.

[0121] Seed information can have an expiration date or a valid number of uses. Usable seed information can be valid seed information that is within its validity period and / or has not exceeded its valid number of uses. The validity period or number of uses of seed information stored locally on the user terminal can be used to determine whether the user terminal can store one seed information or multiple seed information. The aforementioned preset threshold can be 0 or a value greater than 0, such as 1, 2, 3, etc.

[0122] In one implementation, if a user terminal stores seed information, the user terminal can determine whether the locally stored seed information has expired. If it has expired, the user terminal can send a seed acquisition request to the server. The server can then send a usable seed information back to the user terminal based on the request.

[0123] As another implementation, if the user terminal stores multiple seed information entries, the user terminal can determine whether each seed entry has expired based on its validity period or the number of times it has been used. If the number of expired seed entries is greater than or equal to a certain number (e.g., 2, 5, etc.) or the number of remaining usable seed entries is less than or equal to a certain number (e.g., 0, 1, etc.), the user terminal can send a seed acquisition request to the server. The server can then return usable seed information to the user terminal based on the request. The server can return one or more usable seed entries to the user terminal. For example, the user terminal can store a maximum of 5 usable seed entries locally. Assuming the user terminal initially stores 5 usable seed entries locally, and 4 of them expire due to payment transactions or the passage of time, the user terminal can send a request to the server, and the server can return 4 new seed entries to the user terminal.

[0124] In some embodiments, the seed information provided by the server to the user terminal may be provided by the server when the user terminal is in a good network environment. Optionally, before sending the seed acquisition request to the server, the process may further include: determining whether the network status of the user terminal is good. Specifically, sending the seed acquisition request to the server may include: if the network status of the user terminal is good, then sending the seed acquisition request to the server.

[0125] "Good network status" can mean that the network signal strength is greater than or equal to a preset strength threshold, or that the network type is a wireless network. When the user terminal's network status is good, it can send a seed acquisition request to the server. Specifically, if the user terminal's network status is good and the number of valid seed information locally on the user terminal is less than or equal to a preset threshold, the user terminal can send a seed acquisition request to the server.

[0126] Of course, if the user terminal's network condition is not good or the number of usable seed information stored locally on the user terminal exceeds a preset threshold, the user terminal may choose not to send a seed information acquisition request to the server. The execution steps of the above two judgments can be executed synchronously or sequentially, without specific limitations here.

[0127] In some embodiments, the above-mentioned judgment steps can also be performed by the server. If the above-mentioned judgment steps are performed by the server, and the network status of the user terminal is good and / or the number of valid seed information on the user terminal is less than or equal to a preset threshold, the server can actively push the usable seed information to the user terminal.

[0128] In some embodiments, different merchants or payment service providers may offer additional services to better serve consumers, such as sending coupons or points, or providing promotional information for goods or activities. To ensure that the user terminal can complete the payment while also providing these additional services, the user terminal can also obtain business identification information that represents certain business information. Optionally, the payment link information described in the embodiments of this specification may further include business identification information representing business information; the business information includes at least one of payment scenario information and near-field communication device (NFC) device information. The method in the embodiments of this specification may further include: sending the payment identification information and the business identification information to a server, so that the server can associate the payment identification information with the business information corresponding to the business identification information, and process the transaction corresponding to the payment process triggered by the NFC device based on the payment identification information based on the business information.

[0129] The business identification information can be in the form of a token. The server can provide the payment link information containing the business identification information to the near-field communication device, or the server can provide the business identification information to the near-field communication device, and the near-field communication device can assemble the payment link information locally.

[0130] The user terminal may also provide the service identification information or other parts of the payment link information to the near-field communication device (NFC), and / or provide the user terminal's user information (such as the user terminal device identifier, user identifier, etc.) to the NFC so that the NFC can execute subsequent related processes. For example, the NFC can send information that the user terminal can provide to the POS device. Alternatively, the NFC can send information that the user terminal can provide to the server. Or, the NFC can allow the user terminal to use the information provided locally without sending it to the server or POS device.

[0131] For example, after a user terminal interacts with a near-field communication device, the user terminal obtains payment link information and sends the service identification information in the payment link information to the server. The server can then process the transaction based on this service identification information.

[0132] For example, after obtaining the payment link information, the user terminal sends the service identification information from the payment link information to the near-field communication device. The near-field communication device can then execute the corresponding process based on this service identification information.

[0133] For example, after obtaining the payment link information, the user terminal binds the business identifier information in the payment link information with the user information, and then sends the business identifier information to the server. Alternatively, after obtaining the payment link information, the user terminal first sends the business identifier information in the payment link information to the server, and then binds the business identifier information with the user information. Or, after obtaining the payment link information, the user terminal can bind the business identifier information with the user information at the same time as sending the business identifier information to the server.

[0134] For example, after obtaining the payment link information, the user terminal sends the service identifier information and user information from the payment link information to the near-field communication device. Alternatively, after obtaining the payment link information, the user terminal sends the service identifier information and user information from the payment link information to the server. The user terminal can also establish a correspondence or binding relationship between the payment link information or part of its information (such as service identifier information or other information) and the user information, and then the user can feed back the payment link information or part of its information to the near-field communication device or the server.

[0135] Payment scenario information refers to relevant information indicating the specific environment and context in which a user makes a payment. For example, it includes scenario information indicating payment methods such as QR code payment, facial recognition payment, and NFC-based payment; or scenario information indicating the type or location of consumption, such as payment for public transportation like buses and subways, medical payments at hospitals and clinics, or daily necessities payments at shopping malls and supermarkets. Near-field communication (NFC) device information may include device serial number, ID, location, and information about the associated point-of-sale (POS) device.

[0136] The server can store the correspondence between the service identification information and the corresponding service information. For example, the server can store the correspondence between the service identification information and the device information (such as device number, device ID, etc.) of the near-field communication device that receives the service identification information, as well as the information of the merchant (such as merchant name, merchant location, etc.) of the near-field communication device.

[0137] For example, suppose the payment link is an HPPT link, and the content of the link includes: render.alipay.XXXulink / ?scene=nfc&scheme=alipay%123456%2812345678909876527_n_abc.

[0138] The first part, "render.alipay.XXXulink / ", represents a link service domain (alipay.com), specifically used to process and render links or pages for various payment applications. "ulink" indicates a unified link or redirect link. "?scene=nfc" represents some parameter information; "scene" specifies the application scenario of the link, and "nfc" explicitly indicates that this link is used to trigger NFC (Near Field Communication) related functions. "alipay" can represent the application identifier of the payment application. "2812345678909876527" can represent the token for business identification information. After obtaining this payment link information, the user terminal's terminal system can launch the corresponding payment application based on "alipay". The terminal system can also provide this payment link information or part of it to the launched payment application. For example, it can provide information after "ulink" or after "scheme" to the payment application, etc. The specific content provided to the payment application can be determined according to the actual communication protocol used, and is not specifically limited here.

[0139] In some embodiments, the format of the business identification information token can be the same as that of the payment identification information, such as having the same starting character, the same length, or the same character type. Alternatively, the format of the business identification information token can be a different string format than that of the payment identification information.

[0140] After obtaining the payment link information, the user terminal can generate payment identification information locally. On one hand, the user terminal can provide the payment identification information to the near-field communication device (NFC). On the other hand, if the user terminal's network is available or good, the user terminal can also provide the payment identification information and the business identification information from the payment link information to the server. The server can then record the correspondence between the payment identification information and the business identification information, thereby determining the corresponding business information. Combining this with business rules, such as rules on which additional services are available in which scenarios, the server can determine the additional services the user can enjoy in that payment scenario, such as the discount amount and the displayed activity information. Subsequently, after the server receives a payment processing request containing the payment identification information from the NFC or the POS device, the server can process the payment request based on the additional services corresponding to the payment identification information. For example, it could provide an instant discount for the transaction, where the actual amount paid by the user's payment account is less than the actual selling price of the goods. Another example is adding membership points for the user for this transaction. The actual additional services can be set according to actual business needs and are not specifically limited here.

[0141] It should be noted that after generating payment identification information, the user terminal may choose to provide both the payment identification information and the business identification information to the server, or it may choose not to. Whether the server receives this information or not does not affect whether the server can successfully process the transaction. Even if the server does not receive this information, it can still successfully process the transaction; however, it will be unable to provide some additional services to the user, such as the inability to use coupons to process the transaction, preventing the user from enjoying discounts. The user terminal will still successfully pay, but the amount paid will not be the amount for which coupons were used.

[0142] After processing the transaction, the server can also provide transaction result information, which can then be displayed on the user terminal. Optionally, the method in this embodiment may further include: obtaining payment result information representing the payment process; and displaying the payment result information.

[0143] If the user terminal's network is available or in good condition, the payment result information can be provided to the user terminal by the server. If the user terminal's network is not in good condition or is unavailable, the payment result information can be provided to the user terminal by a near-field communication device through short-range communication.

[0144] As one implementation, obtaining payment result information representing the payment process may specifically include: obtaining payment result information transmitted from the near-field communication device to the user terminal via Bluetooth communication. Displaying the payment result information may specifically include: displaying a result page containing the payment result information.

[0145] In some embodiments, due to factors such as device configuration, network configuration, or network connection method, the network status of the near-field communication device or the POS device is usually relatively good. After the server completes the payment processing flow, it can send the payment result information to the near-field communication device or the POS device. For example, the server can send the payment result information to both the near-field communication device and the POS device, or the server can send the payment result information to the near-field communication device, and the near-field communication device can also send the information to the POS device via wired or wireless means, or the server can send the payment result information to the near-field communication device, and the POS device can also send the information to the near-field communication device via wired or wireless means. After obtaining the payment result information, the near-field communication device can transmit it to the user terminal via Bluetooth communication.

[0146] Similar to the near-field communication (NFC) devices described above that transmit payment identification information to user terminals via sound waves, NFC devices can also provide payment result information to user terminals via sound wave transmission. The NFC device may include a program or processing module that converts character information or computer language into sound wave signals and transmits them. The user terminal may include a program or processing module that receives sound wave signals and converts them back into character information or computer language. Thus, after obtaining the payment result information, the NFC device can convert it into sound wave form and transmit it to the user terminal. The user terminal then parses the obtained sound wave information to obtain and display the payment result information.

[0147] In some embodiments, the user terminal may display a page containing payment result information, a pop-up window, a floating layer, etc., or may indicate that the user terminal has received payment result information through vibration, prompt sound, etc.

[0148] Based on the same approach, this manual also provides a payment method using near-field communication devices as the execution entity. Figure 3 This is a flowchart illustrating a payment method provided in an embodiment of this specification. From a programming perspective, the entity executing the process can be a program mounted on a near-field communication (NFC) device. From a hardware perspective, the entity executing the process can be the NFC device itself.

[0149] like Figure 3 As shown, the process may include the following steps.

[0150] Step 302: Send payment link information to the user terminal via near-field communication so that the user terminal can generate payment identifier information using locally stored seed information.

[0151] The payment identification information may include account identification information representing the user's payment account. The payment link information is information that already exists in the near-field communication (NFC) device before it interacts with the user terminal. For example, the payment link information may be obtained from the server or generated locally by the NFC device when it is in standby mode or when the number of locally stored payment link information is less than a preset number. Alternatively, the payment link information may be obtained from the server or generated locally by the NFC device after the associated POS device receives a settlement instruction. Or, the payment link information may be actively pushed to the NFC device by the server. There is no specific limitation on when the NFC device contains payment link information, as long as the NFC device contains payment link information before interacting with the user terminal.

[0152] The payment identifier information can be generated by the user terminal using seed information based on local generation rules. For details about seed information, payment identifier information and payment link information, please refer to the descriptions in the foregoing embodiments, which will not be repeated here.

[0153] Step 304: Obtain the payment identifier information sent by the user terminal.

[0154] The user terminal can send payment identification information to the near-field communication device via one or more of the following methods: NFC, Bluetooth, and acoustic waves. Alternatively, if the user terminal has a good network connection, it can also send locally generated payment identification information to the server, which will then forward it to the near-field communication device.

[0155] Step 306: Trigger the payment process based on the payment identifier information.

[0156] In some embodiments, the near-field communication device can trigger the corresponding payment process after obtaining payment identification information through any method. After obtaining payment identification information through any method, the near-field communication device can terminate the execution of other acquisition methods, or it can continue to execute other acquisition methods, but the same payment identification information obtained later will not trigger the payment process again.

[0157] In some embodiments, if the near-field communication device acts as an intermediary between the user terminal and the cash register, the near-field communication device can also provide the acquired payment identification information to the cash register. Optionally, the above-mentioned triggering of the payment process based on the payment identification information may specifically include: sending the payment identification information to the cash register associated with the near-field communication device, so that the cash register executes the payment process based on the payment identification information.

[0158] The POS device can send a payment processing request to the server based on the acquired payment identifier information. The payment processing request may include the payment identifier information, as well as order-related information such as the amount of goods to be paid and the device identifier of the POS device. This allows the server to identify the two parties involved in the transaction and the quantity of resources to be traded, and then process the transaction between the two parties.

[0159] After processing the payment, the server can send information indicating the payment result to the near-field communication (NFC) device. The NFC device can display the result information, or it can indicate the result through sound prompts, animations, or other means. The result information can indicate that the payment was successful or that it failed. During the payment process, the NFC device can also display prompts or animations indicating that the payment is in progress.

[0160] In some embodiments, if the near-field communication device and the cash register are the same device, or if the near-field communication device can be used as the cash register, the step of the near-field communication device sending payment identification information to the cash register may not be performed, and the near-field communication device can perform the payment process.

[0161] In the embodiments of this specification, the payment link information may be provided by the server to the near-field communication device, or it may be obtained through local processing by the near-field communication device. Optionally, before sending the payment link information to the user terminal via near-field communication, the method in the embodiments of this specification may further include: obtaining the payment link information provided by the server.

[0162] The server can send the entire payment link information to the near-field communication (NFC) device, which can then write the payment link information into an NFC tag, waiting for the user terminal to retrieve it. The server can also record the correspondence between the payment link information and the recipients of that information.

[0163] In some embodiments, the server can provide one or more payment link information to the near-field communication (NFC) device. If the NFC device has one payment link information, the user terminal can obtain the payment link information via NFC. After the NFC device provides the payment link information to the user terminal, it can delete the payment link information from the NFC device or from the NFC tag. If the NFC device has multiple payment link information, it can select one payment link information and write it to the NFC tag. The user terminal can then obtain this payment link information. Similarly, after the NFC device provides this payment link information to the user terminal, it can delete it from the NFC device or from the NFC tag. The same payment link information can be used once, but different payment link information is used for different transactions or different NFC interactions with the NFC device.

[0164] The payment link information described in the embodiments of this specification may include business identifier information (token) representing business information; the business information includes at least one of payment scenario information and near-field communication device device information. Optionally, obtaining the payment link information provided by the server may specifically include: obtaining the business identifier information provided by the server. The method in the embodiments of this specification may further include: generating the payment link information based on the business identifier information and locally stored fixed information; the fixed information includes at least one of application identifier information of the payment application and link prefix information.

[0165] Near-field communication (NFC) devices can have rules or templates for generating payment link information based on service identification information. The NFC device can obtain service identification information from the server and then generate payment link information locally, thus reducing data transmission volume and improving processing efficiency. Different payment link information can contain some identical information; for example, different payment link information can all launch the same payment application, and different payment link information can have the same application identification information. Alternatively, different payment link information can have the same prefix, such as http or https. Or, as illustrated above, different payment link information can have the same prefix indicating the server access domain. The fixed information in a payment link can represent the common information contained in different payment links, such as the payment identifier information, prefix information, etc., mentioned above. After obtaining the service identifier information provided by the server, the near-field communication device can concatenate this information with the fixed information according to preset rules to obtain the payment link information.

[0166] In some embodiments, the server may also provide both the service identification information and the payment link information to the near-field communication device.

[0167] The method by which the near-field communication device obtains payment identification information in the embodiments of this specification is the same as that in the foregoing embodiments. Optionally, obtaining the payment identification information sent by the user terminal may specifically include: obtaining the payment identification information sent by the user terminal via near-field communication; or obtaining the payment identification information sent by the user terminal via Bluetooth communication; or obtaining the payment identification information sent by the user terminal via sound waves.

[0168] The various communication methods are described in the aforementioned embodiments and will not be repeated here. In some embodiments, if the user terminal sends payment identification information in two, three, or all four of the four methods, the payment identification information obtained by the near-field communication device can be the payment identification information transmitted to the near-field communication device in the fastest way.

[0169] To better provide a server for users, similar to the aforementioned user terminal, the near-field communication device (NFC) can also provide the acquired payment identification information and service identification information to the server. Optionally, the payment link information includes service identification information representing service information; the service information includes at least one of payment scenario information and device information of the NFC device. The method in the embodiments of this specification may further include: sending the payment identification information and the service identification information to the server, so that the server can associate the payment identification information with the service information corresponding to the service identification information, and process the transaction corresponding to the payment process triggered by the NFC device based on the payment identification information based on the service information.

[0170] The near-field communication (NFC) device can extract service identification information from the payment link information and upload it, along with the payment identification information provided by the user terminal, to the server. Alternatively, after the server sends service identification information to the NFC device, the NFC device can record this service identification information. After obtaining the payment identification information provided by the user terminal, it can upload both the service identification information and the payment identification information provided by the user terminal to the server. For a detailed description of the service information and service identification information, please refer to the foregoing embodiments; further details will not be provided here.

[0171] In some embodiments, the network status of the near-field communication device is usually relatively good. Uploading payment identification information and service identification information to the server through the near-field communication device can effectively improve the data upload success rate, thereby increasing the probability of providing additional services to users and improving the user experience.

[0172] If both the near-field communication device (NFC) and the user terminal have good network conditions, both can upload payment identification information and service identification information to the server, which can further improve the data upload success rate. The server can save both uploaded information or save duplicates. In some embodiments, regardless of whether the NFC or the user terminal uploads payment identification information and service identification information to the server, the server can associate the payment identification information with the corresponding service information. Based on the service information, the server processes the transaction corresponding to the payment process triggered by the NFC based on the payment identification information. If the service information corresponding to the current payment has additional services, such as coupons, points, or advertising, the user can enjoy those additional services.

[0173] It should be noted that after obtaining payment identification information, the near-field communication device can choose to provide both the payment identification information and the service identification information to the server, or it can choose not to. Whether the server receives this information or not does not affect whether the server can successfully process the transaction. Even if the server does not receive this information—for example, if neither the user terminal nor the near-field communication device uploads the payment identification information and service identification information to the server—the server can still successfully process the transaction. However, it will be unable to provide some additional services to the user, such as the inability to use coupons to process the transaction, preventing the user from enjoying discounts. The user terminal will still successfully pay, but the amount paid will not be the amount for which coupons were used.

[0174] Based on the same idea, this specification also provides a payment method with a server as the execution entity in the embodiments. Figure 4 This is a flowchart illustrating a payment method provided in an embodiment of this specification. From a programming perspective, the entity executing the process can be a program hosted on a server. From a hardware perspective, the entity executing the process can be a server.

[0175] like Figure 4 As shown, the process may include the following steps.

[0176] Step 402: Obtain the payment process trigger request.

[0177] The payment process trigger request is triggered after the near-field communication device obtains the payment identification information provided by the user terminal; the payment identification information is generated by the user terminal based on seed information pre-stored locally on the user terminal. The payment process trigger request can also be understood as a payment processing request, used to request the server to process a transaction.

[0178] The payment identification information is generated by the user terminal according to the methods in the aforementioned embodiments, and will not be described in detail here.

[0179] In one implementation, the payment process trigger request can be sent from the near-field communication (NFC) device to the server. Specifically, after a user touches their terminal with the NFC device, they can obtain payment link information from the NFC device. Based on this payment link information, the corresponding payment application is launched. Based on the launched payment application, the user terminal can generate payment identifier information according to pre-stored seed information and send it to the NFC device. The NFC device can then send a payment process trigger request to the server, which may include the payment identifier information. If the NFC device has already obtained information about goods to be paid for or amounts to be paid for, the payment process trigger request can also include the transaction information. Upon receiving the payment process trigger request, the server executes the payment process, determines the transacting parties and the transaction amount, and processes the transaction.

[0180] As another implementation, the payment process trigger request can be sent to the server by a POS device associated with the near-field communication (NFC) device. Specifically, obtaining the payment process trigger request may include: obtaining a payment process trigger request containing the payment identifier information sent by the POS device; the POS device is associated with the NFC device, and the NFC device sends the payment identifier information to the POS device after obtaining it.

[0181] Specifically, after a user touches their terminal with a near-field communication (NFC) device, they can obtain payment link information from the NFC device. Based on this payment link information, they can launch the corresponding payment application. Based on the launched payment application, the user terminal can generate payment identifier information according to pre-stored seed information and send it to the NFC device. The NFC device can then send this payment identifier information to a cash register. Upon receiving the payment identifier information, the cash register can send a payment process trigger request to the server. This payment process trigger request may include the payment identifier information. In some embodiments, the cash register can also obtain information about goods to be paid for or the amount to be paid before or after the user terminal touches the NFC device. The cash register can also provide this pending transaction information to the server. For example, the payment process trigger request may include the pending transaction information. Upon receiving the payment process trigger request, the server can then execute the payment process, determine the transacting parties and the transaction amount, and process the transaction.

[0182] The payment link information may be provided by the server to the near-field communication device. As one implementation, before the above-mentioned payment process triggers the request, it may also include: sending business identification information representing business information to the near-field communication device, so that the near-field communication device generates payment link information for sending to the user terminal based on the business identification information; the business information includes at least one of payment scenario information and device information of the near-field communication device.

[0183] For details regarding the generation process of payment link information, business information, business identification information, etc., please refer to the descriptions of the aforementioned embodiments, which will not be repeated here.

[0184] In some embodiments, the server may also send payment link information to the near-field communication device, which is not specifically limited here.

[0185] Step 404: Based on the payment process trigger request, execute the payment process and process the transaction of the user terminal.

[0186] The payment process trigger request can include payment identification information, which the server can use to determine the payment account and then process the transaction.

[0187] In some embodiments, the seed information used to generate payment identification information is sent from the server to the user terminal. The server may record the correspondence between the sent seed information and the user terminals receiving the seed information, such as the correspondence between seed information and user UID. After the server receives a payment process trigger request containing payment identification information, it can parse the seed information from the payment identification information and determine the payment account of the user terminal receiving the seed information based on the seed information. For example, the server may have information parsing rules that correspond to the information identification generation rules used in the user terminal to generate the information identification information. These rules may include inverse operation rules, anti-decoding rules, etc., corresponding to the information identification generation rules. The server can determine the user UID receiving the seed information based on the seed information, and then determine the user's payment account, processing the transaction based on that payment account.

[0188] The seed information can be actively pushed to the user terminal by the server, or it can be requested by the user terminal from the server. As one implementation, before the payment process is triggered, the method in this embodiment may further include: obtaining a seed information acquisition request sent by the user terminal; and sending the seed information to the user terminal based on the seed information acquisition request.

[0189] The seed information acquisition request can be sent from the user terminal to the server in the manner described in the foregoing embodiments, and will not be repeated here. The seed information acquisition request may include the user terminal's identification information, such as user UID, device ID, etc., and the server can feed back seed information to the user terminal that sent the request based on this identification information.

[0190] Optionally, the server may also record the correspondence between seed information and the user terminal. The method in the embodiments of this specification may also include saving the correspondence between the seed information and the user terminal.

[0191] The server can record the correspondence between seed information and user terminal identification information. For example, it can record the relationship between seed information and user UID, device ID, or the correspondence between the user account of a user logged into the payment application on the user terminal and seed information, etc. The identification information can be user UID, device ID, device name, user identity information, etc. Thus, as in the aforementioned embodiment, after the server obtains the payment identification information contained in the payment process trigger request, it can determine the payment account based on the correspondence and process the transaction.

[0192] Optionally, the above-mentioned execution of the payment process based on the payment process trigger request may specifically include: determining the payment identifier information contained in the payment process trigger request; parsing the payment identifier information to determine the seed information contained in the payment identifier information; determining the payment account corresponding to the seed information according to the correspondence; and processing the transaction corresponding to the payment process trigger request based on the payment account.

[0193] The server contains parsing rules for retrieving seed information from payment identifier information. After determining the seed information based on these rules, the server can identify the receiving user terminal or user (e.g., user UID) based on the previously saved correspondence when sending the seed information. This allows the server to determine the user's corresponding payment account, which can then be used as the payer's account to process the transaction. The payment account can be the user's bank card account, a third-party account opened by the user in the payment application, or any other account that can be used for payments.

[0194] To better serve users, as described in the foregoing embodiments, the user terminal or near-field communication device can send service identification information and payment identification information to the server. The user terminal or near-field communication device can send these information to the server after acquiring them, either before or after the POS device sends a payment process trigger request. If the server has already received the service identification information and payment identification information from the user terminal or near-field communication device when processing the payment process trigger request from the POS device, the server can determine the additional service corresponding to the payment process trigger request and provide that additional service to the user terminal. Optionally, the method in the embodiments of this specification may further include: acquiring the service identification information and payment identification information sent by the user terminal and / or near-field communication device; the service identification information is identification information representing service information; the service information includes at least one of payment scenario information and near-field communication device device information; and storing the correspondence between the service identification information and the payment identification information. The above-mentioned execution of the payment process based on the payment process trigger request and processing of the user terminal's transaction may specifically include: determining the business identifier information corresponding to the payment identifier information contained in the payment process trigger request according to the correspondence; determining the corresponding business information based on the business identifier information; determining the business supplementary service according to the business processing rules; the business supplementary service includes at least one of preferential service and recommendation service; and processing the user terminal's transaction based on the business supplementary service so that the user of the user terminal can enjoy the business supplementary service.

[0195] For details regarding business information, business identification information, payment identification information, and information transmitted by user terminals and / or near-field communication devices, please refer to the descriptions in the foregoing embodiments, which will not be repeated here.

[0196] The server stores various business information and can also provide additional services corresponding to each piece of business information, configured according to actual needs. Business processing rules represent the rules that determine the corresponding additional services based on the business information. Additional services can include promotional services, recommendation services, etc. Promotional services can include coupons, points, instant discounts, and red envelopes, allowing users to enjoy preferential treatment. Recommendation services can include product recommendations, marketing activity recommendations, advertising recommendations, game recommendations, and other services that provide users with recommended information.

[0197] For example, users who use NFC for offline payments at certain merchants can enjoy instant discounts, so the actual amount paid by the user can be less than the price of the goods; another example is providing a service to recommend nearby restaurants for users who use NFC for in-store payments, so that after the user completes the payment, the user's terminal can display a recommendation page of nearby restaurants.

[0198] The embodiments in this specification are based on the same technical concept, and the embodiments can be referenced to each other. For example, the parts not described in the embodiments with user terminals, near-field communication devices and servers as the execution subjects can be referred to the descriptions in the embodiments with other execution subjects.

[0199] To provide a clearer explanation of the payment methods provided in this manual, Figure 5 Swimlane diagram for a payment method provided in an embodiment of this specification. For example... Figure 5 As shown, the following steps may be included: Step 502: The server sends the service identification information token to the near-field communication device.

[0200] Step 504: The near-field communication device generates payment link information based on the service identifier information token.

[0201] In some embodiments, the payment link information may include the identification information of the payment application. If the near-field communication device can obtain the transaction information to be settled at the cashier device, such as the amount to be paid, the payment link information may also include transaction information specific to the current transaction.

[0202] Step 506: The user terminal approaches the near-field communication device and obtains the payment link information via NFC near-field communication.

[0203] Step 508: Launch the payment application and generate payment identifier information based on the locally stored seed information.

[0204] After obtaining the payment link information, the user terminal can launch a payment application with payment functionality. Based on the seed information already existing on the user terminal, payment identification information is generated. This payment identification information can function similarly to a payment code, a type of offline code generated locally on the user terminal. It can trigger the POS device to create an order and initiate a payment process request to the server. The payment identification information can also represent the user terminal's payment account, allowing the server to determine the payment account.

[0205] In some embodiments, the user terminal can pre-store seed information locally before interacting with the near-field communication device, without having payment identification information. After interacting with the near-field communication device, such as after obtaining payment link information, the user terminal or the launched payment application can generate payment identification information based on the seed information. This can avoid the problem of information leakage caused by the user terminal storing payment identification information locally for a long time, and is conducive to improving payment security.

[0206] In some embodiments, for transactions of larger amounts, users may prefer to use contactless payment methods, such as QR code payment or card payment. To reduce user confusion and improve user experience, payment identification information can be generated locally on the user terminal for transactions within a preset limit. Optionally, the server can determine the preset limit based on the user's historical behavior data or the limit information set by the user, or the user terminal can determine the user's preset limit locally.

[0207] For example, the payment link information contains the transaction amount, which can be used to determine whether the transaction amount exceeds a preset limit. If it does not exceed the preset limit, the user terminal can generate payment identification information locally.

[0208] If the amount exceeds the preset limit, the user terminal and / or near-field communication device can prompt the user to use other payment methods. Other methods may be payment processing methods based on short-range communication, or payment by presenting or scanning a payment code image, or payment by swiping a card, etc.

[0209] For example, if the amount exceeds a preset limit, the user terminal can switch to another processing path. For example, if the amount exceeds the preset limit, the user terminal can send an identifier generation request to the server to request the server to generate target payment identifier information representing the user's payment account. After generating the payment identifier information, the server can feed it back to the user terminal, which can then provide it to the near-field communication device (NFC). Alternatively, the server can also send the target payment identifier information to the NFC, allowing the NFC to trigger the payment process based on the target payment identifier information. This can also facilitate the smooth execution of transactions.

[0210] In some embodiments, the user terminal may have judgment logic, such as the server providing the user with a preset credit limit, which may be updated periodically or irregularly. After the user terminal obtains the payment link information containing the transaction amount, it can locally determine whether the limit has been exceeded. If not, it can execute the process of generating payment identification information locally. If the limit has been exceeded, the process of generating payment identification information locally may not be executed.

[0211] In some embodiments, the near-field communication (NFC) device may have judgment logic. The user terminal can provide a preset limit to the NFC device via short-range communication methods such as Bluetooth, NFC, Wi-Fi, or sound waves. Alternatively, the user terminal can request the server to send the user's payment limit to the NFC device. After obtaining the transaction amount information, the NFC device can determine whether the current transaction exceeds the preset limit. If it does not exceed the preset limit, it can trigger the payment process after obtaining the payment identifier information generated locally by the user terminal. If it exceeds the preset limit, it can send an over-limit warning message to the user terminal, either by sending a message through the server or by not executing the subsequent payment process after obtaining the payment identifier information generated locally by the user terminal.

[0212] If the user terminal receives an over-limit notification from the near-field communication device or server before or during the generation of payment identification information, the user terminal can terminate the process of generating payment identification information.

[0213] Step 510: Send payment identification information to the near-field communication device.

[0214] If the user terminal has a good network status, the user terminal can also perform step 512: send the payment identification information and the business identification information contained in the payment link information to the server.

[0215] The steps of the user terminal sending payment identification information to the server and sending payment identification information to the near-field communication device described above can be executed simultaneously or asynchronously. For example, the payment identification information can be sent to the server first and then to the near-field communication device, or vice versa. Step 514: The near-field communication device obtains the payment identification information and sends it to the cash register.

[0216] In some embodiments, the cashier can first enter the information of the goods to be settled into the POS device. The POS device can then send a settlement trigger command to the near-field communication (NFC) device. The NFC device can then generate payment link information, or confirm the payment link information as usable, or write the payment link information into an NFC tag. The user terminal can obtain the payment link information via NFC and send payment identification information back to the NFC device. Alternatively, in some embodiments, before the cashier enters the information of the goods to be settled into the POS device, the user can first touch the user terminal with the NFC device to obtain the payment link information and send payment identification information back to the NFC device. The NFC device then provides the payment identification information to the POS device. After the cashier enters the information of the goods to be settled into the POS device, the POS device then initiates a request to the server based on the payment identification information. The timing of the user terminal sending the payment identification information back to the NFC device can be after the POS device has obtained the information to be settled, before it has obtained it, or during the process of entering the goods information into the POS device. The specific timing is not limited here.

[0217] Cashiers and other personnel can use barcode scanners or similar devices to provide the POS system with information such as the price of the goods to be paid for, or they can manually input this information. The POS system can also provide the acquired information about the goods to be paid for or transaction information to a near-field communication (NFC) device. Transaction data can include the amount to be paid, such as the total amount to be paid and the unit price of the goods. Transaction data can also include product-related information, such as the quantity, name, and category of the goods. Transaction data can also include merchant-related information, such as the merchant name, type, and location. The specific content of the transaction data can be set according to actual needs and is not limited here.

[0218] If the network status of the near-field communication device is good, the near-field communication device can also perform step 516: send the payment identification information and the business identification information contained in the payment link information to the server.

[0219] The steps of sending payment identification information to the server by the near-field communication device and the steps of sending payment identification information to the cash register device described above can be executed simultaneously or asynchronously. For example, the payment identification information can be sent to the server first and then sent to the cash register device, or the payment identification information can be sent to the cash register device first and then sent to the server.

[0220] In some embodiments, the near-field communication device may also have the ability to generate a payment identifier for triggering a payment process or to store a backup payment identifier. For distinction, the payment identifier generated or stored by the near-field communication device is referred to as a payment credential. In one implementation, after a user terminal touches the near-field communication device, the user terminal can provide user-related information to the near-field communication device, and the near-field communication device can generate payment identifier information representing the user's payment account based on the user-related information.

[0221] In another implementation, the near-field communication (NFC) device can generate or acquire a payment credential that is independent of the user but can trigger the payment process. The payment credential may not contain user information from the user terminal. Before the user terminal engages in NFC communication with the NFC device, the payment credential and the user terminal may have no connection; the user information of the user terminal making the payment cannot be determined from the payment credential, or the user information of the user terminal cannot be parsed from the payment credential. This payment credential can be a pre-stored payment credential in the NFC device. For example, the NFC device may have this payment credential before receiving NFC trigger information (such as a card check signal) sent by the user terminal. It can be provided to the NFC device by a server in advance, or it can be generated locally by the NFC device according to preset rules. Alternatively, the NFC device can request and acquire the credential from the server after touching the user terminal or receiving a card check signal sent by the user terminal, or it can be generated locally.

[0222] The payment credential can have the same string format as the payment identification information, both of which can trigger the payment process on the POS device. Specifically, the near-field communication (NFC) device can pre-load one or more payment credentials. When the user terminal touches the NFC device, the NFC device can send the payment credential to the user terminal, either included in the payment link information or sent to the user terminal along with, before, or after the payment link information. Simultaneously, the NFC device can also send the payment credential to the POS device. Since the payment credential can trigger the payment process, if the POS device receives the payment credential, it can send a payment request to the server based on it.

[0223] Step 518: The POS device can send a payment process trigger request to the server based on the obtained payment identifier information.

[0224] The payment process trigger request may include the obtained payment identification information, as well as pending transaction information such as amount, product, and merchant information. This payment process trigger request can also be understood as a payment request, instructing the server to transfer resources for the current transaction.

[0225] If the user terminal touches the near-field communication (NFC) device, the aforementioned process of the NFC device sending a payment credential is also triggered. This can be understood as follows: a single touch event between the user terminal and the NFC device can trigger two parallel processes: one where the user terminal locally generates a payment identifier, and the other where the NFC device sends a payment credential. The actual request for transaction processing from the server can be made by the cash register device. In this case, the cash register device can also initiate a request based on the information it obtains first. If the cash register device obtains the payment credential first, it sends a request to the server based on that credential; if the cash register device obtains the payment identifier information first, it sends a request to the server based on that identifier information. This way, the cash register device can send a request to the server regardless of which information it obtains first, thus improving payment efficiency.

[0226] Step 520: The server triggers a request to process the transaction based on the payment process.

[0227] If the server also receives payment identification information and service identification information from the user terminal or near-field communication device, it can determine the applicable additional services for the local transaction based on the service information corresponding to the service identification information, such as some preferential services, and process the transaction in combination with the additional services. The server can also send the result information back to at least one of the user terminal, near-field communication device, and POS device. The specific process of the POS device initiating the request and the server processing the request can be found in existing related technologies, and will not be elaborated here.

[0228] In some embodiments, the near-field communication device can send the payment voucher to the cash register at the same time as or within a short interval. If the user terminal's network is available or good, the user terminal can send information containing the payment voucher to the server. For example, the user terminal can send information carrying the payment voucher and user-related information to the server. In this way, the server can obtain the association between the payment voucher and the user. If the server receives a request from the cash register containing the payment voucher, it can determine that it is the same transaction. It can also determine the payment voucher, i.e., the user payment account that can be used for this transaction, based on the association between the payment voucher and the user, and then execute the resource transfer process.

[0229] To ensure transmission security, information transmitted between entities such as servers, user terminals, near-field communication devices, or point-of-sale (POS) devices can be encrypted. The receiving entity can have a corresponding decryption program to recover and parse the transmitted information. Information transmitted between entities can also be compressed or encoded to conform to the adopted transmission method.

[0230] In some embodiments, the aforementioned methods—such as the user terminal contacting the near-field communication (NFC) device and the NFC device sending a payment credential to both the user terminal and the cash register, the user terminal generating payment identifier information locally and then providing it to the cash register via the NFC device or a server, and the server generating the target payment identifier—can all be executed in parallel. The cash register can execute the payment process based on whichever information it obtains first, such as sending a request to the server. Executing multiple methods in parallel can further improve payment efficiency, avoid payment failures caused by a single method malfunction, and improve user experience. Based on the same idea, embodiments of this specification also provide apparatus corresponding to the above methods. Figure 6 The embodiments provided in this specification correspond to Figure 2 A schematic diagram of a payment device is provided. This device can be applied to a user terminal, or it can be a user terminal or a component within a user terminal. Figure 6 As shown, the device may include: The information acquisition module 602 is used to acquire payment link information provided by the near-field communication device through near-field communication.

[0231] Application launch module 604 is used to launch the payment application in the device based on the payment link information. Alternatively, it can launch the payment application in the user terminal.

[0232] The identifier generation module 606 is used to generate payment identifier information based on the launched payment application using pre-stored seed information; the seed information is information stored locally on the device before the device obtains the payment link information; the payment identifier information includes identifier information representing the user's payment account. Alternatively, the seed information can be stored locally on the user's terminal.

[0233] The identifier sending module 608 is used to send the payment identifier information to the near-field communication device so that the near-field communication device can trigger the execution of the payment process based on the payment identifier information.

[0234] based on Figure 6 The present specification provides some specific implementation methods for the apparatus, which are described below.

[0235] Optionally, the device or user terminal may have local identification information generation rules. Specifically, generating payment identification information using pre-stored seed information may include processing the seed information using the identification information generation rules to obtain the payment identification information.

[0236] Optionally, the identification information generation rule includes an index string and an encryption algorithm. The above-mentioned processing of the seed information using the identification information generation rule to obtain the payment identification information may specifically include: processing the seed information using the encryption algorithm to obtain a first string; concatenating a preset starting character with the index string and the first string to obtain the payment identification information.

[0237] Optionally, the identification information generation rule further includes an obfuscation algorithm, and the identification generation module 606 can also be used to: based on the obfuscation algorithm, use the first string to obfuscate the index string to obtain a second string. The above-mentioned concatenation of the preset starting character with the index string and the first string to obtain the payment identification information can specifically include: concatenating the preset starting character with the second string and the first string to obtain the payment identification information.

[0238] Optionally, sending the payment identification information to the near-field communication device may specifically include: sending the payment identification information to the near-field communication device via near-field communication; or sending the payment identification information to the near-field communication device via Bluetooth communication; or sending the payment identification information to the near-field communication device via sound waves.

[0239] Optionally, the device may further include a seed acquisition module. Before generating payment identification information using pre-stored seed information, the seed acquisition module may be used to: determine whether the number of usable seed information stored locally on the user terminal is less than or equal to a preset threshold; if the number of usable seed information stored locally on the user terminal is less than or equal to the preset threshold, send a seed acquisition request to the server; and obtain the seed information fed back by the server.

[0240] Optionally, before sending the seed acquisition request to the server, the seed acquisition module can also be used to: determine whether the network status of the user terminal is good. Specifically, sending the seed acquisition request to the server may include: if the network status of the user terminal is good, then sending the seed acquisition request to the server.

[0241] Optionally, the payment link information includes business identifier information representing business information; the business information includes at least one of payment scenario information and near-field communication device (NFC) device information. The device may further include a business identifier sending module, which can be used to: send the payment identifier information and the business identifier information to a server, so that the server can associate the payment identifier information with the business information corresponding to the business identifier information, and process the transaction corresponding to the payment process triggered by the NFC device based on the payment identifier information, based on the business information.

[0242] Optionally, the payment identification information is a string of preset length; the payment identification information can trigger the cash register associated with the near-field communication device to execute the payment process.

[0243] Optionally, the payment identification information has the same starting character as the payment code number, and / or the number of characters in the payment identification information is the same as the number of characters in the payment code number.

[0244] Optionally, the device may further include a result acquisition module for acquiring payment result information representing the payment process and displaying the payment result information.

[0245] Optionally, the result acquisition module can be specifically used to: acquire payment result information transmitted from the near-field communication device to the user terminal via Bluetooth communication; and display a result page containing the payment result information.

[0246] Optionally, the near-field communication device is a first near-field communication device, the payment link information is first payment link information, and the payment identifier information is first payment identifier information. After sending the payment identifier information to the near-field communication device, the device can further be used to: obtain second payment link information provided by a second near-field communication device via near-field communication; the second near-field communication device is a near-field communication device that has conducted other transactions with the user terminal; the second near-field communication device and the first near-field communication device may be the same device or different devices; based on the second payment link information, launch the payment application in the user terminal; based on the launched payment application, generate second payment identifier information using the pre-stored seed information; the second payment identifier information is different from the first payment identifier information; send the second payment identifier information to the second near-field communication device so that the second near-field communication device triggers the execution of the payment process based on the second payment identifier information.

[0247] Figure 7 The embodiments provided in this specification correspond to Figure 3A schematic diagram of a payment device is provided. This device can be applied to near-field communication (NFC) devices, or it can be a NFC device or a component within a NFC device. Figure 7 As shown, the device may include: The information sending module 702 is used to send payment link information to the user terminal via near-field communication, so that the user terminal can generate payment identification information using locally pre-stored seed information; the payment identification information includes account identification information for representing the user's payment account.

[0248] The identifier acquisition module 704 is used to acquire the payment identifier information sent by the user terminal.

[0249] The process triggering module 706 is used to trigger the execution of the payment process based on the payment identifier information.

[0250] Optionally, the device may further include a link acquisition module. Before sending the payment link information to the user terminal via near-field communication, the link acquisition module may be used to: acquire the payment link information provided by the server.

[0251] Optionally, the payment link information includes business identification information representing business information; the business information includes at least one of payment scenario information and near-field communication device information. The link acquisition module described above can be used to acquire the business identification information provided by the server. Based on the business identification information and locally stored fixed information, the payment link information is generated; the fixed information includes at least one of application identification information of the payment application and link prefix information.

[0252] Optionally, obtaining the payment identification information sent by the user terminal may specifically include: obtaining the payment identification information sent by the user terminal via near-field communication; or, obtaining the payment identification information sent by the user terminal via Bluetooth communication; or, obtaining the payment identification information sent by the user terminal via sound waves.

[0253] Optionally, triggering the payment process based on the payment identifier information may specifically include: sending the payment identifier information to a cash register associated with the near-field communication device, so that the cash register executes the payment process based on the payment identifier information.

[0254] Optionally, the payment link information includes business identifier information representing business information; the business information includes at least one of payment scenario information and near-field communication device (NFC) device information. The device may further include a business identifier sending module, used to send the payment identifier information and the business identifier information to a server, so that the server can associate the payment identifier information with the business information corresponding to the business identifier information, and process the transaction corresponding to the payment process triggered by the NFC device based on the payment identifier information, based on the business information.

[0255] Figure 8 The embodiments provided in this specification correspond to Figure 4 A schematic diagram of a payment device. This device can be applied to a server, or it can be a server or a component within a server. Figure 8 As shown, the device may include: The request acquisition module 802 is used to acquire a payment process trigger request. The payment process trigger request is triggered after the near-field communication device acquires the payment identification information provided by the user terminal. The payment identification information is generated by the user terminal based on seed information pre-stored locally on the user terminal.

[0256] The process execution module 804 is used to execute the payment process based on the payment process trigger request and process the transaction of the user terminal.

[0257] Optionally, the above-mentioned acquisition of the payment process trigger request may specifically include: acquiring a payment process trigger request sent by the POS device containing the payment identifier information; the POS device is associated with the near-field communication device, and the near-field communication device acquires the payment identifier information and sends it to the POS device.

[0258] Optionally, the device may further include a seed sending module, which can be used to: obtain a seed information acquisition request sent by the user terminal; and send the seed information to the user terminal based on the seed information acquisition request.

[0259] Optionally, the device may further include an information storage module for storing the correspondence between the seed information and the user terminal.

[0260] Optionally, the step of executing the payment process based on the payment process trigger request may specifically include: determining the payment identifier information contained in the payment process trigger request; parsing the payment identifier information to determine the seed information contained in the payment identifier information; determining the payment account corresponding to the seed information according to the correspondence; and processing the transaction corresponding to the payment process trigger request based on the payment account.

[0261] Optionally, the device may further include a service identifier sending module, used to send service identifier information representing service information to the near-field communication device, so that the near-field communication device generates payment link information for sending to the user terminal based on the service identifier information; the service information includes at least one of payment scenario information and device information of the near-field communication device.

[0262] Optionally, the device further includes a service identifier acquisition module, which can be used to: acquire service identifier information and payment identifier information sent by the user terminal and / or near-field communication device; the service identifier information is identifier information representing service information; the service information includes at least one of payment scenario information and near-field communication device device information; and store the correspondence between the service identifier information and the payment identifier information. The step of executing the payment process and processing the transaction of the user terminal based on the payment process trigger request can specifically include: determining the service identifier information corresponding to the payment identifier information included in the payment process trigger request according to the correspondence; determining the corresponding service information based on the service identifier information; determining additional service according to service processing rules; the additional service includes at least one of preferential service and recommended service; and processing the transaction of the user terminal based on the additional service so that the user of the user terminal can enjoy the additional service.

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

[0264] Figure 9 This is a schematic diagram of the structure of a payment device provided as an embodiment of this specification. Figure 9 As shown, device 900 may include: at least one processor 910; and, Memory 930 communicatively connected to the at least one processor; wherein, The memory 930 stores instructions 920 that can be executed by the at least one processor 910, which, when executed by the at least one processor 910, enable the at least one processor 910 to perform the at least one payment method described above.

[0265] Based on the same approach, embodiments of this specification also provide a computer-readable medium corresponding to the above-described methods. The computer-readable medium stores computer-readable instructions that can be executed by a processor to implement at least one of the above-described payment methods.

[0266] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. In particular, for... Figure 9As the device shown is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

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

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

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

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

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

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

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

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

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

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

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

[0278] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

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

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

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

Claims

1. A payment method applied to a user terminal, comprising: Obtain payment link information provided by near-field communication devices through near-field communication; Based on the payment link information, the payment application in the user terminal is launched; Based on the launched payment application, payment identification information is generated using identification information generation rules; the payment identification information includes identification information used to represent the user's payment account; The payment identifier information is sent to the near-field communication device so that the near-field communication device can trigger the execution of the payment process based on the payment identifier information.

2. The method according to claim 1, wherein the user terminal has seed information for generating payment identification information; The generation of payment identifier information includes: The seed information is processed using the identification information generation rules to obtain the payment identification information.

3. The method according to claim 2, wherein the identification information generation rule includes an index string and an encryption algorithm; the step of processing the seed information using the identification information generation rule to obtain the payment identification information specifically includes: The seed information is processed using the encryption algorithm to obtain the first string; The payment identifier information is obtained by concatenating the preset starting character with the index string and the first string.

4. The method according to claim 3, wherein the index string is associated with the payment account of the user terminal.

5. The method according to claim 3, wherein the identification information generation rule further includes an obfuscation algorithm, and the method further includes: Based on the obfuscation algorithm, the index string is obfuscated using the first string to obtain the second string; The step of concatenating the preset starting character with the index string and the first string to obtain the payment identification information specifically includes: concatenating the preset starting character with the second string and the first string to obtain the payment identification information.

6. The method according to claim 1, wherein the payment identification information is sent to the near-field communication device in at least one of the following ways: The payment identification information is sent to the near-field communication device via near-field communication. The payment identification information is sent to the near-field communication device via Bluetooth. The payment identification information is transmitted to the near-field communication device via acoustic waves; The payment identification information is sent to the near-field communication device via Wi-Fi.

7. The method according to claim 2, further comprising: Determine whether the number of usable seed information stored locally on the user terminal is less than or equal to a preset threshold; If the number of usable seed information stored locally on the user terminal is less than or equal to a preset threshold, a seed acquisition request is sent to the server. Obtain the seed information returned by the server.

8. The method according to claim 7, further comprising, before sending the seed acquisition request to the server: Determine whether the network status of the user terminal is good; Sending the seed acquisition request to the server specifically includes: If the user terminal has a good network connection, a seed acquisition request is sent to the server.

9. The method according to claim 1, wherein the payment link information includes business identification information representing business information; the business information includes at least one of payment scenario information and near-field communication device information; The method further includes: The payment identifier information and the service identifier information are sent to the server so that the server can associate the payment identifier information with the service information corresponding to the service identifier information, and process the transaction corresponding to the payment process triggered by the near-field communication device based on the payment identifier information based on the service information.

10. The method according to claim 1, wherein the payment identification information is a string of preset length; the payment identification information can trigger the cash register associated with the near-field communication device to execute the payment process.

11. The method according to claim 10, wherein the payment identification information has the same starting character as the payment code number, and / or the number of characters in the payment identification information is the same as the number of characters in the payment code number.

12. The method according to claim 1, further comprising: Obtain payment result information representing the payment process; The payment result information is displayed.

13. The method according to claim 12, wherein obtaining payment result information representing the payment process specifically includes: The payment result information transmitted to the user terminal by the near-field communication device via at least one of Bluetooth, NFC, acoustic wave, and Wi-Fi is obtained. The display of the payment result information specifically includes: displaying a result page containing the payment result information.

14. The method according to claim 3, wherein the seed information can be reused; Alternatively, the seed information may be stored in a secure and trusted environment of the user terminal; Alternatively, the seed information may be a string in a preset format; Alternatively, the seed information can be a string that has been encrypted. Alternatively, the seed information may have an expiration date or a valid number of uses.

15. The method according to any one of claims 1 to 14, wherein the payment identification information is different for different transactions.

16. The method according to claim 1, further comprising: If the payment link information contains a transaction amount, determine whether the transaction amount exceeds a preset limit; If the amount does not exceed the preset limit, payment identification information will be generated.

17. The method according to claim 1, further comprising: Send a preset amount to the near-field communication device; The preset limit is the amount that the user terminal can make payments using the generated payment identifier information; The near-field communication device determines whether the current transaction exceeds the preset limit based on the preset limit. If the amount does not exceed the preset limit, the near-field communication device triggers the payment process based on the payment identifier information.

18. The method according to claim 16 or 17, if the amount exceeds the preset limit, the user is prompted to use other payment methods to make the payment.

19. The method according to claim 16 or 17, if the amount exceeds the preset limit, an identifier generation request is sent to the server to request the server to generate target payment identifier information representing the user's payment account; The target payment identifier information is sent to the near-field communication device so that the near-field communication device can trigger the execution of the payment process based on the target payment identifier information; the target payment identifier information is sent to the near-field communication device by the user terminal or by the server.

20. The method according to claim 1, wherein the payment identification information is encrypted and then sent to a near-field communication device.

21. The method according to claim 1, wherein the payment link information includes an encryption factor, and the payment identifier information is encrypted based on the encryption factor.

22. The method according to claim 1, wherein at least a portion of the information in the payment link information and / or the user information of the user terminal are sent to a near-field communication device.

23. A payment method applied to a near-field communication device, the method comprising: Payment link information is sent to the user terminal via near-field communication, so that the user terminal can generate payment identification information using identification information generation rules; the payment identification information includes account identification information representing the user's payment account; Obtain the payment identification information sent by the user terminal; The payment process is triggered based on the payment identifier information.

24. The method according to claim 23, further comprising, before sending the payment link information to the user terminal via near-field communication: Obtain the payment link information provided by the server.

25. The method according to claim 23, wherein the near-field communication device locally generates payment link information, or the near-field communication device has multiple backup payment link information.

26. The method according to claim 24, wherein the payment link information includes business identification information representing business information; the business information includes at least one of payment scenario information and device information of the near-field communication device; The step of obtaining the payment link information provided by the server specifically includes: obtaining the business identification information provided by the server; The method further includes: generating the payment link information based on the business identification information and locally stored fixed information; the fixed information includes at least one of the application identification information of the payment application and the link prefix information.

27. The method according to claim 23, wherein obtaining the payment identifier information sent by the user terminal specifically includes: The payment identification information is obtained by the user terminal through at least one of near-field communication, Bluetooth, sound waves, and Wi-Fi.

28. The method according to claim 23, wherein the user terminal sends payment identification information via multiple methods selected from near-field communication, Bluetooth, sound waves, and Wi-Fi; The near-field communication device triggers the payment process using the payment identifier information obtained first.

29. The method according to claim 23, wherein triggering the payment process based on the payment identifier information specifically includes: The payment identifier information is sent to the cash register associated with the near-field communication device so that the cash register executes the payment process based on the payment identifier information.

30. The method according to claim 23, wherein the payment link information includes business identification information representing business information; the business information includes at least one of payment scenario information and device information of the near-field communication device; The method further includes: The payment identifier information and the service identifier information are sent to the server so that the server can associate the payment identifier information with the service information corresponding to the service identifier information, and process the transaction corresponding to the payment process triggered by the near-field communication device based on the payment identifier information based on the service information.

31. A payment method applied to a server, comprising: Obtain a payment process trigger request, which is triggered by the near-field communication device after obtaining payment identification information provided by the user terminal; The payment identification information is generated by the user terminal based on the identification information generation rules. Based on the payment process trigger request, the payment process is executed to process the transaction on the user terminal.

32. The method according to claim 31, wherein the step of obtaining the payment process trigger request specifically includes: Obtain a payment process trigger request sent by the POS device, which includes the payment identifier information; The POS device is associated with the near-field communication device, and the near-field communication device sends the payment identification information to the POS device after obtaining it.

33. The method according to claim 31, further comprising, before the payment process trigger request: Obtain the seed information acquisition request sent by the user terminal; Based on the seed information acquisition request, the seed information is sent to the user terminal.

34. The method according to claim 33, further comprising: The correspondence between the seed information and the user terminal is saved.

35. The method of claim 31, comprising: Determine the payment identifier information contained in the payment process trigger request; Parse the payment identifier information to determine the seed information contained in the payment identifier information; Based on the correspondence, determine the payment account corresponding to the seed information; The transaction corresponding to the payment process trigger request is processed based on the payment account.

36. The method according to claim 31, further comprising, before the payment process trigger request is obtained: The service identification information representing the service information is sent to the near-field communication device, so that the near-field communication device generates payment link information for sending to the user terminal based on the service identification information; the service information includes at least one of payment scenario information and device information of the near-field communication device.

37. The method according to claim 31, further comprising: Obtain the service identification information and the payment identification information sent by the user terminal and / or near-field communication device; The service identification information is identification information representing service information; the service information includes at least one of payment scenario information and near-field communication device information. Save the correspondence between the business identifier information and the payment identifier information; The step of triggering a payment process based on the payment process request, executing the payment process, and processing the transaction on the user terminal specifically includes: Based on the correspondence, determine the business identifier information corresponding to the payment identifier information contained in the payment process trigger request; Based on the business identification information, the corresponding business information is determined; Based on the business processing rules, additional business services are determined; the additional business services include at least one of preferential services and recommended services. Based on the aforementioned service add-on, transactions of the user terminal are processed so that the user of the user terminal can enjoy the aforementioned service add-on.

38. A payment device, comprising: The information acquisition module is used to acquire payment link information provided by the near-field communication device via near-field communication. An application launch module is used to launch the payment application in the device based on the payment link information; The identifier generation module is used to generate payment identifier information based on the launched payment application and using identifier information generation rules; the payment identifier information includes identifier information representing the user's payment account; The identifier sending module is used to send the payment identifier information to the near-field communication device so that the near-field communication device can trigger the execution of the payment process based on the payment identifier information.

39. A payment device, comprising: The information sending module is used to send payment link information to the user terminal via near-field communication, so that the user terminal can generate payment identification information using identification information generation rules; the payment identification information includes account identification information representing the user's payment account; The identifier acquisition module is used to acquire the payment identifier information sent by the user terminal; The process triggering module is used to trigger the execution of the payment process based on the payment identifier information.

40. A payment device, comprising: The request acquisition module is used to acquire the payment process trigger request, which is triggered after the near-field communication device acquires the payment identification information provided by the user terminal; The payment identification information is generated by the user terminal using identification information generation rules; The process execution module is used to trigger a request based on the payment process, execute the payment process, and process the transactions of the user terminal.

41. A payment device, comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the payment method according to any one of claims 1 to 37.

42. A computer-readable medium having stored thereon computer-readable instructions that can be executed by a processor to implement the payment method of any one of claims 1 to 37.

Images