支付系统的基础层面和入门

9 评论 9949 浏览 114 收藏 10 分钟

本文作者主要从狭义方面对支付产品系统进行了讲解,不涉及清算核心、账务核心、账户核心,适用于刚入行的同学。

做支付产品有一段时间了,平时总有人问我支付相关的问题,之前也有梳理过支付系统相关内容,供内部分享,但是对外却不一定适用。今日文思泉涌,就写写练手,也希望可以和更多人交流学习!

说到支付系统,我们首先需要知道他的使命是什么,简单说,就是给各类业务场景提供支付能力。

如果我们要服务的业务方很多,那支付系统为了支撑更多的业务方,他设计的前提就是应该具备模块化、组建化的公共服务,也就是人们常说的基础服务。

这样可以实现可复制、可配置的业务支撑作用。基于这个层面,我们一般把支付系统作为中台的一部分。

说到支付,我们首先需要明确的是,信息流和资金流的概念。

  • 信息流:指完整的交易流程信息,包括交易、支付、结算指令等信息流转的过程。
  • 资金流:指交易资金的流动,包括储蓄卡余额的变动、信用卡授信额度的变动、钱包余额变动等过程。

基于以上概念,我们开始进入正题:

一、支付系统架构(信息流层面)

1. 应用层

指的是在各种支付场景中,使用我们服务的对象(业务方),这些场景包括:线上买东西,提交订单需要支付;你吃完饭,需要支付;你购买某个理财产品,需要支付充值。

2. 服务层

主要指各个业务方需要我们提供支付能力时,我们能提供的功能服务,比如我们目前可以提供收银台服务和部分包装好的接口服务。

收银台服务中,我们可以提供各类支付方式,比如:银行卡快捷支付、信用卡支付、网银支付、支付宝、微信等第三方支付平台支付。

接口服务中,我们主要提供的有扣款、付款(提现)、退款、分账服务供业务方调用。

3. 基础层

主要是指支付路由及渠道网关。

支付路由,即通过某种模型或者规则进行渠道选择,支付路由会帮助你选择最优的渠道(比如选择成功率高的、费用便宜的)。

根据不同阶段、不同公司的业务情况,支付路由的复杂性不同,目前主要有人工路由及自动路由(系统根据规则进行自动路由选择渠道)。

当筛选出对应的渠道后,我们需要请求到对应渠道的网关。由渠道执行相应的流程动作。

从目前的情况而言,大部分支付公司都是通过与银行间的连接,都是需要通过银联/网联进行清算的。

4. 支撑层

主要指在整个支付系统里面起到支撑作用的服务,比如:监控预警、异常处理(重试、补偿任务)、数据大盘。

二、支付渠道

从上述内容中可以看到,我们要提供给各个业务方支付能力,依赖的是支付渠道,那我们就来说说支付渠道的那些事。

1. 渠道对接模式

(1)直连模式

2018年6月30日之前,很多支付公司都是直连银行模式,由各个支付公司和银行合作,银行开放接口给支付公司。各家支付公司各凭本事,看谁接的银行够多,额度够高,价格够便宜。

各家支付公司的能力,就体现在支持的银行数多不多,额度够不够高,价格够不够便宜。

(2)网联模式/银联模式

2018年6月30日之后,由于出台新规,开始断直连,支付公司和银行间,需要接入网联/银联,这两大组织作为清算机构,连接支付公司和银行。

在这种情况下,扣款能力,主要取决于银联/网联推出的扣款产品。这时各家支付公司的能力都差不多(支持银行数、限额、费率),我们也不用接太多渠道;

2. 渠道产品

(1)代扣

就是平常说的‘裸代扣’,我们可以调用支付公司的代扣接口,通过四要素完成扣款,不需要用户验证短信验证码。

由于断直连,目前市面上裸代扣接口越来越少了,目前市面上的代扣,基本上都是包装的。主要通过:

  1. 没有断掉的直连接口包装;
  2. 银联提供的无卡支付等产品包装;
  3. 撞库获取到协议支付的协议号包装。

PS:目前主要都是传四要素进行扣款,但是有些扣款渠道是二要素(身份证、卡号)、三要素代扣(姓名、身份证、卡号),所以可能支付能力上会有不一样,二、三要素成功率更高。

(2)快捷支付

与代扣的区别是,用户在首次支付时,多了一个签约的过程,用户会进行短信校验,后续的支付过程无需短验。

  • 签约:是指发卡号像用户的银行预留手机号发送验证码,用户回填验证码,完成签约后,生成一个唯一的协议号(银行卡号、支付公司、发卡银行三方)。
  • 支付:通过协议号,无需短验,即可进行扣款。

很多时候我们把网联的协议支付和银联首次验短的产品都叫快捷支付。

基于此基础,很多支付公司包装了一些支付产品,比如:每次支付都需要短信验证的认证支付。首次需要发短信,但是是支付公司发短信的假协议支付、假快捷支付等。

3. 渠道服务

除了刚刚说的支付服务,这里主要说的是扣款服务,我们第三方支付渠道,还可以提供其他服务,比如:

  1. 付款服务,即代付,背后可能对接的是银联代付、人行大小额系统等。
  2. 退款服务,原路退回或者代付。
  3. 分账服务,实现一笔支付可分账给不同的商户号或不同的账户。
  4. 鉴权服务,包括实名认证,二、三、四要素鉴权。

三、支付路由逻辑

刚刚提及了我们支付路由的2种方式,第一种过于简单,我们忽略。

现在我们主要来说一下,自动路由(规则路由)。

既然说是规则路由,那我们就可以得知,这套路由的模型,是根据一个个路由规则来搭建的。

我们可以通过两类规则来实现:一是过滤规则,将不能用,不可用的规则进行过滤;二是排序规则,将更好、更优的渠道筛选出来。

规则的执行,基于支付要素开展的,那支付的要素都有哪些?

1)卡信息 包括:银行卡归属银行、卡类型(借记卡、贷记卡)、卡属性(对私、对公)

2)限额 包括:单笔限额、单日限额、单月限额

3)费率 包括:固定费率(X元/笔、0.2%*金额)、阶梯费率(小于1000元 2元/笔、大于2000元0.2%*金额)等等。

4)业务要素(主体、业务类型等)

公司不同业务挂在不同主体上,需要开不同的商户号,配置的渠道也不同,需要通过主体号进行区分。

业务类型不同,选择的渠道也不同,比如:退款、代付、分账。

5)运营规则(优先级、特殊判断处理)

这个主要是针对成功率、特殊错误信息等运营上进行调整的规则。

好了,基于支付系统基础层面的内容基本上讲完了,如果还有问题可以留言交流指正,相互学习。笔芯~

 

本文由 @لبيبة  原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 再讲讲啊,出个续集

    来自广东 回复
  2. 线索

    回复
  3. 背景来说 为什么新规会要求断直连呢

    回复
    1. 1、成本和效率层面,直联需要各个支付公司和各家银行对接,成本高,效率低
      2、监控层面,直联方式,支付公司自己扮演了清算角色,支付巨头担任了央行职责,数据脱离了央行的掌控

      来自浙江 回复
    2. 针对该回答的第“2”点我做一下补充说明,当然他的回答也是正确的,但我想解释一下为什么会是充当央行的清算角色及背后隐藏的风险问题,我通过一个假设的场景的描述一下,假设一家第三方支付公司的存管银行是A,两家合作银行分别为B和C:
      1、消费收款场景:用户用B银行卡充值100元,此时这100块钱最终会结算到B银行的备付金中,用户用C银行卡充值200元,此时这200块钱最终会结算到C银行的备付金中,此时支付公司为了统一管理资金或者根据实际情况会将合作银行B和C的资金归集到主存管银行A备付金账户中,也叫头寸调拨。那么现实场景中会有很多用户进行充值操作,一般来讲在进行资金调拨时基本就是一笔转账且走央行的清算系统,那么我们看到这里就是央行在以上场景中只是知道调拨的资金流向,具体这笔调拨的资金都是谁充进来的一些明细信息央行是掌握不了的;
      2、用户提现场景:某用户想提现100元,这100块钱可能来源于消费收款、朋友虚拟账户转账等场景,那么如果用户提现的银行卡是B银行,那么支付公司就会从B银行的备付金进行出款给用户(同行转账),这个时候我们就看到了这本质上就是在做清算功能,因为用户提现的资金来源可能是其他银行的资金,而且央行没有任何记录(因为是银行内转账),银行与银行之间的清算关系一直以来都必须是央行的菜,这就绕开了央行的清算系统且给很多不法分子洗钱等犯罪活动提供了温床;

      补充说明一下,以上举例是在断直连前的情况,因为个人知识水平有限,难免有疏漏的地方,请批评指正或沟通交流。

      来自河北 回复
  4. 写的太好了 解决了一个做支付的设计师业务基础问题

    回复
  5. 代扣里说的:撞库获取到协议支付的协议号包装。 可以具体说明下吗?非常感谢。

    回复
  6. 为什么我的页面是空白的。。。

    回复
  7. 写的很好很详细

    来自北京 回复