CN114255028A - Service processing platform, terminal equipment and account binding method - Google Patents

Service processing platform, terminal equipment and account binding method Download PDF

Info

Publication number
CN114255028A
CN114255028A CN202011002509.1A CN202011002509A CN114255028A CN 114255028 A CN114255028 A CN 114255028A CN 202011002509 A CN202011002509 A CN 202011002509A CN 114255028 A CN114255028 A CN 114255028A
Authority
CN
China
Prior art keywords
account
binding
platform
user
terminal device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202011002509.1A
Other languages
Chinese (zh)
Inventor
刘振
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Advanced Nova Technology Singapore Holdings Ltd
Original Assignee
Alipay Labs Singapore Pte Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alipay Labs Singapore Pte Ltd filed Critical Alipay Labs Singapore Pte Ltd
Priority to CN202011002509.1A priority Critical patent/CN114255028A/en
Publication of CN114255028A publication Critical patent/CN114255028A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401Transaction verification
    • G06Q20/4014Identity check for transactions
    • G06Q20/40145Biometric identity checks

Abstract

The application provides a service processing platform and a method for binding an account executed by the service processing platform; the application also provides a terminal device and an account binding method executed by the terminal device. The service processing platform can be used as a second platform to execute the account binding method, and the first account of the first platform is bound with the second account of the second platform. The account binding method comprises the following steps: generating a binding activation code according to a binding request from a first terminal device associated with a user, wherein the binding request comprises first account information of the first account, and the binding request applies for the second platform to establish a binding relationship between the second account and the first account when the digital resource is used; sending the binding activation code to a second terminal device associated with the user; and binding the second account with the first account based on the binding activation code received from the first platform.

Description

Service processing platform, terminal equipment and account binding method
Technical Field
The present application relates to the field of information technologies, and in particular, to a service processing platform, a terminal device, and an account binding method.
Background
With the rise of electronic purses, more and more people prefer to use electronic purses for online and offline payments. The funding source for electronic wallets is typically an external banking channel. How to bind the electronic wallet and an external banking channel is an important issue in the electronic wallet use scenario.
In a scenario where a debit card (also called a deposit card) is bound to an electronic wallet (hereinafter, referred to as a bound debit card), a card set needs to confirm whether the binding operation subject is the debit card itself.
The user identity can be verified in three verification modes of short message verification, identity card information verification, living body face recognition and the like, so that the problem of user identity confirmation can be solved. Wherein the living human face identification needs the support of technical threshold and related public security organs. In some regions (e.g., overseas), the public security agency may not have the authority and/or ability to capture live facial features of a user. At this point, how the identity of the user is confirmed becomes a barrier to the binding of debit cards.
In addition, even if there is authority and ability to implement live face recognition, the privacy issue is another road barricade. In some regions (e.g., overseas), capturing faces is a privacy-destroying act. Therefore, the face is not popular with users. Therefore, if the binding process requires the collection of facial features of the user, the user may be reluctant to reveal privacy and terminate the binding operation.
Disclosure of Invention
In order to solve the technical problem, the application discloses an account binding method. The account binding method is used for binding a first account of a first platform with a second account of a second platform, wherein the first account is used for storing and providing a digital resource for the second account.
The account binding method comprises the following steps: generating a binding activation code according to a binding request from a first terminal device associated with a user, wherein the binding request comprises first account information of the first account, and the binding request applies for the second platform to establish a binding relationship between the second account and the first account when the digital resource is used; sending the binding activation code to a second terminal device associated with the user; and binding the second account with the first account based on the binding activation code received from the first platform.
In some embodiments, the method of account binding further comprises: receiving the binding request from the first terminal device; sending the first account information to the first platform, and requesting the first platform to acquire a payment mark for payment by using the first account; and receiving the payment token from the first platform.
In some embodiments, wherein said binding the second account with the first account based on the binding activation code received from the first platform comprises: receiving an activation code to be verified from the first platform; determining that the activation code to be verified matches the binding activation code and that the first account is not bound to the second account; and binding the second account with the first account.
In some embodiments, the account binding method further includes instructing the first terminal device and/or the second terminal device to load a prompt message, where the prompt message prompts the user to complete: a target payment comprising a transfer of a target amount of a digital resource from the first account to the second account; and using the binding activation code as an epilogue to the target payment.
In some embodiments, wherein the first account includes at least one of the following settings: the minimum limit of the number of the digital resources in the first account is a preset non-negative number, and the first account is associated with a third-party digital resource transmission channel.
In some embodiments, wherein the first terminal device and the second terminal device are the same.
In some embodiments, said sending said binding activation code to said second terminal device comprises: and sending the binding activation code to the second terminal equipment in a form of short message.
In some embodiments, wherein the first account information comprises: a first account identification of the first account; and identity information of the user.
In some embodiments, the identity information of the user comprises name information and identity card information of the user.
The application also discloses a service processing platform. The service processing platform can be used as a second platform, and the first account of the first platform is bound with the second account of the second platform. Specifically, the service processing platform includes: at least one memory storing at least one instruction set; and at least one processor in communication with the at least one memory, wherein when the server is running, the at least one processor reads and runs the at least one instruction set, and executes the account binding method according to the instruction of the at least one instruction set.
The application also discloses an account binding method, which is used for binding a first account of a first platform with a second account of a second platform, wherein the first account is used for storing and providing a digital resource for the second account.
The account binding method comprises the following steps: acquiring a binding request of a user through a first page loaded by terminal equipment, wherein the binding request applies for the second platform to establish a binding relationship between the second account and the first account when the digital resource is used; loading a binding activation code and prompt information, wherein the prompt information prompts the user to complete a target operation, the target operation comprises a target payment and the binding activation code is used as a postscript of the target payment, and the target payment comprises transferring a target amount of digital resources from the first account to the second account; and loading a second page in response to a signal that the user completed the target operation, wherein the second page prompts that the first account has been bound to the second account.
In some embodiments, the method of account binding further comprises sending the binding request to the second platform; and after receiving the binding request, the second platform generates the binding activation code and sends the binding activation code to the terminal equipment.
In some embodiments, after the second platform sends the binding activation code to the terminal device, the method further performs: receiving an activation code to be verified from the first platform; determining that the activation code to be verified matches the binding activation code and that the first account is not bound to the second account; and binding the second account with the first account.
In some embodiments, wherein the first account includes at least one of the following settings: the minimum limit of the number of the digital resources in the first account is a preset non-negative number, and the first account is associated with a third-party digital resource transmission channel.
In some embodiments, the binding activation code is loaded in the terminal device in a form of a short message.
In some embodiments, wherein the binding request includes first account information of the user, the first account information including: a first account identification of the first account; and identity information of the user.
In some embodiments, the identity information of the user comprises name information and identity card information of the user.
In some embodiments, after the second platform sends the binding activation code to the terminal device, the method further performs: sending the first account information to the first platform, and requesting the first platform to acquire a payment mark for payment by using the first account; and receiving the payment token from the first platform.
The application also discloses a terminal device, including: at least one memory storing at least one instruction set; and at least one processor which is connected with the at least one memory in a communication way, wherein when the terminal equipment runs, the at least one processor reads and runs the at least one instruction set, and executes the account binding method according to the instruction of the at least one instruction set.
In summary, the present application provides a service processing platform and a method for account binding executed by the service processing platform; the application also provides a terminal device and an account binding method executed by the terminal device.
According to the account binding method, the binding activation code is ingeniously utilized and serves as verification information, the binding activation code is generated by the second platform and is sent to a user, the user transmits the binding activation code to the first platform during transfer, and the first platform transmits the binding activation code to the second platform through transfer information. In this way, if the binding activation code finally received by the second platform is correct, the second platform may consider that the operation subject in the delivery flow of the binding activation code is correct, that is, the identity of the user performing the binding operation is correct. Therefore, the identity of the user can be verified without the need of information such as identity card information or fingerprint information or facial features of the user, and the problem to be solved by the application is solved.
According to the account binding method, when the user requests to bind, the second platform verifies the user identity by means of transfer operation, and direct extraction of identity information of the user is avoided. And in the verification process, the user needs to complete the transfer operation. During the transfer process of the user, if the first platform checks and extracts the identity of the user, at this time, the user can input the identity information of the user based on the trust of the first platform. Therefore, the transfer is skillfully utilized, and the operation of extracting the identity information is transferred to the first platform. Whereas, generally, the user has a higher level of trust with respect to a first platform having financial attributes, such as a bank. Therefore, the technical problems to be solved by the application are solved ingeniously.
The method for binding the digital resource account realizes the same-person authentication in an account sending mode, is different from a mode of performing the same-person authentication by living body face recognition, and has the advantages of low realization cost, high acceptance and guaranteed safety level.
Drawings
FIG. 1 is a schematic diagram illustrating a scenario of a method for account binding according to an embodiment of the present application;
fig. 2 is a schematic diagram illustrating a hardware structure of a first terminal device according to an embodiment of the present application;
FIG. 3 is a flow chart illustrating a method of account binding according to an embodiment of the present application;
FIG. 4 is a schematic diagram of a first page provided in accordance with an embodiment of the present application;
FIG. 5 is a diagram illustrating a second page provided by an embodiment of the present application; and
FIG. 6 is a flow chart illustrating another method of account binding provided in accordance with an embodiment of the present application.
Detailed Description
The following description is presented to enable any person skilled in the art to make and use the present disclosure, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present application. Thus, the present application is not limited to the embodiments shown, but is to be accorded the widest scope consistent with the claims.
The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting.
These and other features of the present application, as well as the operation and function of the related elements of structure and the combination of parts and economies of manufacture, may be significantly improved upon consideration of the following description. All of which form a part of this application, with reference to the accompanying drawings. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the application.
These and other features of the present application, as well as the operation and function of the related elements of the structure, and the economic efficiency of assembly and manufacture, are significantly improved by the following description. All of which form a part of this application with reference to the accompanying drawings. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the application.
Fig. 1 is a schematic diagram illustrating an application scenario of a method for account binding according to an embodiment of the present application. Specifically, the application scenario may include the network 400, the first terminal device 100, the second terminal device 500, the electronic wallet 200, and the bank 300.
Network 400 may facilitate the exchange of information and/or data. As shown in fig. 1, the first terminal device 100, the second terminal device 500, the electronic wallet 200, and the bank 300 may be connected to a network 400 and transmit information and/or data to each other through the network 400. For example, the electronic wallet 200 may receive a card binding request from the first terminal device 100 through the network 400, and may also request a deduction from the bank 300. For example, the electronic wallet 200 may transmit a short message to the first terminal device 100 of the user 10 through the network 400. The network 400 may be any type of wired or wireless network, as well as combinations thereof. For example, network 400 may include a cable network, a wireline network, a fiber optic network, a telecommunications network, an intranet, the internet, a Local Area Network (LAN), a Wide Area Network (WAN), a Wireless Local Area Network (WLAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), the Public Switched Telephone Network (PSTN), a bluetooth network, a ZigBee network, a Near Field Communication (NFC) network, or the like. In some embodiments, network 400 may include one or more network access points. For example, the network 400 may include wired or wireless network access points, such as base stations and/or internet exchange points, through which one or more components of the first terminal device 100, the second terminal device 500, the e-wallet 200, and the bank 300 may connect to the network 400 to exchange data and/or information.
The electronic wallet 200 may provide services to the user 10. By way of example, the service may include, but is not limited to, the electronic wallet 200 processing the electronic money of the user 10 according to the authorization of the user 10. In some embodiments, the electronic wallet 200 may provide payment services to the user 10. For example, the electronic wallet 200 may process electronic money of the user 10 according to the authorization of the user 10 when the user 10 consumes/purchases.
The user 10 may register in the electronic wallet 200. The user 10 may have his or her own e-wallet account open in the e-wallet 200. The electronic wallet 200 may manage the electronic wallet account of the user 10. In some embodiments, the user 10's e-wallet account may also have stored therein the user's 10 e-money. The user 10 may use electronic money within his e-wallet account for shopping/consumption.
In some embodiments, the electronic wallet 200 may include an electronic device loaded with server software. The electronic device may comprise a separate server. The electronic device may also include a server cluster. The server cluster may be a distributed server cluster. The distributed server cluster may include a plurality of distributively connected sub-servers. The plurality of sub-servers may communicate data and information with each other. For example, the plurality of sub-servers may be linked together via network 400. The plurality of sub-servers may share a common task, each of the plurality of sub-servers completes one or more of the tasks, and passes the results of the execution of the sub-tasks to other servers that need the sub-tasks. The electronic wallet 200 may provide services to the user 10 through the server software.
The bank 300 may provide services to the user 10. By way of example, the service may include, but is not limited to, the bank 300 processing the electronic money of the user 10 according to the authorization of the user 10. In some embodiments, the bank 300 may provide payment services to the user 10. For example, the bank 300 may process electronic money of the user 10 according to the authorization of the user 10 when the user 10 consumes/purchases.
The user 10 may register in the bank 300. The user 10 may have his or her own e-wallet account with the bank 300. The bank 300 can manage the electronic wallet account of the user 10. In some embodiments, the user 10's e-wallet account may also have stored therein the user's 10 e-money. The user 10 may use electronic money within his e-wallet account for shopping/consumption.
The first terminal device 100 may be an intelligent electronic device of the user 10. In some embodiments, the first terminal device 100 may include a mobile device, a tablet computer, a notebook computer, an in-built device of a motor vehicle, or the like, or any combination thereof. In some embodiments, the first terminal device 100 may include a smart phone, a Personal Digital Assistant (PDA), a gaming device, a navigation device, a point of sale (POS) device, or the like, or any combination thereof. In some embodiments, the smart electronic device may include, but is not limited to, a laptop computer, a tablet computer, a smart home device, a wearable device, a virtual reality device, an augmented reality device, and the like, or any combination thereof. In some embodiments, the smart home devices may include smart lighting devices, control devices for smart electrical devices, smart walkie-talkies, and the like, or any combination thereof. In some embodiments, the wearable device may include a smart bracelet, smart footwear, smart glasses, smart helmet, smart watch, smart garment, smart backpack, smart accessory, or the like, or any combination thereof. In some embodiments, the virtual reality device and/or the augmented reality device may include a virtual reality helmet, virtual reality glasses, a virtual reality patch, an augmented reality helmet, augmented reality glasses, an augmented reality patch, and the like, or any combination thereof. For example, the virtual reality device and/or augmented reality device may include google glasses, Oculus Rift, Hololens, Gear VR, and the like.
Fig. 2 shows a hardware structure diagram of a first terminal device 100 according to an embodiment of the present application.
The first terminal device 100 comprises at least one memory 230 and at least one processor 220. In some embodiments, the first terminal device 100 may further include a communication port 250 and an internal communication bus 210. Meanwhile, the first terminal device 100 may further include an I/O component 260.
Internal communication bus 210 may connect various system components including memory 230 and processor 220.
The I/O component 260 supports input/output between the first terminal device 100 and other components.
Memory 230 may include a data storage device. The data storage device may be a non-transitory storage medium or a transitory storage medium. For example, the data storage devices may include one or more of a disk 232, Read Only Memory (ROM)234, or Random Access Memory (RAM) 236. The memory 230 also includes at least one instruction set stored in the data storage device. The set of instructions is computer program code that may include programs, routines, objects, components, data structures, procedures, modules, and the like that perform the methods of account binding provided herein.
The communication port 250 is used for data communication between the first terminal device 100 and the outside. For example, the first terminal device 100 may be connected to the network 400 through the communication port 250 to receive instructions or messages from the first platform 300 and/or the second platform 200.
The at least one processor 220 communicates with the at least one memory 230 via an internal communication bus 210. The at least one processor 220 is configured to execute the at least one instruction set, and when the at least one processor 220 executes the at least one instruction set, the first terminal device 100 implements the account binding method provided herein. Processor 220 may perform some or all of the steps included in the binding method. Processor 220 may be in the form of one or more processors, and in some embodiments, processor 220 may include one or more hardware processors, such as microcontrollers, microprocessors, Reduced Instruction Set Computers (RISC), Application Specific Integrated Circuits (ASICs), application specific instruction set processors (ASIPs), Central Processing Units (CPUs), Graphics Processing Units (GPUs), Physical Processing Units (PPUs), microcontroller units, Digital Signal Processors (DSPs), Field Programmable Gate Arrays (FPGAs), Advanced RISC Machines (ARM), Programmable Logic Devices (PLDs), any circuit or processor capable of executing one or more functions, or the like, or any combination thereof. For illustrative purposes only, only one processor 220 is depicted in the first terminal device 100 in the present application. It should be noted, however, that the first terminal device 100 may also include multiple processors, and thus, the operations and/or method steps disclosed herein may be performed by one processor as described herein, or may be performed by a combination of multiple processors. For example, if in the present application the processor 220 of the first terminal device 100 performs steps a and B, it is to be understood that steps a and B may also be performed jointly or separately by two different processors 220 (e.g. a first processor performs step a, a second processor performs step B, or a first and a second processor performs steps a and B together).
The first terminal device 100 may comprise an electronic device carrying client software. The client software refers to software that deals with the user 10. The client software may interact with the user 10 as the front desk of the e-wallet 200. The server software can be considered to be the background of the e-wallet 200. Take an electronic wallet as an example: the e-wallet app/applet installed in the first terminal device 100 may be considered as the front desk of the e-wallet; the server software installed in the e-wallet server may be considered to be the back-office of the e-wallet. The client software may send the request of the user 10 received by the first terminal device 100 to the server software in the e-wallet 200 according to a communication protocol. The client software may be tools provided by server software, scripting languages (e.g., Perl), Web application development languages (e.g., ASP, ColdFusion, JSP, and PHP), programming languages (e.g., C, C + +, Java), and the like. As an example, the client software may be an electronic wallet applet or an electronic wallet app installed on the first terminal device 100 of the user 10. The client software can provide the user 10 with the ability to interact with the outside world, as well as an interface, over the network 400. In some embodiments, the client software may present a human-machine interface to the user 10. The human-computer interaction interface may be a web page. The human-computer interaction interface may be displayed on a display device of the first terminal device 100. As an example, the display device may be a display screen of the first terminal device 100. Taking the client software as an electronic wallet app as an example, the human-machine interaction interface may include, but is not limited to, a login page, a setup page, a bind successful page, a query page, and so on.
The structure and function of the second terminal device 500 are the same as or similar to those of the first terminal device 100. For brevity, the structure and functions of the second terminal device 500 will not be described in detail.
According to the foregoing description, the user 10 can interact with the front desk of the electronic wallet 200 installed in the first terminal device 100. For example, the user 10 may interact with an electronic wallet app installed in the first terminal device 100, requesting from the background of the electronic wallet 200 to bind his savings card account at the bank 300 to his electronic wallet account.
For example, the user 10 may request from the electronic wallet back office to bind his savings card account to his electronic wallet account through a setup page in an electronic wallet app installed in the first terminal device 100. In this way, when a user uses his e-wallet account for consumption, payment can be made for consumption directly using the money in the savings card account bound to the e-wallet account.
Upon receiving the user's binding request, the wallet back office needs to authenticate the identity of the user 10 to confirm that the subject sending the binding request is the user at the time the wallet account was registered. As an example, the electronic wallet platform may send an instruction to the first terminal device 100. The first terminal device 100 may load out the verification page according to the instruction. The user 10 may enter authentication information through the authentication page. By way of example, the authentication information may include, but is not limited to, a payment password for the electronic wallet, an authentication code received by a reserved phone number or mailbox at the time of registration of the electronic wallet, a biometric characteristic of the user 10, and the like. The first terminal device 100 may acquire the verification information and send the verification information to the electronic wallet back office. The electronic wallet background can verify the identity of the user requesting binding according to the verification information.
In some embodiments, the user 10 does not want too much of his identity information to be revealed to the electronic wallet 200. For example, when the first terminal device 100 loads an identity verification page, the user is prompted to input the identity card information, the fingerprint information, the facial features, and the like through the page, and the user does not want to disclose the identity card information, the fingerprint information, the facial features, and the like to the electronic wallet 200. If the identity information of the user cannot be acquired, the identity of the user currently performing the binding operation cannot be verified, and further, the security of the binding operation is affected.
The application provides an account binding method. The account binding method can verify the identity of the user without forcing the requirement on the identity card information or fingerprint information or facial feature information of the user, and further can bind the bank card account of the user to the electronic wallet account of the user, so that the technical problem required to be solved by the method is solved.
The account binding method can be used for binding a first account opened by the user 10 in the first platform with a second account opened by the user 10 in the second platform.
The first platform may contain financial attributes. In some embodiments, the first platform may be a financial platform. By way of example, the financial platform may include, but is not limited to, a bank, a payment platform, a third party payment platform, an e-wallet platform, and the like. For example, the first platform may include the bank 300 described above. In some embodiments, the first platform may also be other platforms that include financial attributes, such as, but not limited to, social, entertainment, video, nursery platforms that include electronic wallet functionality, and the like.
The user 10 may have an account with the first platform. For the sake of distinction, the "first account" is taken to mean the account opened by the user 10 in the first platform.
The first account may have stored therein the digital assets of the user 10. By way of example, the digital resource may include electronic currency. The electronic money may include, but is not limited to, electronic cash, electronic change, secure change, electronic credit card, online money, digital money, and the like.
In some embodiments, the minimum limit on the number of digital assets in the first account may be a preset non-negative number. For example, the first account may be a debit account that the user 10 opened at the bank 300 without overdraft functionality.
In some embodiments, the first account may be associated with a third party payment system. For example, the first account may be an account opened by the user 10 in a third party payment system. As an example, the first account may be a debit or credit card account opened by the user 10 at the third party payment system.
The first platform can manage the first account according to the first account information of the first account. In some embodiments, the first account information may include a first account identification of the first account. As an example, the first account identification may be an account number of the first account. The account number may be a character string that the first platform assigns to the first account for uniquely identifying the first account. In some embodiments, the first account information may include identity information of the user 10. The identity information may be used to identify the identity of the user 10. By way of example, the identity information may include, but is not limited to, identification card information, name information, phone number information, mailbox information, household information, biometric information, and the like of the user 10. In the case of a bank savings card, the account information of the savings card account of user 10 may include the account number of the savings card account of user 10 and the identity information of user 10.
The second platform may be a service processing platform. The second platform may provide services to a user. By way of example, the services may include, but are not limited to, social services, communication services, entertainment services, payment services, taxi service, take-away services, and the like.
The user 10 may register in the second platform. The user 10 may set up his own account in the second platform. For the sake of distinction, the "second account" denotes an account opened by the user 10 in the second platform. The second platform may manage a second account for user 10. For example, the second platform may provide services to the user through the second account.
In some embodiments, the second account of the user 10 may also have stored therein the digital resources of the user 10. The user 10 may make purchases/consumptions using the digital resources in his second account. For example, the second platform may include the electronic wallet 200 as described above, and the user may have an electronic wallet account opened in the electronic wallet 200, through which the electronic wallet 200 may provide storage and/or financial and/or payment services for the user.
In some embodiments, the second platform may comprise an electronic device loaded with server software. The electronic device may comprise a separate server. The electronic device may also include a server cluster. The server cluster may be a distributed server cluster. The distributed server cluster may include a plurality of distributively connected sub-servers. The plurality of sub-servers may communicate data and information with each other. For example, the plurality of sub-servers may be linked together via network 400. The plurality of sub-servers may share a common task, each of the plurality of sub-servers completes one or more of the tasks, and passes the results of the execution of the sub-tasks to other servers that need the sub-tasks. The second platform may provide services to the user 10 through the server software. Taking e-wallet platform 200 as an example, the second platform may comprise a computer device loaded with e-wallet server software.
The hardware structures of the first platform and the second platform may be the same as or similar to the hardware structure of the first terminal device 100 shown in fig. 2, and are not repeated here for brevity.
As can be seen from the foregoing description, a first account opened by a user on the first platform may store digital resources of the user, and a second account opened by the user on the second platform may provide services to the user.
In some embodiments, the first account may provide the digital resource to the second account based on authorization of a user. For example, a bank may transfer money in a user's savings card account to the user's e-wallet account upon authorization by the user. For another example, when the user pays for a ride of a car by using an account registered in certain taxi-calling software, the taxi-calling software can directly deduct money from a savings card account bound by the user according to the authorization of the user. The user's savings card account may provide electronic money to his taxi account.
As an example, fig. 3 shows a flowchart of a method S100 for account binding according to an embodiment of the present application. FIG. 3 shows a process for binding an account from the processing of the second platform. The process S100 may be stored as at least one instruction set in a non-transitory storage medium in the second platform for account binding. At least one processor of the second platform is communicatively coupled to the at least one non-transitory storage medium, wherein when the second platform is running, the at least one processor reads the at least one instruction set and performs the steps of flow S100 as indicated by the at least one instruction set.
The illustrated operations of the flow S100 presented below are intended to be illustrative and not limiting. In some embodiments, the process S100 may be implemented with one or more additional operations not described, and/or with one or more operations described herein. Further, the order of the operations shown in FIG. 3 and described below is not intended to be limiting.
For ease of understanding, in the following description of the present application, the functions of the first platform described in the present application are described by taking the bank 300 as an example, and the functions of the second platform described in the present application are described by taking the electronic wallet 200 as an example.
As can be seen from the foregoing description, the first terminal device 100 may have installed therein the foreground, i.e., client software, of the second platform.
In some embodiments, when the user 10 logs in the foreground of the second platform in the terminal device 100, the terminal device 100 may obtain the second account information of the second account of the user 10. In some embodiments, the second account information may include a second account identification of a second account of the user 10. As an example, the second account identification may be an account number of the second account. The account number may be a character string that the second platform assigns to the second account number for uniquely identifying the second account. In some embodiments, the second account information may include identity information of the user 10. The identity information may be used to identify the identity of the user 10. By way of example, the identity information may include, but is not limited to, identification card information, name information, phone number information, mailbox information, household information, biometric information, and the like of the user 10.
Taking the electronic wallet system as an example, the user 10 logs in an electronic wallet app in the terminal device 100, and the terminal device 100 can acquire account information of an electronic wallet account opened in the electronic wallet system by the user 10. The account information of the electronic wallet account of the user 10 may include an account number of the electronic wallet account of the user 10 and identity information of the user 10.
In some embodiments, after acquiring the second account information of the user 10 on the second platform, the terminal device 100 may request authentication of the second account information from the second platform.
The second platform may authenticate the second account information.
When the second account information passes the authentication of the second platform, the second platform can confirm that the identity of the user who logs in the second account or performs related operation on the second account currently has no problem.
After the second account information is authenticated, the second platform may send a message that the authentication is passed to the first terminal device 100, and then the first terminal device 100 may perform a related operation on the second account.
As an example, the user 10 may request from the second platform through the first terminal device 100 to bind a first account opened by the user 10 on the first platform to a second account thereof.
S110, the second platform receives the binding request from the first terminal device 100.
The binding request requests the second platform to establish a binding relationship between the second account and the first account when the digital resource is used.
In some examples, the user may submit the binding request to the foreground of the second platform in the first terminal device 100 through the first page loaded by the first terminal device 100. The first terminal device 100 may acquire the binding request of the user 10 through the first page loaded by the first terminal device.
As an example, fig. 4 shows a schematic diagram of a first page 610 provided according to an embodiment of the present application.
The first page 610 may include identity information 611 of the user 10. Identity information of the user 10 may be displayed directly on the first page 610. Identity information of user 10 may also be embedded in the page content identifier of first page 610.
The first page 610 may further include: the user 10 is prompted to enter prompting information 612 for the first account identification of the first account. By way of example, the prompt may include an input box displayed on the first page 610.
The user 10 may enter the first account identification through the first page 610.
The first terminal device 100 may obtain the first account identification.
After obtaining the first account identifier, the first terminal device 100 may send the first account identifier and the identity information to the second platform, and request the second platform to bind the first account with the second account.
Taking a debit card as an example, the first account identification may include a card number of the debit card. With continued reference to fig. 4, the user 10 may enter the card number of his debit card through an entry box of the prompt message 612 in the first page 610.
After the user 10 inputs the card number through the first page 610, the first terminal device 100 may obtain the card number of the bank card input by the user 10. The first terminal device 100 may send a binding request to the second platform to request the second platform to bind the bank card to the user's e-wallet account. The binding request may include first account information of the user. The first account information may include identity information of a user and the first account identification.
S120, the second platform sends the first account information to the first platform, and requests the first platform to acquire a payment mark for payment by using the first account.
S130, the second platform receives the payment mark from the first platform.
In order to protect the information security of a user and ensure that privacy information such as a bank card and the like is not leaked, a central bank issues a notice to all payment mechanisms, and requires that when the user uses a virtual account and quick payment to carry out transaction payment, the payment mechanisms cannot use real-name information of the user or the bank card is transmitted in a network, each virtual account and the quick binding card must be marked, and then the actual identity information of the user is analyzed through the mark, so that the user information is prevented from being stolen.
In some embodiments, the first platform may provide payment tokenization services. The payment tokenization means: the first platform may receive the tag request from the second platform, generate a tag, and return the tag to the second platform. As an example, the payment token may include a token. For convenience of description, in the following description of the present application, the function of the payment token is described by taking token as an example.
Taking a bank card as an example, after receiving the binding request, the electronic wallet 200 may send the bank card information to the bank 300, and request the bank 300 to obtain the token. The bank 300 may authenticate the identity information of the user, generate the token and send the token to the electronic wallet 200 if the authentication is passed.
To improve security, the second platform (e.g., the e-wallet platform 200) needs to authenticate the first account information, and the following steps illustrate a method of authenticating the first account information in an incoming manner. The method comprises the following specific steps:
s140, the second platform generates a binding activation code according to the binding request from the first terminal device 100 associated with the user.
S150, the second platform sends the binding activation code to the second terminal device 500 associated with the user.
The second terminal device 500 is associated with the user. For example, the second terminal device 500 may be a device where a mobile phone number of a current user is located. For another example, the second terminal device 500 may be a device in which a mailbox account currently logged in and used by the user is located.
As can be seen from the foregoing description, the user 10 initiates a binding request via the first terminal device 100.
The second terminal device 500 and the first terminal device 100 may be identical. For example, the first terminal device 100 may be a mobile phone installed with an electronic wallet app, and the user initiates a binding request through the electronic wallet app in the mobile phone. The second terminal device 500 may be a handset that the user initiates a binding request.
The second terminal device 500 may also be different from the first terminal device 100. For example, the user submits a binding request through a web page in his computer, and the first terminal device 100 is the computer. After receiving the binding request and generating the binding activation code, the electronic wallet back-end may send the binding activation code to the mobile phone where the mobile phone number is located when the user registers, and at this time, the second terminal device 500 is the mobile phone of the user.
By way of example, the binding activation code may include, but is not limited to, a character or string of characters, numbers, words, and the like.
In some embodiments, the binding activation code may be limited to being valid for a particular time or number of times. For example, the binding activation code may be restricted to be valid only this time. For example, the binding activation code may be defined to be valid for 2 hours. In this way, the security of the binding process can be improved by limiting the valid time or number of times of the binding activation code.
In some embodiments, the second platform may send the binding activation code to the second terminal device 500 in a form of a short message. Generally, the mobile phone number of the user is bound with the real-name identity of the user, so that the security of the binding activation code transmission can be ensured by sending the binding activation code by a short message method.
Of course, the second platform may also send the binding activation code to the second terminal device 500 in other forms. By way of example, the form in which the second platform sends the binding activation code may also include, but is not limited to, email, network credit, voice message, page banner, and the like.
S160, the second platform instructs the first terminal device 100 and/or the second terminal device 500 to load the prompt message.
Wherein the prompt information prompts the user to complete: a target payment comprising a transfer of a target amount of a digital resource from the first account to the second account; and using the binding activation code as an epilogue to the target payment.
According to the foregoing description, the second platform sends the binding activation code to the second terminal device 500.
In some embodiments, the second platform may instruct the second terminal device 500 to load the reminder information. In some embodiments, the prompt may be sent to the second terminal device 500 together with the binding activation code and loaded by the second terminal device 500. For example, the prompt message may be sent by the second platform to the second terminal device 500 in the form of a short message together with the binding activation code.
In some embodiments, the second platform may instruct the first terminal device 100 to load the reminder information. For example, when the user applies for binding through the first terminal device 100, the second platform may instruct the first terminal device 100 to load the prompt message in the form of a page banner to prompt the user to complete the target payment and use the binding activation code as an epilogue of the target payment. And the user is prompted to perform target operation in a page banner mode, so that the method is more intuitive for the user.
As an example, the prompt message may include a short message. Of course, the prompting message may also include other forms without departing from the core spirit of the present application. For example, the reminder information may also include, but is not limited to, mail, network mail, voice message, page banner, and the like.
The prompt information prompts the user to execute: transferring a target amount of a digital resource from the first account to a second account.
The prompt message also prompts the user to perform: writing the binding activation code to the epiword upon transfer of the target amount of the digital resource from the first account to the second account.
In some embodiments, the target amount may be a preset amount or a preset range of amounts. Setting the digital resource to a target amount can further improve the security of binding.
In some embodiments, the target amount may also be sized according to the first platform's associated requirements for the user's transfer amount. For example, when the single transfer amount is greater than 1000 dollars, the first platform defines that the user must enter a payment password. Then the target amount may be set to be greater than 1000 dollars.
Taking the electronic wallet system as an example, after receiving a binding request from an electronic wallet app in the first terminal device 100, the electronic wallet back-end may generate a binding card sheet according to the bank card information in the binding request, and the electronic wallet back-end generates a binding card activation code. The e-wallet back office requests the short message service provider or the short message service provider to send a prompt message to the first terminal device 100 of the user 10. The prompting message may prompt the user 10 to transfer a charge to the user's 10 e-wallet account using the bank card that needs to be bound. As an example, the amount of the transfer may be a preset amount (1000 yuan) or a preset range of amount (not less than 500 yuan). The hint information may also include the binding activation code. The prompt message may also prompt the user to write the binding activation code to an epilogue of the transfer.
Thus, if the user transfer is successful and the appendix is correct, the identity of the user currently operating the binding can be confirmed to be authenticated. Therefore, the identity authentication of the user can be skillfully realized in an account coming mode, and the biological characteristics of the user do not need to be collected under the condition of finishing the authentication.
S170, the second platform receives the activation code to be verified from the first platform.
In accordance with the foregoing, the second platform sends a prompt and a binding activation code to the user.
The user 10 may apply to the first platform to transfer the target amount of the digital resource from the first account to the second account and write the to-be-verified activation code in the epilogue.
The first platform can perform transfer operation according to the request of the user and takes the activation code to be verified written by the user as the additional language information.
After the transfer is successful, the first platform may send a message that the transfer was successful to the second platform. A second account of the second platform may receive the incoming account message.
The charge-up message may acknowledge as a confirmation signal that the second account received the target amount of digital resources from the first account.
The preamble of the incoming account message may include the to-be-verified activation code.
The second platform may authenticate the first account information according to the charge message.
S180, the second platform determines that the activation code to be verified is matched with the binding activation code, and the first account is not bound with the second account.
S190, the second platform binds the second account with the first account.
Taking an electronic wallet as an example, a wallet background receives a user account, the wallet traverses a request card binding sheet of the user later to carry out matching card binding, and the matching elements are as follows: card number of the coming account and the appendix of the coming account. And if the matching elements are correct (namely the incoming account number and the activation code to be verified in the incoming account statement are correct), confirming that the first account information is authenticated, activating the binding sheet by the wallet background, and binding the bank card to the account of the electronic wallet.
In summary, the second platform binds the second account with the first account based on the binding activation code received from the first platform.
In response to the signal that the user completes the target operation, the first terminal device 100 may further load a second page, where the second page prompts that the first account and the second account have been bound.
As an example, fig. 5 shows a schematic diagram of a second page 620 provided according to an embodiment of the present application. The second page 620 shows that the bank card of the user 10 has been bound to his e-wallet account.
After binding the bank card to the electronic wallet account, when the user needs to consume, the electronic wallet 200 may send an withholding token, identity information, a payment password, etc. to the bank 300 to request for withholding.
According to the account binding method, the binding activation code is ingeniously utilized and serves as verification information, the binding activation code is generated by the second platform and is sent to a user, the user transmits the binding activation code to the first platform during transfer, and the first platform transmits the binding activation code to the second platform through transfer information. In this way, if the binding activation code finally received by the second platform is correct, the second platform may consider that the operation subject in the delivery flow of the binding activation code is correct, that is, the identity of the user performing the binding operation is correct. Therefore, the identity of the user can be verified without the need of information such as identity card information or fingerprint information or facial features of the user, and the problem to be solved by the application is solved.
According to the account binding method, when the user requests to bind, the second platform verifies the user identity by means of transfer operation, and direct extraction of identity information of the user is avoided. And in the verification process, the user needs to complete the transfer operation. During the transfer process of the user, if the first platform checks and extracts the identity of the user, at this time, the user can input the identity information of the user based on the trust of the first platform. Therefore, the transfer is skillfully utilized, and the operation of extracting the identity information is transferred to the first platform. Whereas, generally, the user has a higher level of trust with respect to a first platform having financial attributes, such as a bank. Therefore, the technical problems to be solved by the application are solved ingeniously.
According to the account binding method, the bank card of the user is bound to the electronic wallet account in an account coming mode, the problem that the user is bound with the same person is solved, and a living body face recognition scheme can be replaced. The card binding authentication is realized in the mode of account sending, the realization cost is low, the acceptance degree is high, only the user can operate the debit card to transfer accounts, and the safety level is guaranteed. Assuming that the cardholder A successfully registers the wallet account C and takes the certificate information and the debit card information of the subscriber B to bind, the subscriber A needs to make a payment for the wallet account C by the subscriber B, and the payment epilogue must be the activation code of the subscriber B.
Correspondingly, the application also provides a service processing platform. The service processing platform may be the second platform described above. The structure and function of the second platform are described above and will not be described herein.
Correspondingly, the application also provides a terminal device and an account binding method executed by the terminal device. As an example, the terminal device may be the first terminal device 100 described above. As an example, fig. 6 shows a flowchart of a method S200 of account binding performed by the terminal device according to some embodiments of the present application. Specifically, the method S200 may include:
s210, a binding request of a user is obtained through a first page loaded by a terminal device, and the binding request applies for the second platform to establish a binding relationship between the second account and the first account when the digital resource is used.
S220, loading a binding activation code and prompt information, wherein the prompt information prompts the user to finish target operation, the target operation comprises target payment and the binding activation code is used as an epilogue of the target payment, and the target payment comprises transferring digital resources of a target amount from the first account to the second account.
S230, responding to a signal that the user completes the target operation, and loading a second page, wherein the second page prompts that the first account and the second account are bound.
The method S200 for account binding may be stored as at least one instruction set in a non-transitory storage medium in the terminal device, and is used for account binding. At least one processor in the terminal device is in communication connection with the at least one non-transitory storage medium, wherein when the terminal device is running, the at least one processor reads the at least one instruction set and executes the above account binding method S200 according to the instruction of the at least one instruction set. The process of the specific account binding method has been described above, and is not described herein again.
In summary, the present application provides a service processing platform and a method for account binding performed by the service platform; the application also provides a terminal device and an account binding method executed by the terminal device. The account binding method achieves the same-person authentication in an account sending mode, is different from a mode of performing the same-person authentication by living body face recognition, and is low in cost, high in acceptance and guaranteed in safety level.
In conclusion, upon reading the present detailed disclosure, those skilled in the art will appreciate that the foregoing detailed disclosure can be presented by way of example only, and not limitation. Those skilled in the art will appreciate that the present application is intended to cover various reasonable variations, adaptations, and modifications of the embodiments described herein, although not explicitly described herein. Such alterations, improvements, and modifications are intended to be suggested by this application and are within the spirit and scope of the exemplary embodiments of the application.
Furthermore, certain terminology has been used in this application to describe embodiments of the application. For example, "one embodiment," "an embodiment," and/or "some embodiments" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the application. Therefore, it is emphasized and should be appreciated that two or more references to "an embodiment" or "one embodiment" or "an alternative embodiment" in various portions of this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined as suitable in one or more embodiments of the application.
It should be appreciated that in the foregoing description of embodiments of the present application, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure aiding in the understanding of such feature. Alternatively, various features may be dispersed throughout several embodiments of the application. This is not to be taken as an admission that any of the features of the claims are essential, and it is fully possible for a person skilled in the art to extract some of them as separate embodiments when reading the present application. That is, embodiments in the present application may also be understood as an integration of multiple sub-embodiments. And each sub-embodiment described herein is equally applicable to less than all features of a single foregoing disclosed embodiment.
In some embodiments, numbers expressing quantities or properties useful for describing and claiming certain embodiments of the present application are to be understood as being modified in certain instances by the terms "about", "approximately" or "substantially". For example, "about", "approximately" or "substantially" may mean a ± 20% variation of the value it describes, unless otherwise specified. Accordingly, in some embodiments, the numerical parameters set forth in the written description and attached claims are approximations that may vary depending upon the desired properties sought to be obtained by a particular embodiment. In some embodiments, numerical parameters should be construed in light of the number of reported significant digits and by applying ordinary rounding techniques. Notwithstanding that the numerical ranges and parameters setting forth the broad scope of the embodiments of the application are approximations, the numerical values set forth in the specific examples are reported as precisely as possible.
Each patent, patent application, publication of a patent application, and other material, such as articles, books, descriptions, publications, documents, articles, and the like, cited herein is hereby incorporated by reference. All matters hithertofore set forth herein except as related to any prosecution history, may be inconsistent or conflicting with this document or any prosecution history which may have a limiting effect on the broadest scope of the claims. Now or later associated with this document. For example, if there is any inconsistency or conflict in the description, definition, and/or use of terms associated with any of the included materials with respect to the terms, descriptions, definitions, and/or uses associated with this document, the terms in this document are used.
Finally, it should be understood that the embodiments of the application disclosed herein are illustrative of the principles of the embodiments of the present application. Other modified embodiments are also within the scope of the present application. Accordingly, the disclosed embodiments are presented by way of example only, and not limitation. Those skilled in the art may implement the present application in alternative configurations according to the embodiments of the present application. Thus, embodiments of the present application are not limited to those embodiments described with precision in the application.

Claims (19)

1. A method of account binding for binding a first account of a first platform with a second account of a second platform, the first account for storing and providing a digital resource to the second account, the method of account binding comprising:
generating a binding activation code according to a binding request from a first terminal device associated with a user, wherein the binding request comprises first account information of the first account, and the binding request applies for the second platform to establish a binding relationship between the second account and the first account when the digital resource is used;
sending the binding activation code to a second terminal device associated with the user; and
binding the second account with the first account based on the binding activation code received from the first platform.
2. The method of account binding of claim 1, further comprising:
receiving the binding request from the first terminal device;
sending the first account information to the first platform, and requesting the first platform to acquire a payment mark for payment by using the first account; and
receiving the payment token from the first platform.
3. The account binding method of claim 1, wherein the binding the second account with the first account based on the binding activation code received from the first platform comprises:
receiving an activation code to be verified from the first platform;
determining that the activation code to be verified matches the binding activation code and that the first account is not bound to the second account; and
binding the second account with the first account.
4. The account binding method of claim 3, further comprising instructing the first terminal device and/or the second terminal device to load a prompt, wherein the prompt prompts the user to complete:
a target payment comprising a transfer of a target amount of a digital resource from the first account to the second account; and
and taking the binding activation code as an epilogue of the target payment.
5. The method of account binding of claim 1, wherein the first account includes at least one setting of:
the minimum limit of the number of the digital resources in the first account is a preset non-negative number, an
The first account is associated with a third party digital resource transmission channel.
6. The method of account binding of claim 1, wherein the first terminal device and the second terminal device are the same.
7. The account binding method of claim 1, wherein the sending the binding activation code to the second terminal device comprises:
and sending the binding activation code to the second terminal equipment in a form of short message.
8. The method of account binding of claim 1, wherein the first account information comprises:
a first account identification of the first account; and
identity information of the user.
9. The account binding method of claim 8, wherein the identity information of the user comprises name information and identification card information of the user.
10. A business processing platform comprising:
at least one memory storing at least one instruction set; and
at least one processor communicatively coupled to the at least one memory, wherein when the server is running, the at least one processor reads and executes the at least one instruction set and performs the method of account binding according to any of claims 1 to 9 as indicated by the at least one instruction set.
11. A method of account binding for binding a first account of a first platform with a second account of a second platform, the first account for storing and providing a digital resource to the second account, comprising:
acquiring a binding request of a user through a first page loaded by terminal equipment, wherein the binding request applies for the second platform to establish a binding relationship between the second account and the first account when the digital resource is used;
loading a binding activation code and prompt information, wherein the prompt information prompts the user to complete a target operation, the target operation comprises a target payment and the binding activation code is used as a postscript of the target payment, and the target payment comprises transferring a target amount of digital resources from the first account to the second account; and
loading a second page in response to a signal that the user completed the target operation, wherein the second page prompts that the first account has been bound to the second account.
12. The method of account binding of claim 11, further comprising sending the binding request to the second platform;
and after receiving the binding request, the second platform generates the binding activation code and sends the binding activation code to the terminal equipment.
13. The account binding method of claim 12, wherein after the second platform sends the binding activation code to the terminal device, further performing:
receiving an activation code to be verified from the first platform;
determining that the activation code to be verified matches the binding activation code and that the first account is not bound to the second account; and
binding the second account with the first account.
14. The method of account binding of claim 11, wherein the first account includes at least one setting of:
the minimum limit of the number of the digital resources in the first account is a preset non-negative number, an
The first account is associated with a third party digital resource transmission channel.
15. The account binding method of claim 11, wherein the binding activation code is loaded in the terminal device in the form of a short message.
16. The method of account binding of claim 11, wherein the binding request includes first account information of the user, the first account information including:
a first account identification of the first account; and
identity information of the user.
17. The account binding method of claim 16, wherein the identity information of the user comprises name information and identification card information of the user.
18. The account binding method of claim 16, wherein after the second platform sends the binding activation code to the terminal device, further performing:
sending the first account information to the first platform, and requesting the first platform to acquire a payment mark for payment by using the first account; and
receiving the payment token from the first platform.
19. A terminal device, comprising:
at least one memory storing at least one instruction set; and
at least one processor communicatively coupled to the at least one memory, wherein when the terminal device is operating, the at least one processor reads and executes the at least one instruction set, and performs the account binding method according to any one of claims 11 to 18 according to an indication of the at least one instruction set.
CN202011002509.1A 2020-09-22 2020-09-22 Service processing platform, terminal equipment and account binding method Pending CN114255028A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011002509.1A CN114255028A (en) 2020-09-22 2020-09-22 Service processing platform, terminal equipment and account binding method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011002509.1A CN114255028A (en) 2020-09-22 2020-09-22 Service processing platform, terminal equipment and account binding method

Publications (1)

Publication Number Publication Date
CN114255028A true CN114255028A (en) 2022-03-29

Family

ID=80789557

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011002509.1A Pending CN114255028A (en) 2020-09-22 2020-09-22 Service processing platform, terminal equipment and account binding method

Country Status (1)

Country Link
CN (1) CN114255028A (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115098840A (en) * 2022-06-24 2022-09-23 北京字跳网络技术有限公司 Identity authentication method, device, equipment, medium and product
CN115564438A (en) * 2022-12-06 2023-01-03 北京百度网讯科技有限公司 Block chain-based digital resource processing method, device, equipment and storage medium

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115098840A (en) * 2022-06-24 2022-09-23 北京字跳网络技术有限公司 Identity authentication method, device, equipment, medium and product
CN115564438A (en) * 2022-12-06 2023-01-03 北京百度网讯科技有限公司 Block chain-based digital resource processing method, device, equipment and storage medium
CN115564438B (en) * 2022-12-06 2023-03-24 北京百度网讯科技有限公司 Block chain-based digital resource processing method, device, equipment and storage medium

Similar Documents

Publication Publication Date Title
US20200387894A1 (en) Apparatus and methods for payment transactions using near field communication
JP6811787B2 (en) Electronic payment system and how
US20190057390A1 (en) Biometric system for authenticating a biometric request
CN107733973A (en) Method of controlling security, terminal, server and computer-readable medium
WO2021259144A1 (en) Terminal device, service processing system, and digital resource transmission methods
CA3030698A1 (en) Electronic payment processing method and system with smart/authenticate fields and definitions
CN112669042A (en) Payment method, server, user terminal, system and storage medium
US11907352B2 (en) Biometric override for incorrect failed authorization
CN114255028A (en) Service processing platform, terminal equipment and account binding method
CN110084586B (en) Mobile terminal secure payment system and method
US20170169424A1 (en) Delegation of transactions
WO2014051586A1 (en) Mobile payment service for small financial institutions
CN108369619A (en) For the user authentication of transaction
CN108351990A (en) Method and system for distributing physical currency
TW201804389A (en) Password resetting system for electronic transaction and method thereof using a third party platform server and a rigorous verification process to increase the security of password resetting for preventing the virtual card from malicious use
CN108475374B (en) Payment device with multiple modes for conducting financial transactions
EP4020360A1 (en) Secure contactless credential exchange
US20180349885A1 (en) Mobile device, method, computer program product and issuance system for configuring ticket co-branded credit card based on tokenization technology
JP7177303B1 (en) Service providing system, service providing method, and program
CN111355722B (en) Method, system and non-transitory storage medium for associating biological characteristics with virtual resources
CN107977841A (en) The method and its terminal of two-dimension code safe payment are realized based on driving layer
US11244297B1 (en) Systems and methods for near-field communication token activation
US20210133756A1 (en) Extended payment instrument
WO2019009802A1 (en) A system for applying for a visa for temporary entry into a country or territory on a computer device
EP3340140A1 (en) System and method for financial instrument applications

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right
TA01 Transfer of patent application right

Effective date of registration: 20240226

Address after: No. 128 Haibin Road, Singapore 20-01 Guoke Zhongcheng Office 189773

Applicant after: Advanced Nova Technology (Singapore) Holdings Ltd.

Country or region after: Singapore

Address before: 45-01 Anson Building, 8 Shanton Avenue, Singapore

Applicant before: Alipay laboratories (Singapore) Ltd.

Country or region before: Singapore