前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >一文搞懂第三方支付系统架构设计

一文搞懂第三方支付系统架构设计

作者头像
腾讯云开发者
发布2024-10-18 13:02:12
210
发布2024-10-18 13:02:12
举报
文章被收录于专栏:【腾讯云开发者】

支付方式的发展历程是怎样的?第一方、二方、三方、四方支付是什么?三方支付系统的背后支撑体系是怎样的?一个第三方支付系统由哪些部分组成?各个组成部分的作用原理是什么?本文作者将细致而全面地带你深入到支付系统的技术设计中,助你体系化掌握支付系统的技术全貌!

本文将是一个系列内容,后续还将发布交易、退款、结算等各个环节的技术知识,感兴趣的读者朋友记得关注腾讯云开发者公众号,不错过后续内容

关注腾讯云开发者,一手技术干货提前解锁👇

01、序言

1.1 背景

支付方式的发展历程是怎样的?第一方、二方、三方、四方支付是什么?三方支付系统的背后支撑体系是怎样的?一个第三方支付系统由哪些部分组成?各个组成部分的作用原理是什么?我会尽可能以通俗易懂的方式来组织结构,从客观现实需要来引出实现,让读者能够更容易理解这一金融基础设施的内部基本原理。

文章内容仅为个人观点,如有不同看法,敬请指正。

1.2 专业名词

本节预先介绍一些下文出现的重要专业名词(下划线标注),可快速浏览便于后续返回查阅。

专业名词

名词解释

支付工具

具有第三方支付能力的应用,如微信支付、支付宝都属于第三方支付工具。何为“第三方”在下文介绍,第三方支付工具后续简称为“支付工具”。

用户

在支付工具中注册并开通和使用支付功能的人,就是该支付工具的用户。

商户

接入支付工具,对用户提供服务并收款的机构或个人。

用户账户

指第三方支付系统中为用户开具的账户,我们用User Account来代指,下文简称U账户。

商户账户

指第三方支付系统中为商户开具的账户,我们用Merchant Account来代指,下文简称M账户。

备付金

支付机构为办理客户委托的支付业务而实际收到的预收待付货币资金。可以简单理解为用户暂存在支付机构开具的银行账户中的资金。

系统资金

指第三方支付系统中登记的账户余额资金,本质上只是一个计算机系统数字记录,并不具备法定货币效力。

物理资金

指银行账户中存在的法定货币资金,可以近似认为是等同货币的真实物理资金。

支付

狭义的支付仅指用户向商户划转资金,广义的支付还包括充值、转账等功能。

付款

指资金从支付机构的备付金账户转出到目的银行账户。如用户将微信余额提现到自己的工行银行卡,此时资金从微信的工行备付金账户转账到用户的工行账户,这是付款的一种典型业务场景。

退款

指支付机构将用户支付的款项从商户账户退回到用户账户或银行卡的过程。

结算

是支付机构将商户账户中的资金,按照合同约定的时间和费率,收取手续费后转入商户的用户账户的过程。通常支付机构还会为商户提供自动提现到银行卡的附加功能。

02、支付发展历史

我们日常生活中使用的微信支付、支付宝都属于第三方支付应用,那么什么是第三方支付?为什么叫做第三方支付?第一方支付和第二方支付又是什么呢?还有第四方支付吗?我们不妨以支付历史发展进程来对它们进行一一阐述。

2.1 第一方支付

第一方支付如下图所示:

第一方支付即现金支付,从最早出现货币的时候,我们就开始并长时间依赖于这种支付方式。“第一方”特指买卖双方直接以法定货币进行交易,即一手交钱一手交货,资金不通过任何中间机构。随着商业的发展,大宗交易不再适合使用现金进行支付,第一方支付不再能满足需求。

2.2 第二方支付

第二方支付如下图所示:

第二方支付是依托于银行的支付方式。买卖双方通过银行来进行资金的划转,避免了大额现金交易带来的安全、携带、保存、清点、验证等问题,使得大额交易变得快捷、方便、安全和简单。由于银行操作存在一定的成本和使用门槛,因此第二方支付逐渐从日常生活和小额市场的支付中淡化并退出,转而在一些巨额的交易和政策性的金融活动中发光发热。

2.3 第三方支付

第三方支付是指具备一定实力和信誉保障,并获得国家颁发运营牌照的独立机构,采用和各大银行签约的方式,通过与银行相关接口对接而促成交易的网络支付模式。我们熟悉的微信支付和支付宝都属于第三方支付工具。第三方支付工具随着移动设备+互联网的大范围普及而迅速占领日常生活中的各种交易场景,逐渐取代了大部分的中小额现金交易。

2.4 第四方支付

第四方支付实际上是聚合了多个第三方支付、合作银行的渠道接口,为商户提供一站式的支付解决方案:

第四方支付的优势在将多家第三方支付聚合在一起,给商户提供了一站式的支付解决方案,同时便利了商户和用户。但第四方支付目前缺乏政策资质,存在较大的资金安全风险

03、第三方支付概述

本章将对第三方支付进行整体性的描述,包括角色拆分、账户体系、原作模式以及领域划分等。

3.1 领域角色

回到我们第三方支付的介绍图中:

上图中涉及到了4个角色:用户、商户、银行以及第三方支付工具本身。由此可见,第三方支付系统必须至少在内部抽象出3种角色来为用户、商户和银行服务。由于支付主要涉及到的是资金的记录和流转,适合以账户形式承载,因此延伸至第三方支付系统中的3种账户。

3.2 三种账户

账户是支付机构内部为其服务对象(用户、商户、银行等)创建的物理记录(类似于表格),这些记录包含了对象的关键信息,如机构为对象分配的唯一 ID、对象的余额、交易的流水、账户状态等等。可以说账户是支付机构识别服务对象的根本,所有服务对象都必须要有账户。

根据第三方支付的服务对象,我们将抽象出三种账户:用户账户(User Account)、商户账户(Merchant Account)以及银行账户(Bank Account)。

3.2.1 用户账户(User Account)

一个用户的账户需要记录什么信息呢?需要有一个唯一的账户 ID 避免记录混乱,需要为用户记录余额,需要记录账户的资金变动过程(流水)。如下图所示:

用户账户的行为特点是什么?

  1. 很少并发:同一时刻通常只会发生一笔交易,因为支付需要用户手动去操作。
  2. 交易频率较低:一个普通用户通常一天只会支付数笔。
  3. 余额敏感:用户对自己的账户余额及其变动非常敏感。

这些特点是很直观的感受,但对我们后文深入的介绍会有很大影响,此处先做了解和铺垫即可。

3.2.2 商户账户(Merchant Account)

商户账户需要记录的最基础信息同用户一样,也是 ID、余额和流水。

商户账户的行为特点是什么呢?

  1. 高并发:同一时刻会有很多用户向同一个商户支付,促销活动时更甚。
  2. 交易频率高:一个商户一天的交易可能会非常大。
  3. 余额变动不敏感:由于商户伴随着用户的不断支付,余额会快速变化,因此商户本身对该账户余额不敏感。

3.2.3 银行账户(Bank Account)

Bank 账户映射的是各大银行,其账户如下所示:

银行账户的特点是什么呢?

  1. 数量有限:银行账户映射的是各大银行,因此数量有限。
  2. 金额流水庞大:一个大型支付机构和银行的资金交易往来通常都是以亿为单位,金额特别庞大。
  3. 并发量高:拥有同一银行卡的用户非常多,这些用户同时使用银行卡支付、体现的量级也非常大,其量级比单个商户会大很多。
  4. 余额不敏感:因为是支付机构内部为了映射银行而开具的内部账户,银行并不会关注,所以除了支付机构本身,没人会关注该账户余额。

3.2.4 对应关系

上述3种账户和第三方支付角色的对应关系是怎样的呢?是直接一对一吗?如下图所示:

用户只拥有用户账户就足够了,而商户则往往同时拥有商户账户和用户账户,银行则只对应于银行账户。

为什么商户还额外拥有用户账户呢?这是出于资金管理的需要。商户账户中的资金并非全部归属于商户本身,其中有一部分是第三方支付机构将会收取商户的佣金。只有在支付机构收完佣金后的净额才归属于商户本身,才能任其自由使用。

简而言之,商户账户中的资金商户无法直接动用,需要在支付机构收取完佣金后结转到商户的用户账户中才能自由提取。这其实就是结算过程,后续结算卷会有专门的文章讲解,此处仅做简单了解即可。

3.3 切换视角

以一个常见的菜市场买菜的场景为例,在用户视角,支付过程如下:

用户挑选好蔬菜后,打开微信支付,扫描卖家二维码,输入金额和密码完成支付,拿走货物,用户角度的支付过程到此结束。但从系统的角度来看,支付仅仅只是整个交易链路中的过程之一。在交易的事前事后还需要很多其他过程的协助。

让我们跳出用户视角,思考一些深入的问题:

  1. 我们购买货物的微信余额是怎么来的?如果使用银行卡支付,那么钱是如何从银行卡转移到微信的?
  2. 当我们的银行卡急需资金,选择从微信提现到银行卡时,资金是如何转移的?
  3. 用户支付的钱是怎么给到商家的?微信支付有收取支付手续费吗?向谁收取的?什么时候收的?
  4. 当我们对购买的货物不满意,想要退款时,资金是如何退回的?

由此可见,想要真正了解支付,我们的关注点就不能只停留在用户的角度。

3.4 运作模式

支付机构本质上还是资金相关的操作,我们知道第三方支付涉及用户、银行和支付机构本身。接下来让我们尝试用上文的账户体系来分析一下常见的支付过程。

3.4.1 初始状态

我们将以一个典型例子来说明,涉及对象的初始状态如下图所示:

涉及的用户有两个,张三和李四,他们分别有自己的微信账户和银行账户,微信也在银行开具了自己的银行账户,称为备付金账户(专业名词章节介绍)。他们各自的余额如上图所示。

3.4.2 用户充值

现在假设张三想要通过自己的银行卡充值20元到微信余额,资金变动如下图所示:

首先是张三的银行账户向微信备付金账户划扣20元,成功后微信则给张三的微信余额加20元,充值完成。

PS:用户在微信中绑定了银行卡,因此不需要用户去银行转账,而是通过微信与银行间的接口来自动完成该笔资金的划扣。

3.4.3 用户提现

假设李四想要将微信中余额提现10元到自己的银行卡,则资金变动如下:

首先将李四的微信余额减去10元,然后微信支付调用银行接口,从微信备付金账户中转账10元到李四的银行卡中,提现过程结束。

PS:这里减去李四微信余额时并不是直接减掉,而是先冻结,等银行侧成功转账后再实际减去。冻结和解冻的细节和原因将在付款卷中详细介绍。

3.4.4 用户转账

假设张三要给李四转账20元,则资金变动如下图:

此时,张三的余额先减20,然后李四的余额加20,转账完成。

PS:微信转账有确认收款的过程,如果我们要用上述账户体系来完成这个功能,可以怎么做呢?这个问题将会在支付卷中探讨。

3.4.5 资金变动汇总

从上面的表格我们注意到:备付金账户和微信账户的变动净额总是相等的。

  1. 在充值时,微信体系余额增加,则备付金账户也会增加相同的金额;
  2. 提现时,微信体系余额减少,则备付金账户的余额也会减少相同金额。
  3. 转账时,只是支付工具内部账户之前的划转,不涉及资金流入和流入支付体系,因此备付金账户余额不变。

因此,我们可以认为所有支付系统余额是所有备付金银行账户余额的映射。我们称微信余额为系统资金,银行余额为物理资金。如果物理资金小于系统资金,则说明物理资金被挪用,可能会导致用户无法提现。国家会监管持牌支付机构的备付金使用情况,避免这样的情况出现。

3.5 支付交互

上一节介绍了用户账户、银行账户之间的一些常见交易类型,本节将介绍涉及商户账户的支付过程,如下图所示:

用户和商户也都拥有自己的银行账户和微信支付账户。微信支付作为中间桥梁,将银行、用户、商户连接起来,共同构成了整个交易网络。 从交互图中可以看出,支付系统具有很多重要的功能:

  1. 充值。用户将银行卡中的资金转移微信支付中,成为微信余额的过程。
  2. 提现。用户或商户将微信余额转移到银行卡的过程。
  3. 支付。这里特指用户将资金从自己的现金账户划转到商户的交易账户过程。
  4. 退款。支付的逆向过程,将资金从商户账户退回到用户账户。
  5. 结算。用户支付给商户的资金,在收取手续费后,划转到商户的现金账户的过程。

上述功能中,有的只涉及用户,如充值和提现;有的同时涉及用户和商户,如支付、退款;而有的只涉及商户,如结算。

3.6 领域拆分

让我们对上面的各种交易类型做一个整合,在业务领域上进行拆分和归纳,如下图说是:

下面对这些领域及其职责进行简单说明:

  1. 支付(广义):负责支付、转账、充值等基础交易能力的提供。
  2. 退款:负责将用户支付的资金从商户账户退回用户账户或用户银行卡。
  3. 付款:负责将支付体系内的资金提取到指定的用户银行账户,即提现。
  4. 结算:负责按照合同约定的规则,将商户交易账户的资金划转到商户现金账户,并收取交易手续费。

各个领域提供基础能力,并服务各种各样的业务场景。有的业务场景需要多种领域能力合作完成,如结算业务需要依赖于付款的提现能力。

04、结束语

在上文的介绍中,我们说明了几个重要的问题:

  1. 什么是第三方支付。
  2. 第三方支付机构的账户体系是怎样的。
  3. 第三方支付业务背后的资金是怎么在账户间流动的。
  4. 第三方支付系统包含哪些主要领域。

在本文中,我们从全局的角度简单说明了一个支付系统的构成和运行过程,并对第三方支付领域做了拆分。后续文章将会对每个领域进行更详细的探索和理解,包括其主要业务流程的实现思路以及一些有趣的问题探讨。

如果觉得文章还不错,欢迎关注个人公众号“此行无捷径”,与君互勉共前行。

-End-

原创作者|周成

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2024-10-17,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 腾讯云开发者 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 01、序言
  • 02、支付发展历史
  • 03、第三方支付概述
  • 04、结束语
相关产品与服务
云开发 CloudBase
云开发(Tencent CloudBase,TCB)是腾讯云提供的云原生一体化开发环境和工具平台,为200万+企业和开发者提供高可用、自动弹性扩缩的后端云服务,可用于云端一体化开发多种端应用(小程序、公众号、Web 应用等),避免了应用开发过程中繁琐的服务器搭建及运维,开发者可以专注于业务逻辑的实现,开发门槛更低,效率更高。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档