绑卡方法及终端与流程

本申请涉及移动支付
技术领域：
，尤其涉及一种绑卡方法及终端。
背景技术：
：移动支付已广泛普及。用户可通过手机等终端上安装的应用程序(application，app)进行支付。常见的移动支付类app(或者：电子钱包app)包括各个手机厂商推出的电子钱包类应用，如华为钱包、applepay等，银行等金融机构推出的手机银行客户端等以及第三方支付服务商推出的微信支付、支付宝等第三方支付应用。目前，用户在电子钱包上注册账户信息后，在电子钱包中添加并绑定银行卡。之后，用户可使用电子钱包完成支付。一些电子钱包支持线上支付和线下支付两种支付方式，如华为钱包、银联钱包、移动和包等。其中，线上支付主要针对网上购物场景，如网页支付、应用内支付(in-apppayment)。终端在联网的状态下，用户可使用电子钱包app中绑定的银行卡进行支付；当然，若终端未联网，只要商户侧收款终端能够联网，也可以使用电子钱包app中绑定的银行卡进行支付，如二维码支付。线下支付主要针对销售点(pointofsale，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为本申请实施例提供的另一种电子钱包服务器的结构示意图。具体实施方式用于执行本申请实施例提供的绑卡方法的终端，具体可以为手机、可穿戴设备、增强现实(augmentedreality，ar)\虚拟现实(virtualreality，vr)设备、平板电脑、笔记本电脑、超级移动个人计算机(ultra-mobilepersonalcomputer，umpc)、上网本、个人数字助理(personaldigitalassistant，pda)等具有nfc支付功能的任意终端。当然，在以下实施例中，对该终端的具体形式不作任何限制。示例性的，如图1所示，终端100具体可以包括：处理器101、射频(radiofrequency，rf)电路102、存储器103、触摸屏104、蓝牙装置105、一个或多个传感器106、无线保真(wireless-fidelity，wi-fi)装置107、定位装置108、音频电路109、外设接口110、电源系统111以及近场通信(nearfieldcommunication，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可以包括高速随机存取存储器(ramdomaccessmemory，ram)，还可以包括非易失存储器，例如磁盘存储器件、闪存器件或其他易失性固态存储器件等。存储器103可以存储各种操作系统，例如，苹果公司所开发的操作系统，谷歌公司所开发的操作系统等。上述存储器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具体可以是全球定位系统(globalpositioningsystem，gps)或北斗卫星导航系统、俄罗斯glonass等定位系统的接收器。定位装置108在接收到上述定位系统发送的地理位置后，将该信息发送给处理器101进行处理，或者发送给存储器103进行保存。在另外的一些实施例中，该定位装置108还可以是辅助全球卫星定位系统(assistedglobalpositioningsystem，agps)的接收器，agps系统通过作为辅助服务器来协助定位装置108完成测距和定位服务，在这种情况下，辅助定位服务器通过无线通信网络与终端例如终端100的定位装置108(即gps接收器)通信而提供定位协助。在另外的一些实施例中，该定位装置108也可以是基于wi-fi接入点的定位技术。由于每一个wi-fi接入点都有一个全球唯一的媒体介入控制(mediaaccesscontrol，mac)地址，终端在开启wi-fi的情况下即可扫描并收集周围的wi-fi接入点的广播信号，因此可以获取到wi-fi接入点广播出来的mac地址；终端将这些能够标示wi-fi接入点的数据(例如mac地址)通过无线通信网络发送给位置服务器，由位置服务器检索出每一个wi-fi接入点的地理位置，并结合wi-fi广播信号的强弱程度，计算出该终端的地理位置并发送到该终端的定位装置108中。nfc装置112，用于为终端提供nfc功能以支持各类nfc业务，如将终端模拟成卡片后直接靠近销售点终端(pointofsale，pos)完成刷卡支付的nfc支付、将终端作为读写器直接靠近物理卡片完成读取卡中的数据的nfc读卡、nfc数据传输等。nfc装置112包括nfc控制器(nearfieldcommunicationcntroller，nfcc)，其功能包括射频信号的调制解调以及nfc协议处理。nfcc连接射频天线(即nfc天线)实现nfc信号的发送与接收。可选的，为了实现nfc业务，尤其是nfc支付，手机中还可能包括安全模块(securityelement，se)。se用于对敏感信息的安全存储和对交易事务提供安全的执行环境，可以集成在处理器101中，或者位于手机的客户识别模块(subscriberidentificationmodule，sim)卡，或者位于手机的安全数字存储卡(securedigitalmemorycard，sd)中，也可以为独立的芯片。nfcc可以和se互相连接。音频电路109、扬声器113、麦克风114可提供用户与终端100之间的音频接口。音频电路109可将接收到的音频数据转换后的电信号，传输到扬声器113，由扬声器113转换为声音信号输出；另一方面，麦克风114将收集的声音信号转换为电信号，由音频电路109接收后转换为音频数据，再将音频数据输出至rf电路102以发送给比如另一手机，或者将音频数据输出至存储器103以便进一步处理。外设接口110，用于为外部的输入/输出设备(例如键盘、鼠标、外接显示器、外部存储器、用户识别模块卡等)提供各种接口。例如通过通用串行总线(universalserialbus，usb)接口与鼠标连接，通过用户识别模块卡卡槽上的金属触点与电信运营商提供的用户识别模块卡(subscriberidentificationmodule，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中示出了用户在huaweimate10上绑定过中国银行卡以及在荣耀9上绑定过交通银行。这样，用户可根据这些提示信息选择要绑定的银行卡。可选的，上述方法中，在显示与所述电子钱包app当前登录的账号关联的至少两个银行卡之前，终端可通过以下实现方式确定界面202a或202b或202c中所显示的与所述电子钱包app当前登录的账号关联的至少两个银行卡：实现方式一、终端获取与所述账号关联的第一历史绑卡记录，该第一历史绑卡记录是指包含与所述账号关联的所有卡应用的标识的列表或其他记录形式。进一步的，终端尝试获取与所述账号关联的第二历史绑卡记录，该第二历史绑卡记录是指包含在当前终端上登录所述账号时绑定的卡应用的标识的列表或其他记录形式。如果终端获取到与所述账号关联的第二历史绑卡记录，则将不包含在所述第二历史绑卡记录但包含在所述第一历史绑卡记录中的卡应用的标识对应的银行卡确定为所述至少两个银行卡。如果终端未获取到所述第二历史绑卡记录，则将所述第一历史绑卡记录中的卡应用的标识对应的银行卡确定为所述至少两个银行卡。其中，所述第一历史绑卡记录为与该账号关联的所有绑卡记录。也即，第一历史绑卡记录包括用户在每个终端(包括当前终端以及其他终端)上登录该当前账号后通过绑卡操作绑定的所有银行卡的记录的集合。可选的，该第一历史绑卡记录既包括当前仍然绑定的，还可能包括曾绑定但当前已解绑的。终端可从电子钱包服务器获取该第一历史绑卡记录。这种方式要求电子钱包服务器中保存在每个终端上登录当前账号时产生的绑卡记录。具体获取时，可以为终端登录当前账号后向电子钱包服务器发送请求以获取第一历史绑卡记录。例如：终端一旦检测到用户在某终端的电子钱包app上登录账号或者执行添加卡片的操作，则电子钱包app主动向电子钱包服务器请求获取第一历史绑卡记录。还可以为电子钱包服务器检测到当前账号在当前终端上登录电子钱包app后主动推送。例如，电子钱包服务器一旦检测到某一终端的上述登录或者添加卡片的操作就主动向该终端的电子钱包app推送上述第一历史绑卡记录。示例性的，所述第一历史绑卡记录如表一或表二或表三所示。表一表二表三需要说明的是，上述表一和表二中，电子钱包服务器向终端推送的第一历史绑卡记录中仅包括卡应用的标识，未区分每个卡应用所属的终端。而上述表三中，电子钱包服务器向终端推送的第一历史绑卡记录中除了包括卡应用的标识，还包括每个卡应用所属的终端的标识。此外，上述表一和表三中卡应用的标识以卡应用的类型(也即卡应用所属的银行及其类型，如某银行的储蓄卡、信用卡等)表示，上述表二中，卡应用的标识以应用标识(applicationidentifier，aid)表示，这两种表示方式均能表示其对应的银行卡。在其他实现方式中，还可以由卡应用的名称或者编号等信息表示。此外，表一或表二或表三中示出的第一历史绑卡记录中还包含卡应用的状态，实际上也可以不包含卡应用的状态。其中，所述第二历史绑卡记录包括当前终端上存在的与当前账号有效绑定的卡应用，此处所说的有效绑定的卡应用是指仍与当前账号绑定且尚未解绑或删除的卡应用。可选的，终端可本地查找得到所述第二历史绑卡记录。在该实现方式中，要求电子钱包app在终端本地维护一个记录，如将该记录保存在可信执行环境(trustedexecutionenvironment，tee)中，或者由tee中的一个可信应用(trustedapplication，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、电子钱包服务器向第一银行服务器发送请求。本申请实施例中，将待验证银行卡对应的银行服务器描述为第一银行服务器，将其余待绑定银行卡对应的银行服务器描述为第二银行服务器。本步骤中，电子钱包服务器收到终端的第一请求后，根据待验证银行卡的验证信息向第一银行服务器发送请求，该请求中包括所述验证信息，用于请求所述第一银行服务器根据所述验证信息进行验证。待验证银行卡的标识用于标识待验证银行卡所属的银行，即第一银行服务器。待验证银行卡和待绑定银行卡的标识可以为银行卡所属银行的名称、银行机构代码或银行服务地址等，或者，也可以为其他能表征该卡应用或其对应银行的标识，如iso7816中定义的aid，该aid中有注册的应用提供商标识rid(registeredapplicationprovideridentifier，可表示该卡应用提供商，如所属银行机构)，又如中国金融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可以是扩展工业标准结构(extendedindustrystandardarchitecture，eisa)总线等。总线804可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，各个单元相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：快闪存储器、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。当前第1页12