支付系统整体架构

http://doc.cocolian.cn/essay/payment/2016/08/08/payment-arch/
作者：凤凰牌老熊

修改记录：
2016-08-08 初稿，列举了现有主流公司的支付架构；
2017-03-04 补充支付系统架构的overview.

支付的典型架构

每个公司根据其业务和公司发展的不同阶段，所设计的支付系统也会有所不同。我们先看看互联网公司的一些典型的支付系统架构。
支付宝
先看看业内最强的支付宝系统，支付宝的支付系统整体架构设计

这个整体架构上并没有与众不同之处。在模块划分上，这个图显示的是最顶层的划分，也无法告知更多细节。 但支付宝架构文档有两个搞支付平台设计的人必须仔细揣摩的要点。 一个是账务处理。在记账方面，涉及到内外两个子系统，外部子系统是单边账，满足线上性能需求；内部子系统走复式记账，满足财务需求。在清结算这个章节中也是基于这个模型来详细介绍如何记账、对账和平账。

另一个亮点是柔性事务处理，利用消息机制来实现跨系统的事务处理，避免数据库锁导致的性能问题。
京东金融
来自京东支付平台总体架构设计 。京东金融是在网银在线的基础上发展起来的。 网银在线的原班技术人员有不少来自易宝公司，在京东收购之后，又引入了支付宝的人才。因而从架构上受这两个公司的影响很大。
去哪儿
来自去哪儿公司分享的支付产品架构
美团
来自美团的支付平台规划架构 。这是2015年的文档。 2016年美团才拿到支付牌照。 从这个架构，大家也能知道为什么美团必须拿到支付牌照。
这些架构文档全部来自互联网公开资料。 对于架构是否真实反映实际系统情况，需要大家自行判断。 我们以这些文档为基础，分析支付系统的应有的软件架构。

参考架构

一般来说，支付系统典型架构会包含如下模块：

支付系统从架构上来说，分为三层;

1. 支撑层： 用来支持核心系统的基础软件包和基础设施， 包括运维监控系统、日志分析系统等。
2. 核心层： 支付系统的核心模块，内部又分为两个部分： 支付核心模块以及支付服务模块。

3. 产品层： 通过核心层提供的服务组合起来，对最终用户、商户、运营管理人员提供的系统。

   支付基础设施

   支撑系统是一个公司提供给支付系统运行的基础设施。 主要包括如下子系统：

4. 运维监控： 支付系统在下运行过程中不可避免的会受到各种内部和外部的干扰，光纤被挖断、黑客攻击、数据库被误删、上线系统中有bug等等，运维人员必须在第一时间内对这些意外事件作出响应，又不能够一天24小时盯着。这就需要一个运维监控系统来协助完成。

5. 日志分析： 日志是支付系统统计分析、运维监控的重要依据。公司需要提供基础设施来支持日志统一收集和分析。
6. 短信平台： 短信在支付系统中有重要作用： 身份验证、安全登录、找回密码、以及报警监控，都需要短信的支持。
7. 安全机制： 安全是支付的生命线。 SSL、证书系统、防刷接口等，都是支付的必要设施。
8. 统计报表： 支付数据的可视化展示，是公司进行决策的基础。

远程连接管理、分布式计算、消息机制、全文检索、文件传输、数据存储、机器学习等，都是构建大型系统所必须的基础软件，这里不再一一详细介绍。

支付核心系统

支付核心系统指用户执行支付的核心流程，包括：

1. 用户从支付应用启动支付流程。
2. 支付应用根据应用和用户选择的支付工具来调用对应的支付产品来执行支付。
3. 支付路由根据支付工具、渠道费率、接口稳定性等因素选择合适的支付渠道来落地支付。

4. 支付渠道调用银行、第三方支付等渠道提供的接口来执行支付操作，最终落地资金转移。

   支付服务系统

   支持支付核心系统所提供的功能。服务系统又分为基础服务系统、资金系统、风控和信用系统。
   基础服务系统提供支撑线上支付系统运行的基础业务功能：

5. 客户信息管理：包括对用户、商户的实名身份、基本信息、协议的管理；

6. 卡券管理： 对优惠券、代金券、折扣券的制作、发放、使用流程的管理；
7. 支付通道管理: 通道接口、配置参数、费用、限额以及QOS的管理；
8. 账户和账务系统： 管理账户信息以及交易流水、记账凭证等。这里的账务一般指对接线上系统的账务，采用单边账的记账方式。 内部账记录在会计核算系统中。
9. 订单系统： 一般订单系统可以独立于业务系统来实现的。这里的订单，主要指支付订单。

资金系统指围绕财务会计而产生的后台资金核实、调度和管理的系统，包括：

1. 会计核算： 提供会计科目、内部账务、试算平衡、日切、流水登记、核算和归档的功能。
2. 资金管理： 管理公司在各个支付渠道的头寸，在余额不足时进行打款。 对第三方支付公司，还需要对备付金进行管理。
3. 清算分润： 对于有分润需求的业务，还需要提供清分清算、对账处理和计费分润功能。

风控系统是支付系统必备的基础功能，所有的支付行为必须做风险评估并采取对应的措施；信用系统是在风控基础上发展的高级功能，京东的白条，蚂蚁花呗等，都是成功的案例。

支付应用

支撑系统、核心系统和服务系统，在每个公司的架构上应该是大同小异的，都是必不可少的模块。而支付应用是每个公司根据自己的业务来构建的，各不相同。 总的来说，可以按照使用对象分为针对最终用户的应用、针对商户的应用、针对运营人员的运营管理、BI和风控后台。

总结

这一章节简单描述支付系统的整体架构。后续我们将以此为基础，分别介绍各个模块的设计。

支付系统

来源：https://mp.weixin.qq.com/s/gK4fy0dL4pp1fmIfmhMnRA

支付系统

概述
支付系统是连接消费者、商家（或平台）和金融机构的桥梁，管理支付数据，调用第三方支付平台接口，记录支付信息（对应订单号，支付金额等），金额对账等功能，根据不同公司对于支付业务的定位不同大概有几个阶段：第一阶段：支付作为一个（封闭）的、独立的应用系统，为各系统提供支付功能支持。一般来说，这个系统仅限于为公司内部的业务提供支付支持，并且和业务紧密耦合。第二阶段：支付作为一个开发的系统，为公司内外部系统、各种业务提供支付服务，支付服务本身应该是和具体的业务解耦合。

支付是电商系统中核心

我们先来看一下用户完成一次购物需要进行那些操作：

通常消费者在手机APP或者网站都会涉及到支付相关的业务场景，用户只需要简单点击支付按钮输入支付密码，就可以完成整个支付过程，那么我就和大家一起来看看一个完整的支付系统有什么功能组成和设计时需要考虑那些问题。

01
支付系统的作用

从上图中我们可以看出真实的资金流向。首先当用户产生支付行为时，资金从用户端流向支付系统，退款时则相反，从支付系统回流至用户端。因此在整个交易过程中用户端与支付系统是双向资金的流动方式。对于支付系统而言，资金有进有出。从支付系统到商户端就比较简单了，在清算完成后支付系统负责将代收的资金结算给商户，通常结算的操作可以在线上来完成（采用支付公司代付接口或者银企直连接口来完成），也可以由公司财务通过线下手工转账的方式来完成，因此这种资金流动的方式是单向的。出于资金安全考虑，大多数公司通常这部分采用线下方式实现。
真实的资金流由支付公司按照约定期限（通常 T+1 ）结算到平台公司对公账户中，然后再由平台公司再按照交易明细进行二次清算后结算给对应的商户。

支付系统
一个支付系统需要由哪些功能模块组成

01
完整的支付系统包括如下功能：

1. 应用管理: 同时支持公司多个业务系统对接。
2. 商户管理: 支持商户入驻，商户需要向平台方提供相关的资料备案。
3. 渠道管理: 支持微信、支付宝、银联、京东支付等多种渠道。
4. 账户管理: 渠道账户管理，支持共享账户（个人商户）及自有账户。
5. 支付交易: 生成预支付订单、提供退款服务。
6. 对账管理: 实现支付系统的交易数据与第三方支付渠道交易明细的自动核对（通常T+1），确保交易数据的准确性和一致性。
7. 清算管理: 计算收款交易中商户的应收与支付系统收益。
8. 结算管理: 根据清算结果，将资金划拨至商户对应的资金帐户中。

02
核心流程
支付系统有几个关键的核心流程：支付流程、对账流程、结算流程

支付流程

支付流程说明

1. 用户在商城选购商品并发起支付请求；
2. 商城将支付订单通过B2C网关收款接口传送至支付网关；
3. 用户选择网银支付及银行，支付平台将订单转送至指定银行网关界面；
4. 用户支付完成，银行处理结果并向平台返回处理结果；
5. 支付平台接收处理结果，落地处理并向商户返回结果；
6. 商城接收到支付公司返回结果，落地处理（更改订单状态）并通知用户。

一般而言支付系统会给商户设置有“可用余额”账户、“待结算”账户；系统在接收到银行返回支付成功信息会进行落地处理，一方面更改对应订单状态，另一方面在商户待结算账户记入一笔金额；该笔金额，系统会根据结算周期从待结算账户—->“可用余额”账户。
退款流程说明

1. 用户在商户平台发起退款申请，商户核实退款信息及申请；
2. 商户登录支付平台账户/或者通过支付公司提供的退款接口向支付平台发起退款；
3. 支付系统会对退款信息校验（退款订单对应的原订单是否支付成功？退款金额是否少于等于原订单金额？），校验商户账户余额是否充足等；校验不通过，则无法退款；
4. 支付系统在商户可用余额账户扣除金额，并将退款订单发送至银行，银行完成退款操作。注意：对于网关收款的订单退款，各银行要求不一，有些银行提供的退款接口要求原订单有效期在90或180天，有些银行不提供退款接口；针对超期或者不支持接口退款的订单，支付公司通过代付通道完成退款操作。

对于收单金额未结算，还在“待结算”账户的订单，如果出现退款情况，业务流程和上述流程差不多，只是从待结算账户进行扣款。

对账流程

说明
对账，我们一般称为勾兑，支付系统的对账，包含着两个层面：

1. 支付系统内部间的对账，支付系统一般是分布式的，整个支付系统被拆分成了多个子系统，如交易系统、账户系统、会计系统、账户系统，每个子系统在处理各自的业务，系统间的对账，就是以上系统的核对，用于修正内部系统的数据不一致。
2. 支付系统与渠道的对账，这里的渠道泛指所有为支付系统提供代收付业务的渠道，如：第三方支付公司、银行、清算中心、网联、银联等。

支付系统与渠道间的对账
系统间的对账比较好理解，这里主要讲支付系统与渠道间的对账。支付系统与渠道间的对账，又包含2个维度：

1. 信息流勾对：即业务对账／交易对账，主要是就收单交易的支付信息与银行提供的信息流文件进行勾兑。信息流的勾地能发现支付系统与银行系统间的掉单、两边由于系统间的原因导致的同一笔交易支付金额不一致（可能性很小）或者支付状态不一致。信息流勾兑一般用来恢复掉单数据，可通过补单或者具体系统问题排查解决。
2. 资金流勾对：即资金对账，主要就收单交易的支付信息与银行提供的资金流信息进行勾兑。资金流的勾兑能发现支付系统在银行的帐户资金实际发生的变动与应该发生的变动的差异，比如长款（银行多结算给支付系统）和短款（银行少结算给支付系统）。

说了这么多，就出现来4个对账文件，支付系统信息流文件、支付系统资金流文件、银行信息流文件、银行资金流文件。业务对账（勾兑）就是支付系统的信息流文件与银行的信息流文件勾兑，资金对账即支付系统的资金流文件与银行的资金流文件勾兑。

核对的差异处理
1、信息流勾对的差异处理

• 支付系统信息流没有，而银行有的差异，可能是因为支付系统交易数据的丢失、银行的掉单，如果是银行的掉单，由支付公司的运营登录银行网银确认后，做补单处理，并将差异表中该记录核销。
• 支付系统信息流有，而银行没有的差异，此种情况一般不会发生，因为支付系统所有的交易数据都是取银行返回状态的数据。

2、资金流勾对对差异处理

• 支付系统资金流没有，而银行有的差异。可能原因如下：1、银行日切晚与支付系统核心账务系统；2、支付系统账务核心系统与其他系统间的掉单。一旦出现，则会出现长款（即银行不应该结算而实际结算）的现象，对于因日切导致的差异，在第二天的对账中系统会对平，其他原因的，需要技术排查。
• 支付系统资金流有，而银行没有的差异，可能是因为银行日切早于支付系统的核心账务系统，一旦出现，会出现短款（银行应结算而实际未结算）的现象，银行日切导致段差异，会在下一天与银行的勾对中，将此笔差异勾对上，如果是非日切导致的原因，就需要找银行追款了。

总结就是，业务对账，即信息流对账，支付系统的交易流水与银行的交易流水间核对，保障支付交易完整入账。资金对账，即资金流对账，支付系统的入账流水与银行的结算流水间核对，保障银行入账流水与实际入账资金的匹配。

结算流程

在清结算部分，系统按照设定好的清结算规则自动将钱款结算给商户。完善的运营会计体系帮助财务进行精细化核算，提高财务效率。与支付渠道自动进行对账，确保账务正确，在异常情况下能及时定位问题并处理。系统更是能对商户进行个性化的费率配置或账期配置，方便灵活。系统的价值不仅体现在支付清结算方面，同时更是提升了运营管理效率。支付清结算系统可以有效帮助运营、财务、开发以及管理人员。对于运营人员，系统可帮助处理平台的运营工作，包括各类支付管理，商户、会员管理，营销活动的数据统计等，全面提高运营效率。针对财务人员，可以协助完成资金对账、会计处理，出入款管理，账务差错处理等，大部分工作由系统自动处理，减少人工处理，提高资金处理效率。一套灵活便捷的配置后台供开发人员快速调整系统以适应新的业务，并能方便对系统进行维护，如渠道接入、费率配置、账期调整等，提高开发效率。系统提供资金流转过程中各个环节的数据，能够从各个维度进行核算和分析，形成对管理人员的决策支持，从而提高决策效率。
03
关键表设计

04
支付系统要点
在支付系统中，支付网关和支付渠道的对接是最繁琐重要的功能之一，其中支付网关是对外提供服务的接口，所有需要渠道支持的资金操作都需要通过网关分发到对应的渠道模块上。一旦定型，后续就很少，也很难调整。而支付渠道模块是接收网关的请求，调用渠道接口执行真正的资金操作。每个渠道的接口，传输方式都不尽相同，所以在这里，支付网关相对于支付渠道模块的作用，类似设计模式中的wrapper，封装各个渠道的差异，对网关呈现统一的接口。而网关的功能是为业务提供通用接口，一些和渠道交互的公共操作，也会放置到网关中。
支付系统对其他系统，特别是交易系统，提供的支付服务包括签约，支付，退款，充值，转帐，解约等。有些地方还会额外提供签约并支付的接口，用于支持在支付过程中绑卡。 每个服务实现的流程也是基本类似，包括下单，取消订单，退单，查单等操作。每个操作实现，都包括参数校验，支付路由，生成订单，风险评估，调用渠道服务，更新订单和发送消息这7步，对于一些比较复杂的渠道服务，还会涉及到异步同通知处理的步骤。
01
网关前置
支付网关前置是对接业务系统，为其提供支付服务的模块。它是所有支付服务接口的集成前置，将不同支付渠道提供的接口通过统一的方式呈现给业务方。这样接入方就只需要对接支付网关，增加和调整支付渠道对业务方是透明的。 支付网关前置的设计对整个支付系统的稳定性、功能、性能以及其他非功能性需求有着直接的影响。
在支付网关中需要完成大量的操作，为了保证性能，这些操作都尽量异步化来处理。支付网关前置应保持稳定，尽量减少系统重启等操作对业务方的影响。支付网关也避免不了升级和重启。这可通过基于Nginx的LBS(Load Balance System)网关来解决。LBS在这里有两个作用： 一个是实现负载均衡，一个是隔离支付网关重启对调用的影响。 支付网关也采用多台机器分布式部署，重启时，每个服务器逐个启动。某台服务器重启时，首先从LBS系统中取消注册，重启完成后，再重新注册到LBS上。这个过程对调用方是无感知的。
为了避免接口受攻击，在安全上，还得要求业务方通过HTTPS来访问接口，并提供防篡改机制。防篡改则通过接口参数签名来处理。现在主流的签名是对接口参数按照参数名称排序后，做加密和散列，参考微信的签名规范。
02
参数校验

• 所有的支付操作，都需要对输入执行参数校验，避免接口受到攻击。
• 验证输入参数中各字段的有效性验证，比如用户ID,商户ID,价格，返回地址等参数。
• 验证账户状态。交易主体、交易对手等账户的状态是处于可交易的状态。
• 验证订单：如果涉及到预单，还需要验证订单号的有效性，订单状态是未支付。为了避免用户缓存某个URL地址，还需要校验下单时间和支付时间是否超过预定的间隔。
• 验证签名。签名也是为了防止支付接口被伪造。 一般签名是使用分发给商户的key来对输入参数拼接成的字符串做MD5 Hash或者RSA加密，然后作为一个参数随其他参数一起提交到服务器端。

03
路由选择
根据用户选择的支付方式确定用来完成该操作的合适的支付渠道。用户指定的支付方式不一定是最终的执行支付的渠道。比如用户选择通过工行信用卡来执行支付，但是我们没有实现和工行的对接，而是可以通过第三方支付，比如支付宝、微信支付、易宝支付，或者银联来完成。那如何选择合适的支付渠道，就通过支付路由来实现。支付路由会综合考虑收费、渠道的可用性等因素来选择最优方案
04
风险评估
检查本次交易是否有风险。风控接口返回三种结果：阻断交易、增强验证和放行交易。

• 阻断交易，说明该交易是高风险的，需要终止，不执行第5个步骤；
• 增强验证，说明该交易有一定的风险，需要确认下是不是用户本人在操作。这可以通过发送短信验证码或者其他可以验证用户身份的方式来做校验，验证通过后，可以继续执行该交易。
• 放行交易，即本次交易是安全的，可以继续往下走。

05
发送消息
通过消息来通知相关系统关于订单的变更。风控，信用BI等，都需要依赖这数据做准实时计算。
06
更新订单
对于同步返回的结果，需要在主线程中更新订单的状态，标记是支付成功还是失败。对于异步返回的渠道，需要在异步程序中处理。
07
异步通知
其中涉及到调用远程接口，其延迟不可控。如果调用方一直阻塞等待，很容易超时。引入异步通知机制，可以让调用方在主线程中尽快返回，通过异步线程来得到支付结果。对于通过异步来获取支付结果的渠道接口，也需要对应的在异步通知中将结果返回给调用方。 异步通知需要调用方提供一个回调地址，一般以http或者https的方式。这就有技术风险，如果调用失败，还需要重试。而重试不能过于频繁，需要逐步拉大每一次重试的时间间隔。 在异步处理程序中，订单根据处理结果变更状态后，也要发消息通知相关系统。
08
生成交易订单
将订单信息持久化到数据库中。当访问压力大的时候，数据库写入会成为一个瓶颈。
09
交易流水和记账
每一笔交易都需要记录流水，并登记到个人和机构的分户账户上，统计和分析也需要根据交易流水来更新相关数据。 而个人和机构账户总额更新、交易流水记录以及库存的处理，更是需要事务处理机制的支持。 从性能角度， 可以弱化了事务处理的要求，采用消息机制来异步化和交易相关的数据处理。

• 在支付网关前置的主流程中，仅记录交易流水，即将当前的请求保存到数据库中。
• 完成数据记录后，发送MQ出来，记账、统计、分析，都是接收MQ来完成数据处理。
• 涉及到本地资金支付，比如钱包支付，会需要分布式事务处理，扣减账号余额，记账，扣减库存等，每个操作失败，都要回滚。阿里有很不错的分享，这里不详细描述。
• 当交易量上来后，需要考虑交易表的分表分库的事情。分表分库有两个策略，按照流水号或者交易主体id来走。后者可以支持按用户来获取交易记录。我们用的是前者。后者可以走elastic，确保数据库专用。风控，信用和统计所需要的数据，通过MQ同步到历史库里面。作为支付系统最有价值的数据，在存储上做到专库专用，无可厚非，毕竟存储成本还是廉价的。

10
支付路由
支付路由是一个复杂的话题。对支付系统来说，能支持的支付方式越多越好，不能由于支付方式的不支持断了财路。现实中的支付方式多得难以置信。用户随时甩出一张你听都没听说过的卡。如果一个银行卡只有几个用户在用，那针对这个卡开发个对接有点得不尝失。现在第三方支付的爆发，确实给开发支付系统省了不少事。但是公司不可能只对接一个第三方支付，如果这个渠道出问题了，或者闹矛盾了，把链接给掐了，老板还不欲哭无泪。总之，得对接多个渠道。对于交易量大的银行，还得考虑直联。
11
渠道接入
对于支付渠道，首先考虑的是接入哪些渠道。要对接的渠道按优先级有：

• 第三方支付，对大部分应用来说，支付宝和微信支付都是必须的，一般来说，这两者可以占到90%以上的交易量。用户不需要绑卡，授权后直接支付就行。各种平台都支持，性能和稳定性都不错。对于一些特殊业务，比如游戏，企业支付，可以查看一些专用的第三方支付平台。
• 银联，它的存在，极大方便了和银行的对接。和第三方支付主要不同在两个地方一是需要绑卡，也就是用户先把卡号，手机，身份证号提供出来。这一步会折损不少用户。绑卡后，以后的支付操作就简单了，用户只需要输入密码就行。手机客户端不需要像第三方支付那样安装SDK，都在服务器端完成。当然，这是针对快捷支付。网银支付还是挺麻烦的。银联接入也需要ADSS认证。
• 银行：2018年2月9日银监会公布了最新权威数字：一共【4549家】开发性金融机构1家：国家开发银行；政策性银行2家：进出口银行、农业发展银行；5大国有银行：工、建、农、中、交；邮储银行1家；全国性股份制商业银行12家：招行、中信、兴业、民生、浦发、光大、广发、华夏、平安、浙商、渤海、恒丰；金融资产管理公司4家：信达、华融、长城、东方四大AMC；城商行134家；住房储蓄银行1家；民营银行17家，如网商银行；农商行1262家；农村合作银行33家；农村信用社965家；村镇银行1562家；贷款公司13家；农村资金互助社48家；外资法人银行39家；信托公司68家；金融租赁公司69家；企业集团财务公司247家；汽车金融公司25家；消费金融公司22家；货币经纪公司5家；其他金融机构14家。一般对接一个银行预计有3周左右的工作量，大部分银行需要专线接入，费用和带宽有关，一年也得几万费用。不同银行对接入环境有不同要求，这也是成本。
• 手机支付：比如苹果的In-App支付， 三星支付、华为支付等， 这些支付仅针对特定的手机型号， 支持NFC等，根据业务需要也可以接入。

总结
支付系统是一个繁杂的系统，其中涉及了各种错综复杂的业务流程，以上只是简单介绍了支付系统我们能看见的一些问题和设计，还有后续的系统保障没有写出来，没写出来的才是关键部分，比如：支付系统监控（业务监控分类、渠道监控、商户监控、账户监控）文章只是引子， 架构不是静态的，而是动态演化的。只有能够不断应对环境变化的系统，才是有生命力的系统。所以即使你掌握了以上所有的业务细节，仍然需要演化式思维，在设计的同时，借助反馈和进化的力量推动架构的持续演进。

电商系统：记账设计之订单管理、流水管理

作者 @侠之大者

原文链接：http://www.woshipm.com/pd/2737301.html

推荐人：冰雨幻天

本文所描述的记账，非企业ERP等专业财务软件记账场景。适用于公司自研以及采购的类电商系统后台记账设计。在电商场景下，涉及订单管理、交易流水、资金流水等多种不同口径的管理需求。

平台型电商记账特色

常见平台型电商如淘宝、拼多多、美团，京东、亚马逊也有一部分业务为平台型。所谓平台型电商就是搭建一个电子商城，引商家入驻。平台主要起着撮合交易的角色。常见模式如下图：

平台型电商的这种业务模式也决定了其必须要适应不同商户角色的不同需求。

• 运营关注订单流水（订单支付成功与否）
• 店主关注交易流水（收入多少，支出多少）
• 财务关注资金流水（实付金额、手续费等）

三者概念模型关系如下：
（三者都可以加上支付渠道属性）

订单流水

常见支付订单有如下几种状态：待支付、支付失败、支付成功、部分退款、已退款、已撤销。

• 待支付：下单成功，唤起支付后，尚未完成支付。
• 支付失败：密码错误或者余额不足引起的渠道扣款失败。
• 支付成功：扣款成功
• 部分退款：发起退款，但没有退全款。
• 已退款：退全款

• 已撤销：传统POS系统中，指的是交易撤销，退全款；线上交易，指使预支付失效。

  订单状态流转关系

  
  业务含义：以客户与商户之间达成交易的状态为核心，表达交易是否完成。
  生成条件：和业务订单发起支付同步生成。

  案例

• A商户订单支付成功，无分账。

• B商户交易分账，分账接收方分别为C、D。
• E商户的订单已经退款。

交易流水

店铺的经营情况的主要指标。交易流水不关心卖了什么，只关注各个商户收了多少钱，退了多少款。交易流水不关注订单的状态和订单的交易时间，只关注交易的类型和时间。
交易流水类型为：

• ‘1’：支付
• ‘2’：退款

（不计算费率因素）
业务含义：商户经营情况。
生成条件：以订单结算商户为核心，参考支付订单、分账订单、退款订单、撤销订单为触发条件。

案例

根据上述“订单流水”的例子，可生成如下交易流水信息。

• B商户虽然有订单，但是因为其分账给C、D，所有其无交易流水。
• C、D商户参与B订单的分账，所有C、D商户各有一条交易流水。
• E商户的订单支付成功后，又退款成功，所以涉及两条交易流水。（如果是部分退款，就会关联多条退款流水）

资金流水

资金流水是我们财务意义上真正的“记账”。
资金流水要在交易流水的基础上考虑费率的因素。在每个结算周期结束时，根据资金流水来计算应结算金额。以目前支付行业相关规定，支付成功的订单在1年以内都可以操作退款。且渠道会退回手续费。我们以常见费率0.6% 为例，请看案例：
（注：应结算金额=收入-支出）

案例

• A商户加上费率因素，涉及两条资金流水；
• B商户无资金流水；
• C、D各涉及两条资金流水；
• E涉及4条，因为其订单在支付和退款两个状态切换时，各会涉及两条记录；

资金流水信息一般要同步到企业财务系统。在退款时一定要记录手续费的收入。因为支付渠道在操作退款时，会用之前所收取的手续费抵扣掉今天所产生的手续费。

总结

做电商系统后台时，切不可把订单流水、交易流水、资金流水混为一谈。否则会陷入无止境的数据核对和口径问题中。最好的办法就是三者解耦和，根据事件触发去保证三者的关系。三者各司其责，各有独自的业务含义和统计意义。
订单流水、交易流水、资金流水 此为作者本人习惯叫法，切勿去扣订单、交易、流水等词汇标准含义。因为支付行业是发展很快，词汇含义也同步演化。大家可以根据各自系统特点叫不同的名称均可。

本文由 @侠之大者 原创发布于人人都是产品经理，未经作者许可，禁止转载。