这里有一套比较宏观的支付体系模型

2018-09-27 22:42:00

最近参与对接了公司接入第三方支付的工作，于是整理输出了一套比较宏观的支付体系模型，希望对刚接触支付的产品经理有一些帮助。

文章结构：

支付体系模型；
支付规则详解；
支付模型总结；
小公司如何对接第三方支付。

一、支付体系模型

模型是复杂体系的简化，也是认识复杂体系的思维脚手架。支付体系的核心模型可以抽象为：信息流、现金流、支付规则。
如下图：
超级产品经理
信息流：明确支付过程中每个环节的信息流转和状态响应，一些信息的流转最终会导致资金的在各银行账户之间的转移，只不过在信息的传递和价值的传递上有时间上的延迟，通常表现为T+1,D+1 等（当然数字货币很好的解决了这个问题）。
资金流：这里了定义的资金流指的是我们应该明确支付完成后具体的钱（也是数字）是怎么在银行与银行之间进行清结算的，资金流转发生在各银行账户之间。
任何的支付的具体场景和表现形式，都应该明确信息流&资金流具体的流转过程，是我们梳理支付逻辑最近本的方法论。
举一个简单的例子：微信公众号支付
商户已有H5商城网站，用户通过消息或扫描二维码在微信内打开网页时，可以调用微信支付完成下单购买的流程。

步骤1：如图7.1，商户下发图文消息或者通过自定义菜单吸引用户点击进入商户网页。
步骤2：如图7.2，进入商户网页，用户选择购买，完成选购流程。

超级产品经理

步骤3：如图7.3，调起微信支付控件，用户开始输入支付密码。
步骤4：如图7.4，密码验证通过，支付成功。商户后台得到支付成功的通知。

超级产品经理

步骤5：如图7.5，返回商户页面，显示购买成功，该页面由商户自定义。
步骤6：如图7.6，微信支付公众号下发支付凭证。

超级产品经理
上述是一个完整的支付流程，能清楚地看到各种信息状态的流转以及响应。能够直观感知的是银行卡余额的减少&话费增加这样的信息，实际支付背后资金的流转逻辑是：用户浦发银行账户里面的钱，经过清结算系统支付给了微信所拥有的第三方银行账户，暂存在该银行账户里，微信的银行账户会按照一定的周期（T+1）自动结算到运营商的银行账户，微信在以上整个支付逻辑中扮演了第三方支付服务提供商的角色。
支付规则：我们应该清楚支付体系的所有基本规则，从基本的名词概念出发，到具体的产品逻辑实践，积累中慢慢地让我们看到整个支付体系的全貌。
超级产品经理

二、支付规则详解

1.支付渠道

支付渠道，顾名思义就是平台上支持用户支付的通道，这些支付渠道帮助平台用户完成交易金额的支付，并且支持平台与银行之间进行资金流转、对账和清分，比如：微信、支付宝、通联、易宝等。一般交易平台都会对接多家支付渠道公司。
（1）第三方支付
对于目前的市场情况来说，首先而且必选的第三方支付渠道就是支付宝和微信支付。这两种支付渠道几乎占据了在线支付第三方渠道的90%以上的市场份额，并且这两个渠道支持各种业务的平台，对接的银行非常多，性能和稳定性都非常高。
（2）银联
银联作为第三方的支付渠道，为平台对接银行起到非常大的帮助作用。平台对接银联的支付渠道后（快捷支付），用户在平台消费时需要绑银行卡，首次需要上传银行卡号、手机号、身份证号码，银行卡绑定后，后续的操作步骤会相对便捷一些，只需在每次支付时输入密码即可。后续的支付扣款流程跟其他第三方支付一样需要内嵌SDK，而是都在服务端完成校验。
（3）银行
截止到2015年底，我国银行业金融机构包括6家大型的商业银行、12家股份制商业银行、133家城市商业银行和5家民营银行等1000多家银行。其中首选的就是5家商业银行，其累计占40%的交易量，其次就是各种股份制银行和邮政储蓄银行等。
一般情况下，对接一个银行的话预期需要2-3周的工作量，不同银行对接入环境有不同要求，这也是成本，比如：大部分银行需要专线接入，费用和带宽有关，一年也得几万费用。
（4）第四方支付
第四方支付是相对第三方而言的，作为对第三方支付平台服务的拓展。第三方支付介于银行和商户之间，而第四方支付是介于第三方支付和商户之间，没有支付许可牌照的限制。
第四方支付集成了各种三方支付平台/合作银行/合作电信运营商/其他服务商接口，也就是说集合了各个第三方支付及多种支付渠道的优势，能够根据商户的需求进行个性化定制，形成支付通道资源互补优势，满足商户需求，提供适合商户的支付解决方案。
总体来讲，第四方支付属于支付服务集成商，具有无可比拟的灵活性，便捷性和支付服务互补性。而且第四方支付具有中立性优势，可以一定程度上调和支付机构恶意竞争的状况，保证支付行业健康发展。
（6）卡外支付
对于由海外支付的需求，还需要提供外卡支付支持。国内不少支付渠道都能支持外卡支付，如：支付宝全球购等。直接对接Paypal，也是目前用的最多的外卡支付渠道。
（7）其他支付
支付渠道还有一些小众和特殊的存在，比如：话费支付。这一块容易被人忽略，但考虑到国内不少职场人士，话费是公司报销的，每个月多的用不完，所以这块支付还是相当有市场的。
问题是，联通和移动两大运营商，不仅接口不能互通，内部各个地域也是各自为政，所以对接起来还是有点麻烦。不过话费支付领域也有类似支付宝微信的第三方支付公司，比如：虹软、联动优势等公司。

2. 支付通道

支付通道是只用户在交易平台进行支付操作时选用的支付方式，常见的有网银支付、快捷支付、认证支付&账户支付等。
（1）网银支付
网银支付，即网上银行支付，是即时到帐交易。网银支付是银联最为成熟的在线支付功能之一，也是网民在线支付的首选方式，是国内电子商务企业提供在线交易服务不可或缺的功能之一。其特点是银行卡需事先开通网银支付功能，且在支付时完全是在银行网银页面输入银行卡信息并验证支付密码，具有稳定易用，安全可靠的特点。
目前可以支持国内20多家银行的借记卡和信用卡，网银支付分为：银行网银&银联网银。
第三方支付平台接了银行网银接口后，从银行的角度讲，其只是对外开放了一个网银接口。网银和网关其实是两个不同的概念，二者是针对不同的主体来说的，所起的作用也不一样。但是因为第三方支付平台连接网银接口，进行支付跳转时，第三方支付平台充当了一个网关的角色，或者充当了银行的代理，所以经常有人弄混。
从普通用户的感知来讲，这就是平时经常所说的第三方支付平台的网银支付，但是注意网银与网关不是一码事。
（2）认证支付
“认证支付”，是指付款人通过第三方支付平台接收输入的银行卡相关信息（如：卡号、密码、CVN2、有效期、预留手机号等要素），由第三方支付平台经过付款人发卡行进行验证，使用第三方支付平台短信验证或发卡行手机短信验证等辅助认证以完成支付交易的支付方式。
（3）快捷支付
“快捷支付”，一种是与“认证支付”模式相同；另一种，是指付款人在第三方支付平台的注册用户账户并付款人的银行卡账户实现关联（一般情况下关联时需由发卡行验证），在交易时付款人使用在第三方支付平台的用户账户发起交易，由第三方支付平台联动付款热绑定的银行，由发卡银行进行交易授权的支付方式。
“从银行角度讲，这是其对外开放的快捷支付接口，而对于普通用户的感知来说，也是我们经常所说的快捷支付。进行快捷支付时，第三方支付平台往往会要求用户先在第三方支付平台注册成为会员，然后进行四要素绑卡（姓名、身份证、卡号、银行预留手机），最后才能完成付款。
注：有些商户平台（如P2P）与第三方支付平台深度合作，用户只需要在商户平台界面上完成绑卡即可，整个绑卡流程下来都不会出现第三方支付平台的界面，这是由于用户在商户平台填写的信息都在后台传给了第三方支付平台，然后第三方支付平台为用户隐式注册了第三方平台账户。这么做只是为了让用户的绑卡流程不会被打断，让用户体验好一点而已，原理还是与用户在第三方支付平台显式注册一样。”
（4）账户支付模式
账户支付指买卖双方必须先到第三方支付平台注册成为第三方支付平台的会员，用户通过网银或其它方式先往虚拟账户中充值（资金流：钱从用户的银行卡划转到第三方支付公司银行账户），用户消费付款时，从虚拟账户直接扣除（这里并不涉及实际的资金划转，只是数据层面上数字的减少），典型的，如：Paypal。
超级产品经理

3. 支付方式

以为支付方式&支付载体来划分支付类型，这里用微信支付来举例。
超级产品经理
（1）刷卡支付

步骤1：用户选择刷卡支付付款并打开微信，进入“我”->“钱包”->“收付款”条码界面；
步骤2：收银员在商户系统操作生成支付订单，用户确认支付金额；
步骤3：商户收银员用扫码设备扫描用户的条码/二维码，商户收银系统提交支付；
步骤4：微信支付后台系统收到支付请求，根据验证密码规则判断是否验证用户的支付密码，不需要验证密码的交易直接发起扣款，需要验证密码的交易会弹出密码输入框。支付成功后微信端会弹出成功页面，支付失败会弹出错误提示。

（2）公众号支付
商户已有H5商城网站，用户通过消息或扫描二维码在微信内打开网页时，可以调用微信支付完成下单购买的流程。

步骤（1）：商户下发图文消息或者通过自定义菜单吸引用户点击进入商户网页。
步骤（2）：进入商户网页，用户选择购买，完成选购流程。
步骤（3）：调起微信支付控件，用户开始输入支付密码。
步骤（4）：密码验证通过，支付成功。商户后台得到支付成功的通知。
步骤（5）：返回商户页面，显示购买成功。该页面由商户自定义。
步骤（6）：微信支付公众号下发支付凭证。
（3）扫码支付
用户扫描商户展示在各种场景的二维码进行支付。
步骤（1）：商户根据微信支付的规则，为不同商品生成不同的二维码，展示在各种场景，用于用户扫描购买。
步骤（2）：用户使用微信“扫一扫”扫描二维码后，获取商品支付信息，引导用户完成支付
步骤（3）：用户确认支付，输入支付密码。
步骤（4）：支付完成后会提示用户支付成功，商户后台得到支付成功的通知，然后进行发货处理。
（4）APP支付
适用于商户在移动端APP中集成微信支付功能。
商户APP调用微信提供的SDK调用微信支付模块，商户APP会跳转到微信中完成支付，支付完后跳回到商户APP内，最后展示支付结果。
目前微信支付支持手机系统有：IOS（苹果）、Android（安卓）和WP（Windows Phone）。
交互细节如下：
步骤（1）：用户进入商户APP，选择商品下单、确认购买，进入支付环节。商户服务后台生成支付订单，签名后将数据传输到APP端。以微信提供的DEMO为例。
步骤（2）：用户点击后发起支付操作，进入到微信界面，调起微信支付，出现确认支付界面。
步骤（3）：用户确认收款方和金额，点击立即支付后出现输入密码界面，可选择零钱或银行卡支付见。
步骤（4）：输入正确密码后，支付完成，用户端微信出现支付详情页面。
步骤（5）：回跳到商户APP中，商户APP根据支付结果个性化展示订单处理结果。
（5）H5支付
H5支付是指商户在微信客户端外的移动端网页展示商品或服务，用户在前述页面确认使用微信支付时，商户发起本服务呼起微信客户端进行支付。
主要用于触屏版的手机浏览器请求微信支付的场景，可以方便的从外部浏览器唤起微信支付。
（6）应用内支付
应用内支付指使用手机操作系统自带的支付功能来支持支付，目前国内主要的应用内支付有 Google Pay、Apple Pay、小米支付、华为支付等。其中Apple Pay是典型的一个应用内支付，Android平台的各种支付也一般是沿用Apple Pay的设计。
很多手机厂商都内置了各种支付，比如：苹果的App-pay支付，三星支付、华为支付等；这些支付仅针对特定的手机型号，支持NFC等，根据业务需要也可以接入；就是目前用户群不大，收益不明显。
4. 支付类型
以支付标的物来划分，支付类型分为：银行卡支付、余额支付、零钱支付、积分支付、代币支付、话费支付等。
（1）银行卡支付
银行卡支付指的是我们直接使用微信、支付宝、网银、快捷支付等绑定的银行卡作为支付标的，银行卡分为线上支付（我们通常使用的在线支付）&线下刷卡（POS）支付。
（2）余额支付
有的交易平台为了增加用户粘性会设立余额账户，用户可以给自己的余额账户充钱，在后续的支付过程中可以直接使用余额支付。背后的资金流转只在用户充值，提现的时候提现，平时的余额支付仅仅只是信息的流转。
（3）零钱支付
和余额支付原理一样，例如微信零钱包，收到的红包存入零钱可以用来支付，或者提现，还可以对零钱进行充值。
（4）积分支付
用户在交易平台获得的积分，可以用来购买支付平台商品，这个时候只有信息流的流转，背后并不会有实际资金流的流转。
（5）代币支付
交易平台会发行自己的代币，用户充值购买代币后，可以在平台商城进行消费，背后的支付逻辑和余额支付是一样的。
（6）话费支付
话费支付这一块容易被人忽略，但考虑到国内不少职场人士，话费是公司报销的，每个月多的用不完，所以这块支付还是相当有市场的。问题是，联通和移动两大运营商，不仅接口不能互通，内部各个地域也是各自为政，所以对接起来还是有点麻烦。不过话费支付领域也有类似支付宝微信的第三方支付公司，比如：虹软、联动优势等公司。
5. 银行接口
任何一家支付机构后台都要接入一堆银行，来完成代收的操作。目前银行开放给第三方机构（包括第三方支付平台）的接口大概有四类： POS收单接口，网银接口，快捷支付接口和代扣接口，这四类接口的作用就是把资金从用户的银行卡划转出来。
我们经常所说的网银支付，快捷支付其实是针对银行接口来说的，并不是第三方支付方式，只不过第三方支付平台要完成扣款的操作，必须要接入这些银行接口。用户在第三方支付平台选择网银进行支付时，此时的第三方支付平台其实也是充当了银行网关的作用。
但是并不能说网关支付就是网银支付，这是两个不同的概念，网关支付是针对第三方支付平台来说的，网银是针对银行来说的，只不过因为使用银行网银进行支付时，第三方支付平台充当了一个网关的角色，所以经常有人把这两个概念混淆。
6. 支付应用
常见的支付应用有：支付、转账、充值、提现、红包，基于以上规则还会衍生出很多的支付场景和应用。
7. 支付系统
支付系统比较复杂，每一个大的模块都需要用整篇文章来说明，本文暂不讨论支付系统，但是支付系统是支付体系的具象表达，所以设计&研习的基本模型不变。明确具体业务和场景的信息流&现金流以及基本规则，基于框架设计出业务闭环&逻辑闭环的系统模块。
三、支付模型总结
综上，我们可以得出支付产品设计的高阶方法论：基于基本的支付规则，明确每个支付场景和应用下的信息流&资金流转，结合可操作性的用户支付流程，从而设计出逻辑闭环的支付产品。
四、小公司如何对接第三方支付
1. 选择合适的支付公司&支付渠道
寻找合适的支付公司，可以通过百度去搜索相关第三方支付公司的资料以及排名等，看支付公司的背景和应用的商户的体量，支付渠道公司在支付行业内的知名度和沉淀（经验），这些可以从侧面体现支付公司的技术稳定性，产品稳定性。
在大前提的OK的情况下，具体了解其支付业务都有哪些，而平台需要的支付业务都有哪些，然后进行匹配。此外，还要考虑是否需要对接钱包和账户体系等。
准确传达目前公司的业务逻辑和支付需求场景，让支付公司推荐最优的解决方案。同时，洽谈范围中非常重要的还需要包含支取渠道收取平台的手续费的问题，还有就是支付渠道的分账是T+1（仅工作日次日）还是D+1（无论工作日与非工作日的次日）等等细节也都是需要在此阶段最终明确的。
下面是一些第三方公司支付渠道的一些性能参数，可以作为筛选的评判标准。

1.1 稳定性
支付渠道首先需要保持足够的稳定性，不稳定的支付渠道可能会导致支付流程崩溃、掉单等情况的发生。
1.2 成功率
支付渠道的成功率也是非常重要的，支付渠道的成功率较低的话会很容易导致大量的掉单的情况，用户的支付体验较差。
1.3 手续费
支付渠道的使用并非免费的，通过支付渠道的每一笔交易都会被支付渠道公司收取一定百分比的手续费，平台存在大量交易的情况下，选择手续费高的支付渠道会导致平台支付渠道的成本变高。因此，对比多家支付渠道的情况下，选择手续费较低且稳定性和成功率有保障的公司是最佳的。
一般大流量的平台往往可以拿到较低的手续费率，比如：支付宝和微信等第三方支付渠道给大型交易平台的支付手续费一般会在0.3%以下，甚至更低。而个人商户或者小平台的费率比较高，可能达到0.6%左右。
1.4 支付限额
出于资金安全和风控的角度考虑，很多支付渠道都会定义其对应银行支付的支付限额，比如：使用某支付渠道单日支付金额限制不超过5W。平台在选择支付渠道时，支付限额较高的渠道相对来讲具有更大的支付便捷性，在用户支付大额的订单金额时，不会很容易被限制而无法完成单笔支付。
1.5 其他因素（支付流程)
支付流程主要是关于支付渠道的的产品细节沟通，比如：该支付渠道公司的支付走的是认证支付还是快捷支付，还是两者都有？是通过API接口形式还是SDK嵌入的形式？
SDK嵌入形式会导致底层数据平台端无法获取，平台可以获得到的就是一个支付结果，但是API的对接形式平台自己可以监控整个的支付流程，包含支付中发生的异常情况监测，比如响应超时的情况等。还有，需要确认字段信息，支付四要素（姓名、身份证、银行卡号、预留手机号）等。
以上信息都是综合判断选择一家支付公司的评判标准。
2. 选择合适的支付公司后进行商务对接
确定支付渠道&形成支付产品逻辑闭环
在初步确定好支付公司后，平台方公司支付产品需要梳理出支付全流程业务需求，然后跟支付渠道公司做具体方案的对接和讨论，形成从用户的支付场景闭环到技术的闭环。
3. 技术对接
在确认好业务支付流程和具体的产品方案细节后，就将进入技术对接的阶段。这个阶段内双方公司的研发同学会进行技术层面的对接和调试，根据确定的支付流程细节的方案来确定需要开发的内容，并按照支付公司提供的接口文档和流程图等资料来进行支付功能的开发。
比较核心的内容就是”支付“和”对账“：关于支付主要考虑支付在交易流程中如何调用来唤起支付，而对账主要是进行公司内部对账、公司与商家对账、公司与支付渠道对账的数据记录。
PS：一般这种支付信息对账都是T+1进行的。
4. 测试调通
技术对接阶段完成基本对接和调试后，将进入双方协同的测试阶段，在遍历了全部业务流程的全部支付场景无误之后（包含异常流程的测试，比如：故意吧四要素信息填写错了，银行卡余额不足来测试等等），完成测试，并确定支付渠道产品上线。产品上线后，还需要一段时间的跟踪验证，对于出现的线上问题及时修复和处理，以保证支付渠道无BUG。
5. 进件
5.1 个体商户
小明开了一家饭馆，这个时候他想接入收钱吧的聚合支付，让客户自己扫码支付，提高收银效率。这个时候他只需要提交给支付公司以下资料就，审核通过就可以接通收钱吧的聚合支付。
个体商户全称需按照营业执照上登记的名称全称填写，简称的话可以填写品牌名称；
上传企业法人代表身份证照片（原件电子版）；
提交个体营业执照扫描件或原件电子版；
提交与个体营业执照商户名相符的门店照片（门面照、内景照及前台照）；
签署合同，个体商户由法人或负责人签字并加盖指纹；
结算卡信息必须使用营业执照法人账户。
5.2 企业商户进件
老王开了一家匹凸匹的互金公司，准备对接一家第三方支付公司来满足客户的充值，提现的支付需求。这个时候老王只需要提交一下资料给第三方公司，然后审核通过后就可以接入第三方支付。
商户名全称需按照营业执照上登记的公司名全称填写，简称的可以填写品牌名称；
上传公司法人代表的身份证照片（原件电子版）；
提交企业营业执照扫描件或原件电子版；
提交与营业执照公司名相符的门店照片（门面照、内景照及前台照）；
签署合同，企业商户由法人代表签字并加盖公司公章；
结算卡信息必须使用同名对公账户。
5.3 平台型企业
小赵有一家公司，这家公司类似于淘宝，连接店主和C端客户的交易。这个时候小赵需要对接一家支付公司，可以满足C端用户在店主商城支付的场景，同时能满足店主的充值提现需求。这个时候小赵公司如果有支付牌照，那样就可以完全可以满足以上的支付需求。
如果小赵公司没有支付牌照，那么他有两种选择：
第一种：代替店主向第三方支付公司进件，店主获得的收益会自动由第三方公司结算。优点是小赵的公司没有形成资金池，也不存在“二清”的违规操作，缺点是各个商户渠道侧的支付数据小赵的公司是拿不到的，如果店主出现对账问题，小赵的公司要第一时间解决是一件很麻烦的事情。
第二种：小赵可以公司名义单独进件，其他商户可以理解为公司的连锁商户。这个时候所有的交易流水都在一个商户后台，且能看到所有门店的交易数据以及解决对账问题。但是无法进行充值提现的需求，因为会形成资金池，在没有支付牌照的情况下这样做会涉及到“二清”的违规操作。