干货丨绑卡产品设计实战指导.pdf

干货丨绑卡产品设计实战指导 绑卡，即绑定银行卡，是银行卡与账户的一种关联行为。狭义上的绑卡即银行卡与账户的简 单关联，广义上的绑卡有通过银行卡信息要素的验证，通过后方便进行后续的支付、提现等 动作，也有通过绑卡的形式进行实名认证、找回支付密码等操作。 为了更好的理解本篇文章，建议大家先参考本人知乎专栏文章《银行卡号编码规则及其应用》 一、绑卡目的 1 、为后续业务做铺垫 绑定银行卡后，进行快捷支付及提现都将非常方便。快捷支付中，大部分使用代扣通道，通过绑卡 的形式进行身份鉴权与签约，银行（第三方）返回绑定号，在支付业务中凭靠绑定号发起扣款指令 。 2 、验证身份信息要素 包括实名认证和找回支付密码等过程。 实名认证，如借记卡卡号、姓名、身份证号、预留手机号 4 要素验证中，验证通过下发短信验证码 ，用户回填验证码，验证通过即可提取姓名、身份证号码作为实名认证信息，并且因下发短信验 证码，极大的提高了信息获取门槛。 找回支付密码，同样利用信息要素验证的特性，原则上可确保为本人发起。 二、绑卡需求 三、相关说明 四、绑卡流程 1 、 流程图 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 规则后，自行制作了