以下文章来源于彬彬不倦，作者Weto0
本文将帮助大家彻底搞清楚什么是交易，如何设计收银台，怎么解决二清问题，有架构、有流程、有产品方案、有关键指标，非常全面
接下来，将从交易模块、收银台、二清方案三大模块帮助大家梳理清楚支付全链路的设计方法论，内容遵循产研实施过程的基本流程
每部分内容，将从模块定位、需求分析、方案设计等一步步拆解。读起来就像亲身经历参与了他们的设计一样。
01.交易系统
从业务需求到系统落地全维度解析
你有没有遇到过这样的问题？
公司业务模式一变或者新增其他的业务模式，交易模块就得大改？
为什么都是交易模块，电商的交易模块和支付系统的交易模块设计完全不同？
有的系统能轻松支持“购物车合单支付”，而有的连“拆单、退款”都做不好？
确实，在互联网行业，“交易”这个词被广泛使用，但不同业务场景下的“交易模块”有着天壤之别。
比如，我们在淘宝下单交易模块负责的是订单创建、库存锁定、商品优惠计算；而当我们用支付宝付款时，交易模块负责的却是支付路由、资金划拨、风控拦截。
那么问题来了：为什么不同业务模式下的交易模块设计差异如此之大？
答案很简单：因为业务模式不同，决定了交易的本质不同。
电商交易关注的是商品与订单的流转，核心是商品流通，所以交易模块要解决的是订单履约问题；
而支付系统交易关注的是资金的流转，核心是资金流通，所以交易模块要解决的是支付成功率、资金安全、交易对账的问题
一个是"物"的交易，一个是"钱"的交易，自然设计思路迥异。
1.1.支付系统交易模块的业务定位和需求分析
不管是何种交易，交易模块的核心目标是类似的：在业务场景中，安全高效地完成业务过程的流转。
但不同业务场景对交易的需求不尽相同，开篇有提到，这里在展开下：
电商交易：主要是为了订单履约（库存、商品优惠、物流），比如淘宝购物下单；
支付交易：主要是为了资金处理（支付、退款、结算），比如支付宝支付下支付单，
金融交易：主要是为了资产划转（计息、资金核对、账户变动），比如基金申购赎回。
所以，对于不同的业务类型，交易的核心载体也不相同：
电商的交易模块，核心是订单；
支付的交易模块，核心是支付指令；
金融的交易模块，核心是资金账户处理。
一句话总结：交易模块本质上是业务模式的抽象。
本文主要探讨支付系统的交易模块的设计方法，所以后续的交易都针对支付系统的交易模块展开。
可以想象一下，如果支付系统没有交易模块，支付系统会是什么样？
用户发起支付请求后，直接调用银行或支付公司接口完成扣款。
看起来简单直接，其实有非常多的问题没法解决，比如：
支付过程中断怎么办？
如果需要对同一笔资金进行多次处理怎么办？
需要支持复杂的支付组合怎么办？
需要记录完整的资金流转轨迹怎么办？
这些都是交易模块解决的问题，所以交易模块存在的意义：它是支付系统链接业务系统和底层支付渠道的入口和“转换层”；
支付系统交易模块的核心作用，我个人认为有以下4个：
记录交易行为：比如谁付钱？付给谁？付多少？状态如何？
管理资金流动：比如钱怎么进、怎么出、怎么冻结、怎么结算？
支持业务扩展：比如能否支持合单？能否拆单、退款？能否适应新业务？
封装统一能力和服务：比如能否一套接口对接所有支付渠道？能否适配各种支付产品的不同差异？
我们可以把支付系统交易模块的核心定位基本概括为：
通过统一的接口，整合多维度的支付渠道和支付产品，链接业务需求和资金流转，并保证全链路的一致性、安全性和高可用性。
所以交易模块是支付系统中最复杂的核心模块之一。
1.2.支付系统交易模块的结构和设计
我们还是拿之前文章中典型的支付中台的交易流程做开始，窥见交易模块在整个支付系统的位置，窥全貌见细节。
支付系统各模块交互流程
从图上我们可以看到，交易系统是业务系统请求处理的先锋，业务系统需要按照标准接口，将支付请求给到交易系统，交易系统会落单，并将请求转发到关联模块处理。
这个当然还不能解释交易系统需要如何设计，还需要引申出交易模块中的两个核心概念：交易类型、交易模式。
上文提到交易模块是业务模式的抽象，核心就是通过这两个概念的组合完成通用的处理。
交易类型，主要针对资金流动方向的角度而言，可以简单理解成主要是从付款方角度看到的资金处理，主要包括：
支付：定义为付款方扣款，
退款：将资金退还给付款方
转账：将资金从A转给B
充值：将自己的资金从银行卡转移到记账账户
提现：从账户将资金划转到自己的银行卡
代付：将资金付给别人的银行卡
当然基于实际的支付业务，还有其他一些类型，可能不涉及资金变动，但也是要处理的交易，比如签约，银行卡绑卡进行四要素签约，也可以是一种交易类型。
交易模式，是针对“支付”这个交易类型的行为方式。淘宝首创的担保交易，就是针对电商行业开创的非常了不起的一种交易模式。这个可以简单理解成主要是从收款方角度看到的资金处理，常见的交易模式有：
即时到账：用户支付后，资金直接给到商家
担保交易：用户支付后，资金先要放在担保账户，等确认收货后才给到商家
预授权交易：用户确认后，资金是先做冻结，后续才真实扣款
订金模式：用户先支付部分订金，业务结束再收取后续尾款
不同的交易模式代表着用户支付成功之后的资金处理流程不同，会影响后续的清结算和账务处理。
我们拿典型的电商担保交易举例看下整体处理流程
担保交易流程
交易收到业务系统请求，给到后续系统执行支付扣款
扣款成功后，因为是担保交易，支付系统先行记账到担保账户或者商家待结算账户（根据平台账户体系可能有区别）
用户确认收货，交易将订单给到清结算
清结算清分商户应结算金额及平台分润等各类费项，将资金分账到对应账户
如果是即时到账，那用户支付完成之后，收单记账完成会直接给到清结算，清分完成即时就给到了商户账户。
交易模块这两个概念确定之后，后续的大部分业务场景基本在类型和模式上进行扩展就可以满足。
正向的下单、支付；
逆向的关单、退款；
相应的查询服务
需说明，交易模块是一个大模块，本身其实也是可以分层的，一般典型的会分成两层：
一笔交易单可能有多笔支付单，同样的一笔支付单也可能有多笔渠道单
下面咱们挑两个典型的交易场景，模拟下方案扩展
第一个典型的场景是电商业务的购物车。
购物车场景下，一笔业务订单包含了多个不同商户的商品，这就意味着在给商户进行记账和结算时，需要按照商户维度分别清分结算，但用户希望可以一笔就完成支付。这要求交易模块具备合单支付的能力。
合单支付还是交易类型的一个扩充，在普通的支付类型之外，新增合单支付的场景。
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.二清
二清的渊源及解决方案
二清的概念前文已经有所介绍，主要存在两种场景，资金二清和信息二清，主要的判断标准还是看平台对资金是否具有控制权。二清的问题处理不好，会有诸多影响。
对平台而言，支付机构暂停结算、监管通报、对平台的舆论发酵影响平台商户入驻等都会切实影响商户业务发展。
对商户和消费者而言，权益无法保障，面临资金风险，严重情况消费者接收不到货物，商家无法拿到货款，所以消费者和和商户也会审慎选择平台。如此恶性循环。
那为什么会产生二清？
针对二清，平台需要做什么才能避免实质性的二清行为？
我们继续聊。
3.1.平台商户为什么存在二清问题？
为什么针对平台商户容易有二清问题，之前的商家在交易过程中就不存在或者没有这么明显呢，其实逻辑非常浅显。
过往的交易中，一般都是面对面的，货比三家讨价还价，最终进入交易阶段，一手交钱一手交货，钱货当面两清，所以基本不存在事后需要进行结算的问题。
当电商平台的业务模式出现后，钱货的时效性处理是不一样的，用户支付完成，资金已经付出，但货物从商户侧通过物流寄送到达签收需要时间，平台采用“担保交易”模式是平台保证用户交易安全的一种方式，但资金的停留造成了事实上的资金留存。这是业务模式导致的原因。
业务流程简图
第二个原因是账期，平台和供应商之间的结算，有多种模式，用户收到货之后也不一定是立马给商户结算，可能按照约定账期，比如按月结算一次，平台也会存在资金滞留。当然这一点平台和商户是有冲突的，商户希望尽快收到货款，平台希望尽量多周期留存。
伴随着电商业务越来越复杂，一笔交易的参与方越来越多，代理、主播、平台、商户、营销、资方等，一笔交易涉及到多方的结算，资金需要经过复杂的清分计算，也造成了平台不得不进行实际上的清结算处理。
当然在商户角度，另外不得不提的一点是，二清模式下，对商户有极大的利益诱惑：
平台产生资金留存后，可以产生沉淀利息或理财收益
大量的平台交易除了产生资金沉淀，继而可以以此为筹码和银行/三方进行通道手续费、技术服务费等费用支出的谈判。降低平台整体成本。
3.2.解决方案参考
知道产生的原因并不是为了给平台类商户找借口，而是针对业务情况寻找解决方案。针对大部分商户，个人结合过往工作经验和实际看到的诸多案例，建议采用直付通+收付通+银行存管方案并行的处理方式。附上资金流程以便理解。
三种二清解决方案并行资金流程
采用这种方式的原因：
当然，以上纯属个人观点，不是什么标准答案，平台还是需要根据实际情况来。
另外有同学问到前文提到的银行和三方打通的方案，没有特别理解，所以也附上该方案的资金流程。
三方和银行信息流/资金流互通的资金流程
这种模式下，收单机构只承担收单职责，资金按照二级商户维度100%全部结算给存管行，存管行T+1核对资金流和信息流无误后，清算到二级商户在存管行的待结算账户，后续再按照平台的交易指令，以订单为基础维度进行逐笔订单的补差/抽佣，完成商户最终结算。
该方案从合规角度看基本是比较完美的，但基本一户一议，需要提前和三方/银行/当地监管沟通，确认实际执行才能落地。中间的沟通成本/业务成本/多方的共同开发成本都还是比较高的，所以应该只有少数非持牌的大平台有使用这种方式。当然受限于个人信息界面，不一定完尽。
3.3.之前一个真实案例分享
微信/支付宝在实际生活中支付占比最高，直付通/收付通的合规也确实无可挑剔，所以保证平台大部分资金处于完全合规的状态是最稳妥的
微信/支付宝针对平台型商户有相应政策，避免后续被监管到，还需要系统改造
其他支付方式的收单可以使用银行的方案，市面上相似方案还很多（感觉这是个很好的软文广告位，比如附上某产品介绍，哈哈），三方也有很多，但建议优先银行的方案。这种方式可以兼顾平台消费分期/白条等金融业务的开展，优先银行而不是其他三方，主要是考虑在微信/支付宝/三方体系内和资方资金体系打通比较困难，但和银行可以根据平台情况实际商讨针对资方放款的资金链路如何走通，避免业务受限。
劣势在于银行的方案可能有一定信息二清的嫌疑，但资金量在平台占比一般不会很高，风险可控，对监管也可以解释。
这是之前实际工作中的一个案例，和以上方案的基本逻辑是一致的，但会多出更多细节，有些内容已经老旧，不符合目前实际情况，细节就不展开了，供大家参考，附案例图。
核心内容分成两张图：一张是整体的交易流程，一张是资金流程。
交易结构和流程
资金流程
案例整体采用的都是银行存管的模式，当然银行的模式也不是一成不变的，也随着业务情况一直在迭代。如图中所示，还是之前比较老的大商户存管模式，目前已经并不合时宜，但图本身不重要，核心还是逻辑和思路，有所启发就有价值。
继续那个追问，你们平台是如何解决二清问题的呢？欢迎留言讨论。
最后强烈推荐大家关注彬彬不倦，他是专注互联网支付领域近10年的产品人，在支付公司、垂类头部平台、一线大厂等公司任职支付产品经理/产品专家多年，经历过多个产品和项目
