前言：
从需求到场景之间的联系即为产品，支付伴生于平台，服务于场景，连接需求，解决问题并持续升阶。
大纲：
1 领域简述
1.1 市场概况
2 产品浅析
2.1 实名认证
2.2 绑卡
2.3 结算
2.4 提现
2.5 对账
2.6 风控
3 总结
1 领域简述：
1.1 市场概况：
当今互联网支付市场群雄割据，支付宝，微信支付，银联商务占据了绝对的市场份额；而移动
支付市场，则是支付宝和微信支付遥遥领先。
面对严峻的市场环境，对于其他支付产品而言，未尝不是机会和挑战，常言道“船小好调头”，
可以利用自身的机动性，从场景着手，实现细分市场的超车。
2 产品浅析：
对于整个金融市场的思考与分析，将在后续的文章中进行延展，本文将从支付产品的各模块入手，一方面梳理和沉淀所学知识，另一方面与志同道合的PM们，共同学习与进步。
2-1 实名认证：
实名认证是支付的基础，一般来讲分为to B和to C，本文将从to C的角度进行展开，对于实名认证进行粗浅的介绍。
A、Why：
● 来自监管的需要： 相关的行政机关和平台政策法规层面的硬性要求；
● 来自资金安全的需要： 用户进行绑卡、提现、结算等后续业务动作所必须；
● 来自用户权益保障的需要： 防止个人信息被他人恶意抢注而影响本人权益；
B、How：（存在面对面&非面对面两种类型，因本人所处互联网行业，固此处以非面对面类型进行展开，并着重对辅助验证进行描述）
●资料审核类： 例如商城卖家上传手持身份证的照片；
●辅助验证类：
●姓名+身份证： 通过第三方机构进行验证
优点： 方便简单，有较高的准确率
缺点： 信息数据安全性低，无法保障是本人操作
●姓名+身份证+手机号： 通过获得运营商的服务支持，验证一致性通过后，下发验证码
优点： 信息安全性高，可信度高
缺点： 获取运营商服务支持过程复杂，需要多家运营商提供服务
●随机支付： 用户提供账户+账号，平台进行随机小金额转账，用户回填金额进行验证
优点： 信息安全性好，可信度高
缺点： 操作流程复杂，多终端交互，信息流转周期长，用户体验较差
●绑卡： 绑定银行卡，进行四要素验证（用户名，身份信息，银行卡号，预留手机号）
优点： 信息可信度高，可以将实名认证和绑卡同步进行，简化流程
缺点： 准确率受第三方约束，存在信息正确但验证错误的情况
●交叉类： 资料审核+辅助验证等其他组合形式；
●趋势类： 例如人脸识别；
2-2 绑卡：
●意义： 建立账户与银行卡之间的关联关系
●目的：
为后续业务动作提供基础： 如结算，提现等动作
对身份信息要素进行验证： 如实名认证，找回支付密码等动作
●需求：
降低移动端易错几率： 对卡号进行合法性验证，当错误时，进行友好提示
tips： 卡号验证通过LUNH（摸十算法）验证，感兴趣的朋友可以@我或自行度娘
降低用户操作成本： 对卡号进行BIN验证，自动填充银行及卡种信息，减少用户操作
考虑移动端容错机制： 四要素验证时，对错误项进行精准定位，并提供解决方法指导
●流程：（只对核心流程进行简述，细节不做过多说明）
a、输入银行卡号
b、进行LUNH验证
c、通过后获取银行卡号（如未通过，则进行友好提示，“重新输入”或“确认无误”）
d、获取银行卡号后进行BIN号验证
e、提前准备好BIN数据库，以方便检索
f、根据字段不同逐类验证
g、检索成功后，自动填充银行及卡种信息（如检索未成功，可以选择禁止绑卡或人工完善）
h、进行“四要素验证”
i、验证成功，下发验证码（如验证失败，则精准定位错误要素，并提供解决方法指导）
j、用户回填验证码
k、验证成功后，绑卡成功
l、数据库记录绑定号（方便为后续动作提供服务）
2-3 结算：
结算的核心包括资金流的流出和流入，通过路由和通道来保障支付流程的顺利进行
●内容： 入款 & 出款
●引导路由： 为用户提供入款或出款方式的选择，例如：支付方式的选择
●支付路由： 根据通道策略，进行合理的通道选择
tips：策略类型：成本优先；安全优先；备用机制；政策导向等
2-4 提现：
●定义： 由用户发起，实现数据流（用户虚拟资金账户→用户银行资金账户）和资金流（备付金账户→用户银行资金账户）的流转
tips： 我微信提现1元，微信账户显示少了1元，银行卡账户显示多了1元，其实这个时候钱并没有真的到账，待平台和银行完成对账后，这1元才真的流入我的银行账户
●流程：
2-5 对账：
●Why：对一定周期内的交易进行双方确认，一方面为结算提供依据，另一方面检测是否有异常情况
●What：对账的核心基础就是针对信息流和资金流的核对确认
信息流： 对如订单金额，订单状态等元素进行对比确认
资金流： 应结算账单和实际结算账单进行对比确认
●How：
a、获取对账单： 通过不同方式进行账单获取（接口，邮件，FTP等）
b、规范数据： 对文件名称进行统一规范，并通过脚本对不同渠道文档进行针对性解析
c、账单比对： 根据文件规范化名称获取系统订单，并根据数据逻辑层级进行顺序比对
d、通过顺序逐条比对，判断是否存在多项和余项
e、通过单条逐项比对，判断是否存在数据差异
f、对对账结果状态进行记录（已对账，短帐，多帐，金额不一致等）
g、结果输出：
当结果无差异时，记录对账成功并进行数据汇总
当结果有差异时，进行差异展示，并进行差异处理
h、差异处理：
目的： 平账
案例： 例如由于结算周期的差异，引起的短帐，一般通过挂账方式进行处理
tips： 涉及《会计学》相关知识，请小伙伴自行学习，加油！
注：当遇见由于bug引起的差异情况时，优先解决bug，然后再进行差异处理
2-6 风控：风险控制在支付领域举足若轻，涉及知识广且深，随着大数据和机器学习的迅猛发展，为风控系统提供了更多的支撑，但安全和风险从来都是此消彼长，相互博弈的一对手，限于个人能力，不敢妄论，以下仅以小篇幅进行抛砖引玉，望大牛们不吝赐教！
●类型： 合规政策风控 & 交易风控
●目的：
控制风险而非杜绝风险（私理解为，性质等同于“误差”）
实现利益最大化而非风险最小化（引用蔡崇信的一句话：“风险值得冒，但要输得起”）
●策略：
时间维度： 例如，控制支付行为的时间间隔
空间维度： 例如，两次支付行为的发起地点，在时间约束条件下的空间可行性
数量 & 金额： 例如，固有周期内支付次数的限制；单次支付额度的限制
3 总结：
随着“无现金社会”理念的推出，支付无疑成为了商家必争之地，在同质化的竞争环境下，又都在寻找差异化的突围方式。自从入了产品坑以来，“场景”便无时无刻的伴随着每一个PM，不同的Level都保持着各自或独立或追随的思考，支付产品也在从最初的伴生服务型产品，逐渐的升阶，去平台化，去中心化的理念不断的涌出，各方思维在博弈碰撞。
支付产品的机遇和挑战，也在不断的博弈中，涌现。相信，随着需求的变革（来源于消费能力，消费内容和消费意愿的升级）和场景的变革（个人动态金融场景的大范围，高频率，深维度的展开），作为连接二者的纽带，支付产品必将步入新的纪元。
最后，愿每一名奔跑中的PM，无愧初心！
网友评论