绑卡，即绑定银行卡，是银行卡与账户的一种关联行为。狭义上的绑卡即银行卡与账户的简单关联，广义上的绑卡有通过银行卡信息要素的验证，通过后方便进行后续的支付、提现等动作，也有通过绑卡的形式进行实名认证、找回支付密码等操作。
为了更好的理解本篇文章，建议大家先参考本人知乎专栏文章《银行卡号编码规则及其应用》
一、绑卡目的1、为后续业务做铺垫绑定银行卡后，进行快捷支付及提现都将非常方便。快捷支付中，大部分使用代扣通道，通过绑卡的形式进行身份鉴权与签约，银行（第三方）返回绑定号，在支付业务中凭靠绑定号发起扣款指令。
2、验证身份信息要素包括实名认证和找回支付密码等过程。
实名认证，如借记卡卡号、姓名、身份证号、预留手机号4要素验证中，验证通过下发短信验证码，用户回填验证码，验证通过即可提取姓名、身份证号码作为实名认证信息，并且因下发短信验证码，极大的提高了信息获取门槛。
找回支付密码，同样利用信息要素验证的特性，原则上可确保为本人发起。
二、绑卡需求- 考虑到移动设备输入易错性，需判断银行卡号输入合法性，如不合法则需进行友好提示；用户输入银行卡号后，系统能智能识别出发卡行及卡种，无需用户手动选择；卡号、姓名、身份证号码、预留手机号等要素验证，对于验证不通过的，应该尽量明确错误原因，并指导用户采取相应解决办法。
- 本次绑卡仅限常规绑卡，以主流绑卡流程为主；本次绑卡假设已完成实名认证；本次绑卡以APP端为例；本次主要介绍借记卡绑卡过程；本次绑卡主要介绍主流程，细节部分不做过多讨论。
A、输入卡号并提交后，通过LUHN算法验证卡号输入合法性，可检查出90%以上卡号输入错误，提升用户体验。考虑到极少数银行卡号未按照LUHN算法进行生成，因此，在不符合时，进行友好提示，用户可以选择返回修改或确认无误进入下一步。关于银行卡号生成规则LUHN算法的知识，可参考本人知乎专栏文章《银行卡号编码规则及其应用》
B、银行卡号获取到后，则需根据银行卡号检索银行卡发卡行及卡种等信息，卡BIN数据库需事先准备好，检索流程如下：
我们知道，卡BIN一般是6位组成，并且一般是不会重复，但是确实存在6/7/8/9/10等几位卡BIN长度，而且多位的卡BIN可能和低位的卡BIN前几位会相同，另外也存在卡BIN相同但卡长度不同代表不同银行卡的。因此需要从卡BIN10位向6位检索，并通过卡长度辅助查询，详看上图。
另外，对于数据库检索不到的卡BIN，则可以选择不允许绑卡或用户通过手动形式进行选择银行及卡种，大家可根据实际情况选择。
C、 对于借记卡，一般验证姓名、身份证号、卡号、预留手机号4要素进行验证，因前期以进行实名认证，因此姓名、身份证号码不需再重复输入。现卡号也已获取到，只需再输入预留手机号即可。
预留手机号输入完成提交后，进行姓名、身份证号、卡号、预留手机号4要素验证。对于验证通过的，则下发短信验证码，根据合作方式的不同，此验证码可能由平台自行下发，也可能由银行或第三方支付下发。
D、 用户收到验证码后进行回填并提交，验证无误后绑卡完成，数据库需记录银行或第三方支付返回的绑定号，以便用于日后支付动作。
2、线框图A、姓名调取实名认证信息，无需用户输入，也不可更改
B、银行卡号长度满12位后方可点击下一步，卡号每隔4位隔开
C、 卡号输入完成点击下一步时，由客户端自行完成LUHN算法对银行卡号合法性进行验证，通过时进入下一步，不通过是进行友好提示，用户可选择返回修改或确认无误
D、银行卡号符合LUHN算法后，检索卡BIN信息，返回发卡行及卡种
E、用户输入手机号，手机号需满足首位为1，长度为11的要求，且进行1XX XXXX XXXX的展示
F、 手机号无误提交进行姓名、身份证号（此两项取自实名信息，无需用户填写）、卡号、预留手机号验证，验证通过则下发短信验证码
G、用户回填短信验证码，无误后绑卡完成，服务端记录卡信息，记录银行（第三方支付）返回的绑定号（如有）
五、嘚瑟一下原公司APP早期绑卡产品卡BIN信息为通过第三方接口获得，每次接口调用2元。后本人学习到银行卡编码规则及卡BIN规则后，自行制作了一套卡BIN读取系统及相应数据，有如下成就：
1、节省成本：按照20万次的接口调取量，预计可节省约40万元（此处应有掌声！哎呀，似乎没涨工资！）；
2、由调用第三方接口改为内部接口，降低了外部的依赖性，也提高了响应速度；
六、课后作业一般来说，调用银行或第三方支付接口对姓名、身份证号、卡号、预留手机号4要素进行验证时，对方只会返回一致或者不一致，而不会告知哪个或哪几个要素不对。如果返回的是不一致，为了明确错误原因指导用户相应操作，如何确定哪个要素有误？
答案在原文中有相关提示哦。后期会把答案公布出来。