A payment method, apparatus, device and medium

Abstract

The embodiments of the present specification disclose a payment method, device, equipment and medium. The scheme comprises: acquiring near field communication trigger information sent by a user terminal; based on the near field communication trigger information, sending a payment voucher for triggering a transaction process to the merchant device; the payment voucher is generated before the near field communication device acquires the near field communication trigger request, and is used to trigger the merchant device to initiate a payment request to the server; the payment voucher does not contain user information of the user terminal; based on the near field communication trigger information, the payment voucher is sent to the user terminal; the payment voucher is used to be sent to the server by the user terminal, so that the server processes the payment request initiated by the merchant device.

Description

[0001] This application is a divisional application of the invention application entitled "A payment method, device, equipment and medium", with parent application number "202510798180.0" and parent application date of June 13, 2025. 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] With the development of computer technology, electronic payment is increasingly used in offline consumption, and various electronic payment methods are constantly emerging, such as QR code payment, facial recognition payment, palm print payment, and tap-to-pay based on near-field communication (NFC). Among these, tap-to-pay based on NFC is attracting more users due to its simpler operation. Therefore, how to further improve the user experience has become a pressing technical problem to be solved. Summary of the Invention

[0004] This specification provides a payment method, apparatus, device, and medium to improve user experience.

[0005] To solve the above-mentioned technical problems, the embodiments in this specification are implemented as follows.

[0006] This specification provides an embodiment of a payment method applied to a near-field communication device associated with a merchant's device, comprising: Obtain near-field communication trigger information sent by the user terminal; Based on the near-field communication trigger information, a payment credential for triggering the transaction process is sent to the merchant device; the payment credential is generated before the near-field communication device receives the near-field communication trigger request, and is used to trigger the merchant device to initiate a payment request to the server; the payment credential does not contain the user information of the user terminal; Based on the near-field communication trigger information, the payment credential is sent to the user terminal; the payment credential is used by the user terminal to send to the server so that the server can process the payment request initiated by the merchant device.

[0007] This specification provides an embodiment of a payment method applied to a server, including: The system retrieves a payment request sent by a merchant device. The payment request is generated by the merchant device based on a first payment credential provided by a near-field communication (NFC) device associated with the merchant device. This first payment credential is generated before the NFC device receives NFC trigger information sent by the user terminal. The payment credential is used to trigger the merchant device to initiate a payment request to the server. The payment credential does not contain user information from the user terminal. Obtain payment confirmation information containing a second payment credential sent by the user terminal; If the first payment voucher is the same as the second payment voucher, the payment request is processed based on the user information of the user terminal.

[0008] This specification provides an embodiment of a payment method applied to a user terminal, including: Send near-field communication trigger information; Obtain a payment credential sent by a near-field communication device in response to the near-field communication triggering information; the payment credential is generated before the near-field communication device obtains the near-field communication triggering request; the payment credential does not include the user information of the user terminal; Based on the payment voucher, the transaction process is triggered.

[0009] This specification provides an embodiment of a payment device applied to a near-field communication device associated with a merchant's device, comprising: The trigger information acquisition module is used to acquire near-field communication trigger information sent by the user terminal; The first credential sending module is used to send a payment credential to the merchant device to trigger a transaction process based on the near-field communication trigger information; the payment credential is generated before the near-field communication device receives the near-field communication trigger request, and is used to trigger the merchant device to initiate a payment request to the server; the payment credential does not contain the user information of the user terminal; The second credential sending module is used to send the payment credential to the user terminal based on the near-field communication trigger information; the payment credential is used by the user terminal to send to the server so that the server can process the payment request initiated by the merchant device.

[0010] This specification provides an embodiment of a payment device applied to a server, comprising: The request acquisition module is used to acquire a payment request sent by a merchant device; the payment request is generated by the merchant device based on a first payment credential provided by a near-field communication device associated with the merchant device; the first payment credential is a payment credential generated by the near-field communication device before it acquires near-field communication trigger information sent by the user terminal; the payment credential is used to trigger the merchant device to initiate a payment request to the server; the payment credential does not contain user information of the user terminal; The confirmation information acquisition module is used to acquire payment confirmation information containing the second payment voucher sent by the user terminal; The payment processing module is used to process the payment request based on the user information of the user terminal if the first payment voucher is the same as the second payment voucher.

[0011] This specification provides an embodiment of a payment device applied to a user terminal, comprising: The trigger information sending module is used to send near-field communication trigger information; The credential acquisition module is used to acquire a payment credential sent by a near-field communication device in response to the near-field communication triggering information; the payment credential is generated before the near-field communication device acquires the near-field communication triggering request; the payment credential does not include the user information of the user terminal; The transaction processing module is used to trigger the execution of the transaction process based on the payment voucher.

[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 that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the aforementioned payment method.

[0013] This specification provides an embodiment of a computer-readable medium storing computer-readable instructions that can be executed by a processor to implement a payment method.

[0014] At least one embodiment of this specification can achieve the following beneficial effects: In the embodiments of this specification, after the near-field communication device associated with the merchant device receives the near-field communication trigger information sent by the user terminal, it can send a pre-generated payment credential for triggering the transaction process to the merchant device. This allows the merchant device to execute the transaction process based on the payment credential; for example, the merchant device can send a payment request to the server based on the payment credential. After receiving the near-field communication trigger information sent by the user terminal, the near-field communication device can also send the payment credential to the user terminal, allowing the user terminal to also execute the corresponding transaction process. For example, the user terminal can send the payment credential to the server, so that the server can process the transaction between the merchant device and the user terminal that sent the same payment credential. The payment credential sent by the near-field communication device to both the merchant device and the user terminal may not contain the user terminal's user information. This payment credential may be pre-stored in the near-field communication device before receiving the near-field communication trigger signal from the user terminal. This way, the merchant device does not need to wait for the user terminal to directly or indirectly provide its user information before executing the transaction process, allowing the payment processes executed by the merchant device and the user terminal to proceed synchronously. This reduces the overall payment process time, decreases user waiting time, allows users to complete transactions faster, and improves the 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 as described 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 3A 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 9 This is a schematic diagram of the structure of a payment device provided in an embodiment of this specification. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of one or more embodiments of this specification clearer, the technical solutions of one or more embodiments of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of one or more embodiments of this specification.

[0018] The terminology used in one or more embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this application. The singular forms “a,” “the,” and “the” used in one or more embodiments of this application and in 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” used in one or more embodiments of this application 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 application, 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 application, 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] To clearly illustrate the implementation methods of the various embodiments in this specification, some terms are explained below.

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

[0022] 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.

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

[0024] 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 some information from the phone to the payment device, which acts as the tag. A device in this mode can be called a card reader device.

[0025] 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.

[0026] 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 together; and swapping characters or sharing items in multiplayer games.

[0027] 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.

[0028] 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 a 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.

[0029] Currently, there are two main 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 is in card emulation mode, and the merchant device 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 sends information representing its user information to the merchant, or requests the server to send this information. The merchant, upon receiving the user information, executes the transaction process, such as sending a payment request to the server. The server then processes the transaction between the merchant and the user. In the second NFC-based payment solution, before the server processes the transaction, the merchant needs to obtain the user information provided by the user terminal or request it from the server before submitting a processing request. The steps performed by the merchant and user terminal are similar to a sequential process.

[0030] To further improve transaction processing efficiency 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 as described in the embodiments of this specification. For example... Figure 1As shown, this scheme may include a user terminal 1, a near-field communication (NFC) device 2, a merchant device 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. When the user terminal 1 and NFC device 2 are close together, for example, when the user touches the NFC device, the NFC device 2 can respond to the NFC trigger signal from the user terminal 1 and send a payment credential to both the merchant device 3 and the user terminal 1. This payment credential can be information used to trigger the merchant device to execute the payment process; for example, it may resemble a payment code string. However, this payment credential is unrelated to the user terminal before it is sent from the NFC device to the user terminal, and the user terminal's relevant information, such as the payment account, cannot be determined solely from this payment credential. After obtaining the payment credential, the merchant device 3 can send a payment request to the server 4, requesting the server to settle the current transaction. After obtaining the payment credential, the user terminal 1 can send the payment credential along with its information to the server so that the server can determine the payer. After receiving the payment voucher sent by the user terminal and the payment request containing the payment voucher sent by the merchant device, the server can process the request and handle the transaction between user terminal 1 and merchant device 3. This allows merchant device 3 and user terminal 1 to execute their respective transaction processes in parallel, shortening the overall transaction time and enabling users to obtain transaction results faster, thus improving the user experience.

[0031] In some embodiments, the near-field communication device 2 provides a payment credential to the merchant device. This credential is information that can trigger the merchant device to execute the payment process. However, the payment credential does not contain the user's information, and payment cannot actually occur based solely on this credential. The server can only determine the two parties to the transaction and actually execute the transaction after receiving a payment request containing the payment credential from the merchant device and a confirmation message containing the payment credential from the user terminal that sent the same credential.

[0032] 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.

[0033] 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 or movable and placed at the checkout counter, or it can be a component located in a self-checkout device or an electronic device connected to the self-checkout device via wired or wireless means.

[0034] Merchant device 3 can be a device capable of processing transactions, or it can be a device with a cashier function, such as a cashier counter, POS machine, self-service checkout device, smart vending machine, etc.

[0035] In some embodiments, the near-field communication device 2 and the merchant 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 merchant device, all of which can associate the near-field communication device 2 with the merchant device 3. From a hardware perspective, the near-field communication device 2 and the merchant 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.

[0036] 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.

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

[0038] 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 mounted on a near-field communication (NFC) device. From a hardware perspective, the entity executing the process can be the NFC device itself.

[0039] like Figure 2 As shown, the process may include the following steps.

[0040] Step 202: Obtain the near-field communication trigger information sent by the user terminal.

[0041] The user terminal can act as a near-field communication (NFC) reader device, sending NFC trigger information to initiate NFC communication. Specifically, the user terminal's NFC function can be enabled and it can be in reader mode, sending electromagnetic signals to establish NFC communication. In some embodiments, the user terminal can be in card detection mode, transmitting a card detection signal to detect the presence of an NFC tag or NFC card 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. The user terminal, acting as a NFC reader device, can also write data into the NFC device and use the NFC device to transmit data.

[0042] In some embodiments, the NFC reader mode can be activated when the user terminal is unlocked. For example, when making a payment, the user first unlocks their mobile phone or smartwatch, which can then activate the NFC reader mode and send a near-field communication (NFC) trigger message. Alternatively, before making a payment, the user may be using their mobile phone or smartwatch, which can remain in NFC reader mode throughout the process, sending NFC trigger messages via low-power card detection mode or normal card detection mode. The user can bring the user terminal close to or touch the NFC device, allowing the user terminal to detect the NFC tag or card in the NFC device and read the tag information via NFC.

[0043] Near-field communication (NFC) devices can be devices associated with merchant devices that have NFC functionality. They can serve as auxiliary devices to help merchants complete transactions and can also be called auxiliary payment devices, auxiliary transaction devices, etc.

[0044] This allows merchants who previously did not support transactions based on near-field communication (NFC) to also conduct transactions via NFC. For the merchant, no modifications are needed to their equipment, enabling them to conduct transactions via NFC at a low cost, or even without any additional cost.

[0045] In one implementation, the near-field communication (NFC) device can be associated with the merchant's device via wired or wireless means. For example, the NFC device can be connected to the merchant's device via a USB cable or other form of cable; or the NFC device and the merchant's device can be on the same wired or wireless network.

[0046] As another implementation method, the near-field communication (NFC) device can establish a binding relationship with a merchant's device. For example, the binding relationship can be established through a mobile terminal such as a smartphone within an application, mini-program, or webpage used to establish the binding relationship. Alternatively, if the NFC device has an operable interface or screen, the binding relationship can also be established by accessing the application, mini-program, or webpage used to establish the binding relationship through the NFC device. Similarly, if the merchant's device has an operable interface or screen, the binding relationship can also be established by accessing the application, mini-program, or webpage used to establish the binding relationship through a POS device. 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 technical descriptions. The specific method is not limited here, as long as it enables the NFC device and the merchant's device to have an association.

[0047] 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.

[0048] Step 204: Based on the near-field communication trigger information, send a payment voucher to the merchant device to trigger the transaction process.

[0049] The payment credential is generated by the near-field communication device before it receives the near-field communication trigger request, and is used to trigger the merchant device to initiate a payment request to the server; the payment credential may not contain the user information of the user terminal.

[0050] Payment credentials can be information that enables a merchant's device to trigger the execution of a transaction process. These payment credentials can be pre-stored in the near-field communication device. The near-field communication device can have these payment credentials before it receives the near-field communication trigger information sent by the user terminal. For example, they can be provided to the near-field communication device in advance by the server or generated locally by the near-field communication device in advance according to preset rules.

[0051] The payment credential may not contain user information of the user terminal that sent the near-field communication trigger information. In other words, before the user terminal engages in near-field communication with the near-field communication device, the payment credential and the user terminal may have no association. The user information of the user terminal making the payment cannot be determined from the payment credential, or it cannot be parsed from the payment credential. Before the server receives the payment credential sent by the user terminal, the server may not have a corresponding relationship between the payment credential and the user terminal.

[0052] Payment vouchers can be in the form of strings. For example, they can contain one or more characters such as numbers, symbols, etc., with a preset length.

[0053] In some embodiments, to distinguish different users, after a user registers on the online platform, the system automatically assigns the user a User Identification (UID) value, which represents the user's unique identifier. Different users have different UIDs. As one implementation method, user information can be information related to the user that can uniquely identify them. Specifically, user information can be the user's UID. Of course, user information can also be other information that can uniquely identify a user, such as the user's payment account information, email address, ID card number, mobile phone number, etc. The specific content of the user information is not limited here, as long as it can uniquely identify the user or the account used for payment.

[0054] As one implementation method, the payment voucher can have the same format as the payment code number.

[0055] The payment code data can be a number representing the payment code. When a merchant cannot scan the QR code, payment can be completed by manually entering this string of numbers. In the embodiments of this specification, the payment voucher can have the same format as the payment code number, such as the same number of characters, character type, etc.

[0056] Optionally, the payment voucher may have the same starting character as the payment code number, and / or the number of characters in the payment voucher may be the same as the number of characters in the payment code number.

[0057] 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 voucher and the payment code numbers are the same; or the first two, three, or four characters of the payment voucher and the payment code numbers are the same. For example, both the payment voucher and the payment code numbers are strings that start with "28", or both are strings that start with "13", etc.

[0058] 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.

[0059] In the embodiments of this specification, the number of characters contained in the payment voucher can be the same as the number of characters contained in the payment code. For example, the payment voucher can be 16 or 18 characters, or 17 characters, or 13 characters, etc. Alternatively, the payment voucher can be a string of pure numbers of 16, 18, 17, or 13 characters. Or, the payment voucher may contain a portion consisting of 5 consecutive numbers, or a portion consisting of 3 consecutive letters, etc.

[0060] In some related technologies, a merchant 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 transaction 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 merchant device; the meaning of the payment code information or the corresponding user account is maintained by the server. For the merchant, if they obtain information conforming to a preset format, they can trigger the payment process. The specific information format can be pre-agreed upon between the merchant and the server, or the merchant can process it according to a preset protocol.

[0061] In the embodiments of this specification, the payment voucher can have the same format as the payment code number, which can reduce or even eliminate the need for modifications to the merchant side, allowing merchants to continue using existing programs or hardware devices. For example, for the widely used QR code payment, the merchant can trigger the payment process after obtaining the information representing the payment code. For instance, the merchant device can trigger the payment process after obtaining a 28-digit code or an 18-digit pure number. The payment voucher in the embodiments of this specification can also be a string conforming to the 28-digit code format, but this string is unrelated to the user terminal or user account, and can be random or a string that does not represent any special meaning. For example, the payment code number that can truly represent the user's terminal and user account is 28**0020**0040*6*0. After obtaining this payment code number, the server can parse it according to preset rules to obtain the user account corresponding to the payment code number. In this embodiment of the specification, the payment voucher can be 2*33**55**7*8*9*00. After the server obtains this payment voucher and parses it according to preset rules, it cannot obtain the corresponding user account. This payment voucher can be used by the server to identify the two parties involved in the same transaction, but it cannot be used to deduce the actual user account. Simply using this payment voucher cannot result in actual payment.

[0062] Of course, in some embodiments, the merchant device has a dedicated processing flow for payment vouchers. The format of the payment voucher may differ from that of the payment code number. It can be a format negotiated between the server administrator and the merchant device owner, as long as it can be recognized by the merchant device and the server to trigger the corresponding business process. The specific format of the payment voucher is not limited here. Step 206: Based on the near-field communication trigger information, send the payment voucher to the user terminal.

[0063] The payment credential is used by the user terminal to send to the server so that the server can process the payment request initiated by the merchant device.

[0064] To facilitate user terminal identification, as one implementation method, the near-field communication device can send the payment credential to the user terminal in the form of a link. For example, https: / / aa.bb.cc.2*33**55**7*8*9*00.dd, this link can contain the payment credential. After obtaining the link, the user terminal can access the link or retrieve the payment credential from the link and send it to the server. In this way, the server can determine the correspondence between the payment credential and the user terminal, and can also identify the two parties involved in the same transaction based on the payment credential, and process the transaction.

[0065] For example, a link can contain information representing a payment voucher, such as https: / / aa.bb.cc.AA.dd, where AA is a shorter string obtained by processing the original payment voucher 2*33**55**7*8*9*00 according to a preset compression rule. After obtaining the link, the user terminal can restore AA according to the corresponding decompression rule to obtain the original payment voucher 2*33**55**7*8*9*00.

[0066] Of course, payment vouchers do not have to be sent to the user terminal in the form of a link. There are no restrictions on the method of sending payment vouchers, as long as the near-field communication device can send the same payment voucher to both the user terminal and the merchant device after a single contact with the user terminal.

[0067] Similarly, near-field communication devices can also provide payment credentials to merchant devices via a link. Alternatively, they can provide payment credentials to merchant devices without a link, such as providing them directly to the merchant device. No specific limitations are specified here.

[0068] In the embodiments described in this specification, the user terminal sends a near-field communication (NFC) trigger message. Upon triggering this message, a near-field communication device within the user terminal's NFC range can send a payment credential to the merchant device, enabling the merchant device to execute a transaction based on the payment credential. The NFC device can also send the payment credential to the user terminal, allowing the user terminal to execute the corresponding transaction process. This allows the user terminal and merchant device to execute their respective process steps synchronously or in parallel. Compared to methods where the merchant must wait for the user terminal to execute certain transaction steps before starting their own, such as in some payment methods where the user terminal, after obtaining NFC tag information, first requests the server to send credential information representing the user terminal's payment account to the merchant device, and then the merchant device triggers the payment process based on this credential information, this method requires sequential execution of the processes on both the merchant and user terminal sides, resulting in significant time consumption. The embodiments described in this specification allow the merchant and user terminal sides to execute their respective steps in parallel, effectively reducing the overall transaction time.

[0069] In some embodiments, the near-field communication device can simultaneously send payment credentials to both the user terminal and the merchant device; alternatively, the near-field communication device can first send the payment credentials to the merchant device, and then send the payment credentials to the user terminal within a short period of time; or alternatively, the near-field communication device can first send the payment credentials to the user terminal, and then send the payment credentials to the merchant device within a short period of time. The specific order of these actions is not limited here.

[0070] In some embodiments, a user can bring their user terminal close to the near-field communication (NFC) device, allowing the NFC device to receive NFC trigger information sent by the user terminal. The NFC device can be a device with an NFC tag or a device with a NFC card emulation mode. The NFC device may also have a storage unit where payment credentials can be stored. If the NFC device has an NFC tag, the payment credentials can be stored in the NFC tag; if the NFC device is a device with a NFC card emulation mode, the payment credentials can be stored in the card emulation mode's storage unit.

[0071] In some embodiments, the near-field communication device can provide payment credentials to the merchant device in at least one of the following ways.

[0072] In one implementation, if the near-field communication device (NFC) and the merchant device are connected via a data cable, the NFC can provide the payment credential to the merchant device through the data cable. For example, if the NFC and the merchant device are connected via a USB cable, the NFC can transmit the payment credential to the merchant device via the USB cable after the user terminal comes into contact with the NFC.

[0073] In one implementation, if the near-field communication (NFC) device and the merchant's device are connected via a wireless network, the NFC device can provide the payment credential to the merchant's device through the wireless network. For example, if the NFC device is located in the merchant's local area network, or if the NFC device and the merchant's device are on the same network address, the NFC device can transmit the payment credential to the merchant's device via the network after the user terminal touches the NFC device.

[0074] In one implementation, if both the near-field communication device and the merchant device can communicate with the server, the near-field communication device can send the payment voucher to the server, and the server can then send the payment voucher to the merchant device.

[0075] For example, when a user terminal comes into contact with a near-field communication (NFC) device, the NFC device receives NFC trigger information sent by the user terminal. The NFC device can then send a request containing payment credentials to a server. This request may also include the NFC device's identifier. The server stores a mapping between NFC devices and merchant devices using those devices. Based on the NFC device's identifier, the server can determine the corresponding merchant device and send the payment credentials to that device. Alternatively, the request may include the merchant device's identifier, allowing the server to send the payment credentials to the merchant device based on that identifier.

[0076] For example, when a user terminal comes into contact with a near-field communication (NFC) device, the NFC device receives NFC trigger information sent by the user terminal. The NFC device can then send a credential issuance request to the server. The server, based on a pre-stored mapping between NFC devices and merchant devices, can send the payment credential stored on the server to the merchant device. Alternatively, the credential issuance request may include the merchant device's identifier, allowing the server to send the payment credential to the merchant device based on that identifier. The server can also send the payment credential to the NFC device, enabling the NFC device to forward the payment credential to the user terminal.

[0077] In some embodiments, the near-field communication device may use one or more of the above methods to provide payment credentials to the merchant device. The specific method can be set according to actual needs and is not specifically limited here.

[0078] Near-Field Communication (NFC) devices can send payment credentials to user terminals via NFC. As one implementation, the NFC tag information contained within the NFC device can include the payment credential. The user terminal, acting as an NFC reader, can obtain the NFC tag information from the NFC device and thus acquire the payment credential. For details on the specific process of transmitting information via NFC, please refer to relevant technical descriptions; they will not be elaborated upon here.

[0079] The user terminal can also send the obtained payment voucher to the server, so that the server can identify the user terminal that transacted with the merchant and process the payment request initiated by the merchant.

[0080] In the embodiments of this specification, the payment voucher obtained by the merchant device may not contain relevant information about the user terminal, and the payment request sent by the merchant device to the server may also not contain relevant information about the user terminal. After only obtaining the payment request sent by the merchant, the server cannot determine the counterparty to the transaction with the merchant device. After the user terminal sends the payment voucher to the server, the server can determine the user terminal to which the transaction is being conducted based on the payment voucher, and thus determine the two parties to the transaction, and further process the payment request sent by the merchant device.

[0081] It should be understood that the order of some steps in the methods described in one or more embodiments of this specification may be interchanged according to actual needs, or some steps may be omitted or deleted.

[0082] Figure 2The method described involves a near-field communication (NFC) device associated with a merchant device receiving NFC trigger information from a user terminal. The NFC device can then send a pre-generated payment credential to the merchant device to trigger a transaction. The merchant device can then execute the transaction based on this credential, such as sending a payment request to a server. Similarly, the NFC device can also send the payment credential to the user terminal after receiving the NFC trigger information, allowing the user terminal to execute the corresponding transaction. For example, the user terminal can send the payment credential to a server so the server can process transactions between the merchant device and the user terminal that sent the same payment credential. The payment credential sent by the NFC device to both the merchant device and the user terminal may not contain the user terminal's user information. This payment credential can be pre-stored in the NFC device before receiving the NFC trigger signal from the user terminal. This eliminates the need for the merchant device to wait for the user terminal to provide its user information directly or indirectly before executing the transaction. For example, in existing technologies, the user terminal needs to confirm the transaction information first, and then the user terminal or server provides the merchant with the credential information used to trigger the merchant to execute the transaction process, such as providing the user terminal's payment code information to the merchant, who then executes the corresponding transaction process. The method in the embodiments of this specification allows the payment process executed by the merchant's device and the user terminal to be synchronized, thereby reducing the overall payment process time, reducing user waiting time, allowing users to complete transactions faster, and improving user experience.

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

[0084] To facilitate user terminals in identifying information provided by near-field communication (NFC) devices, the information contained in the NFC tag of the NFC device can be in the form of a link. Optionally, the method in the embodiments of this specification may further include: Based on the payment credential, payment link information containing the payment credential is generated; the payment link information is in the form of a link. Sending the payment credential to the user terminal may specifically include: sending the payment link information containing the payment credential to the user terminal.

[0085] The payment credential can be information obtained by the near-field communication device from the server before receiving near-field communication trigger information sent by the user terminal, or information pushed by the server to the near-field communication device and stored locally on the near-field communication device. Alternatively, the payment credential can be information generated locally by the near-field communication device according to preset rules before or after receiving near-field communication trigger information sent by the user terminal.

[0086] Payment link information can be a link generated by a near-field communication device after obtaining a payment credential, following a preset link template. For example, link information starting with http or https.

[0087] The payment link information may directly contain payment credentials, or it may contain information that represents the payment credentials after encryption or rule processing. The payment link information may contain payment credentials directly or indirectly; no specific limitations are imposed here.

[0088] The payment link information can be generated by the near-field communication device before it receives the near-field communication trigger information sent by the user terminal, or it can be generated by the near-field communication device after it receives the near-field communication trigger information sent by the user terminal.

[0089] In some embodiments, the payment link information may also be generated by the server. Alternatively, the server may provide payment link information containing the payment credential to the near-field communication device shortly before, after, or simultaneously with the server providing the payment credential to the near-field communication device.

[0090] To facilitate users' understanding of transaction information, the near-field communication device in this embodiment can also obtain transaction information provided by the merchant, such as amount information, information on the goods purchased by the user, etc. Optionally, the method in this embodiment may further include: Obtain transaction data provided by the merchant's device; the transaction data includes at least one of the following: amount information to be transacted, product information, and merchant information; The above-mentioned generation of payment link information containing the payment voucher based on the payment voucher may specifically include: generating payment link information containing the transaction data and the payment voucher based on the transaction data and the payment voucher.

[0091] In some embodiments, cashiers or other personnel can provide information such as the price of the goods to be paid for to the merchant's device via a barcode scanner or other device, or by manually entering the information. The merchant's device can then provide the obtained information about the goods to be paid for or transaction information to a near-field communication device.

[0092] Transaction data can include information about the amount to be transacted, such as the total amount to be paid and the unit price of the goods. It can also include product-related information, such as the quantity, name, and category of the goods. Furthermore, it can include merchant-related information, such as the merchant name, type, and location. The specific content of the transaction data can be customized according to actual needs and is not limited here.

[0093] In the embodiments of this specification, the payment link information provided by the near-field communication device to the user terminal may also include transaction data. The payment link information may directly or indirectly contain transaction information. For example, the transaction information may be included in plaintext in the payment link information, or the near-field communication device may process the transaction data according to preset rules, such as encryption, compression, or tokenization, to obtain information that represents the transaction information, which can then be included in the payment link information. For example, the payment link information is: https: / / aa.bb.cc.2*33**55**7*8*9*00.$20, which may contain the payment voucher 2*33**55**7*8*9*00 and the amount to be paid 20.

[0094] In the embodiments of this specification, the near-field communication device can generate payment link information containing both payment credentials and transaction data. After obtaining the payment link information, the user terminal can also provide the payment credentials and transaction data to the server so that the server can process the transaction data.

[0095] If the payment request sent by the merchant's device to the server also includes transaction data, the server can use that transaction data to identify the user who transacted with that merchant's device. This allows the server to determine the user based on both payment credentials and transaction data, thus improving transaction accuracy.

[0096] Considering that user terminals can obtain payment link information from near-field communication (NFC) devices via NFC, and the amount of data transmitted affects transmission time, to enable user terminals to obtain payment link information from NFC devices as quickly as possible, the NFC devices can compress transaction data and / or payment vouchers to obtain compressed information, generating payment link information containing the compressed information. The user terminal can have a corresponding decompression program, which, after obtaining the payment link information from the NFC device, can also decompress the compressed information in the payment link information to restore the transaction data and / or payment vouchers.

[0097] Of course, the user terminal can also access the server based on the compressed information, providing the compressed information to the server, which will then perform decompression to restore the transaction data and / or payment vouchers. In this way, the user terminal can avoid performing the decompression process. The specific data transmission and processing methods can be set according to actual needs and are not specifically limited here.

[0098] Optionally, after obtaining the payment link information, the user terminal can access the payment link information and display a page containing transaction information. This page may contain operable controls, such as confirmation controls. The user terminal can provide information indicating transaction confirmation to the server based on this page. After receiving the confirmation information provided by the user terminal, the server can process the payment request provided by the merchant device.

[0099] In some embodiments, to improve user experience, the payment link information may optionally include at least one of the following: application identifier information of the payment application, business identifier information for representing the payment business, merchant identifier information of the merchant device, transaction amount information, and device identifier information of the near-field communication device.

[0100] The payment application can be a terminal application with payment functionality, such as an app or mini-program. The application identifier information of the payment application can be information that uniquely identifies the payment application, such as its name, abbreviation, or package name. Different user terminals or user terminals on different systems can identify the corresponding payment application based on this application identifier information.

[0101] If the payment link information contains the application identifier of the payment application, the user terminal can launch the corresponding payment application based on the application identifier after obtaining the payment link information, and execute the corresponding transaction process within the payment application. For example, a payment credential can be sent to the server based on the launched payment application. This eliminates the need for the user to manually launch the payment application on their terminal. On the other hand, if the user is handling other tasks on the user terminal before using it to conduct a transaction near a near-field communication device, such as browsing e-books, watching videos, or making phone calls, the user does not need to exit the currently processed task, which also improves the user experience.

[0102] The business identification information used to represent payment transactions can be information that instructs the server or user terminal to execute the payment transaction process. Specifically, it can be a token or other forms of information, as long as it can be recognized by the server or user terminal.

[0103] The merchant identifier for a merchant device can be one or more of the following: device number, device ID, device name, device location, etc.

[0104] The transaction amount information can include the amount of the goods the user purchased, the amount the user needs to pay, etc. The amount the user needs to pay can be less than or equal to the amount of the goods purchased. For example, if the user enjoys membership discounts, coupon discounts, or spending threshold discounts, the amount the user needs to pay can be less than the amount of the goods purchased.

[0105] The device identifier of a near-field communication device can be one or more of the following: device number, device ID, device name, device location, etc.

[0106] Continuing the previous example, in the payment link information https: / / aa.bb.cc.2*33**55**7*8*9*00.$20, 'aa' can represent the application identifier of payment application A. After the user terminal obtains this link, it can launch payment application A. 'bb' can represent business identifier information. After the user terminal obtains this link and launches payment application A, payment application A can execute an access process to the server based on this business identifier information, or payment application A can access this link, and the server can trigger the execution of the corresponding business processing process based on this business identifier information. 'cc' can be the merchant identifier of the merchant device. When the user terminal accesses this link, it can provide the merchant identifier to the server, and the server can use this merchant identifier to help identify the two parties in the transaction.

[0107] It is understood that the payment link information shown above is only an illustration. In some embodiments, the content and form of the link information can be set according to actual needs. For example, the payment link information may not include amount information, merchant identification, business identification information, etc., or the position of amount information, merchant identification, business identification information and payment voucher in the payment link information may not be as shown above.

[0108] In some embodiments, each merchant may set up one or more near-field communication devices. In order to reduce the possibility of duplicate payment vouchers, the payment voucher may be generated based on the device identifier of the near-field communication device and / or the merchant identifier of the merchant device associated with the near-field communication device.

[0109] For example, a payment voucher can be obtained by processing the device identifier of the near-field communication device and / or the merchant identifier of the merchant device associated with the near-field communication device according to preset rules; or, information such as a timestamp can be added to the device identifier of the near-field communication device and / or the merchant identifier of the merchant device associated with the near-field communication device, and then processed according to preset rules to obtain a payment voucher.

[0110] It is understood that the above is only an illustration. In some embodiments, the generated payment voucher may also be unrelated to near-field communication devices or merchant devices, and no specific limitation is made here.

[0111] Optionally, in addition to providing payment credentials to the server, the user terminal may also provide at least one of the following to the server: business identification information representing the payment transaction, merchant identification of the merchant device, transaction amount information, and device identification of the near-field communication device, so that the server can execute the corresponding business process or assist the server in determining the two parties to the transaction.

[0112] To improve transaction accuracy, the payment vouchers used in the embodiments of this specification can be one-time information. Optionally, the methods in the embodiments of this specification may further include: Delete the payment credential from the local storage space of the near-field communication device; Alternatively, the payment voucher can be marked as invalid.

[0113] In the embodiments described in this specification, the near-field communication (NFC) device can pre-store one or more backup payment credentials locally. After a user terminal sends a NFC trigger message, if the NFC device receives the NFC trigger message, it can respond to the trigger message by sending a payment credential to the merchant device, and can also send the payment credential to the user terminal. After the NFC device sends the payment credential to the merchant device and / or the user terminal, the NFC device can delete the locally stored payment credential or mark the payment credential as invalid. Subsequently, when the NFC device receives NFC trigger messages from other user devices or from that user device, it will not send the previously sent payment credential to other user devices, that user device, or the merchant device.

[0114] The local storage space of a near-field communication device can be memory space, cache space, or even a trusted execution environment (TEE). No specific limitation is made on the storage space here.

[0115] A payment credential marked as invalid can indicate that it cannot be used or sent to a merchant's device or user terminal. In some embodiments, the invalid payment credential can also be deleted, or deleted after a preset period of time.

[0116] In the embodiments of this specification, the near-field communication device may pre-store one or more usable payment credentials so that after receiving near-field communication trigger information sent by the user terminal, the payment credentials can be quickly sent to the merchant device and / or the user terminal. As one implementation, before obtaining the near-field communication trigger information sent by the user terminal, the method may further include: obtaining a plurality of backup payment credentials sent by the server; the plurality of backup payment credentials including the aforementioned payment credentials; and storing the plurality of backup payment credentials in the local storage space of the near-field communication device.

[0117] Among them, the backup payment voucher can represent the payment voucher that can be used. After the near-field communication device obtains the near-field communication trigger information sent by the user terminal, it can select a payment voucher from the backup payment vouchers and send it to the merchant device and the user terminal.

[0118] The local storage space of a near-field communication (NFC) device can store one or more backup payment vouchers. The server can proactively push backup payment vouchers to the NFC device. For example, the server can determine whether the backup payment vouchers in the NFC device have been used, or whether the number is less than or equal to a preset quantity, based on payment requests sent by the merchant's device. Once the sending conditions are met, such as if the backup payment vouchers in the NFC device have been used, or the number of backup payment vouchers in the NFC device is less than or equal to the preset quantity, the server can proactively send one or more new backup payment vouchers to the NFC device.

[0119] The server can also send backup payment vouchers based on requests from near-field communication devices. As one implementation, the method in this specification embodiment may further include: sending a voucher retrieval request to the server; and retrieving the backup payment voucher returned by the server based on the voucher retrieval request.

[0120] In this context, after the near-field communication (NFC) device sends a payment credential to the merchant device and / or the user terminal in response to a NFC trigger message sent by the user terminal, it can send a credential retrieval request to the server. The credential retrieval request may include relevant information about the NFC device, such as the device number and device ID. Based on this information, the server can send a backup payment credential back to the NFC device.

[0121] In some embodiments, the payment credential may also have validity period information, such as one day, three days, one week, two weeks, etc. If the payment credential is not used within its validity period, the near-field communication device may delete the payment credential or mark it as invalid. Subsequently, the near-field communication device may send a credential retrieval request to the server to obtain a new payment credential.

[0122] As one implementation method, the near-field communication (NFC) device can pre-store multiple backup payment vouchers, such as 12, 5, or 15. This allows the NFC device to promptly send payment vouchers to merchant devices and user terminals in situations with high transaction frequency. Optionally, the method in the embodiments of this specification may further include: determining whether the number of backup payment vouchers stored in the NFC device is less than or equal to a preset threshold.

[0123] The aforementioned sending of a credential retrieval request to the server may specifically include: if the number of backup payment credentials stored in the near-field communication device is less than or equal to a preset threshold, then sending a credential retrieval request to the server.

[0124] The credential retrieval request may include the identification information of the near-field communication device, so that the server can send a backup payment credential to the near-field communication device that sent the credential retrieval request.

[0125] Optionally, the credential retrieval request may also include information on the number of payment credentials to be retrieved, and the server may send that number of backup payment credentials back to the near-field communication device.

[0126] In some embodiments, the near-field communication device can determine whether the number of locally stored backup payment vouchers is less than or equal to a preset threshold; alternatively, the server can determine whether the number of locally stored backup payment vouchers is less than or equal to a preset threshold. No specific limitations are imposed here.

[0127] As one implementation, the near-field communication device can record the number of payment vouchers used, or the near-field communication device can detect the number of locally stored backup payment vouchers in real time or periodically or after sending a payment voucher. If the number is less than or equal to a preset threshold, it can send a voucher retrieval request to the server.

[0128] In one implementation, the server can record the number of backup payment vouchers that have been sent to the near-field communication device, as well as the number of payment requests sent by merchant devices associated with the near-field communication device, or the number of payment vouchers obtained from the near-field communication device by user terminals. Based on this quantity information, the server can determine the number of unused backup payment vouchers in the near-field communication device. If the number is less than or equal to a preset threshold, the server can send backup payment vouchers to the near-field communication device.

[0129] The server can send one backup payment credential to the near-field communication device at a time, or it can send multiple backup payment credentials to the near-field communication device at once. No specific limitation is made here.

[0130] It is understood that in some embodiments, the steps described above regarding determining the number of backup payment vouchers may not be performed. For example, after sending a payment voucher, the near-field communication device can send a voucher retrieval request to the server, and the server can send a new payment voucher back to the near-field communication device. Alternatively, after processing a payment request for a payment voucher, or after receiving a payment request for a payment voucher, the server can send a new payment voucher to the near-field communication device.

[0131] Based on the same idea, the embodiments of this specification also provide a method with a server as the execution subject corresponding to the above method. Figure 3This 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.

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

[0133] Step 302: Obtain the payment request sent by the merchant's device.

[0134] The payment request may be generated by the merchant device based on a first payment credential provided by a near-field communication device associated with the merchant device; the first payment credential may be a payment credential generated by the near-field communication device before it obtains near-field communication trigger information sent by the user terminal; the payment credential is used to trigger the merchant device to initiate a payment request to the server; the payment credential does not contain the user information of the user terminal.

[0135] In some embodiments, after a user terminal approaches a near-field communication (NFC) device, the NFC device can send a pre-stored payment credential to the merchant device. The merchant device can then send a payment request to the server based on the payment credential, so that the server can process the transaction for the merchant device.

[0136] As one implementation method, the payment request may include a first payment credential sent by the near-field communication device based on near-field communication trigger information sent by the user terminal. For example, the merchant device may directly include the first payment credential in the payment request, or it may include the first payment credential in the payment request after encryption, compression, or other processing. As long as the server can recognize it, no specific limitation is made here.

[0137] In some embodiments, the payment request may also include the identification information of the merchant device, or the identification information of the merchant to which the merchant device belongs, or it may also include pending transaction information, such as the transaction amount to be paid, the goods to be paid, etc. The specific request content can be set according to actual needs, and will not be elaborated here.

[0138] The near-field communication device can execute the methods in the foregoing embodiments and can send payment credentials to the merchant device and / or user terminal based on the methods in the foregoing embodiments. Furthermore, the relevant descriptions of the characteristics of the merchant device, user terminal, payment credentials, user information, etc., can be found in the foregoing embodiments and will not be repeated here.

[0139] Step 304: Obtain payment confirmation information containing the second payment voucher sent by the user terminal.

[0140] In the embodiments described in this specification, after the near-field communication device receives near-field communication trigger information sent by the user terminal, it can respond to the near-field communication trigger information by sending a payment credential back to the user terminal. The user terminal can then send payment confirmation information to the server based on the payment credential, so that the server can utilize the resources in the user's account to process the transaction. The second payment credential here can be the payment credential sent back to the user terminal by the near-field communication device after receiving the near-field communication trigger information sent by the user terminal.

[0141] Payment confirmation information may include payment vouchers or information that represents payment vouchers. For example, the user terminal may directly include a second payment voucher in the payment confirmation information, or it may encrypt, compress, or otherwise incorporate the second payment voucher into the payment request. As long as the server can recognize it, there are no specific limitations here.

[0142] Payment confirmation information can be generated based on user actions. For example, after receiving a second payment credential from a near-field communication device, the user terminal can display a payment confirmation page containing transaction information such as the amount to be paid. This page can include controls for the user to confirm the transaction information. When the user interacts with these controls, the user terminal can send payment confirmation information to the server. Payment confirmation information can also be sent automatically by the user terminal. For example, if the user has enabled the express payment function, the authorized terminal does not need to display a payment confirmation page; after receiving the second payment credential, the user terminal can automatically send payment confirmation information to the server without displaying a payment confirmation page.

[0143] In some embodiments, the server can process payment requests from multiple merchant devices and payment confirmation messages from multiple user terminals, thus handling transactions between multiple merchants and users. Therefore, the server may have multiple unprocessed payment requests or multiple unprocessed payment confirmation messages. The use of "first payment credential" and "second payment credential" above is for clarity in defining the process executed by the server; in some embodiments, the first payment credential and the second payment credential may be the same payment credential or different payment credentials.

[0144] For example, after a user terminal establishes near-field communication with a near-field communication device, the near-field communication device sends a payment credential to a merchant device and can also send the payment credential to the user terminal. The merchant device can then send a payment request to a server based on the payment credential, and the user terminal can also send payment confirmation information to the server based on the payment credential. In this case, the first payment credential of the payment request and the second payment credential of the payment confirmation information are the same payment credential, and the merchant device that sends the payment request and the user terminal that sends the payment confirmation information are the two parties to the same transaction.

[0145] For example, a server can provide services for multiple merchants, such as Merchant A and Merchant B. Suppose a user uses user terminal A1 to establish near-field communication (NFC) with near-field communication device A2 in Merchant A. NFC device A2 can then send a payment credential A3 to Merchant A's merchant device A4 and also to user terminal A1. Merchant device A4 can then send a payment request to the server based on payment credential A3, and user terminal A1 can send payment confirmation information to the server based on payment credential A3. Similarly, suppose that after, before, or simultaneously with NFC communication between user terminal A1 and NFC device A2 in Merchant A, another user in Merchant B uses user terminal B1 to establish NFC communication with NFC device B2 in Merchant B. NFC device B2 can then send a payment credential B3 to Merchant B's merchant device B4 and also to user terminal B1. Merchant device B4 can then send a payment request to the server based on payment credential B3, and user terminal B1 can send payment confirmation information to the server based on payment credential B3. If we interpret the payment request in step 302 as a payment request sent by merchant device A4 based on payment voucher A3, and the payment confirmation information in step 304 as payment confirmation information sent by user terminal B1 based on payment voucher B3, then the first payment voucher and the second payment voucher are different payment vouchers.

[0146] Step 306: If the first payment voucher is the same as the second payment voucher, then process the payment request based on the user information of the user terminal.

[0147] The first payment voucher is identical to the second payment voucher, indicating that the user terminal sending the payment confirmation information and the merchant device sending the payment request are the same party in the same transaction. The server can process the payment request sent by the merchant device for the same transaction based on the user information of the user terminal. For example, the server can transfer a corresponding amount of resources from the user account of the user terminal to the merchant account corresponding to the merchant device based on transaction information such as the amount contained in the payment request or payment confirmation information.

[0148] If the first payment voucher and the second payment voucher are different, it may indicate that the user terminal that sent the payment confirmation information and the merchant device that sent the payment request are not for the same transaction, and the payment request cannot be processed based on the user information of that user terminal.

[0149] In some embodiments, the server can determine the payment account of the user using the user terminal based on the user information of the user terminal, and then use the resources in the payment account to process the payment request, for example, transferring the required amount of resources from the user's payment account to the merchant account corresponding to the merchant device. As one implementation, processing the payment request based on the user information of the user terminal may specifically include: determining the user account information of the user terminal based on the payment confirmation information; determining the receiving account information of the merchant device based on the payment request; determining the amount to be transacted based on the payment request or the payment confirmation information; deducting the amount of resources represented by the amount to be transacted from the user account represented by the user account information; and adding the amount of resources to the receiving account represented by the receiving account information.

[0150] In the embodiments of this specification, the near-field communication (NFC) device can pre-store one or more payment credentials. These payment credentials may not contain user terminal information, but they can trigger the merchant to execute a transaction process. After the user terminal establishes NFC communication with the NFC device, the NFC device can send payment credentials to both the merchant's device and the user terminal, allowing both the merchant and user sides to execute at least part of the transaction process in parallel, thus improving transaction efficiency. The server can determine the two parties involved in the transaction based on the payment credentials, ensuring the accuracy and security of the transaction.

[0151] based on Figure 3 In addition to the method described herein, this specification also provides some specific implementation schemes of the method, which will be described below.

[0152] In some embodiments, due to factors such as network conditions, user operations, and hardware configuration, for the same transaction, the payment request sent by the merchant device may arrive at the server side first, while the corresponding payment confirmation information sent by the user terminal may arrive at the server side later. Alternatively, the payment request sent by the merchant device may arrive at the server side later, while the corresponding payment confirmation information sent by the user terminal arrives at the server side first. To improve processing efficiency, after receiving the payment request sent by the merchant device, the server can match it with the already obtained payment confirmation information to determine whether there is a payment confirmation information for the same transaction as the payment request. If it exists, the payment request can be processed. If it does not exist, the payment request can be temporarily left unprocessed until the corresponding payment confirmation information arrives.

[0153] Optionally, after obtaining the payment request sent by the merchant device, the method in this embodiment may further include: determining whether there is target payment confirmation information containing the first payment voucher among the various payment confirmation information that has been obtained; if there is no target payment confirmation information containing the first payment voucher among the various payment confirmation information that has been obtained, then marking the payment request as a temporary state.

[0154] The payment confirmation information already obtained can refer to the payment confirmation information that the server has obtained before the server receives the payment request sent by the merchant device in step 302 above.

[0155] If none of the obtained payment confirmation messages contain the target payment confirmation message for the first payment voucher, it indicates that the user terminal corresponding to the payment request sent by the merchant's device has not yet sent payment confirmation information to the server, or the server has not yet received payment confirmation information from the user terminal for the same transaction. In this case, the server can suspend processing of the payment request and mark it as pending.

[0156] Temporary states can be represented using preset temporary symbols, such as strings of numbers, letters, or symbols. There are no specific limitations here, as long as the server can recognize them.

[0157] In some embodiments, payment requests that are not yet processed can be placed in a temporary request pool, such as an index file. Payment requests in the temporary request pool can also represent payment requests marked as pending. The temporary request pool can be a data storage area or database for storing temporarily unprocessed payment requests. In some embodiments, payment requests in the temporary request pool can also be marked with identification information indicating their pending status. If the server subsequently obtains new payment confirmation information, it can continue to process the payment requests in the temporary request pool.

[0158] If the acquired payment request already contains target payment confirmation information including the first payment credential, the server can process the payment request sent by the merchant's device. Optionally, the above-mentioned processing of the payment request based on the user information of the user terminal may specifically include: if the acquired payment confirmation information includes target payment confirmation information containing the first payment credential, processing the payment request based on the user information of the user terminal.

[0159] In some embodiments, the payment confirmation information obtained may or may not include the payment confirmation information in step 304 above.

[0160] In one implementation, if step 304 is executed before step 302, the acquired payment confirmation information may include the payment confirmation information in step 304. Specifically, if the first payment voucher and the second payment voucher are the same, it indicates that among the acquired payment confirmation information, there is target payment confirmation information containing the first payment voucher; this target payment confirmation information is the payment confirmation information in step 304.

[0161] In some embodiments, the acquired payment confirmation information may include the payment confirmation information from step 304 above, but none of the acquired payment confirmation information contains the target payment confirmation information of the first payment voucher, or it may indicate that the first payment voucher is different from the second payment voucher. In this case, the server may temporarily not process the payment request obtained in step 302.

[0162] As another implementation, if step 304 was not executed before step 302, it indicates that the server has already obtained payment confirmation information, excluding the payment confirmation information obtained in step 304. If any of the obtained payment confirmation information includes target payment confirmation information containing the first payment voucher, the server can process the payment request based on the user account of the user terminal that sent the target payment confirmation information, and can identify the user terminal that sent the target payment confirmation information as the counterparty in the transaction with the merchant device. In this case, the server can still continue to execute step 304, except that the payment confirmation request obtained in step 304 is not sent by the user terminal of the counterparty in the transaction with the merchant device.

[0163] If none of the acquired payment confirmation information contains the target payment confirmation information for the first payment voucher, after executing step 304, the server continues to match the payment request obtained in step 302 with the payment confirmation information obtained in step 304. If the first payment voucher and the second payment voucher are the same, the payment request is processed based on the user information of the user terminal that sent the payment confirmation information in step 304. If the first payment voucher and the second payment voucher are different, the server continues to match other payment confirmation information to find payment confirmation information containing the first payment voucher.

[0164] To facilitate management and improve processing efficiency, a binding database can be set up on the server. This database can contain the mapping relationship between the user information of the user terminal corresponding to each payment confirmation message obtained by the server and the payment voucher contained in the corresponding payment confirmation message. Specifically, after receiving payment confirmation information sent by a user terminal, the server establishes the mapping relationship between the user terminal's user information and the payment voucher contained in the payment confirmation message. This allows the server to determine the payer corresponding to the payment request after receiving a payment request from a merchant's device, and then process the transaction.

[0165] Optionally, the above determination of whether there is target payment confirmation information containing the first payment voucher among the various payment confirmation information already obtained may specifically include: determining whether the first payment voucher exists in the binding information database; the binding information database includes the correspondence between the user information of the user terminal corresponding to each of the various payment confirmation information already obtained and the payment voucher contained in the corresponding payment confirmation information.

[0166] The user information can be information that identifies the user account used for payment. For example, it could be the user's identification information, such as a User Identification ID (UID), or it could be the user's email address, ID number, mobile phone number, transaction card number, etc. The specific content of the user information is not limited here, as long as it can identify the account providing the resources.

[0167] In some embodiments, if any payment credential in the binding information database matches the payment credential included in the payment request sent by the merchant device, after the server completes processing the payment request (e.g., transferring resources from the user's account to the account corresponding to the merchant device), the server can delete that payment credential and its corresponding user information from the binding information database. This reduces the amount of information in the binding information database, allows for faster matching or retrieval, and improves payment processing efficiency. The binding information database stores the correspondence between user information of user terminals corresponding to various payment confirmation messages that the server has obtained but not yet processed, and the payment credentials included in those payment confirmation messages.

[0168] To facilitate transaction processing, after receiving payment confirmation information sent by the user terminal, the server can determine the user information of the user terminal based on the payment confirmation information, thereby facilitating the subsequent determination of the account used for payment based on the user information. Optionally, after obtaining the payment confirmation information containing the second payment voucher sent by the user terminal, the process may further include: determining the user information of the user terminal that sent the information; and saving the correspondence between the user information and the second payment voucher.

[0169] If the first payment voucher is the same as the second payment voucher, the payment request is processed based on the user information of the user terminal. Specifically, this may include: if the first payment voucher is the same as the second payment voucher, determining the user information of the user terminal based on the correspondence; and processing the payment request based on the user payment account corresponding to the user information.

[0170] The user information can be found in the relevant descriptions in the foregoing embodiments, and will not be repeated here.

[0171] In some embodiments, the server may be a server providing payment services, and the user terminal user may be a user registered on the server. The user can log in to the registered account using the user terminal and then perform business processing under the account, such as making payments. The server may store the correspondence between registered users and the accounts authorized by the users.

[0172] As one implementation method, the payment confirmation request sent by the user terminal may include user information and a second payment voucher. After the server receives the payment confirmation request, it can save the correspondence between the user information and the second payment voucher.

[0173] As another implementation, the payment confirmation request may include the user terminal's identification information or the user's login account information and the second payment credential. The server can determine the user information corresponding to the user terminal from the user information stored in the server based on the user terminal's identification information or the user's login account information, and then save the correspondence between the user information and the second payment credential.

[0174] In one implementation, user information can be a user's identity verification UID stored on the server. The server can store the correspondence between the user's identity verification UID and the second payment voucher. Specifically, the server can determine the user's payment account based on user information such as the user's identity verification UID. After determining the amount to be paid, the server can deduct the corresponding amount of resources from the user's payment account and transfer the resources to the merchant's account.

[0175] In some embodiments, the correspondence between user information and the second payment credential can also be saved in the binding information database so that after the server receives the payment request sent by the merchant device, it can query the corresponding user information from the binding information database to complete the transaction.

[0176] Similar to the logic of the above embodiments, for the same transaction, the server may first obtain the payment confirmation information sent by the user terminal, or it may first obtain the payment request sent by the merchant device. Optionally, after obtaining the payment confirmation information containing the second payment credential sent by the user terminal in the embodiments of this specification, the method may further include: determining whether there is a target payment request containing the second payment credential among the various payment requests that have been obtained; if there is no target payment request containing the second payment credential among the various payment requests that have been obtained, the payment confirmation information can be saved to the confirmation information cache.

[0177] The above-mentioned processing of the payment request based on the user information of the user terminal may specifically include: If any of the acquired payment requests contains a target payment request that includes the second payment credential, then the payment request containing the second payment credential is processed based on the user information of the user terminal.

[0178] The confirmation information cache can be a storage space or data set used to store payment confirmation information that the server has already obtained. In some embodiments, the confirmation information cache can be used to store payment confirmation information that the server has obtained but has not yet processed.

[0179] As one implementation, once the payment request containing the second payment credential has been processed, the payment confirmation information containing the second payment credential can be deleted from the confirmation information cache. For example, transferring resources from the user's account on the user terminal to the merchant's account on the merchant's device that sent the payment request can indicate that the payment request has been processed, and the payment confirmation information containing the second payment credential can then be deleted from the confirmation information cache.

[0180] In some embodiments, if the server obtains payment confirmation information, it can directly save the payment confirmation information to the confirmation information cache library, and then select the payment confirmation information to be used from the confirmation information cache library. Before saving the payment confirmation information to the confirmation information cache library, it is not necessary to determine whether there is a target payment request containing the second payment voucher among the various payment requests that have been obtained.

[0181] To facilitate faster transaction processing, optionally, the payment confirmation information can be saved to a confirmation information cache. Specifically, this may include: saving the correspondence between the user information of the user terminal that sent the payment confirmation information and the second payment voucher to a binding information database; the binding information database is used to store the correspondence between the user information of the user terminal corresponding to each payment confirmation information obtained by the server and the payment voucher contained in the corresponding payment confirmation information.

[0182] The specific content of the binding information database can be found in the description of the aforementioned embodiments, and will not be repeated here.

[0183] In some embodiments, the payment requests obtained may or may not include the payment confirmation information from step 302 above.

[0184] In one implementation, if step 302 is executed before step 304, the acquired payment requests may include the payment requests from step 302. Specifically, if the first payment voucher and the second payment voucher are the same, it indicates that among the acquired payment requests, there exists a target payment request containing the second payment voucher; this target payment request is the payment request from step 302.

[0185] In some embodiments, it's possible that the acquired payment requests include the payment request from step 302, but none of the acquired payment requests contain a target payment request with a second payment credential, or the first payment credential and the second payment credential may be different. In this case, the server can temporarily suspend processing the payment confirmation information obtained in step 304, marking it as temporarily stored or suspended, and wait for the acquisition of a target payment request containing a second payment credential before continuing processing. Alternatively, the server can determine the user information of the user terminal based on the payment confirmation information, save the correspondence between the user information and the second payment credential, and subsequently, after acquiring a target payment request containing a second payment credential, determine the user information corresponding to the second payment credential based on this correspondence, and also determine the user account for making the payment based on the user information, thus processing the target payment request.

[0186] As another implementation, if step 302 was not executed before step 304, it may indicate that the server has already obtained payment requests that do not include the payment request obtained in step 302. If any of the obtained payment requests includes a target payment request containing the second payment credential, the server can, based on the payment confirmation information in step 304, process the target payment request. Specifically, the merchant device sending the target payment request can be identified as the payee, and the user terminal sending the payment confirmation information can be identified as the payer, thus processing the transaction between the two parties. In this case, the server can still continue executing step 302, except that the payment request obtained in step 302 is not sent by the merchant device corresponding to the user terminal in step 304.

[0187] If none of the acquired payment requests contain the second payment credential, after executing step 302, the server can continue to match the payment confirmation information obtained in step 304 with the payment requests obtained in step 302. If the first payment credential and the second payment credential are the same, the payment request in step 304 is processed based on the user information of the user terminal that sent the payment confirmation information in step 304. If the first payment credential and the second payment credential are different, the server can obtain other payment requests and continue matching to find a payment request containing the second payment credential.

[0188] In this embodiment of the specification, after the server determines the two parties involved in a transaction, it can also provide the payer's information to the merchant's device so that the merchant can understand the transaction information. Optionally, if the first payment voucher and the second payment voucher are the same, the method in this embodiment of the specification may further include: sending the user information to the merchant's device.

[0189] The fact that the first payment voucher and the second voucher are the same indicates that the server has received a payment request for a transaction and has also received payment confirmation information provided by the payer. The server can then provide the payer's user information to the merchant's device.

[0190] In some embodiments, the server may send the user information to the merchant device after processing the payment request sent by the merchant device. Alternatively, the server may provide the user information based on the information query request sent by the merchant device. The timing of sending the user information is not specifically limited here.

[0191] If the merchant's equipment has a display screen, the screen can also display user information. If the user information includes private information, the server can further process the information to prevent leakage.

[0192] To facilitate information statistics or verification on the merchant's side, the server can also send a transaction number back to the merchant's device. Optionally, if the first payment voucher and the second payment voucher are the same, the method in this embodiment may further include: generating a transaction number representing the uniqueness of the transaction; and sending the transaction number back to the merchant's device.

[0193] A transaction number represents the identifier of a transaction and can be used to indicate the uniqueness of a transaction. Different transactions have different transaction numbers. If the first payment voucher and the second payment voucher are the same, it can indicate that the merchant device sending the payment request containing the first payment voucher and the user terminal sending the payment confirmation information containing the second payment voucher are the two parties to the same transaction. The server can generate a transaction number for this transaction according to preset rules and can also send the transaction number back to the merchant device.

[0194] In some embodiments, the server may send the transaction number to the merchant device after processing the payment request sent by the merchant device. Alternatively, the server may return the transaction number based on an information query request sent by the merchant device. The timing of sending the transaction number is not specifically limited here.

[0195] To help merchants understand the transaction status, the server can also send information indicating the transaction status back to the merchant's device. Optionally, after obtaining the payment request sent by the merchant's device, the process may further include: sending information indicating the transaction status to the merchant's device; the information indicating the transaction status includes at least one of information indicating that the transaction is being processed and information indicating the transaction processing result.

[0196] As one implementation method, after receiving a payment request from the merchant's device, the server can send information indicating that the transaction is being processed to the merchant's device. For example, the merchant's device can display messages such as "Transaction in progress" to indicate that the transaction is being processed.

[0197] In one implementation, after processing the payment request sent by the merchant's device, the server can generate transaction result information and send this information back to the merchant's device. Alternatively, it can send the transaction result information back to the user's terminal. The transaction result information can indicate a successful transaction or a failed transaction, etc.

[0198] In this embodiment of the specification, the near-field communication device may pre-store payment credentials. As one implementation, the pre-stored payment credentials may be generated by a server and sent to the near-field communication device. Optionally, before obtaining the payment request sent by the merchant device, the process may further include: sending a plurality of backup payment credentials to the near-field communication device; the plurality of backup payment credentials may include the first payment credentials.

[0199] The payment voucher can be either actively pushed by the server to the near-field communication device (NFC), or it can be requested by the NFC device from the server. The specific process for generating the payment voucher and its contents can be found in the foregoing embodiments, and will not be repeated here.

[0200] Based on the same idea, the embodiments of this specification also provide a method with the user terminal as the execution subject corresponding to the above method. 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 installed on a user terminal. From a hardware perspective, the entity executing the process can be the user terminal.

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

[0202] Step 402: Send near-field communication trigger information.

[0203] The user terminal can be a mobile terminal with near-field communication (NFC) capabilities, which can act as an NFC reader or NFC master device to emit electromagnetic signals to trigger NFC communication.

[0204] Step 404: Obtain the payment credential sent by the near-field communication device in response to the near-field communication trigger information.

[0205] The payment credential is generated before the near-field communication device receives the near-field communication trigger request; the payment credential does not include the user information of the user terminal.

[0206] The near-field communication (NFC) device may include an NFC tag, or, in NFC card emulation mode, may store tag information. The tag information may include a payment credential. The NFC device may respond to a NFC trigger message sent by a user terminal and send the payment credential back to the user terminal. This payment credential may be pre-stored by the NFC device; details can be found in the foregoing embodiments and will not be repeated here.

[0207] Step 406: Based on the payment voucher, trigger the execution of the transaction process.

[0208] The user terminal can execute the corresponding transaction process based on the obtained payment voucher.

[0209] For example, a user terminal can launch the corresponding payment application, which displays a payment confirmation page containing information about the amount to be paid. The user can perform a confirmation operation on this page, and the user terminal can send payment confirmation information to the server. The server can then determine the payer of the transaction based on the payment confirmation information and process the transaction.

[0210] The embodiments described in this specification are based on the same idea, and the various embodiments can be referred to each other. For example, the parts not described in the various 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.

[0211] To more clearly explain the payment methods provided in this instruction manual, Figure 5 Swimlane diagram for a payment method provided in an embodiment of this specification. For example... Figure 5 As shown, the method may specifically include: The user terminal acting as an NFC card reader can perform step 502: send near-field communication trigger information.

[0212] The near-field communication device acting as an NFC card can perform step 504: in response to the near-field communication trigger information, send a payment credential to the merchant device and send NFC tag information containing the payment credential to the user terminal.

[0213] The merchant device can perform step 506: obtain the payment credential sent by the near-field communication device.

[0214] Step 508 can also be performed: Based on the payment voucher, generate a payment request including the payment voucher and send it to the server.

[0215] In some embodiments, before the near-field communication device responds to the near-field communication trigger signal, a cashier or other merchant user can enter information about the goods the user is purchasing into the merchant device, and the payment request generated by the merchant device may also include transaction information.

[0216] The user terminal can perform step 510: obtain NFC tag information sent by the near field communication device.

[0217] The NFC tag information may include payment credentials, and the specific payment credentials or information representing the payment credentials may be included in the payment link information.

[0218] In some embodiments, to simplify user operations, the payment link information or NFC tag information may also include the identification information of the payment application. The user terminal's terminal system program can launch the payment application on the user terminal based on this identification information. The launched payment application can then execute the corresponding transaction process.

[0219] Once the user terminal's system program obtains the NFC tag information or payment link information, it can provide at least a portion of the information in the NFC tag information or payment link information to the launched payment application. The payment application can then access the server based on the obtained information and execute the transaction process.

[0220] In one implementation, the NFC tag information may include transaction information to be processed, such as NFC tag information, payment link information, merchant information, etc. The transaction information may be located within or outside the payment link information; no specific limitation is made here. Based on the transaction information, the user terminal can display a payment confirmation page, which may contain the amount to be paid. The user can perform a confirmation operation on this page. For example, the page may include a confirmation control; if the user interacts with this control, the user terminal can generate payment confirmation information indicating that the user agrees to the payment or that the user has completed the verification of the information to be paid. Alternatively, the page may include a countdown control; if the user does not cancel the confirmation or interact with the countdown control before the countdown ends, it can also indicate that the user agrees to the payment or that the user has completed the verification of the information to be paid, and the user terminal can also generate payment confirmation information.

[0221] In some embodiments, if the user has authorized the payment application not to display the payment confirmation page, the user terminal may also not display the payment confirmation page after obtaining the NFC tag information, and the payment confirmation information can be automatically generated by the user terminal.

[0222] The user terminal can also perform step 512: send payment confirmation information containing payment credentials to the server.

[0223] In the embodiments of this specification, the steps of the merchant device obtaining payment vouchers and subsequent processing, and the steps of the user terminal obtaining payment vouchers and subsequent processing, can be executed in two independent links, without any order, or they can be executed synchronously or in parallel. For example, steps 506 and 508 above can be executed in parallel with steps 510 and 512.

[0224] The server can perform step 514: obtain the payment request containing payment credentials sent by the merchant's device.

[0225] You can also perform step 516: obtain payment confirmation information containing payment vouchers sent by the user terminal.

[0226] After obtaining the payment confirmation information, the server can also determine the user information of the user terminal and bind the user information with the payment voucher.

[0227] The user terminal can interact with the server to send payment vouchers to the server, or it can send them using a near-field communication device. For example, the user terminal can write the payment voucher to the near-field communication device via NFC, and then the near-field communication device can send it to the server.

[0228] If the merchant's equipment needs to use some user information from the user terminal, it can also use a near-field communication device as an intermediary to send the information from the user terminal to the merchant's equipment.

[0229] In some embodiments, the server may first receive a payment request containing a payment credential sent by the merchant device, and then receive payment confirmation information containing the payment credential sent by the user terminal; or, it may first receive payment confirmation information containing a payment credential sent by the user terminal, and then receive a payment request containing the payment credential sent by the merchant device.

[0230] If a payment request is received first from the merchant's device, the server can temporarily store the request and return a notification to the merchant indicating that payment is in progress. At this stage, the server may not need to provide the merchant's transaction number or user information. Subsequently, if payment confirmation information is received from the user's terminal, the server can bind the user information to the merchant's payment initiation credentials, proceed with the payment, and transfer resources from the user's terminal's user account to the merchant's device's merchant account. In some embodiments, the merchant can also obtain payment result information through queries or asynchronous notifications, which may include the transaction number, user information, and other relevant information.

[0231] If the server first obtains the payment confirmation information sent by the user terminal, it can temporarily store the payment confirmation information. If it subsequently obtains the payment request sent by the merchant device, the server can determine that the user has confirmed the payment and proceed with the payment. It can also return the payment result to the merchant device.

[0232] Before user confirmation, the server may not return the transaction number and user information to the merchant's device during the order creation and payment processes; it may only return the transaction status. After user confirmation, the server may return the transaction number and user information to the merchant's device.

[0233] Step 518: Process the payment request based on the obtained payment confirmation information.

[0234] After the transaction is processed, the server can also send the transaction result information back to the user terminal, merchant device and / or near-field communication device.

[0235] The embodiments in this specification employ a two-stage approach, significantly reducing the perceived time spent on a single payment for both users and merchants. Furthermore, the server only confirms user information and executes resource transfer steps after receiving payment confirmation information from the user's terminal, thus ensuring payment security.

[0236] Based on the same idea, the embodiments of this specification also provide the apparatus corresponding to the above method. Figure 6 The embodiments provided in this specification correspond to Figure 2 A schematic diagram of a payment device. This device can be applied to near-field communication devices, such as... Figure 6 As shown, the device may include at least some of the following modules.

[0237] The trigger information acquisition module 602 is used to acquire near-field communication trigger information sent by the user terminal.

[0238] The first credential sending module 604 is used to send a payment credential to the merchant device to trigger a transaction process based on the near-field communication trigger information; the payment credential is generated before the near-field communication device obtains the near-field communication trigger request, and is used to trigger the merchant device to initiate a payment request to the server; the payment credential does not contain the user information of the user terminal.

[0239] The second credential sending module 606 is used to send the payment credential to the user terminal based on the near-field communication trigger information; the payment credential is used by the user terminal to send to the server so that the server can process the payment request initiated by the merchant device.

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

[0241] Optionally, the payment voucher has the same format as the payment code number.

[0242] Optionally, the payment voucher and the payment code number have the same starting character, and / or the number of characters in the payment voucher is the same as the number of characters in the payment code number.

[0243] Optionally, the device may further include a link generation module, which can be used to: generate payment link information containing the payment voucher based on the payment voucher; the payment link information is information in the form of a link.

[0244] Sending the payment voucher to the user terminal as described above may specifically include: sending payment link information containing the payment voucher to the user terminal.

[0245] Optionally, the device may further include a transaction data acquisition module, which can be used to: acquire transaction data provided by the merchant device; the transaction data includes at least one of the following: amount information to be transacted, product information, and merchant information.

[0246] The above-mentioned generation of payment link information containing the payment voucher based on the payment voucher may specifically include: generating payment link information containing the transaction data and the payment voucher based on the transaction data and the payment voucher.

[0247] Optionally, the payment link information may also include at least one of the following: application identifier information of the payment application, business identifier information for representing the payment business, merchant identifier of the merchant device, amount information to be transacted, and device identifier of the near-field communication device.

[0248] Optionally, the device may further include a clearing module, which can be used to: delete the payment credential from the local storage space of the near-field communication device; or mark the payment credential as invalid.

[0249] Optionally, the device may further include a credential acquisition module. Before acquiring the near-field communication trigger information sent by the user terminal, the credential acquisition module may be used to: acquire a plurality of backup payment credentials sent by the server; the plurality of backup payment credentials include the payment credentials; and store the plurality of backup payment credentials in the local storage space of the near-field communication device.

[0250] Optionally, the device may further include a request sending module, which can be used to: send a credential acquisition request to the server; and acquire a backup payment credential provided by the server based on the credential acquisition request.

[0251] Optionally, the device may further include a quantity determination module, which can be used to determine whether the number of backup payment vouchers stored in the near-field communication device is less than or equal to a preset threshold.

[0252] The aforementioned sending of a credential retrieval request to the server may specifically include: if the number of backup payment credentials stored in the near-field communication device is less than or equal to a preset threshold, then sending a credential retrieval request to the server.

[0253] Based on the same idea, the embodiments of this specification also provide the apparatus corresponding to the above method. Figure 7 The embodiments provided in this specification correspond to Figure 3 A schematic diagram of a payment device. This device can be applied to servers, such as... Figure 7 As shown, the device can comprise at least some of the following modules.

[0254] The request acquisition module 702 is used to acquire a payment request sent by a merchant device; the payment request is generated by the merchant device based on a first payment credential provided by a near-field communication device associated with the merchant device; the first payment credential is a payment credential generated by the near-field communication device before it acquires near-field communication trigger information sent by the user terminal; the payment credential is used to trigger the merchant device to initiate a payment request to the server; the payment credential does not contain user information of the user terminal; The confirmation information acquisition module 704 is used to acquire payment confirmation information containing the second payment voucher sent by the user terminal; The payment processing module 706 is used to process the payment request based on the user information of the user terminal if the first payment voucher is the same as the second payment voucher.

[0255] Optionally, the device may further include a temporary storage processing module. After the device obtains the payment request sent by the merchant device, the temporary storage processing module may be used to: determine whether there is a target payment confirmation information containing the first payment voucher among the various payment confirmation information that has been obtained; if there is no target payment confirmation information containing the first payment voucher among the various payment confirmation information that has been obtained, then the payment request is marked as a temporary storage state.

[0256] Optionally, the above-mentioned processing of the payment request based on the user information of the user terminal may specifically include: if among the various payment confirmation information that have been obtained, there is target payment confirmation information that includes the first payment voucher, the payment request is processed based on the user information of the user terminal.

[0257] Optionally, the device further includes a storage module. After obtaining the payment confirmation information containing the second payment voucher sent by the user terminal, the storage module can be used to: determine the user information that sent the user terminal; and store the correspondence between the user information and the second payment voucher.

[0258] If the first payment voucher is the same as the second payment voucher, the payment request is processed based on the user information of the user terminal. Specifically, this may include: if the first payment voucher is the same as the second payment voucher, determining the user information of the user terminal based on the correspondence; and processing the payment request based on the user payment account corresponding to the user information.

[0259] Optionally, the device may further include a judgment module. After obtaining the payment confirmation information containing the second payment credential sent by the user terminal, the judgment module may be used to: determine whether there is a target payment request containing the second payment credential among the various payment requests that have been obtained; if there is no target payment request containing the second payment credential among the various payment requests that have been obtained, then save the payment confirmation information to the confirmation information cache.

[0260] The above-mentioned processing of the payment request based on the user information of the user terminal may specifically include: if among the various payment requests that have been obtained, there is a target payment request that includes the second payment credential, then the payment request that includes the second payment credential is processed based on the user information of the user terminal.

[0261] Optionally, the device may further include an information sending module. If the first payment voucher is the same as the second payment voucher, the information sending module may be used to send the user information to the merchant device.

[0262] Optionally, the device may further include a transaction number sending module. If the first payment voucher is the same as the second payment voucher, the transaction number sending module may be used to: generate a transaction number that represents the uniqueness of the transaction; and send the transaction number back to the merchant device.

[0263] Optionally, the device may further include a status sending module. After obtaining the payment request sent by the merchant device, the status sending module may be used to: send information indicating the transaction status to the merchant device; the information indicating the transaction status includes at least one of information indicating that the transaction is being processed and information indicating the transaction processing result.

[0264] Optionally, the device may further include a credential sending module, which may be used to: send a plurality of backup payment credentials to the near-field communication device before obtaining the payment request sent by the merchant device; the plurality of backup payment credentials may include the first payment credential.

[0265] Based on the same idea, the embodiments of this specification also provide the apparatus corresponding to the above method. 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 user terminals, such as... Figure 8 As shown, the device may include at least some of the following modules.

[0266] The trigger information sending module 802 is used to send near-field communication trigger information.

[0267] The credential acquisition module 804 is used to acquire a payment credential sent by a near-field communication device in response to the near-field communication triggering information; the payment credential is generated before the near-field communication device acquires the near-field communication triggering request; the payment credential does not include the user information of the user terminal.

[0268] The transaction processing module 806 is used to trigger the execution of the transaction process based on the payment voucher.

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

[0270] 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.

[0271] 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.

[0272] 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 describing the differences from other embodiments. In particular, for... Figure 9 As 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.

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

[0274] 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.

[0275] 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.

[0276] 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.

[0277] 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.

[0278] 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.

[0279] 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.

[0280] 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.

[0281] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus 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.

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

[0283] 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.

[0284] 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.

[0285] 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.

[0286] 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.

[0287] 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.

[0288] 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 near-field communication device associated with a merchant device, comprising: Obtain near-field communication trigger information sent by the user terminal; Based on the near-field communication trigger information, a payment voucher for triggering the transaction process is sent to the merchant's device; The payment credential is used to trigger the merchant device to initiate a payment request to the server; Based on the near-field communication trigger information, the payment voucher is sent to the user terminal; The payment credential is used by the user terminal to send to the server so that the server can process the payment request initiated by the merchant device.

2. The method according to claim 1, wherein the payment voucher and the payment code number have the same format.

3. The method according to claim 2, wherein the payment voucher and the payment code number have the same starting character, and / or the number of characters of the payment voucher is the same as the number of characters of the payment code number.

4. The method according to claim 1, wherein sending the payment voucher to the user terminal specifically includes: Send a payment link containing the payment voucher to the user terminal.

5. The method according to claim 4, wherein the payment link information is generated by the near-field communication device; or, the payment link information is generated by the server and sent to the near-field communication device.

6. The method according to claim 4, further comprising: Based on the payment voucher, payment link information containing the payment voucher is generated; the payment link information is in the form of a link; the payment link information contains the payment voucher, or the payment link information contains information representing the payment voucher obtained after encrypting or processing the payment voucher according to rules.

7. The method according to claim 6, further comprising: Obtain transaction data provided by the merchant's device; the transaction data includes at least one of the following: amount information to be transacted, product information, and merchant information; The step of generating payment link information containing the payment voucher based on the payment voucher specifically includes: Based on the transaction data and the payment voucher, a payment link information containing the transaction data and the payment voucher is generated.

8. The method according to claim 1, further comprising: After the payment credential is sent, it is deleted from the local storage space of the near-field communication device; Alternatively, after sending the payment voucher, mark the payment voucher as invalid; Alternatively, if the payment voucher is not used within its validity period, the payment voucher may be deleted or marked as invalid.

9. The method according to claim 1, further comprising, before acquiring the near-field communication trigger information sent by the user terminal: Obtain several backup payment vouchers sent by the server; the several backup payment vouchers include the payment voucher; The plurality of backup payment vouchers are stored in the local storage space of the near-field communication device.

10. The method according to claim 1, further comprising: Send a credential retrieval request to the server; Obtain the backup payment voucher returned by the server based on the voucher in the request.

11. The method of claim 10, further comprising: Determine whether the number of backup payment vouchers stored in the near-field communication device is less than or equal to a preset threshold; Sending the credential acquisition request to the server specifically includes: If the number of backup payment vouchers stored in the near-field communication device is less than or equal to a preset threshold, a voucher retrieval request is sent to the server.

12. The method according to claim 5 or 7, wherein the payment link information further includes at least one of the following: application identifier information of the payment application, business identifier information for representing the payment business, merchant identifier of the merchant device, amount information to be transacted, and device identifier of the near-field communication device.

13. The method according to any one of claims 1 to 11, wherein the near-field communication device and the merchant device are independent devices, or the near-field communication device and the merchant device are integrated into one device.

14. The method according to claim 1, wherein the payment credential is generated locally in advance by the near-field communication device according to a preset rule before or after obtaining near-field communication trigger information sent by the user terminal.

15. The method according to any one of claims 1 to 11, wherein the near-field communication device provides the payment credential to the merchant device in at least one of the following ways: Near-field communication devices deliver payment credentials to merchant devices via data cables; The near-field communication device sends the payment credential to the server, which then sends the payment credential to the merchant's device. The near-field communication device sends a request to the server, and the server sends the payment credential to the merchant's device; Near Field Communication (NFC) devices deliver payment credentials to merchant devices via wireless networks.

16. The method according to any one of claims 1 to 11, wherein the payment credential is generated based on the device identifier of the near-field communication device and / or the merchant identifier of the merchant device; and / or, the payment credential does not contain user information of the user terminal.

17. The method according to any one of claims 1 to 11, further comprising: The payment voucher is compressed to obtain compressed information; The compressed information is sent to the user's terminal.

18. A payment method applied to a server, comprising: Obtain the payment request sent by the merchant's device; The payment request is generated by the merchant device based on a first payment credential provided by a near-field communication device associated with the merchant device; the first payment credential is sent to the merchant device by the near-field communication device after obtaining near-field communication trigger information sent by the user terminal; The system obtains payment confirmation information containing a second payment credential sent by the user terminal; the payment confirmation information is generated by the user terminal after obtaining the second payment credential sent by the near-field communication device. If the first payment voucher is the same as the second payment voucher, the payment request is processed based on the user information of the user terminal.

19. The method according to claim 18, further comprising, after obtaining the payment request sent by the merchant device: Determine whether any of the acquired payment confirmation messages contain the target payment confirmation message containing the first payment voucher; If none of the obtained payment confirmation information contains the target payment confirmation information of the first payment voucher, the payment request is marked as temporarily stored. The process of processing the payment request based on the user information of the user terminal specifically includes: if any of the acquired payment confirmation information contains target payment confirmation information that includes the first payment voucher, processing the payment request based on the user information of the user terminal.

20. The method according to claim 18, further comprising, after obtaining the payment confirmation information containing the second payment voucher sent by the user terminal: Determine the user information to be sent to the user terminal; Save the correspondence between the user information and the second payment voucher; If the first payment voucher is the same as the second payment voucher, then the payment request is processed based on the user information of the user terminal, specifically including: If the first payment voucher is the same as the second payment voucher, then the user information of the user terminal is determined based on the correspondence. The payment request is processed based on the user's payment account corresponding to the user information.

21. The method according to claim 18, further comprising, after obtaining the payment confirmation information containing the second payment voucher sent by the user terminal: Determine whether any of the acquired payment requests contain the second payment voucher as a target payment request; If none of the acquired payment requests contain the second payment voucher, the payment confirmation information is saved to the confirmation information cache. The process of processing the payment request based on the user information of the user terminal specifically includes: If any of the acquired payment requests contains the second payment credential, then the payment request containing the second payment credential is processed based on the user information of the user terminal.

22. The method according to claim 18, wherein if the first payment voucher and the second payment voucher are the same, the method further comprises: Send the user information to the merchant's device; The user information includes information that can identify the user account used to make the payment.

23. The method according to claim 18, wherein if the first payment voucher and the second payment voucher are the same, the method further comprises: Generate a transaction number that uniquely represents a transaction; The transaction number is sent back to the merchant's device.

24. The method according to claim 18, further comprising, after obtaining the payment request sent by the merchant device: Send information indicating the transaction status to the merchant's device; The information indicating the transaction status includes at least one of information indicating that the transaction is being processed and information indicating the result of the transaction processing.

25. The method according to claim 18, further comprising, before obtaining the payment request sent by the merchant device: Send several backup payment vouchers to the near-field communication device; The first payment voucher is included among the plurality of backup payment vouchers.

26. A payment method applied to a user terminal, comprising: Send near-field communication trigger information; Obtain the payment voucher sent by the near-field communication device in response to the near-field communication trigger information; The payment credential is generated before the near-field communication device receives the near-field communication trigger request; the payment credential does not include the user information of the user terminal; Based on the payment credential, a transaction process is triggered so that the server can initiate a payment request containing the payment credential based on the payment credential initiated by the merchant's device.

27. The method according to claim 26, wherein obtaining a payment credential sent by a near-field communication device in response to the near-field communication triggering information comprises: Obtain payment link information sent by the near-field communication device in response to the near-field communication trigger information; The payment link information includes the payment voucher; Based on the payment voucher, the transaction execution process is triggered, including: Based on the payment link information, launch the payment application; Based on the launched payment application, the payment credential is sent to the server.

28. The method according to claim 26, wherein triggering a transaction execution process based on the payment voucher includes: Send the payment voucher to the server; Alternatively, the payment voucher and other information can be sent to the server; The other information includes at least one of the following: business identification information for representing payment transactions, merchant identification information of the merchant device, transaction amount information, and device identification information of the near-field communication device.

29. The method according to claim 26, wherein triggering a transaction execution process based on the payment voucher includes: Based on the payment voucher, a payment confirmation message is sent to the server; The payment confirmation information is generated based on the user's actions or automatically generated by the user's terminal.

30. A payment device applied to a near-field communication device associated with a merchant device, comprising: The trigger information acquisition module is used to acquire near-field communication trigger information sent by the user terminal; The first credential sending module is used to send a payment credential to the merchant device to trigger the transaction process based on the near-field communication trigger information. The payment credential is used to trigger the merchant device to initiate a payment request to the server; The second credential sending module is used to send the payment credential to the user terminal based on the near-field communication trigger information; The payment credential is used by the user terminal to send to the server so that the server can process the payment request initiated by the merchant device.

31. A payment device applied to a server, comprising: The request retrieval module is used to retrieve payment requests sent by the merchant's device; The payment request is generated by the merchant device based on a first payment credential provided by a near-field communication device associated with the merchant device; the first payment credential is sent to the merchant device by the near-field communication device after obtaining near-field communication trigger information sent by the user terminal; The confirmation information acquisition module is used to acquire payment confirmation information containing the second payment voucher sent by the user terminal; The payment processing module is used to process the payment request based on the user information of the user terminal if the first payment voucher is the same as the second payment voucher.

32. A payment device, applied to a user terminal, comprising: The trigger information sending module is used to send near-field communication trigger information; The credential acquisition module is used to acquire a payment credential sent by a near-field communication device in response to the near-field communication triggering information; the payment credential is generated before the near-field communication device acquires the near-field communication triggering request; the payment credential does not include the user information of the user terminal; The transaction processing module is used to trigger the execution of the transaction process based on the payment voucher.

33. 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 29.

34. 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 29.

Images