最近有一些交流，我发现大家对支付的理解其实还是有很大不同。

据我个人观察，做支付的起源会导致大家的认知有很大的差异。对于从支付公司出身的同学而言，基本理解会较为一致；在商户侧做支付的同学更多的会认为支付就只是收单。而清结算、账务和支付系统无强关联。这种理解没有孰对孰错之分，都是不同环境造就的认知差异。

对于很多同学看到的支付系统认为就是收单、收银台、支付渠道对接等资金收款方面的流程，这个理解也不能说错，但个人对支付的理解，是更广义的支付结算资金管理系统。是从资金收款、到清分结算、到账务记账管理等完整流程。

简单概括整套系统的核心模块，包含交易、收银台、渠道/路由、清结算和账户。

渠道/路由很容易理解，核心作用是接入外部渠道，进行资金流通，路由则需要在成本和效率之间进行一系列策略的决策，选择当前交易下最优的渠道。

清结算可以从字面理解，清分+结算，核心作用是将交易成功后的支付订单，进行各类角色、费项的计算和分类，最终将资金结算给对应的商户/用户。这里就有认知差异，核心区别其实主要是清分对象不同，支付公司使用支付订单，而商户侧一般使用业务订单进行计费清分结算，对象不同，导致支付系统的范围也就发生了差异。

而交易和账户，一个是资金的流通管理，一个是资金的记账管理。交易有支付交易、业务交易的概念区别，账户记账也会存在是以那个模块为核心驱动记账的差异，导致大家也会理解不一致。

详细的内容之前其实有单篇讲过，这里根据部分同学的诉求和反馈，进行简单整合，方便大家一起阅读。之前已经读过原文的同学，可以pass，也可以温故知新。

01交易模块

你有没有遇到过这样的问题？

公司业务模式一变或者新增其他的业务模式，交易模块就得大改？

为什么都是交易模块，电商的交易模块和支付系统的交易模块设计完全不同？

有的系统能轻松支持“购物车合单支付”，而有的连“拆单、退款”都做不好？

确实，在互联网行业，“交易”这个词被广泛使用，但不同业务场景下的“交易模块”有着天壤之别。

比如，我们在淘宝下单交易模块负责的是订单创建、库存锁定、商品优惠计算；而当我们用支付宝付款时，交易模块负责的却是支付路由、资金划拨、风控拦截。

那么问题来了：为什么不同业务模式下的交易模块设计差异如此之大？

答案很简单：因为业务模式不同，决定了交易的本质不同。

电商交易关注的是商品与订单的流转，核心是商品流通，所以交易模块要解决的是订单履约问题；

而支付系统交易关注的是资金的流转，核心是资金流通，所以交易模块要解决的是支付成功率、资金安全、交易对账的问题

一个是"物"的交易，一个是"钱"的交易，自然设计思路迥异。

1.1支付系统交易模块的业务定位和需求分析

不管是何种交易，交易模块的核心目标是类似的：在业务场景中，安全高效地完成业务过程的流转。

但不同业务场景对交易的需求不尽相同，开篇有提到，这里在展开下：

电商交易：主要是为了订单履约（库存、商品优惠、物流），比如淘宝购物下单；

支付交易：主要是为了资金处理（支付、退款、结算），比如支付宝支付下支付单，

金融交易：主要是为了资产划转（计息、资金核对、账户变动），比如基金申购赎回。

所以，对于不同的业务类型，交易的核心载体也不相同：

电商的交易模块，核心是订单；

支付的交易模块，核心是支付指令；

金融的交易模块，核心是资金账户处理。

一句话总结：交易模块本质上是业务模式的抽象。

本文主要探讨支付系统的交易模块的设计方法，所以后续的交易都针对支付系统的交易模块展开。

可以想象一下，如果支付系统没有交易模块，支付系统会是什么样？

用户发起支付请求后，直接调用银行或支付公司接口完成扣款。

看起来简单直接，其实有非常多的问题没法解决，比如：

支付过程中断怎么办？

如果需要对同一笔资金进行多次处理怎么办？

需要支持复杂的支付组合怎么办？

需要记录完整的资金流转轨迹怎么办？

这些都是支付交易模块解决的问题，所以交易模块存在的意义：它是支付系统链接业务系统和底层支付渠道的入口和“转换层”；

支付系统交易模块的核心作用，我个人认为有以下4个：

记录交易行为：比如谁付钱？付给谁？付多少？状态如何？

管理资金流动：比如钱怎么进、怎么出、怎么冻结、怎么结算？

支持业务扩展：比如能否支持合单？能否拆单、退款？能否适应新业务？

封装统一能力和服务：比如能否统一对接所有支付渠道？能否适配各种支付产品的不同差异？

我们可以把支付系统交易模块的核心定位基本概括为：

通过统一的服务，整合多维度的支付渠道和支付产品，链接业务需求和资金流转，并保证全链路的一致性、安全性和高可用性。

所以交易模块是支付系统中最复杂的核心模块之一。

1.2支付系统交易模块的结构和设计

我们先看一套典型的支付中台的交易流程做开始，窥见交易模块在整个支付系统的位置，窥全貌见细节。

整体系统各模块交互流程

从图上我们可以看到，交易系统是业务系统请求处理的先锋，业务系统需要按照标准接口，将支付请求给到交易系统，交易系统会落单，并将请求转发到关联模块处理。

这个当然还不能解释交易系统需要如何设计，还需要引申出交易模块中的两个核心概念：交易类型、交易模式。

上文提到交易模块是业务模式的抽象，核心就是通过这两个概念的组合完成通用的处理。

交易类型，主要针对资金流动方向的角度而言，可以简单理解成主要是从付款方角度看到的资金处理，主要包括：

支付：定义为付款方扣款，

退款：将资金退还给付款方

转账：将资金从A转给B

充值：将自己的资金从银行卡转移到记账账户

提现：从账户将资金划转到自己的银行卡

代付：将资金付给别人的银行卡

当然基于实际的支付业务，还有其他一些类型，可能不涉及资金变动，但也是要处理的交易，比如签约，银行卡绑卡进行四要素签约，也可以是一种交易类型。

交易模式，是针对“支付”这个交易类型的行为方式。淘宝首创的担保交易，就是针对电商行业开创的非常了不起的一种交易模式。这个可以简单理解成主要是从收款方角度看到的资金处理，常见的交易模式有：

即时到账：用户支付后，资金直接给到商家

担保交易：用户支付后，资金先要放在担保账户，等确认收货后才给到商家

预授权交易：用户确认后，资金是先做冻结，后续才真实扣款

订金模式：用户先支付部分订金，业务结束再收取后续尾款

不同的交易模式代表着用户支付成功之后的资金处理流程不同，会影响后续的清结算和账务处理。

我们拿典型的电商担保交易举例看下整体处理流程

担保交易流程

交易收到业务系统请求，给到后续系统执行支付扣款

扣款成功后，因为是担保交易，支付系统先行记账到担保账户或者商家待结算账户（根据平台账户体系可能有区别）

用户确认收货，交易将订单给到清结算

清结算清分商户应结算金额及平台分润等各类费项，将资金分账到对应账户

如果是即时到账，那用户支付完成之后，收单记账完成会直接给到清结算，清分完成即时就给到了商户账户。

交易模块这两个概念确定之后，后续的大部分业务场景基本在类型和模式上进行扩展就可以满足。

另外通过上图也可以提炼交易模块提供出去的能力基本包括了：

正向的下单、支付；

逆向的关单、退款；

相应的查询服务

需说明，交易模块是一个大模块，本身其实也是可以分层的，一般典型的会分成两层：

交易层：主要关心支付业务的受理，

关键业务信息包括：交易订单ID、子交易订单ID（如有）、交易类型、交易的状态（待支付、支付中、支付成功/失败；逆向的退款中、退款成功/失败等）、交易金额、币种、收款方、付款方、创建时间、更新时间、交易成功时间等

支付层：主要执行真实的支付动作，

主要的业务信息包括：支付单ID、关联的交易单号、支付方式、渠道、实际支付金额、支付状态、支付时间、更新时间等

渠道层是否算在交易，这个仁者见仁智者见智，但总体上肯定是大交易其中的一环。所以也暂时放在这。

一笔交易单可能有多笔支付单，同样的一笔支付单也可能有多笔渠道单

下面咱们挑两个典型的交易场景，模拟下方案扩展

第一个典型的场景是电商业务的购物车。

购物车场景下，一笔业务订单包含了多个不同商户的商品，这就意味着在给商户进行记账和结算时，需要按照商户维度分别清分结算，但用户希望可以一笔就完成支付。这要求交易模块具备合单支付的能力。

合单支付还是交易类型的一个扩充，在普通的支付类型之外，新增合单支付的场景。

1、业务系统到支付系统下单时，除了提供业务订单外，还需要提供各子业务订单信息，

2、交易系统会按照相应结构生成交易的主单和子单，

3、后续调用支付渠道时，是一笔渠道请求，

4、支付成功，分别更新各子交易订单状态和主交易订单状态

5、最后通知业务系统

支付系统内部后续给商户进行清分和结算时，按照子交易订单维度分别清分。

第二个典型的场景是用户分多次/多阶段支付，比如用户需要用余额和银行卡组合支付。

这个场景下，业务系统到支付系统只需要下一次支付单即可，用户在支付时选择组合余额和银行卡支付，这需要交易具有拆单支付的能力。

1、业务系统到支付系统下单，

2、交易按照用户选择的组合或者配置逻辑自行组合，分别生成主单和子单（详细的拆分逻辑不一定是在交易受理层，也可能是在交易内部的其他层别，比如支付层，需要根据实际系统架构来）

3、交易各自调用不同的渠道完成支付，最后分别更新子交易单状态后，在统一更新主交易单状态。

这个拆单是支付系统自行处理的，需要有这个能力，但是业务侧不一定有感知。

和合单支付不同的是，后续商户记账和结算时，要按照主交易单维度处理（当然也得根据拆分逻辑看），要不然商户收到两笔款，会有些疑问，虽然资金总额是一致的。

这里抛一个问题，如果使用同样的支付方式比如银行卡支付，碰到渠道限额不足，比如通道单笔限额1w，但用户需要支付2w，这时候怎么处理？

想到这个问题是写到这发现，拆单和合单的逻辑，在一套灵活的交易系统中非常常见，也呼应了上文一句话：一笔交易单可能有多笔支付单，同样的一笔支付单也可能有多笔渠道单。

当然交易模块也涉及到和风控、会员等系统的交互，而且交易本身也有分层，交易层、收银层、支付层等等，不同公司有不同的模块和概要设计，所以以上讲的方案和设计也不一定完全符合所有的场景。

甚至有些功能的实现不一定是在支付的交易模块实现，在业务侧也不是没有方案。所以又回到之前的一句话：产品要结合实际的场景和诉求，根据公司不同的阶段和情况，找到适合的方案。一味的套用框架或设计，反而可能适得其反。

1.3交易模块的数据指标体系不能忘

交易模块虽然不像收银台，没有对用户的UI界面展示，但是交易如果有问题，会影响用户的使用体验。顺利的情况下用户无感，但是异常的情况下用户就会有很明显的体感。

用户只会抱怨咱们收银台不好用，但我们自己知道问题其实是在交易环节。

所以交易模块的一套数据指标体系也是非常有必要的。

我个人觉得交易模块的数据指标可以从以下两个维度安排：

基础交易指标

交易量：每分钟/小时/天的交易笔数

交易金额：每分钟/小时/天的交易总额

退款金额：每分钟/小时/天的退款总额

成功率：成功交易占总交易的比例

退款率：退款金额占总交易金额的比例

平均耗时：从发起到完成的平均时间

这些指标看似简单，但需要根据不同维度进行拆分分析，比如按支付渠道、按交易类型、按商户等继续细化。

进阶交易指标

支付方式分布：各支付方式的占比及表现

时段分布：交易在不同时间段的分布情况

金额分布：不同金额区间的交易分布

失败原因分析：失败交易的错误类型分布，要按照交易失败原因统计

这些指标可以帮助发现潜在问题，比如某渠道成功率突然下降，可能意味着该渠道接口出现异常。

同样监控指标设计完成之后，需要建立实时看板，并设置关键指标的预警阀值。

1.4交易系统设计建议

如果你正在设计或优化支付系统的交易模块，建议可以从以下几个方向开始：

梳理业务场景：列出所有需要支持的交易类型和模式，不仅仅是现在的，可预见的将来如果需要支持，也可以一并考虑；

设计核心定义：比如定义交易、账户等核心实体及其关系，特别是不同交易模式下对后续账户流转过程的梳理；

绘制流程图：将各种场景的处理流程通过时序或者泳道图等画出来，这样可以查漏补缺看逻辑是否闭环，有没有遗漏；

制定并完善监控方案：确定关键指标和监控方式，并建立完善看板。

另外交易系统有些坑，是可以规避掉的：

比如不要过度设计，保证模型的通用即可，梳理归梳理，但不需要上来就把所有的交易模式都支持掉，可以分步骤迭代升级；

另外不要低估并发：支付场景往往有突发流量，要做好压力测试，当然这个开发同学一般都会考虑；

最后再重申不要忘记监控：没有监控的交易模块就是在裸奔，产品不提需求，研发同学再没有进行监控设计，那真的就是一出事故就直奔火葬场的节奏。

我个人是觉得支付系统没有完美的设计，只有适合业务的设计，而适合的支付系统不是一下子设计出来的，是迭代出来的。

所以不需要追求一步到位，不要被各种"高大上"的方案迷惑，从业务本质出发，解决实际问题才是王道。

支付系统的交易模块，虽然很复杂，但也不是无规律可循。只要咱们从业务出发，理清资金流向，不遗漏所有需要的交易类型和模式，有合理的状态机，再做好通用可扩展的模型设计，我们一定可以得到一套稳定、灵活的交易系统

02收银台

收银台大家都不陌生，从古代的实物柜台一直延续至今，现在去商场购物结账也依然存在前往收银台刷卡/付现金，拿到付款小票再去领商品，或者推着商品在收银台一个个清点完商品在付款。

在电商业务和现代电子支付体系发展之前，这是一个最普遍的交易转换形式。

接着就是到电商业务的飞速发展，伴随着现代电子支付的建设，收银台发展成了线上模式，变成现代支付系统最显而易见的部分。

收银台的设计好坏关系到用户的使用体验，进而关系到商户的交易转化，可以说这是大部分支付流程的起点和用户转化的关键节点。作为支付领域从业者，如何设计收银台是一定会经历或者需要知道的事情。

那如何设计一套好用的收银台？收银台设计到底有哪些讲究和需要避雷的坑，本文我们一起来探讨。

2.1收银台的业务定位和需求分析

虽然收银台的形式不断演变，发生了很大的体验上的变化，但收银台的业务定位和核心职能其实一直未曾变化：核对交易信息、提供付款方式、确保资金安全转移。

在设计收银台时，前文介绍的5W2H的需求调研和分析的方法正好可以用上，重点确定需要为谁，解决什么问题，怎么解决。

在整个支付结算体系中，收银台是链接用户、商户、支付系统的核心节点，所以对于收银台需要从不同的视角下来看。不同的公司和平台，不同角色，对收银台的考虑点不尽相同。

用户视角：用户作为收银台的直接使用者，希望的是界面清晰，逻辑简单，操作流畅，支付方式丰富，错误提示及引导流程友好。如果在支付时还能有些优惠更是锦上添花。

商户视角：商户最关注的是用户支付的转化率，希望用户下单后尽快完成付款动作，减少中间漏斗损失。同时商户对收银台的诉求，希望能支持灵活多样的支付方式配置，五花八门的营销活动展示，对各种业务场景和交易模式的支持，比如预售，定金，组合支付等。

支付公司或支付中台视角：作为通用型组件，支付机构或商户内部中台更注重收银台的平台化能力和风险控制。能支持多商户、多业务的快速接入，提供标准的API和SDK，实现支付方式的智能路由及风险控制。

所以，在支付公司设计收银台，和在一个平台型商户设计收银台，第一优先目标不同，侧重点不同，自然方案会有些许差别，导致的结果就是收银台在不同平台和场景下的形态可能有很大的差异。

电商平台的收银台是整个电商交易的一环，可以认为是用户下单流程的延续，为了提升用户支付速度和降低决策成本，经常采用“嵌入式”设计，减少页面跳出，最典型的例子比如X多多，收银台隐藏很深，主动选择切换支付方式才会看到收银台主页。

而对于支付公司或者垂直行业的saas服务商，则更倾向于提供标标准化的收银台能力，典型的如支付宝/微信的收银台。

2.2典型的通用收银台架构和系统交互设计

结合前文所述，不同公司/平台对收银台的设计有不同考虑，所以我们的方案设计不能直接穷举罗列。

还是那句话：产品要结合实际的场景和诉求，根据公司不同的阶段和情况，找到适合的方案。一味的套用框架或设计，反而可能适得其反。

所以关于怎么设计收银台，本文只能找典型和通用的进行阐述。

还是先看典型的支付中台的交易流程，了解收银台在整体支付结算系统中的位置。窥全貌见细节。

支付系统各模块交互流程

这张图并不能解释如何设计收银台，其作用主要是有个宏观概念，需要理解，收银台不只是简单的页面展示，需要多个子系统协同工作。

收银台的详细设计，从架构层面看，收银台通常采用前后端分离的设计思想，前端负责界面展示用户交互，服务端处理业务逻辑及和后续子系统的对接。

收银台的整体交互流程，市场已经被微信/支付宝的设计方式教育趋于同质化，可以概括为四段式交互：收银台下单-跳转拉起收银台支付-服务端结果回调通知-前端页面回调返回。

结合所有上述前后端分离的思路和与其他子系统交互的整体链路，我们基本可以描绘出一个典型的收银台全链路的交互流程。

典型的收银台全链路的交互流程

这里面收银台与周边系统的交互链路是设计难点。其中收银台服务端承载着相当多的业务逻辑。收银台可以设计的非常简单，但也可以设计的很复杂，这里面最大的区别就在于收银台服务端承载的能力和功能模块划分。一个标准典型的收银台服务端至少需要承载以下能力：

支付方式的获取和扩展：服务端需要根据商户、用户情况，找到当前条件下所有可用的支付方式。就会有相应的商户配置，用户配置信息交互。并且设计时需要考虑后续新增支付方式的灵活扩展功能。

路由引擎：获取基本的支付方式之后，但不代表这些支付方式用户一定可用，所以还会有业务路由模块确认最终可使用的支付方式。路由的规则要素，可以非常多，当前设备类型、终端版本、业务场景、地理位置等等。我建议这些因素从设计开始就考虑进来，比如终端和设备，对于展业使用app的商户就很重要，不同设备版本能支持的支付方式是有区别的；不同业务场景下能使用的支付方式也会存在不同，比如加油业务和电商业务拓展的支付渠道不同，支持的支付方式能力不同；地理位置特别是在跨境业务场景下，需要根据不同国家和地区展示当地习惯的支付方式。

推荐策略：决定支付方式的展示顺序，优先展示哪个。这里还需要结合其他子系统，比如用户画像，历史交易数据等。引导用户使用低成本的支付方式也是一种推荐策略。

营销管理：和营销系统交互，确认当前支付是否存在营销内容，获取相应信息之后并在收银台前端展示

收银台前端界面设计也很重要，需要一点交互心理学和基础的设计能力，展示哪些信息元素，重要信息的呈现方式，这些就不赘述了。原型输出是产品再基础不能基础的技能了。

另外收银台和交易的关系，这个在架构上其实可以按需调整，有的公司收银台是交易的上游系统，有的公司，必须先到交易下单才能唤起收银台。

这个的判断区分标准，我个人总结是看公司的业务形态有多复杂，需要多复杂的支付交易系统。比如电商有合单和拆单等比较复杂的场景，那必须先到交易进行合单或者拆单的下单，在返回拉起收银台的参数，并且拉起收银台之后也需要和交易进行下单数据的核对。如果交易模式比较简单，也完全可以先到收银台再到交易下单，只不过交易模式的提炼薄一些。

2.3收银台的数据指标体系建设

收银台作为支付转化的关键环节，优化离不开数据的支撑。所以我们需要建立完善的数据监控体系和指标体系，评估优化的结果，也发现潜在的问题和改进点。

当然数据优化是个需要持续循环反馈的过程，不一定只是产品涉及其中，需要多部门配合协作，如运营、技术同学等。

收银台的核心监控指标，可以用来评估收银台的“健康度”。有6个指标个人建议是必须进行监控的：

支付转化率：从进入收银台到支付成功的用户比例，反映收银台整体效率

支付方式切换率：用户更换初始推荐支付方式的频率，反映推荐准确性

支付时效：从进入收银台到支付完成的平均时长，影响用户体验

各支付方式成功率：识别渠道性能问题

失败原因分布：指导针对性优化

用户回溯行为：支付失败后的行为路径分析

这一切的前提当然是基于数据埋点，数据埋点前端和服务端都需要在关键节点部署埋点。埋点数据应当尽量包含用户ID、设备信息、网络环境、交易特征、详细交易细节等信息。

前端埋点主要用于后续的转化漏斗分析，分析各个步骤间的转化率，快速定位主要流失点。常见的转化漏斗包括：

高首页流失：收银台加载速度或首屏设计问题

支付方式选择页流失：推荐策略或支付选项展示问题

确认支付页流失：金额或收款方信息引起用户疑虑

支付过程中流失：渠道性能或交互流程问题

服务端埋点主要是为了后续能有足够的上下文信息，前后端埋点结合可以进行更精准的分析。

针对收银台的关键节点，可以考虑以下埋点

收银台加载开始

收银台加载完成

支付方式列表展示

支付方式切换事件

支付确认按钮点击

支付请求发起

渠道跳转/调起

支付结果返回

支付成功展示

支付失败展示

错误提示展示

重新尝试支付

放弃支付离开

埋点之后还需要建立实时监控看板，帮助团队快速发现和响应问题。并针对一些异常情况进行告警，比如支付成功率突降，支付时长延长，特定的支付方式失败率升高，某个错误码集中高频出现等。预警阀值也得基于历史数据动态调整，避免过度警告。

03账户体系

收单成功之后，那为了资金的管理，所有的支付相关链路和环节都需要进行详细的记账，保证账务的清晰明确，可追溯可管理。

但看了很多账户相关的架构和理论，还是不明白账户系统需要怎么设计？

知道账户的功能，充转提、开户销户、冻结解冻，但还是不知道怎么应用，是吗？

或者觉得账户很简单，不就是上面那些功能吗，资金到了，余额加一笔就行了？

如果你有上述的疑问或者理解，其实不是什么怪事，因为账户最隐晦的那部分并不可见，想要弄清楚账户如何设计或者深刻理解账户，最核心的是需要搞清楚账户系统最基本的一个环节：账户流转。

账户系统复杂的，从来不是某个单独账户的功能或者管理，而是整个账户体系的搭建和协同配合。

需要哪些账户类型？每个账户的开户条件和流程怎么设计？账户的流转规则是如何定义的？怎么和上下游系统联动？另外还需要考虑账户的性能、安全等方面。

账户其实是支付结算系统中最复杂的一部分，它需要咱们深刻理解业务流程，抽象业务模型转化为账户模型，还需要根据业务不同场景制定账户的开通流程和功能权限，以及最重要的在不同的交易场景下定义账户资金的流转规则，同时兼顾账户安全和性能。

所以账户是集业务、资金、交易、合规、安全、技术等多个维度的综合体现，但账户设计的复杂度，我个人认为80%来自于业务规则，而20%来自于技术实现。不是说技术不重要，而是业务的多样性和复杂性是账户体系的更大难题。

以我个人在支付结算领域的经历，常听到一句话：账户体系设计决定了支付系统或者交易系统的天花板。可见账户系统的重要性。

我也看了一些账户拆解的文章，写的非常专业，所以我想从另外的视角，不堆叠那么多的概念和逻辑，尽量用简单直白的语言，讲明白设计思路，特别是为什么这么设计。

如何弄清楚？先看一张图。看懂这张图，我相信大家对账户就已经理解了80%了。

3.1一张图get账户系统到底做什么

我们假设的场景如下：用户消费购买100元的商品，实际支付90元，平台有活动补贴10元，收单渠道手续费1元，平台从商家抽取技术服务费5元，最终结算95为例。

话不多说，先上图。

电商平台支付中台，用户支付-补差-抽佣-结算-提现全记账流程

这张图的实际例子，是参考电商平台用户完成一笔消费并给商家结算的流程。当然只举例了正向流程。

不同公司实际的设计可能和我举例的有区别，为什么有区别？因为这个和咱们平台选择的二清解决方案、整体架构、财务要求等都有关系，也和咱们是商户还是支付公司等有区别

但不用担心，看完这部分，大家也就理解为什么会不同了。

而且我举的例子是一个非常完整的记账链路，实际公司使用可能不一定需要这么全链路记录，特别商户侧。支付公司一般都会完整记录。

看到这张图，大家可能有以下疑问：

资产、负债是什么？

为什么有这些账户，为什么取这个名字，从哪来的？

为什么这么记账，而不是直接到商户账户？

怎么触发记账节点的？

其实搞懂这些问题，你就完全知道账户是怎么玩的了。我们一个个来解答你的疑惑。

首先，第一个问题资产负债。

账户设计需要一些财务会计基础。参考我举例的复式记账法的情况下。

现在大部分商户和支付公司都是采用的复式记账法，是一个比较通用也比较合理的方式，平衡了业务要求、资金管理要求和财务要求。你说，用单边记账行不行，只记录单向的流水行不行，也行，这个看平台实际的资金管理和财务诉求。

会计基础不用担心，我们不需要那么深入去理解财务的领域知识，复式记账是财务非常基础的一个领域知识。也很好理解。核心我们就记住下面这个公式和一句话：

资产+费用=负债+权益+收入

有借必有贷，借贷必相等

大家应该经常能听到资产、负债、收入、费用这些名词，这些是财务管理使用的会计要素，可以理解成是科目的分类，常说的科目就都是这些分类下面的子类目。

科目可以设置多级，而每一个账户都会有个科目。举个例子，资产类科目：银行存款-工行6699银寸账户。

这个公式的推导过程也列上，感兴趣的同学可以看看：

首先很好理解，利润=收入-费用

而公司的资产=负债+所有者权益+利润

所以，资产=负债+权益+收入-费用，那运用数学公式，把费用挪到左边就变成了

资产+费用=负债+权益+收入。

这个公式的运用，就是下面那句有借必有贷，借贷必相等。也就是发生金额变化的科目如果在等号两边，那就是同增同减；如果发生的科目在等号的同一边，那就是有增有减。

举两个简单的例子：资产增加10元，是因为公司收入了10元，所以收入也增加10元，两边等式还是相等的对吧；如果公司支出了5元费用，那资产也就减少了5元，所以资产减5，费用加5，两边还是相等的。

当然财务语言上，不叫增加或减少，而是叫借和贷。增加和减少是为了方便大家理解，要记住不是说某个科目增加就一定是借或者贷，这个可以这么记忆：

资⾦、费⽤增加为借

资产、费⽤减少为贷

收⼊、负债增加为贷

收⼊、负债减少为借

第二个，这些账户为什么叫这个名字，怎么来的？

首先这些账户名称不是我们自己定义的，这些的来源可以说是公司财务。所以设计账户之前，需要和财务先沟通好，公司到底有哪些科目，这些账户都对应到那个科目，并确认财务的核算规则，资金到底需要怎么记账，记到哪些账户。

因为每个公司的财务体系和科目设计可能有非常大的区别，所以这些必须要和财务确认好。要不然后续账户记账不知道要流转到哪个科目。

但是还有个问题，为什么是这些账户，而不是其他账户？和财务确认的是这些账户都核算到那个科目去，但这些账户是怎么来的呢？

这些账户的来源，归根到底就是咱们的业务需求。我们需要将业务的资金流理顺，并明确出来中间哪些节点需要记账，用到哪些账户。

所以第二个问题转换成咱们做账户设计的语言的话，就是：不同的业务流程下需要用到哪些账户，这些账户都需要核算到那个科目下。

这里面已经可以窥见账户设计的两个核心环节了：

一、需要和业务沟通，梳理完整的业务流程，并整理相应的资金流，看需要使用哪些账户

二、和财务确认核算规则，明确每一笔交易的资金需要如何记账，核算到那个科目

请记住，这两步是账户设计必须经历的步骤，跳过后续肯定会出问题。

第三个问题，记账是怎么被触发的？

这个问题本身并不复杂，因为账户记账是个被动事项，肯定是有某个模块给到账户指令，让账户开始记账。

复杂的其实是指令，给什么样的指令，账户能明确知道需要怎么记账。

这就是账户的规则引擎，以及和周边模块的联动。账户需要和上游约定好类型，账户收到这个类型的指令，就按照事先编排好的规则进行记账。

到这里，我们回到上面这张图，再来仔细看一遍整体流程，这里会结合交易的流程一起阐述：

<

1、用户支付环节，交易系统完成了收单，通知业务系统外，支付核心会给账户发送记账指令

不同公司有不同设计，可能不一定是支付核心通知，也可能是其他业务交易系统，特别平台类商户，在没有做支付中台的情况下。理解这里交易成功后肯定有个trigger会给到账户记账就行。

账户收到指令后，找到指令其中的交易类型、交易模式、支付渠道等信息，发现这是担保交易，并且是一笔支付交易，而且支付渠道是走的支付宝直连渠道1（可能有多个支付宝渠道，这里引申下，渠道的新增也要和财务确认科目），在这里财务给了两个科目：支付宝渠道1-渠道待清算、商户待结算。

用户用卡支付完之后，真实的资金，支付宝并不是当天就能给到绑定的银行结算卡的（因为支付宝也有下游的渠道，资金并不是立刻就给到了支付宝，真实的资金一般是D+1，当然支付宝账户余额里已经可以看到了，但是不能提现。能提现的话就是支付宝垫资了）

所以，这是一笔待结算到给我们平台的资金，记成在途清算，后续平台将收到一笔来自支付宝结算到银行卡的真实资金，所以这是资产，记账为：资产-支付宝渠道1待清算-借90

按照上面的口诀，有借必有贷，贷在哪呢？这笔资金不是平台自己的资金，后续是需要结算给商户的对吧，所以这同时也是一笔平台对商户的负债，所以负债-商户待结算-贷90

2、支付成功之后，渠道会收取咱们的手续费，那在这里又和财务约定好两个科目，渠道手续费记账账户和渠道手续费真实出金的账户。

一般渠道手续费记账都是在第二天和渠道对完账，确定交易金额、笔数、及手续费均没有问题才会记账。

渠道手续费应付是个负债类记账账户，记录了应该付出去多少手续费；渠道手续费实付是真实的费用支出，所以是个费用账户，资金会真实从咱们账户扣除；这里记账：负债-渠道手续费应付-借1，费用-渠道手续费实付-贷1；

3、D+1真实资金到银行卡了。财务确认资金无误后，支付宝的渠道待清算账户就没有资金了，而是划转到了真实的银行存款账户-公司的对公卡上。所以这里继续记账：资产-支付宝渠道待清算-贷90，资产-工商银行6699银存账户-借90

直到这一步，收单交易才算完整记账了，可以看到，一笔收单交易，对应了多笔记账。

4、因为营销活动，用户实际只支付了90，所以平台还需要在进行补差10元。这里是从补差账户将资金给到商户待结算账户去，所以记录：负债-平台补差户-借10，负债-商户待结算-贷10；

补差户的资金是申请预算之后补充的，那这部分是要花出去的钱，本质上也可以理解成是对商户的负债，原因是由于对C端的补贴。

5、这时候商户待结算账户已经有了100元，用户收到货之后，需要给商户结算了，平台清结算清分计算之后，抽取技术服务费5元，商户应结算95元。所以记账：

负债-商户待结算-借5，收入-平台收入户-贷5；

负债-商户待结算-借95，负债-商户可用余额-贷95；

6、商户将资金提现走，是从平台的银行账户将资金付款给了商户的银行卡，平台对商户的负债没有了，同时平台对公银行卡内的资金也出去了，记录：资产-工商银行6699银存-贷95，负债-商户待结算-借95

至此，这一整个链路上的交易流程全部记账完成了。

这应该是账户中最隐晦生涩的部分。从我的交流情况看，很多同学不理解账户其实就是不明白这个环节。而其他的账户相关的内容，比如功能结构、账户类型在实际设计过程中还会有一些可见流程。

上面只是我基于一个场景给出来的账户记账全流程，得说明，任何一个细小的变化就会导致记账流程变化。

比如上面这个例子里，如果渠道手续费平台不自己出，需要商户出资。大家可以思考下，需要如何调整？

而且我并没有列举其他的场景，比如充值、转账、余额支付等。大家也可以思考下。

细心的同学可能已经发现，我上面举例的流程是有问题的，因为这个流程涉及到了二清。

平台触碰了商户资金，所以这个资金流对平台商户来说是不合规的。但不影响大家理解账户的流转过程。也是上文中那句话，结合平台的二清解决方案，记账科目和流转可能会有区别。

合规的流程的话，得替换上图中的银存账户，将真实的资金全部结算到存管银行或者支付公司，同时平台的账户体系按需求可以和底层存管方提供的账户体系映射。具体方案就不再这里展开了。

那我为什么还要举这个例子？

一是想表达不同机构角色，在账户的设计上是会有区别的，如果是持牌机构，这种记账方式就完全没问题。当然现在支付机构的银存已经集中到人行备付金了，没有所谓“银行存款”了。

二是这种方式有一个妙用。在断直连之前很普遍，或者在现在的跨境支付领域也很常见。原因就在于银存账户可以是多个，支付机构可自行决定从哪个账户给用户付款。具体的用处稍微展开讲下。

假设一个跨境支付公司，在美国和欧洲都同时开展收单业务。按照当地合规要求在当地存管银行都开通了存管账户。

一个美国的用户，购买了欧洲卖家的商品。美国用户支付之后，资金在收单机构美国存管账户，也就是支付公司的美国银存账户。

而卖家是欧洲的，如果欧洲卖家需要提现，正常逻辑上，支付公司需要将这笔资金付款到欧洲银存账户，然后在给到卖家的银行账户。

支付公司将资金从美国转到欧洲也是需要时间的，并且也有手续费成本。

但如果用上面的这种方式，时间和成本可以大幅缩短。原因是这家公司在欧洲同时也有收单业务，银存账户也同样有资金。可以直接从欧洲的银存账户出款给到欧洲卖家的银行卡。

这样既避免了资金调拨到欧洲的时间成本和手续费成本，还提升了商户的实际到账体验，只需要在记账时明确真实的出金账户是哪个就可以了。

不知道各位看到这里，对账户的流转过程理解的如何？我也确实没找到更好的书面表达方式，有点啰嗦，各位担待，也很感谢还能看到这里的同学。

主要想表达的还是，只要理解了上面的流转过程，再来看账户的那些概念、结构、功能，从我个人的角度，真的就非常容易代入了。

3.2账户模块的业务定位和需求分析

看完这个案例，也可以理解，我们为什么需要账户系统。

可以假想一下，没有账户系统会怎样？

以上面的案例继续展开，用户下单付款，资金从用户的银行卡直接扣除，并直接结算给了商家银行卡。看起来非常简单，但问题来了：

资金没法对账，是很明显的问题

另外如果商户要抽佣部分服务费，怎么扣

资金直接给到商户，平台怎么保证资金安全

货物消费者没收到，需要退款，怎么从商户银行卡退回

如果以后想发展用户余额支付，优惠券，红包，都不能支持

所以账户模块的核心作用，就是让资金流动可控、可追溯、可管理。

而具体需要哪些账户，则是业务模型的抽象。

比如电商平台需要商家结算，就有商户结算户

支付公司可以提供支付账户余额进行支付，就有用户余额账户

平台需要抽佣，就有内部收入户，

银行的资金需要管理，银存账户要显像化，就有了资金账户

平台要商户缴纳保证金，就有了保证金账户等等

所以，账户的本质，还是业务模型的抽象，账户并不是凭空设计出来的，而是业务需求的具像化。

3.3典型的账户通用设计思路拆解

第一步，明确每个单一账户基本结构。

每一个单一账户，同时也都是一个小实体，它记录着以下核心信息，这个基本是行业通用的，企业也都基本是相同设计。

账户归属人，用户ID、商户ID，及账户实名或认证信息，比如个人身份信息、企业统一社会信用代码等认证信息。

账户余额：账户中有多少资金

流水：每一笔资金进出的明细记录，流水就是我们在开头列举的流转过程的记录，就会和科目相关联

交易：资金怎么进出账户，就和交易模块的交易类型关联上了。

第二步：梳理业务场景和资金流，明确需要哪些账户类型和具体账户

账户类型是另一个必须要理解的概念。上文一番流程下来已经可以窥见到。常见的账户类型分类有：

商户账户：比如商户结算户，商户可以真实使用的账户，看到结算资金并提现

过渡户：比如商户的待结算账户，商户不可见，中间记账流转。也有的平台不按照商户区分待结算，而是使用统一的一个过渡户。个人建议分开，分开后资金归属更明确，不容易形成池子，导致后续资金混淆

内部账户：比如收入账户、费用账户、手续费账户等

例子中没有的用户账户，比如用户的余额钱包，红包账户等。

当然账户按照不同的维度，还可以继续分成不同的类型。比如：

业务账户：因业务场景需要使用的账户，比如保证金账户、加油账户、仓储账户。

资金账户：银存账户就是一类资金账户，用于记录真实银行资金。

所以账户的复杂性的另一面，就是要确认平台需要哪些账户类型，这个是完全和业务挂钩的。

同时千万别忘了和财务确认好每个账户的科目设计。

第三步，账户流转的规则引擎定义。

根据不同的场景，约定好账户需要如何流转记账。这是账户设计的核心。

这个环节的难点，在于需要联动周边的模块。驱动账户记账的来源有多个，可能是收单，也可能是清结算。

比如参考第一章节的例子，收单成功要怎么记账，商户抽佣要怎么记账，商户提现要怎么记账。

还记得之前那张支付中台的交易流程图吧，账户系统在这里才开始和上下游系统有交互。前期的那些工作和其他系统没关系。

<

记账规则比较通用的做法，是通过确定的产品码+交易码来匹配事先编排好的记账规则。比如交易码JY001-代表担保交易，产品码CP001-代表收单，那收单成功后，账户收到通知，获取交易码+产品码后，按照预设规则，会记账到渠道待结算和商户待结算。

第四步，也是最显化的部分，围绕账户的全生命周期管理功能，设计相应流程

账户的功能结构，前面已经提到过了，每一个账户都可以有充值、转账、提现、开户、销户、冻结、解冻的能力。但在不同的账户类型下，功能可能会有不同。

在这个环节，主要围绕账户的每个独立功能进行流程设计，需要明确很多的细节问题。以开户和销户为例。

比如开户：

需要明确开户的具体流程，在业务流程环节中怎么嵌入

开户需要满足的条件，需要提供哪些材料，是否强制个人实名或企业认证，是否需要外部渠道核验进行KYC

不同账户的开通流程区别，比如已经开通过结算户，在新开保证金账户，是否需要继续提供材料，或者进行KYC等

开通的不同账户默认的账户权限定义，功能定义。比如商户结算户不允许充值，保证金账户不允许提现等，内部户一般不需要冻结等

比如销户：

销户的流程是怎样的，商户需要如何提交销户申请

销户申请提交时，账户的状态要求，比如账户必须是可用状态，余额全部提现，不存在应缴未缴的欠款等

注销之后的生效时间和注销数据范围，比如立即生效还是10日后生效，所有数据删除还是部分删除等

其他需要注意的

账户最怕两个问题，账户超支和热点账户，前者可能会导致资损，后者会让数据库崩溃。需要和技术同学确认好技术方案。

前者需要做好账务核对，后者需要采用一些技术手段，比如先缓存后续批次处理，或者拆解事务先处理借记再处理贷记，或者使用哈希算法将账户分散多个子账户。

账户需要满足合规要求，支付机构账户/银行账户，按照央行规定的账户一二三类等级，有对应不同的外部渠道验证要求和限额要求。

3.4账户系统设计建议

咱们如果要设计账户体系，建议先不要着急画账户架构。按照上面的步骤先梳理一遍再开始不迟。

很多账户产品经理有个误区，在和开发同学比专业，专注于某个实现细节。我个人认为是没有必要，在具体实现上，开发同学肯定比产品更专业。

账户产品经理的核心工作是：

和业务对焦确认业务流程和资金流程

和财务确认资金流转和科目设计

和合规确认账户设计是否合规，有哪些开户条件和监管规则

直白点，我们要做的工作就是按照业务需求，明确需要哪些节点记账，记账到哪些账户，怎么核算科目，以及每个账户怎么开通关闭。

归根到底我们不需要和开发同学比专业，产品经理的首要职责是将这些业务规则转化为账户间的映射关系，我们要的是把这些业务理清楚给到开发同学实现，协同配合把账户建设好。

当然，这个梳理可能很复杂，账户设计有点像下围棋，规则其实很简单，但真正的艺术在于如何在这些简单规则下构建精妙的战略。简单的规则却可以有极其复杂的棋盘格局。

但是也不用担心，理清楚业务和资金流程是万能良药，剩下的就是和团队协作落地，咱们并不是要自己一个人从前到后干完所有。