支付系统设计:移动端应用的钱账系统设计
这里我们讨论的支付,其实并不是指支付行为本身,而是在整体产品逻辑之下,钱账系统该如何规划。
随着移动端应用的崛起与渗透,越来越多的支付场景由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系统)
附上三大支付平台的链接:
鉴于不同产品的支付需要不尽相同,钱账系统的展现形式也可以是多种多样的,我们采取QA的形式来解决一些设计过程中的要点:
Q1 是否有必要设计应用内的钱包?
钱包的本质是预充值,即用户已经将资金转入平台,当要进行其他购买操作时只完成平台内的一步资金划扣就可以了,这个体验优于拉取站外支付。缺点是要求用户对平台具有一定的信任度,这给部分用户造成了负反馈。
基于以上,当交易行为具有高频小额,易受刺激(冲动型消费)的特性时,比如直播应用,付费社区,钱包将会给用户带来十分便捷的支付体验。
同时,钱包会带来更多的运营促活手段,比如充值返赠,强运营型的产品可以将钱包做为一个着力点。
Q2 如何保证平台内的账户安全?
账户安全包括很多方面,除去技术手段上对于系统健壮性的保护,产品层面,我们以下几个要点需要把握好:
1 身份验证
敏感操作前,需要对用户的真实身份进行认证,常见的认证要素有:真实姓名、手机号、银行卡号、身份证号(护照),根据业务所需来调用相应的鉴权接口来验证所需字段,值得一提的是,对于实名要求很高的场景,还应引入复杂验证,比如人脸识别,视频验证,上传照片等。支付宝和国政通都提供相关的欺诈验证接口服务。
2 操作安全
操作安全主要为了防止用户误操作,他人操作,或用户隐私泄露。常见的方法有:应用内手势锁屏,支付密码,关键信息的部分遮罩处理等。
Q3:还有什么其他需求吗?
当完成了以上的产品设计后,基本上主线流程已经明确了。但同时不要忘记数据统计的需求,因为数据是用户行为的客观体现,也是我们迭代优化的重要依据,例如:
数据监控需求,通常这部分数据也为运营和财务部门服务,属于后台系统设计的范畴,包括但不限于支出、充值、转账等流水信息。
用户行为数据,这部分数据主要依赖前端打点统计得出,用来验证用户和界面交互式是否符合预期。
关键转化率漏斗,这部分数据为复合型数据,使用起来会包含以上两种类型,用来衡量核心模块,比如充值,提现,消费的转化效率。
其他需求,根据团队的需要,PM提供的个性化需求。
安全
安全性是钱账系统第一优先级的需求,在上线前一定要经历严密的测试,保证用户和平台的资金安全。一方面技术层面要进行规范的开发和自查,规避漏洞;另一方面对潜在的外部安全隐患有预警和应急方案,以备不时之需:
信用卡盗刷
如果你的支付系统支持信用卡消费,那么一旦发生了信用卡盗刷我们期望系统可以第一时间做出反应,及时止损,这里可以采取的措施主要是判同一用户是否有连续多笔的大额消费,并在风险出现时进行相关验证。
洗钱
理论上来说,任何一个完整支持资金流闭环的钱账系统都可以洗钱。即不法分子使用非法收入进行支付后再提出,从而将非法收入合理化。尤其是当系统的资金流闭环支持无损提现(无手续费,无抽成)时更应考虑到洗钱的风险。当然,大多数洗钱案件都涉案数额较大,一般的互联网产品不会被这类人使用。规避的办法主要是把控资金出口,进行高门槛的身份鉴权。
本文由 @ 阿厮 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自PEXELS,基于CC0协议
关于支付,很业余的。苹果不是支付公司,银联也不需要千吧,2C代付更不需要一块五···
最毒的一点,钱包涉嫌资金池,违规哦。
感谢大家的打赏,收藏和赞。 😉