支付平台都或多或少间连或直连了第三方支付机构、银行、卡组织，与这些机构发生着支付交易。账单是支付交易的一部分，机构会按照约定时间、约定方式将账单发送或上传给支付平台。
在获取支付通道对账单的整个流程中，支付平台主要完成以下三个事项。
1、明确对账文件规范和要求
在下载对账文件前，必须先知道与其相关的规范和要求，才能保证下载准确及时。在获取对账单服务时，我们常做的工作如下。
（1）明确对账文件的命名规范与格式
我们一般根据文件名来查找并下载对账文件。因为各机构的对账文件命名规范与格式不尽相同，所以我们需要首先明确对账文件的命名规范与格式。
大体的命名规范是商户号_交易日期文件格式。当然，如果不同的交易类型使用不同的对账单，那么对账单的格式会变成交易类型_商户号交易日期.文件格式。如果数据量大，有多份对账单，还可能会在后面加上序号，变成交易类型商户号交易日期序号.文件格式。
交易日期一般采用YYYYMMDD的格式，文件格式有xls、txt、csv等，如0000120180809.xls表示商户00001于2018年8月9日在该通道交易的对账文件。
（2）明确对账文件的时间
一份对账文件有以下4个与时间相关的因素。
1）对账文件日切时间区间。每个文件的交易时间是有日切时间点的，日切时间区间指从一个工作日的开始时间到结束时间，所以首先要知道一个对账文件涉及交易的时间区间，一般来说国内交易是0点至24点。
2）提供对账文件的时间差。比如是T+1还是D+1提供对账文件，某些国外通道（如美国运通）甚至可能会T+3提供对账文件。对账文件的时间差不同就意味着支付平台下载规则和对账规则不同，拿到一份对账文件可能最长需要8~10天。
需要说明的是，如果按照T+N提供对账文件，那么需要明确工作日是按照哪国的工作日。比如对接海外通道或者开展海外业务时，我们按照国内工作日，而支付通道按照泰国工作日，这就会有纰漏。
3）日切时间所依据的时区。时间是和时区绑定在一起的，就像交易金额一定关联着交易币种一样。我们在做国内业务时，默认使用北京时间，因此不用关心时区问题。但如果做的是海外业务或者接入的是国际通道，就必须明确日切时间依据哪个时区，比如是北京时间还是伦敦时间，否则会给后续下载账单和对账带来很多问题。
4）账单推送时间。无论是主动下载账单还是人工登录后台下载，支付平台都需要先等通道生成账单并将其推送到服务器。
比如通道日切时间点是24点，账单推送时间是第二天凌晨4点前，那么我们就需要设定系统在4点后自动下载，或者让运营人员4点后进行人工下载，避免做无用功。
2、下载对账文件
对账文件的获取方式有很多，有支付通道主动推送的，也有需要支付平台自己去下载的；有人工的，也有自动的。要明确获取方式，根据具体方式向对方提供或者要求对方提供对应的信息。
常见的获取方式有以下3种。
·邮件推送。我们需要向支付通道提供邮箱地址，便于对方推送。
·SFTP（SecretFileTransferProtocol，安全文件传送协议）或者FTP获取。SFTP和FTP都是文件传输的方式，如果是让对方将对账文件推送给我们，我们需要向其提供文件推送地址、用户名及密码；反之，如果是我们从对方地址下载，需要对方提供给我们对应的地址、用户名及密码。
·后台下载。一些银行或第三方机构会为支付公司开设企业门户，分配账号和初始密码，由运营人员登录后台进行下载。但是我们并不推荐采用这样的方式，因为它需要人工参与，无法实现账单自动下载，而账单自动下载是清结算自动对账中重要的一步。
3、解析对账文件
每家支付通道的文件格式不一样，每个文件字段代表的意义不一样，字段所在位置也不同，平台在下载对账文件后，需要理解对账文件中的字段，并将这些字段对应到自身系统进行解析落库。
我们来看两个对账文件的样例。
（1）某国内第三方支付机构的交易对账单
该账单的名称格式为交易对账单交易起始日期-交易结束日期.xls，如交易对账单20200101-20200101.xls，如图1所示。
图1 某国内第三方支付机构交易对账单
拿到这样的对账单样表我们就需要明确告知清结算系统的开发人员，让他们将表格解析成如下字段。
·第2列：交易日期。对应支付发起的交易日期。
·第3列：交易流水号。对应通道返回的流水号。
·第4列：机构名称。对应支付平台在支付机构开通的商户号或户名。
·第5列：交易类型。对应交易发起的类型，如消费、退款、预授权等。
·第6列：交易金额。对应发起的支付金额。
·第7列：商户应收款。对应支付平台应该结算的款项。商户应收款与结算方式有关，比如对于一笔1000元的交易，如果是全额结算，就会结算1000元，商户应收款就是1000元；如果是净额结算，扣除手续费20元，商户应收款就只有980元。
·第8列：机构服务费。对应支付平台应该支付的手续费。
上面是个简单易懂的对账文件，我们再来看一个相对复杂的例子。
（2）某国际卡组织对应的对账文件
图2为某国际卡组织对应的对账文件，看起来像是“天书”，如果产品经理不做解释，运营人员和开发人员根本就看不懂，会无所适从。下面我们看看如何来解析这个对账文件。
图2 某国际卡组织对应的对账文件
产品经理经过研究文档，并与卡组对接人员沟通，了解到如下信息。
1）国际卡组织。对账文件中会存在交易币种与结算币种。
2）对账文件中每个商户号、每个结算币种会产生不同结算记录。
3）币种金额规则。当交易币种为JPY（日元）、KRW（韩元）时表示元，为其余币种时表示分。
4）明细交易既包括所有正向的收款、付款交易，也包括负向的退款交易。数据说明如下：
正向交易 负向交易
1=A -1=J
2=B -2=K
3=C -3=L
4=D -4=M
5=E -5=N
6=F -6=0
7=G -7=P
8=H -8=Q
9=I -9=R
0={ -0=}
示例1：十进制货币（decimalcurrency），如对于欧元，124.59=12451，代表正向收款交易124.59元；-445.21=4452J，代表负向退款交易445.21元。
示例2：非十进制货币（non-decimalcurrency），如对于日元，16906=0001690F，代表正向收款交易16906日元。
5）每行第33~35位为识别号，通过识别号区分每行数据的意义。
识别号100代表单-商户号的单一结算币种的总结算数据，识别号100字段解释见表1。
表1 识别号100字段表
识别号210代表单一商户号的单一交易币种与结算金额的交易数据，识别号210字段解释见表2。
表2 识别号210字段表
识别号260代表扣款交易明细记录，识别号260字段解释见表3。
表3 识别号260字段表
6）空格也算位数。
经过上述的研究、了解后，再看原来看似天书一般的对账文件就能看懂了。
1）文件名xxxxx59846.EPAPE170808220620。它代表商户59846在交易日期为2017年8月8日的对账单。
2）第一行：表头，用于记录文件生成时间。DFHDR201308071138PANEURPAN-EUROPEEPAFILE，代表2013年8月7日胜成的欧元交易对账单。
3）第2行中，
·第1~10位，950000001，代表商户所属商户号；
·第14~21位，20130808，代表结算日期为2013年8月8日；
·第33~35位，100，代表此商户号欧元结算币种的总结算数据；
·第41~55位，000000000174F，代表正向进款结算金额为1746欧元；
·第71~90位，634010210061，代表结算银行账户；
·第91~105位，000000000180{，代表应结算总额为18.00元，对应币种见323~325位；
·第106~120位，0000000代表手续费为0元，对应币种见323~325位；
·第121~127位，0000000，代表费率为0；
·第323~325位，EUR，代表结算币种为欧元。
4）第3行中，
·第1~10位，90000000，代表商户所属商户号；
·第14~21位，20130808，代表结算日期为2013年8月8日；
·第3~35位，210，代表此商户号交易币种与结算金额的交易数据；
·第41~48位，20130801，代表交易日期为2013年8月1日；
·第64~78位，000000000180{，代表交易金额为18.00元，对应交易币种见238~240位；
·第109~123位，000000000174F，代表结算净额为17.46元，对应币种见238~240位；
·第124~130位，0003000，代表手续费率为3%；
·第238~240位，EUR，代表交易币种为欧元；
·第293~307位，0000000010000{，代表汇率为100%，说明交易币种与结算币种一致。
5）第4行中，
·第1~10位，950000001，代表商户所属商户号；
·第14~21位，20130808，代表结算日期为2013年8月8日；
·第33~35位，260，代表此商户号交易明细记录；
·第41~51位，000000180{，代表交易金额为正向进款18.00元；
·第52~59位，20130731，代表交易日期为2013年7月31日；
·第60~71位，004505，代表银行返回流水号为004505；
·第90~104位，37588****1011，代表该笔交易部分加密后的具体卡号。
正如上面的例子中所说，在清结算工作中，产品经理需要充分理解对账文件含义，清楚定义所需字段，并为开发人员解读，才能尽可能避免对账失误。通过明确对账文件规范和要求、下载对账文件、对账文件解析这三步，我们便能保证成功获取支付通道对账单，落地所需数据，为后续对账做好准备。
