今天完成的事情：

学习支付模块

明天计划的事情：

继续

存在的问题：哎

收获：

一、绑卡目的

1、为后续业务做铺垫

绑定银行卡后，进行快捷支付及提现都将非常方便。快捷支付中，大部分使用代扣通道，通过绑卡的形式进行身份鉴权与签约，银行（第三方）返回绑定号，在支付业务中凭靠绑定号发起扣款指令。

2、验证身份信息要素

包括实名认证和找回支付密码等过程。

实名认证，如借记卡卡号、姓名、身份证号、预留手机号4要素验证中，验证通过下发短信验证码，用户回填验证码，验证通过即可提取姓名、身份证号码作为实名认证信息，并且因下发短信验证码，极大的提高了信息获取门槛。

找回支付密码，同样利用信息要素验证的特性，原则上可确保为本人发起。

二、绑卡需求

1. 考虑到移动设备输入易错性，需判断银行卡号输入合法性，如不合法则需进行友好提示；
2. 用户输入银行卡号后，系统能智能识别出发卡行及卡种，无需用户手动选择；
3. 卡号、姓名、身份证号码、预留手机号等要素验证，对于验证不通过的，应该尽量明确错误原因，并指导用户采取相应解决办法。

三、绑卡流程

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、 用户收到验证码后进行回填并提交，验证无误后绑卡完成，数据库需记录银行或第三方支付返回的绑定号，以便用于日后支付动作。