WO2019105296A1 - 绑卡方法及终端 - Google Patents

绑卡方法及终端 Download PDF

Info

Publication number
WO2019105296A1
WO2019105296A1 PCT/CN2018/117178 CN2018117178W WO2019105296A1 WO 2019105296 A1 WO2019105296 A1 WO 2019105296A1 CN 2018117178 W CN2018117178 W CN 2018117178W WO 2019105296 A1 WO2019105296 A1 WO 2019105296A1
Authority
WO
WIPO (PCT)
Prior art keywords
bank
card
server
terminal
bound
Prior art date
Application number
PCT/CN2018/117178
Other languages
English (en)
French (fr)
Inventor
丁建新
赵晓娜
常新苗
Original Assignee
华为技术有限公司
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
Priority claimed from CN201810016329.5A external-priority patent/CN109842605B/zh
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP23183519.0A priority Critical patent/EP4307198A3/en
Priority to US16/767,879 priority patent/US20200372490A1/en
Priority to EP18882735.6A priority patent/EP3693911B1/en
Publication of WO2019105296A1 publication Critical patent/WO2019105296A1/zh
Priority to US18/623,603 priority patent/US20240249273A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/354—Card activation or deactivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3221—Access to banking information through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G06Q20/3263—Payment applications installed on the mobile devices characterised by activation or deactivation of payment capabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/351—Virtual cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/352—Contactless payments by cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363—Payment 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3672—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes initialising or reloading thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, 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/401—Transaction verification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations

Definitions

  • the present application relates to the field of mobile payment technologies, and in particular, to a card binding method and a terminal.
  • the common mobile payment APP includes e-wallet applications launched by various mobile phone manufacturers, such as Huawei wallet, Apple PAY, mobile banking clients launched by financial institutions such as banks, and third-party payment service providers. WeChat payment, Alipay and other third-party payment applications.
  • the user After the user registers the account information on the electronic wallet, the user adds and binds the bank card in the electronic wallet. After that, the user can complete the payment using the electronic wallet.
  • Some e-wallets support online payment and offline payment, such as Huawei wallet, UnionPay wallet, mobile and package. Among them, online payment is mainly for online shopping scenarios, such as web payment and in-app payment.
  • the terminal When the terminal is in the networked state, the user can use the bank card bound in the e-wallet APP to make payment; of course, if the terminal is not connected to the network, as long as the merchant-side receiving terminal can be connected to the network, the bank card bound in the electronic wallet APP can also be used.
  • Make a payment such as a QR code payment.
  • Offline payment is mainly for the point of sale (POS) terminal card swipe scene.
  • POS point of sale
  • the user can log in to the electronic wallet APP, and then use the bank card bound to the electronic wallet APP to complete the payment, that is, the mobile phone is simulated as a bank card for payment.
  • the corresponding card needs to be downloaded to the terminal for each bank card, and the user is required to perform the input card number and mobile phone number for each bank card to be bound. , card payment password, set wallet payment password, security issues, etc., a series of input information operations, and then complete the personalization of each card application to complete the binding.
  • card applications and their corresponding personalized data are saved locally on the terminal. Therefore, if the terminal is replaced, the user needs to re-bind the card after using the originally registered account to log in to the electronic wallet on the replaced terminal. Download the card application and re-execute the above series of input information one by one. In this way, the user is more cumbersome in the process of tying the card after the first time to bind the card or replace the terminal, and the efficiency of the card is low.
  • the embodiment of the present invention discloses a card binding method and a terminal, so as to solve the problem that the card binding efficiency is low when using the terminal NFC payment in the prior art.
  • the solution provided by the embodiment of the present application includes:
  • a method for tying a card for use in a terminal.
  • the method includes: displaying, by the terminal, a first interface, where the first interface displays at least two bank cards associated with an account currently registered by the electronic wallet APP.
  • the terminal determines, from the at least two bank cards, a bank card to be verified and at least one bank card to be bound.
  • the terminal displays a second interface, which is used to prompt the user to input verification information of the bank card to be verified.
  • the terminal sends the verification information to the server to request the server to deliver the card application and the personalized data corresponding to each bank card to be bound to the terminal after verifying the verification according to the verification information to complete binding the at least one to be tied.
  • Set the bank card is provided for use in a terminal.
  • the to-be-verified bank card is one or more of the at least one bank card to be bound.
  • the user after determining the bank card to be bound and the bank card to be verified, the user only needs to input the verification information of the bank card to be verified to complete binding all the bank cards to be bound, which can be realized by one (or a few). A few) The verification information of the bank card is verified and passed to bind all (or described as a few) bank cards to be bound.
  • the operation of triggering the user to display the first interface includes: a triggering operation input by the terminal through the electronic wallet APP before the first interface is displayed.
  • a triggering operation input by the terminal through the electronic wallet APP For example, the login operation input by the user on the login interface of the electronic wallet APP, or the operation of adding the bank card to be bound, input through the preset entry after the user successfully logs in to the electronic wallet APP.
  • the terminal determines, from the at least two bank cards, the bank card to be verified and the at least one bank card to be bound, which may be implemented by the terminal operating from the at least two bank cards according to the user's selection operation. Determining the bank card to be verified and the at least one bank card to be bound.
  • the method further includes: determining, by the terminal, the bank card to be verified and the at least one bank card to be bound from the at least two bank cards according to a preset rule.
  • the preset rule includes: determining a bank card whose historical usage count is greater than a preset threshold as a bank card to be verified or determining any one of the at least two bank cards that have been displayed as a bank card to be verified.
  • the terminal determines the at least two banks associated with the account currently registered by the electronic wallet APP.
  • the card may be specifically configured to: obtain, by the terminal, a first history card record associated with the account, and if the second history card record associated with the account is also acquired, the second history card is not included in the card.
  • the bank card corresponding to the identifier of the card application recorded but included in the first history card record is determined as the at least two bank cards. If the second history card is not obtained, the bank card corresponding to the identifier of the card application in the first history card record is determined as the at least two bank cards.
  • the first history card record includes an identifier of all card applications associated with the account, for example, an identifier of a card application of a bank card bound to the account when logging in to the other terminal, or unbound The identification of the card application of the bank card.
  • the first history card record can be obtained by the terminal from the server.
  • the second history card record includes an identifier of a card application bound by the account when logging in on the terminal.
  • the second history card record can be obtained by the terminal searching for a locally saved list.
  • the list stores the identifier of the card application bound by the account when logging in on the current terminal.
  • the second history card record can also be obtained by the terminal from the server.
  • the determining the at least two bank cards associated with the account currently registered by the e-wallet APP may also be implemented as: the third history carding record sent by the terminal receiving server, the The third history card record includes an identifier of a card application that is associated with the account and that is not locally bound by the terminal. Further, the terminal may determine, as the at least two bank cards, the bank card corresponding to the identifier of the card application in the third history card record.
  • the determining at least two bank cards associated with the account currently registered by the electronic wallet APP may be implemented as: determining, by the terminal, all the bank cards supported by the electronic wallet APP as The at least two bank cards associated with the account currently registered by the e-wallet APP.
  • the terminal sends the at least one bank card to be bound and the identifier of the bank card to be verified to the electronic wallet server after determining the bank card to be verified and the at least one bank card to be bound.
  • the e-wallet server requests the bank server to perform verification according to the identifier of the at least one bank card to be bound and the identifier of the bank card to be verified, and delivers the card application and personalized data corresponding to the bank card to be bound to the terminal.
  • bank server corresponding to the bank card to be verified is described as a first bank server, and any bank server corresponding to the bank card to be bound is described as a second bank server.
  • the terminal sends the verification information to the server to request the server to deliver the card application and the personalized data corresponding to each bank card to be bound to the terminal after the verification according to the verification information, including:
  • the e-wallet server sends the first request, so that the e-wallet server requests the first bank server to verify the verification information, and then delivers the card application and the personalized data corresponding to the bank card to be verified to the terminal.
  • the first request carries the verification information
  • the personalized data carries a mutual trust certificate.
  • the terminal After receiving the card application and the personalized data corresponding to the bank card to be verified, the terminal then sends a second request to the electronic wallet server to request the electronic wallet server to request the mutual trust certificate between the second bank server and the first bank server.
  • the card application and the personalized data corresponding to the bank card to be bound are delivered to the terminal through the verification.
  • the second request carries the mutual trust certificate.
  • the terminal sends the verification information to the server to request the server to deliver the card application and the personalized data corresponding to each bank card to be bound to the terminal after verifying the verification according to the verification information, including:
  • the terminal sends a request to the electronic wallet server, where the request carries the verification information of the bank card to be verified, so that the electronic wallet server separately requests the first bank server and the second bank server to be authenticated by the first bank server according to the verification information.
  • the bank server delivers the card application and the personalized data corresponding to the bank card to be verified to the terminal, and the card application and personalization corresponding to the bank card to be bound are sent by the second bank server to the terminal data.
  • the terminal sends the verification information to the server to request the server to deliver the card application and the personalized data corresponding to each bank card to be bound to the terminal after verifying the verification according to the verification information, including: the terminal.
  • the card application and the personalized data corresponding to each bank card to be bound are delivered to the terminal.
  • the verification information carried in the above request is the encrypted verification information.
  • a second aspect provides a method for applying a card to a terminal.
  • the method includes: displaying, by the terminal, a first interface, where the first interface displays at least two bank cards associated with an account currently registered by the electronic wallet APP, and each bank The card corresponds to the identity of the terminal that has bound the bank card.
  • the terminal prompts the user with the historical information, that is, the terminal displays the identifiers of other terminals and the bank card bound when logging in to the current account on the other terminal.
  • the identifier of the current terminal and the bank card that has been bound on the current terminal are also displayed on the first interface.
  • the terminal determines, from the at least two bank cards, a bank card to be verified and at least one bank card to be bound; the terminal displays a second interface, the second The interface is used to prompt the user to input the verification information of the bank card to be verified; the terminal sends the verification information to the server to request the server to deliver the card application and the individual corresponding to the bank card to be bound to the terminal after verifying the verification according to the verification information.
  • the data is completed to bind the at least one bank card to be bound.
  • the terminal determines, from the at least two bank cards, the bank card to be verified and the at least one bank card to be bound, the terminal displays the second interface, and the terminal sends the verification information to the server to request the server to verify the verification according to the verification information.
  • the card application to be bound to each of the at least one bank card to be bound refer to the possible design of the first aspect. Narration.
  • the terminal before displaying the first interface, displays a second interface, where the second interface is used to prompt the user to input verification information of the bank card to be verified.
  • the terminal determines at least one bank card to be bound from the at least two bank cards; the terminal sends the verification information of the bank card to be verified to the server to request the server to After the verification of the verification information, the card application and the personalized data corresponding to each bank card to be bound are delivered to the terminal to complete binding of the at least one bank card to be bound.
  • the implementation manner can be understood as: the terminal first displays the second interface for prompting the user to input the verification information of the bank card to be verified, and then displays the first interface for displaying at least two bank cards, so that the user can The at least two bank cards further determine the bank card to be bound. Then, the terminal sends the verification information to the server to request the server to verify, according to the verification information, the card application and the personalized data corresponding to each bank card to be bound, to complete the binding of the at least one to be bound. Bank card. It can be seen that the implementation manner can still realize that the user only needs to input the verification information of the bank card to be verified to complete binding all the bank cards to be bound, and can verify the verification information through one (or a few) bank cards. After binding all (or described as a few) cards to be bound.
  • the terminal determines, from the at least two bank cards, the bank card to be bound, the terminal displays the second interface, and the terminal sends the verification information to the server to request the server to send the terminal to the terminal after verifying the verification according to the verification information.
  • the card application and the personalized data to be bound to the at least one bank card to be bound refer to the possible design manner of the first aspect, and details are not described herein again.
  • bank server corresponding to the bank card to be verified is described as a first bank server, and any bank server corresponding to the bank card to be bound is described as a second bank server.
  • a third aspect provides a method for binding a card to an electronic wallet server, the method comprising: receiving, by the electronic wallet server, an identifier of at least one bank card to be bound and verification information of the bank card to be verified, according to the verification The information and the identifier of the at least one bank card to be bound are requested to the bank server to deliver the card application and the personalized data corresponding to each bank card to be bound to the terminal after the verification of the verification information.
  • the electronic wallet server pushes the first historical carding record to the terminal before receiving the identifier of the at least one bank card to be bound and the verification card of the bank card to be verified sent by the terminal, the first The history card record includes the identifiers of all card applications associated with the account currently registered by the e-wallet APP.
  • the identifiers of all card applications associated with the account currently registered by the electronic wallet APP include the identity of the card application that the user binds when logging in to the current account on the electronic wallet APP on all terminals.
  • the identity of all card applications associated with the account currently logged in by the electronic wallet APP also includes the identity of the card application associated with the account but unbundled.
  • the electronic wallet server sends a second history binding card record to the terminal before receiving the identifier of the at least one bank card to be bound and the verification card of the bank card to be verified sent by the terminal, and the second history is tied.
  • the card record includes an identifier of the card application bound by the account when logging in in the electronic wallet APP on the terminal.
  • the electronic wallet server pushes a third historical carding record to the terminal before receiving the at least one identity of the bank card to be bound and the verification information of the bank card to be verified sent by the terminal, and the third history is tied.
  • the card record includes an identifier of a card application that is associated with the account and is not locally bound at the terminal, or an identifier of all card applications supported by the electronic wallet APP.
  • the electronic wallet server pushing the first history card record or the second history card record or the third history card record to the terminal may be specifically implemented by: the electronic wallet server receiving the query request of the terminal, in response to The query requests the historical bond record to be pushed to the terminal.
  • the electronic wallet server monitors the operation of logging in the account on the electronic wallet APP, the electronic wallet server pushes the historical carding record to the terminal.
  • the electronic wallet server requests the bank server to issue each to be bound to the terminal after verifying the verification information according to the verification information and the identifier of the at least one bank card to be bound. Determining the card application and the personalized data corresponding to the bank card, the electronic wallet server respectively requesting the first bank server and the second bank server to verify according to the verification information according to the identifier of the at least one bank card to be bound After the first bank server, the card application and the personalized data corresponding to the bank card to be verified are sent to the terminal, and the card application corresponding to the bank card to be bound is sent by the second bank server to the terminal. And personalization data.
  • the electronic wallet server requests the bank server to issue each to be bound to the terminal after verifying the verification information according to the verification information and the identifier of the at least one bank card to be bound.
  • Determining the card application and the personalized data corresponding to the bank card the method includes: the electronic wallet server sends a first request to the first bank server, where the first request includes the verification information, and is used to request the first bank server to After the verification information is verified, the card application and the personalized data corresponding to the bank card to be verified are sent, and the personalized data carries the mutual trust certificate; after receiving the mutual trust certificate, according to the bank card to be bound
  • the identifier sends a second request to the second bank server, where the second request includes the mutual trust certificate and the identifier of the bank card to be verified, so that the second bank server requests the identifier according to the bank card to be verified After the first bank server verifies the mutual trust certificate, the card application and personalization corresponding to the bank card to be bound are delivered to the terminal. It is.
  • the electronic wallet server requests the bank server to issue each to be bound to the terminal after verifying the verification information according to the verification information and the identifier of the at least one bank card to be bound.
  • the card application and the personalized data corresponding to the bank card the electronic wallet server sends a third request to the third-party trusted server, where the third request includes the verification information and the at least one bank card to be bound And the identification, so that the third-party trusted server requests the first bank server to send the card application and personalized data corresponding to the to-be-verified bank card to the terminal after the verification by the verification information, wherein the The personalization data includes a mutual trust certificate; and causing the third-party trusted server to request the second bank server to send the certificate to the terminal according to the verification of the mutual trust certificate according to the identifier of the at least one bank card to be bound
  • the card application and personalization data corresponding to the binding bank card are described.
  • a fourth aspect provides a terminal, including: a display unit, configured to display a first interface, where the first interface displays at least two bank cards associated with an account currently registered by the electronic wallet APP. And a processing unit, configured to determine, from the at least two bank cards, a bank card to be verified and at least one bank card to be bound. The display unit is further configured to display a second interface, where the second interface is used to prompt the user to input verification information of the bank card to be verified. a sending unit, configured to send the verification information to the server, to request the server to deliver the card application and the personalized data corresponding to each bank card to be bound to the terminal after the verification is verified according to the verification information, to complete the binding The at least one bank card to be bound is determined.
  • the terminal further includes: a receiving unit, configured to receive a triggering operation input by the user through the electronic wallet APP, wherein the triggering operation includes: inputting by the user on the login interface of the electronic wallet APP The login operation; or, after the user successfully logs in to the electronic wallet APP, the operation of adding the bank card to be bound is input through the preset entry.
  • a receiving unit configured to receive a triggering operation input by the user through the electronic wallet APP, wherein the triggering operation includes: inputting by the user on the login interface of the electronic wallet APP The login operation; or, after the user successfully logs in to the electronic wallet APP, the operation of adding the bank card to be bound is input through the preset entry.
  • the processing unit is further configured to determine, according to a user's selection operation, the bank card to be verified and the at least one bank card to be bound from the at least two bank cards, or Determining, from the at least two bank cards, the bank card to be verified and the at least one bank card to be bound according to a preset rule.
  • the preset rule includes: determining a bank card whose historical usage count is greater than a preset threshold as a bank card to be verified or determining any one of them as a bank card to be verified.
  • the display unit is further configured to display an installation progress of a card application corresponding to each of the bank cards to be bound.
  • the bank card to be verified is one or more of the at least one bank card to be bound.
  • the processing unit is further configured to determine the at least two bank cards associated with an account currently registered by the electronic wallet APP.
  • the processing unit is further configured to acquire a first history card record associated with the account, and if the second history card record associated with the account is obtained, it is not included in the The bank card corresponding to the identifier of the card application included in the second history card record but included in the first history card record is determined as the at least two bank cards; or, if the second history is not acquired The card record is determined, and the bank card corresponding to the identifier of the card application in the first history card record is determined as the at least two bank cards.
  • the first history card record includes an identifier of all card applications associated with the account; the second history card record includes a card application bound by the account when logging in on the terminal. logo.
  • the processing unit is further configured to acquire the first history card record from the server.
  • the processing unit is further configured to find a locally saved list to obtain the second history card record; wherein the account is saved in the list when the account is registered on the terminal.
  • the identifier of the card application, or the second history card record obtained from the server.
  • the receiving unit is further configured to receive a third historical carding record sent by the server, where the third historical carding record includes being associated with the account and the terminal is not locally The identity of the bound card application.
  • the processing unit is further configured to determine, as the at least two bank cards, a bank card corresponding to the identifier of the card application in the third history card record.
  • the processing unit is further configured to determine, to the bank card, all the bank cards supported by the electronic wallet APP as the at least two bank cards associated with the account currently registered by the electronic wallet APP.
  • the sending unit is further configured to send the identifier of the at least one bank card to be bound to the electronic wallet server, so that the electronic wallet server is configured according to the at least one bank card to be bound
  • the identifier requests the bank server to deliver the card application and personalized data corresponding to the bank card to be bound to the terminal.
  • the sending unit is further configured to send a first request to the electronic wallet server, so that the electronic wallet server requests the first bank server to verify the verification information and send the Card application and personalization data corresponding to the bank card to be verified.
  • the first request carries the verification information
  • the first bank server is a bank server corresponding to the bank card to be verified
  • the personalized data carries a mutual trust certificate.
  • the sending unit is further configured to: after receiving the card application and the personalized data corresponding to the bank card to be verified, send a second request to the electronic wallet server, so that the electronic wallet server requests the second bank server and the first After the verification of the mutual trust certificate by a bank server, the card application and the personalized data corresponding to the bank card to be bound are delivered to the terminal.
  • the second request carries the mutual trust certificate; the second bank server includes any one of the bank servers corresponding to the bank card to be bound.
  • the sending unit is further configured to send a request to the electronic wallet server, so that the electronic wallet server separately requests the first bank server and the second bank server to verify the verification according to the verification information.
  • the first bank server sends the card application and the personalized data corresponding to the bank card to be verified to the terminal, and the card corresponding to the bank card to be bound is sent by the second bank server to the terminal Apply and personalize data.
  • the request carries the verification information of the bank card to be verified, the first bank server is a bank server corresponding to the bank card to be verified, and the second bank server is any one of the banks to be bound.
  • the bank server corresponding to the card is a bank server corresponding to the bank card.
  • the sending unit is further configured to send a request to the electronic wallet server, so that the electronic wallet server separately requests the first bank server and the second bank server by using a third-party trusted server, according to the After the verification of the verification information, the card application and the personalized data corresponding to each bank card to be bound are delivered to the terminal.
  • the first bank server is a bank server corresponding to the bank card to be verified
  • the second bank server is a bank server corresponding to any bank card to be bound.
  • the verification information carried in the request is encrypted verification information.
  • a terminal includes: a display unit, configured to display a first interface, where the first interface displays at least two bank cards associated with an account currently registered by the electronic wallet APP, and a corresponding bank card The identifier of the terminal that binds the bank card.
  • the terminal further includes a processing unit and a transmitting unit.
  • the processing unit is configured to determine, from the at least two bank cards, a bank card to be verified and at least one bank card to be bound.
  • the display unit is further configured to display a second interface after the first interface is displayed, where the second interface is used to prompt the user to input verification information of the bank card to be verified.
  • the sending unit is configured to send the verification information to the server to request the server to deliver the card application and the personalized data corresponding to each bank card to be bound to the terminal after verifying the verification according to the verification information to complete the binding. At least one bank card to be bound.
  • the display unit is further configured to display a second interface, where the second interface is used to prompt the user to input verification information of the bank card to be verified before displaying the first interface.
  • the processing unit is further configured to: after displaying the first interface, determine at least one bank card to be bound from the at least two bank cards.
  • the sending unit is further configured to send the verification information of the to-be-verified bank card to the server, to request the server to verify, according to the verification information, the card application and the personalized data corresponding to each bank card to be bound by the backward terminal. Binding the at least one bank card to be bound.
  • an electronic wallet server comprising: a receiving unit, configured to receive at least one identifier of a bank card to be bound and verification information of a bank card to be verified sent by the terminal. a processing unit, configured to request, according to the verification information and the identifier of the at least one bank card to be bound, the bank server to send a card corresponding to each bank card to be bound to the terminal after verifying the verification information Application and personalization data.
  • the bank server includes a first bank server and a second bank server, the first bank server is a bank server corresponding to the bank card to be verified, and the second bank server is any one of the banks to be bound The bank server corresponding to the card.
  • the electronic wallet server further includes: a sending unit, configured to push a first historical carding record to the terminal, where the first historical carding record includes a current login with the electronic wallet APP The ID of all card applications associated with the account.
  • the identifiers of all the card applications associated with the account currently registered by the electronic wallet APP include the identifiers of the card applications that the user binds when logging in to the current account on the electronic wallet APP on all terminals.
  • the identifiers of all the card applications associated with the account currently registered by the electronic wallet APP further include an identifier of the card application associated with the account but untied.
  • the sending unit is further configured to send a second history binding card to the terminal before receiving the identifier of the at least one bank card to be bound and the verification information of the bank card to be verified sent by the terminal Recording, the second history card record includes an identifier of the card application bound by the account when logging in in the electronic wallet APP on the terminal.
  • the sending unit is further configured to: before the identifier of the at least one bank card to be bound and the verification information of the bank card to be verified sent by the receiving terminal, push the third history binding card to the terminal.
  • the third history card record includes an identifier of a card application that is associated with the account and is not locally bound at the terminal, or an identifier of all card applications supported by the electronic wallet APP.
  • the receiving unit is further configured to receive a query request of the terminal, and the sending unit is further configured to: push the historical card binding record to the terminal in response to the query request.
  • the sending unit is further configured to: after listening to the operation of logging in the account on the electronic wallet APP, pushing the historical card binding record to the terminal.
  • the historical card binding record includes the first history card binding record, the second history card binding record, and the third history card binding record.
  • the sending unit is further configured to separately request the first bank server and the second bank server to verify the verification according to the verification information according to the identifier of the at least one bank card to be bound And the card application and the personalized data corresponding to the bank card to be verified are sent by the first bank server to the terminal, and the card application corresponding to the bank card to be bound is sent by the second bank server to the terminal.
  • Personalized data is sent by the first bank server and the second bank server to verify the verification according to the verification information according to the identifier of the at least one bank card to be bound.
  • the sending unit is further configured to send a first request to the first bank server, where the first request includes the verification information, and is used to request the first bank server to perform After the verification information is verified, the card application and the personalized data corresponding to the bank card to be verified are sent, and the personalized data carries the mutual trust certificate.
  • the second bank server After receiving the mutual trust credential, sending a second request to the second bank server according to the identifier of the to-be-bound bank card, where the second request includes the mutual trust credential and the identifier of the to-be-verified bank card, After the second bank server requests the first bank server to verify the mutual trust certificate according to the identifier of the bank card to be verified, the second bank server sends the card application corresponding to the bank card to be bound to the terminal and Personalized data.
  • the sending unit is further configured to send a third request to the third-party trusted server, where the third request includes the verification information and the identifier of the at least one bank card to be bound So that the third-party trusted server requests the first bank server to send the card application and personalized data corresponding to the to-be-verified bank card to the terminal after verifying the verification according to the verification information, wherein the individual And the third-party trusted server requesting the third-party trusted server to send the the second bank server to the terminal according to the verification of the mutual-trust credential according to the identifier of the at least one bank card to be bound Card application and personalization data corresponding to the bank card to be bound.
  • an embodiment of the present application provides a terminal, including: a processor, a memory, a bus, and a communication interface; the memory is configured to store a computer execution instruction, and the processor is connected to the memory through the bus, when the terminal is running The processor executes the computer-executed instructions stored in the memory to cause the terminal to perform the card-capping method according to any of the first aspect, the first aspect, the second aspect, or the second aspect.
  • an embodiment of the present application provides an electronic wallet server, including: a processor, a memory, a bus, and a communication interface; the memory is configured to store a computer execution instruction, and the processor is connected to the memory through the bus, and the electronic wallet While the server is running, the processor executes the computer-executed instructions stored by the memory to cause the electronic wallet server to perform the card binding method of any of the above.
  • the embodiment of the present application provides a computer readable storage medium, where the computer readable storage medium stores an instruction, when the instruction is run on any of the foregoing terminals, causing the terminal to perform any of the foregoing The method of binding cards.
  • the embodiment of the present application provides a computer program product comprising instructions, when the terminal is run on any of the foregoing terminals, causing the terminal to perform the card binding method according to any one of the above.
  • the names of the foregoing terminals are not limited to the devices themselves, and in actual implementation, the devices may appear under other names. As long as the functions of the respective devices are similar to the embodiments of the present application, they are within the scope of the claims and their equivalents.
  • FIG. 1 is a schematic structural diagram of a terminal according to an embodiment of the present application.
  • FIG. 2A is a schematic diagram of an application scenario of a card binding method according to an embodiment of the present disclosure
  • FIG. 2B is a second example of an application scenario of a card binding method according to an embodiment of the present disclosure
  • FIG. 2C is a schematic diagram of an application scenario of a card binding method according to an embodiment of the present disclosure.
  • FIG. 2D is a schematic diagram of an application scenario of a card binding method according to an embodiment of the present disclosure.
  • FIG. 2 is a schematic diagram of an application scenario of a card binding method according to an embodiment of the present disclosure
  • FIG. 2 is a schematic diagram of an application scenario of a card binding method according to an embodiment of the present disclosure
  • FIG. 3 is a schematic diagram 1 of a specific implementation process of a card binding method according to an embodiment of the present application.
  • FIG. 4 is a second schematic diagram of a specific implementation process of the method for tying a card according to an embodiment of the present disclosure
  • FIG. 5 is a third schematic diagram of a specific implementation process of a card binding method according to an embodiment of the present disclosure
  • FIG. 6 is a schematic structural diagram of a terminal according to an embodiment of the present application.
  • FIG. 7 is a schematic structural diagram of an electronic wallet server according to an embodiment of the present application.
  • FIG. 8 is a schematic structural diagram of another electronic wallet server according to an embodiment of the present application.
  • the terminal for performing the card binding method provided by the embodiment of the present application may specifically be a mobile phone, a wearable device, an augmented reality (AR), a virtual reality (VR) device, a tablet computer, a notebook computer, and a super device.
  • Any terminal having an NFC payment function such as an ultra-mobile personal computer (UMPC), a netbook, or a personal digital assistant (PDA).
  • UMPC ultra-mobile personal computer
  • PDA personal digital assistant
  • the terminal 100 may specifically include: a processor 101, a radio frequency (RF) circuit 102, a memory 103, a touch screen 104, a Bluetooth device 105, one or more sensors 106, and wireless fidelity. (WIreless-Fidelity, Wi-Fi) device 107, positioning device 108, audio circuit 109, peripheral interface 110, power system 111, and near field communication (NFC) device 112 and the like. These components can communicate over one or more communication buses or signal lines (not shown in Figure 1). It will be understood by those skilled in the art that the hardware structure shown in FIG. 1 does not constitute a limitation on the terminal 100, and the terminal 100 may include more or less components than those illustrated, or combine some components, or different component arrangements. .
  • RF radio frequency
  • the various components of the terminal 100 are specifically described below with reference to FIG. 1 :
  • the processor 101 is a control center of the terminal 100, and connects various parts of the terminal 100 by various interfaces and lines, executes or executes an application stored in the memory 103, and calls data stored in the memory 103, and executes the terminal 100.
  • the processor 101 may include one or more processing units; for example, the processor 101 may be a Kirin 960 chip manufactured by Huawei Technologies Co., Ltd.
  • the processor 101 may further include a fingerprint verification chip for verifying the collected fingerprint.
  • the radio frequency circuit 102 can be used to receive and transmit wireless signals during transmission or reception of information or calls.
  • the radio frequency circuit 102 can process the downlink data of the base station and then process it to the processor 101; in addition, transmit the data related to the uplink to the base station.
  • radio frequency circuits include, but are not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier, a duplexer, and the like.
  • the radio frequency circuit 102 can also communicate with other devices through wireless communication.
  • the wireless communication can use any communication standard or protocol, including but not limited to global mobile communication systems, general packet radio services, code division multiple access, wideband code division multiple access, long term evolution, email, short message service, and the like.
  • the memory 103 is used to store applications and data, and the processor 101 executes various functions and data processing of the terminal 100 by running applications and data stored in the memory 103.
  • the memory 103 mainly includes a storage program area and a storage data area, wherein the storage program area can store an operating system, an application required for at least one function (such as a sound playing function, an image playing function, etc.); the storage data area can be stored according to the use terminal. Data created at 100 o'clock (such as audio data, phone book, etc.).
  • the memory 103 may include a high speed random access memory (RAM), and may also include a nonvolatile memory such as a magnetic disk storage device, a flash memory device, or other volatile solid state storage device.
  • the memory 103 can store various operating systems, for example, developed by Apple. Operating system, developed by Google Inc. Operating system, etc.
  • the above memory 103 may be independent and connected to the processor 101 via the above communication bus; the memory 103 may also be integrated with the processor 101.
  • the touch screen 104 may specifically include a touch panel 104-1 and a display 104-2.
  • the touch panel 104-1 as an input device of the terminal can collect a touch event on or near the user (for example, the user uses a finger, a stylus, or the like on the touch panel 104-1 or in touch.
  • the operation near the board 104-1) and the collected touch information is transmitted to other devices (for example, the processor 101).
  • the touch event of the user in the vicinity of the touch panel 104-1 may be referred to as a hovering touch; the hovering touch may mean that the user does not need to directly touch the touchpad in order to select, move or drag a target (eg, an icon, etc.) And only the user is located near the terminal in order to perform the desired function.
  • the touch panel 104-1 can be implemented in various types such as resistive, capacitive, infrared, and surface acoustic waves.
  • a display (also referred to as a display screen) 104-2 can be used to display information entered by the user or information provided to the user as well as various menus of the terminal 100.
  • the display 104-2 can be configured in the form of a liquid crystal display, an organic light emitting diode, or the like.
  • the touchpad 104-1 can be overlaid on the display 104-2, and when the touchpad 104-1 detects a touch event on or near it, it is transmitted to the processor 101 to determine the type of touch event, and then the processor 101 may provide a corresponding visual output on display 104-2 depending on the type of touch event.
  • the touchpad 104-1 and the display 104-2 are implemented as two separate components to implement the input and output functions of the terminal 100, in some embodiments, the touchpad 104- 1 is integrated with the display screen 104-2 to implement the input and output functions of the terminal 100.
  • the touch screen 104 is formed by stacking a plurality of layers of materials. In the embodiment of the present application, only the touch panel (layer) and the display screen (layer) are shown, and other layers are not described in the embodiment of the present application. .
  • the touch panel 104-1 can be disposed on the front side of the terminal 100 in the form of a full-board
  • the display screen 104-2 can also be disposed on the front side of the terminal 100 in the form of a full-board, so that the front side of the mobile phone can be borderless. Structure.
  • the terminal 100 may also include other input devices, such as, but not limited to, a physical keyboard, a function key (such as a volume control button, a power switch button, etc.), a trackball, a mouse, a joystick, etc. A variety.
  • a function key such as a volume control button, a power switch button, etc.
  • a trackball such as a mouse, a joystick, etc.
  • the terminal 100 may further include a Bluetooth device 105 for implementing data exchange between the terminal 100 and other short-range terminals (for example, mobile phones, smart watches, etc.).
  • the Bluetooth device in the embodiment of the present application may be an integrated circuit or a Bluetooth chip or the like.
  • Terminal 100 may also include at least one type of sensor 106, such as a fingerprint acquisition device, a light sensor, a motion sensor, and other sensors.
  • the fingerprint collection device may be configured on the back side of the terminal 100 (for example, below the rear camera), or the fingerprint collection device may be disposed on the front side of the terminal 100 (for example, below the touch screen 104).
  • the fingerprint collection device can be configured in the touch screen 104 to implement the fingerprint recognition function, that is, the fingerprint collection device can be integrated with the touch screen 104 to implement the fingerprint recognition function of the terminal 100.
  • the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor may adjust the brightness of the display of the touch screen 104 according to the brightness of the ambient light, and the proximity sensor may turn off the power of the display when the terminal 100 moves to the ear.
  • the accelerometer sensor can detect the magnitude of acceleration in all directions (usually three axes). When it is stationary, it can detect the magnitude and direction of gravity. It can be used to identify the gesture of the mobile phone (such as horizontal and vertical screen switching, related Game, magnetometer attitude calibration), vibration recognition related functions (such as pedometer, tapping).
  • Other sensors such as a gyroscope, a barometer, a hygrometer, a thermometer, an infrared sensor, and the like which are also configurable by the terminal 100 will not be described herein.
  • the Wi-Fi device 107 is configured to provide the terminal 100 with network access complying with the Wi-Fi related standard protocol, and the terminal 100 can access the Wi-Fi access point through the Wi-Fi device 107, thereby helping the user to send and receive emails, Browsing web pages and accessing streaming media, etc., it provides users with wireless broadband Internet access.
  • the Wi-Fi device 107 can also function as a Wi-Fi wireless access point, and can provide Wi-Fi network access to other terminals.
  • the positioning device 108 is configured to provide a geographic location for the terminal 100. It can be understood that the positioning device 108 can be specifically a receiver of a positioning system such as a global positioning system (GPS) or a Beidou satellite navigation system, and a Russian GLONASS. After receiving the geographical location transmitted by the positioning system, the positioning device 108 sends the information to the processor 101 for processing, or sends it to the memory 103 for storage. In still other embodiments, the positioning device 108 may also be an assisted global positioning system (AGPS) receiver, and the AGPS system assists the positioning device 108 in performing ranging and positioning services by acting as an auxiliary server.
  • AGPS assisted global positioning system
  • the secondary location server provides location assistance over a wireless communication network in communication with a terminal, such as the location device 108 (i.e., GPS receiver) of the terminal 100.
  • the positioning device 108 can also be a Wi-Fi access point based positioning technology. Since each Wi-Fi access point has a globally unique media access control (MAC) address, the terminal can scan and collect the surrounding Wi-Fi access points when Wi-Fi is turned on. Broadcast signals, so the MAC address broadcasted by the Wi-Fi access point can be obtained; the terminal sends the data (such as the MAC address) capable of indicating the Wi-Fi access point to the location server through the wireless communication network, and is retrieved by the location server. The geographic location of each Wi-Fi access point, combined with the strength of the Wi-Fi broadcast signal, calculates the geographic location of the terminal and sends it to the location device 108 of the terminal.
  • MAC media access control
  • the NFC device 112 is configured to provide an NFC function for the terminal to support various types of NFC services. For example, after the terminal is simulated as a card, the NFC payment for the card payment is completed directly near the point of sale (POS), and the terminal is used as a reader/writer. NFC card reading, NFC data transmission, etc., which directly read the data in the card directly close to the physical card.
  • the NFC device 112 includes a NFC controller (Near Field Communication Cntroller, NFCC), and its functions include modulation and demodulation of radio frequency signals and NFC protocol processing.
  • the NFCC is connected to a radio frequency antenna (ie, an NFC antenna) to transmit and receive NFC signals.
  • the mobile phone may also include a security element (SE).
  • SE security element
  • the SE is used to securely store sensitive information and provide a secure execution environment for transaction transactions. It can be integrated into the processor 101, or located on the Subscriber Identification Module (SIM) card of the mobile phone, or secure digital storage located on the mobile phone. In the Secure Digital Memory Card (SD), it can also be a stand-alone chip.
  • SIM Subscriber Identification Module
  • SD Secure Digital Memory Card
  • the NFCC can be interconnected with the SE.
  • the audio circuit 109, the speaker 113, and the microphone 114 can provide an audio interface between the user and the terminal 100.
  • the audio circuit 109 can transmit the converted electrical data of the received audio data to the speaker 113 for conversion to the sound signal output by the speaker 113; on the other hand, the microphone 114 converts the collected sound signal into an electrical signal by the audio circuit 109. After receiving, it is converted into audio data, and then the audio data is output to the RF circuit 102 for transmission to, for example, another mobile phone, or the audio data is output to the memory 103 for further processing.
  • the peripheral interface 110 is used to provide various interfaces for external input/output devices (such as a keyboard, a mouse, an external display, an external memory, a subscriber identity module card, etc.). For example, it is connected to the mouse through a universal serial bus (USB) interface, and is connected with a subscriber identification module (SIM) card provided by the telecommunication operator through a metal contact on the card slot of the subscriber identification module. . Peripheral interface 110 can be used to couple the external input/output peripherals described above to processor 101 and memory 103.
  • USB universal serial bus
  • SIM subscriber identification module
  • the terminal 100 may further include a power supply device 111 (such as a battery and a power management chip) that supplies power to the various components, and the battery may be logically connected to the processor 101 through the power management chip to manage charging, discharging, and power management through the power supply device 111. And other functions.
  • a power supply device 111 such as a battery and a power management chip
  • the battery may be logically connected to the processor 101 through the power management chip to manage charging, discharging, and power management through the power supply device 111. And other functions.
  • the terminal 100 may further include a camera (front camera and/or rear camera), a flash, a micro-projection device, and the like, and details are not described herein.
  • a camera front camera and/or rear camera
  • a flash flash
  • micro-projection device micro-projection device
  • the above terminal is only an example, and the terminal 100 may have more or less components than those shown in the figure, may combine two or more components, or may have different component configurations. .
  • the user can use the e-wallet APP to complete the offline payment, such as completing the NFC card payment on the physical store or the physical POS machine.
  • the user needs to perform a process of inputting a card number, a mobile phone number, a card payment password, setting a wallet payment password, and a security question for each bank card to be bound to complete the binding. It can be seen that when the current card binding mode is used to complete the binding of multiple cards, the user's operation is cumbersome and the card binding efficiency is low.
  • the embodiment of the present application provides a method for binding a card, which requires the user to input only the verification information of a single card or a few bank cards to bind all the banks to be bound at one time. card.
  • the terminal displays a first interface, where the first interface displays at least two bank cards associated with an account currently registered by the electronic wallet APP.
  • the at least two bank cards may include all bank cards associated with the account but not yet bound on the terminal. How the terminal specifically determines how the at least two bank cards are implemented may be referred to the following.
  • the terminal displays at least two bank cards associated with the currently logged in account but not yet bound on the terminal through the interface 202A in FIG. 2A, or the terminal displays and the current login according to the identifier of the terminal through the interface 202B in FIG. 2C.
  • At least two bank cards associated with the account but not yet bound to the terminal that is, the terminal identification indicates that each bank card displayed is bound to which terminal when the account is logged in.
  • the at least two bank cards may include all the bank cards associated with the account, for example, the terminal displays, by using the interface 202C in FIG. 2C, that the current terminal is associated with the account when the current account is logged in but not yet on the terminal.
  • Bind at least two bank cards and simultaneously displays the bank card that has been bound to the terminal when the current terminal logs in to the current account. Thereafter, the terminal determines, from the at least two bank cards, the bank card to be verified and at least one bank card to be bound and obtains verification information of the bank card to be verified. Exemplarily, the user can select a bank card to be verified and a bank card to be bound from at least two bank cards displayed in the interface 202A or 202B or 202C. After the terminal detects the user's selection operation, the display interface 203 is configured to prompt the user to input verification information of the bank card to be verified.
  • the user can input relevant information of the bank card to be verified according to the prompt of the interface 203, such as a bank name, a card number, a reserved mobile phone number, a withdrawal password, and a security problem setting.
  • relevant information of the bank card to be verified such as a bank name, a card number, a reserved mobile phone number, a withdrawal password, and a security problem setting.
  • the user can manually edit the input, or can be input through other modes such as a voice, a picture, a picture taken by taking a picture of the card, or an NFC card reading method, which is not limited in the embodiment of the present application. As shown in FIG.
  • the terminal display interface 2031 prompts the user to take a photo of the bank card to be verified to read the card number of the bank card to be verified, and then the terminal then displays the interface 2032 to prompt the user to continue to input the to-be-verified. Other verification information for the bank card.
  • the terminal sends the verification information of the bank card to be verified to the server to request the server to deliver the card application and the personalized data corresponding to each bank card to be bound to the terminal to complete the binding after verifying the verification according to the verification information.
  • the at least one bank card to be bound is displayed.
  • the operation of triggering the terminal to display the first interface includes a triggering operation input by the user through the electronic wallet APP.
  • the triggering operation includes a login operation 201A input by the user on the login interface of the electronic wallet APP. It is mainly used in the scenario where the terminal detects that the user first uses an account to log in to the e-wallet APP on the terminal. For example, the first time the user logs in to the e-wallet APP on the terminal 1 by using the account abcd, the triggering operation may be the first login operation of the user on the terminal 1 detected by the terminal.
  • the triggering operation may be that the terminal detects that the user is on the terminal 2.
  • First login operation As shown in FIG. 2B, the triggering operation further includes: after the user successfully logs in to the electronic wallet APP, the operation 201B of adding a bank card to be bound is input through a preset portal, such as an add button of the card binding interface.
  • the terminal displays a first interface as shown by interface 202A, 202B or 202C.
  • FIG. 2A - 2D can be specifically divided into different types of cards, such as a savings card, a credit card, etc., and the specific implementation can be explicitly indicated by a text or a picture. Not limited.
  • the interface as shown in the interface 202A may be displayed again to prompt the user to select another bank card to be bound, and then perform the subsequent card binding process and display as shown in the interface 204. interface.
  • the user when the user inputs the verification information of a bank card in the electronic wallet APP to bind the bank card, the user is prompted to bind the remaining bank cards at the same time, and the user is not required to input the remaining bank to be bound.
  • the display interface 203 after the terminal detects the triggering operation of the user, the display interface 203 prompts the user to input the verification information of the bank card to be bound (in the figure, China Merchants Bank as an example).
  • the triggering operation may be the login operation 201A of the login electronic wallet APP shown in FIG.
  • the terminal displays an interface 205A, which is used to prompt the user to bind the other bank cards at the same time and bind the other bank cards that the user can select, such as the Bank of China. Bank of Communications, etc.
  • the interface 205A it is specifically suggested which bank cards can be referred to later.
  • the user does not need to input the verification information of the Chinese bank card.
  • the terminal can simultaneously bind the Chinese bank card and the merchant bank card according to the verification information of the merchant bank card previously input by the user. .
  • the prompt interface shown in 205A can be replaced with the prompt interface shown in 205B.
  • the terminal displays the historical card binding information associated with the current account, which is specifically the bank card information that the user has bound to the current account when the user logs in to the current account.
  • the user is shown on the HUAWEI Mate10 in the interface 205B. Bind the Chinese bank card and bound the Bank of Communications on Glory 9. In this way, the user can select the bank card to be bound according to the prompt information.
  • the terminal may determine the electronic device displayed in the interface 202A or 202B or 202C by using the following implementation manner. At least two bank cards associated with the account currently registered by the wallet APP:
  • Embodiment 1 The terminal acquires a first history card record associated with the account, where the first history card record refers to a list or other record form including identifiers of all card applications associated with the account. Further, the terminal attempts to acquire a second history card record associated with the account, where the second history card record refers to a list or other record of the card application that is bound when the account is logged in to the current terminal. form. If the terminal obtains the second history card record associated with the account, the bank corresponding to the identifier of the card application not included in the second history card record but included in the first history card record is The card is determined to be the at least two bank cards. If the terminal does not obtain the second history card record, the bank card corresponding to the identifier of the card application in the first history card record is determined as the at least two bank cards.
  • the first history card is recorded as all the card records associated with the account. That is, the first history card record includes a set of records of all bank cards bound by the card binding operation after the user logs in to the current account on each terminal (including the current terminal and other terminals).
  • the first historical card binding record includes both currently bound, and may be bound but currently unbundled.
  • the terminal can obtain the first history card record from the electronic wallet server. In this way, the electronic wallet server is required to store the card binding record generated when the current account is registered on each terminal. When the terminal obtains the current account, the terminal can send a request to the electronic wallet server to obtain the first history card record.
  • the electronic wallet APP actively requests the electronic wallet server to acquire the first history carding record.
  • the electronic wallet server may also detect that the current account is actively pushed after logging in to the electronic wallet APP on the current terminal.
  • the electronic wallet server actively pushes the first history carding record to the electronic wallet APP of the terminal upon detecting the login or adding a card of the terminal.
  • the first history card record is as shown in Table 1 or Table 2 or Table 3.
  • the first historical card-binding record pushed by the electronic wallet server to the terminal includes only the identifier of the card application, and the terminal to which each card application belongs is not distinguished.
  • the first history card record that the e-wallet server pushes to the terminal includes the identifier of the terminal to which each card application belongs, in addition to the identifier of the card application.
  • the identification of the card application in Tables 1 and 3 above is represented by the type of card application (ie, the bank to which the card application belongs and its type, such as a bank's savings card, credit card, etc.), in the above Table 2, the card application The identifier is represented by an application identifier (AID), and both representations can indicate their corresponding bank cards. In other implementations, it may also be represented by information such as the name or number of the card application.
  • the first history card record shown in Table 1 or Table 2 or Table 3 also includes the status of the card application, and may not actually include the status of the card application.
  • the second history card binding record includes a card application that is effectively bound to the current account on the current terminal.
  • the card application that is effectively bound here is still bound to the current account and has not been unbound or deleted.
  • the terminal can locally find the second history binding card record.
  • the e-wallet APP is required to maintain a record locally in the terminal, such as saving the record in a Trusted Execution Environment (TEE), or by a trusted application in the TEE (Trusted Application, TA) ) responsible for maintaining this record.
  • TEE Trusted Execution Environment
  • TA Trusted Application
  • the e-wallet APP can determine whether there is the above-mentioned valid card-binding record, that is, the second history-linked card record, by looking up whether the record is present locally in the current terminal.
  • the terminal may also obtain the second historical carding record from the electronic wallet server.
  • the second history card is recorded as a card application currently existing on the terminal and effectively bound to the current electronic wallet account.
  • the second history card record refers to the identifier of the card application that has been bound when logging in to the current account on the current terminal, meaning that the current The terminal has already stored and bound the card applications without rebinding. Therefore, only the identifiers of the card applications not included in the second history card record but included in the first history card record may be corresponding.
  • the bank card is determined to be the at least two bank cards. For example, refer to the first historical card-binding record shown in Table 3 and the second history-linked card record shown in Table 4.
  • the “ICBC Credit Card” is the bank card that the user binds on other terminals, and the “CCB Credit Card” is before the user.
  • ICBC Credit Card and "CCB Credit Card” can be determined as at least two bank cards as described above and displayed. Of course, as shown above, these bank cards can be directly displayed only through the interface 202A as shown in FIG. 2A. Considering that the at least two bank cards may be bound by the card binding operation when logging in to the account on other different terminals, the interface may be similar to the interface 202B shown in FIG. 2C, and the terminal displays at least two bank cards to the user.
  • the terminal identifiers corresponding to the bank cards are separately displayed, that is, the bank cards are displayed in groups on the interface.
  • the interface 202C shown in FIG. 2D can also be displayed.
  • the currently bound bank card can also be displayed.
  • Embodiment 2 The terminal receives a third history card record sent by the server, where the third history card record includes an identifier of a card application that is associated with the account and is not locally bound to the terminal, that is, The identifier of the card application that is not bound by the current terminal when the current terminal logs in to the current account. Then, the terminal determines the bank card corresponding to the identifier of the card application in the third history card record as the at least two bank cards.
  • the e-wallet server is required to save the card-carrying record generated when the current account is logged in on each terminal, and optionally includes a record of unbinding after the card is tied.
  • the electronic wallet server saves the first historical card binding record and the second history card binding record, and the electronic wallet server can directly bind the first history card and the second history card according to the saved history.
  • the identifiers of the card applications that are not bound when the current terminal logs in to the current account are obtained, and the identifiers are sent to the terminal as a third history carding record in a list or other record form.
  • the first history card binding record may be saved, and then the card binding record corresponding to the terminal other than the current terminal and the tied or untied card record corresponding to the current terminal are directly used as the first Three historical tie card records are sent to the current terminal.
  • the server pushes the third history binding card record, it may be pushed after receiving the request from the terminal, or may be actively pushed.
  • the terminal may directly determine, as the at least two bank cards, the bank card supported by the electronic wallet APP.
  • This implementation is mainly applicable to the scenario where the user logs in to the current account for the first time, for example, the scenario where the newly registered account is used for the first time to bind the card on a certain terminal.
  • the at least two bank cards are operated according to the user's selection operation. Determining the bank card to be verified and the at least one bank card to be bound.
  • the terminal may automatically determine the bank card to be verified and the bank card to be bound according to a preset rule without prompting the user to select, or even if the user is prompted to select but the user has not selected for a long time.
  • the preset rule may be, for example, determining a bank card to be bound or a bank card to be verified based on the user's past usage, such as a bank card whose historical usage times exceed a preset number of times or a preset time or within a preset location range. Use more frequent bank cards.
  • all the bank cards in the at least two bank cards determined by the default are determined as the bank card to be bound and one bank card is arbitrarily selected as the bank card to be verified.
  • the user selects one of the bank cards to be bound as the bank card to be verified as an example.
  • the number of bank cards to be verified is not limited, that is, the number of bank cards to be verified selected by the user may be multiple.
  • select one card to be verified that is, select one bank card to be verified for each of the two groups of bank cards to be bound.
  • mutual trust authentication between Bank A and Bank B can be understood as sending bank card information issued by Bank A, such as card number, password or account holder identity information, to Bank B for user identity verification, or The verification result of the bank A's information on the bank card issued by it is sent to the bank B as a verification certificate for the bank B to use for user identity verification.
  • the actual application does not limit whether the bank card to be verified belongs to the bank card to be bound, that is, the bank card to be verified may be a bank card other than the bank card to be bound. In this case, the bank card to be verified is only For verification, there is no need to issue the card application and the task data of the bank card to be verified, that is, the bank card to be verified need not be bound.
  • the terminal 100 can receive a trigger operation input by the user through the electronic wallet APP through the RF circuit 102.
  • the terminal displays at least two bank cards associated with the account currently registered by the electronic wallet APP through the display 104-2.
  • the terminal determines, by the processor 101, the bank card to be verified and the at least one bank card to be bound and the verification information of the bank card to be verified from the at least two bank cards.
  • the terminal controls the touch panel 104 through the processor 101 to obtain the verification information that the user determines the bank card to be verified from the at least two bank cards, and at least one bank card to be bound and the bank card to be verified input by the user.
  • the terminal 100 sends the verification information to the server through the RF circuit 102 to request the server to deliver the card application and personalization corresponding to each bank card to be bound to the terminal after verifying the verification according to the verification information.
  • the data is completed to bind the at least one bank card to be bound.
  • the bank card to be verified is bound according to the verification information of the bank card to be verified.
  • the specific implementation process is to determine a card to be verified and the bank card to be verified belongs to one of the bank cards to be bound as an example.
  • the electronic wallet server in response to the request of the terminal, the electronic wallet server first requests the bank server corresponding to the bank card to be verified to verify the bank card according to the verification information of the bank card to be verified, and generates a mutual trust certificate and automatically after the verification is passed.
  • the bank card to be verified is bound, and then the bank server corresponding to the other bank card to be bound is separately requested to automatically bind the remaining bank cards to be bound according to the mutual trust certificate.
  • the implementation specifically includes the following steps 301 to 310:
  • the terminal sends a first request to the electronic wallet server.
  • the first request carries the verification information of the bank card to be verified, and the verification information includes a bank name, a card number, a reserved mobile phone number, a withdrawal password, and a security problem setting, and the information is used to determine the bank to be verified. Whether the card is a legitimate card can be understood as determining whether the card holder is legal, that is, whether the terminal user is legal.
  • the first request is used to request verification of the verification information of the bank card to be verified and to issue the card application and personalization data of the bank card to be verified to complete the binding of the bank card to be verified.
  • the electronic wallet server sends a request to the first bank server.
  • the bank server corresponding to the bank card to be verified is described as the first bank server, and the bank server corresponding to the remaining bank card to be bound is described as the second bank server.
  • the electronic wallet server After receiving the first request of the terminal, the electronic wallet server sends a request to the first bank server according to the verification information of the bank card to be verified, where the request includes the verification information, and is used to request the first bank server. Verification is performed based on the verification information.
  • the identifier of the bank card to be verified is used to identify the bank to which the bank card to be verified belongs, that is, the first bank server.
  • the identifier of the bank card to be verified and the bank card to be bound may be the name of the bank to which the bank card belongs, the bank institution code or the bank service address, or the like, or other identifiers that can represent the card application or its corresponding bank, such as ISO.
  • the AID defined in 7816 which has a registered Application Provider Identifier (RID (which may indicate the card application provider, such as a banking institution), and a product identifier defined in the Chinese Financial IC Card Specification PBOC.
  • the product identification information has a bank identification code.
  • the terminal before the step 301, after determining the bank card to be verified and the bank card to be bound, the terminal directly sends the identifier of the bank card to be verified and the bank card to be bound to the electronic wallet server and is determined by the electronic wallet.
  • the server is saved locally.
  • the electronic wallet server can request the corresponding bank server to send the card application and personalized data corresponding to the bank card to be bound to the terminal according to the identifiers.
  • the electronic wallet server determines the first bank server according to the identifier of the locally saved bank card to be verified and sends a request to the first bank server.
  • the first request carries an identifier of the bank card to be verified.
  • the electronic wallet server may request the bank server corresponding to the bank card to be verified according to the identifier of the bank card to be verified in the first request.
  • the first request may carry the terminal identifier, the identifier of each bank card to be bound, and the account currently used to log in to the electronic wallet APP, in addition to the verification information of the bank card to be verified.
  • the first bank server verifies, according to the verification information, the card application and the personalized data corresponding to the bank card to be verified, and the personalized data carries the mutual trust certificate.
  • the card application can be downloaded and installed to a secure area (such as SE, TEE, etc.) of the terminal, and the personalized data includes a token of the card and a privacy related to the card application, such as a key. data.
  • the token can be understood as data of the card number of the physical card, and the role is similar to the real card number.
  • the first bank server first sends the card application of the bank card to be verified and the personalized data to the electronic wallet server, and is further sent by the electronic wallet server to the terminal.
  • the terminal can bind the bank card to be verified according to the card application and the personalized data of the bank card to be verified.
  • the first bank server directly sends the card application of the bank card to be verified and the personalized data to the terminal to complete binding the bank card to be verified by the terminal.
  • the terminal is addressed according to the terminal identifier forwarded by the electronic wallet server to directly send the card application and its personalized data to the terminal.
  • the mutual trust credential may be partial information in the personalized data, such as the token described above, or credential information specifically generated by the first bank server according to a request sent by the electronic wallet server or a mutual trust requirement flag carried in the request.
  • the mutual trust requirement flag can be understood as indicating that the current binding card needs to use the verification information of the to-be-verified card to complete binding of other bank cards.
  • the mutual trust credential is used in the process of binding the remaining bank cards to be bound, and the second bank server and the first bank server use the mutual trust credential to perform cross-line verification, so that after the inter-bank verification is passed, the second bank server The terminal sends the card application of the other bank card to be bound and its personalized data, as detailed in the following.
  • the terminal binds the to-be-verified bank card according to the card application and the personalized data corresponding to the bank card to be verified.
  • the terminal may register the NFC service with the system, and the NFC service may be an HCE service or a non-HCE service, thereby making the card application available or
  • the status of the user can be selected and activated and can be used after the user selects the activation.
  • the electronic wallet server can locally save the binding relationship between the account registered by the electronic wallet and the bank card to be verified, or save the binding relationship between the terminal, the registered electronic wallet account and the bank card to be verified.
  • the terminal After the binding of the bank card to be verified is completed, the terminal performs the following steps to further complete binding of the remaining bank cards to be bound.
  • the terminal sends a second request to the electronic wallet server.
  • the second request is used to request the electronic wallet server to send the card application and personalization data of the remaining bank cards to be bound.
  • the electronic wallet server sends a request to the second bank server.
  • the electronic wallet server After receiving the second request sent by the terminal, the electronic wallet server sends a request to the corresponding second bank server according to the identifiers of the remaining bank cards to be bound, and the request is used to request the second bank server to pass the verification according to the mutual trust certificate. After that, the card application and personalization data of the remaining bank cards to be bound are issued.
  • the identifiers of the remaining bank cards to be bound are used to identify the bank to which the bank card to be bound, other than the bank card to be verified, belongs, that is, the second bank server.
  • the identifiers of the remaining bank cards to be bound may be sent by the terminal before step 301.
  • the identifier of the remaining bank card to be bound may also be carried in the second request described in step 305.
  • the identifier of the bank card to be bound may also be carried in the first request in step 301 together with the identifier of the bank card to be verified.
  • the electronic wallet server carries the mutual trust certificate in a request sent to the second bank server.
  • the mutual trust certificate may be carried by the terminal to the electronic wallet server in the second request described in step 305, and further sent by the electronic wallet server to the second bank server.
  • the electronic wallet server in step 303, if the first bank server sends the mutual trust certificate to the terminal through the electronic wallet server, the electronic wallet server locally stores the mutual trust certificate, and the electronic wallet server can directly send the locally saved mutual trust certificate to the first Second bank server.
  • the request carries the terminal identifier, the account used to log in to the electronic wallet APP, and the identifier of the bank card to be verified (ie, the identifier of the first bank server).
  • the second bank server requests the first bank server to verify the mutual trust certificate according to the mutual trust certificate.
  • the second bank server determines the first bank server according to the identifier of the bank card to be verified.
  • the identifier of the bank card to be verified may be carried in the request described in step 306, or may be sent by the terminal to the second bank server.
  • the first bank server sends a verification success message to the second bank server.
  • the first bank server verifies the mutual trust certificate, and determines whether the mutual trust certificate is legal, such as determining whether the mutual trust certificate is identical to the mutual trust certificate generated by itself.
  • the first bank server may further determine whether the identifier of the second bank server is the same as the identifier of the second bank server sent by the electronic wallet server in the previous step 302, that is, the identifier of the remaining bank card to be bound.
  • the mutual trust certificate is encrypted, the mutual trust certificate is also decrypted.
  • the second bank server sends the corresponding card application and personalized data of the bank card to be bound to the terminal.
  • the terminal completes binding the remaining bank cards to be bound according to the card application and the personalized data delivered by the second bank server.
  • the transmission data may be encrypted.
  • the key of the bank to which the bank card to be verified belongs that is, the density of the first bank server may be used.
  • the key is to perform encryption processing on the verification information of the verification bank card, and accordingly, the first bank server decrypts the encrypted verification information and then performs verification.
  • the above steps 301 and 305 may be combined. That is, the terminal only sends a request to the electronic wallet server, and the request carries at least the verification information of the bank card to be verified. Optionally, the identifier of all the bank cards to be bound may also be carried. Then, after receiving the request, the electronic wallet server performs the foregoing steps 302, 303, 304, 306, 307, 308, 309, and 310 between the electronic wallet server, the first bank server, and the second bank server, and the specific process may refer to As mentioned above. In this implementation manner, after receiving the request from the terminal, the electronic wallet server first requests the first bank server to verify the bank card verification and issue the card application and personalized data of the bank card to be verified.
  • the electronic wallet server After determining the personalization of the first card application, the electronic wallet server directly parses the mutual trust certificate in the personalized data, and uses the mutual trust certificate to separately request the other second bank server to perform cross-line verification and the delivery card application and personalization data. To complete the binding further.
  • the terminal first requests the first bank server to verify the bank card through the electronic wallet server, and after the verification is passed, the corresponding card application and personalized data are sent by the first bank server.
  • the personalized data carries a mutual trust certificate.
  • the second bank server is further requested to perform cross-line verification on the mutual trust certificate according to the mutual trust certificate, and the card application and the personalized data of the remaining bank card to be bound are delivered by the second bank server after the verification is passed.
  • the user can input only the verification information of the bank card to be verified, and can complete binding all the bank cards to be bound according to the verification information.
  • the verification information of the bank card to be verified is separately sent to the bank server corresponding to all the bank cards to be bound (including the first bank server and the second bank server), and the bank card to be verified is Corresponding bank server, that is, the first bank server verifies the verification information and the bank server corresponding to the bank card to be bound except the bank to be verified, that is, each second bank server requests according to the verification information
  • a bank server performs cross-line verification, and after the verification is passed, the card application and personalized data of each bank card to be bound are respectively delivered. Referring to FIG. 4, the implementation includes the following steps 401 to 407:
  • the terminal sends a request to the electronic wallet server.
  • the request carries the verification information of the bank card to be verified.
  • the terminal encrypts the verification information of the verification bank card.
  • the encryption operation may be that the terminal encrypts the verification information once by using a bank server corresponding to the bank card to be verified, that is, a key of the first bank server, such as a public key or a symmetric key.
  • the request further carries an identifier of the terminal and an account used by the current login e-wallet APP.
  • the electronic wallet server sends a request to the first bank server and the second bank server, respectively.
  • the request carries the verification information of the bank card to be verified.
  • the electronic wallet server sends the verification information of the bank card to be verified to the first bank server and the second bank server according to the identifier of the bank card to be verified and the identifier of the remaining bank card to be bound.
  • the identifier of the bank card to be verified and the identifier of the remaining bank card to be bound may be sent before the step 401.
  • the terminal After determining the bank card to be verified and the bank card to be bound, the terminal directly sends the bank card to be verified to the electronic wallet server. And the identity of the bank card to be bound and saved locally by the electronic wallet server. It can also be carried in the request described in step 401. This embodiment of the present application does not limit this.
  • the electronic wallet server sends a request to the second bank server, in addition to carrying the verification information of the bank card to be verified, the identifier of the bank card to be verified or the identifier of the first bank server is carried, so that the second bank server can find the request.
  • the first bank server performs a cross-line verification operation.
  • the electronic wallet server may further encrypt the verification information before sending the request to the second bank server (if the encryption is performed once in step 401, the electronic wallet server may perform secondary encryption), that is, respectively The verification information is encrypted using the key of the second bank server to ensure the security of the data transmission.
  • the request may further carry an identifier of the terminal and an account used by the current login to the electronic wallet APP.
  • the first bank server verifies the bank card to be verified according to the verification information of the bank card to be verified, and sends the card application and the personalized data of the bank card to be verified to the terminal after the verification is passed.
  • step 303 For the specific implementation of this step, refer to step 303, and details are not described herein again.
  • the terminal binds the to-be-verified bank card according to the card application and the personalized data corresponding to the bank card to be verified.
  • step 304 For the specific implementation of this step, refer to step 304, and details are not described herein again.
  • the second bank server requests the first bank server to verify the verification information according to the verification information of the bank card to be verified.
  • the second bank server may directly send the verification information of the bank card to be verified sent by the electronic wallet server to the first bank server.
  • it can also be encrypted and sent to the first bank server.
  • the private key or symmetric key of the second bank server for encryption it may be necessary to save the public key of the second bank server at the first bank server or Symmetric keys, which can be the banks participating in the cooperation (can be understood as the cooperation between the two parties to support the cross-line verification described in the embodiment of the present application, that is, the verification result of a certain bank can be trusted by other banks). Key, etc.
  • the request sent by the electronic wallet server to the first bank server may further carry the identifier of the other bank card to be bound or the identifier of the second bank server.
  • the first bank server can verify the verification information and can also verify the second bank server. If the first bank server receives a request from a second bank server, verifying whether the second bank server is legal according to the received identity of the bank card to be bound or the identity of the second bank server: if the second bank server The identifier belongs to the second bank server indicated by the identifier of the bank card to be bound received in step 402 or the identifier of the second bank server that has been received in step 402, and then confirms that the second bank server is legal, otherwise it is illegal. .
  • the first bank server sends a verification success message to the second bank server.
  • the second bank server After receiving the verification success message returned by the first bank server, the second bank server sends the application of the bank card to be bound and the personalized data to the terminal.
  • the terminal completes binding the remaining bank cards to be bound according to the card application and the personalized data delivered by the second bank server.
  • the implementation process of binding the to-be-verified bank card described in the foregoing steps 403 and 404 and the implementation of binding the remaining bank cards to be bound as described in steps 405, 406, 407, and 408 are not limited. The order between the processes. These two implementations may be performed simultaneously or sequentially.
  • the electronic wallet server sends the verification information of the bank card to be verified to each second bank server in addition to the first bank server.
  • the first bank server can directly issue the card application and personalization data after the verification information is successfully verified.
  • the second bank server can issue the corresponding card application and personalized data after the verification of the verification information by the first bank server.
  • the first bank server is requested to verify the mutual trust certificate, and steps 405 and 406 in the embodiment shown in FIG.
  • the illustrated second bank server requests the first bank server to verify the verification information, and may also be implemented in other manners.
  • the second bank servers respectively request the first bank server to access the information through an intermediate third party trusted server.
  • these intermediate third-party trusted servers can be a party that works with all of these banks, such as UnionPay or other service providers.
  • the electronic wallet server sends the verification information of the bank card to be verified to the third-party trusted server, and the third-party trusted server requests the first bank server corresponding to the bank card to be verified to verify the verification information successfully.
  • the second bank server corresponding to the other bank card to be bound is separately requested to perform the card binding operation.
  • the third-party trusted server described in this embodiment of the present application can be operated and managed by the electronic wallet service provider. In this case, it can be understood that the third-party trusted server and the above-mentioned electronic wallet server are only divided into logical functions. A distinction was made.
  • third-party trusted servers can also be operated and managed by an independent third party, such as financial institutions such as banks or UnionPay, or third-party payment service providers such as Alipay. Referring to FIG. 5, the implementation includes the following steps 501 to 508:
  • the terminal sends a request to the electronic wallet server.
  • step 401 This step can be referred to step 401, and details are not described herein again.
  • the electronic wallet server sends a request to a third-party trusted server.
  • the request includes the verification information of the bank card to be verified and the identifier of each bank card to be bound or the identifier of the bank to which it belongs or the identifier of the bank server.
  • the request may further include a terminal identifier and an account used by the current login e-wallet APP.
  • the third-party trusted server sends a request to the first bank server.
  • the request carries the verification information of the bank card to be verified, and is used to request the first bank server to verify the verification information, and after the verification is successful, issue the card application and the personalized data of the bank card to be verified.
  • the first bank server sends the card application and the personalized data of the bank card to be verified to the third-party trusted server after the verification of the verification information of the bank card to be verified is successful.
  • step 303 For the specific implementation of this step, refer to step 303, and details are not described herein again.
  • the third-party trusted server sends a request to the second bank server.
  • the third-party trusted server After receiving the card application and personalization data of the bank card to be verified sent by the first bank server, the third-party trusted server indicates that the first bank server has verified the verification information of the bank card to be verified, or the third-party trusted server receives After the verification result sent by the first bank server is passed, it is determined that the first bank server has verified the verification information of the bank card to be verified. Then, the third-party trusted server may further request each second bank server to deliver the card application and personalized data of the remaining bank cards to be bound, that is, perform the following step 506.
  • the request may carry the terminal identifier and the account used by the current e-wallet APP, and the request may further carry the verification pass result, where the request is used to request the second bank server to deliver the corresponding bank to be bound. Card application and personalization data.
  • the personalization data sent by the first bank server to the third-party trusted server further carries the mutual trust certificate in step 504, or the first bank server sends the verification result to the third-party trusted server, Carrying the mutual trust certificate, then the request sent in the step 505 also carries the mutual trust certificate.
  • the second bank server may send the mutual trust certificate to the first bank server and perform the following step 506 after the first bank server passes the mutual trust certificate.
  • the second bank server sends the card application and personalized data of the bank card to be bound to the third-party trusted server.
  • the third-party trusted server sends the card application and personalization data of the bank card to be verified and the remaining bank cards to be bound to the terminal.
  • the terminal completes binding each bank card to be bound according to the card application and the personalized data of each bank card to be bound.
  • the first bank server or the second bank server may directly send the card application and the personalized data to the electronic wallet server and further send the terminal to the terminal by the electronic wallet server.
  • the first bank server or the second bank server directly sends the card application and the personalized data to the terminal.
  • the third-party trusted server simultaneously delivers the card application and the personalized data to the terminal through the electronic wallet server.
  • the third-party trusted server may send the card application and personalized data of the bank card to be verified after step 504, and then issue the card application and personalization of the bank card to be bound after step 506. data.
  • the third party trusted server interacts with the first bank server and the second bank server respectively to complete binding the respective bank cards to be bound.
  • the card application is delivered to the terminal by the corresponding bank server after the user identity verification is passed.
  • the electronic wallet APP may also directly use the bank server corresponding to each bank card determined by the electronic wallet server. Download the card application and register the card application one by one to the system. Then, when the downloaded card application is personalized after determining the bank card to be verified and the bank card to be bound, only the card application for verifying the bank card and the bank card to be bound is personalized.
  • the e-wallet server may request the respective bank server to verify the verification information of the bank card to be verified by using the electronic wallet server, and then deliver the corresponding personalized data.
  • the debit from the corresponding account can be implemented in any of the following ways: (1) Associate all the bound card applications with the account of the bank card to be verified, that is, the user's subsequent credit card consumption is the account from the bank card to be verified. Deductions are made in the middle. (2) Associate each bound card application with a bank card account that the user has previously opened at the bank to which the card application belongs, that is, the user subsequently swipes the card account from the bank card account opened by the bank to which the card application belongs. The deduction is made in the middle.
  • the card application of the Merchants Bank is bound to the terminal. If the terminal has previously opened an account at the China Merchants Bank, the card application of the China Merchants Bank is established and the card is opened. The relationship between the China Merchants Bank accounts. Subsequent to the NFC payment using the China Merchants Bank card application that has been bound to the terminal, the bank account is debited from the opened China Merchant Bank account. (3) Associate each of the bound card applications with the bank account to which the card application belongs in this online card for the newly opened card account, and the card account can be associated with the account of the bank card to be verified.
  • the association is performed to allow the user to transfer the account of the card to be verified to the account of the card, and the user subsequently swipes the card.
  • the server of CITIC Bank opens the CITIC bank card application through an online mode (different from the current face-to-face account opening method).
  • a corresponding account the server of China Merchants Bank opened a corresponding account for the investment bank card application through online mode, and the user can subsequently transfer the account from the account of the bank card to be verified (such as the bank card of the Bank of China) by transfer.
  • the transfer is made in the two accounts, so that the user can deduct the fee from the corresponding account when using the card application of the CITIC Bank, and the card can be deducted from the corresponding account when using the card application of the China Merchants Bank.
  • the method shown in the method provided by the embodiment of the present application may be extended to be applied in a scenario in which payment is performed using a two-dimensional code.
  • the two-dimensional code payment function of the electronic wallet it only supports the bound bank card to generate its corresponding two-dimensional code.
  • the bank card A can be Generate your own QR code for verification by your own server.
  • Bank B can generate its own QR code for verification by its own server.
  • QR code to pay different stores may have different promotions for different bank cards. In order to enjoy the preferential needs offered by each bank, users need to bind as many bank cards as possible.
  • the user only needs to bind one bank card, and then uses the information of the bound bank card to request the two-dimensional code or data necessary for generating the two-dimensional code from other banks. (such as key seed, etc.).
  • the solution provided by the embodiment of the present application is specifically as follows: (1) determining the bank card most suitable for the payment, such as the bank with the most preferential payment.
  • the bank with the strongest offer is recommended according to the current location information of the terminal, or the bank with the strongest offer is recommended according to the information of the store where the user is currently located, or determined by other means.
  • the server of the determined bank verifies the two-dimensional code that is sent to the terminal or the related data necessary for generating the two-dimensional code, such as the two-dimensional code key seed, according to the verification information of the bank card to be verified,
  • the verification process can refer to the implementation shown in FIG.
  • the terminal may generate a corresponding two-dimensional code according to the received related data.
  • the user can complete the payment according to the two-dimensional code, such as the user presenting the two-dimensional code to the merchant for the merchant to scan the code to complete the deduction.
  • the solution provided by the embodiment of the present application is mainly introduced from the perspective of how the terminal and the electronic wallet server complete the card binding process. It can be understood that, in order to implement the above functions, the terminal and the electronic wallet server include corresponding functional modules for performing respective functions.
  • the present application can be implemented in a combination of hardware or hardware and computer software, in conjunction with the examples and steps described in the embodiments disclosed herein. Whether a function is implemented in hardware or computer software to drive hardware depends on the specific application and design constraints of the solution. A person skilled in the art can use different methods to implement the described functions for each particular application, but such implementation should not be considered to be beyond the scope of the present application.
  • the terminal and the electronic wallet server may also be divided according to the above method example.
  • each module or unit may be divided according to each function, or two or more functions may be integrated into one processing module.
  • the above integrated modules can be implemented in the form of hardware or in the form of software modules or units.
  • the division of modules or units in the embodiments of the present application is schematic, and is only a logical function division, and may be further divided in actual implementation.
  • FIG. 6 is a schematic diagram showing a possible structure of a terminal involved in the above embodiment.
  • the terminal 600 includes a storage unit 601, a processing unit 602, a display unit 603, an input unit 604, and a communication unit 605.
  • the storage unit 601 is configured to store one or more program codes.
  • the processing unit 602 is configured to execute the program code stored by the storage unit 601 to perform steps 304, 310 in FIG. 3, step 408 in FIG. 4, step 508 in FIG. 5, and/or other processes for the techniques described herein.
  • the display unit 603 is for displaying the interface shown in FIGS. 2A to 2F.
  • the input unit 604 is configured to implement user interaction with the electronic device and/or information input into the terminal. For example, the input unit can receive numeric or character information entered by the user to generate signal inputs related to user settings or function controls.
  • the input unit 604 is for receiving an input operation of the user in the interface shown in FIGS. 2A to 2F.
  • the communication unit 605 is used for the terminal 600 to communicate with other devices, such as the support terminal performing steps 301, 303, 305, 309 in FIG. 3, steps 401, 403, 407 in FIG. 4, steps 501, 507 and / in FIG. Or for other processes described herein.
  • the terminal 600 includes, but is not limited to, the unit modules listed above, and the functions that can be implemented by the foregoing units include, but are not limited to, the functions corresponding to the method steps described in the foregoing embodiments. Reference is made to the detailed description of the corresponding method steps, and details are not described herein again.
  • the storage unit 601 can be implemented in the memory 103 in the terminal 100, and the processing unit 602 can be implemented in the processor 101 in the terminal 100.
  • the display unit 603 can be implemented in the display 104 in the terminal 100.
  • the communication unit 604 can be implemented in the radio frequency circuit 102 in the terminal 100.
  • the input unit 604 can be implemented in the touch panel 104-1 of the terminal 100.
  • the input unit 604 can also be other human-computer interaction interfaces, such as physical input keys, microphones, and the like.
  • other external information capture devices such as one or more of a camera, a microphone, a physical keyboard, function keys, a trackball, a mouse, a joystick, and the like.
  • FIG. 7 is a schematic diagram showing a possible structure of an electronic wallet server involved in the above embodiment.
  • the electronic wallet server 700 includes a storage unit 701, a processing unit 702, and a communication unit 703.
  • the storage unit 701 is configured to store one or more program codes.
  • the processing unit 702 is configured to execute the program code stored by the storage unit 701 to perform at least two bank cards to determine the terminal to be displayed, and other processes of the techniques described herein.
  • the communication unit 703 is used for the electronic wallet server 700 to communicate with other devices, such as supporting the electronic wallet server to perform steps 301, 302, 303, 305, 306, 309 in FIG. 3, steps 401, 402, 403, 407 in FIG. Steps 501, 502, 507 in Figure 5 and/or for other processes described herein.
  • the electronic wallet server 700 includes, but is not limited to, the unit modules listed above, and the functions that can be implemented by the above units include, but are not limited to, the functions corresponding to the method steps described in the foregoing embodiments, and each of the electronic wallet servers 700
  • the unit modules listed above include, but are not limited to, the functions corresponding to the method steps described in the foregoing embodiments, and each of the electronic wallet servers 700
  • the electronic wallet servers 700 For a detailed description of the unit, reference may be made to the detailed description of the corresponding method steps, and details are not described herein again.
  • the storage unit 701 may be a memory 801 in the electronic wallet server 800, and the memory 801 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as Read only memory, flash memory, hard disk or solid state hard disk; the memory may also include a combination of the above types of memory.
  • a volatile memory such as a random access memory
  • the memory may also include a non-volatile memory, such as Read only memory, flash memory, hard disk or solid state hard disk
  • the memory may also include a combination of the above types of memory.
  • Processing unit 702 can be a controller or processor 802 in the electronic wallet server 800 that can implement or perform various exemplary logical blocks, modules, and circuits described in connection with the present disclosure.
  • the processor or controller can be a central processing unit, a general purpose processor, a digital signal processor, an application specific integrated circuit, a field programmable gate array or other programmable logic device, a transistor logic device, a hardware component, or any combination thereof. It is possible to implement or carry out the various illustrative logical blocks, modules and circuits described in connection with the present disclosure.
  • the processor may also be a combination of computing functions, for example, including one or more microprocessor combinations and the like.
  • the communication unit 703 may be a transceiver in the base station, a transceiver circuit or a communication interface 803, or the like.
  • the electronic wallet server 800 also includes a bus 804, which may be an Extended Industry Standard Architecture (EISA) bus or the like.
  • the bus 804 can be divided into an address bus, a data bus, a control bus, and the like. For ease of representation, only one thick line is shown in Figure 8, but it does not mean that there is only one bus or one type of bus.
  • the disclosed apparatus and method may be implemented in other manners.
  • the device embodiments described above are merely illustrative.
  • the division of the modules or units is only a logical function division.
  • there may be another division manner for example, multiple units or components may be used. Combinations can be integrated into another system, or some features can be ignored or not executed.
  • the coupling or direct coupling or communication connection of the various units to each other may be an indirect coupling or communication connection through some interface, device or unit, and may be in electrical, mechanical or other form.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of the embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the above integrated unit can be implemented in the form of hardware or in the form of a software functional unit.
  • the integrated unit if implemented in the form of a software functional unit and sold or used as a standalone product, may be stored in a computer readable storage medium.
  • a computer readable storage medium A number of instructions are included to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to perform all or part of the steps of the methods described in various embodiments of the present application.
  • the foregoing storage medium includes: a flash memory, a mobile hard disk, a read only memory, a random access memory, a magnetic disk, or an optical disk, and the like, which can store program codes.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本申请实施例公开一种绑卡方法及终端，涉及移动支付技术领域。为了解决现有技术中存在的用户在首次绑卡或更换终端后绑卡过程中操作均比较繁琐，绑卡效率较低的问题而发明。本申请实施例公开的绑卡方法，应用于终端，该方法包括：显示第一界面，该第一界面显示有与电子钱包APP当前登录的账号关联的至少两个银行卡。从该至少两个银行卡中确定待验证银行卡以及至少一个待绑定银行卡。显示第二界面，该第二界面用于提示用户输入待验证银行卡的验证信息。向服务器发送该验证信息以请求服务器在根据所述验证信息验证通过后向所述终端下发每个待绑定银行卡对应的卡应用及个人化数据以完成绑定所述至少一个待绑定银行卡。

Description

绑卡方法及终端
本申请要求于2018年1月8日提交中国专利局、申请号为201810016329.5、申请名称为“绑卡方法及终端”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及移动支付技术领域，尤其涉及一种绑卡方法及终端。
背景技术
移动支付已广泛普及。用户可通过手机等终端上安装的应用程序(application，APP)进行支付。常见的移动支付类APP(或者：电子钱包APP)包括各个手机厂商推出的电子钱包类应用，如华为钱包、Apple PAY等，银行等金融机构推出的手机银行客户端等以及第三方支付服务商推出的微信支付、支付宝等第三方支付应用。
目前，用户在电子钱包上注册账户信息后，在电子钱包中添加并绑定银行卡。之后，用户可使用电子钱包完成支付。一些电子钱包支持线上支付和线下支付两种支付方式，如华为钱包、银联钱包、移动和包等。其中，线上支付主要针对网上购物场景，如网页支付、应用内支付(in-app payment)。终端在联网的状态下，用户可使用电子钱包APP中绑定的银行卡进行支付；当然，若终端未联网，只要商户侧收款终端能够联网，也可以使用电子钱包APP中绑定的银行卡进行支付，如二维码支付。线下支付主要针对销售点(Point of Sale，POS)终端刷卡场景。对于支持NFC功能的终端，即使在终端未联网的状态下，用户只要登录电子钱包APP，便可使用该电子钱包APP中绑定的银行卡完成支付，即将手机模拟成银行卡进行支付。
对于线下支付的支付方式，目前在绑定银行卡时，需要为每张银行卡分别下载对应的卡应用到终端，并针对每张要绑定的银行卡要求用户执行“输入卡号、手机号、卡支付密码，设置钱包支付密码、安保问题”等一系列输入信息的操作，然后完成每个卡应用的个人化以完成绑定。这些卡应用及其对应的个人化数据在终端本地保存，因此，如果更换了终端，则用户在更换后的终端上使用原来注册的账户登录电子钱包后，需要重新绑卡，也即需要逐个重新下载卡应用，逐个重新执行上述一系列输入信息的操作。如此，用户在首次绑卡或更换终端后绑卡过程中操作均比较繁琐，绑卡效率较低。
发明内容
本申请实施例公开一种绑卡方法及终端，以解决现有技术中存在的使用终端NFC支付时绑卡效率较低的问题。
为达到上述目的，本申请实施例提供的方案包括：
第一方面，提供一种绑卡方法，应用于终端。该方法包括：终端显示第一界面，该第一界面显示有与电子钱包APP当前登录的账号关联的至少两个银行卡。之后，终端从该至少两个银行卡中确定待验证银行卡以及至少一个待绑定银行卡。接着，终端显示第二界面，该第二界面用于提示用户输入待验证银行卡的验证信息。最后，终端 向服务器发送所述验证信息以请求服务器在根据该验证信息验证通过后向终端下发每个待绑定银行卡对应的卡应用及个人化数据以完成绑定所述至少一个待绑定银行卡。
可选的，所述待验证银行卡为所述至少一个待绑定银行卡中的其中一个或多个。
通过上述方法，用户在确定了待绑定银行卡和待验证银行卡后，只需要输入待验证银行卡的验证信息便可完成绑定所有待绑定银行卡，能够实现通过一张(或少数几张)银行卡的验证信息进行验证通过后绑定所有(或描述为多数几张)待绑定银行卡。
在一种可能的设计中，触发用户显示第一界面的操作包括：在显示第一界面之前终端接收的用户通过电子钱包APP输入的触发操作。例如，用户在所述电子钱包APP的登录界面输入的登录操作，或者，用户成功登录电子钱包APP后，通过预设入口输入的添加待绑定银行卡的操作。
在一种可能的设计中，终端从所述至少两个银行卡中确定待验证银行卡以及至少一个待绑定银行卡，可实现为：终端根据用户的选择操作从所述至少两个银行卡中确定所述待验证银行卡以及所述至少一个待绑定银行卡。还可实现为：终端按照预设规则从所述至少两个银行卡中确定待验证银行卡以及所述至少一个待绑定银行卡。例如：该预设规则包括：将历史使用次数大于预设阈值的银行卡确定为待验证银行卡或将已显示的所述至少两个银行卡中任意一张确定为待验证银行卡。
在一种可能的设计中，在绑定银行卡的过程中，显示每个待绑定银行卡对应的卡应用的安装进度。
在一种可能的设计中，终端在显示与所述电子钱包APP当前登录的账号关联的至少两个银行卡之前，终端确定与所述电子钱包APP当前登录的账号关联的所述至少两个银行卡，具体可实现为：终端获取与所述账号关联的第一历史绑卡记录，如果还获取到与所述账号关联的第二历史绑卡记录，则将不包含在该第二历史绑卡记录但包含在所述第一历史绑卡记录中的卡应用的标识对应的银行卡确定为所述至少两个银行卡。如果未获取到所述第二历史绑卡记录，则将第一历史绑卡记录中的卡应用的标识对应的银行卡确定为所述至少两个银行卡。其中，所述第一历史绑卡记录中包括与所述账号关联的所有卡应用的标识，例如：在其他终端上登录该账号时绑定的银行卡的卡应用的标识，或者已解绑的银行卡的卡应用的标识。该第一历史绑卡记录可由终端从所述服务器获取得到。所述第二历史绑卡记录中包括所述账号在所述终端上登录时绑定的卡应用的标识。该第二历史绑卡记录可由终端查找本地保存的列表得到，当然，该列表中保存有所述账号在该当前终端上登录时绑定的卡应用的标识。当然，该第二历史绑卡记录也可由终端从服务器获取得到。
在一种可能的设计中，所述确定与所述电子钱包APP当前登录的账号关联的所述至少两个银行卡，还可实现为：终端接收服务器发送的第三历史绑卡记录，该第三历史绑卡记录中包括与所述账号关联且所述终端本地未绑定的卡应用的标识。进而，终端可将该第三历史绑卡记录中的卡应用的标识对应的银行卡确定为所述至少两个银行卡。
在一种可能的设计中，所述确定与所述电子钱包APP当前登录的账号关联的至少两个银行卡，还可实现为：终端将电子钱包APP所支持的所有银行卡确定为与所述电子钱包APP当前登录的账号关联的所述至少两个银行卡。
在一种可能的设计中，终端在确定待验证银行卡以及至少一个待绑定银行卡之后 还要向电子钱包服务器发送所述至少一个待绑定银行卡和待验证银行卡的标识以便于所述电子钱包服务器根据所述至少一个待绑定银行卡的标识和待验证银行卡的标识请求银行服务器进行验证并向终端下发待绑定银行卡对应的卡应用及个人化数据。
为便于描述，将所述待验证银行卡对应的银行服务器描述为第一银行服务器，将任意一个所述待绑定银行卡对应的银行服务器描述为第二银行服务器。
在一种可能的设计中，终端向服务器发送验证信息以请求服务器在根据验证信息验证通过后向终端下发每个所述待绑定银行卡对应的卡应用及个人化数据，包括：终端向电子钱包服务器发送第一请求以便于该电子钱包服务器请求第一银行服务器对所述验证信息验证通过后向终端下发所述待验证银行卡对应的卡应用及个人化数据。其中，该第一请求中携带所述验证信息，所述个人化数据中携带互信凭证。在接收所述待验证银行卡对应的卡应用及个人化数据后，终端接着向电子钱包服务器发送第二请求以便于电子钱包服务器请求第二银行服务器与第一银行服务器之间对所述互信凭证验证通过后向终端下发所述待绑定银行卡对应的卡应用及个人化数据。其中，该第二请求中携带所述互信凭证。
在一种可能的设计中，终端向服务器发送验证信息以请求服务器在根据所述验证信息验证通过后向终端下发每个所述待绑定银行卡对应的卡应用及个人化数据，包括：终端向电子钱包服务器发送请求，该请求中携带所述待验证银行卡的验证信息，以便于电子钱包服务器分别请求第一银行服务器和第二银行服务器在根据验证信息验证通过后由所述第一银行服务器向所述终端下发所述待验证银行卡对应的卡应用和个人化数据以及由所述第二银行服务器向所述终端下发所述待绑定银行卡对应的卡应用和个人化数据。
在一种可能的设计中，终端向服务器发送验证信息以请求服务器在根据该验证信息验证通过后向终端下发每个所述待绑定银行卡对应的卡应用及个人化数据，包括：终端向电子钱包服务器发送请求，该请求中携带所述待验证银行卡的验证信息，以便于电子钱包服务器通过第三方可信服务器分别请求第一银行服务器和第二银行服务器在根据所述验证信息验证通过后分别向所述终端下发每个所述待绑定银行卡对应的卡应用和个人化数据。
在一种可能的设计中，上述请求中携带的所述验证信息为加密后的验证信息。
第二方面，提供一种绑卡方法，应用于终端，该方法包括：终端显示第一界面，该第一界面显示有与电子钱包APP当前登录的账号关联的至少两张银行卡以及每张银行卡对应的曾绑定所述银行卡的终端的标识。
通过该实现方式，如果存在与当前登录的电子钱包APP账号相关的历史绑卡信息，例如：用户在其他终端上登录该账号时，绑定的银行卡。那么，终端向用户提示该历史信息，也即终端显示其他终端的标识以及在该其他终端上登录当前账号时绑定的银行卡。
在一种可能的设计中，所述第一界面上还显示有当前终端的标识及在当前终端上已绑定的银行卡。
在一种可能的设计中，终端在显示所述第一界面之后，从所述至少两个银行卡中确定待验证银行卡以及至少一个待绑定银行卡；终端显示第二界面，该第二界面用于提示用户输入待验证银行卡的验证信息；终端向服务器发送所述验证信息以请求服务 器在根据该验证信息验证通过后向终端下发每个待绑定银行卡对应的卡应用及个人化数据以完成绑定所述至少一个待绑定银行卡。
当然，终端从所述至少两个银行卡中确定待验证银行卡以及至少一个待绑定银行卡、终端显示第二界面以及终端向服务器发送所述验证信息以请求服务器在根据该验证信息验证通过后向终端下发每个待绑定银行卡对应的卡应用及个人化数据以完成绑定所述至少一个待绑定银行卡的具体实现可参考第一方面的可能设计方式，此处不再赘述。
在一种可能的设计中，终端在显示所述第一界面之前，显示第二界面，所述第二界面用于提示用户输入待验证银行卡的验证信息。相应的，在终端显示所述第一界面后，终端从所述至少两个银行卡中确定至少一个待绑定银行卡；终端向服务器发送所述待验证银行卡的验证信息以请求服务器根据该验证信息验证通过后向终端下发每个待绑定银行卡对应的卡应用及个人化数据以完成绑定所述至少一个待绑定银行卡。
也即，该实现方式可理解为：终端先显示第二界面用于提示用户输入待验证银行卡的验证信息，之后，再显示第一界面用于显示至少两张银行卡，以便于用户可从该至少两张银行卡中进一步确定待绑定银行卡。之后，终端再向服务器发送该验证信息以请求服务器根据该验证信息验证通过后向终端下发每个待绑定银行卡对应的卡应用及个人化数据以完成绑定所述至少一个待绑定银行卡。可见，该实现方式仍然可实现用户只需要输入待验证银行卡的验证信息便可完成绑定所有待绑定银行卡，能够实现通过一张(或少数几张)银行卡的验证信息进行验证通过后绑定所有(或描述为多数几张)待绑定银行卡。
同样的，终端从所述至少两个银行卡中确定待绑定银行卡、终端显示第二界面以及终端向服务器发送所述验证信息以请求服务器在根据该验证信息验证通过后向终端下发每个待绑定银行卡对应的卡应用及个人化数据以完成绑定所述至少一个待绑定银行卡的具体实现可参考第一方面的可能设计方式，此处不再赘述。
为便于描述，将所述待验证银行卡对应的银行服务器描述为第一银行服务器，将任意一个所述待绑定银行卡对应的银行服务器描述为第二银行服务器。
第三方面，提供一种绑卡方法，应用于电子钱包服务器，该方法包括：电子钱包服务器接收终端发送的至少一个待绑定银行卡的标识和待验证银行卡的验证信息，根据所述验证信息和所述至少一个待绑定银行卡的标识请求银行服务器在对该验证信息验证通过后向所述终端下发每个待绑定银行卡对应的卡应用及个人化数据。
在一种可能的设计中，电子钱包服务器在接收终端发送的至少一个待绑定银行卡的标识和待验证银行卡的验证信息之前，向所述终端推送第一历史绑卡记录，该第一历史绑卡记录中包括与电子钱包APP当前登录的账号关联的所有卡应用的标识。
在一种可能的设计中，与电子钱包APP当前登录的账号关联的所有卡应用的标识包括用户在所有终端上的电子钱包APP上登录当前账号时绑定的卡应用的标识。
在一种可能的设计中，与电子钱包APP当前登录的账号关联的所有卡应用的标识还包括与所述账号关联但已解绑的卡应用的标识。
在一种可能的设计中，电子钱包服务器在接收终端发送的至少一个待绑定银行卡的标识和待验证银行卡的验证信息之前，向终端发送第二历史绑卡记录，该第二历史绑卡记录中包括所述账号在所述终端上的电子钱包APP中登录时绑定的卡应用的标 识。
在一种可能的设计中，电子钱包服务器在接收终端发送的至少一个待绑定银行卡的标识和待验证银行卡的验证信息之前，向终端推送第三历史绑卡记录，该第三历史绑卡记录中包括与所述账号关联且在所述终端本地未绑定的卡应用的标识，或者，所述电子钱包APP支持的所有卡应用的标识。
在一种可能的设计中，电子钱包服务器向终端推送第一历史绑卡记录或第二历史绑卡记录或第三历史绑卡记录可具体实现为：电子钱包服务器接收终端的查询请求，响应于该查询请求，向终端推送历史绑卡记录。或者，电子钱包服务器监听到在所述电子钱包APP上登录所述账号的操作后，电子钱包服务器向终端推送所述历史绑卡记录。
在一种可能的设计中，电子钱包服务器根据所述验证信息和所述至少一个待绑定银行卡的标识请求银行服务器在对所述验证信息验证通过后向所述终端下发每个待绑定银行卡对应的卡应用及个人化数据，包括：电子钱包服务器根据所述至少一个待绑定银行卡的标识分别请求所述第一银行服务器和所述第二银行服务器根据所述验证信息验证通过后由所述第一银行服务器向所述终端下发待验证银行卡对应的卡应用和个人化数据以及由所述第二银行服务器向所述终端下发待绑定银行卡对应的卡应用和个人化数据。
在一种可能的设计中，电子钱包服务器根据所述验证信息和所述至少一个待绑定银行卡的标识请求银行服务器在对所述验证信息验证通过后向所述终端下发每个待绑定银行卡对应的卡应用及个人化数据，包括：电子钱包服务器向所述第一银行服务器发送第一请求，所述第一请求包括所述验证信息，用于请求所述第一银行服务器根据所述验证信息验证通过后下发待验证银行卡对应的卡应用及个人化数据，所述个人化数据中携带互信凭证；在接收到所述互信凭证后，根据所述待绑定银行卡的标识向第二银行服务器发送第二请求，所述第二请求包括所述互信凭证和所述待验证银行卡的标识，以使所述第二银行服务器在根据所述待验证银行卡的标识请求所述第一银行服务器对所述互信凭证验证通过后向所述终端下发所述待绑定银行卡对应的卡应用及个人化数据。
在一种可能的设计中，电子钱包服务器根据所述验证信息和所述至少一个待绑定银行卡的标识请求银行服务器在对所述验证信息验证通过后向所述终端下发每个待绑定银行卡对应的卡应用及个人化数据，包括：电子钱包服务器向第三方可信服务器发送第三请求，所述第三请求中包括所述验证信息和所述至少一个待绑定银行卡的标识，以使所述第三方可信服务器请求所述第一银行服务器根据所述验证信息验证通过后向所述终端下发所述待验证银行卡对应的卡应用及个人化数据，其中所述个人化数据包括互信凭证；以及使所述第三方可信服务器根据所述至少一个待绑定银行卡的标识请求所述第二银行服务器根据所述互信凭证验证通过后向所述终端下发所述待绑定银行卡对应的卡应用及个人化数据。
第四方面，提供一种终端，包括：显示单元，用于显示第一界面，所述第一界面显示有与所述电子钱包APP当前登录的账号关联的至少两个银行卡。处理单元，用于从所述至少两个银行卡中确定待验证银行卡以及至少一个待绑定银行卡。所述显示单元，还用于显示第二界面，所述第二界面用于提示用户输入所述待验证银行卡的验证 信息。发送单元，用于向服务器发送所述验证信息以请求服务器在根据所述验证信息验证通过后向所述终端下发每个所述待绑定银行卡对应的卡应用及个人化数据以完成绑定所述至少一个待绑定银行卡。
在一种可能的设计中，所述终端还包括：接收单元，用于接收用户通过电子钱包APP输入的触发操作，其中，所述触发操作包括：用户在所述电子钱包APP的登录界面输入的登录操作；或者，用户成功登录所述电子钱包APP后，通过预设入口输入的添加待绑定银行卡的操作。
在一种可能的设计中，所述处理单元，还用于根据用户的选择操作从所述至少两个银行卡中确定所述待验证银行卡以及所述至少一个待绑定银行卡，或者，按照预设规则从所述至少两个银行卡中确定所述待验证银行卡以及所述至少一个待绑定银行卡。所述预设规则包括：将历史使用次数大于预设阈值的银行卡确定为待验证银行卡或将其中任意一张确定为待验证银行卡。
在一种可能设计中，所述显示单元，还用于显示每个所述待绑定银行卡对应的卡应用的安装进度。
在一种可能的设计中，所述待验证银行卡为所述至少一个待绑定银行卡中的其中一个或多个。
在一种可能的设计中，所述处理单元，还用于确定与所述电子钱包APP当前登录的账号关联的所述至少两个银行卡。
在一种可能设计中，所述处理单元，还用于获取与所述账号关联的第一历史绑卡记录，如果获取到与所述账号关联的第二历史绑卡记录，则将不包含在所述第二历史绑卡记录但包含在所述第一历史绑卡记录中的卡应用的标识对应的银行卡确定为所述至少两个银行卡；或者，如果未获取到所述第二历史绑卡记录，则将所述第一历史绑卡记录中的卡应用的标识对应的银行卡确定为所述至少两个银行卡。其中，所述第一历史绑卡记录中包括与所述账号关联的所有卡应用的标识；所述第二历史绑卡记录中包括所述账号在所述终端上登录时绑定的卡应用的标识。
在一种可能的设计中，所述处理单元，还用于从所述服务器获取所述第一历史绑卡记录。
在一种可能的设计中，所述处理单元，还用于查找本地保存的列表得到所述第二历史绑卡记录；其中，所述列表中保存有所述账号在所述终端上登录时绑定的卡应用的标识，或者从所述服务器获取所述第二历史绑卡记录。
在一种可能的设计中，所述接收单元，还用于接收所述服务器发送的第三历史绑卡记录；所述第三历史绑卡记录中包括与所述账号关联且所述终端本地未绑定的卡应用的标识。所述处理单元，还用于将所述第三历史绑卡记录中的卡应用的标识对应的银行卡确定为所述至少两个银行卡。
在一种可能的设计中，所述处理单元，还用于将所述电子钱包APP所支持的所有银行卡确定为与所述电子钱包APP当前登录的账号关联的所述至少两个银行卡。
在一种可能的设计中，所述发送单元，还用于向电子钱包服务器发送所述至少一个待绑定银行卡的标识以便于所述电子钱包服务器根据所述至少一个待绑定银行卡的标识请求银行服务器向终端下发待绑定银行卡对应的卡应用及个人化数据。
在一种可能的设计中，所述发送单元，还用于向电子钱包服务器发送第一请求以 便于所述电子钱包服务器请求第一银行服务器对所述验证信息验证通过后向终端下发所述待验证银行卡对应的卡应用及个人化数据。其中，所述第一请求中携带所述验证信息，所述第一银行服务器为所述待验证银行卡对应的银行服务器，所述个人化数据中携带互信凭证。所述发送单元，还用于在接收所述待验证银行卡对应的卡应用及个人化数据后，向所述电子钱包服务器发送第二请求以便于所述电子钱包服务器请求第二银行服务器与第一银行服务器之间对所述互信凭证验证通过后向所述终端下发所述待绑定银行卡对应的卡应用及个人化数据。其中，所述第二请求中携带所述互信凭证；所述第二银行服务器包括任意一个所述待绑定银行卡对应的银行服务器。
在一种可能的设计中，所述发送单元，还用于向电子钱包服务器发送请求以便于所述电子钱包服务器分别请求第一银行服务器和第二银行服务器在根据所述验证信息验证通过后由所述第一银行服务器向所述终端下发所述待验证银行卡对应的卡应用和个人化数据以及由所述第二银行服务器向所述终端下发所述待绑定银行卡对应的卡应用和个人化数据。其中，所述请求中携带所述待验证银行卡的验证信息，所述第一银行服务器为所述待验证银行卡对应的银行服务器，所述第二银行服务器为任意一个所述待绑定银行卡对应的银行服务器。
在一种可能的设计中，所述发送单元，还用于向电子钱包服务器发送请求以便于所述电子钱包服务器通过第三方可信服务器分别请求第一银行服务器和第二银行服务器在根据所述验证信息验证通过后分别向所述终端下发每个所述待绑定银行卡对应的卡应用和个人化数据。其中，所述第一银行服务器为所述待验证银行卡对应的银行服务器，所述第二银行服务器为任意一个所述待绑定银行卡对应的银行服务器。
在一种可能的设计中，所述请求中携带的所述验证信息为加密后的验证信息。
第五方面，提供一种终端，包括：显示单元，用于显示第一界面，该第一界面显示有与电子钱包APP当前登录的账号关联的至少两张银行卡以及每张银行卡对应的曾绑定所述银行卡的终端的标识。
在一种可能的设计中，所述终端还包括处理单元和发送单元。其中，所述处理单元，用于从所述至少两个银行卡中确定待验证银行卡以及至少一个待绑定银行卡。所述显示单元，还用于在显示第一界面后显示第二界面，该第二界面用于提示用户输入待验证银行卡的验证信息。所述发送单元，用于向服务器发送所述验证信息以请求服务器在根据该验证信息验证通过后向终端下发每个待绑定银行卡对应的卡应用及个人化数据以完成绑定所述至少一个待绑定银行卡。
在一种可能的设计中，所述显示单元，还用于在显示第一界面之前显示第二界面，所述第二界面用于提示用户输入待验证银行卡的验证信息。所述处理单元，还用于在显示所述第一界面后，从所述至少两个银行卡中确定至少一个待绑定银行卡。所述发送单元，还用于向服务器发送所述待验证银行卡的验证信息以请求服务器根据该验证信息验证通过后向终端下发每个待绑定银行卡对应的卡应用及个人化数据以完成绑定所述至少一个待绑定银行卡。
第六方面，提供一种电子钱包服务器，包括：接收单元，用于接收终端发送的至少一个待绑定银行卡的标识和待验证银行卡的验证信息。处理单元，用于根据所述验证信息和所述至少一个待绑定银行卡的标识请求银行服务器在对所述验证信息验证通过后向所述终端下发每个待绑定银行卡对应的卡应用及个人化数据。其中，所述银行 服务器包括第一银行服务器和第二银行服务器，所述第一银行服务器为所述待验证银行卡对应的银行服务器，所述第二银行服务器为任意一个所述待绑定银行卡对应的银行服务器。
在一种可能的设计中，所述电子钱包服务器，还包括：发送单元，用于向所述终端推送第一历史绑卡记录，所述第一历史绑卡记录中包括与电子钱包APP当前登录的账号关联的所有卡应用的标识。
在一种可能的设计中，所述与电子钱包APP当前登录的账号关联的所有卡应用的标识包括用户在所有终端上的电子钱包APP上登录当前账号时绑定的卡应用的标识。
在一种可能的设计中，所述与电子钱包APP当前登录的账号关联的所有卡应用的标识还包括与所述账号关联但已解绑的卡应用的标识。
在一种可能的设计中，所述发送单元，还用于在接收终端发送的至少一个待绑定银行卡的标识和待验证银行卡的验证信息之前，向所述终端发送第二历史绑卡记录，所述第二历史绑卡记录中包括所述账号在所述终端上的电子钱包APP中登录时绑定的卡应用的标识。
在一种可能的设计中，所述发送单元，还用于在接收终端发送的至少一个待绑定银行卡的标识和待验证银行卡的验证信息之前，向所述终端推送第三历史绑卡记录，所述第三历史绑卡记录中包括与所述账号关联且在所述终端本地未绑定的卡应用的标识，或者，所述电子钱包APP支持的所有卡应用的标识。
在一种可能的设计中，所述接收单元，还用于接收终端的查询请求；所述发送单元，还用于响应于所述查询请求，向所述终端推送所述历史绑卡记录。或者，所述发送单元，还用于监听到在所述电子钱包APP上登录所述账号的操作后，向所述终端推送所述历史绑卡记录。其中，所述历史绑卡记录包括所述第一历史绑卡记录、所述第二历史绑卡记录和所述第三历史绑卡记录。
在一种可能的设计中，所述发送单元，还用于根据所述至少一个待绑定银行卡的标识分别请求所述第一银行服务器和所述第二银行服务器根据所述验证信息验证通过后由所述第一银行服务器向所述终端下发待验证银行卡对应的卡应用和个人化数据以及由所述第二银行服务器向所述终端下发待绑定银行卡对应的卡应用和个人化数据。
在一种可能的设计中，所述发送单元，还用于向所述第一银行服务器发送第一请求，所述第一请求包括所述验证信息，用于请求所述第一银行服务器根据所述验证信息验证通过后下发待验证银行卡对应的卡应用及个人化数据，所述个人化数据中携带互信凭证。在接收到所述互信凭证后，根据所述待绑定银行卡的标识向第二银行服务器发送第二请求，所述第二请求包括所述互信凭证和所述待验证银行卡的标识，以使所述第二银行服务器在根据所述待验证银行卡的标识请求所述第一银行服务器对所述互信凭证验证通过后向所述终端下发所述待绑定银行卡对应的卡应用及个人化数据。
在一种可能的设计中，所述发送单元，还用于向第三方可信服务器发送第三请求，所述第三请求中包括所述验证信息和所述至少一个待绑定银行卡的标识，以使所述第三方可信服务器请求所述第一银行服务器根据所述验证信息验证通过后向所述终端下发所述待验证银行卡对应的卡应用及个人化数据，其中所述个人化数据包括互信凭证；以及使所述第三方可信服务器根据所述至少一个待绑定银行卡的标识请求所述第二银行服务器根据所述互信凭证验证通过后向所述终端下发所述待绑定银行卡对应的卡应 用及个人化数据。
第七方面，本申请的实施例提供一种终端，包括：处理器、存储器、总线和通信接口；该存储器用于存储计算机执行指令，该处理器与该存储器通过该总线连接，当终端运行时，该处理器执行该存储器存储的该计算机执行指令，以使终端执行上述第一方面、第一方面任一项、第二方面或第二方面任一项所述的绑卡方法。
第八方面，本申请实施例提供一种电子钱包服务器，包括：处理器、存储器、总线和通信接口；该存储器用于存储计算机执行指令，该处理器与该存储器通过该总线连接，当电子钱包服务器运行时，该处理器执行该存储器存储的该计算机执行指令，以使电子钱包服务器执行上述任一项所述的绑卡方法。
第八方面，本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当该指令在上述任一项终端上运行时，使得终端执行上述任一项所述的绑卡方法。
第九方面，本申请实施例提供一种包含指令的计算机程序产品，当其在上述任一项终端上运行时，使得终端执行上述任一项所述的绑卡方法。
本申请的实施例中，上述终端的名字对设备本身不构成限定，在实际实现中，这些设备可以以其他名称出现。只要各个设备的功能和本申请的实施例类似，即属于本申请权利要求及其等同技术的范围之内。
另外，第三方面至第九方面中任一种设计方式所带来的技术效果可参见上述第一方面、第二方面中不同设计方法所带来的技术效果，此处不再赘述。
附图说明
图1为本申请实施例提供的终端的结构示意图；
图2A为本申请实施例提供的绑卡方法的应用场景示例图一；
图2B为本申请实施例提供的绑卡方法的应用场景示例图二；
图2C为本申请实施例提供的绑卡方法的应用场景示例图三；
图2D为本申请实施例提供的绑卡方法的应用场景示例图四；
图2E为本申请实施例提供的绑卡方法的应用场景示例图五；
图2F为本申请实施例提供的绑卡方法的应用场景示例图六；
图3为本申请实施例提供的绑卡方法的具体实现过程示意图一；
图4为本申请实施例提供的绑卡方法的具体实现过程示意图二；
图5为本申请实施例提供的绑卡方法的具体实现过程示意图三；
图6为本申请实施例提供的终端的结构示意图；
图7为本申请实施例提供的一种电子钱包服务器的结构示意图；
图8为本申请实施例提供的另一种电子钱包服务器的结构示意图。
具体实施方式
用于执行本申请实施例提供的绑卡方法的终端，具体可以为手机、可穿戴设备、增强现实(augmented reality，AR)\虚拟现实(virtual reality，VR)设备、平板电脑、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数 字助理(personal digital assistant，PDA)等具有NFC支付功能的任意终端。当然，在以下实施例中，对该终端的具体形式不作任何限制。
示例性的，如图1所示，终端100具体可以包括：处理器101、射频(radio frequency，RF)电路102、存储器103、触摸屏104、蓝牙装置105、一个或多个传感器106、无线保真(WIreless-Fidelity，Wi-Fi)装置107、定位装置108、音频电路109、外设接口110、电源系统111以及近场通信(near field communication，NFC)装置112等部件。这些部件可通过一根或多根通信总线或信号线(图1中未示出)进行通信。本领域技术人员可以理解，图1中示出的硬件结构并不构成对终端100的限定，终端100可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。
下面结合图1对终端100的各个部件进行具体的介绍：
处理器101是终端100的控制中心，利用各种接口和线路连接终端100的各个部分，通过运行或执行存储在存储器103内的应用程序，以及调用存储在存储器103内的数据，执行终端100的各种功能和处理数据。在一些实施例中，处理器101可包括一个或多个处理单元；举例来说，处理器101可以是华为技术有限公司制造的麒麟960芯片。在本申请一些实施例中，上述处理器101还可以包括指纹验证芯片，用于对采集到的指纹进行验证。
射频电路102可用于在收发信息或通话过程中，无线信号的接收和发送。特别地，射频电路102可以将基站的下行数据接收后，给处理器101处理；另外，将涉及上行的数据发送给基站。通常，射频电路包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器、双工器等。此外，射频电路102还可以通过无线通信和其他设备通信。所述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统、通用分组无线服务、码分多址、宽带码分多址、长期演进、电子邮件、短消息服务等。
存储器103用于存储应用程序以及数据，处理器101通过运行存储在存储器103的应用程序以及数据，执行终端100的各种功能以及数据处理。存储器103主要包括存储程序区以及存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)；存储数据区可以存储根据使用终端100时所创建的数据(比如音频数据、电话本等)。此外，存储器103可以包括高速随机存取存储器(ramdom access memory，RAM)，还可以包括非易失存储器，例如磁盘存储器件、闪存器件或其他易失性固态存储器件等。存储器103可以存储各种操作系统，例如，苹果公司所开发的
Figure PCTCN2018117178-appb-000001
操作系统，谷歌公司所开发的
Figure PCTCN2018117178-appb-000002
操作系统等。上述存储器103可以是独立的，通过上述通信总线与处理器101相连接；存储器103也可以和处理器101集成在一起。
触摸屏104具体可以包括触控板104-1和显示器104-2。
其中，触控板104-1作为终端的输入设备可采集用户在其上或附近的触摸事件(比如用户使用手指、触控笔等任何适合的物体在触控板104-1上或在触控板104-1附近的操作)，并将采集到的触摸信息发送给其他器件(例如处理器101)。其中，用户在触控板104-1附近的触摸事件可以称之为悬浮触控；悬浮触控可以是指，用户无需为了选择、移动或拖动目标(例如图标等)而直接接触触控板，而只需用户位于终端附近以便执行所想要的功能。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型来实现触控板104-1。
显示器(也可称为显示屏)104-2可用于显示由用户输入的信息或提供给用户的信息以及终端100的各种菜单。可以采用液晶显示器、有机发光二极管等形式来配置显示器104-2。触控板104-1可以覆盖在显示器104-2之上，当触控板104-1检测到在其上或附近的触摸事件后，传送给处理器101以确定触摸事件的类型，随后处理器101可以根据触摸事件的类型在显示器104-2上提供相应的视觉输出。虽然在图1中，触控板104-1与显示屏104-2是作为两个独立的部件来实现终端100的输入和输出功能，但是在某些实施例中，可以将触控板104-1与显示屏104-2集成而实现终端100的输入和输出功能。
可以理解的是，触摸屏104是由多层的材料堆叠而成，本申请实施例中只展示出了触控板(层)和显示屏(层)，其他层在本申请实施例中不予记载。另外，触控板104-1可以以全面板的形式配置在终端100的正面，显示屏104-2也可以以全面板的形式配置在终端100的正面，这样在手机的正面就能够实现无边框的结构。
需要说明的是，终端100还可能包括其他输入设备，比如可以包括但不限于物理键盘、功能键(比如音量控制按键、电源开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。
终端100还可以包括蓝牙装置105，用于实现终端100与其他短距离的终端(例如手机、智能手表等)之间的数据交换。本申请实施例中的蓝牙装置可以是集成电路或者蓝牙芯片等。
终端100还可以包括至少一种传感器106，比如指纹采集器件、光传感器、运动传感器以及其他传感器。具体地，可以在终端100的背面(例如后置摄像头的下方)配置指纹采集器件，或者在终端100的正面(例如触摸屏104的下方)配置指纹采集器件。又例如，可以在触摸屏104中配置指纹采集器件来实现指纹识别功能，即指纹采集器件可以与触摸屏104集成在一起来实现终端100的指纹识别功能。光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节触摸屏104的显示器的亮度，接近传感器可在终端100移动到耳边时，关闭显示器的电源。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等。至于终端100还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。
Wi-Fi装置107，用于为终端100提供遵循Wi-Fi相关标准协议的网络接入，终端100可以通过Wi-Fi装置107接入到Wi-Fi接入点，进而帮助用户收发电子邮件、浏览网页和访问流媒体等，它为用户提供了无线的宽带互联网访问。在其他一些实施例中，该Wi-Fi装置107也可以作为Wi-Fi无线接入点，可以为其他终端提供Wi-Fi网络接入。
定位装置108，用于为终端100提供地理位置。可以理解的是，该定位装置108具体可以是全球定位系统(global positioning system，GPS)或北斗卫星导航系统、俄罗斯GLONASS等定位系统的接收器。定位装置108在接收到上述定位系统发送的地理位置后，将该信息发送给处理器101进行处理，或者发送给存储器103进行保存。在另外的一些实施例中，该定位装置108还可以是辅助全球卫星定位系统(assisted global positioning system，AGPS)的接收器，AGPS系统通过作为辅助服务器来协助定位装置108完成测距和定位服务，在这种情况下，辅助定位服务器通过无线通信网络与终端例如终端100的定位装置108(即GPS接收器)通信而提供定位协助。在另外的一些实施例中，该定位装置 108也可以是基于Wi-Fi接入点的定位技术。由于每一个Wi-Fi接入点都有一个全球唯一的媒体介入控制(media access control，MAC)地址，终端在开启Wi-Fi的情况下即可扫描并收集周围的Wi-Fi接入点的广播信号，因此可以获取到Wi-Fi接入点广播出来的MAC地址；终端将这些能够标示Wi-Fi接入点的数据(例如MAC地址)通过无线通信网络发送给位置服务器，由位置服务器检索出每一个Wi-Fi接入点的地理位置，并结合Wi-Fi广播信号的强弱程度，计算出该终端的地理位置并发送到该终端的定位装置108中。
NFC装置112，用于为终端提供NFC功能以支持各类NFC业务，如将终端模拟成卡片后直接靠近销售点终端(point of sale，POS)完成刷卡支付的NFC支付、将终端作为读写器直接靠近物理卡片完成读取卡中的数据的NFC读卡、NFC数据传输等。NFC装置112包括NFC控制器(Near Field Communication Cntroller，NFCC)，其功能包括射频信号的调制解调以及NFC协议处理。NFCC连接射频天线(即NFC天线)实现NFC信号的发送与接收。
可选的，为了实现NFC业务，尤其是NFC支付，手机中还可能包括安全模块(security element，SE)。SE用于对敏感信息的安全存储和对交易事务提供安全的执行环境，可以集成在处理器101中，或者位于手机的客户识别模块(Subscriber Identification Module，SIM)卡，或者位于手机的安全数字存储卡(Secure Digital Memory Card，SD)中，也可以为独立的芯片。NFCC可以和SE互相连接。
音频电路109、扬声器113、麦克风114可提供用户与终端100之间的音频接口。音频电路109可将接收到的音频数据转换后的电信号，传输到扬声器113，由扬声器113转换为声音信号输出；另一方面，麦克风114将收集的声音信号转换为电信号，由音频电路109接收后转换为音频数据，再将音频数据输出至RF电路102以发送给比如另一手机，或者将音频数据输出至存储器103以便进一步处理。
外设接口110，用于为外部的输入/输出设备(例如键盘、鼠标、外接显示器、外部存储器、用户识别模块卡等)提供各种接口。例如通过通用串行总线(universal serial bus，USB)接口与鼠标连接，通过用户识别模块卡卡槽上的金属触点与电信运营商提供的用户识别模块卡(subscriber identification module，SIM)卡进行连接。外设接口110可以被用来将上述外部的输入/输出外围设备耦接到处理器101和存储器103。
终端100还可以包括给各个部件供电的电源装置111(比如电池和电源管理芯片)，电池可以通过电源管理芯片与处理器101逻辑相连，从而通过电源装置111实现管理充电、放电、以及功耗管理等功能。
尽管图1未示出，终端100还可以包括摄像头(前置摄像头和/或后置摄像头)、闪光灯、微型投影装置装置等，在此不再赘述。
需要说明的是，上述终端仅是一个示例，并且终端100可以具有比图中所示出的更多的或者更少的部件，可以组合两个或更多的部件，或者可以具有不同的部件配置。
在终端上安装电子钱包APP并绑定银行卡后，用户可利用该电子钱包APP完成线下支付，如在实体店或物理POS机上完成NFC刷卡支付。目前，在电子钱包APP中绑定银行卡时，用户需要针对每张待绑定的银行卡执行输入卡号、手机号、卡支付密码，设置钱包支付密码、安保问题等过程以完成绑定。由此可见，采用目前的绑卡方式完成多张卡的绑定时，用户的操作比较繁琐，绑卡效率较低。
为了简化用户操作以提高绑卡效率，本申请实施例提供一种绑卡方法，该方法要求 用户仅输入单张或少数几张银行卡的验证信息便可一次完成绑定所有待绑定的银行卡。具体的，参考图2A、图2C，终端显示第一界面，该第一界面显示有与所述电子钱包APP当前登录的账号关联的至少两个银行卡。该至少两个银行卡可以包括所有与该账号相关联但尚未在该终端上绑定的银行卡，终端具体如何确定该至少两个银行卡的实现方式可参考后文详述。例如：终端通过图2A中界面202A显示与当前登录的账号相关联但尚未在该终端上绑定的至少两个银行卡，或者，终端通过图2C中界面202B按终端的标识分组显示与当前登录的账号相关联但尚未在该终端上绑定的至少两个银行卡，即通过终端的标识标明所显示的每个银行卡分别是在哪个终端上登录该账号时绑定的。可选的，该至少两个银行卡可以包括与该账号关联的所有银行卡，例如：终端通过图2C中的界面202C显示在当前终端登录当前账号时与该账号相关联但尚未在该终端上绑定的至少两个银行卡，同时显示在当前终端登录当前账号时已经在该终端上绑定的银行卡。之后，终端从所述至少两个银行卡中确定待验证银行卡以及至少一个待绑定银行卡并且获取待验证银行卡的验证信息。示例性的，用户可从界面202A或202B或202C中所显示的至少两个银行卡中选择待验证银行卡和待绑定银行卡。终端检测到用户的选择操作后，显示界面203，用于提示用户输入待验证银行卡的验证信息。用户可根据界面203的提示输入待验证银行卡的相关信息，如银行名称、卡号、预留手机号、取款密码以及安保问题设置等。当然，用户在输入验证信息时，可由用户手动编辑输入，或者，可通过如语音、图片，如对卡片拍照所得图片或者NFC读卡方式等其他方式输入，本申请实施例不作限定。如图2D所示，在确定待验证银行卡后，终端显示界面2031提示用户可对待验证银行卡拍照以读取待验证银行卡的卡号，之后终端接着显示界面2032以提示用户继续输入该待验证银行卡的其他验证信息。之后，终端向服务器发送待验证银行卡的验证信息以请求服务器在根据所述验证信息验证通过后向终端下发每个所述待绑定银行卡对应的卡应用及个人化数据以完成绑定所述至少一个待绑定银行卡。可选的，如界面204所示，在绑定银行卡的过程中，显示每个待绑定银行卡的绑定进度。
当然，参考图2B，触发终端显示所述第一界面的操作包括用户通过电子钱包APP输入的触发操作。示例性的，该触发操作包括：用户在所述电子钱包APP的登录界面输入的登录操作201A。其主要应用在终端检测到用户首次使用某个账号登录该终端上的电子钱包APP的场景下。例如：用户首次使用账号abcd在终端1上登录电子钱包APP，那么，所述触发操作可以为终端检测到的用户在终端1上的首次登陆操作。又如：用户虽然在终端1上使用账号abcd登录过电子钱包APP，但首次在终端2上用该账号abcd登录电子钱包APP，那么，所述触发操作可以为终端检测到用户在终端2上的首次登陆操作。仍如图2B所示，所述触发操作还包括：用户成功登录所述电子钱包APP后，通过预设入口，如绑卡界面的添加按钮，输入的添加待绑定银行卡的操作201B。响应于所述触发操作201A或201B，终端显示如界面202A、202B或202C所示的第一界面。
需要说明的是，上述图2A-2D中所述的银行卡可以具体分为不同类型的卡，如储蓄卡、信用卡等，具体实现中可通过文字或图片等形式进行明确提示，本申请实施例不进行限定。
在另一种实现方式中，如果用户在202A所示的界面中选择了待绑定银行卡和待验证银行卡后，例如：仅选择了一张银行卡，该银行卡既是待绑定银行卡也是作为待验证银行卡。那么，在用户通过界面203输入验证信息后，可再次显示如界面202A所示的界面 以提示用户还可选择其他待绑定银行卡，之后执行后续的绑卡过程并显示如界面204所示的界面。
在另一种实现方式中，用户在电子钱包APP中输入某张银行卡的验证信息以绑定该银行卡时，提示用户是否同时绑定其余银行卡，并在无需用户输入其余待绑定银行卡的验证信息的前提下根据已输入的银行卡的验证信息完成绑定其余所有银行卡。参考图2E，终端检测到用户的触发操作后，显示界面203以提示用户输入待绑定银行卡(图中以招商银行为例)的验证信息。当然如前文所述，该触发操作可以为图2B所示的登录电子钱包APP的登录操作201A或已登录电子钱包APP后输入的添加银行卡的操作201B。用户完成验证信息的输入后，终端显示界面205A，该界面用于提示用户在绑定前述招商银行卡的同时是否同时绑定其他银行卡并提供了可供用户选择的其他银行卡如中国银行、交通银行等。当然，在该界面205A具体提示哪些银行卡可参考后文详述。以用户选择了中国银行卡为例，用户无需输入中国银行卡的验证信息，如界面204所示，终端根据用户之前输入的招商银行卡的验证信息便可同时绑定中国银行卡和招商银行卡。
可选的，205A所示的提示界面可替换为205B所示的提示界面。在该提示界面205B中，终端显示与当前账号关联的历史绑卡信息，具体为用户曾在其他设备上登录当前账号时绑定的银行卡信息，如界面205B中示出了用户在HUAWEI Mate10上绑定过中国银行卡以及在荣耀9上绑定过交通银行。这样，用户可根据这些提示信息选择要绑定的银行卡。
可选的，上述方法中，在显示与所述电子钱包APP当前登录的账号关联的至少两个银行卡之前，终端可通过以下实现方式确定界面202A或202B或202C中所显示的与所述电子钱包APP当前登录的账号关联的至少两个银行卡：
实现方式一、终端获取与所述账号关联的第一历史绑卡记录，该第一历史绑卡记录是指包含与所述账号关联的所有卡应用的标识的列表或其他记录形式。进一步的，终端尝试获取与所述账号关联的第二历史绑卡记录，该第二历史绑卡记录是指包含在当前终端上登录所述账号时绑定的卡应用的标识的列表或其他记录形式。如果终端获取到与所述账号关联的第二历史绑卡记录，则将不包含在所述第二历史绑卡记录但包含在所述第一历史绑卡记录中的卡应用的标识对应的银行卡确定为所述至少两个银行卡。如果终端未获取到所述第二历史绑卡记录，则将所述第一历史绑卡记录中的卡应用的标识对应的银行卡确定为所述至少两个银行卡。
其中，所述第一历史绑卡记录为与该账号关联的所有绑卡记录。也即，第一历史绑卡记录包括用户在每个终端(包括当前终端以及其他终端)上登录该当前账号后通过绑卡操作绑定的所有银行卡的记录的集合。可选的，该第一历史绑卡记录既包括当前仍然绑定的，还可能包括曾绑定但当前已解绑的。终端可从电子钱包服务器获取该第一历史绑卡记录。这种方式要求电子钱包服务器中保存在每个终端上登录当前账号时产生的绑卡记录。具体获取时，可以为终端登录当前账号后向电子钱包服务器发送请求以获取第一历史绑卡记录。例如：终端一旦检测到用户在某终端的电子钱包APP上登录账号或者执行添加卡片的操作，则电子钱包APP主动向电子钱包服务器请求获取第一历史绑卡记录。还可以为电子钱包服务器检测到当前账号在当前终端上登录电子钱包APP后主动推送。例如，电子钱包服务器一旦检测到某一终端的上述登录或者添加卡片的操作就主动向该终端的电子钱包APP推送上述第一历史绑卡记录。示例性的，所述第一历史绑卡记录如 表一或表二或表三所示。
表一
钱包账号 卡应用列表信息卡应用状态
钱包账号1中行储蓄卡 可用：已绑定
   工行信用卡 可用：已绑定
   建行信用卡 不可用：已解绑/已删除
表二
钱包账号 卡应用列表信息卡应用状态
钱包账号1 AID1 可用：已绑定
   AID2   可用：已绑定
   AID3   不可用：已解绑/已删除
表三
钱包账号 终端标识 卡应用列表信息卡应用状态
钱包账号1终端标识1 中行储蓄卡 可用：已绑定
   终端标识2 工行信用卡 可用：已绑定
   终端标识1 建行信用卡 不可用：
已解绑/已删除
需要说明的是，上述表一和表二中，电子钱包服务器向终端推送的第一历史绑卡记录中仅包括卡应用的标识，未区分每个卡应用所属的终端。而上述表三中，电子钱包服务器向终端推送的第一历史绑卡记录中除了包括卡应用的标识，还包括每个卡应用所属的终端的标识。此外，上述表一和表三中卡应用的标识以卡应用的类型(也即卡应用所属的银行及其类型，如某银行的储蓄卡、信用卡等)表示，上述表二中，卡应用的标识以应用标识(application identifier，AID)表示，这两种表示方式均能表示其对应的银行卡。在其他实现方式中，还可以由卡应用的名称或者编号等信息表示。此外，表一或表二或表三中示出的第一历史绑卡记录中还包含卡应用的状态，实际上也可以不包含卡应用的状态。
其中，所述第二历史绑卡记录包括当前终端上存在的与当前账号有效绑定的卡应用，此处所说的有效绑定的卡应用是指仍与当前账号绑定且尚未解绑或删除的卡应用。可选的，终端可本地查找得到所述第二历史绑卡记录。在该实现方式中，要求电子钱包APP在终端本地维护一个记录，如将该记录保存在可信执行环境(Trusted Execution Environment，TEE)中，或者由TEE中的一个可信应用(Trusted Application，TA)负责维护该记录。该记录可以是列表的形式，该记录用于将每个账号及其对应的卡应用进行关联。因此，电子钱包APP可以通过在当前终端本地查找是否有该记录来确定是否有上述有效绑卡记录，也即第二历史绑卡记录。或者，终端还可从电子钱包服务器获取所述第二历史绑卡记录。该具体实现方式可参考终端从电子钱包服务器获取第一历史绑卡记录，此处不再赘述。
示例性的，如表四所示，所述第二历史绑卡记录为当前终端上存在的与当前电子钱 包账号有效绑定的卡应用。
表四
钱包账号 卡应用列表信息卡应用状态
钱包账号1中行储蓄卡 可用：已绑定
终端在分别获取到第一历史绑卡记录和第二历史绑卡记录后，由于第二历史绑卡记录中是指在当前终端上登录当前账号时已经绑定的卡应用的标识，意味着当前终端已经存储并绑定了这些卡应用无需再绑定，因此，可仅将不包含在所述第二历史绑卡记录但包含在所述第一历史绑卡记录中的卡应用的标识对应的银行卡确定为所述至少两个银行卡。例如：参考表三所示的第一历史绑卡记录和表四所示的第二历史绑卡记录，“工行信用卡”是用户在其他终端上绑定的银行卡，“建行信用卡”为用户之前在当前终端登录当前账号曾经绑定但已解绑的银行卡。这些都可能为用户此次想要在当前终端上绑定的银行卡。因此，可将“工行信用卡”和“建行信用卡”确定为上文所述的至少两个银行卡并显示。当然，如前文所示，可以通过如图2A所示的界面202A直接仅显示这些银行卡。考虑到该至少两个银行卡可能是之前在其他不同终端上登录该账号时通过绑卡操作绑定的，因此可类似图2C所示的界面202B，终端在向用户展示至少两个银行卡的同时，还分别显示这些银行卡对应的终端标识，即在界面上按终端分组显示这些银行卡。当然，还可以类似图2D所示的界面202C，除了显示终端当前尚未绑定的至少两个银行卡外，还可显示当前已经绑定的银行卡。
实现方式二、终端接收所述服务器发送的第三历史绑卡记录，该第三历史绑卡记录中包括与所述账号关联且在所述终端本地未绑定的卡应用的标识，也即在当前终端登录当前账号时当前终端时，当前终端未绑定的卡应用的标识。然后，终端将该第三历史绑卡记录中的卡应用的标识对应的银行卡确定为所述至少两个银行卡。在该实现方式中，要求电子钱包服务器保存当前账号在每个终端上登录时产生的绑卡记录，可选地，还可包括绑卡后又解绑的记录等。例如，电子钱包服务器既保存了上述第一历史绑卡记录，也保存了上述第二历史绑卡记录，那么，电子钱包服务器可以直接根据其保存的第一历史绑卡记录和第二历史绑卡记录得到与在当前终端登录当前账号时未绑定的卡应用的标识，并将这些标识以列表或其他记录形式作为第三历史绑卡记录发送给终端。或者，可以仅保存上述第一历史绑卡记录，然后直接将其中除了当前终端之外的其他终端所对应的绑卡记录，以及当前终端对应的曾绑定但已解绑的绑卡记录作为第三历史绑卡记录发给该当前终端。同理，服务器在推送第三历史绑卡记录时，可以是在接收终端的请求后推送，也可以主动推送。
可选的，在其他实现方式中，终端还可直接将所述电子钱包APP所支持的所有银行卡确定为与所述电子钱包APP当前登录的账号关联的所述至少两个银行卡。该实现方式主要适用在用户登录当前账号首次绑卡的场景，例如，在某个终端上使用新注册的账号进行首次绑卡的场景。
可选的，在从至少两个银行卡中确定待验证银行卡以及至少一个待绑定银行卡时，除了如图2A至图2D所示，根据用户的选择操作从所述至少两个银行卡中确定所述待验证银行卡以及所述至少一个待绑定银行卡之外。在不提示用户选择，或者即使提示了用户选择但用户长时间未选择的情况下，终端还可按照预设规则自动确定待验证银行卡以及待绑定银行卡。示例性的，该预设规则可以为如基于用户以往使用情况确定待绑定银行 卡或待验证银行卡，如历史使用次数超过预设次数的银行卡或预设时间或在预设位置范围内使用较频繁的银行卡。或者，直接默认将确定出的所述至少两个银行卡中的所有银行卡均确定为待绑定银行卡并从中任意选择一个银行卡作为待验证银行卡。
此外，需要说明的是，在图2A至图2D中，以用户选择其中一张待绑定银行卡作为待验证银行卡为例说明。实际应用中，不限定待验证银行卡的数量，也即用户选择的待验证银行卡可以为多张。例如，对于所有待绑定银行卡对应的银行，如果其中一类特定银行之间有合作可对用户做互信身份验证，另外一类银行卡之间有合作可对用户做互信身份验证，那么需要分别针对每类有互信合作的银行选择一张待验证卡，也即为所有待绑定银行卡中的两组待绑定银行卡分别选择一张待验证银行卡。此外，银行A和银行B之间存在互信身份验证可以理解为将银行A发行的银行卡的信息，如卡号、密码或开户户主身份信息等，发送给银行B进行用户身份验证，或者，可以将银行A对其发行的银行卡的信息的验证结果作为验证凭证发送给银行B，供银行B用于用户身份验证。此外，实际应用中也不限定待验证银行卡是否属于待绑定银行卡，也即待验证银行卡可以为除待绑定银行卡以外的其他银行卡，这种情况下，待验证银行卡仅仅用于验证，无需下发该待验证银行卡的卡应用及个任务数据，也即无需绑定该待验证银行卡。
值得说明的是，当上述方法由图1所示终端100执行时，终端100可通过RF电路102接收用户通过电子钱包APP输入的触发操作。响应于所述触发操作，终端通过显示器104-2显示与所述电子钱包APP当前登录的账号关联的至少两个银行卡。然后，终端通过处理器101从所述至少两个银行卡中确定待验证银行卡以及至少一个待绑定银行卡以及获取所述待验证银行卡的验证信息。或者终端通过处理器101控制触摸板104获取用户从所述至少两个银行卡中确定待验证银行卡以及至少一个待绑定银行卡以及用户输入的所述待验证银行卡的验证信息。之后，终端100再通过RF电路102向服务器发送所述验证信息以请求服务器在根据所述验证信息验证通过后向所述终端下发每个所述待绑定银行卡对应的卡应用及个人化数据以完成绑定所述至少一个待绑定银行卡。
下文通过终端、电子钱包服务器、银行服务器的内部交互详细介绍本申请实施例中在确定待绑定银行卡和待验证银行卡后根据待验证银行卡的验证信息完成绑定所有待绑定银行卡的具体实现过程。此外，下文均以确定一个待验证卡以及该待验证银行卡属于待绑定银行卡的其中一张为例说明。
在一种实现方式中，为响应终端的请求，电子钱包服务器先请求待验证银行卡对应的银行服务器根据待验证银行卡的验证信息对待验证银行卡进行验证并在验证通过后生成互信凭证以及自动绑定该待验证银行卡，然后分别请求其他待绑定银行卡对应的银行服务器根据该互信凭证自动绑定其余待绑定银行卡。参考图3，该实现方式具体包括以下步骤301至步骤310：
301、终端向电子钱包服务器发送第一请求。
可选的，所述第一请求中携带待验证银行卡的验证信息，该验证信息包括银行名称、卡号、预留手机号、取款密码以及安保问题设置等，这些信息用于判断该待验证银行卡是否为合法的卡，进而可理解为是判断该银行卡的持有人，即终端用户是否合法。第一请求用于请求对待验证银行卡的验证信息进行验证以及下发待验证银行卡的卡应用和个人化数据以完成待验证银行卡的绑定。
302、电子钱包服务器向第一银行服务器发送请求。
本申请实施例中，将待验证银行卡对应的银行服务器描述为第一银行服务器，将其余待绑定银行卡对应的银行服务器描述为第二银行服务器。
本步骤中，电子钱包服务器收到终端的第一请求后，根据待验证银行卡的验证信息向第一银行服务器发送请求，该请求中包括所述验证信息，用于请求所述第一银行服务器根据所述验证信息进行验证。
待验证银行卡的标识用于标识待验证银行卡所属的银行，即第一银行服务器。待验证银行卡和待绑定银行卡的标识可以为银行卡所属银行的名称、银行机构代码或银行服务地址等，或者，也可以为其他能表征该卡应用或其对应银行的标识，如ISO 7816中定义的AID，该AID中有注册的应用提供商标识RID(Registered Application Provider Identifier，可表示该卡应用提供商，如所属银行机构)，又如中国金融IC卡规范PBOC中定义的产品标识信息，该产品标识信息中有银行标识码。
在一种实现方式中，在步骤301之前，终端在确定了待验证银行卡和待绑定银行卡后，直接向电子钱包服务器发送待验证银行卡和待绑定银行卡的标识并由电子钱包服务器本地保存。这样，电子钱包服务器可根据这些标识请求相应的银行服务器向终端下发待绑定银行卡对应的卡应用及个人化数据。例如：在该步骤302中，电子钱包服务器根据本地已保存的待验证银行卡的标识确定第一银行服务器并向第一银行服务器发送请求。
可选的，在另一种实现方式中，在步骤301中，第一请求中携带待验证银行卡的标识。那么，该步骤302中，电子钱包服务器可根据第一请求中的待验证银行卡的标识请求待验证银行卡对应的银行服务器。
此外，该第一请求中除了携带待验证银行卡的验证信息外，还可携带终端标识、每个待绑定银行卡的标识、以及当前登录该电子钱包APP所使用的账号。
303、第一银行服务器根据所述验证信息验证通过后向终端下发待验证银行卡对应的卡应用及个人化数据，所述个人化数据中携带互信凭证。
可选的，所述卡应用可被下载与安装到该终端的安全区域(如SE、TEE等)，所述个人化数据包括卡片的令牌(token)以及密钥等该卡应用相关的隐私数据。其中，该token可理解为替代物理卡片的卡号的数据，其作用与真实卡号类似。
可选的，第一银行服务器先向电子钱包服务器发送待验证银行卡的卡应用以及个人化数据并进一步由电子钱包服务器下发给终端。则终端可根据该待验证银行卡的卡应用及个人化数据实现绑定该待验证银行卡。
可选的，第一银行服务器直接向终端下发待验证银行卡的卡应用以及个人化数据以由终端完成绑定该待验证银行卡。如根据电子钱包服务器转发的上述终端标识对该终端进行寻址，以直接向终端下发卡应用及其个人化数据。
所述互信凭证可以是所述个人化数据中的部分信息，如上述token，或者由所述第一银行服务器根据电子钱包服务器发送的请求或该请求中携带的互信需求标志专门生成的凭证信息。其中，该互信需求标志可理解为用于表示本次绑卡需要同时用该待验证卡的验证信息完成其他银行卡的绑定。
该互信凭证用于在绑定其余待绑定银行卡的过程中，其他第二银行服务器与第一银行服务器之间利用该互信凭证进行跨行验证，以使在跨行验证通过后第二银行服务器向终端下发其他待绑定银行卡的卡应用及其个人化数据，具体可见后文详述。
304、终端根据待验证银行卡对应的卡应用及个人化数据绑定该待验证银行卡。
本步骤中，待验证银行卡的卡应用下载与安装到终端本地后，终端可向系统注册NFC服务，该NFC服务可能为HCE服务或非HCE服务，从而使该卡应用变为可使用状态或者可供用户选择与激活的状态并在用户选择激活后可使用，该具体实现可参考现有技术，此处不再赘述。
相应地，电子钱包服务器可在本地保存电子钱包所登录的账号与该待验证银行卡的绑定关系，或者保存该终端、所登录的电子钱包账号与该待验证银行卡的绑定关系。
在完成绑定待验证银行卡后，终端执行下述步骤以进一步完成绑定其余待绑定银行卡。
305、终端向电子钱包服务器发送第二请求。
所述第二请求用于请求电子钱包服务器发送其余待绑定银行卡的卡应用及个人化数据。
306、电子钱包服务器向第二银行服务器发送请求。
本步骤中，电子钱包服务器收到终端发送的第二请求后，根据其余待绑定银行卡的标识向相应的第二银行服务器发送请求，该请求用于请求第二银行服务器根据互信凭证验证通过后下发其余待绑定银行卡的卡应用及个人化数据。
其余待绑定银行卡的标识用于标识除待验证银行卡之外的其他待绑定银行卡所属的银行，即第二银行服务器。参考步骤302，所述其余待绑定银行卡的标识可以在步骤301之前由终端发送。可选的，所述其余待绑定银行卡的标识还可以携带在步骤305所述的第二请求中。可选的，在另一种实现方式中，待绑定银行卡的标识还可以和待验证银行卡的标识一并携带在步骤301中的第一请求中。
本步骤中，电子钱包服务器向第二银行服务器发送的请求中携带所述互信凭证。可选的，所述互信凭证可以携带在步骤305所述的第二请求中由终端发送给电子钱包服务器再进一步由电子钱包服务器发送给第二银行服务器。可选的，步骤303中，第一银行服务器如果通过电子钱包服务器向终端下发互信凭证，则电子钱包服务器本地保存有该互信凭证，那么电子钱包服务器可直接将本地保存的互信凭证发送给第二银行服务器。
此外，该请求中除了携带互信凭证外，还携带终端标识、当前登录电子钱包APP所使用的账号、待验证银行卡的标识(即第一银行服务器的标识)。
307、第二银行服务器根据互信凭证请求第一银行服务器对所述互信凭证进行验证。
本步骤中，第二银行服务器根据待验证银行卡的标识确定第一银行服务器。当然，该待验证银行卡的标识可以携带在步骤306所述的请求中，也可以由终端发送给第二银行服务器。
308、第一银行服务器向第二银行服务器发送验证成功消息。
本步骤中，第一银行服务器对互信凭证进行验证，判断该互信凭证是否合法，如判断该互信凭证与自己之前生成的互信凭证是否完全相同。
进一步的，第一银行服务器还可判断该第二银行服务器的标识与之前步骤302中电子钱包服务器发送的第二银行服务器的标识(即上述其余待绑定银行卡的标识)是否相同。
此外，若该互信凭证是经过加密的，则还对该互信凭证进行解密。
309、第二银行服务器向终端下发相应的待绑定银行卡的卡应用及个人化数据。
310、终端根据第二银行服务器下发的卡应用及个人化数据依次完成绑定其余待绑定银行卡。
上述步骤309-310与前面步骤303-304原理类似，这里不再赘述。
需要说明的是，在执行上述步骤301至步骤310的过程中，传输数据可以是经过加密的，如在执行步骤301时，可用待验证银行卡所属银行的密钥，即第一银行服务器的密钥对待验证银行卡的验证信息做加密处理，相应地，第一银行服务器对加密的验证信息进行解密后再做验证。
此外，可选的，上述步骤301和步骤305可以合并。也即，终端仅向电子钱包服务器发送一次请求，该请求中至少携带待验证银行卡的验证信息。可选的，还可携带所有待绑定银行卡的标识。那么，电子钱包服务器收到该请求后，电子钱包服务器、第一银行服务器、第二银行服务器之间执行上述步骤302、303、304、306、307、308、309、310，该具体过程可参考前文所述。在该实现方式中，电子钱包服务器收到终端的请求后，先向第一银行服务器请求对待验证银行卡验证以及下发待验证银行卡的卡应用及个人化数据。之后，在确定第一卡应用的个人化完成后，电子钱包服务器直接解析个人化数据中的互信凭证，并利用该互信凭证分别请求其他第二银行服务器进行跨行验证与下发卡应用及个人化数据以进一步完成绑定。
可见，通过步骤301至步骤310所描述的过程，终端通过电子钱包服务器先请求第一银行服务器对待验证银行卡进行验证并在验证通过后由第一银行服务器下发相应的卡应用及个人化数据，该个人化数据中携带互信凭证。进一步的，再根据该互信凭证进一步分别请求第二银行服务器对互信凭证进行跨行验证并在验证通过后由第二银行服务器下发其余待绑定银行卡的卡应用及个人化数据。这样，能够实现用户仅输入待验证银行卡的验证信息，便能根据该验证信息完成绑定所有待绑定银行卡。
在另一种实现方式中，将待验证银行卡的验证信息分别发送给所有待绑定银行卡对应的银行服务器(既包括第一银行服务器还包括第二银行服务器)，并由待验证银行卡对应的银行服务器，即第一银行服务器对所述验证信息进行验证以及由除待验证银行之外的其他待绑定银行卡对应的银行服务器，即各个第二银行服务器根据所述验证信息请求第一银行服务器进行跨行验证，在验证通过后分别下发每个待绑定银行卡的卡应用及个人化数据。参考图4，该实现方式包括以下步骤401至步骤407：
401、终端向电子钱包服务器发送请求。
其中，该请求中携带待验证银行卡的验证信息。可选的，终端对待验证银行卡的验证信息进行加密。该加密操作可以是终端使用待验证银行卡对应的银行服务器，即第一银行服务器的密钥(如公钥或对称密钥)对该验证信息进行一次加密。
可选的，该请求中还携带终端的标识以及当前登录电子钱包APP所使用的账号。
402、电子钱包服务器分别向第一银行服务器和第二银行服务器发送请求。
其中，该请求中携带待验证银行卡的验证信息。
在一种实现方式中，电子钱包服务器分别根据待验证银行卡的标识和其余待绑定银行卡的标识向第一银行服务器和第二银行服务器发送待验证银行卡的验证信息。
当然，该待验证银行卡的标识和其余待绑定银行卡的标识可以在步骤401之前，终端在确定了待验证银行卡和待绑定银行卡后，直接向电子钱包服务器发送待验证银行卡和待绑定银行卡的标识并由电子钱包服务器本地保存。也可以在携带在步骤401所述的请求中。本申请实施例对此不作限定。
需要说明的是，电子钱包服务器向第二银行服务器发送请求时，除了携带待验证银 行卡的验证信息，还携带待验证银行卡的标识或第一银行服务器的标识，以便于第二银行服务器找到第一银行服务器进行跨行验证操作。
可选的，电子钱包服务器在向第二银行服务器发送请求之前，还可以对其中的验证信息做一次加密(若步骤401中已做一次加密，则电子钱包服务器可做二次加密)，即分别使用第二银行服务器的密钥对该验证信息进行加密以保证数据传输的安全。
可选的，该请求中还可携带终端的标识以及当前登录电子钱包APP所使用的账号。
403、第一银行服务器根据所述待验证银行卡的验证信息对待验证银行卡进行验证并在验证通过后向终端下发待验证银行卡的卡应用及个人化数据。
该步骤的具体实现可参考步骤303，此处不再赘述。
404、终端根据待验证银行卡对应的卡应用及个人化数据绑定该待验证银行卡。
该步骤的具体实现可参考步骤304，此处不再赘述。
405、第二银行服务器根据所述待验证银行卡的验证信息请求第一银行服务器对所述验证信息进行验证。
可选的，第二银行服务器可直接将电子钱包服务器发送过来的待验证银行卡的验证信息发送给第一银行服务器。当然，也可以再次加密后发给第一银行服务器，如利用第二银行服务器的私钥或对称密钥做加密，此时可能需要在第一银行服务器处保存有第二银行服务器的公钥或对称密钥，这些密钥可以是参与合作的银行(可以理解为双方达成合作以支持本申请实施例中所述的跨行验证，即某个银行的验证结果可被其他银行信任)预置的密钥等。
可选的，在步骤402中，电子钱包服务器向第一银行服务器发送的请求中还可以携带其他待绑定银行卡的标识或第二银行服务器的标识。这样，在本步骤中第一银行服务器对验证信息进行验证的同时还可以对第二银行服务器进行验证。如第一银行服务器收到某个第二银行服务器的请求时，根据已接收的待绑定银行卡的标识或第二银行服务器的标识验证该第二银行服务器是否合法：如果该第二银行服务器的标识属于步骤402中已接收的待绑定银行卡的标识所指示的第二银行服务器或属于步骤402中已接收的第二银行服务器的标识，则确认该第二银行服务器合法，否则不合法。
406、第一银行服务器向第二银行服务器发送验证成功消息。
407、第二银行服务器收到第一银行服务器返回的验证成功消息后，向终端下发待绑定银行卡的应用以及个人化数据。
408、终端根据第二银行服务器下发的卡应用及个人化数据依次完成绑定其余待绑定银行卡。
该步骤的具体实现可参考前述步骤310，此处不再赘述。
需要说明的是，本申请实施例不限定上述步骤403、404所描述的绑定待验证银行卡的实现过程和步骤405、406、407、408所描述的绑定其余待绑定银行卡的实现过程之间的顺序。这两个实现过程可能同时执行也可能先后执行。
可见，在图4所示的实现方式中，电子钱包服务器将待验证银行卡的验证信息除了发送给第一银行服务器外，还发送给了每个第二银行服务器。这样，第一银行服务器可直接对验证信息验证成功后下发卡应用及个人化数据。第二银行服务器可通过第一银行服务器对验证信息验证通过后下发相应的卡应用及个人化数据。
需要说明的是，针对图3所示的实施例中步骤307、308所示的第二银行服务器请求 第一银行服务器对上述互信凭证进行验证，以及图4所示的实施例中步骤405、406所示的第二银行服务器请求第一银行服务器对上述验证信息进行验证，还可以通过其他方式实现，例如，这些第二银行服务器分别通过一个中间第三方可信服务器请求第一银行服务器对这些信息进行跨行验证，这些中间第三方可信服务器可以是与所有这些银行合作的一方，如银联或其他服务提供商。
在又一种实现方式中，电子钱包服务器将待验证银行卡的验证信息发送给第三方可信服务器，由第三方可信服务器请求待验证银行卡对应的第一银行服务器对该验证信息验证成功后下发卡应用及其个人化数据以进行绑卡操作，再分别请求其他待绑定银行卡对应的第二银行服务器进行绑卡操作。需要说明的是，本申请实施例所述的第三方可信服务器可以由电子钱包服务提供商运营与管理，此时可以理解为是第三方可信服务器与上述电子钱包服务器的划分只是从逻辑功能上进行了区分。当然，第三方可信服务器还可以由一个独立的第三方运行与管理，如银行或银联等金融机构，或者支付宝这种第三方支付服务提供机构等。参考图5，该实现方式包括以下步骤501至步骤508：
501、终端向电子钱包服务器发送请求。
该步骤可参考步骤401，此处不再赘述。
502、电子钱包服务器向第三方可信服务器发送请求。
其中，该请求中包含待验证银行卡的验证信息以及每个待绑定银行卡的标识或所属银行的标识或所述银行服务器的标识。可选的，该请求中还可能包含终端标识和当前登录电子钱包APP所使用的账号。
503、第三方可信服务器向第一银行服务器发送请求。
该请求中携带待验证银行卡的验证信息，用于请求第一银行服务器对该验证信息进行验证并在验证成功后下发待验证银行卡的卡应用及个人化数据。
504、第一银行服务器根据待验证银行卡的验证信息验证成功后向第三方可信服务器下发待验证银行卡的卡应用及个人化数据。
该步骤的具体实现可参考步骤303，此处不再赘述。
505、第三方可信服务器向第二银行服务器发送请求。
第三方可信服务器收到第一银行服务器发送的待验证银行卡的卡应用及个人化数据后，表明第一银行服务器已经对待验证银行卡的验证信息验证通过，或者，第三方可信服务器收到第一银行服务器发送的验证通过结果后确定第一银行服务器已经对该待验证银行卡的验证信息验证通过。那么，第三方可信服务器可进一步请求各个第二银行服务器下发其余待绑定银行卡的卡应用及个人化数据，也即执行下述步骤506。
可选的，该请求中可能携带终端标识、当前登录电子钱包APP所使用的账号，该请求中还可能携带上述验证通过结果，该请求用于请求第二银行服务器下发相应的待绑定银行卡的卡应用及个人化数据。可选的，如果步骤504中第一银行服务器向第三方可信服务器下发的所述个人化数据中还携带互信凭证，或者第一银行服务器向第三方可信服务器发送上述验证通过结果时还携带互信凭证，那么，该步骤505中发送的请求中同样携带所述互信凭证。这样第二银行服务器收到互信凭证后可向第一银行服务器发送该互信凭证并在第一银行服务器对该互信凭证通过后执行下述步骤506。
506、第二银行服务器向第三方可信服务器发送待绑定银行卡的卡应用及个人化数据。
507、第三方可信服务器向终端下发待验证银行卡以及其余各个待绑定银行卡的卡应用及个人化数据。
508、终端根据各个待绑定银行卡的卡应用及个人化数据完成绑定各个待绑定银行卡。
需要说明的是，上述步骤504、步骤506中，第一银行服务器或第二银行服务器也可直接将卡应用及个人化数据下发给电子钱包服务器并进一步由电子钱包服务器发送给终端。或者第一银行服务器或第二银行服务器直接将卡应用及个人化数据下发给终端。此外，上述步骤507中，第三方可信服务器同时向终端下发或通过电子钱包服务器向终端下发卡应用及个人化数据。在其他实现方式中，第三方可信服务器可在步骤504之后先下发待验证银行卡的卡应用及个人化数据，以及在步骤506后再下发待绑定银行卡的卡应用及个人化数据。
可见，在该实现方式中，通过上述步骤501至步骤508，通过第三方可信服务器分别与第一银行服务器、第二银行服务器交互以完成依次绑定各个待绑定银行卡。
至此，通过上述图3、图4或图5所示的实现方式可完成仅根据待验证银行卡的验证信息绑定所有待绑定银行卡。
需要说明的是，在图3或图4或图5所示的实现方式中，卡应用由相应的银行服务器在对用户身份验证通过后下发到终端。可选的，还可以通过其他方式下载卡应用。例如：电子钱包APP在确定了至少两个银行卡之后但尚未确定待验证银行卡以及其余待绑定银行卡之前，也可以直接由电子钱包服务器依次从已确定的各个银行卡分别对应的银行服务器下载卡应用，并逐个向系统进行卡应用的注册。然后，在确定了待验证银行卡和待绑定银行卡后对已下载的卡应用进行个人化时，仅对待验证银行卡和待绑定银行卡的卡应用进行个人化。当然，在完成个人化操作时，可类似前面实施例描述的方式通过电子钱包服务器请求各个银行服务器对上述的待验证银行卡的验证信息进行验证通过后下发相应的个人化数据。
此外，在完成绑定所有待绑定银行卡的卡应用后，实际应用中，还要建立卡应用与相应账户的关联，以便于在用户使用该已完成绑定的卡应用进行NFC支付时，可通过以下任意一种方式实现从相应的账户扣费：(1)将所有已绑定的卡应用与待验证银行卡的账户进行关联，即用户后续刷卡消费时是从待验证银行卡的账户中进行扣费等。(2)将每个已绑定的卡应用与用户先前在该卡应用所属银行已开通的银行卡账户进行关联，即用户后续刷卡消费时是从在该卡应用所属银行已开通的银行卡账户中进行扣费。示例性的，采用本申请实施例提供的上述方法，终端中绑定了招商银行的卡应用，如果终端之前已经在招商银行开通了某个账户，那么建立该招商银行的卡应用与该已开通招商银行账户之间的关联关系。后续在使用该终端已绑定的招商银行卡应用进行NFC支付时，从已开通的招商银行账户中扣款。(3)将每个已绑定的卡应用与该卡应用所属银行在本次绑卡中以在线方式为其新开通的卡账户进行关联，而该卡账户可与上述待验证银行卡的账户进行关联，以允许用户从待验证银行卡的账户向该卡的账户进行转账，以用户后续刷卡消费。例如，用户在该终端的电子钱包APP中绑定中信银行的卡应用和招商银行的卡应用时，中信银行的服务器通过在线方式(与目前的柜台当面开户方式不同)给该中信银行卡应用开通了一个对应的账户，招商银行的服务器通过在线方式为该招商银行卡应用开通了一个对应的账户，用户后续可通过转账的方式从待验证银行卡(如中国银行的储 蓄卡)的账户向这两个账户中进行转账，这样，用户使用中信银行的卡应用刷卡消费时可以从其对应的账户上扣费，使用招商银行的卡应用刷卡消费时可以从其对应的账户上扣费。
除了应用在NFC支付的场景下，还可根据本申请实施例提供的方法所示的原理进行扩展以应用在使用二维码支付的场景下。目前，对于电子钱包的二维码支付功能，其只支持已绑定银行卡生成其对应的二维码，如某个电子钱包APP绑定了A、B两个银行卡，则银行卡A可生成自己的二维码供自己所属服务器进行验证，银行B可生成自己的二维码供自己所属服务器进行验证。在使用二维码支付时，可能不同商店针对不同银行卡有不同的优惠活动，为了尽量享受各家银行提供的优惠的需求，用户需要尽可能多的绑定银行卡，这种情况下，用户同样需要逐个输入银行卡的相关信息，也即同样存在绑卡操作比较繁琐的问题。因此，为了简化绑卡操作，本申请实施例中，用户只需要绑定一张银行卡，然后使用该已绑定银行卡的信息向其他银行请求二维码或者生成二维码所必需的数据(如密钥种子等)。针对这种二维码支付场景，本申请实施例提供的方案的具体为：(1)确定最适合本次支付的银行卡，如本次支付优惠力度最大的银行。可选的，根据终端当前位置信息推荐优惠力度最大的银行，或者根据用户当前所在商店的信息推荐优惠力度最大的银行，或者采用其他方式确定。(2)之后经过用户授权后使用电子钱包中已绑定的银行卡的信息作为待验证银行卡的验证信息向步骤(1)中所确定银行的服务器发送请求，用于请求生成其对应的二维码或生成其对应二维码所必需的数据。(3)该所确定银行的服务器根据待验证银行卡的验证信息验证通过后向该终端下发的二维码或生成二维码所必需的相关数据，如二维码密钥种子等，该验证过程可参考图3或图4或图5所示的实现方式。(4)终端可根据接收到的该相关数据生成相应的二维码。(5)之后，用户可根据该二维码完成支付，如用户向商家呈现该二维码供商家扫码，以完成扣费。
上述主要从终端和电子钱包服务器如何完成绑卡过程的角度对本申请实施例提供的方案进行了介绍。可以理解的是，终端和电子钱包服务器为了实现上述功能，其包含了执行各个功能相应的功能模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例以及步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
当然，还可以根据上述方法示例对终端和电子钱包服务器进行划分，例如，可以对应各个功能划分各个模块或者单元，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件模块或者单元的形式实现。其中，本申请实施例中对模块或者单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
图6示出了上述实施例中所涉及的终端的一种可能的结构示意图。该终端600包括存储单元601、处理单元602、显示单元603、输入单元604和通信单元605。
其中，存储单元601用于存储一个或多个程序代码。处理单元602用于执行存储单元601存储的程序代码执行图3中的步骤304、310、图4中的步骤408、图5中步骤的508和/或用于本文所描述的技术的其它过程。显示单元603用于显示图2A至图2F所示的界面。输入单元604用于实现用户与电子设备的交互和/或信息输入到终端中。例如，输入 单元可以接收用户输入的数字或字符信息，以产生与用户设置或功能控制有关的信号输入。输入单元604用于接收用户在图2A至图2F所示的界面中的输入操作。通信单元605用于终端600和其他设备通信，如支持终端执行图3中的步骤301、303、305、309，图4中的步骤401、403、407，图5中的步骤501、507和/或用于本文所描述的其他过程。
当然，终端600包括但不限于上述所列举的单元模块，并且上述单元的具体所能够实现的功能也包括但不限于上述实施例所述的方法步骤对应的功能，终端600的各个单元详细描述可以参考其所对应方法步骤的详细描述，本申请实施例这里不再赘述。
可选的，所述存储单元601可包含在终端100中的存储器103中实现，所述处理单元602可包含在终端100中的处理器101中实现。所述显示单元603可包含在终端100中的显示器104中实现。所述通信单元604可包含在终端100中的射频电路102中实现。所述输入单元604可包含在终端100的触控板104-1中实现，当然在本申请具体实施方式中，输入单元604还可以是其他人机交互界面，例如实体输入键、麦克风等，还可是其他外部信息撷取装置，例如摄像头、麦克风、物理键盘、功能键、轨迹球、鼠标、操作杆等中的一种或多种。
图7示出了上述实施例中所涉及的电子钱包服务器的一种可能的结构示意图。该电子钱包服务器700包括存储单元701、处理单元702和通信单元703。
其中，存储单元701用于存储一个或多个程序代码。处理单元702用于执行存储单元701存储的程序代码执行确定终端要显示的至少两个银行卡以及本文所描述的技术的其它过程。通信单元703用于电子钱包服务器700和其他设备通信，如支持电子钱包服务器执行图3中的步骤301、302、303、305、306、309，图4中的步骤401、402、403、407，图5中的步骤501、502、507和/或用于本文所描述的其他过程。
当然，电子钱包服务器700包括但不限于上述所列举的单元模块，并且上述单元的具体所能够实现的功能也包括但不限于上述实施例所述的方法步骤对应的功能，电子钱包服务器700的各个单元详细描述可以参考其所对应方法步骤的详细描述，本申请实施例这里不再赘述。
其中，如图8所示，存储单元701可以是电子钱包服务器800中的存储器801，该存储器801可以包括易失性存储器，例如随机存取存储器；该存储器也可以包括非易失性存储器，例如只读存储器，快闪存储器，硬盘或固态硬盘；该存储器还可以包括上述种类的存储器的组合。
处理单元702可以是该电子钱包服务器800中的控制器或处理器802，该控制器或处理器802可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。该处理器或控制器可以是中央处理器，通用处理器，数字信号处理器，专用集成电路，现场可编程门阵列或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合等。
通信单元703可以是基站中的收发器、收发电路或通信接口803等。
电子钱包服务器800还包括总线804，该总线804可以是扩展工业标准结构(Extended Industry Standard Architecture，EISA)总线等。总线804可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一条粗线表示，但并不表示仅有一根总线或一种类型 的总线。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，各个单元相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：快闪存储器、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (35)

  1. 一种绑卡方法，其特征在于，应用于终端，所述方法包括：
    显示第一界面，所述第一界面显示有与所述电子钱包应用程序APP当前登录的账号关联的至少两个银行卡；
    从所述至少两个银行卡中确定待验证银行卡以及至少一个待绑定银行卡；
    显示第二界面，所述第二界面用于提示用户输入所述待验证银行卡的验证信息；
    向服务器发送所述验证信息以请求服务器在根据所述验证信息验证通过后向所述终端下发每个所述待绑定银行卡对应的卡应用及个人化数据以完成绑定所述至少一个待绑定银行卡。
  2. 根据权利要求1所述的方法，其特征在于，在显示第一界面之前，所述方法还包括：
    接收用户通过电子钱包APP输入的触发操作；
    其中，所述触发操作包括：用户在所述电子钱包APP的登录界面输入的登录操作；或者，用户成功登录所述电子钱包APP后，通过预设入口输入的添加待绑定银行卡的操作。
  3. 根据权利要求1所述的方法，其特征在于，所述从所述至少两个银行卡中确定待验证银行卡以及至少一个待绑定银行卡，包括：
    根据用户的选择操作从所述至少两个银行卡中确定所述待验证银行卡以及所述至少一个待绑定银行卡；
    或者，按照预设规则从所述至少两个银行卡中确定所述待验证银行卡以及所述至少一个待绑定银行卡，所述预设规则包括：将历史使用次数大于预设阈值的银行卡确定为待验证银行卡或将所述至少两个银行卡中任意一张确定为待验证银行卡。
  4. 根据权利要求1至3任一项所述的方法，其特征在于，所述方法还包括：
    显示每个所述待绑定银行卡对应的卡应用的安装进度。
  5. 根据权利要求1至4任一项所述的方法，其特征在于，所述待验证银行卡为所述至少一个待绑定银行卡中的其中一个或多个。
  6. 根据权利要求1至5任一项所述的方法，其特征在于，在显示与所述电子钱包APP当前登录的账号关联的至少两个银行卡之前，所述方法还包括：
    确定与所述电子钱包APP当前登录的账号关联的所述至少两个银行卡。
  7. 根据权利要求6所述的方法，其特征在于，所述确定与所述电子钱包APP当前登录的账号关联的所述至少两个银行卡包括：
    获取与所述账号关联的第一历史绑卡记录；
    如果获取到与所述账号关联的第二历史绑卡记录，则将不包含在所述第二历史绑卡记录但包含在所述第一历史绑卡记录中的卡应用的标识对应的银行卡确定为所述至少两个银行卡；
    或者，
    如果未获取到所述第二历史绑卡记录，则将所述第一历史绑卡记录中的卡应用的标识对应的银行卡确定为所述至少两个银行卡；
    其中，所述第一历史绑卡记录中包括与所述账号关联的所有卡应用的标识；所述第二历史绑卡记录中包括所述账号在所述终端上登录时绑定的卡应用的标识。
  8. 根据权利要求7所述的方法，其特征在于，所述获取与所述账号关联的第一历史绑卡记录，包括：
    从所述服务器获取所述第一历史绑卡记录。
  9. 根据权利要求7所述的方法，其特征在于，所述获取与所述账号关联的第二历史绑卡记录，包括：
    查找本地保存的列表得到所述第二历史绑卡记录；其中，所述列表中保存有所述账号在所述终端上登录时绑定的卡应用的标识；
    或者
    从所述服务器获取所述第二历史绑卡记录。
  10. 根据权利要求6所述的方法，其特征在于，所述确定与所述电子钱包APP当前登录的账号关联的所述至少两个银行卡，还包括：
    接收所述服务器发送的第三历史绑卡记录；所述第三历史绑卡记录中包括与所述账号关联且所述终端本地未绑定的卡应用的标识；
    将所述第三历史绑卡记录中的卡应用的标识对应的银行卡确定为所述至少两个银行卡。
  11. 根据权利要求6所述的方法，其特征在于，所述确定与所述电子钱包APP当前登录的账号关联的至少两个银行卡，还包括：
    将所述电子钱包APP所支持的所有银行卡确定为与所述电子钱包APP当前登录的账号关联的所述至少两个银行卡。
  12. 根据权利要求1至11任一项所述的方法，其特征在于，所述方法还包括：
    向电子钱包服务器发送所述至少一个待绑定银行卡的标识以便于所述电子钱包服务器根据所述至少一个待绑定银行卡的标识请求银行服务器向终端下发待绑定银行卡对应的卡应用及个人化数据。
  13. 根据权利要求1至12任一项所述的方法，其特征在于，所述向服务器发送所述验证信息以请求服务器在根据所述验证信息验证通过后向所述终端下发每个所述待绑定银行卡对应的卡应用及个人化数据，包括：
    向电子钱包服务器发送第一请求以便于所述电子钱包服务器请求第一银行服务器对所述验证信息验证通过后向终端下发所述待验证银行卡对应的卡应用及个人化数据；
    其中，所述第一请求中携带所述验证信息，所述第一银行服务器为所述待验证银行卡对应的银行服务器，所述个人化数据中携带互信凭证；
    在接收所述待验证银行卡对应的卡应用及个人化数据后，向所述电子钱包服务器发送第二请求以便于所述电子钱包服务器请求第二银行服务器与第一银行服务器之间对所述互信凭证验证通过后向所述终端下发所述待绑定银行卡对应的卡应用及个人化数据；
    其中，所述第二请求中携带所述互信凭证；所述第二银行服务器包括任意一个所述待绑定银行卡对应的银行服务器。
  14. 根据权利要求1至12任一项所述的方法，其特征在于，所述向服务器发送所述验证信息以请求服务器在根据所述验证信息验证通过后向所述终端下发每个所述待绑定银行卡对应的卡应用及个人化数据，包括：
    向电子钱包服务器发送请求以便于所述电子钱包服务器分别请求第一银行服务器和第二银行服务器在根据所述验证信息验证通过后由所述第一银行服务器向所述终端下发 所述待验证银行卡对应的卡应用和个人化数据以及由所述第二银行服务器向所述终端下发所述待绑定银行卡对应的卡应用和个人化数据；
    其中，所述请求中携带所述待验证银行卡的验证信息，所述第一银行服务器为所述待验证银行卡对应的银行服务器，所述第二银行服务器为任意一个所述待绑定银行卡对应的银行服务器。
  15. 根据权利要求1至12任一项所述的方法，其特征在于，所述向服务器发送所述验证信息以请求服务器在根据所述验证信息验证通过后向所述终端下发每个所述待绑定银行卡对应的卡应用及个人化数据，包括：
    向电子钱包服务器发送请求以便于所述电子钱包服务器通过第三方可信服务器分别请求第一银行服务器和第二银行服务器在根据所述验证信息验证通过后分别向所述终端下发每个所述待绑定银行卡对应的卡应用和个人化数据；
    其中，所述第一银行服务器为所述待验证银行卡对应的银行服务器，所述第二银行服务器为任意一个所述待绑定银行卡对应的银行服务器。
  16. 根据权利要求14或15所述的方法，其特征在于，所述请求中携带的所述验证信息为加密后的验证信息。
  17. 一种终端，其特征在于，包括：
    显示单元，用于显示第一界面，所述第一界面显示有与所述电子钱包应用程序APP当前登录的账号关联的至少两个银行卡；
    处理单元，用于从所述至少两个银行卡中确定待验证银行卡以及至少一个待绑定银行卡；
    所述显示单元，还用于显示第二界面，所述第二界面用于提示用户输入所述待验证银行卡的验证信息；
    通信单元，用于向服务器发送所述验证信息以请求服务器在根据所述验证信息验证通过后向所述终端下发每个所述待绑定银行卡对应的卡应用及个人化数据以完成绑定所述至少一个待绑定银行卡。
  18. 根据权利要求17所述的终端，其特征在于，还包括：
    输入单元，用于接收用户通过电子钱包APP输入的触发操作；
    其中，所述触发操作包括：用户在所述电子钱包APP的登录界面输入的登录操作；或者，用户成功登录所述电子钱包APP后，通过预设入口输入的添加待绑定银行卡的操作。
  19. 根据权利要求17所述的终端，其特征在于，
    所述处理单元，还用于根据用户的选择操作从所述至少两个银行卡中确定所述待验证银行卡以及所述至少一个待绑定银行卡；
    或者，按照预设规则从所述至少两个银行卡中确定所述待验证银行卡以及所述至少一个待绑定银行卡，所述预设规则包括：将历史使用次数大于预设阈值的银行卡确定为待验证银行卡或将所述至少两个银行卡中任意一张确定为待验证银行卡。
  20. 根据权利要求17至19任一项所述的终端，其特征在于，
    所述显示单元，还用于显示每个所述待绑定银行卡对应的卡应用的安装进度。
  21. 根据权利要求17至20任一项所述的终端，其特征在于，所述待验证银行卡为所述至少一个待绑定银行卡中的其中一个或多个。
  22. 根据权利要求17至21任一项所述的终端，其特征在于，
    所述处理单元还用于确定与所述电子钱包APP当前登录的账号关联的所述至少两个银行卡。
  23. 根据权利要求22所述的终端，其特征在于，
    所述处理单元，还用于获取与所述账号关联的第一历史绑卡记录；
    如果获取到与所述账号关联的第二历史绑卡记录，则将不包含在所述第二历史绑卡记录但包含在所述第一历史绑卡记录中的卡应用的标识对应的银行卡确定为所述至少两个银行卡；
    或者，
    如果未获取到所述第二历史绑卡记录，则将所述第一历史绑卡记录中的卡应用的标识对应的银行卡确定为所述至少两个银行卡；
    其中，所述第一历史绑卡记录中包括与所述账号关联的所有卡应用的标识；所述第二历史绑卡记录中包括所述账号在所述终端上登录时绑定的卡应用的标识。
  24. 根据权利要求23所述的终端，其特征在于，
    所述处理单元，还用于从所述服务器获取所述第一历史绑卡记录。
  25. 根据权利要求23所述的终端，其特征在于，
    所述处理单元，还用于查找本地保存的列表得到所述第二历史绑卡记录；其中，所述列表中保存有所述账号在所述终端上登录时绑定的卡应用的标识；
    或者
    从所述服务器获取所述第二历史绑卡记录。
  26. 根据权利要求22所述的终端，其特征在于，
    所述通信单元，还用于接收所述服务器发送的第三历史绑卡记录；所述第三历史绑卡记录中包括与所述账号关联且所述终端本地未绑定的卡应用的标识；
    所述处理单元，还用于将所述第三历史绑卡记录中的卡应用的标识对应的银行卡确定为所述至少两个银行卡。
  27. 根据权利要求22所述的终端，其特征在于，
    所述处理单元，还用于将所述电子钱包APP所支持的所有银行卡确定为与所述电子钱包APP当前登录的账号关联的所述至少两个银行卡。
  28. 根据权利要求17至27任一项所述的终端，其特征在于，
    所述通信单元，还用于向电子钱包服务器发送所述至少一个待绑定银行卡的标识以便于所述电子钱包服务器根据所述至少一个待绑定银行卡的标识请求银行服务器向终端下发待绑定银行卡对应的卡应用及个人化数据。
  29. 根据权利要求17至28任一项所述的终端，其特征在于，
    所述通信单元，还用于向电子钱包服务器发送第一请求以便于所述电子钱包服务器请求第一银行服务器对所述验证信息验证通过后向终端下发所述待验证银行卡对应的卡应用及个人化数据；
    其中，所述第一请求中携带所述验证信息，所述第一银行服务器为所述待验证银行卡对应的银行服务器，所述个人化数据中携带互信凭证；
    在接收所述待验证银行卡对应的卡应用及个人化数据后，向所述电子钱包服务器发送第二请求以便于所述电子钱包服务器请求第二银行服务器与第一银行服务器之间对所述互信凭证验证通过后向所述终端下发所述待绑定银行卡对应的卡应用及个人化数据；
    其中，所述第二请求中携带所述互信凭证；所述第二银行服务器包括任意一个所述待绑定银行卡对应的银行服务器。
  30. 根据权利要求17至28任一项所述的终端，其特征在于，
    所述通信单元，还用于向电子钱包服务器发送请求以便于所述电子钱包服务器分别请求第一银行服务器和第二银行服务器在根据所述验证信息验证通过后由所述第一银行服务器向所述终端下发所述待验证银行卡对应的卡应用和个人化数据以及由所述第二银行服务器向所述终端下发所述待绑定银行卡对应的卡应用和个人化数据；
    其中，所述请求中携带所述待验证银行卡的验证信息，所述第一银行服务器为所述待验证银行卡对应的银行服务器，所述第二银行服务器为任意一个所述待绑定银行卡对应的银行服务器。
  31. 根据权利要求17至28任一项所述的终端，其特征在于，
    所述通信单元，还用于向电子钱包服务器发送请求以便于所述电子钱包服务器通过第三方可信服务器分别请求第一银行服务器和第二银行服务器在根据所述验证信息验证通过后分别向所述终端下发每个所述待绑定银行卡对应的卡应用和个人化数据；
    其中，所述第一银行服务器为所述待验证银行卡对应的银行服务器，所述第二银行服务器为任意一个所述待绑定银行卡对应的银行服务器。
  32. 根据权利要求30或31所述的终端，其特征在于，所述请求中携带的所述验证信息为加密后的验证信息。
  33. 一种终端，其特征在于，包括：一个或多个处理器、显示器、存储器和通信接口；
    所述存储器用于存储计算机执行指令，当所述终端运行时，所述处理器执行所述存储器存储的所述计算机执行指令，以使所述终端执行如权利要求1至16中任一项所述的绑卡方法。
  34. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当所述指令在终端上运行时，使得所述终端执行如权利要求1至16中任一项所述的绑卡方法。
  35. 一种计算机程序产品，其特征在于，所述计算机程序产品包括软件代码，所述软件代码用于执行上述权利要求1至16中任一项所述的方法。
PCT/CN2018/117178 2017-11-29 2018-11-23 绑卡方法及终端 WO2019105296A1 (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP23183519.0A EP4307198A3 (en) 2017-11-29 2018-11-23 Card binding method and terminal
US16/767,879 US20200372490A1 (en) 2017-11-29 2018-11-23 Card Binding Method and Terminal
EP18882735.6A EP3693911B1 (en) 2017-11-29 2018-11-23 Card linking method and terminal
US18/623,603 US20240249273A1 (en) 2017-11-29 2024-04-01 Card Binding Method and Terminal

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN201711227577.6 2017-11-29
CN201711227577 2017-11-29
CN201810016329.5A CN109842605B (zh) 2017-11-29 2018-01-08 绑卡方法及终端
CN201810016329.5 2018-01-08

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US16/767,879 A-371-Of-International US20200372490A1 (en) 2017-11-29 2018-11-23 Card Binding Method and Terminal
US18/623,603 Continuation US20240249273A1 (en) 2017-11-29 2024-04-01 Card Binding Method and Terminal

Publications (1)

Publication Number Publication Date
WO2019105296A1 true WO2019105296A1 (zh) 2019-06-06

Family

ID=66663807

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/117178 WO2019105296A1 (zh) 2017-11-29 2018-11-23 绑卡方法及终端

Country Status (3)

Country Link
US (1) US20240249273A1 (zh)
EP (1) EP4307198A3 (zh)
WO (1) WO2019105296A1 (zh)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110363511A (zh) * 2019-06-10 2019-10-22 阿里巴巴集团控股有限公司 基于ic卡的业务实现方法、虚拟ic卡和移动终端
CN111061502A (zh) * 2019-12-19 2020-04-24 贵阳货车帮科技有限公司 一种安装包获取方法、装置、设备和存储介质
US10748054B2 (en) 2016-07-08 2020-08-18 Alibaba Group Holding Limited Two-dimensional code information query method, server, client, and system
CN112070225A (zh) * 2020-09-01 2020-12-11 多点(深圳)数字科技有限公司 一种基于无监督学习的实体卡异常绑卡报警的方法
CN112258177A (zh) * 2020-10-16 2021-01-22 中国工商银行股份有限公司 银联卡注册电子钱包和支付的方法、终端、设备及介质
US10902415B2 (en) * 2018-01-23 2021-01-26 Advanced New Technologies Co., Ltd. Payment card binding method, trust evaluation method, apparatus, and electronic device
CN112492518A (zh) * 2020-12-09 2021-03-12 深圳市欢太科技有限公司 卡片确定方法、装置、电子设备及存储介质
CN112825173A (zh) * 2020-11-03 2021-05-21 中国银联股份有限公司 卡片交易安全验证方法以及移动终端
CN113807843A (zh) * 2021-09-06 2021-12-17 中国银联股份有限公司 绑卡方法、用户终端、服务器、系统及存储介质

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230367643A1 (en) * 2022-05-12 2023-11-16 Bank Of America Corporation System for identification and management of layered dependent resource distribution devices

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101017583A (zh) * 2006-02-10 2007-08-15 刘明晶 安全地绑定银行帐号与个人终端的方法
CN102184499A (zh) * 2011-05-27 2011-09-14 钱袋网（北京）信息技术有限公司 账户信息绑定方法、金融交易方法及移动终端
CN104065639A (zh) * 2013-11-06 2014-09-24 腾讯科技（深圳）有限公司 银行卡的绑定方法及系统
CN104933563A (zh) * 2015-06-23 2015-09-23 上海卓易科技股份有限公司 一种支付银行卡的方法及装置
CN107146076A (zh) * 2017-04-10 2017-09-08 广州智造家网络科技有限公司 安全交易方法及系统

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1569405A1 (en) * 2004-02-27 2005-08-31 Telefonaktiebolaget LM Ericsson (publ) Technique for creation and linking of communications network user accounts
US8031207B2 (en) * 2008-06-04 2011-10-04 Mastercard International, Inc. Card image description format to economize on data storage
US20100063906A1 (en) * 2008-09-05 2010-03-11 Giftango Corporation Systems and methods for authentication of a virtual stored value card
US20100076833A1 (en) * 2008-09-19 2010-03-25 Giftango Corporation Systems and methods for managing and using a virtual card
US20100125495A1 (en) * 2008-11-17 2010-05-20 Smith Steven M System and method of providing a mobile wallet at a mobile telephone
US20100125510A1 (en) * 2008-11-17 2010-05-20 Smith Steven M System and method of conducting transactions using a mobile wallet system
US8918855B2 (en) * 2011-12-09 2014-12-23 Blackberry Limited Transaction provisioning for mobile wireless communications devices and related methods
US8763896B2 (en) * 2012-02-23 2014-07-01 XRomb Inc. System and method of loading a transaction card and processing repayment on a mobile device
US20140279115A1 (en) * 2013-03-15 2014-09-18 Samsung Electronics Co., Ltd. Mobile payment using cloud computing
US11017384B2 (en) * 2014-05-29 2021-05-25 Apple Inc. Apparatuses and methods for using a primary user device to provision credentials onto a secondary user device
US20170032362A1 (en) * 2015-07-31 2017-02-02 Ca, Inc. Streamlined enrollment of credit cards in mobile wallets
US20170278095A1 (en) * 2016-03-28 2017-09-28 Microsoft Technology Licensing, Llc Mobile payment system and method

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101017583A (zh) * 2006-02-10 2007-08-15 刘明晶 安全地绑定银行帐号与个人终端的方法
CN102184499A (zh) * 2011-05-27 2011-09-14 钱袋网（北京）信息技术有限公司 账户信息绑定方法、金融交易方法及移动终端
CN104065639A (zh) * 2013-11-06 2014-09-24 腾讯科技（深圳）有限公司 银行卡的绑定方法及系统
CN104933563A (zh) * 2015-06-23 2015-09-23 上海卓易科技股份有限公司 一种支付银行卡的方法及装置
CN107146076A (zh) * 2017-04-10 2017-09-08 广州智造家网络科技有限公司 安全交易方法及系统

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10748054B2 (en) 2016-07-08 2020-08-18 Alibaba Group Holding Limited Two-dimensional code information query method, server, client, and system
US10902415B2 (en) * 2018-01-23 2021-01-26 Advanced New Technologies Co., Ltd. Payment card binding method, trust evaluation method, apparatus, and electronic device
CN110363511A (zh) * 2019-06-10 2019-10-22 阿里巴巴集团控股有限公司 基于ic卡的业务实现方法、虚拟ic卡和移动终端
CN110363511B (zh) * 2019-06-10 2023-08-11 创新先进技术有限公司 基于ic卡的业务实现方法、虚拟ic卡和移动终端
CN111061502A (zh) * 2019-12-19 2020-04-24 贵阳货车帮科技有限公司 一种安装包获取方法、装置、设备和存储介质
CN112070225A (zh) * 2020-09-01 2020-12-11 多点(深圳)数字科技有限公司 一种基于无监督学习的实体卡异常绑卡报警的方法
CN112070225B (zh) * 2020-09-01 2023-10-10 多点(深圳)数字科技有限公司 一种基于无监督学习的实体卡异常绑卡报警的方法
CN112258177A (zh) * 2020-10-16 2021-01-22 中国工商银行股份有限公司 银联卡注册电子钱包和支付的方法、终端、设备及介质
CN112258177B (zh) * 2020-10-16 2024-01-30 中国工商银行股份有限公司 银联卡注册电子钱包和支付的方法、终端、设备及介质
CN112825173A (zh) * 2020-11-03 2021-05-21 中国银联股份有限公司 卡片交易安全验证方法以及移动终端
CN112825173B (zh) * 2020-11-03 2024-02-09 中国银联股份有限公司 卡片交易安全验证方法以及移动终端
CN112492518A (zh) * 2020-12-09 2021-03-12 深圳市欢太科技有限公司 卡片确定方法、装置、电子设备及存储介质
CN112492518B (zh) * 2020-12-09 2023-08-15 深圳市欢太数字科技有限公司 卡片确定方法、装置、电子设备及存储介质
CN113807843A (zh) * 2021-09-06 2021-12-17 中国银联股份有限公司 绑卡方法、用户终端、服务器、系统及存储介质
CN113807843B (zh) * 2021-09-06 2023-10-20 中国银联股份有限公司 绑卡方法、用户终端、服务器、系统及存储介质

Also Published As

Publication number Publication date
EP4307198A3 (en) 2024-01-31
US20240249273A1 (en) 2024-07-25
EP4307198A2 (en) 2024-01-17

Similar Documents

Publication Publication Date Title
EP3693911B1 (en) Card linking method and terminal
WO2019105296A1 (zh) 绑卡方法及终端
US11887110B2 (en) Methods and systems for processing transactions on a value dispensing device using a mobile device
US8306916B2 (en) Method and system for digital document management on a mobile device
US20210287204A1 (en) Near Field Communication NFC-Based Transaction Method and Device
RU2604433C2 (ru) Метод и система процессинга электронного документооборота без использования карт
CN107005619B (zh) 一种注册移动销售点终端pos的方法、对应装置及系统
US20120284195A1 (en) Method and system for secure user registration
CN112258206A (zh) 道具资源获取方法、装置、电子设备及存储介质
US20240202714A1 (en) Methods and systems for processing transactions on a value dispensing device using a mobile device

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18882735

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2018882735

Country of ref document: EP

Effective date: 20200504

NENP Non-entry into the national phase

Ref country code: DE