支付系统设计:移动端应用的钱账系统设计

3 评论 21816 浏览 165 收藏 12 分钟

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

随着移动端应用的崛起与渗透,越来越多的支付场景由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协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 关于支付,很业余的。苹果不是支付公司,银联也不需要千吧,2C代付更不需要一块五···
    最毒的一点,钱包涉嫌资金池,违规哦。

    来自北京 回复
  2. 感谢大家的打赏,收藏和赞。 😉

    来自北京 回复