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

　　随着移动端应用的崛起与渗透，越来越多的支付场景由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 是否有必要设计应用内的钱包?