A member payment method, device, equipment and medium

Abstract

This specification discloses a membership payment method, apparatus, device, and medium. The scheme may include: a user terminal sending a near-field communication (NFC) trigger signal; obtaining a membership payment link provided by a NFC device responding to the NFC trigger signal; the membership payment link including fixed information and a dynamic token; determining that a target application in the user terminal is in a running state based on an application identifier contained in the fixed information; sending confirmation information containing the dynamic token to a server based on the running target application; the server determining the user information and payment credential of the user terminal based on the dynamic token and sending them to a merchant device associated with the NFC device; and obtaining payment result information fed back by the server.

Description

Technical Field

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

[0002] With the rapid development of the internet economy, user consumption behavior is gradually shifting from single transactions to continuous service relationships. Against this backdrop, membership mechanisms, as a core user operation model, significantly improve user stickiness and commercial value conversion efficiency through differentiated services and incentive benefits, leading to an increasing number of businesses using membership mechanisms to provide services to users.

[0003] Currently, in consumer scenarios, the common way to use memberships is for merchants to scan the membership code provided by the user through a mobile phone or other terminal, or for the merchant to ask for the user's mobile phone number, membership number, and other information. The merchant first completes the user's membership login on the cashier or other merchant equipment, and then the merchant checks out the goods purchased by the user. During the checkout process, the user also needs to use the payment code provided by the mobile phone or other terminal to complete the checkout. The whole process requires multiple operations by the merchant or the user, which is quite cumbersome.

[0004] Therefore, there is a need to provide a more convenient method for member payments. Summary of the Invention

[0005] This specification provides a membership payment method, apparatus, device, and medium to solve the problem of cumbersome operation in existing membership payment methods.

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

[0007] This specification provides an embodiment of a membership payment method applied to a user terminal, including:

[0008] Send a near-field communication trigger signal;

[0009] Obtain a membership payment link provided by a near-field communication device in response to the near-field communication trigger signal; the membership payment link includes fixed information and a dynamic token;

[0010] Based on the application identifier contained in the fixed information, it is determined that the target application in the user terminal is in the running state.

[0011] The target application, once launched, sends confirmation information containing the dynamic token to the server; the server determines the user information and payment credential of the user terminal based on the dynamic token and sends them to the merchant device associated with the near-field communication device; the merchant device executes a membership processing procedure based on the user information and sends a payment request to the server based on the payment credential; the payment credential represents the user account information of the user terminal.

[0012] Obtain payment result information from the server; the payment result information is generated by the server based on the payment request sent by the merchant's device.

[0013] This specification provides an embodiment of a membership payment method applied to near-field communication devices, comprising:

[0014] Acquire the near-field communication trigger signal sent by the user terminal;

[0015] In response to the near-field communication trigger signal, a membership payment link is sent to the user terminal; the membership payment link includes fixed information and a dynamic token; the user terminal is used to execute the above method based on the membership payment link.

[0016] This specification provides an embodiment of a membership payment device, comprising:

[0017] Trigger signal sending module, used to send near-field communication trigger signals;

[0018] The link acquisition module is used to acquire a membership payment link provided by a near-field communication device in response to the near-field communication trigger signal; the membership payment link includes fixed information and a dynamic token;

[0019] The application startup module is used to determine whether the target application in the user terminal is in a startup state based on the application identifier contained in the fixed information.

[0020] The information sending module is used to send confirmation information containing the dynamic token to the server based on the launched target application; the server is used to determine the user information and payment credential of the user terminal based on the dynamic token and send them to the merchant device associated with the near-field communication device; the merchant device is used to execute a membership processing procedure based on the user information and send a payment request to the server based on the payment credential; the payment credential is used to represent the user account information of the user terminal;

[0021] The result acquisition module is used to acquire payment result information fed back by the server; the payment result information is generated by the server based on the payment request sent by the merchant's device.

[0022] This specification provides an embodiment of a membership payment device, comprising:

[0023] The trigger signal acquisition module is used to acquire the near-field communication trigger signal sent by the user terminal;

[0024] A link sending module is used to send a membership payment link to the user terminal in response to the near-field communication trigger signal; the membership payment link includes fixed information and a dynamic token; the user terminal is used to execute the above method based on the membership payment link.

[0025] This specification provides an embodiment of a membership payment device, comprising:

[0026] At least one processor; and,

[0027] A memory communicatively connected to the at least one processor; wherein,

[0028] The memory stores instructions that can be executed by the at least one processor, which, when executed, enable the at least one processor to perform the aforementioned member payment method.

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

[0030] At least one embodiment of this specification can achieve the following beneficial effects: A user terminal can obtain a member payment link from a near-field communication device associated with a merchant device via near-field communication. This member payment link includes fixed information and a dynamic token. The user terminal can launch a target application based on the application identifier contained in the fixed information, and can also send the dynamic token to the server based on the target application. After receiving the dynamic token sent by the user terminal, the server can determine the user information and payment credentials of the user terminal and send them directly or indirectly to the merchant device associated with the near-field communication device. The merchant device can execute a member processing flow based on the user information, and can also send a payment request to the server based on the payment credentials to complete the payment process. The user terminal can also obtain transaction result information generated by the server processing the payment request sent by the merchant device.

[0031] In the embodiments described in this specification, the user terminal can obtain link information for membership payment via near-field communication (NFC). Based on the user terminal's access, the server can send user information and payment credentials to the merchant device. The merchant device can execute the membership processing flow based on the user information and request the server to process payment transactions based on the payment credentials. Throughout this process, a single interaction between the user terminal and the NFC device can trigger both membership login and payment processes, thus simplifying both user and merchant operations.

[0032] For example, users only need to touch their terminal with the near-field communication device once to use their membership benefits for payment, without having to log in and then make the payment. For merchants, there's no need to manually enter user information, such as phone numbers, and then manually perform payment operations like scanning QR codes.

[0033] On the other hand, in the embodiments of this specification, the server queries the user terminal's user information and payment credentials based on the dynamic token sent by the user terminal. The user terminal sending the dynamic token to the server indicates the user's consent to make membership payments. In other words, the server only queries the user terminal's relevant information after user confirmation, which improves the security of user information. It also reduces invalid queries and saves computing resources. Attached Figure Description

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

[0035] Figure 1 This is a schematic diagram illustrating an application scenario of a membership payment method provided in the embodiments of this specification;

[0036] Figure 2 A flowchart illustrating a membership payment method provided in an embodiment of this specification;

[0037] Figure 3 This is a flowchart illustrating a member payment method provided in the embodiments of this specification;

[0038] Figure 4 Swimlane diagram of a membership payment method provided in the embodiments of this specification;

[0039] Figure 5 The embodiments provided in this specification correspond to Figure 2A schematic diagram of the structure of a membership payment device;

[0040] Figure 6 The embodiments provided in this specification correspond to Figure 3 A schematic diagram of the structure of a membership payment device;

[0041] Figure 7 This is a schematic diagram of a membership payment device provided in an embodiment of this specification. Detailed Implementation

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

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

[0044] 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."

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

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

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

[0048] 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. A device in this mode can be called a card reader device.

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

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

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

[0052] In practical applications, NFC tags can also be software, such as devices in card emulation mode. When an NFC tag is software, it can be installed on a physical card or in a terminal device. It can be implemented as multiple software programs or software modules (e.g., to provide distributed authentication services) or as a single software program or software module.

[0053] Membership payment refers to a payment method where users make payments as members. Specifically, it can mean that users become members of a specific platform or service provider, for example, by registering for free or for a fee, and thus obtain exclusive payment methods or benefits, enjoying convenience, security, or additional discounts in transactions.

[0054] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0055] Figure 1 This is a schematic diagram illustrating an application scenario of a membership payment method provided in an embodiment of this specification. For example... Figure 1 As shown, the solution 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 send a NFC trigger signal in NFC reader mode. The NFC device 2 may contain an NFC tag or be in card emulation mode. When the user terminal 1 and the NFC device 2 are close together, for example, when the user touches the NFC device with their terminal, the NFC device 2 can respond to the NFC trigger signal from the user terminal 1 by sending NFC tag information to the user terminal 1. The NFC tag information includes a membership payment link used to trigger membership payments.

[0056] User terminal 1 can launch the target application based on the application identifier in the member payment link. The launched payment application can then send confirmation information containing the dynamic token from the member payment link to server 4. This confirmation information indicates that the user agrees to make a member payment; specifically, it indicates that the user agrees to log in or register as a merchant member and use their membership to make a payment. After receiving the dynamic token sent by the user terminal, server 4 can query the user terminal's user information and payment credentials, and send these directly or indirectly to merchant device 3. Merchant device 3, upon receiving the user information, can execute member login or registration processes for managing member information. Furthermore, merchant device 3 can use the obtained payment credentials to initiate a payment request to server 4, requesting server 4 to process the transaction required by the user terminal.

[0057] In practical applications, user terminal 1 can be one or more of the following: smartphone, laptop, tablet, IoT device, portable wearable device, or immersive image display device. Specifically, IoT devices can be one or more of the following: smart speaker, smart TV, smart air conditioner, or smart in-vehicle device. Portable wearable devices can be one or more of the following: smartwatch, smart bracelet, or head-mounted device. Immersive image display devices include, but are not limited to, augmented reality (AR) devices and virtual reality (VR) devices.

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

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

[0060] In practical applications, near-field communication device 2 and 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, thus associating near-field communication device 2 with merchant device 3. From a hardware perspective, near-field communication device 2 and merchant device 3 can be two independent devices or an integrated device; no specific limitation is made here. 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.

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

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

[0063] Figure 2This is a flowchart illustrating a membership 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 user terminal. From a hardware perspective, the entity executing the process can be the user terminal.

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

[0065] Step 202: Send a near-field communication trigger signal.

[0066] In the embodiments of this specification, the user terminal can act as a near-field communication (NFC) card reader device, emitting a NFC trigger signal to initiate NFC communication. Specifically, the NFC function of the user terminal can be enabled and it can be in card reader mode, sending electromagnetic signals to establish NFC communication. In practical applications, the user terminal can be in card detection mode, emitting a card detection signal to detect whether an NFC tag or NFC card is nearby. After confirming the presence of an NFC tag or NFC card, it can perform NFC NFC NFC communication with the NFC tag or NFC card to obtain information from it. For specific details, please refer to relevant technologies; they will not be elaborated here.

[0067] In practical applications, 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 NFC reader mode and send a near-field communication (NFC) trigger message. Alternatively, before making a payment, the user can use their mobile phone or smartwatch, which remains in NFC reader mode throughout the process, sending NFC trigger messages through either 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.

[0068] In practical applications, user terminals can also activate NFC reader mode while the device is not unlocked. For example, a user terminal can activate NFC reader mode when the screen is on. Alternatively, if the user terminal obtains biometric information such as facial or iris scans when the screen is off or locked, it can activate NFC reader mode. Or, the user can activate NFC reader mode by performing some preset operations on the user terminal, such as pressing the power button or volume buttons once or multiple times. There are no specific limitations on the timing or method of activating NFC reader mode, as long as it is activated before engaging in near-field communication with the device.

[0069] Step 204: Obtain the membership payment link provided by the near-field communication device in response to the near-field communication trigger signal; the membership payment link includes fixed information and a dynamic token.

[0070] Near-field communication (NFC) devices can be electronic devices with NFC functionality and logic processing capabilities. NFC devices can operate in NFC card emulation mode or may include NFC tags to store NFC tag information. If the NFC device is within the NFC range of a user terminal, it can respond to a NFC trigger signal sent by the user terminal and send tag information to the user terminal. The tag information may contain a membership payment link. This link can be in HTTP, HTTPS, or other formats. The membership payment link may include fixed information and a dynamic token. The fixed information can represent information shared across different membership payment links. The dynamic token can represent a unique token for the membership payment link, such as a token. Different membership payment links may contain the same fixed information but different dynamic tokens.

[0071] Step 206: Based on the application identifier contained in the fixed information, determine that the target application in the user terminal is in the running state.

[0072] The target application can be a terminal application with payment functionality. For example, it could be a mobile app (APP) or a mini-program. The application identifier can be uniquely identifying the application, such as its name, abbreviation, or package name. Different user terminals or user terminals on different systems can determine the corresponding target application based on this application identifier.

[0073] In practical applications, if the user terminal has not launched the target application before obtaining the membership payment link information, it can launch the target application after obtaining the membership payment link information. Specifically, the user terminal's system program can parse the application identifier from the payment link information, launch the target application, and then provide the membership payment link or the dynamic token within that link to the target application, which then accesses the server based on the membership payment link or dynamic token. If the user terminal has already launched or is using the target application before obtaining the payment link information, the user terminal does not need to launch it again after obtaining the payment link information; the already launched target application can access the server based on the membership payment link or dynamic token.

[0074] The target application can be in the foreground or background of the user's terminal; there is no specific limitation here.

[0075] Step 208: Based on the launched target application, send confirmation information containing the dynamic token to the server.

[0076] The server can be used to determine the user information and payment credential of the user terminal based on the dynamic token and send them to the merchant device associated with the near-field communication device. The merchant device is used to execute a membership processing procedure based on the user information and to send a payment request to the server based on the payment credential. The payment credential represents the user account information of the user terminal.

[0077] The confirmation information can indicate that the user agrees to use their membership benefits for payment. For example, it can indicate that the user agrees to log in as a member or register as a member and make a payment. The confirmation information may include a dynamic token contained in the membership payment link obtained by the user's terminal. The server can pre-set the execution flow that the dynamic token can trigger. In the embodiments of this specification, the membership payment link can trigger two processes: member login and payment. Specifically, after the server obtains the dynamic token sent by the terminal, it can query the user information and payment voucher of the user terminal. The user information can be information used to identify the user and can be used to determine the user's membership benefits. The payment voucher can be information used to identify the user account on the user terminal and can be used to determine the user account making the payment.

[0078] In practical applications, to distinguish different users, after a user registers on a network 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, capable of uniquely identifying the user. As another implementation method, user information may include the user's unique identifier within the target application. For example, the user's UID within the target application.

[0079] Of course, user information can also be other information that can uniquely identify a user or represent the user's identity, 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.

[0080] A payment credential can be information representing a user's account on a user terminal, enabling the merchant's device to trigger a transaction process. For example, a payment credential could be a user's payment account, a payment code corresponding to that account, etc. As one implementation, the payment credential may include the payment code number of the user's account on the user terminal.

[0081] Payment code data can be a number representing a payment code. When a merchant cannot scan the QR code, payment can be completed by manually entering this string of numbers. In common QR code payment scenarios, merchants scan the payment code presented by the user's terminal to obtain the corresponding payment code number and then execute the corresponding payment processing flow. The payment code number can correspond to a unique payment account. The payment code number can be a string that conforms to preset rules. For example, the payment code number can be a string containing only numbers, or it can be a string containing multiple character formats such as numbers, letters, and symbols. For example, a string starting with "28", a string starting with "13", etc. The specific format of the payment code number can be set according to actual needs or the format supported by the target application; no specific limitations are made here.

[0082] Merchant equipment can refer to the equipment used by merchants to conduct transactions, such as cash registers, POS machines, and self-checkout devices.

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

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

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

[0086] 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. Furthermore, 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 the NFC device. For example, 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. Alternatively, after the NFC device is distributed 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.

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

[0088] In practical applications, after the server determines the user information and payment voucher of the user terminal, it can send them directly to the merchant's device, or it can send them to the near-field communication device, which will then send them to the merchant's device.

[0089] In one implementation, the member payment link can be generated by the server and sent back to the near-field communication device. The server can store the correspondence between the member payment link or dynamic token and the near-field communication device, and can also store the correspondence between the near-field communication device and the associated merchant device. After the server determines the user information and payment credential based on the dynamic token sent by the user terminal, it can also determine the merchant device associated with the near-field communication device using the dynamic token, and then send the user information and payment credential to the merchant device.

[0090] As another implementation, the member payment link can be generated by the server and sent back to the near-field communication device (NFC). The server can store the correspondence between the member payment link or dynamic token and the NFC device. After determining the user information and payment credential based on the dynamic token sent by the user terminal, the server can also determine the NFC device using the dynamic token, and then send the user information and payment credential to the NFC device. The NFC device can provide the user information and payment credential to the merchant's device wirelessly or via a wired connection.

[0091] Merchant devices can execute membership processing procedures based on user information. For example, user information can be used to determine a user's membership benefits at the merchant's membership center, such as membership level, discount amount, and discount information. Alternatively, it can add membership points to a user after payment is completed.

[0092] Merchant devices can also generate payment requests based on payment credentials and send them to the server. These payment requests may include the payment credentials or identifying information that represents them, enabling the server to determine the paying user.

[0093] In practical applications, when the server returns user information and payment credentials, it can also include a dynamic token. Merchant devices can also send payment requests to the server based on payment credentials and dynamic tokens. The payment request may include payment credentials or identification information that can represent the payment credentials, and may also include a dynamic token.

[0094] Alternatively, after the user terminal reads the member payment link, the near-field communication (NFC) device can detect that the link has been read and can also send a dynamic token to the merchant device; or, after obtaining the user information and payment credentials from the server, the NFC device can provide the dynamic token along with the payment credentials to the merchant device, so that the merchant device can also initiate payment to the server based on the dynamic token and payment credentials. The server can determine the transaction between the two parties based on the dynamic token and process it.

[0095] Step 210: Obtain the payment result information fed back by the server; the payment result information is generated by the server based on the payment request sent by the merchant's device.

[0096] After receiving a payment request from a merchant's device, the server can process the transaction requested by the payment request and generate payment result information. This payment result information can indicate that the payment was completed, successful, or failed, etc.

[0097] The server can send payment result information back to the user's terminal. The user's terminal can then display the payment result information, or play a notification sound or voice message.

[0098] In practical applications, the server can also send payment result information back to the merchant's device and / or near-field communication (NFC) device. The content or format of the payment result information displayed on the user terminal, merchant's device, and NFC device can be the same or different; no specific limitations are imposed here.

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

[0100] Figure 2 The proposed method allows user terminals to obtain a link for membership payments via near-field communication (NFC). Based on this access, the server can send user information and payment credentials to the merchant's device. The merchant's device can then execute membership processing based on the user information and request payment processing from the server based on the payment credentials. In this entire process, a single interaction between the user terminal and the NFC device triggers both membership login and payment processes, simplifying operations for both users and merchants. For example, users only need to touch their terminal to the NFC device once to use their membership benefits for payment, eliminating the need for separate login and payment steps. For merchants, there's no need to manually input user information, such as phone numbers, and then manually perform payment operations like scanning QR codes.

[0101] On the other hand, in the embodiments of this specification, the server queries the user terminal's user information and payment credentials based on the dynamic token sent by the user terminal. The user terminal sending the dynamic token to the server indicates the user's consent to make membership payments. In other words, the server only queries the user terminal's relevant information after user confirmation, which improves the security of user information. It also reduces invalid queries and saves computing resources.

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

[0103] In practical applications, when a user makes a payment at a merchant, the user may not have previously registered as a merchant member, or they may already be a registered member. The user terminal can display different page information depending on the situation. As one implementation, if the user terminal user is not a registered member of the merchant to which the merchant device belongs; the sending of confirmation information containing the dynamic token to the server based on the launched target application may specifically include:

[0104] Based on the launched target application, a member registration and payment page is displayed;

[0105] Based on the user's confirmation action on the membership registration and payment page, a first confirmation message indicating agreement to register as a member and make payment is generated and sent to the server; the first confirmation message includes the dynamic token.

[0106] After a user terminal obtains a member payment link, it can access the server based on that link. The server, using a dynamic token, can identify the corresponding merchant device or merchant. For example, the server may store one or more correspondences between merchants, merchant devices, near-field communication devices, member payment links, or dynamic tokens. Based on these correspondences, when a user terminal accesses the server using a member payment link, the server can determine the merchant corresponding to that link. The server or the merchant's server may store member information. After receiving access from a user terminal, the server can determine whether the user is a registered member based on the stored member information. If the user is not a registered member, i.e., a new member requiring registration, the server can send a member registration and payment page to the user terminal.

[0107] Alternatively, the user terminal or the target application on the terminal can store the merchant members that the user has already registered with, allowing the user terminal to determine locally whether the user is a registered member. For example, the member payment link can contain a merchant identifier, and the user terminal can record the identifier information of each merchant that the user has already registered with. After obtaining the member payment link, the user terminal can determine whether the user is a member of the merchant corresponding to that member payment link based on the merchant identifier in the member payment link and the user's previously registered merchant members. If the user is not a member of the merchant corresponding to that member payment link, a registration request can be sent to the server, and the server can return a member registration and payment page to the user terminal.

[0108] In this embodiment of the specification, the member registration and payment page can be a page used to trigger the member registration and payment process. This page may include a confirmation control, a member registration prompt, or an authorization agreement. The confirmation control can indicate that the user agrees to register as a member and make a payment, such as a control displaying the words "Register Member and Pay". If the user performs an operation on the confirmation control, it indicates that the user agrees to register as a merchant member and agrees to make payments as a merchant member.

[0109] In practical applications, confirmation controls can also be controls that allow users to not perform any actual operations. For example, a countdown timer can be displayed in or near the confirmation control display area. If the user does not click the cancel control or exit the member registration and payment page within the preset countdown time, it can also indicate that the user agrees to register as a member and make a payment. The user terminal can also generate first confirmation information containing a dynamic token.

[0110] If a user is a newly registered member, the user information provided by the server to the merchant's device or near-field communication device may include, in addition to the user's unique identifier in the target application, information representing the user's identity provided in the target application and provided to the merchant's device or near-field communication device, with the user's authorization and consent. This includes, for example, the user's mobile phone number, nickname, name, ID card number, etc., so that the merchant's device or management system can manage members based on user identity information. Specific methods or content of member management can be found in existing related technologies and will not be elaborated here. It is understood that this information representing user identity is compliant and legal.

[0111] Considering practical applications, some users may not want to register as members and only want to make regular payments. The aforementioned membership registration and payment page can also include controls for payment-only transactions, such as controls displaying the words "Direct Payment." If a user interacts with this control, the user terminal can send payment confirmation information containing a dynamic token to the server. Based on this information, the server can send the retrieved payment credentials from the user terminal to the merchant device or near-field communication device (NFC), without needing to send the user's personal information. Alternatively, the server can send an instruction indicating a regular payment to the merchant device or NFC, allowing the merchant device to initiate payment to the server based on the dynamic token. In this case, the merchant device does not need to perform membership processing for the user terminal.

[0112] If the user is already a merchant member, the user terminal can also display a page for member login and payment after obtaining the member payment link. Optionally, if the user on the user terminal is a registered member of the merchant where the merchant device is located; the step of sending confirmation information containing the dynamic token to the server based on the launched target application can specifically include:

[0113] Based on the launched target application, a member login and payment page is displayed;

[0114] Based on the user's confirmation action on the member login and payment page, a second confirmation message indicating agreement to log in and make payment is generated and sent to the server. The second confirmation message includes the dynamic token.

[0115] The member login and payment page can be a page used to trigger the member login and payment process. This page may contain confirmation controls, member login prompts, or login authorization agreements. Confirmation controls indicate that the user agrees to log in as a member and make a payment, such as controls displaying the words "Log in as a member and make a payment." If the user interacts with this confirmation control, it indicates that the user agrees to log in as a merchant member and agrees to make payments as a merchant member.

[0116] In practical applications, confirmation controls can also be controls that allow users to not perform any actual operations. For example, a countdown timer can be displayed in or near the confirmation control display area. If the user does not click the cancel control or log out of the member login and payment page within the preset countdown time, it can also indicate that the user agrees to log in as a member and make a payment. The user terminal can also generate first confirmation information containing a dynamic token.

[0117] The aforementioned member registration and payment page and / or member login and payment page can be a page displayed on the user terminal after the server sends page information back to the user terminal following the user terminal's access to the server via a member payment link; alternatively, the member registration and payment page and / or member login and payment page can be generated and displayed locally on the user terminal based on a preset page template. The member registration and payment page and / or member login and payment page may also include cancellation controls, page close controls, etc. The specific generation process and content of the page are not specifically limited here and can be set according to actual needs.

[0118] In practical applications, to further simplify user operations, users can authorize terminal applications to automatically process some information requiring confirmation. As one implementation, the target application can have a high-speed business processing function. Once this function is activated, the user terminal may not render and display the intermediate business page, or may display it within a very short time, with the target application automatically performing the confirmation operation on the intermediate page, eliminating the need for manual user intervention. Optionally, it can be determined whether the user terminal has activated the high-speed business processing function; the high-speed business processing function is the function where the target application automatically processes the intermediate business page, eliminating the need for manual user operation. Specifically, displaying the member login and payment page may include: if the user terminal has not activated the high-speed business processing function, then displaying the member login and payment page.

[0119] The target application on the user terminal can record whether the user has enabled the high-speed service processing function. The above judgment steps can be executed locally on the user terminal.

[0120] If the user does not activate the high-speed service processing function, the user terminal can display a member login and payment page. After the user performs a confirmation operation on this page, the user terminal can send a second confirmation message containing a dynamic token to the server.

[0121] Optionally, the method in the embodiments of this specification may further include: if the user terminal has activated the high-speed service processing function, the target application automatically generates third confirmation information containing the dynamic token.

[0122] If the user terminal has activated the express service function, after obtaining the member payment link, the user terminal may not display the member login and payment page on the front end, or it may display the page but the target application will automatically perform the confirmation operation without requiring the user to perform the confirmation operation. The target application may also send confirmation information containing a dynamic token to the server.

[0123] If the member login and payment page is generated locally on the user's terminal, and if the user has enabled the express business processing function before or after confirming that the user is a registered user, the member login and payment page may not be generated locally on the user's terminal; instead, confirmation information containing a dynamic token may be generated directly.

[0124] If the member login and payment page is generated by the server, the server can generate the page information according to a preset process and send it back to the user terminal. If the user terminal has enabled the high-speed business processing function, after receiving the page information, the user terminal may not render and display the member login and payment page. Instead, the target application will automatically perform the confirmation operation on the page in the background. Alternatively, the user terminal may send a second confirmation message containing a dynamic token to the server without displaying the member login and payment page. Alternatively, after receiving the page information, the user terminal can render and display the member login and payment page on the front end. After the member login and payment page is displayed, the target application will automatically perform the confirmation operation and send a confirmation message containing a dynamic token to the server.

[0125] From the user's perspective, after the user touches the user terminal with the near-field communication device, the membership payment can be completed without any other operation.

[0126] In practical applications, the aforementioned high-speed business processing function can be a service function provided by the target application, or it can be a service provided by the target application to the user based on user authorization and under preset conditions, such as good user credit. It can also be a function that does not require the user to manually start it.

[0127] In practical applications, the target application can also provide high-speed business processing functions for all application users. The above-mentioned step of determining whether the user terminal has started the high-speed business processing function can also be omitted. After the user terminal obtains the member payment link, the target application in the started state can automatically send confirmation information containing dynamic tokens to the server.

[0128] Considering that user terminals or servers also need some time to execute business processes, in order to improve user experience, after the user terminal obtains the member payment link, during the process of launching the target application, a page indicating that the target application is launching can be displayed, or during the process of logging in or registering as a member, a page indicating that the member is logging in or registering can be displayed, or during the process of the server obtaining the payment request sent by the merchant device and processing the transaction, the user terminal can also display a page indicating that the transaction is being processed, and so on.

[0129] Based on the same idea, this specification also provides a method with a near-field communication device as the execution subject in the embodiments. Figure 3 This is a flowchart illustrating a membership payment method provided in the embodiments 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. For example... Figure 3 As shown, the process may include the following steps.

[0130] Step 302: Obtain the near-field communication trigger signal sent by the user terminal.

[0131] Step 304: In response to the near-field communication trigger signal, send a member payment link to the user terminal.

[0132] The member payment link includes fixed information and a dynamic token; the user terminal is used to execute the member payment method described above based on the member payment link.

[0133] The technical details of features such as user terminals, near-field communication devices, and member payment links can be found in the aforementioned embodiments and will not be repeated here.

[0134] In practical applications, to prevent users from accidentally logging into memberships by accidentally touching the near-field communication (NFC) device, and for payment security, the membership payment link sent by the NFC device to the user terminal in this embodiment can be a membership payment link determined by the NFC device after the merchant device triggers the membership login process. Optionally, before obtaining the NFC trigger signal sent by the user terminal, the process may further include: obtaining a membership login instruction issued by the merchant device associated with the NFC device; and determining the membership payment link based on the membership login instruction.

[0135] In practical applications, cashiers and other users can perform operations on the merchant's device. When a user needs to settle the transaction, the cashier can perform a member login operation on the merchant's device, such as clicking a button or control to trigger the member login process. Alternatively, when the merchant's device is a self-checkout device, the user can perform the member login operation on the merchant's device. The member login instruction can be generated by the merchant's device based on preset operations performed by the checkout personnel on the merchant's device.

[0136] Near Field Communication (NFC) devices can be associated with merchant devices. For example, NFC devices and merchant devices can be associated through at least one of the following methods: network, data cable; or, a server can store a mapping between NFC devices and their associated devices.

[0137] Merchant devices can send member login commands to near-field communication (NFC) devices via network or data cable. Alternatively, merchant devices can send member login commands to a server, which then forwards the command to the NFC device.

[0138] After receiving a member login command, the near-field communication device can place the member payment link in the NFC tag, or set the NFC tag or the member payment link in the NFC tag to a usable state, so that the near-field communication device can send the member payment link to the user terminal in response to the near-field communication trigger signal of the user terminal.

[0139] Understandably, in practical applications, near-field communication (NFC) devices may not need to receive member login commands sent by the merchant device. The tag information of the NFC device can be obtained by the user terminal at any time, without the need for the merchant device to send trigger commands. No specific restrictions are placed here regarding whether the merchant device needs to send member login commands.

[0140] The member payment link can be requested by the near-field communication device from the server, or it can be a member payment link pre-stored locally on the near-field communication device.

[0141] As one implementation method, determining the member payment link based on the member login instruction may specifically include: sending a link information retrieval request to the server based on the member login instruction; and retrieving the member payment link returned by the server.

[0142] Near-field communication (NFC) devices can interact with servers. A specific NFC device may contain an application or application terminal. The NFC device can access the server according to a preset access path and send a link information retrieval request to the server. This request may include the NFC device's identification information, and may also include business identification information to instruct the server to provide a member payment link. Upon receiving the request, the server can determine whether to execute the process of generating a member payment link and then send the member payment link back to the NFC device.

[0143] To ensure the uniqueness of member payment links, dynamic tokens can also be generated based on the identification information of near-field communication devices. For example, dynamic tokens can be generated based on the device number of the near-field communication device, or they can be generated based on the device number and timestamp.

[0144] To improve the efficiency of member payments, the near-field communication (NFC) device can locally store fixed information contained in the member payment link. A dynamic token can be generated by the server, and then the NFC device can locally assemble the member payment link. This reduces the amount of data transmission between the server and the NFC device, improving data transmission efficiency and stability, and also enhancing the user experience. Optionally, obtaining the member payment link returned by the server may specifically include: obtaining the dynamic token returned by the server; and assembling the dynamic token with the fixed information stored locally on the NFC device to obtain the member payment link.

[0145] After receiving the dynamic token from the server, the near-field communication (NFC) device can combine locally stored fixed information with the acquired dynamic token according to preset rules to obtain a member payment link. For example, the NFC device may have a link template locally, or a link template containing fixed information. The dynamic token can be placed into the link template to obtain the member payment link.

[0146] In this embodiment of the specification, to improve processing efficiency, the near-field communication device may also pre-store one or more backup membership payment links locally. These backup membership payment links may be membership payment links that already exist locally on the near-field communication device before the merchant device issues the membership login command. Optionally, the near-field communication device may store several backup membership payment links locally; the aforementioned determination of the membership payment link based on the membership login command specifically includes sending the membership payment link to the user terminal, which may specifically include selecting one membership payment link from the several backup membership payment links stored locally.

[0147] As one implementation, the near-field communication device may have a local logic program for generating member payment links. When the number of idle or standby member payment links of the near-field communication device is less than or equal to a preset number, the near-field communication device may locally generate one or more standby member payment links.

[0148] To ensure the uniqueness of transactions, member payment links can be links that can only be used once. After providing the member payment link to the user terminal, the near-field communication device can delete the member payment link or mark it as invalid.

[0149] As another implementation, the backup membership payment links stored locally by the near-field communication device can be provided by a server. Optionally, before obtaining the near-field communication trigger signal sent by the user terminal, the process may further include: obtaining the plurality of backup membership payment links sent by the server; and saving the plurality of backup membership payment links to the local storage space of the near-field communication device.

[0150] In practical applications, near-field communication devices can request the server to send a backup membership payment link, or the server can proactively push a backup membership payment link to the near-field communication device.

[0151] For example, if the number of available backup membership payment links locally on the near-field communication (NFC) device is less than or equal to a preset number, the NFC device can send a link acquisition request to the server. This request can also include information about the number of membership payment links to be acquired. Based on this request, the server can send back the corresponding number of membership payment links to the NFC device, which will then store them locally as backup membership payment links. If a user terminal establishes NFC communication with the NFC device, the NFC device can provide the user terminal with the membership payment links stored locally.

[0152] For example, the server can record the number of member payment links sent to the near-field communication device, and can also record the number of payment requests sent by merchant devices associated with the near-field communication device. Then the server can determine whether the number of available backup member payment links on the near-field communication device is less than or equal to a preset number. If it is less than or equal to the preset number, the server can actively push a certain number of member payment links to the near-field communication device.

[0153] For example, after the near-field communication device sends a membership payment link to the user terminal, it can request the server or generate a new membership payment link based on local logic programs as a backup membership payment link for later use.

[0154] Near-field communication (NFC) devices can have a storage module, and the NFC device can store fixed information locally. For example, the local storage space of the NFC device can be memory space, cache space, or even a trusted execution environment (TEE). There is no specific limitation on the storage space here.

[0155] Similar to the above embodiments, the aforementioned acquisition of the plurality of backup member payment links sent by the server may specifically include: the plurality of backup dynamic tokens sent by the server.

[0156] Near-field communication devices can assemble various backup dynamic tokens based on existing local fixed information or link templates to obtain backup member payment links.

[0157] For example, after a near-field communication (NFC) device receives a NFC trigger signal from a user terminal, it can select a dynamic token from the backup dynamic tokens and concatenate it according to existing fixed information or link templates to obtain a membership payment link that can be sent to the user terminal. Alternatively, after acquiring several backup dynamic tokens, the NFC device can concatenate each dynamic token using existing fixed information or link templates, or the NFC device can perform the concatenation process when idle to obtain various backup membership payment links. The timing of membership payment link generation is not limited here.

[0158] In the embodiments of this specification, the merchant device can reuse existing membership management links and payment links. The user information and payment credentials of the user terminal queried by the server can be provided to the merchant device so that the merchant device can execute the membership processing flow based on the user information and send payment requests to the server based on the payment credentials.

[0159] In one implementation, the near-field communication (NFC) device can serve as an auxiliary device for the merchant device. The server can send user information and payment vouchers to the NFC device, which then provides them to the merchant device. Optionally, the method in the embodiments of this specification may further include: obtaining user information and payment vouchers from the user terminal fed back by the server; and sending the user information and payment vouchers to the merchant device associated with the NFC device.

[0160] In practical applications, the server that processes the payment request sent by the merchant device may be a different server from the server that provides user information and payment credentials. In the embodiments of this specification, the near-field communication device has the ability to access the server that provides user information and payment credentials. If the merchant device cannot access the server that provides user information and payment credentials according to the existing link, the near-field communication device can also obtain user information and payment credentials as an intermediary device. In this way, the merchant device can also execute the membership and payment process according to the existing link.

[0161] If a merchant's device can access a server that provides user information and payment credentials, this server may contain a mapping between merchant devices and near-field communication (NFC) devices, as well as mapping information between NFC devices and member payment links or dynamic tokens. After the user terminal sends a confirmation message containing the dynamic token to the server, the server can determine the merchant device corresponding to the dynamic token based on the mapping. The server can then send the determined user information and payment credentials to that merchant device. In this way, the merchant device can also obtain user information and payment credentials.

[0162] To ensure the accuracy of transactions, in this embodiment, the server can provide user information and payment credentials based on queries from the near-field communication device. Optionally, after responding to the near-field communication trigger signal and sending a member payment link to the user terminal, the process may further include: sending a transaction information query request containing the dynamic token to the server based on the dynamic token.

[0163] Specifically, a transaction information query request can be a request to the server to query user-related information from the user terminal that sent the same dynamic token. In practical applications, after a near-field communication device detects that a member payment link has been read, it can poll the server for user information and payment credentials based on the dynamic token in the member payment link.

[0164] If the server receives a transaction information query request from a near-field communication (NFC) device but has not yet received confirmation information from a user terminal containing a dynamic token consistent with the request, the server may choose not to process the current query request, or suspend or mark it as pending. If the server subsequently receives confirmation information from the user terminal containing a dynamic token consistent with the request, it can use this confirmation information to query the user terminal's user information and payment credentials, and then send the user information and payment credentials back to the NFC device that sent the transaction information query request containing the dynamic token, or to the merchant device associated with that NFC device.

[0165] In this embodiment, the server executes the process of querying user information and payment vouchers after receiving confirmation information from the user terminal. Before receiving confirmation information from the user terminal, the server may not execute the process of querying user information and payment vouchers. Even after receiving a transaction information query request from the near-field communication device, the server may not execute the process of querying user information and payment vouchers, but will wait until receiving confirmation information from the user terminal before executing it. After receiving the transaction information query request from the near-field communication device, the server will then provide the retrieved user information and payment vouchers. This ensures information security and avoids invalid queries.

[0166] To more clearly illustrate the member payment method provided in the embodiments of this specification, Figure 4 This is a swimlane diagram illustrating a membership payment method provided in an embodiment of this specification. Figure 4 As shown, the scheme may include the following steps.

[0167] Step 402: The merchant's device obtains the member login trigger operation performed by the cashier.

[0168] Merchant devices can be those with operating screens, keyboards, and other control components. When a user arrives at the checkout counter, the cashier can ask if the user is a member or if they are paying through a membership. After the user confirms their membership, the cashier can operate the merchant device, such as clicking the "Member" button, which triggers controls for member login and payment processes. The merchant device can then receive the member login trigger actions performed by the cashier.

[0169] In practical applications, if the merchant's equipment is a self-checkout device, the person who performs the member login trigger operation can also be the user making a purchase. Here, the specific entity that performs the trigger operation is not limited.

[0170] Step 404: Send member login command to near-field communication device.

[0171] Merchant devices can also send instructions to near-field communication (NFC) devices based on member login triggers performed by cashiers, so that NFC devices can request member payment links from the server.

[0172] Step 406: The near-field communication device sends a connection acquisition request to the server.

[0173] Among them, after receiving the instructions sent by the merchant's device, the near-field communication device can request the member payment link from the server.

[0174] The link retrieval request may include device identification information for the near-field communication device and / or the merchant's device, such as the device ID. The server can generate a member payment link based on the device identification information and send it to the near-field communication device.

[0175] Step 408: The server sends a payment link to the member's near-field communication device.

[0176] In practical applications, near-field communication devices can also pre-store one or more backup member payment link information, and steps 402 to 408 above can be omitted. For example, when the near-field communication device is idle or the number of pre-stored backup member payment link information is less than or equal to a preset number, the near-field communication device can actively send a link acquisition request to the server, or the server can actively push the link to the near-field communication device.

[0177] Membership payment links can include fixed information and dynamic tokens. To improve data transmission efficiency, the server can send back a dynamic token instead of the entire membership payment link to the near-field communication device. The near-field communication device can then assemble the membership payment link based on the acquired dynamic token and locally stored fixed information or link template.

[0178] Near-field communication (NFC) devices can include NFC tags. These tags can store member payment links, allowing users to access the links via NFC when a user terminal approaches or touches the device.

[0179] The server can also record which member payment links were sent to which near-field communication devices, the correspondence between near-field communication devices and merchant devices, and the merchant account information corresponding to the merchant devices, etc.

[0180] After sending a member payment link to a near-field communication device, the server can also record the correspondence between the member payment link and the near-field communication device, or record the correspondence between a dynamic token and the near-field communication device that received the dynamic token.

[0181] In practical applications, users can establish NFC near-field communication connections between user terminals such as mobile phones and smartwatches and near-field communication devices. For example, when a user touches or brings their mobile phone close to a near-field communication device, the user terminal, acting as an NFC card reader, can execute step 410: send a near-field communication trigger signal.

[0182] As one implementation method, when the user terminal is unlocked, it can be in NFC reader mode, emitting NFC electromagnetic signals to retrieve nearby NFC tags.

[0183] Near-field communication devices located within the near-field communication range of the user terminal can respond to the electromagnetic signal and send tag information back to the user terminal. Specifically, the near-field communication device can perform step 412: sending a membership payment link to the user terminal.

[0184] The membership payment link can be contained in the tag information of an NFC tag or an analog tag within a near-field communication (NFC) device. The NFC device can respond to a near-field communication trigger signal sent by the user terminal and send the membership payment link back to the user terminal via NFC. For details on the specific information transmission process, please refer to existing related technologies; these will not be elaborated upon here.

[0185] After determining that a membership payment link needs to be sent to the user terminal, or during the process of communicating the membership payment link with the user terminal, or after the transmission is completed, or after the near-field communication device detects that the link has been read, the near-field communication device can also request user-related information from the server through polling. Specifically, the near-field communication device can execute step 414: polling for user information based on a dynamic token.

[0186] Near-field communication devices can query the server for relevant information about the user who received the membership payment link or dynamic token based on the dynamic token in the membership payment link, according to a preset time frequency, until they obtain the relevant user information from the server.

[0187] In practical applications, user terminals can be equipped with terminal applications that have payment or membership management functions, such as terminal applications (APPs) or mini-programs. The membership payment link can contain the application identifier of the terminal application used to process payment transactions, and the user terminal can execute step 416: launch the payment application based on the application identifier.

[0188] The user terminal's system can launch the payment application on the user terminal based on the application identifier contained in the member payment link. This payment application can be one that the user has already registered and is using. With user authorization, the user terminal can automatically launch the payment application based on the application identifier. In practice, the payment application can be launched in the background or in the foreground; no specific limitation is made here.

[0189] The user terminal system can also provide a member payment link or a dynamic token in the link to the launched payment application. The payment application can access the server based on the link or dynamic token. The server can determine the user terminal as a user terminal that has established near-field communication with the near-field communication device based on the dynamic token. The server can determine the user terminal as a user terminal that is transacting with the near-field communication device or the merchant device. The user of the user terminal and the merchant of the merchant device are the two parties to the same transaction.

[0190] After the user terminal accesses the server, a member payment inquiry page can be displayed. This page may ask the user whether they want to log in as a member or use member payment. This page may include a confirmation control; by interacting with this control, the user agrees to log in as a member and use member benefits for payment. Alternatively, if the user has not yet registered as a merchant member, the member payment inquiry page may ask the user whether they want to register as a merchant member or make a payment. This page may include controls for registering as a member or registering and making a payment; by interacting with these controls, the user agrees to register as a merchant member or use member benefits for payment. If the user performs a confirmation operation based on the member payment inquiry page, the user terminal can execute step 418: send confirmation information to the server based on the launched payment application.

[0191] In practical applications, if a user is already a member of a merchant and has authorized the user terminal or payment application to perform member login or payment operations, the user terminal may not display a member payment inquiry page, such as a member login and payment page. Instead, the user terminal can automatically generate confirmation information and send it to the server. For example, after the user terminal accesses the server with a dynamic token via a launched payment application, the server can provide the merchant information corresponding to that dynamic token to the user terminal. After obtaining the merchant information, the user terminal can automatically execute the member login confirmation process and send confirmation information to the server.

[0192] Alternatively, after accessing the server, the user terminal can obtain and display the member payment inquiry page, but without requiring the user to perform a confirmation operation. The page can automatically exit within a short period of time, and the user terminal can automatically perform a confirmation operation and send confirmation information to the server.

[0193] After receiving the confirmation information sent by the user terminal, the server can execute step 420: query user information and generate a payment voucher.

[0194] Step 422: Return user information and payment credentials to the near-field communication device.

[0195] The user information can be payment-related or membership registration-related. Examples include user UID, mobile phone number, ID number, address, and email address.

[0196] Payment credentials can be information that represents the user's payment account, such as payment code information, like payment code numbers.

[0197] In practical applications, the existing processing capabilities of the merchant's equipment can be utilized or reused, allowing the merchant's equipment to execute the transaction process. The near-field communication device can also perform step 424: sending user information and payment credentials to the merchant's equipment.

[0198] After the merchant's device obtains the user information and payment voucher, it can execute step 426: execute the member login process based on the user information.

[0199] Merchant devices can query the member information database based on user information to determine the rights and interests of the member, and based on these rights and interests, determine the amount to be paid by the user, the amount of discounts they are entitled to, or the member's points, etc., to manage member information.

[0200] The merchant device can also perform step 428: Initiate payment based on payment credentials.

[0201] The merchant device can send a payment request to the server. The payment request may include the payment credential, the amount to be paid by the user, the merchant identification information, or the dynamic token contained in the payment link information, so that the server can determine the two parties to the transaction and the amount to be transacted.

[0202] In practical applications, if the merchant device has already obtained information about the goods to be paid for, such as the product name, quantity, and amount, before the cashier or other operator performs the member login trigger operation, the merchant device can first scan the product's barcode, and the checkout counter can then summarize the product's price and other information. After the cashier or other operator performs the member login trigger operation, the merchant device can also send the user's unpaid amount and other information to the near-field communication (NFC) device. The NFC device can then include this information in the NFC tag information and provide it to the user's terminal. The confirmation message sent from the user's terminal to the server can also include the user's unpaid amount and other information. In this way, the server can also verify the order based on the unpaid amount and other information, further ensuring the accuracy of the transaction.

[0203] Of course, the product information pending payment can also be obtained by the merchant's device after the cashier or other operator performs a member login trigger operation on the merchant's device. For example, the cashier first clicks the "Member" button at the checkout counter, and then performs operations such as scanning the product. In this way, when the merchant's device initiates payment, it can provide information such as the amount pending payment or the amount that the user actually needs to pay based on membership benefits to the server, and the server processes the transaction. The server can also execute step 430: execute the payment process and process the payment.

[0204] The server can process transactions based on payment requests sent by the merchant's device. For example, it can transfer resources from the user account corresponding to the user terminal to the merchant account corresponding to the merchant device.

[0205] The server can also generate transaction result information and execute step 432: send the transaction result information back to the user terminal.

[0206] In practical applications, the server can also send transaction result information back to near-field communication devices or merchant devices, without making specific limitations here.

[0207] Based on the same idea, embodiments of this specification also provide apparatus corresponding to the above methods. Figure 5 The embodiments provided in this specification correspond to Figure 2 A schematic diagram of a membership payment device. This device can be applied to user terminals. Figure 5 As shown, the device may include:

[0208] Trigger signal sending module 502 is used to send near-field communication trigger signals;

[0209] The link acquisition module 504 is used to acquire a membership payment link provided by a near-field communication device in response to the near-field communication trigger signal; the membership payment link includes fixed information and a dynamic token;

[0210] Application startup module 506 is used to determine that the target application in the user terminal is in a startup state based on the application identifier contained in the fixed information;

[0211] The information sending module 508 is used to send confirmation information containing the dynamic token to the server based on the launched target application; the server is used to determine the user information and payment credential of the user terminal based on the dynamic token and send them to the merchant device associated with the near-field communication device; the merchant device is used to execute a membership processing procedure based on the user information and send a payment request to the server based on the payment credential; the payment credential is used to represent the user account information of the user terminal;

[0212] The result acquisition module 510 is used to acquire payment result information fed back by the server; the payment result information is generated by the server based on the payment request sent by the merchant's device.

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

[0214] Optionally, different member payment links may contain the same fixed information as different dynamic tokens.

[0215] Optionally, the user information includes the user's unique identifier in the target application; the payment credential includes the payment code number of the user's account on the user terminal.

[0216] Optionally, if the user of the user terminal is not a registered member of the merchant to which the merchant device belongs, the above information sending module can be specifically used to: display a member registration and payment page based on the launched target application; generate first confirmation information indicating agreement to register as a member and make payment to the server based on the user's confirmation operation on the member registration and payment page; the first confirmation information includes the dynamic token.

[0217] Optionally, if the user of the user terminal is a registered member of the merchant where the merchant device is located, the above information sending module can be specifically used to: display a member login and payment page based on the launched target application; and generate second confirmation information indicating agreement to log in and pay to the server based on the user's confirmation operation on the member login and payment page, wherein the second confirmation information includes the dynamic token.

[0218] Optionally, the device may further include a judgment module. Before displaying the member login and payment page, the judgment module may be used to: determine whether the user terminal has started the high-speed business processing function; the high-speed business processing function is a function that automatically processes the intermediate business page of the target application without requiring the user to manually operate the intermediate business page.

[0219] The aforementioned display of the member login and payment page may specifically include: if the user terminal has not activated the high-speed service processing function, then the member login and payment page will be displayed.

[0220] Optionally, the device can also be used to: if the user terminal has activated the high-speed service processing function, the target application automatically generates third confirmation information containing the dynamic token.

[0221] Based on the same idea, embodiments of this specification also provide apparatus corresponding to the above methods. Figure 6 The embodiments provided in this specification correspond to Figure 3 A schematic diagram of a membership payment device. This device can be applied to near-field communication (NFC) equipment. Figure 6 As shown, the device may include:

[0222] The trigger signal acquisition module 602 is used to acquire the near-field communication trigger signal sent by the user terminal;

[0223] The link sending module 604 is used to send a membership payment link to the user terminal in response to the near-field communication trigger signal; the membership payment link includes fixed information and a dynamic token; the user terminal is used to execute the above method based on the membership payment link.

[0224] Optionally, the device may further include an instruction acquisition module. Before acquiring the near-field communication trigger signal sent by the user terminal, the instruction acquisition module may be used to: acquire a member login instruction issued by a merchant device associated with the near-field communication device; and determine a member payment link based on the member login instruction.

[0225] Optionally, the device may further include an information acquisition and transmission module, which can be used to: acquire user information and payment vouchers of the user terminal fed back by the server; and send the user information and payment vouchers to a merchant device associated with the near-field communication device.

[0226] Optionally, the device may further include a request sending module. After sending the member payment link to the user terminal in response to the near-field communication trigger signal, the request sending module may be used to: send a transaction party information query request containing the dynamic token to the server based on the dynamic token.

[0227] Optionally, determining the member payment link based on the member login instruction may specifically include: sending a link information retrieval request to the server based on the member login instruction; and retrieving the member payment link returned by the server.

[0228] Optionally, obtaining the member payment link fed back by the server may specifically include: obtaining the dynamic token fed back by the server; and assembling the dynamic token with the fixed information stored locally by the near-field communication device to obtain the member payment link.

[0229] Optionally, the near-field communication device has a number of backup member payment links stored locally; determining the member payment link based on the member login instruction may specifically include selecting one member payment link from the number of backup member payment links stored locally.

[0230] Optionally, the device further includes a storage module. Before acquiring the near-field communication trigger signal sent by the user terminal, the storage module can also be used to: acquire the plurality of backup member payment links sent by the server; and save the plurality of backup member payment links to the local storage space of the near-field communication device.

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

[0232] Figure 7 This is a schematic diagram of a membership payment device provided as an embodiment of this specification. Figure 7 As shown, device 700 may include:

[0233] At least one processor 710; and,

[0234] Memory 730 communicatively connected to the at least one processor; wherein,

[0235] The memory 730 stores instructions 720 that can be executed by the at least one processor 710, which, when executed by the at least one processor 710, enables the at least one processor 710 to perform the at least one membership payment method described above.

[0236] Based on the same approach, embodiments of this specification also provide a computer-readable medium corresponding to the above-described method. The computer-readable medium stores computer-readable instructions, which can be executed by a processor to implement the above-described membership payment method.

[0237] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. In particular, for... Figure 7 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0253] 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 membership payment method, applied to a user terminal, comprising: Send a near-field communication trigger signal; Obtain a member payment link provided by a near-field communication device in response to the near-field communication trigger signal; the member payment link includes fixed information and a dynamic token; after sending the member payment link to the user terminal, the near-field communication device sends a transaction party information query request containing the dynamic token to the server; The member payment link is selected by the near-field communication device from multiple pre-stored backup member payment links, or the near-field communication device stores the fixed information locally, and after obtaining the dynamic token from the server, the near-field communication device concatenates the locally stored fixed information with the dynamic token to obtain the member payment link; the fixed information represents the same information contained in different member payment links; Based on the application identifier contained in the fixed information, it is determined that the target application in the user terminal is in the running state. Upon startup, the target application sends a confirmation message containing the dynamic token to the server. After receiving confirmation information containing the dynamic token, the server queries the user information and payment credentials of the user terminal based on the dynamic token, and feeds back to the near-field communication device that sent the transaction query request containing the dynamic token, so that the near-field communication device can send the user information and payment credentials to the merchant device associated with the near-field communication device; the merchant device is used to execute the membership processing process based on the user information and send a payment request to the server based on the payment credentials. The payment voucher is used to represent the user account information of the user terminal; Obtain payment result information from the server; the payment result information is generated by the server based on the payment request sent by the merchant's device.

2. The method according to claim 1, wherein different member payment links contain the same fixed information and different dynamic tokens.

3. The method according to claim 1, wherein the user information includes a unique user identifier for the user in the target application; and the payment credential includes a payment code number for the user account of the user terminal.

4. The method according to claim 1, wherein the user of the user terminal is not a registered member of the merchant to which the merchant device belongs; The process of sending confirmation information containing the dynamic token to the server based on the launched target application specifically includes: Based on the launched target application, a member registration and payment page is displayed; Based on the user's confirmation action on the membership registration and payment page, a first confirmation message indicating agreement to register as a member and make payment is generated and sent to the server; the first confirmation message includes the dynamic token.

5. The method according to claim 1, wherein the user of the user terminal is a registered member of the merchant where the merchant device is located; The process of sending confirmation information containing the dynamic token to the server based on the launched target application specifically includes: Based on the launched target application, a member login and payment page is displayed; Based on the user's confirmation action on the member login and payment page, a second confirmation message indicating agreement to log in and make payment is generated and sent to the server. The second confirmation message includes the dynamic token.

6. The method according to claim 5, further comprising, before displaying the member login and payment page: Determine whether the user terminal has started the high-speed service processing function; the high-speed service processing function is a function that automatically processes the intermediate service pages of the target application without requiring the user to manually operate the intermediate service pages; The page displaying member login and payment specifically includes: If the user terminal has not activated the high-speed service processing function, the member login and payment page will be displayed.

7. The method according to claim 6, further comprising: If the user terminal has activated the high-speed service processing function, the target application will automatically generate third confirmation information containing the dynamic token.

8. A membership payment method applied to a near-field communication device, comprising: Acquire the near-field communication trigger signal sent by the user terminal; In response to the near-field communication trigger signal, a membership payment link is sent to the user terminal; The member payment link includes fixed information and a dynamic token; the user terminal is used to execute the method of claim 1 based on the member payment link.

9. The method according to claim 8, further comprising, before acquiring the near-field communication trigger signal sent by the user terminal: Obtain a member login command issued by a merchant device associated with the near-field communication device; Based on the member login instruction, the member payment link is determined.

10. The method according to claim 8, further comprising: Obtain the user information and payment voucher of the user terminal returned by the server; Send the user information and payment voucher to the merchant device associated with the near-field communication device.

11. The method according to claim 8, further comprising, after sending the membership payment link to the user terminal in response to the near-field communication trigger signal: Based on the dynamic token, a transaction information query request containing the dynamic token is sent to the server.

12. The method according to claim 9, wherein determining the member payment link based on the member login instruction specifically includes: Based on the member login instruction, a link information retrieval request is sent to the server; Obtain the member payment link returned by the server.

13. The method according to claim 12, wherein obtaining the member payment link returned by the server specifically includes: Obtain the dynamic token returned by the server; The dynamic token is combined with the fixed information stored locally on the near-field communication device to obtain the member payment link.

14. The method according to claim 9, wherein the near-field communication device locally stores a plurality of backup member payment links; the step of determining the member payment link based on the member login instruction specifically includes: Select one member payment link from several backup member payment links stored locally.

15. The method according to claim 14, further comprising, before acquiring the near-field communication trigger signal sent by the user terminal: Obtain the several backup member payment links sent by the server; The aforementioned backup member payment links are saved to the local storage space of the near-field communication device.

16. A membership payment device, applied to a user terminal, comprising: Trigger signal sending module, used to send near-field communication trigger signals; The link acquisition module is used to acquire a member payment link provided by a near-field communication device in response to the near-field communication trigger signal; the member payment link includes fixed information and a dynamic token; after sending the member payment link to the user terminal, the near-field communication device sends a transaction party information query request containing the dynamic token to the server; The member payment link is selected by the near-field communication device from multiple pre-stored backup member payment links, or the near-field communication device stores the fixed information locally, and after obtaining the dynamic token from the server, the near-field communication device concatenates the locally stored fixed information with the dynamic token to obtain the member payment link; the fixed information represents the same information contained in different member payment links; The application startup module is used to determine whether the target application in the user terminal is in a startup state based on the application identifier contained in the fixed information. The information sending module is used to send confirmation information containing the dynamic token to the server based on the launched target application; After receiving confirmation information containing the dynamic token, the server queries the user information and payment credentials of the user terminal based on the dynamic token, and feeds back to the near-field communication device that sent the transaction query request containing the dynamic token, so that the near-field communication device can send the user information and payment credentials to the merchant device associated with the near-field communication device; the merchant device is used to execute the membership processing process based on the user information and send a payment request to the server based on the payment credentials. The payment voucher is used to represent the user account information of the user terminal; The result acquisition module is used to acquire payment result information fed back by the server; the payment result information is generated by the server based on the payment request sent by the merchant's device.

17. A membership payment device, applied to a near-field communication device, comprising: The trigger signal acquisition module is used to acquire the near-field communication trigger signal sent by the user terminal; A link sending module is used to send a membership payment link to the user terminal in response to the near-field communication trigger signal; the membership payment link includes fixed information and a dynamic token; the user terminal is used to execute the method of claim 1 based on the membership payment link.

18. A membership 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 membership payment method according to any one of claims 1 to 15.

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

Images