PM vs 学习 | 支付产品浅析

前言：

从需求到场景之间的联系即为产品，支付伴生于平台，服务于场景，连接需求，解决问题并持续升阶。

大纲：

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，无愧初心！