这里有一套比较宏观的支付体系模型
2018/10/1 18:00:00 人人都是产品经理

    

     作者:Allen,火星移民计划PM

     微信公众号:思维改变生活

     全文共 8704 字 8 图,阅读超过 18 分钟

     ———— / BEGIN / ————

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

     文章结构:

     支付体系模型;

     支付规则详解;

     支付模型总结;

     小公司如何对接第三方支付。

     一、支付体系模型

     模型是复杂体系的简化,也是认识复杂体系的思维脚手架。

     支付体系的核心模型可以抽象为:信息流、现金流、支付规则。

     如下图:

    

     信息流:明确支付过程中每个环节的信息流转和状态响应,一些信息的流转最终会导致资金的在各银行账户之间的转移,只不过在信息的传递和价值的传递上有时间上的延迟,通常表现为T+1,D+1 等 (当然数字货币很好的解决了这个问题)。

     资金流:这里了定义的资金流指的是我们应该明确支付完成后具体的钱(也是数字)是怎么在银行与银行之间进行清结算的,资金流转发生在各银行账户之间。

     任何的支付的具体场景和表现形式,都应该明确信息流&资金流具体的流转过程,是我们梳理支付逻辑最近本的方法论。

     举一个简单的例子:微信公众号支付

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

     步骤1:如图7.1,商户下发图文消息或者通过自定义菜单吸引用户点击进入商户网页。

     步骤2:如图7.2,进入商户网页,用户选择购买,完成选购流程。

    

     步骤3:如图7.3,调起微信支付控件,用户开始输入支付密码。

     步骤4:如图7.4,密码验证通过,支付成功。商户后台得到支付成功的通知。

    

     步骤5:如图7.5,返回商户页面,显示购买成功,该页面由商户自定义。

     步骤6:如图7.6,微信支付公众号下发支付凭证。

    

     上述是一个完整的支付流程,能清楚地看到各种信息状态的流转以及响应。

     能够直观感知的是银行卡余额的减少&话费增加这样的信息,实际支付背后资金的流转逻辑是:

     二、 支付规则详解

     1. 支付渠道

     支付渠道,顾名思义就是平台上支持用户支付的通道,这些支付渠道帮助平台用户完成交易金额的支付,并且支持平台与银行之间进行资金流转、对账和清分。

     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端用户在店主商城支付的场景,同时能满足店主的充值提现需求。

     这个时候小赵公司如果有支付牌照,那样就可以完全可以满足以上的支付需求。

     如果小赵公司没有支付牌照,那么他有两种选择:

     第一种:代替店主向第三方支付公司进件,店主获得的收益会自动由第三方公司结算。 优点是小赵的公司没有形成资金池,也不存在“二清”的违规操作,缺点是各个商户渠道侧的支付数据小赵的公司是拿不到的,如果店主出现对账问题,小赵的公司要第一时间解决是一件很麻烦的事情。

     第二种:小赵可以公司名义单独进件,其他商户可以理解为公司的连锁商户。这个时候所有的交易流水都在一个商户后台,且能看到所有门店的交易数据以及解决对账问题。但是无法进行充值提现的需求,因为会形成资金池,在没有支付牌照的情况下这样做会涉及到“二清”的违规操作。

     5. 进件审核通过—正式调通

     进件审核通过后,技术同学会拿到生产环境的参数,然后进行配置并测试后,正式上线。后续出现什么问题如果需要支付公司协助解决,可以直接联系他们。

     参考资料:

     百度百科,百度知道,知乎

     《万字长文,详解线上线下收单业务(一):第三方支付 》

     《2个案例,6个章节聊聊支付渠道的那些事儿!(支付渠道浅析》

     《从产品分类、模块功能和业务流程,了解支付产品服务的设计》

     ———— / END / ————

    

     ———— / 推荐阅读 / ————

     >> 支付战争:移动支付5年纪

     >> 支付宝10.1,社交还是支付?

     >> 支付宝、微信、银联的移动支付三国之战

     >> 支付系统中,账户体系的设计与记账处理

     >> 写真+限权,支付宝的「社交」到底行不行?

    

     专为3年以上中高阶产品经理量身定制

     帮你重构产品总监的核心技能体系

     点击“阅读原文”查看课程详情

    http://weixin.100md.com
返回 人人都是产品经理 返回首页 返回百拇医药