找回密码
 立即注册
搜索
查看: 72|回复: 0

60张手绘高清大图理清支付系统最核心的概念

[复制链接]

6

主题

0

回帖

18

积分

新手上路

积分
18
发表于 2024-12-8 23:25:12 | 显示全部楼层 |阅读模式
1.webp

支付系统因其专业性,术语或概念稍为晦涩不好懂。而我向来喜欢“一图胜千言”,所以为支付系统相关的概念画了300多张手绘风格的图,摘录部分供各位参考。
极致简化,真实的实现会复杂非常多。

1.账户分类
2.webp

在账务系统中,通常包含以下几种账户类型:

  • 客户账户:对客可见。包括:对私的个人客户账户,对公的商户账户。
  • 内部账户:对客不可见。包括:头寸、手续费收入、过渡户(也称中间户)等。

2.记账方向
3.webp

说明:
1)账户类型与借贷方向,相同为加,相异为减,也就是所谓的:DD+,DC-,CC+,CD-。
2)示例:用户提现100元,记账如下:

  • DR:用户余额(负债类账户)100
  • CR:提现过渡户(负债类账户)100

3.实时记账与缓冲记账
一般来说,客户账户的记账需要是实时的,比如用户充值、提现,商家提现,用户退款等。
这些账户如果不做实时记账,一来有损用户体验,二来有资损风险。比如用户充值100块,如果延时不到账,用户可能会投诉。如果提现不实时记账,用户有可能重复提现成功。如果退款不实时记账,有可能在退款场景下被透支。
假设记账需要几十毫秒(数据库性能决定的),一个账户最高也就只支持几十个TPS的记账请求,对于一些高并发的账户(也称为热点账户)一定是性能不足的。这个时候一般使用缓冲记账,以提高性能。开通缓冲记账的,通常是内部账户或允许商户透支的流出场景。
缓冲记账通常就是先记录流水,然后起定时任务去捞取流水,汇总后进行记账。前提是一定要做好资损防控。
除了缓冲记账外,还有拆分账户的方式来解决热点账户问题。
还没有画好,占个坑。

4.会计科目与会计分录
会计科目就是把会计要素进行分类,比如资产、负债等。通常都会有多级分类。
会计科目示例:
4.webp

说明:

  • 一般支付系统使用三级科目就已经足够。部分特别复杂的系统,可能会用到五级科目。
  • 为便于理解,上面的示例做了很大的精简,各公司内部对科目的编制差异可能会比较大。

5.记账方案
有了账户和会计科目,发生一笔交易时,如何让系统自动去记账?这个是记账方案做的事。其中一个解决方案就是给不同的交易场景制定不同的交易码,通过交易码来驱动记账。
下面是一个典型的支付系统的记账方案示例。
5.webp


6.会计日与日切
6.webp

会计日,也称为会计结算日或账务结算日,是支付平台在会计周期中进行账务处理和结算的特定日期。比如在分布式环境下,各机器可能存在时间差,一笔交易在零点时有可能跨天处理,如何判断一笔交易归属于哪天,就依据会计日来计算。
所谓日切,简单理解就是切换到下一个会计日。主要做的工作:

  • 借贷试算平衡:也就是所谓“有借必有贷,借贷必相等”这条会计恒等式的落地。
  • 父子科目试算平衡。
  • 总账试算平衡。
  • 日、月、季度、年汇总。
  • 会计日变更。
日切试算平衡核心逻辑:

  • 借方发生额 = 贷方发生额
  • 借方余额 = 贷方余额
  • 期末余额 = 期初发生额 + 发生额
  • 父科目累积额 = 子科目累积额

7.对账差异处理
对账一般有几种结果:

  • 对平:双方交易类型、单号、状态、币种、金额都是一致的。
  • 长款:我方多钱。支付长款:支付90块,渠道清算100块,或我方失败,渠道成功。退款长款:退款100块,渠道清算90块。充值长款、提现长款类比。
  • 短款:我方少钱。支付短款:支付00块,渠道清算90块。退款长款:退款90块,渠道清算100块。充值短款、提现短款类比。
因为我方和渠道之间有一定的时间差,所以长短款在T+1对账对不上时,往往先进入存疑清单里面,第T+2对账还是对不上,才会进入差异处理。
还没有画好,占个坑。

8.银行通道三层对账体系
7.webp

第一层是信息流明细对账。我方流水和银行清算文件的流水逐一核对。可能会存在长短款情况。
第二层是账单对账。就是把我方流水汇总生成我方账单,然后把银行流水汇总生成银行账单,进行对账。可能会存在银行账单和我方账单不一致的情况,比如共支付100万,渠道分2次打款,一笔98万,一笔2万。
第三层是账实对账。就是我方内部记录的银行头寸和银行真实的余额是否一致。可能存在我方记录的头寸是220万,但是银行实际余额只有200万的情况。

9.支付记账
我们通常说的记账,哪怕是一笔简单的支付,也会有多次记账。具体在什么节点记什么账,一般由财务人员决定。
下面是一个典型的使用银行通道进行支付的记账,会涉及网关过渡户,渠道待清算,商户待结算,手续费,银行头寸等多个内部户。
8.webp

说明:

  • 图中只画了正常场景,像明细对账出现差异(长短款)、账单对不平(渠道少打款或多打款)等场景没有画出来。
  • 上面只是一个典型的记账方案,真实的场景有些更简单,有些更复杂。
  • 开多个中间账户,什么场景下记到哪个账户,一般都是由财务团队决定。

10.商户结算记账
商户结算和用户支付是两个独立流程。
以典型的商户结算到卡记账为例,通常涉及商户待结算户,网关过渡户,渠道应清算,渠道已清算,银行头寸等内部户。
9.webp

说明:

  • 上述是商户结算到卡场景。
  • 各公司的内部户编制可能有所不同。

11.简明复式记账
金融机构的记账一定是基于复式记账法。下面以用户通过支付平台使用银行支付500块为例做个简要说明。
假设:支付平台使用CMB做为收单行,在CMB开设有备付金账户。
涉及的支付平台内部账户:
10.webp

记账步骤:
11.webp

说明:
1)持牌支付机构的记账一定是复式记账法。内部开设了很多账户和科目。

  • 【借记类】账户:资产,应收款等;
  • 【贷记类】账户:负债,所有者权益,应付款等;
2)借贷简要公式(不太严谨,但是够用):

  • 【借记类】账户(如资产,应收款),【增加】为【借】,【减少】为【贷】;
  • 【贷记类】账户(如负债和所有者权益,应付款),【增加】为【贷】,【减少】为【借】;
3)复式记账的专业书籍很多,这里只摘录几个重要的说明:

  • 复式记账法定义:对每项经济业务按相等的金额在两个或两个以上有关账户中同时进行登记的方法。
  • 记账原则:有借必有贷,借贷必相等。
  • 记账依据:会计恒等式:1. 资产 = 负债 + 所有者权益;2. 利润 = 收入 – 费用。
  • 账户:具有一定格式和结构,能够用来连续、系统、全面的记录反映某种经济业务的增减变化及其结果。
  • 科目:同类财务交易的分类,比如资产、负债、所有者权限、收入或费用等都属于科目。一般科目会分为多级。
  • 账户和科目的区别:科目只有名字,账户包括结构和格式,每个账户对应一个特定的科目。

12. 支付系统核心业务
支付平台尤其是持牌的收单机构通过都会提供非常多的服务,除了常见的支付、退款、提现等业务外,还会提供个人账单查询,商户账单下载等服务。
这里只介绍对客(包括个人客户和商户)感知的最核心的几个服务。
12.webp

一个持牌支付机构的系统一般会提供以下几个核心的对客能力:

  • 支付(收单):帮商户把用户的钱从扣到支付平台的账户。
  • 撤销:没有支付成功的直接关闭订单,已经支付成功的钱退回给用户。
  • 退款:把用户支付的钱退回给用户。
  • 清算:外部渠道把钱给到支付平台。
  • 结算:支付平台把钱结给商家。
  • 充值:用户把钱充值到在平台开的余额账户。
  • 转账:用户或商户账户之间进行转账。
  • 代发:帮商户把钱转到个人用户的账户。有代发到卡和代发到余额。
  • 调拨:支付平台内部因为流动性管理的需要,在多个银行账户之间转账。
  • 提现:用户把钱从平台的余额账户中提现到外部的银行卡。
一些跨境场景下,支付系统还需要提供外汇服务,比如中国商家在多多的海外品牌temu卖货,用户在美国支付的是美元,但是中国商家需要在中国拿到人民币。
除此之外,还会有很多辅助能力,比如商户入驻,商户自助服务,个人自助服务等。
任何一个业务在支付系统内部都是由多个子域经历很多操作步骤才能完成。比如支付业务的下单子流程,先是入口网关的验签,解密,然后请求商户平台的权限校验,再请求风控系统做风控校验,产品中心做产品校验等,最后在收单域保存入库。

13. 支付的本质
13.webp

说明:

  • 支付的本质是帮商户把用户的钱扣到支付平台的账户
  • 比较特殊是余额支付和营销,余额是平台内容开设的虚拟账户,不会调用外部渠道。营销往往也是调用内部的营销系统做核销,分有资和无资。
  • 涉及的记账,这里没有画出来。在后面的账务系统章节中有详细介绍。

14. 支付资金流
资金流在后面的账务章节会详细介绍,这里只做个简单说明。
首先是虚拟资金流,也就是支付平台内部的资金流,以即时到账模式为例,如下:
14.webp

说明:

  • 支付平台记账都是复式记账法,渠道扣款成功后,会同时记“支付网关过渡户”和“渠道待清算”。此处为了简化,只写了支付网关过渡户。
  • 还有分账、分润模式。比如:商户A是通过一个大商户B入驻到了支付平台,商户A收98块,大商户B收手续费1块,平台直接结算给商户A和大商户B,就是典型的分润模式。
实体资金流就是外部银行之间的资金流转。
15.webp


15. 退款本质
16.webp

说明:

  • 退款的本质就是把钱先从商户那里扣除,然后转给用户。
  • 余额支付的退款不会调用外部渠道。
  • 完整的流程很长。
比如:收到商户的退款请求后,需要先查询历史合约,检查合约是否支持退款,是否过了退款有效期,是否满足最小退款金额,全部通过后,就创建退款单并保存。接下来会进入退款资金准备阶段,因为从资损防控的角度,除非另有合约约定,否则支付平台一般是不会做垫资退款的。在退款资金准备阶段,需要实时扣减商户待结算户的钱,这是与支付流程很大不同的点。当然,有些支付公司可能和商户约定从独立的退款账户进行扣款,那也需要保证这个退款账户余额充足。

16. 退款资金流
17.webp

说明:

  • 退款校验通过后,需要做资金准备,归集到退款过渡户。调用渠道成功后,到渠道待清算。
  • 为了简化,只画了单边账户,实际记账时是复式记账。
  • 还有一些流程没有画出来,比如清算文件过来会对账,推进到渠道应清算,与渠道对账后,还会推进到银行头寸。

17. 外部渠道清算
外部渠道支付成功、或退款成功,都会涉及清算流程,简单地说,就是外部渠道把当天的支付、退款交易数据先进行轧差,然后生成一个清算文件,支付平台拿到这个文件后,解析并与内部的交易进行对账,对账成功后,从待清算户到应清算户,在渠道真实打款后,查到账单,再从应清算到银行头寸。
更详细的可以参考后面的账务域内容。
18.webp

说明:

  • 图中画的外部渠道是三方钱包的场景,也就是支付平台和外部渠道全部都是在银行开的账户,那就会有跨行转账。
  • 特殊情况下,外部渠道是一个银行,支付平台直接在这个银行开了账户,那就是外部渠道内部转账。

18. 商户结算
在收单机构(支付平台)里,结算就是把帮商户收进来的钱,按约定的结算规则、准确、及时地结算给商户
19.webp

结算前需要先做清分,就是把一笔支付的钱,根据当初签订的合约分成若干份。比如支付100块,平台手续费1块,商户99块。
根据合约,可以结算到余额,也可以结算到卡,结算还有结算周期,也就是所谓的T+n,其中的T是指交易时间,n指第几天结算。比如T+0就是当天的交易当天结算,T+2就是当天的交易在第3天才结算。

19. 充值
充值就是把用户的钱充到支付平台余额账户。余额因为涉及到资金安全,所以无论国内国外基本上都是需要持牌经营。
很多持牌机构都想让用户做充值,好处也很明显,比如:

  • 使用余额支付的成功率极高。
  • 因为有资金留存,用户打开的频率更高。
  • 在国外,如果利用好流动性管理,因为资金量足够大,利息或理财收益也很高。
20.webp

充值的核心只有2个点:

  • 支付平台调用渠道把用户账户的钱转到支付平台的账户。
  • 支付平台把用户的余额账户加上对应的金额。

20. 转账/代发/调拨
转账、代发、调拨的本质就是把资金从一个账户转到另一个账户。三者之间有一些细微的区别:

  • 转账:一般是指个人到个人的转账。包括余额到余额,余额到卡。
  • 代发:一般是指商户到个人的转账。比如代发工资。
  • 调拨:一般是指支付平台内部多个银行账户之间做流动性管理时的转账。
还有两种比较特殊的转账,就是发红包和AA收款。一对一的红包,本质就是一对一的转账,一对多的红包,本质就是一对多转账。AA收款的本质就是多对一的转账。
以转账到银行卡为例,用户A把自己的余额100元转给B用户在招行的银行卡,如下:
21.webp

说明:

  • 支付平台先把A用户余额账户扣减。
  • 然后调用外部渠道转账,由银行把支付平台备付金的资金转到B用户的账户上。

21. 提现
提现的本质也是转账,只是用户把支付平台余额账户的钱,转到自己在外部渠道的账户里。
与一般意义上的转账的区别在于,通常情况下说的转账是不同用户或商户之间的转账,而提现默认是自己余额账户的钱提到自己开设在外部银行的账户。比如支付宝或微信余额提现到自己在招行的账户里。
22.webp


22. 外汇
外汇业务表面上只是把一种货币换成另外一种货币,但是实际情况下是非常复杂的。比如需要区分自由流动货币和管制货币,交易有即期、远期、掉期等,涉及跨境电商有结汇入境和入境结汇。另外,外汇市场是全球最大的金融市场。
23.webp


23. 收单演进形态
无收单机构模式
24.webp

这就是小时候去小卖部买糖的模式,一手交钱一手交货。
好处:足够简单。不足:无法完成线上交易。
行内收单模式
25.webp

所谓行内收单,就是发行卡和收单是同一家银行。
好处:手续费低,成功率高。不足:业务比较受限,以线下收单为例,商户无法部署所有的银行POS机。
发卡行与收单行分离模式
26.webp

大部分情况下,用户的发卡行和商户的收单行是不同的银行。
不过,这种情况基本也已经灭绝,因为需要发卡行和收单行两两对接,形成一个巨大的网状结构,维护成本高昂。
清算机构模式
27.webp

发卡行和收单行之间不再直连,而是通过清算机构。清算机构通常是央行下面的特许经营的金融机构。这样围绕清算机构形成一个星形架构,所有银行只需要和清算机构对接就行。
当前银行间的交易基本上是这种形态。比如中国的银联,国外的VISA,MASTERCARD等,是卡组,也是清算机构。
第三方支付(电子钱包)形态
28.webp

随着互联网支付的兴起,以第三方支付为中心形成另外一个星形结构。
上图做了很大的简化。在中国因为断直连的关系,支付宝、微信支付背后的财付通等这些第三方支付机构都是对接银联、网联,而不是直连银行。但是在国外仍然是允许直连银行的。

24. 支付咨询
支付前需要调用收银台查看用户可用的支付方式,简称支付咨询,或支付方式咨询。
29.webp

上面的图分别是电商(京东)的收银台,支付平台(微信支付)的收银台。说明收银台是有多种存在形式的。
30.webp

支付咨询阶段,需要做以下几个工作:

  • 基础检查:可支付检查(有可能订单已经已经被支付),用户检查,商户检查等。
  • 资产咨询:绑卡数据,账户余额,营销(比如满减、红包等)。
  • 渠道咨询:通过币种、金额、渠道开关等。
  • 额度咨询:单笔限额、日累计限额、月累计限额等。
  • 支付方式组装:把上面的资产、渠道等组装成用户方便理解的支付方式。
  • 支付方式排序:把用户可用支付方式做好推荐排序(既要考虑用户体验,又要考虑营销策略)。
最后把支付方式返回给用户,供用户在支付时选择。

25. 支付受理
31.webp

用户选择好支付方式,点击“确认支付”,就到了支付受理阶段。主要做以下几个工作:

  • 在支付咨询阶段的工作全部做一遍。因为用户在支付方式渲染后有可能过了很久才支付,很多数据在后台可能已经发生变化,比如余额已变更,或者订单已经过了有效期等情况。
  • 全部通过后,调用风控进行风险判断。
  • 如果是外部渠道的卡支付,还需要调用渠道路由,选择出一条最优的渠道。
  • 然后是提交支付请求到支付引擎进行真实扣款。
  • 最后是从收单平台轮询交易结果。
特别说明一下:为什么轮询结果是从收单平台而不是支付引擎?因为对用户而言,收单的结果代表最终的支付结果。比如用户支付回来后,支付引擎是成功的,但是收单平台因为已经订单过期关闭,就会发起资金退回操作,这样收单平台的订单实际是没有支付成功的。就会提示用户:“订单已关闭,如果已经扣款,支付款项预计在X个工作日内原路退回。”

26. 常见渠道类型
有些公司称为通道,有些公司称为渠道,都是一个意思。下面统一称为渠道。
渠道类型在各个公司的定义是不一样的,没有一个行业标准,且持续在发展。先讲几个当前仍然通用的分类。
从资金流转的角度,渠道分为四大类:支付渠道、流出渠道、外汇渠道、信息渠道。
支付渠道
32.webp

这类渠道的核心作用是实现用户资金的流入。具体来说,它们将用户在银行账户中的资金转移到支付平台在银行的备付金账户。这个过程在我们日常生活中极为常见,典型的场景包括用户的充值操作和在线支付。
例如,当你使用手机应用进行购物支付时,资金从你的银行账户流向支付平台的账户,最后再结算给商户,就是通过这类渠道完成的。
流出渠道
33.webp

相对于资金的流入,流出类渠道则处理资金的流出。这包括两种主要情形:

  • 将支付平台的备付金转移至用户个人或商户的银行账户,常见于用户提现或商户收款的场景;
  • 将资金从一个备付金账户转移到另一个,通常用于支付平台内部的资金流动性调配。
流出类渠道确保了资金在用户和商户之间的顺畅流动,是整个支付系统的重要支撑。
外汇渠道
34.webp

这类渠道涉及货币兑换和跨国资金转移,支持不同货币间的转换和结算。在跨境电商、国际旅游等场景中,外汇渠道提供了跨币种资金转换的关键服务。且随着全球化贸易的增长,跨境支付需求日益增加,外汇渠道的作用变得更加重要。
信息渠道
这类渠道不涉及资金流转,比如个人实名认证(KYC),银行卡绑卡(纯绑卡)等。
支付类渠道
随着业务和技术的发展,支付类的渠道定义也是千奇百怪,或者说是与时俱进,下面是一些通用的分类。
卡渠道
35.webp

借记卡/信用卡支付:这是最传统且广泛使用的支付方式之一。用户通过输入卡信息进行支付,资金直接从其银行账户扣除。其中信用卡还有预授权、请款,2D、3D等场景。
还有所谓的预付卡,就是提前充值的支付卡,用户支付时,资金从预付卡余额中扣除。这个在支付平台一般不感知。
欧美国家的信用卡支付普遍使用得比较多。
除了使用卡明文直接支付外,现在很多渠道还支持先绑定后使用token支付的模式:
36.webp

支付流程和卡明文支付差不多,只是在发给渠道的报文中使用token替换了卡明文。
卡支付的交易有所谓的四方模式:商户、收单行、卡组、发卡行。这里的四方指的是四种类型的机构。
37.webp

网银渠道
38.webp

通过跳转到银行网站完成支付。这个操作麻烦,可能还需要密码控件,成功率不高,在中国已经很少使用。国外还有不少。
快捷支付渠道
39.webp

用户事先在支付平台绑定银行卡,支付时无需重复输入卡信息,便捷快速。在中国率先被支付宝发明出来并被推广,支付成功率从网银的60%左右提升到了96%以上。
国外有些叫“一键支付”,差不多一个意思。
代扣渠道
40.webp

代扣支付是一种银行或第三方支付平台在用户授权的基础上,直接从用户的银行账户或关联的支付账户中自动扣除款项的支付方式。
这种方式和快捷支付最大的区别在于:快捷支付是用户实时参与交易过程,有可能出风控挑战,比如OTP(短信验证码),或者密码等。代扣是提前授权,交易过程用户不会实时参与,也就没办法出挑战,要不成功,要不失败。
代扣广泛用于周期性支付场景,如水电费自动缴纳、会员服务费、订阅服务等,还有就是滴滴打车这种,下车就走。这种方式免去了用户每次手动支付的麻烦。
第三方钱包渠道
41.webp

基于第三方钱包账户基础之上的支付。在中国有支付宝、微信支付等,在国外有PayPal,GCash等。
第三方钱包通常是一个综合支付工具,除了钱包余额,钱包里面可能还绑定了银行卡。
钱包通常提供两种交互模式:

  • 跳转模式:比如在京东APP下单,选择使用微信支付,就会跳转到微信APP。
  • 非跳转模式:比如在淘宝APP下单,直接后台调用支付宝的免密支付。
VA渠道
42.webp

Virtual Account, 虚拟账户。用户通过银行生成的虚拟账号进行支付,常用于无卡支付场景。在东南亚用得特别多。
简单地说,就是用户没有银行卡,但是又要在网上购物,那么支付平台调用银行生成一个VA,并把这个VA和订单绑定,再展示给用户,用户拿着这个VA,去银行的ATM或银行柜台把现金存进去,银行通知支付平台这个VA入账成功,支付平台通知商户发货。
VA还会用于商家的收款(VA来账),这个是另外一个范围,不归属于支付类渠道。
OTC渠道
43.webp

Over-The-Counter,柜台支付。在支付场景下,和VA很类似,也是生成一个支付码,只是这个支付码是由7-11,肯德基等这些连锁店生成的,而VA是银行账户。用户拿着这个OTC码去线下连锁店,给店员现金,店员给这个OTC码充值,连锁店系统通知支付平台支付成功,支付平台通知商户发货。
信用付渠道
渠道根据用户的信用授予一定的额度,可以先消费,后还款。国外通常叫BNPL(Buy Now Pay Later)。
国内有支付宝的花呗,京东的白条。国外也有很多第三方金融机构提供类似的服务。
支付流程和第三方钱包差不多,只是需要先做开户和额度授权。
信用付与信用卡分期的区别:信用卡分期是以银行发行的信用卡为基础,而信用付基于第三方金融机构的账户授权(没有卡,非银行也能提供服务)。
在一些银行卡普及率不高的国家地区,信用付很有优势。

27. 渠道路由
44.webp

渠道路由核心作用是当有多个渠道同时满足业务诉求时,综合支付成功率、支付成本、用户体验、渠道状态等多种因素挑选出最优的一条渠道。具体如下:

  • 提高支付成功率:通过选择最合适的渠道,可以提高支付的成功率,减少支付失败带来的用户流失。原因在于不同的渠道在其内部的风险偏好是不一样的,同一个请求在A渠道会失败,但在B渠道会成功。
  • 优化成本:不同渠道的费用可能不同,通过合理的路由,可以降低支付成本。一些渠道还有阶梯收费,需要通过分流不同的渠道,保持整体成本最优。
  • 提升用户体验:快速、稳定的支付体验能增强用户的满意度和忠诚度。用户如果经常在A渠道支付,新的请求过来后,仍然发给A渠道支付的成功率往往会更高。
  • 负载均衡:将支付请求合理分配到不同的渠道,避免某个渠道过载,提升整体系统的稳定性。

28. 最简支付流程
45.webp

说明:

  • 这是一个最简化的支付流程。真实的交互比这个复杂得多,单收银台渲染就可以写一整篇文章。但对于讲清楚支付系统的作用,已经足够。
  • 从图中可以引申出支付系统最核心的作用:帮商户收钱。所以有牌照的也称“收单机构”。如果没有资质,只是做信息转发,也被称为“收单转接”。
  • 有支付当然就有退款、撤销等逆向操作,复杂的跨境支付还会有外汇交易,跨境结算等业务。

29. 最简清结算流程
46.webp

说明:

  • 这里画的是信息流。
  • 银行和支付平台之间是机构对机构的关系,通常使用清算概念,因为金融机构之间大部分情况下会由独立的清算机构完成清算服务。
  • 支付平台和商户之间,通常使用结算概念,由支付平台直接打款给商户。(清算与结算区别是中文环境才会有,本质是一个东西)
  • 上面画的是结算到商户开在支付平台的内部账户余额,所以需要商户手动提现,支付平台通常也支持直接结算到卡,这样就不需要商户手动提现。
  • 清结算三个字还有另外一层含义:清分 + 结算。前者是把钱算清楚,后者是真实打款。也有些公司叫清分清偿,前者算好钱怎么分,后面完成债权任务关系的完结。本质也是一个东西。

30. 最简本对本收单流程
47.webp

说明:

  • 所谓本对本收单,就是指商户的商品标价币种、向支付系统的下单币种、用户支付币种、商户结算币种都是同一个币种。不涉及到外汇交易。
  • 一个中国人拿着中国招商银行信用卡在中国境内通过多多买了两斤山东大樱桃,就是标准的本对本收单。

31. 最简跨境收单流程
48.webp

说明:

  • 所谓跨境收单,就是结算给商户的币种和用户支付的币种不一样,需要经过外汇机构换汇。
  • 在扣款EUR成功后,支付平台会调用外部的外汇机构进行锁汇(HA)。
  • 在银行清算后,支付平台再调用外部的外汇机构进行真正的换汇(TA)。
  • 最后支付平台结算给商户USD。
  • 上面也是只是跨境的一个小场景,真实的跨境场景极为丰富和复杂。不信你问问这段时间做俄罗斯生意收卢布的朋友们。
如果换成时序图,如下:
49.webp

说明:

  • 上面之所以有锁汇,是因为外汇时刻在变化,支付平台不想承担汇损风险,直接在支付款里加点手续费。能力强的支付机构也不需要锁汇,更高风险,但可能有更多收益。
  • 还有些渠道直接提供空中换汇的能力。比如土耳其用户使用TRY进行支付,在支付成功后,由渠道侧直接换汇成USD,然后由渠道直接结算USD给支付平台。
  • 一般来说,很多国家的货币是受管制的,无法自由出境,如果使用空中换汇直接拿到的就是USD,就比较容易出境。
  • 涉及跨境场景下,往往需要设计各种各样的资金流,最主要是考虑合规诉求,某次是收益。如果能力强,利用流动性管理,资金量大,收益还是非常可观的,毕竟外面不像某国要求备付金100%缴存央行,还不给利息。

32. 稍复杂的跨境支付示例
我们以最典型的电商购物举个例子(只是举例):小明使用PayPal在拼多多电商(海外)通过多多钱包(海外)支付了50美金。
经过简化后的交互图如下:
50.webp

说明:

  • 持牌的第三方支付机构和电商是独立的法律主体,所以多多钱包和多多电商是互相独立的,需要走独立的结算。
  • 为突出重点,中间省略了很多中间机构,比如花旗通过清算网络才能转账到汇丰,清算网络先略过。
  • 为简化描述,还有几个假设:


    • 假设拼多多电商选择结算到银行卡。还有一个场景是电商选择结算到余额,然后自己手动提现。
    • 假设单币种场景,跨币种场景还涉及到外汇兑换。


33. 最简信息流与资金流
51.webp

说明:

  • 用户在支付平台充值10元,支付平台向银行发起扣款请求,这些指令操作归属于信息交互,属于信息流。
  • 真实资金流:银行账户余额的变动。比如:银行在内部把用户的余额减10元,给支付平台备付金账户加10元。
  • 虚拟资金流:支付平台内部账户余额的变动。比如:支付平台内部把银行应收账户加10元,给用户余额账户加10元。
  • 为什么会有真实资金流和虚拟资金流之分?因为我们真正能拿到钱的地方是银行,在支付系统内看到的只是一个数字,如果想变成真实世界的钱,还得发给银行提现。

34. 加入结算的极简信息流与资金流
在支付流程中,就是商户委托收单机构(支付平台)把用户的钱收回来,然后再把钱结算给商家。
下面以典型通过外部渠道的卡支付为例说明。
52.webp

说明:

  • 用户的钱最终会走到商户的收款银行账户。真实情况下用户的支付的钱会分成多份,包括通道收的费用,支付平台收的手续费,税费,营销分润,商户结算款等。通道费用还可以继续细分为发卡行手续费,收单行手续费,清算机构手续费等。
  • 跨行一般都需要通过清算机构,这里为简化也没有画出来。
  • 支付平台内部的资金流在详细版中给出。此图有重复。

35. 极简跨境收单的协议关系
53.webp

说明:

  • 这只是跨境收单的一种协议关系,真实场景存在多种形态。
  • 上述的收单机构是持牌的,但是没有跨境结算的能力,所以需要委托有跨境结算牌照的金融机构代为处理跨境结算业务。
  • 跨境电商平台只是一个商户平台,没有收单资质,所以需要委托收单机构给它下面的供应商结算打款。
  • 剩下的协议关系都是一目了然的,只是我们日常没有注意。比如用户和电商平台之间在注册时就会有会员协议要签署。
  • 特殊的情况下,一些实力雄厚的机构,比如蚂蚁、财付通、连连支付、空中云汇等,下面会成立多个实体,然后用不同的实体去申请不同的牌照(收单、银行、外汇、跨境代发等),这样表面上全部是一家公司搞定,但是实际的协议关系仍然是上面这样的,在各实体之间仍然需要签署各种协议。
  • 如果是本对本收单场景就简单很多,没有外汇和跨境结算这一层关系,如果跨境电商的货品全部是电商实体自营的,那就更简单,没有供应商委托结算的协议。
  • 一般电商平台在没有牌照情况下是不能开设余额账户的,如果电商想开通余额,可以委托第三方有牌照的公司托管(通常也是收单机构,收单机构一般会同时申请PA、PG牌照),这种情况下,电商平台和收单机构还会签署账户委托协议。

36. 极简跨境资金方案
54.webp

说明:

  • 这是一个典型的跨境资金流案例。用户支付USD,收单机构收到的是USD,但是需要结算CNY给中国境内的商户。
  • 收单机构(也就是支付平台)需要先将USD兑换成CNH(离岸人民币),再由入境代发机构把CNY结算给中国境内商户。这是所谓的“结汇入境”。
  • 如果采用“入境结汇”的方式,则收单机构直接结算USD给商户在境外的银行账户中,由商户以USD汇入境内,再兑换成CNY。或者收单机构先把USD汇入境内备付金账户,再兑换成CNY,然后再结算CNY给中国境内商户。
  • 以上这些不同的资金处理方案,统称为资金方案。
  • 不同的资金方案,一方面要考虑合规的诉求,另一方面就是考虑收益最大化,以及资金周转的时效性。

37. 核心系统依赖图
55.webp

说明:

  • 图中画得比较清楚了,没有太多需要补充的。
  • 其中蓝色线为支付主链路。
  • 真实的调用关系如同一张蜘蛛网,从简洁出发,有些依赖没有画出来,比如收银核心也会依赖卡中心进行绑卡信息的写入和读取。

38. 支付安全
支付安全核心关注点:
56.webp

支付安全是一个很大的范畴,但我们一般只需要重点关注以下几个核心点就够:

  • 敏感信息安全存储。
对个人和商户/渠道的敏感信息进行安全存储。
个人敏感信息包括身份证信息、支付卡明文数据和密码等,而商户/渠道的敏感信息则涉及商户登录/操作密码、渠道证书密钥等。

  • 交易信息安全传输。
确保客户端与支付系统服务器之间、商户系统与支付系统之间、支付系统内部服务器与服务器之间、支付系统与银行之间的数据传输安全。这包括采用加密技术等措施来保障数据传输过程中的安全性。

  • 交易信息的防篡改与防抵赖。
确保交易信息的完整性和真实性,防止交易信息被篡改或者被抵赖。一笔典型的交易,通常涉及到用户、商户、支付机构、银行四方,确保各方发出的信息没有被篡改也无法被抵赖。

  • 欺诈交易防范。
识别并防止欺诈交易,包括套现、洗钱等违规操作,以及通过识别用户信息泄露和可疑交易来保护用户资产的安全。这一方面通常由支付风控系统负责。

  • 服务可用性。
防范DDoS攻击,确保支付系统的稳定运行和服务可用性。通过部署防火墙、入侵检测系统等技术手段,及时发现并应对可能的DDoS攻击,保障支付服务的正常进行。
39. 资损防控

所有支付公司都对资损(资金损失)看得很重,轻则钱没了,重则舆论风波,要是引起监管介入,更是吃不了兜着走。
常在河边走的支付人,如果想少湿鞋,一定要了解资损防控体系建设。
资损本质
57.webp

资损防控本质
58.webp

资损防控全生命周期
59.webp

资损风险分类
资损场景有很多种,但分类只有下面几大类:
60.webp

资损场景及应对
过于庞大,略过。

39. 结束语
一图胜千言,希望这精选出来的60张高清大图对大家学习支付系统设计与实现有所帮助。
内容主要包括支付系统核心业务,支付流程,结算流程,跨境收单,信息流与资金流,账户设计,记账,对账等。
相关的概念大部分做了极致简化,用于入门是极好的,对于理解概念也是够用的。不过真实的实现会复杂非常多。
这些概念如同支付核心系统拼图的一些小碎片,串起这些小碎片,对理解支付系统大图是大有裨益的。
深耕境内/跨境支付架构设计十余年,欢迎关注并星标公众号“隐墨星辰”,和我一起深入解码支付系统的方方面面。
这是《图解支付系统设计与实现》专栏系列文章中的第(50)篇。
作者:隐墨星辰,公众号:隐墨星辰
本文由 @隐墨星辰 原创发布于人人都是产品经理。未经作者许可,禁止转载
题图来自Unsplash,基于CC0协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Archiver|手机版|小黑屋|ARC

GMT+8, 2024-12-27 05:48 , Processed in 0.151563 second(s), 22 queries .

Powered by Discuz! X3.5

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表