支付交易——清结算

摘要

老王有个账本，店里进了哪些货、进的谁家货、花了多少钱，老王都会—一记下来;卖了哪些货、卖给了谁、卖了多少钱，也都会记下来。为什么要有个账本，看看老王是怎么进货和卖货的就知道了。老王店里虽然商品种类很多，但是备的量都不大，有些甚至仅作展示用。有时候客人因为家里办事，来店里大量采购，老王就立即打电话让供货商送货过来;有时候客人要为公司采办团建用品，但老王没那么多货，也是打电话让供货商送货。

老王要向厂家进货，客人向老王买货，常来常往，都互相信任，这钱一般都是到了约定的账期或者一天空闲了的时候再付。老王记账本，一来是为了自己记录进货成本，二来是怕结算的时候供应商多收钱，三来一些乡亲要赊账或者改天结，需要有个明细，怕到时候时间长了，大家忘了，没有账目就说不清楚。不同的供应商有不同的结算日子:有的不赊账，要求先款后货﹔有的当天就要付;有的按月结，到了结算日子就会给老王寄账单，老王也从不拖欠。另外，如果老王的进货量大，按月结的供应商还会给一些返利，在结算时给他打个折。但有一点，老王在拿到账单后，都要先与自己的账本核对一遍，对得上就付，对不上就去找供应商核查，对明白了再付。到了乡亲们来结算的时候，老王就将账本拿给他们看，没问题就按照账本付钱，有问题就找老王。

生意这么做着，老王每个月、每个季度、每年都会汇总下账本记录，看看自己是赚了还是亏了，赚是赚在哪里，亏是亏在哪里。这便是老王的账本的功能，也是支付里清分与结算所做的事情。
老王账本上记的那些供应商和客户的账对应于支付里账单服务所做的通道对账单与供应商对账单。
供应商给了对账单，老王要对得上才给钱，对不上的要去核查是哪里错了，这对应于支付里对账服务的账账对账与差账处理。

供应商对老王针对进货金额进行返利，这对应于支付里的合同系统计费规则。不同的供应商对老王发货与打款规定不一样，这对应于支付里的结算规则。老王定期汇总账本，盘点自己的盈亏情况，这对应于支付里的会计服务。其实老王和支付做的事情一样，只是换了角色、生意大小不同而已。

一、清结算的概述

开始我们从老王用一只羊换老李两只鸡的故事中知道，支付就是三件事:交易、清分和结算。交易是支付的前提和基础;清分是结算的数据准备阶段;结算是资产交割与转移的过程，是支付的完结。

清分是根据交易的的终态结果，对商户、用户和支付通道进行手续费计算，账单和账款资金的核对，结算是根据清分的数据，用与商户、用户、支付通道等约定的结算方式，借宿那周期进行资金的调拨，清分与结算合称为结算。

1.1 双边关系

在阐述如何清分和结算之前,有必要说明一下，商户、支付平台、支付通道之间的关系是双边关系，这是正确认知清分、结算乃至支付的前提。

在支付里，商户与支付平台、支付平台与支付通道都是双边关系，不存在三角债，各自的边界都很明确，不能逾越。从图7-1中我们可以看到，支付分成4个过程-进件、交易、清分和结算，涉及3个对象——商户、支付平台和支付通道。

1. 进件环节

进件环节包括以下两个部分。

商户人驻支付平台:商户按照支付或者业务平台的要求提交进件信息，支付平台为商户开通秘钥、权限和支付产品等权限。
支付平台入驻支付通道:支付平台按照接人的各支付通道要求提交进件信息，支付通道为支付平台开通秘钥、权限和支付产品等权限。

可以看出，在这个关系中，两边都是完全独立的双边关系；商户只是支付平台的商户，并不是支付通道的商户；支付通道的商户只有一个，就是支付平台。

2. 交易环节

交易环节包括以下两个部分。

商户向支付平台发起交易:商户按照支付平台签约信息，上送报文（包括支付平台为自己分配的密钥、开通的支付业务范围）给支付平台﹔支付平台返回给商户对应的支付结果和返回码，这个返回码是基于支付通道的原始返回码进行映射后转译的。
支付平台向支付通道发起交易:支付平台收到商户请求，按照自己的路由规则，计算出最优通道，上送报文（包括支付通道为自己分配的密钥、开通的支付业务能力)给支付通道;支付通道返回给支付平台对应的支付结果和返回码。

3.清分环节

清分环节包括以下两个部分。

商户和支付平台对账:支付平台将商户的所有交易订单生成账单并推送给商户;商户按照支付平台推送的账单进行对账，如果有对不平的账单就联系支付平台进行差账处理。
支付平台和支付通道对账:支付通道将支付平台的所有交易订单生成账单推送给支付平台;支付平台按照支付通道推送的账单进行对账，如果有对不平的账单联系支付通道进行差账处理。

4.结算环节

结算环节包括以下两个部分。

商户和支付平台结算:支付平台按照与商户约定的账期、费率、结算方式进行商户款项结算。
支付平台和支付通道结算:支付通道按照与支付平台约定的账期、费率、结算方式进行支付平台款项结算。

从上面的流程可以看出，两两都是双边关系，无论上游支付通道有没有向支付平台提供账单，支付平台都应该按照自己记录的商户交易结果向商户提供账单;无论上游支付通道有没有将款项结算给支付平台，支付平台都应该按照自己的账单结算给商户。没有三角债，两两都是清清楚楚的双边关系，需要做到收支两条账，需要财务调拨头寸、管理资金。

1.2 模块职能

在建立了双边关系的认知后，我们看看清分与结算的具体职能。在清分的过程中，需要确保账务信恩数据准确、账务对平,能够为后续债权债务提供数据支撑。这包括交易信息落地和状态流转、根据各方日切时间将数据汇总、差账异常数据处理、计算出应收应付金额等。

在结算的过程中、需要确保债权债务信息完整.状态符合流程,确保结算资金的可用性，记录并通知结算结果等。

为了确保上述职能的执行，支付体系中提供了很多服务模块，包括对账服务、计费服务、文件服务、差账处理服务、结算服务等。如果涉及会计和账户，那么还有会计模块和账户模块。我们把这些叫作清算服务层，如图所示。

1.支付核心模块

支付核心模块用来接收支付交易请求，处理支付交易，比如收款、出款、鉴权等场景中的消费、预授权、退货等不同类型的支付交易。支付核心模块会调用路由系统，根据路由决策情况将交易上送给支付通道，根据支付通道返回结果更新支付通道流水状态和业务订单状态，同时将业务订单和支付通道流水号推送至清结算系统，进行后续账单生成、清分与结算处理。

2.账单模块

账单模块主要有下面这4个职能。

落地交易单数据。商户发起交易，当支付状态流转至终态时（无论成功还是失败)，系统会将终态订单推送至账单模块，账单模块记录下该支付数据（涵盖商户、交易单、通道单、交易金额、支付方式、交易类型、支付产品等数据)。
获取支付通道对账单。根据与支付通道的约定，支付平台通过各种形式获取支付通道对账单，如支付通道的邮件推送、FTP下载与推送，自己通过后台下载等。
生成并推送商户对账单。根据与商户的约定，通过各种形式让商户获取商户对账单，如邮件推送、FTP下载与推送、让商户自己通过后台下载等。
生成通道对账单。对账单包括商户对账单和支付通道对账单。账单服务分别对商户维度的业务订单和支付通道维度的通道流水进一步处理，调用计费模块获取商户和支付通道手续费，生成对账单，并将账单按照分类推送:将商户对账单推送至商户;将支付通道对账单推送至对账模块，进行通道交易对账和通道资金对账。

3.计费模块

计费模块主要负责商户手续费和通道成本的配置（可由商户合同系统或者路由配置推送至计费模块，生成数据)，以及计算并返回费用结算方式、币种、金额及结算日期。

4.对账差锚模块

对账既包括自身支付平台与上游支付通道（如第三方支付公司或银行）对账，也包括自身各个服务间（比如账单与会计)对账，其作用是保证自身各个应用之间记录一致。我们将前者叫作单向对账，将后者叫作双向对账。

与上游支付通道的对账过程分为交易流水对账和到账凭证、到账实际资金的对账。我们把前者叫作账帐对账，将后者叫作账证对账、账实对账。

对账用来将账单核算对平，对于不能核对匹配的交易进行补单或者退款等差账处理，最终实现账单对平。我们将这个过程称为轧账和平账。

5.账户模块

账户模块用来进行资产的账户分类，并根据交易和对账情况进行账户的记账及资金信息流变动。常见的账户有余额账户、冻结账户、礼品卡账户等。

6.会计模块

会计模块根据账户模块的请求进行会计的日间记账，并进行日终处理和财务并账。本书中不会详细阐述会计模块，原因有二:其一，会计借贷及科目分录需要有专业财务人员参与，在此不作为产品经理必备技能;其二，会计模块在清结算中并非必需模块，很多公司用流水账单汇总代替公司对账，并不采用会计模块。

7.财务模块

财务模块根据对账情况进行账证对账（核实对账结果与银行打款凭证是否匹配)、账实对账（核实对账结果与银行实际打款是否匹配)，以及按照结算方式和账期进行结算处理。

1.3 模块流转

在清算服务模块流转图中，除了给出相关模块，还标记了序号。这些序号就是各模块的流转顺序。下面具体看看各个模块是如何流转的。

支付订单推送。支付核心模块将有效的支付订单（包括支付订单、退款订单、风险订单等）推送至账单模块。注意、这里说的是“有效”而不是“成功”．因为在有些类型的交易中（如外卡交易).有的交易不管成不成功都要支付风控手续费，也就是说即使支付失败，也是要记录并且收费的。
支付通道流水推送。支付核心模块将成功和失败的支付通道流水（包括支付、退款等）推送至账单模块。
请求商户计费。账单模块根据支付订单交易信息，请求计费模块计算商户手续费。
返回商户计费结果。计费模块返回商户手续费的计算结果、收费模式及收费日期。
请求通道成本计算。账单模块根据通道流水请求计费模块计算通道成本。
返回通道成本。计费模块返回通道成本的计算结果、收费模式及收费日期。
推送账单数据并记账。账单模块完成商户账单计费，生成商户账单后，将账单推送至商户账户并请求账户模块记账，变动资金信息流。
请求会计记账。账户模块记账成功后均请求会计模块进行会计记账。
支付通道流水对账。账单模块在支付通道流水成本计算完成后，.将其推送至对账差错模块进行交易对账:解析支付通道订单格式，进行两边账单的账账对账;针对对不平的账单进行差账处理;根据对账结果推送给财务模块或者会计模块。
请求账户记账。对账差错模块将对账结果推送至账户进行记账。
对账差错处理。针对对账的长短款，对账差错模块请求支付核心模块进行补单和退款处理。
财务并账。每日将科目发生额和余额进行映射并自动推送到财务系统，每月进行核对。

整体介绍完各模块的职能与流转后，下面我们依次重点讲解计费服务、账单服务和对账服务。

二、计费服务

不管最终对的是商户账还是支付通道账，也不管最终付款方式是全额结算还是净额结算，清分和结算的前提都是记录和计算完成应付或应收多少手续费。而这个记录和计算的过程，我们就称为“计费服务”。

计费服务中计算的对象有两个:一个是服务的商户，一个是上游的供应商。就像老王开店一样，一方面把货批发给那些小代理商，一方面向厂家批货，两头的账都要算清楚。而要算清楚，就得把每个对象收多少钱、付多少钱、怎么收钱、怎么付钱的规则都记录下来。

我们可以把计费对象分为商户和支付通道，将计费服务所做的流程分为3个步骤:配置、查询和计费。计费服务的具体流程如下。

商户计费规则配置。
商户计费规则查询。
商户手续费计算。
支付通道成本规则配置。
支付通道成本规则查询。
支付通道成本计算。

2.1 商户计费模块

2.1.1 商户计费配置

首先需要说明的是，除了在计费系统直接配置计费规则外，还有多种方式进行计费数据的配置。比如在合同签约时，可以将商户计费规则配置在合同系统中，由合同系统推送至计费系统中;支付通道可在配置通道基础信息里配置收费规则，由物理通道计费信息与计费规则保持同步，推送至计费规则。

这里重点来看商户计费规则应该有哪些信息，至于如何记录或生成计费信息，不展开介绍。另外还要说的是，这里的计费配置设计有两个方向。-个方向是把支付产品拆解得足够细．用变付产品来定义手续费．比如可以将信用卡拆解为信用卡快捷、信用卡非快捷、信用卡不区分、信用卡 3DS等。在这个方向上，可以按照业务需要无限枚举支付产品。另·个方向凰支付产品撷粒度粗，用支付产品·钱他字段远性代表-条唯的规则、比如信用卡 3DS产品可以用信用卡支付产品＋是否3DS来表示。

在商户计费规则配置模块中，有不同维度的属性。支付核心模块支付完成后，推送账单模块，账单模块调用计费模块获取信息并生成最终对账单，而计费模块就是按照这些字段计算出每一笔手续费的。

1. 计费规则ID

每一条规则自动生成不重复的编号。由于计费的维度很多，-个商户可以有多条计费规则,也可以在.条计费规则里配置多个计费维度。多条还是一条属于UI层面的问题，大家可以按照实际需要来，在这里我们以一个商户一条规则、一个计费维度来演示。

2. 商户信息

商户信息部分有3个必填项。

商户号:每个商户的唯一ID，比如0001。
商户名称:与商户号一一对应，比如老王杂货店。
规则名称:作用是方便相关人员从名称大概了解规则内容，比如老王杂货铺3DS交易规则。

3 计费维度

关于计费维度需要说明的是，维度有很多，不是每个维度都是必填项。另外，如果配置了多个计费维度，很可能会一笔交易命中多个计费维度，这时按照优先级高的执行。

币种:交易发生时上送支付网关金额所对应的币种，比如美元、日元。在多币种的支付能力里，需要特别注意交易币种，否则将印尼盾结算成美元，资损就太大了。
地区:按实际地理位置划分的地区。不同的地区收费方式可能不一样，之前我们介绍卡组织时说过不同地区的收费差异，所以这里按照实际需要进行地区划分，比如亚洲、欧洲。
国家:实际地理位置。同一地区不同国家的收费情况不-样，这里按照国家划分，比如中国、美国。
卡组织:按照卡组织计费。常见的卡组织有Visa、Mastercard、JCB、美国运通等。
卡类型:按照卡类型计费。卡类型有贷记卡、借记卡、准贷记卡，可以扩展“余额”类别。
账户类型:用来表示是对公交易还是对私交易。
支付方式:按照不同支付方式计费，比如信用卡支付、借记卡支付、账户支付等。你可能会有疑问，卡类型与支付方式是否重复。答案是，如果提供的支付能力只有卡基支付，那么这里是重复的;但如果提供的支付能力包括账户支付，那么就不重复。通过支付方式＋卡类型可以实现钱包账户信用卡支付的计费。
交易方式:这里指是DCC还是EDC，前面已经介绍过,这里不再赘述。
风险模型:支付中有3DS和非3DS，按照3DS和非3DS单独计费。
支付通道:按照支付通道计费，比如某某代扣通道、银联认证通道。
到账时效:用于按照商户到账时间来计费，比如实时到账、T+1到账等。
支付产品:按照支付产品计费，比如免密支付产品、鉴权产品等。支付产品和规则维度成反比关系:如果支付产品维度足够细，那么规则维度就可以精简;如果支付产品维度粗，那么规则维度就需要细。

4. 计费规则类型

计费规则类型部分有以下4项内容。

交易类型:按照不同交易类型计费，比如转账、代扣、代付等。
单笔/批量:计费形式，用于区分是按单笔收费还是按批次收费。
计费类型:用来表示单笔收费、按照百分比、按照阶梯手续费或者是否有封顶手续费等不同计费类型。
手续费:表示具体手续费值。当然，阶梯和非阶梯表现不一样。

5 计费规则状态

计费规则状态部分有以下3项内容。

状态:确定规则的有效性，比如生效还是失效。
生效日期/失效日期:表达规则有效期。比如，二者的取值20200101和20200301表示2020年1月1日到2020年3月1日这段时间内有效。
优先级:同一商户同样匹配规则按照优先级顺序执行，甚至还可以定义对于相同优先级的规则，创建时间晚的优先。

6 结费属性

结费属性部分有以下4项内容。

费用结算周期:比如按月结还是按日结。
结算日:每月固定日期结算，还是T+1或D+1。
结算日期类型:工作日还是自然日结算。
收费方式:全额结算还是净额结算。

通过上述字段及其排列组合，我们能够灵活地对商户配置计费规则，并且能够设置不同优先级的计费规则。接下来看看如何接受调用方请求进行查询与计费。

2.1.2 商户计费规则查询与计费

商户计费服务有两个职能:-是支持查询手续费计费规则，二是支持计算手续费。两种职能不一样，如果请求类型是查询手续费计费规则，那么就根据查询参数返回目前优先级最高的手续费情况;如果请求类型是计算手续费，那么就根据请求参数返回具体手续费计算金额。

无论是查询还是计费，请求参数都是根据上面的配置条件项来的，差别仅在于是返回手续费计费规则（如内扣还是外扣、3%o还是每笔1元手续费)，还是返回计算好的具体手续费（如1元人民币)。因此，这里不再一一列举请求参数和返回参数。

但计费规则是有优先级的。优先级除了直接手动设定之外，还可以以规则内容的详细程度来决定。与之前路由系统中的基础路由或引导路由一样,匹配到的规则中，越具体的优先级越高。

2.2 支付通道成本模块

支付的过程始终连接着两边:商户与支付通道。上面已经了解了商户的计费模块配置，这里再来看通道计费规则就会容易很多，几乎一样。因为我们与商户、支付通道与我们之间都是上下游关系，所以理论上，我们与商户之间有哪些收费方式和计费模型，通道与我们之间就有哪些收费方式和计费模型。

通道计费规则中也有各种各样的属性。支付核心模块支付完成后，推送账单模块，账单模块调用计费模块获取信息并生成最终对账单;而计费模块就是按照这些字段计算出每一笔手续费的。

图7-5中各个字段在商户计费规则中展开说明过，查询与计费逻辑也都与商户计费规则几乎一致，这里不再赘述。以上基本就是商户和通道的计费模型与逻辑设计了，但正如哲学上所说，事物具有普遍性和特殊性,具有共性和个性。这里只是基于“共性”的说明，大家在具体实操和处理需求时也许还会面对各种各样的“个性”，比如结算时需要有保证金，只结算交易的一部分，剩下的部分作为风险拒付等方面的保证金。

三、账单服务

一笔订单在支付的过程中会变成不同的类型，比如支付成功订单、退款订单、拒付订单等。一笔订单在支付处理的过程中会面对不同的对象，会面对商户，面对支付通道。订单的种类也分很多种，有交易单，有通道单。

账单服务所做的就是处理这些不同类型、不同对象的订单，并落地数据，提供账单。本节将详细介绍账单服务的4个职能:落地交易单数据、获取支付通道对账单、生成与推送商户对账单、生成通道对账单。

3.1 落地交易单数据

先来回顾一下，一笔流转至终态、成为有效订单的支付订单经历了哪些步骤。

商户向支付平台发起交易。商户在发起交易时，会带着一系列请求参数，比如商户的商户号、加密密钥、业务订单号、交易币种、交易金额、交易类型、支付方式、支付要素乃至此次交易的商品详情等。
支付平台生成交易单或流水号并提供给商户。支付平台可能要在有了最终支付结果后才向商户提供支付流水号，这取决于这笔交易采用的是账基支付还是卡基支付，是实时同步支付结果还是异步通知。
支付平台获取最优通道。支付系统通常都会有路由系统，差别仅在于这个路由系统是否健壮、其算法是否丰富等。由之前对路由系统的介绍可知，这一步支付平台会根据商户发起的交易请求确定最优物理通道，也就是接入的支付通道是哪个，也会知道计算此通道为最优的路由规则是哪个。
支付平台将交易上送给通道进行交易。根据路由计算结果，支付平台将交易上送给支付通道进行交易，支付通道返回对应的支付结果及返回码。注意，即使是支付平台余额支付，我们也将余额视为支付通道，差别仅在于通道服务方属于内部还是外部而己。
支付平台将支付结果返回给商户，将订单推送至账单服务。对于支付通道返回的支付返回码，支付平台会将其转译，映射为方便商户或用户理解的对应返回码。此外，无论是收款还是退款，无论是成功还是失败，订单一旦进入终态，就会被推送到账单服务或者进入数据库，等待后续工作。

对于上面的每一类信息，举例如下。

商户信息。比如商户的商户号、加密密钥、业务订单号、交易币种、交易金额、交易类型、发起时间、支付方式、支付要素、支付产品、支付地区、风险模型、DCC/EDC、商品详情、支付结果、映射支付返回码等。
用户信息。比如用户ID、用户风险等级、用户会员等级、用户营销等。
自身系统信息。比如生成的给商户的支付流水号、给支付通道的自身业务单号、路由规则ID、风险数据、自身系统异常的错误原因、营销优惠信息等。
支付通道信息。比如支付通道ID、上送通道的交易类型、支付方式、支付产品、支付金额、汇率、币种、支付结果、通道返回的原始支付返回码等。

以上信息就是一条交易单所存储的内容。总的来说，保存的信息越详细，能够做的事情越精细:提供给商户的账单可以更翔实，维度更多；发生调单、定位问题时，可以找到的信息也越多;等等。

3.2 获取支付通道对账单

支付平台都或多或少间连或直连了第三方支付机构、银行、卡组织，与这些机构发生着支付交易。账单是支付交易的一部分，机构会按照约定时间、约定方式将账单发送或上传给支付平台。在获取支付通道对账单的整个流程中，支付平台主要完成以下三个事项。

3.2.1 明确对账文件规范和要求

在下载对账文件前，必须先知道与其相关的规范和要求，才能保证下载准确及时。在获取对账单服务时，我们常做的工作如下。

1.1 明确对账文件的命名规范与格式

我们一般根据文件名来查找并下载对账文件。因为各机构的对账文件命名规范与格式不尽相同，所以我们需要首先明确对账文件的命名规范与格式。

大体的命名规范是商户号_交易日期.文件格式。当然，如果不同的交易类型使用不同的对账单，那么对账单的格式会变成交易类型_商户号_交易日期﹒文件格式。如果数据量大，有多份对账单，还可能会在后面加上序号，变成交易类型_商户号交易日期_序号﹒文件格式。

交易日期一般采用YYYYMMDD 的格式，文件格式有xls、txt、csv等，如00001__20180809.xls表示商户00001于2018年8月9日在该通道交易的对账文件。

1.2 明确对眼文件的时间

一份对账文件有以下4个与时间相关的因素。

对账文件日切时间区间。每个文件的交易时间是有日切时间点的，日切时间区间指从一个工作日的开始时间到结束时间，所以首先要知道一个对账文件涉及交易的时间区间，一般来说国内交易是0点至24点。
提供对账文件的时间差。比如是T+1还是D+1提供对账文件，某些国外通道（如美国运通）甚至可能会T+3提供对账文件。对账文件的时间差不同就意味着支付平台下载规则和对账规则不同，拿到一份对账文件可能最长需要8~10天。需要说明的是，如果按照T+N提供对账文件，那么需要明确工作日是按照哪国的工作日。比如对接海外通道或者开展海外业务时，我们按照国内工作日，而支付通道按照泰国工作日，这就会有纰漏。
日切时间所依据的时区。时间是和时区绑定在一起的，就像交易金额一定关联着交易币种一样。我们在做国内业务时，默认使用北京时间，因此不用关心时区问题。但如果做的是海外业务或者接人的是国际通道，就必须明确日切时间依据哪个时区，比如是北京时间还是伦敦时间，否则会给后续下载账单和对账带来很多问题。
账单推送时间。无论是主动下载账单还是人工登录后台下载，支付平台都需要先等通道生成账单并将其推送到服务器。比如通道日切时间点是24点，账单推送时间是第二天凌晨4点前,那么我们就需要设定系统在4点后自动下载，或者让运营人员4点后进行人工下载，避免做无用功。

3.2.2 下载对账文件

对账文件的获取方式有很多，有支付通道主动推送的,也有需要支付平台自己去下载的;有人工的，也有自动的。需要明确获取方式，根据具体方式向对方提供或者要求对方提供对应的信息。
常见的获取方式有以下3种。

邮件推送。我们需要向支付通道提供邮箱地址，便于对方推送。
SFTP ( Secret File Transfer Protocol，安全文件传送协议)或者 FTP获取。SFTP和 FTP都是文件传输的方式，如果是让对方将对账文件推送给我们，我们需要向其提供文件推送地址、用户名及密码;反之，如果是我们从对方地址下载，需要对方提供给我们对应的地址、用户名及密码。
后台下载。一些银行或第三方机构会为支付公司开设企业门户，分配账号和初始密码，由运营人员登录后台进行下载。但是我们并不推荐采用这样的方式，因为它需要人工参与，无法实现账单自动下载，而账单自动下载是清结算自动对账中重要的一步。

3.2.3 解析对账文件

每家支付通道的文件格式不一样，每个文件字段代表的意义不一样，字段所在位置也不同，平台在下载对账文件后，需要理解对账文件中的字段，并将这些字段对应到自身系统进行解析落库。

来国内第三方支付机构的交易对账单

该账单的名称格式为交易对账单_交易起始日期-交易结束日期.xls，如交易对账单_20200101-20200101.xls，如图7-6所示。

拿到这样的对账单样表，我们就需要明确告知清结算系统的开发人员，让他们将表格解析成如下字段。

第2列:交易日期。对应支付发起的交易日期。
第3列:交易流水号。对应通道返回的流水号。
第4列:机构名称。对应支付平台在支付机构开通的商户号或户名。
第5列:交易类型。对应交易发起的类型，如消费、退款、预授权等。
第6列:交易金额。对应发起的支付金额。
第7列:商户应收款。对应支付平台应该结算的款项。商户应收款与结算方式有关，比如对于一笔1000元的交易，如果是全额结算，就会结算1000元，商户应收款就是1000元;如果是净额结算，扣除手续费20元，商户应收款就只有980元。
第8列:机构服务费。对应支付平台应该支付的手续费。

某国际卡组织对应的对账文件

图]7-7为某国际卡组织对应的对账文件，看起来像是“天书”，如果产品经理不做解释，运营人员和开发人员根本就看不懂，会无所适从。下面我们看看如何来解析这个对账文件。产品经理经过研究文档，并与卡组对接人员沟通，了解到如下信息。

国际卡组织。对账文件中会存在交易币种与结算币种。
对账文件中每个商户号、每个结算币种会产生不同结算记录。
币种金额规则。当交易币种为JPY(日元)、KRW(韩元)时表示元，为其余币种时表示分。
明细交易既包括所有正向的收款、付款交易，也包括负向的退款交易。

3.3 生成与推送商户对账单

上一节介绍了账单服务和通道之间关于账单处理的流程，本节来讲解账单服务和商户之间关于账单处理的流程。在这个场景里主要有两个流程:生成商户对账单和推送商户对账单。

3.3.1 生成商户对账单

商户对账单是指按照约定提供包含交易明细与交易总额的账单文件，里面至少包含商户号、交易日期、支付流水号、交易类型（消费、预授权、退款）或交易方向（正交易、反交易)、交易金额（如涉及多币种交易，还有交易币种)、手续费这些参数，有的对账单还会加上商户订单号、风控处理费等参数。

具体对账单可以看节中的例子。节中账单生成与提供方是支付通道侧，支付平台作为商户侧接收与获取对账单;现在反过来，变成支付平台侧是支付通道角色，提供给合作方对应商户对账单。

在商户接入时，会依据公司清结算服务设计及商户需求与商户约定对账单的规则，这些规则也应该成为我们交付给商家的标准手册。在将一份账单提供给商户前，必须先告诉商户账单里有哪些内容、有几份账单，这样商户才能根据内容范围进行解读与分析，具体如下：

对账单日切时间与时区。支付平台为商户提供的对账单覆盖的交易时间范围是什么，比如О点至24点;时间对应的是哪个时区。
不同交易币种的对账单规则。支付平台支持商户不同的交易币种，这些不同交易币种的交易是在同一份账单中体现，还是每个交易币种在独立的对账单中体现。
不同结算币种的对账单规则。不同的商户在针对同一结算币种时也会有不同的结算币种需求，特别是跨地区经营或者交易量大的头部商户。有的商户希望同样的币种（如泰铢）交易，50%结算成泰铢在当地，50%结算成美元到中国香港。不同的结算币种涉及不同的汇率差，所以对账单是一份还是多份是需要明确告知商户的。
不同交易类型的对账单规则一个支付平台给同一商户提供的交易类型可以是多样的，有出款交易（如代付交易)，也有收款交易（如代扣、消费、预授权)，对于这些不同交易类型所涉及的对账单，同样需要明确是一份还是多份。
对账单同一天发生正反交易的规则、交易中会出现同样一笔订单当天客户既做了支付正交易，又做了全额退款或者撤销交易。对此，不同支付公司的处理方式不一样，有的轧差同时不体现，有的不做轧差，同时放进去。对账单的内容规则不同，后续对账时规则也会不一样，这也是需要明确告知商户的。
一份对账单的最大文件容量与笔数．一-份对账文件不可能无限大，而对它的限制是通过设定笔数或者文件大小来实现的。对于商户来说，交易量特别大的时候，一份对账单会无法覆盖其全部交易。支付平台需要明确告知商户支持的最大交易笔数，避免商户在下载对账文件时有所遗漏。

将以上规则明确告知商户后，商户就能够准确解读和分析对账单了。我们看看一份给商户的对账单是如何生成的。在图7-8所示的用例图中，一份商户对账单通过脚本（JOB）生成账单，生成账单的数据来自两方面:交易时的数据和该商户提供计费服务配置的费率。

生成商户对账单的具体步骤如下。

落地支付平台交易数据。前面阐述了交易中涉及支付平台自身的交易数据，其中既包含服务的商户与具体支付情况，也包含调用的内外部自身支付通道，商户数据就是从这里拆分出来的。
获取商户计费费率与落地商户交易数据。7.3节阐述了商户计费规则的多项参数可灵活配置，实现不同的计费产品。从支付平台交易数据中拆分商户数据时，先将交易中相关参数传递给计费服务，获取对应的手续费，然后连同手续费写入商户交易数据中。查询参数和落地参数可参见7.3.1节。
生成商户对账文件。JOB服务或者账单服务根据商户交易数据库中的有效交易、与商户约定的账单时间与账单规则，生成对应份数的商户账单。

3.3.2 推送商户对账单

阐述过获取对账文件的方式有很多，有支付通道主动推送的，也有需要支付平台自己去下载的;有人工的，也有自动的。需要明确获取方式，然后根据其方式提供给对方或者要求对方提供对应的信息。

这里关于获取方式、推送的注意事项并没有变化，只是文件生成与获取方向变了。我们作为支付平台要获取支付通道的账单，而这里我们成了支付平台，商户要获取我们的账单。因此关于推送商户对账单的相关问题.与确认事项。

3.4 生成通道对账单

对账中有一个词与流程叫作“账账对账”，它是指用我们的账单与对方提供的账单进行明细账、总账等的对账。毕竞是与钱相关的事情，不能别人给什么，就信什么。要做这一步，首先要有我们的账单。

相同维度的账单才能对得上，对得平。相同维度包括相同的日期、商户、交易类型、币种等。为了使得生成的通道账单在相同的维度，需要事先确认好对方的账单规定，以对方的为准。这里只是双方方向改变了，确认的事项内容都没变，不再赘述。

账单服务将交易订单进行拆分，分别对商户维度的支付订单和支付通道维度的通道流水进行清分处理（包括商户手续费和自己的通道成本)，将通道流水清分后推送至对账模块进行通道交易对账和通道资金对账。通道对账单生成流程如图所示，图中一份支付通道对账单通过JOB生成账单，生成账单的数据来自两方面:交易时的数据和该通道提供计费服务配置的费率成本。

生成通道对账单的具体步骤如下。

落地支付平台交易数据。7.4.1节阐述了交易中涉及支付平台自身的交易数据，其中既包含服务的商户与具体支付情况，也包含调用的内外部自身支付通道，支付通道数据就是从这里拆分出来的。
获取支付通道计费成本与落地支付通道交易数据。7.3节阐述了支付通道计费规则的多项参数可灵活配置，实现不同的计费产品。从支付平台交易数据中拆分支付通道数据时，先将交易中相关参数传递给计费服务，获取对应的手续费成本，然后连同手续费写入通道交易数据中。查询参数可查看7.3.2节中介绍的各项配置条件，落地参数包含商户号、支付通道、支付平台订单号、支付通道流水号、交易日期、交易类型、交易金额、交易币种等。
生成支付通道对账文件。JOB服务或者账单服务根据支付通道交易数据库中的有效交易、与支付通道约定的账单时间与账单规则，生成对应的支付通道对账单。
更新支付通道对账单对账状态。对账所说的对平是指﹐交易金额和交易笔数都既不能多也不能少，否则就对不平，出现如长短账之类的差账。对账服务在对账对平之后会到账单服务里来更新对账状态，表示这一份数据没有问题了;超过一定时间没有对平的数据会进入差账处理模块，由人工介入。

四、对账服务

清分是数据的准备与计算的过程。账单服务承担的职能就是数据的准备工作，而对账服务承担的就是计算的职能，无论是单向对账还是双向对账。

我们已经知道对账分为单向对账和双向对账，单向对账又分为账账对账、账证对账和账实对账。此外，我们还了解了对账是轧账和平账的过程。轧账和平账的目的是进行交易核算，将账单对平，对于不能核对匹配的交易，进行补单或者退款等差账处理方式，最终实现账单对平。

作为支付产品经理，我们更关注的是将账单模块生成的系统支付通道流水与支付通道对账文件进行核对，也就是单向对账和账账对账的过程。如果账单对平会推送账单给财务系统、由财务人员校验凭证是否正确、款项是否无误，也就是账证对账和账实对账的过程。

在对账的过程中，按照对明细账或者对总额的核账规则进行对账。如果账账核对完全对平，会将账单打包批次推送至财务模块进行后续流转;如果账账对账不能核对匹配，就会对账单中交易的长款、短款进行差错处理。

在处理通道与账账对账时有3条原则。

第一，不能少收钱。交易了1万元，只收了9000元，这样肯定不行，生意再红火也抵不住后面有个洞，每天都在漏着。
第二，不能多收钱。明明自己记了数,交易了1万元，结果银行对账给了一万一，这样也不行。你多收了钱，肯定是有客户多付了钱没发现。不管是出于诚信还是担心事后客户投诉，都应该给客户退款。
第.三.，不能收错钱。钱总数对了，但是该收的没收，不该收的收了，这更不行。这说明没付钱的人以为支付平台付钱了，付钱了的以为没付钱，支付平台需要做的是给多付了钱的人退款，给没付钱的退单。

4.1 对账基准：

以哪一方账单为准，对账基准有两个。

以对方的为准。支付中主要指以支付通道或者银行的为准。对方的对账文件每一条交易数据和金额对齐了，就可以打包批次，更新状态，表示对齐了。
以我方的为准。支付中指以支付平台根据日切时间和通道规则生成的账单为准。只有支付平台自身生成的账单每一条交易数据和金额都对齐了，才算对平账。

在实际应用中，我们一般以对方的账单流水为准。而自己如果有没对上的流水，后续会再进行差账处理，但对方账单的对账状态为已对平。原因在于，支付通道侧打款规则不管我方账单能否对平，都会根据支付通道侧的账单记录，给支付平台打款。为了不影响资金入账后账单与资金进行核对，也就是相关的账证对账、账实对账，需要在对方账单对平后就视为对平，可以打包批次。

4.2 对账内容

对账对的是哪些字段，对账分为对明细账和对总账。

对明细账是将自身的账单与账单提供方提供的账单中每一条记录进行核对。在支付中，根据账单通道订单号或者支付流水号、交易类型、交易金额、交易日期、交易手续费进行比对。如果是外卡交易，会再加上交易币种、结算币种、结算汇率;如果收费条件不仅是商户折扣费率（MDR)，那么需要再加上其他的手续费率，比如还有风控手续费用、货币转换费之类。

对总账是将自身记录与账单提供方汇总金额、笔数进行核对。在支付中，根据交易日期与结算日期核对总交易金额、交易笔数等，整体金额一致就算对上。

需要说明的是，交易类型是对账过程中很重要的因素，因为它有着双重含义，不仅代表自身具体的交易类型，如消费、预授权、退款，还代表了交易方向，退款代表负交易，消费代表正交易。计算总账时是要根据这些交易类型进行加加减减的。

4.3 对账时间

日切时间是指下一账单日的开始计算时间。定义了日切时间，就确定了一个账单日的开始时间和结束时间。

对于支付这样高频的交易，每一秒都会发生很多瞬时交易，在日切时间也不例外。由于瞬时交易和交易系统的交互存在时间差，会出现支付平台侧交易时间算在当天，但是通道侧算在下一账单日的情况，进而造成在对账时出现账对不平、长短账的问题。

我们知道账对不平，是要推送差账处理的，那么在这种情况下，应该如何处理呢?

我们会为每个通道设定一个自动对账时间范围,比如48小时，也就是两个账单日。每份通道对账单会与对应日期的支付平台账单对账，如果有对不上的地方，会将无法匹配的订单留在对账交易列表中，等到下一日支付平台对账单生成时再进行比对。如果对上则为对平，依旧对不上的话，才会推送到差账模块进行处理。这样的对账我们称为连续对账、滚动对账。

4.4 对账结果

对账的结果通常分为4种:对平、长款．短.款、金额不-致m其中长短款是站在对账方角度看的，多收了钱就是长款，少收了钱就是短款。

特别说明，以下我们说的账单笔数都是基于正交易也就是我们收钱的角度．如果是反方向交易，比如退款、代付这些出款交易、长短款会完全相反。

第一种结果：对账完全匹配。这是最理想的结果，匹配后需要做的就是打包批次，抛送财务模块，进行后续的账实对账，看结算资金与账单金额是否一致。
第二种结果：支付通道有订单．支付平台侧无。我们站在支付平台立场，支付平台会多收到钱，因此我们将此种情况称为“长款”。比如支付通道对账单有100条，而我们只有99条订单，多结算了一笔。长款的情况既包括支付平台无订单，也包括无有效订单。长款的处理方式如下。
1. 支付平台侧补单。在支付平台侧补出所缺失的订单，使得两边都是100条订单，然后可以对平。
2. 支付平台侧对所补订单进行退款。由于这一笔订单是多收了用户的，补单只是为了对平，对平后还是需要退款，将多收的钱退回给用户。
3. 出现长款的原因除了系统bug、系统掉单外，还有一个更主要的原因是两边系统交互时间过长，导致查询无结果。支付平台侧对于无结果返回订单会进行定时轮询，但不会一直查询。超过一定时间若还无结果返回，就会置失败，等到第二天根据对账单情况再去判断是否进行差账处理。
第三种结果：支付通道无订单，支付平台侧有订单。由于支付通道侧比支付平台侧少订单，比如支付通道对账单有99条，我们有100条订单，最后支付平台侧账单是10 000元，对方因为少了l单订单记录，汇总是9900元。支付平台会认为自己少收了钱，此种情况我们称为“短款”。短款的情况是支付平台认为成功了，实际上银行并没有收到请求。对于这种情况，处理结果只有两种:短款追回或者短款坏账。处理的步骤如下。
1. 第一步，去“调单”，判断是不是通道侧失误，漏了。由于每笔交易在支付通道与支付平台之间都有报文存在，无论是发起交易请求还是交易结果回复，如果明确收到通道侧返回支付成功报文，可以去追责，要求支付通道侧补齐这个订单，认这个账。
2. 第二步，如果支付通道侧不认或者无法界定责任，需要支付平台侧采取补偿机制，重新发起扣款，补扣款项，避免资损。如果是非快捷交易，可能无法重试，那么需要联系商家冻结订单或者联系用户重新支付。如果货已经发出且用户不愿意再支付，那么就是资损。从这个角度也能看到，免密支付或者快捷交易在支付里不仅能用于改善用户体验、提升支付成功率，也能用于事后代扣、避免资损。
3. 需要说明的是，在免密支付的能力用于补扣款的场景中，一定要提前在用户进行绑卡的协议文案中说明得到用户授权，否则用户是可以联系发卡行拒付的。
第四利结果:两边金额不-致。两边账单明细都对得上，但是金额不一致。这种情况很少见，需要以一方为主进行差账处理，修改金额，使得两边账单一致