这篇文章里，作者对部分支付名词进行了解释，也对支付名词所对应的作用、使用场景做了一定解读，一起来看看，或许会对想了解支付行业的同学有所帮助。
关于支付名词解释之前已经写过一部分，不过之前写的更偏线下支付（银行卡收单）多一些，可以根据自己实际工作，结合着看，可翻看历史文章：
关于支付名词，除了部分平台自己定义或行业内达成共识的名词，别的大部分名词在不同使用环境、不同行业、不同公司代表的含义都不一样，甚至每个人理解都不一样，所以切记要结合实际业务使用场景去理解，而不是死记硬背。
下文中，我尽可能用大白话解释每个词的作用、使用场景，方便大家理解，因为如果仅是把百度百科或者官方平台的名词说明粘贴过来，毫无意义，同时我尽可能按照业务/交互流程去展开解释，整体串起来方便理解。
狭义上的支付就是客户通过不同的支付方式完成订单付款的过程，底层：资金从客户的资金账户转移到商户在支付机构的账户中，这个比较好理解，不再赘述。
简单来说就是支付的逆流程，正常底层资金要按照原有支付方式，原路退回到用户资金账户中，退款这块的业务逻辑还是很多的。
例如：退款金额的计算、多种支付方式的话退款顺序、原路退失败时如何处理？退款后优惠券的处理逻辑等等。
有的地方也叫【商户入网】，只是叫法不同，本质是一样的，仅在支付行业来说，进件就是想开通某种支付产品的商户，提交相关资料提交到支付机构/银行，商户完成认证、平台审核资料通过后，给商户开通对应支付产品的过程。
上文我们已经说了【支付】的定义，简单来说就是通过某种工具，完成资金不同账户间转移的过程，那“支付产品”，就是其中的【工具】，在不同的资金转移场景中，对应使用的工具也不一样，所以就会存在不同的支付产品，例如下图微信生态内的支付产品。
支付通道个人觉得就是支付产品的具象化/实体化的概念，有点偏技术性语言，简单理解为商户确定对接支付机构的支付产品之后，需要进行技术对接，才可以真正使用，也即是通道对接。
也就是支付通道的对接方式，总的来说分为直连和间连2种，分开简单说下：
👉直连：即商户直接对接支付机构，不需要通过中间服务商或额外的支付机构。
👉间连：即通过支付服务商或其他支付机构对接支付机构，举例：对接微信公众号支付，可以直接对接微信支付（直连），也可以通过微信服务商对接，再或者通过易宝（别的支付机构）对接。
至于两种对接方式的适用场景、优劣，之前写了一篇文章，后续整理好，会发出来，可以后续关注。。
有的人也叫“通道费率”，简单来说就是上文中“支付产品”对应的价格，即商户通过支付产品收款，需要缴纳给支付机构的手续费，需要注意的是不同的支付产品在不同行业（MCC），支付费率是不同的，这个每个支付机构都有明确的说明。
简单来说网关就是有支付需求的各业务线统一对接外部支付通道的桥梁，一家大的公司，可能多个业务线都需要支付能力，但不能各个业务线都对接一遍支付机构，所以需要一个系统统一对外交互，完成与支付机构的对接，而其他系统直接对接支付网关即可，统一对外的桥梁也就是支付网关，大概关系如下图：
狭义角度来说支付即付款，付款方式有很多：积分支付、余额支付、三方支付（微信/支付宝等）、组合支付（余额+三方）等等，这个理解起来比较简单，不再赘述。
这个需要支付通道结合着来看，上文中说到想要收款就得对接支付通道，有可能同一个支付产品对接了好几家支付机构，那用户支付时走哪条支付通道（支付产品）呢，这里就需要支付路由介入了。
不同的支付机构的支付产品特点不一样，有的可能便宜但稳定性不好，有的可能稳定性好但通道费率有点高，这个时候就需要根据路由规则选择对应通道，例如：优先请求便宜的通道，如果便宜的通道失败了，系统立马请求稳定性好的通道，这即是支付路由，实际的路由规则可能会比这个复杂些，只是简单举个例子。
简单来说就是系统会从多个维度判断此笔支付交易的真实性，防止出现盗刷、跑分等各种违规交易，给用户与平台带来资金损失，风控的话主要分为2个维度：
👉1个是用户维度：例如用户突然多笔大额支付，有可能微信就直接风控无法支付。
👉1个是商户维度：主要风控的维度有地点、时间、金额、频次等等，例如1个早餐店，晚上12点忽然发生多笔大额交易金额，就很有可能触发支付机构的风控。
简单来说就是计费，也有叫清算，清结算的，本质都是资金计费，即计算订单过程中各参与角色各自应得资金，这块可以实际参与业务中去，很容易出成绩，职业生涯中如果有机会建议可以重点发展，至于怎么做，这块有详细写过，可以查看历史文章。
结算也即是计费的下一步，参与方的资金算好了，对应要结算给参与角色，结算时的注意事项，结算单调整，审核，结算周期，结算方式管理等等，同样具体怎么做，可以直接查看历史文章，已经有详细说明。
简单来说就是计算完成的资金结算至商户的哪类资金账户，是结算至平台的资金账户体系，还是结算至商户的微信/支付宝账户，又或者直接结算至商家的银行卡账户中，有的公司也叫结算方式、结算类型等等，这个不重要，理解本质之后叫什么都可以。
实际业务场景中，商户的订单收入都会被支付机构或者平台抽佣（手续费），那结算的时候，就需要扣除这部分资金，也就诞生了足额结算和净额结算两种结算方式，分开说下：
👉足额结算：简单来说就是“收支两条线”，举个例子：收款金额100，手续费90，期初余额为0，则结算流水为下图：
有些商户为了记账的便利性，会要求专款专用，手续费从单独的账户出，即结算账户只记订单收入的资金明细，手续费明细单独记在手续费账户里，专业叫手续费的“内扣”（合账户记）、“外扣”（分账户记）。
👉净额结算：还有一个称呼叫“轧差结算”，简单来说就是“一次性结清”，还是上面的例子，实际的流水就会变成下图：
实际业务场景中大都采用足额结算，净额结算的很少，因为足额结算“收支两条线”，记账更加清晰明了，而“数据清晰”是记账的核心诉求。
代付可以从字面意思上去理解：”代为支付/付款“，也是支付机构/银行一种资金转移的产品，上文中的支付产品是收款的产品，代付是付款的产品，即平台可以通过此产品，将资金付款给个人（员工发工资）、供应商款项结算等等，可以代付到银行卡，也可以代付到商户/用户的微信/支付宝账户。
这个也比较好理解，即资金结算到商家实际可支配账户的时间，常见的结算周期主要有以下几个：
👉D+0：自然日当天结算，节假日也正常结算，也就是常说的实时结算。
👉D+1：自然日次日结算，节假日也正常结算。
👉T+0：工作日当天结算，但法定节假日不结算，顺延至工作日首日结算。
👉T+1：工作日次日结算，为支付机构最常见的结算周期。
👉T/D+N：T/D的含义与上文相同，N的话为各个平台视自身业务需要自行制定，常见于电商平台给平台商户结算控制的周期。
正常情况下支付机构都是T+1将资金结算至商家账户中，但实际业务开展中，部分业务场景是支持实时结算的，特别是线下支付（TX交易）中，实时到账是一个非常强的业务需求，这个时候就涉及到垫资。
即支付机构提前结算商户收款资金，垫资的方式可以通过垫资通道，也可以通过支付机构和服务商按比例共同出资完成，但这种业务某种意义上不合规的，常见某支付机构因为非法T0结算被处罚。
本质就是商户/用户间完成资金转移的一种方式，微信/支付宝转账都是比较常见的业务场景，同时支付机构的商户之间也是支持转账的，但多见于平台商户向下面的子商户的转账，子商户之间互转的能力基本不对外开放，一是场景很少，二是存在洗钱风险。
这个业务场景线上线下都比较常见（详见下图），需要特殊说明的是没有支付牌照的情况下，提供充值功能，形成资金沉淀法务层面是不合规的，需要对接支付机构或银行的账户体系，但话又说回来，如果业务都不行了，业务再合规又有什么意义呢，个人观点：在平台没有主观意愿要违规的情况下，可以先开展业务，后续再去处理合规的事情，很多大平台也是这么发展过来的。
有充值就得有提现，不然充值的资金退不出来，用户得炸锅，提现的技术侧实现方式可以用退款也可以用代付，代付更灵活些，因为退款涉及到较多的异常场景，例如超过退款周期、组合支付的下不同支付方式退款的优先级、赠送资金的处理逻辑等等都比较麻烦。
调账即“调整账务”，在实际的工作中【账务】比较常见的就是商家/用户的账户资金数据或者结算单资金数据，那【调账】也就是调整资金数据，调整的核心内容包括：金额、收支方向、记账月份（也可以按照发生月系统自动记账）、调账原因等。
我们上文中说了“帐”基本上也可以理解为资金数据，那分账简单来说就是分钱，市面上说的分账一般都是指分账能力，每个支付机构都有自己的分账产品，例如下图微信支付的分账产品，感兴趣的可以去微信开放平台查看。
收银台比较常见的实体就是我们常见的支付渠道选择页（如下图），其实可以映射我们生活中的收银台，超市结账的时候你也可以选择现金、微信支付宝，或者储值卡支付。
但实际上收银台还是有底层逻辑的，例如不同支付方式的展示顺序、营销提示语等等，都可以根据业务需要做成后台配置的。
订单你可以理解为就是1个数据合集，数据记录的侧重点在于购买产品的相关信息，例如商品信息：名称、价格/规格、数量等，购买人信息：用户ID、手机号、地址等、订单的状态信息、购买时间等等。
账单也是1个数据合集，数据记录的侧重点在于资金相关的信息，例如应付/实付金额、不同支付方式的金额、退款金额/状态、账单的状态/类型、营销金额/方式信息等等。
上文中说到1笔账单可以使用多种方式完成支付，为了数据记录的清晰与准确性，不同支付方式会生成对应的记录，也即是支付流水，举例：账单金额100，微信支付90，优惠券支付10，则会生成如下2条流水：
对账的话主要分为交易对账与资金对账，简单分开说下：
👉交易对账：交易对账其实又可以分为2类，一类是各系统间数据核对，保证数据没有重复，防止重复下单、结算、打款等等，一类是商户与支付机构间对账，主要作用是确定平台订单的状态、金额与支付机构返回的是否一致，以上2类对账主要技术侧同学关心。
👉资金对账：主要平台应收与实收的核对，平台应收即平台侧支付成功订单金额，平台实收即该订单支付机构实际结算金额，这个主要是财务侧关心，也是对账中心主要的使用用户。
市面上还有账实核对、账证核对等等，晦涩难懂、忽略就好，实际工作中基本不会有人提这些概念。
上文说了支付通道侧会对2次，1次是交易对账，通道侧提供的是交易对账文件，1次是资金对账，通道侧提供的是资金结算的数据文件，也即是资金对账文件。
支付机构提供的对账文件，支持在商户系统后台手动下载，也支持通过接口的形式对接下载，实际对账的时候，两种形式都要支持，互相兜底。
关于对账系统的的具体设计，后续也会写文章分享，可以持续关注。
这个是财务语言，很多人说的很复杂，又是资产/负债/损益啥的，但实际日常和财务同学打交道的过程中，基本不会提这么专业的概念，绝大多数情况下都是用支出/收入这种字眼交流，所以大多数人可以忽略掉市面上这部分内容，把重心用于了解实际业务。
这个与会计科目类似，很多人把这个字眼说地很复杂：会计恒等式、借贷相等等，不明觉厉，好像很高大上，其实记账很简单，就是把用户/商户的资金往来的关键信息记清楚就好（举例如下图），而且实际业务中大多数都是采用单边记账。
只有在一笔资金在两个账户流动的时候，才需要双边记账，例如从商户的保证金账户扣除资金去冲抵商家薪资账户的欠款，这也就是所谓的”有借必有贷，借贷必相等“。
这个直接从字面意思理解即可，即聚合了多种支付方式以满足实际业务场景需要，一般这种都是线上与线下支付场景都有，需要对接、管理不同的支付通道、其实如果一个公司对接了很多支付机构，基本上都可以看做是1个小的聚合支付平台，后续我也会分享为某集团设计的聚合支付平台（线上与线下支付都有），可以关注下。
所谓”二清“即二次清算（清分+结算），也就是支付机构把资金结算给平台商户之后，平台商户再次根据平台自己的规则结算给平台内的商户，如果平台商户本身没有对应的支付牌照或资质，就涉及合规问题，二清分为2类，简单展开说下：
👉资金二清：这个是市场上最常见的二清合规类型，即支付机构将资金结算至平台后，平台直接进行资金的二次清算。
👉信息二清：这个提的相对少一些，简单来说就是平台通过支付机构或者银行的分账能力，伪造交易信息将资金进行二次分配，本质还是为了资金二清。
二者的区别在于，前者直接分配资金，后者通过中间机构分配资金，市面上大部分银行的二清合规的产品都存在“信息二清”的问题，因为收款没有走银行，原始的订单收款信息拿不到，基本上平台说怎么分就怎么分。
支付相关的岗位工作中经常会提及合规问题，正常情况下有专业的法务同事判断就好，但个人也需要有一个初步判断，这里分享一个之前合规同事说的小技巧，即功能或者行为对于平台的用户/商户是否存在风险，如果有，那大概率会有合规问题，例如搭建资金池（钱包/充值）、押金等等，风险就是平台跑路。
总结：
上文只是介绍了常见的部分支付相关的名词，没有覆盖全部，而且仅是我个人的理解，在理解其本质之后，叫什么名字都可以，只是一个代号而已。
本文由 @鲸爷陆 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。