一种获取银行卡签约要素信息的方法、系统及设备与流程

本说明书涉及计算机
技术领域：
，尤其涉及一种获取银行卡签约要素信息的方法、系统及设备。
背景技术：
：在电子支付应用场景中，通常使用银行机构以外的第三方电子支付机构进行电子支付操作。为了简化第三方电子支付机构的电子支付流程，第三方电子支付机构的用户会将自身的银行卡与自身的电子支付机构签约，签约成功后用户可直接将此银行卡用于在此电子支付机构的快捷支付场景。在现有技术中，第三方电子支付机构与银行卡的签约过程通常是，用户在银行和支付机构通过手机短信、持卡人身份验证等手段同时完成信息匹配和验证，并完成银行卡和支付机构账号绑定的过程。在上述银行卡签约过程中，需要用户手动输入包含持卡人信息(姓名、身份信息、手机号)、银行卡信息(卡号、cvv2、有效期、卡bin营销标记)的签约要素信息。由于签约要素信息包含的信息繁琐且不方便记忆，很容易发生用户输入手误或用户忘记签约要素信息的情况，从而最终造成银行卡无法成功签约。技术实现要素：有鉴于此，本说明书实施例提供了一种获取银行卡签约要素信息的方法、系统及设备，用于解决在支付机构签约银行卡过程中无法获取准确的签约要素信息的问题。本说明书实施例采用下述技术方案：本说明书实施例提供一种获取银行卡签约要素信息的方法，所述方法包括：获取银行卡签约请求，其中，所述银行卡签约请求仅容许被第一用户授权的应用程序或设备获取，所述银行卡签约请求由待签约银行卡的发卡银行针对所述待签约银行卡生成，所述待签约银行卡为所述第一用户的银行卡；解析所述银行卡签约请求，获取对应所述待签约银行卡的银行卡令牌；基于所述银行卡令牌向所述发卡银行发起访问请求，获取与所述银行卡令牌对应的签约要素信息。在本说明书一实施例中，获取银行卡签约请求，包括：接收所述银行卡签约请求，其中，所述银行卡签约请求基于所述第一用户在银行应用程序的唤端操作被输出；和/或，采集所述银行卡签约请求，其中，通过所述第一用户在银行柜面的扫码操作采集所述银行卡签约请求。在本说明书一实施例中，所述方法还包括：基于所述银行卡签约请求唤起并进入用于解析所述银行卡签约请求的应用程序。在本说明书一实施例中，基于所述银行卡签约请求唤起并进入用于解析所述银行卡签约请求的应用程序，其中，通过带落地页的概要进行所述应用程序的唤起，所述概要指定固定应用标识的应用打开链接。在本说明书一实施例中，利用需要进行银行卡签约的支付机构的应用程序解析所述银行卡签约请求、向所述发卡银行发起所述访问请求、以及获取所述签约要素信息。在本说明书一实施例中，利用用户已成功登录的应用程序获取所述银行卡签约请求、解析所述银行卡签约请求、向所述发卡银行发起所述访问请求、以及获取所述签约要素信息。本说明书实施例还提供一种生成银行卡签约请求的方法，所述方法包括：确认第一用户的身份，根据所述第一用户的身份确认所述第一用户的待签约银行卡；生成与所述待签约银行卡对应的银行卡令牌；根据所述银行卡令牌生成银行卡签约请求。在本说明书一实施例中，在发卡银行为所述第一用户开卡时生成针对新开卡的银行卡签约请求。本说明书实施例还提供一种银行卡签约方法，所述方法包括：根据本说明书实施例所述的方法获取对应第一用户的待签约银行卡的签约要素信息；基于所述签约要素信息为第一用户的支付机构账户签约所述待签约银行卡。在本说明书一实施例中，基于所述签约要素信息为第一用户的支付机构账户签约银行卡，包括：确认所述签约要素信息与所述第一用户是否匹配；当所述签约要素信息与所述第一用户匹配时进入静默签约流程。在本说明书一实施例中，确认所述签约要素信息与所述第一用户是否匹配，包括：将所述第一用户保存在所述支付机构中的信息与所述签约要素信息进行一致性比对；当所述一致性比对成功时，向所述第一用户展示所述签约要素信息的脱敏信息，请求所述第一用户确认所述脱敏信息与所述第一用户在所述发卡银行的银行预留信息是否一致。本说明书实施例还提供一种银行卡签约要素信息获取系统，所述系统包括：银行卡签约请求接收模块，其用于在获得第一用户授权后获取银行卡签约请求，所述银行卡签约请求由待签约银行卡的发卡银行针对所述待签约银行卡生成，所述待签约银行卡为所述第一用户的银行卡；银行卡签约请求解析模块，其用于解析所述银行卡签约请求，获取对应所述待签约银行卡的银行卡令牌；银行访问模块，其用于使用所述银行卡令牌从所述发卡银行处获取所述待签约银行卡的签约要素信息。本说明书实施例还提供一种生成银行卡签约请求的系统，所述系统包括：身份确认模块，其用于确认第一用户的身份，根据所述第一用户的身份确认所述第一用户的待签约银行卡；令牌生成模块，生成与所述待签约银行卡对应的银行卡令牌；银行卡签约请求生成模块，其用于根据所述银行卡令牌生成银行卡签约请求。本说明书实施例还提供一种银行卡签约系统，所述系统包括：签约要素信息获取模块，其用于接收来自如本说明书实施例所述的银行卡签约要素信息获取系统的签约要素信息；签约模块，其用于基于所述签约要素信息为第一用户的支付机构账户签约待签约银行卡。本说明书实施例还提出了一种用于在访问方设备端信息处理的设备，该设备包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该设备执行本说明书实施例所述系统所述的方法。本说明书实施例采用的上述至少一个技术方案能够达到以下有益效果：根据本说明书实施例的方法，可以从发卡银行处获取待签约银行卡的签约要素信息，从而从根源上规避了由用户手动输入签约要素信息而带来的手动输入失误以及忘记签约要素信息的情况的发生；相较于现有技术，本说明书实施例的方法可以确保签约要素信息的准确性，从而提高银行卡签约成功率。附图说明此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：图1～4以及图6为本说明书实施例中应用程序的运行方法的流程图；图5为本说明书实施例中应用程序的静默签约流程的流程图；图7～9为本说明书实施例中系统的结构框图。具体实施方式为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。在现有技术中的银行卡与支付机构的签约过程中，需要用户手动输入签约要素信息。由于签约要素信息包含的信息繁琐且不方便记忆，很容易发生输入手误或忘记的情况，从而最终造成用户银行卡无法签约成功。针对上述问题，本说明书实施例提出了一种获取银行卡签约要素信息的方法。为了提出本说明书实施例的方法，发明人首先分析实际银行卡签约应用场景。为了在用户输入签约要素信息过程中避免输入手误或忘记签约要素信息的情况的发生，最直接的解决方案是取消用户手动输入操作，直接从签约要素信息的数据源获取签约要素信息。进一步的，由于签约要素信息是银行卡用户的个人私密信息，关系到银行卡用户的银行账户安全。因此，为了避免签约要素信息泄露或者被篡改，签约要素信息不能随意保存在非发卡银行的第三方系统中。这就使得如果想要直接获取签约要素信息，就要访问发卡银行的数据系统。因此，在本说明书一实施例中，在需要获取签约要素信息时，直接从发卡银行处获取签约要素信息。进一步的，对于发卡银行而言，为了避免签约要素信息泄露或者被篡改，其必须确保签约要素信息仅能被该签约要素信息对应的合法用户所获取(在银行卡签约应用场景中，必须确保签约要素信息仅能被与待签约银行卡的所有者绑定的系统访问获取)。因此，在本说明书一实施例中，在访问发卡银行以获取签约要素信息时，必须向发卡银行发起身份验证请求，由发卡银行进行身份验证，从而返回与访问者身份匹配的签约要素信息。进一步的，由于需要签约要素信息的用户需要绑定银行卡的支付机构，因此，针对上述技术方案，一个较简单的实现方式是，由支付机构向发卡银行发起针对指定支付机构用户的身份验证请求，由发卡银行根据接收到的身份验证请求确认对应的银行卡所有者，并最终由发卡银行向支付机构返回对应的签约要素信息。上述方案的实现前提包括：1，发卡银行可以识别并验证支付机构发送的身份验证请求；2，发卡银行能够根据身份验证请求正确的确认唯一对应的银行卡所有者。这不仅要求身份验证请求所包含的身份数据信息与用户的真实身份间具备唯一对应关系，而且要求保存在支付机构以及发卡银行的数据系统中的身份数据信息匹配一致。然而，由于通常的支付机构并不严格要求用户填写完整的用户信息，并且，并不严格验证用户所填写的用户信息，这就导致某些用户账户中可能并不包含用于生成身份验证请求的身份数据信息，或者，某些用户账户中的用户信息并不能唯一匹配到正确的用户。例如，针对采用实名信息(例如，身份证件类型+证件号码)作为身份数据信息的应用方案，虽然实名信息可以确保在发卡银行处匹配到唯一对应的银行卡所有者，但是在支付机构处，并不是所有的用户都经过了实名认证并保存有实名信息。再例如，针对采用手机号码作为身份数据信息的应用方案，其不仅无法解决未绑定过手机号的支付机构用户的银行卡签约问题，而且用户绑定手机号的质量无法保证，一些低质量未经过验证的手机号会大大降低发卡银行处进行身份验证的安全性的稳定性。综上，在实际应用场景中，基于支付机构自身所保存用户信息来向发卡银行发起用户身份验证的普适性不能得到保证。因此，在本说明书一实施例中，并不由支付机构向发卡银行发起用户身份验证，而是由用户自身向发卡银行发起身份验证，当发卡银行成功验证用户身份后，输出该用户对应的签约要素信息。进一步的，在本说明书一实施例中，签约要素信息的接收方只能是当前银行卡签约操作的合法执行者或合法关联者，即，合法执行当前银行卡签约操作的相关应用程序。也就是说，签约要素信息的接收方必须是得到了用户授权的装置/应用程序。例如，进行当前银行卡签约操作的用户正在操作的装置上所安装的合法应用程序，该合法应用程序在用户的操作下采集/接收签约要素信息，即相当于其采集/接收操作得到了用户的授权。或者，进一步的，已被用户成功登录的应用程序，该应用程序按照用户的设定进行采集/接收签约要素信息时，其执行主体是用户的账号并且用户账号执行的操作是得到用户确认后的，也就相当于其进行的采集/接收得到了用户授权。进一步的，为了避免签约要素信息在输出过程中被拦截或者输出错误，在本说明书实施例中，采用了令牌访问的方式。具体的，由发卡银行向用户对应的装置/应用程序发送对应签约要素信息的访问令牌，用户对应的装置/应用程序在获取到访问令牌后再使用该令牌从发卡银行处获取签约要素信息。根据本说明书实施例的方法，可以从发卡银行处获取待签约银行卡的签约要素信息，从而从根源上规避了由用户手动输入签约要素信息而带来的手动输入失误以及忘记签约要素信息的情况的发生；相较于现有技术，本说明书实施例的方法可以确保签约要素信息的准确性，从而提高银行卡签约成功率。以下结合附图，详细说明本说明书各实施例提供的技术方案。在本说明书一实施例中，提出了一种获取银行卡签约要素信息的方法，如图1所示，方法包括：s110，获取银行卡签约请求，其中，该银行卡签约请求仅容许被第一用户授权的应用程序或设备获取，该银行卡签约请求由待签约银行卡的发卡银行针对待签约银行卡生成，待签约银行卡为第一用户的银行卡；s120，解析银行卡签约请求，获取对应待签约银行卡的银行卡令牌；s130，基于银行卡令牌向发卡银行发起访问请求，获取与银行卡令牌对应的签约要素信息。具体的，在本说明书一实施例中，银行卡令牌唯一对应待签约银行卡。具体的，在本说明书一实施例中，解析银行卡签约请求，获取发卡机构、银行卡类型及银行卡信息唯一令牌标识。进一步的，在本说明书一实施例中，在获取与银行卡令牌对应的签约要素信息的过程中，为了确保数据安全，通过银行卡令牌、通过专线去发卡银行获取该银行卡令牌所对应的签约要素信息。、进一步的，在实际应用场景中，签约要素信息在发卡银行处可能并不是以签约要素信息作为归类统一保存的。因此，在本说明书一实施例中，基于银行卡令牌向发卡银行发起访问请求，向发卡银行请求回馈用于当前银行卡签约的要素信息。发卡银行验证访问请求后，从该银行卡账户所保存的信息中调出用于银行卡签约的要素信息并输出。具体的，在本说明书一实施例中，在步骤s110中，执行获取银行卡签约请求的是被第一用户授权的应用程序或设备。具体的，在一应用场景中，执行获取银行卡签约请求的是用户当前操作的设备(例如手机)上安装的合法应用程序，用户操作该应用程序获取银行卡签约请求。进一步的，在本说明书一实施例中，步骤s120以及步骤s130的执行者也是被第一用户授权的应用程序或设备。具体的，在本说明书一实施例中，步骤s110～s130的执行者也是被第一用户授权的同一应用程序。进一步的，在本说明书一实施例中，在获取银行卡签约请求的过程中，主动采集银行卡签约请求。具体的，在本说明书一实施例中，在获取银行卡签约请求的过程中，采集银行卡签约请求，其中，通过第一用户在银行柜面的扫码操作采集银行卡签约请求。进一步的，在本说明书一实施例中，在获取银行卡签约请求的过程中，被动接收银行卡签约请求。具体的，在本说明书一实施例中，在获取银行卡签约请求的过程中，接收银行卡签约请求，其中，该银行卡签约请求基于第一用户在银行应用程序的唤端操作被输出。进一步的，在本说明书一实施例中，使用同一应用程序获取银行卡签约请求、解析银行卡签约请求、向发卡银行发起访问请求、以及获取签约要素信息。进一步的，考虑到对银行卡签约请求进行处理的应用程序并不是始终处于开启状态。因此，在本说明书一实施例中，方法还包括：基于银行卡签约请求唤起并进入用于解析银行卡签约请求的应用程序。具体的，在本说明书一实施例中，通过用户已授权的第三方应用程序(例如，移动装置的操作系统)获取(接受或采集)银行卡签约请求，再由获取到银行卡签约请求的第三方应用程序基于银行卡签约请求唤起用于解析银行卡签约请求的应用程序。具体的，在本说明书一实施例中，通过第一用户在银行应用程序的唤端操作唤起并进入对应的应用程序，或者，通过第一用户使用第三方应用程序在银行柜面进行扫码操作从而唤醒并进入对应的应用程序。具体的，在本说明书一实施例中，通过带落地(landing)页的概要(schema)进行应用程序(app)的唤起，上述流程中，概要指定固定应用标识的应用打开链接。具体的，在本说明书一实施例中，在一应用场景中：landing页url:https://render.xxx.com/p/s/i/？scheme＝'schema指定固定appid(20000067)应用打开链接：alipays://platformapi/startapp？appid＝20000067&url＝进一步的，考虑到当前用户可能并不是当前设备和/或应用程序的唯一使用者。在本说明书一实施例中，利用用户已成功登录的应用程序获取银行卡签约请求、解析银行卡签约请求、向发卡银行发起访问请求、以及获取签约要素信息。具体的，在一应用场景中，用户在成功登录当前操作的设备(例如手机)上安装的合法应用程序后，操作该应用程序获取银行卡签约请求。进一步的，考虑到在银行卡签约过程中，最终签约要素信息的接收方应该是支付机构，因此，在一实施例中，利用需要进行银行卡签约的支付机构的应用程序获取银行卡签约请求、解析银行卡签约请求、向发卡银行发起访问请求、以及获取签约要素信息。进一步的，考虑到支付机构的应用程序并不是始终开启的，因此，在本说明书一实施例中，通过用户已授权的第三方应用程序(例如，移动装置的操作系统)获取(接受或采集)银行卡签约请求，再由获取到银行卡签约请求的第三方应用程序基于银行卡签约请求唤起需要进行银行卡签约的支付机构的应用程序，利用支付机构的应用程序解析银行卡签约请求、向发卡银行发起访问请求、以及获取签约要素信息。具体的，如图2所示，在一实施例中，方法包括：s210，银行app唤端或柜面扫码，获取银行卡签约请求；s211，确认银行卡签约请求对应的支付机构app；s220，判断是否安装有支付机构app；当步骤s220判断安装有支付机构app，s221，唤起并进入支付机构app；当步骤s220判断安装有支付机构app，s222，提醒用户安装支付机构app；s230，支付机构app获取用户登录状态，判断用户是否成功登录；当步骤s230判断用户已成功登录，s240，解析银行卡签约请求，获取银行卡令牌；当步骤s230判断用户尚未登录，s241，提醒用户登录；s250，基于银行卡令牌向发卡银行发起访问请求，获取与银行卡令牌对应的签约要素信息。进一步的，在本说明书一实施例中，与发卡银行的数据通信均采用专线进行通讯(在实际应用场景中，专线的具体链路格式由发卡银行确认)。进一步的，在本说明书一实施例中，获取签约要素信息的接口为发卡银行提供的后端接口；与发卡银行进行请求/回应报文交互接口使用xml格式；与发卡银行进行信息交互采用http请求；报文数字签名采用整体报文加签，签约算法sha256withrsa，并做base64加密；报文传输不加密。具体的，在一实施例中，银行卡签约请求的格式如表1所示。中文域名英文域名类型出现要求机构标识instldstringm交易时间datestringm银行卡令牌tokenstringm消息扩展extensions自定义o表1在表1中，机构标识、交易时间以及银行卡令牌为必需项，即，出现要求为必须(must，m)；消息扩展为可选项，即，出现要求为可选(optional，o)。具体的，在本说明书一实施例中，银行卡签约请求的机构标识为发送方的机构标识。具体的，在本说明书一实施例中，银行卡签约请求的交易时间为银行卡签约请求的发送时间。格式为，yyyymmddhh：mm：ss。具体的，在本说明书一实施例中，银行卡令牌作为银行卡签约请求的唤端url的传入参数。进一步的，在本说明书一实施例中，银行卡令牌附加有有效期。例如，在一应用场景中，银行卡令牌在生成后15分钟内有效。具体的，在本说明书一实施例中，银行卡签约请求的消息扩展为机构特殊字段。例如，在一应用场景中，银行卡签约请求的消息扩展包括卡权益标识、ip、设备号等信息扩展字段。具体的，在一应用场景中，银行卡签约请求的消息扩展结构如下：具体的，在一实施例中，发卡银行返回的签约要素信息的格式如表2所示。中文域名英文域名类型出现要求机构标识instldstringm交易时间datestringm卡号cardnostringm用户姓名usernamestringm证件类型certtypestringm证件号certnostringm手机号mobilestringm返回码信息resplnfom表2在表2中，各项均为为必需项，即，出现要求为必须(must，m)。进一步的，对应本说明书实施例所提出的获取银行卡签约要素信息的方法，本说明书实施例还提出了一种生成银行卡签约请求的方法。具体的，如图3所示，在本说明书一实施例中，生成银行卡签约请求的方法包括：s310，确认第一用户的身份，根据第一用户的身份确认第一用户的待签约银行卡；s320，生成与待签约银行卡对应的银行卡令牌；s330，根据银行卡令牌生成银行卡签约请求。具体的，在本说明书一实施例中，在发卡银行为第一用户开卡时生成针对新开卡的银行卡签约请求。由于在开卡环节，新开卡就是绑定了第一用户的身份的，因此，针对新开卡，不需要再次验证第一用户的身份。只需要在新开卡时，针对新开卡生成对应的银行卡签约请求，然后向新开卡的所有者(第一用户)授权的应用程序发送银行卡签约请求即可。具体的，在一应用场景中，用户在银行开卡成功后，银行针对新开卡生成银行卡签约请求二维码，用户使用自身设备(手机)扫描二维码，唤起自身设备上安装的支付机构应用程序，获取银行卡签约请求。进一步的，基于本说明书实施例所提出的获取银行卡签约要素信息的方法，本说明书实施例还提出了一种银行卡签约方法。具体的，如图4所示，在本说明书一实施例中，银行卡签约方法包括：s410，根据本说明书实施例所述的获取银行卡签约要素信息的方法获取签约要素信息；s420，基于获取到的签约要素信息为第一用户的支付机构账户签约银行卡。进一步的，为了进一步确保签约要素信息所对应的用户与支付机构的当前用户一致，在本说明书一实施例中，基于签约要素信息为第一用户的支付机构账户签约银行卡的过程包括：确认签约要素信息与第一用户是否匹配；当签约要素信息与第一用户匹配时进入静默签约流程。具体的，在本说明书一实施例中，以支付机构与发卡银行预先约定好的签约流程作为静默签约流程。具体的，在本说明书一实施例中，静默签约流程如图5所示。支付机构触发静默签约流程后，组装签约要素信息(s511)；在指定域(具体的，在一应用场景中为authmsg域)填入约定值(s512)；发起鉴权请求(s513)。清算平台通过鉴权请求通道转发鉴权请求到发卡银行(s520)。发卡银行接收并处理鉴权请求(s531)；验证签约要素信息(s532)；签约要素信息验证失败时返回失败信息(s533)；签约要素信息验证成功时验证指定域是否是约定值(s534)；当指定域不是约定值时返回失败信息(s533)；当指定域是约定值时返回成功信息(s535)。支付机构接收发卡银行返回的失败/成功信息，识别鉴权结果(s514)；当鉴权失败时，签约失败；当鉴权成功时，在指定域填入约定值(s515)，发起签约请求(s516)。清算平台通过签约请求通道转发签约请求到发卡银行(s521)。发卡银行接收并处理签约请求(s536)；验证指定域是否是约定值(s537)；当指定域不是约定值时返回签约结果(签约失败)(s539)；当指定域是约定值时落实签约协议(s538)，返回签约结果(签约成功)(s539)。支付机构接收发卡银行返回的签约结果，识别签约结果(s517)；当签约失败时，签约失败；当签约成功时，签约成功。具体的，在本说明书一实施例中，确认签约要素信息与第一用户是否匹配的过程包括：将第一用户保存在支付机构中的信息与签约要素信息进行一致性比对；当一致性比对成功时，向第一用户展示签约要素信息的脱敏信息，请求第一用户确认脱敏信息与第一用户在发卡银行的银行预留信息是否一致。具体的，在本说明书一实施例中，如图6所示，银行卡签约流程包括：s610，获取获取签约要素信息；s620，将第一用户保存在支付机构中的信息与签约要素信息进行一致性比对；当一致性对比失败时，s621，银行卡签约失败；当一致性对比成功时，s630，向第一用户展示签约要素信息的脱敏信息；s640，请求第一用户确认脱敏信息与第一用户在发卡银行的银行预留信息是否一致；s641，判断第一用户的确认结果；当第一用户的确认结果为一致时，s650，进入静默签约流程；当第一用户的确认结果为不一致时，s621，银行卡签约失败。进一步的，在本说明书一实施例中，在静默签约流程中，支付机构塞入静默签约特定标识，通过第三方支付机构和银行之间的非银行支付机构网络支付清算平台发送给发卡银行验证。具体的，在一应用场景中，支付机构应用程序签约银行卡的h5落地页面链接为：https://xxx.com/mobile/sign/express/entrance？instid＝xxx&token＝xxxxxx&cardtype＝xx&bankurl＝xxxxxxx.进一步的，在本说明书一实施例中，发卡银行本身提供回跳url，在银行卡签约成功或失败后由用户选择是否跳回发卡银行app。具体的，在一应用场景中，回跳url为：http://xxx.com/mobile/sign/express/entrance？instid＝cmb&token＝ddf6b4101bba4b98a7f370702f9bb5f6&cardtype＝cc&bankurl＝cmblife％3a％2f％2fcfp.cmb.com进一步的，基于本说明书实施例的银行卡签约要素信息获取方法，本说明书实施例还提出了一种银行卡签约要素信息获取系统。具体的，如图7所示，在本说明书一实施例中，银行卡签约要素信息获取系统包括：银行卡签约请求接收模块710，其用于在获得第一用户授权后获取银行卡签约请求，其中，银行卡签约请求由待签约银行卡的发卡银行针对待签约银行卡生成，待签约银行卡为所述第一用户的银行卡；银行卡签约请求解析模块720，其用于解析银行卡签约请求，获取对应所述待签约银行卡的银行卡令牌；银行访问模块730，其用于使用银行卡令牌从发卡银行处获取待签约银行卡的签约要素信息。进一步的，基于本说明书实施例的生成银行卡签约请求的方法，本说明书实施例还提出了一种生成银行卡签约请求的系统。具体的，如图8所示，在本说明书一实施例中，生成银行卡签约请求的系统包括：身份确认模块810，其用于确认第一用户的身份，根据第一用户的身份确认第一用户的待签约银行卡；令牌生成模块820，生成与待签约银行卡对应的银行卡令牌；银行卡签约请求生成模块830，其用于根据银行卡令牌生成银行卡签约请求。进一步的，基于本说明书实施例的银行卡签约方法，本说明书实施例还提出了一种银行卡签约系统。具体的，如图9所示，在本说明书一实施例中，银行卡签约系统包括：签约要素信息获取模块910，其用于接收来自本说明书实施例所述的银行卡签约要素信息获取系统的签约要素信息；签约模块920，其用于基于签约要素信息为第一用户的支付机构账户签约银行卡。进一步的，基于本发明的方法，本发明还提出了一种用于在访问方设备端信息处理的设备，该设备包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该设备执行本发明所述的方法。在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(programmablelogicdevice,pld)(例如现场可编程门阵列(fieldprogrammablegatearray，fpga))就是这样一种集成电路，其逻辑功能由访问方对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片pld上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logiccompiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(hardwaredescriptionlanguage，hdl)，而hdl也并非仅有一种，而是有许多种，如abel(advancedbooleanexpressionlanguage)、ahdl(alterahardwaredescriptionlanguage)、confluence、cupl(cornelluniversityprogramminglanguage)、hdcal、jhdl(javahardwaredescriptionlanguage)、lava、lola、myhdl、palasm、rhdl(rubyhardwaredescriptionlanguage)等，目前最普遍使用的是vhdl(very-high-speedintegratedcircuithardwaredescriptionlanguage)与verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(applicationspecificintegratedcircuit，asic)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：arc625d、atmelat91sam、microchippic18f26k20以及siliconelabsc8051f320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。当前第1页12