这里我们讨论的支付，其实并不是指支付行为本身，而是在整体产品逻辑之下，钱账系统该如何规划。

随着移动端应用的崛起与渗透，越来越多的支付场景由web端转移到了移动端，同时传统的银行卡支付已经不能满足简单便捷的移动体验了。在这样的大背景下，应运而生的各类第三方支付服务提供商便有了生存空间。移动支付几乎在各种场景中出现：外卖，电商，直播，社区等等。

这里我们讨论的支付，其实并不是指支付行为本身，而是在整体产品逻辑之下，钱账系统该如何规划。项目的复杂度主要产生于如何将自身的支付诉求与第三方服务结合，给用户带来安全可靠，明确易用的支付体验。

背景与需求

钱账系统中最基本的元素是账户，帐户之间资金的流动就构成了交易，发起交易的一方，被称为交易主体，资金从该主体所拥有的账户中流出，交易主体可以是个人或企业。而接收资金的一方，被称为交易对手，同理也可以是个人或企业。

普通企业是没有支付牌照且不具备清算资质的，所以我们必须通过接入第三方服务商来实现交易，所以本质上，真正的支付过程是由我方系统调用服务商的接口来实现资金转移的。这些第三方服务商也被称作渠道，他们就像机器人的摇臂一样替我们实现交易。当然，渠道会在这个过程中收取一定的费用。

就像规划任何新的产品一样，首先应该明确需求，这里我们不讨论具体的用户需求，而是以钱账业务的服务对象（资金流）为核心，常见的资金流有以下几种类型：

• C to B to C － 淘宝店铺
• C to B －京东自营
• C to C －打赏转账
• B to B ­ －企业级服务

C 代表个人帐户，B代表企业账户。退款属交易异常处理，所以不在此处讨论。

无论是以上哪一种资金流模式，涉及的交易动作都是无外乎支付和提现两种，站在渠道的角度，也被称作收款和付款。

除此之外，在项目前期还应确定产品支持的手机平台及形态，以保有后期的拓展性。

目前常见的手机平台有：Apple公司的iOS系统及各品牌的安卓系统；

常见的产品形态有：手机app，手机wap页，web网页，微信公众号。

支付与提现

支付是指用户将平台外的资金转移至平台内账户的过程，本质为个人账户向对公账户进行转账。（也存在一些特殊形式，比如p2p企业和银行合作的资金存管）

提现是指用户将平台内账户的资金转移出去的过程，本质为对公账户向个人账户（或对公账户）进行转账，与支付相逆。

通常情况下，支付需求比提现更多，所以支付商支持的场景也更丰富。

支付渠道

目前主流的渠道有支付宝、微信、银联、苹果。（海外市场暂不讨论）

适用性

标记代表支持，空白代表不支持。

支付渠道适用性

关于支付宝，微信，银联相信大家都比较熟悉。需要特别指出的是，苹果公司目前提供两种截然不同的支付方式，Apple Pay和 IAP，区别在于前者适用于现实存在的服务和商品，而后者仅用于购买虚拟物品，根据Apple的规定，二者是严格不可混用的。这也要求pm在定义好自己售卖的物品特性后再选择合适的支付方式。

支付费率

大同小异，除了苹果公司的IAP支付方式需要支付30%的费率，其他渠道均稳定在0.5%－1.2%左右。此处列举了微信和支付宝的费率明细，苹果支付的底层服务也走银联，且银联的支付通道费率均是可谈的，大约在0.8%左右，具体请参考中国银联商户中心网站。

在产品设计上，支付手续费通常由平台抹平，所以用户是感知不到的（单客利润应大于支付费率）

支付宝-支付费率

微信-支付费率

提现费率

相较于支付，提现功能所要支付

各渠道提现费率

规划与设计

当做好了前期准备后，我们就可以push团队动起来了。需要注意的是，各种渠道的申请所需材料，审核时长都不一样，建议在确定大方向后的第一时间就先进行渠道申请，以避免影响项目的排期。（此处建议阿里的B端pm好好梳理下业务逻辑，同时优化下无比鸡肋的QA系统）

附上三大支付平台的链接：

• 银联：https://merchant.unionpay.com/join/
• 微信：https://pay.weixin.qq.com/
• 支付宝：https://www.alipay.com/

鉴于不同产品的支付需要不尽相同，钱账系统的展现形式也可以是多种多样的，我们采取QA的形式来解决一些设计过程中的要点：

Q1 是否有必要设计应用内的钱包？

钱包的本质是预充值，即用户已经将资金转入平台，当要进行其他购买操作时只完成平台内的一步资金划扣就可以了，这个体验优于拉取站外支付。缺点是要求用户对平台具有一定的信任度，这给部分用户造成了负反馈。

基于以上，当交易行为具有高频小额，易受刺激（冲动型消费）的特性时，比如直播应用，付费社区，钱包将会给用户带来十分便捷的支付体验。

同时，钱包会带来更多的运营促活手段，比如充值返赠，强运营型的产品可以将钱包做为一个着力点。

Q2 如何保证平台内的账户安全？

账户安全包括很多方面，除去技术手段上对于系统健壮性的保护，产品层面，我们以下几个要点需要把握好：

1 身份验证

敏感操作前，需要对用户的真实身份进行认证，常见的认证要素有：真实姓名、手机号、银行卡号、身份证号（护照），根据业务所需来调用相应的鉴权接口来验证所需字段，值得一提的是，对于实名要求很高的场景，还应引入复杂验证，比如人脸识别，视频验证，上传照片等。支付宝和国政通都提供相关的欺诈验证接口服务。

2 操作安全

操作安全主要为了防止用户误操作，他人操作，或用户隐私泄露。常见的方法有：应用内手势锁屏，支付密码，关键信息的部分遮罩处理等。

Q3：还有什么其他需求吗？

当完成了以上的产品设计后，基本上主线流程已经明确了。但同时不要忘记数据统计的需求，因为数据是用户行为的客观体现，也是我们迭代优化的重要依据，例如：

数据监控需求，通常这部分数据也为运营和财务部门服务，属于后台系统设计的范畴，包括但不限于支出、充值、转账等流水信息。

用户行为数据，这部分数据主要依赖前端打点统计得出，用来验证用户和界面交互式是否符合预期。

关键转化率漏斗，这部分数据为复合型数据，使用起来会包含以上两种类型，用来衡量核心模块，比如充值，提现，消费的转化效率。

其他需求，根据团队的需要，PM提供的个性化需求。

安全

安全性是钱账系统第一优先级的需求，在上线前一定要经历严密的测试，保证用户和平台的资金安全。一方面技术层面要进行规范的开发和自查，规避漏洞；另一方面对潜在的外部安全隐患有预警和应急方案，以备不时之需：

信用卡盗刷

如果你的支付系统支持信用卡消费，那么一旦发生了信用卡盗刷我们期望系统可以第一时间做出反应，及时止损，这里可以采取的措施主要是判同一用户是否有连续多笔的大额消费，并在风险出现时进行相关验证。

洗钱

理论上来说，任何一个完整支持资金流闭环的钱账系统都可以洗钱。即不法分子使用非法收入进行支付后再提出，从而将非法收入合理化。尤其是当系统的资金流闭环支持无损提现（无手续费，无抽成）时更应考虑到洗钱的风险。当然，大多数洗钱案件都涉案数额较大，一般的互联网产品不会被这类人使用。规避的办法主要是把控资金出口，进行高门槛的身份鉴权。

本文由 @ 阿厮 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自PEXELS，基于CC0协议