支付系统设计涉及金融、电子商务、互联网产品管理等方面的知识，不同行业需要学习的侧重点有所区别。在支付系统很多人都有记账的习惯，但是记到后面却发现自己的帐算不清楚，记账不能只靠着单方面的账单，还要进行对账才能确保无误；本文将会从产品设计的业务知识点出发，详细介绍对账业务流程，并列举会出现的常见问题和解决方法。
业务背景：
对账模块是支付系统的核心能力之一，是信息流和资金流关联的重要依据，平台如果只使用渠道的单边账单或者平台流水订单，出现差错或渠道恶意扣单的风险极高。
为提高资金账务的正确性和保障平台的利益，需要通过平台系统对账能力与上游渠道对账单逐笔勾兑确认，如有差异能及时解决或归档。
用户画像：
1）清结算专员：负责发起清分的操作者，首先确保信息流对平，然后确认资金流应收款和信息流平账账单金额一致。希望能及时发现长短款问题，并解决，保障资金清算给商户（平台可收款用户）的时效性。
2）对账异常订单处理专员：负责核算异常订单原因，并在平台操作将异常订单执行修正、平账。
一、必须知道的业务知识点
1. 对账
在会计上概念：指为了保证账簿记录的正确性而进行的有关账项的核对工作；做到账证相符、账账相符、账实相符。
在支付系统上的体现：
1）账证核对：是将账簿记录与记账凭证进行核对。这里是记账凭证是指第三方上游提供的渠道对账单，第三方渠道会根据对账单金额实际结算资金，也就是常说的信息流对账。（有的支付公司或银行只要收到对账单了且平账，即使资金未实际到账，业务也允许发起清分以提高清算时效性）
2）账账核对：是把有相互关系的多个账簿记录进行核对，有相互关系的账簿记录，包括总分类账簿间核对，明细账簿间核对等多种类型。整个支付系统可以被拆分成了多个子系统，如交易系统、账户系统、会计系统、账户系统，每个子系统在处理各自的业务并记录，其实就相当于会记理论中的账簿。系统间的对账，主要用于修正内部系统的数据不一致。
3）账实核对：是各项资产物资的记录数值与实际真实数额间的核对。确认第三方汇款到银行账户资金和平账对账单结算金额是否匹配，也就是常说的资金流对账。
2. 轧帐
对账系统主要做的是信息流的对账，若对账中发现有差异的订单归类记入对账异常订单表，可称为轧帐。
3. 平帐
对账异常订单进入差错流程，可以通过人工或者自动的方式，按照事先设计好的规则处理这些异常差错，可称为平帐。
4、渠道对账单
上游渠道会按照平台在其申请的渠道账户维度推送对账单，渠道账户也就是常说的支付通道。
如果是第三方支付公司或银行，上游渠道是微信、支付宝、银联二维码（云闪付）等等。例如：支付平台申请有微信2通道和微信6通道，则微信侧会生成2份对账单文件。
每份对账单会包括支付成功订单和退款成功订单。第三方会以对账单中的结算金额（支付订单金额-支付订单手续费）-（退款订单金额-退款订单手续费）结算汇款给到平台资金账户。
5、银联二维码（难点）
银联二维码是银联平台自主推出的支付产品，C端使用云闪付、各手机银行APP支付，订单底层走的都是银联二维码通道。
为什么银联二维码需要重点说呢？
因为它不同于微信、支付宝通道统一费率的原则，银联会根据C端用户支付时使用的银行卡借贷性质和交易金额是否大于1000作为费率规则，并且还会收取额外的品牌服务费，详情参见下图。
所以设计银联二维码通道对账时，还需考虑到多费率及品牌服务费的场景。
二、对账流程
1. 业务流程
对账业务可以插解为5个业务环节，本文主要说明每个环节的能力职责、常见问题和通用解决方法，具体的产品方案还需要结合读者平台自身的业务特点和系统架构设计。
三、对账任务
对账是一个日常操作，正常情况下上游渠道都会以D+1的周期生成渠道对账单。
每天系统可以默认生成定时对账任务，每个上游渠道生成时间不一样，可以事前和上游确认，并结合平台对账的处理时效和商户到账需求，设计一个合理的时间执行。
对账任务设计前需确认，渠道对账单推送方式、解析方法、匹配字段，并提前做好联调适配工作；例如渠道有可能会需要申请白名单权限或提供SFTP地址信息，要谨防上线后才发现系统无法正常获取对账单的情况。
1. 创建任务批次
创建批次一方面是为了防止重复对账，另一方面需要在对账结束的时候将对账的结果信息存储到批次中。
2. 记录任务信息
对账任务信息，例如：通道名称、通道编号、渠道商户号、对账任务批次、对账任务状态、交易时间、任务创建时间、下载开始时间、下载结束时间、下载状态、对账开始时间、对账结束时间、对账结果、对账方式；
对账方式为对账处理时的对账规则，可以根据业务实际情况分为：无需对账、以渠道为准、以平台为准。
- 以渠道为准，则若对账订单平台交易状态为支付中或支付失败，但渠道为支付成功，则平台状态改为支付成功。
- 以平台为准，则是若出现上述情况，对账订单记录为异常订单。
3. 重置任务机制
考虑到对账过程中可能会遇到的来自上游渠道的问题或平台系统自身问题，需要设计重置机制。
上游渠道对账单错误，需求二次或多次推送，所以需要设计重新下载渠道对账单或重新上传渠道对账单；有可能平台自身数据错误导致出现大量的差异订单，修复后需要重新对账。
4. 对账任务详情示例
- 对账信息：记录对账任务基本情况；
- 对账结果信息：显示关键对账字段值；
- 挂销账信息：显示是否有挂销账订单及金额；
- 对账异常信息：显示是否有对账异常订单及金额；
- 备注：将系统自动处理的过程记录，也可以手动修改。
四、对账单下载
1. 获取文件
渠道对账单获取方式，一般提前作为任务规则写死。
大多数银行都要求接入方提供ftp服务，银行定时将对账单推送到接入方提供的ftp服务器上面；
还有一部分银行会提供对账单的下载服务，通过ftp/http的都有，ftp方式居多；
另外网银的对账单比较特殊，一般都需要结算登录网银的后台管理系统中，手动下载，结算下载完对账单后在导入到对账系统。
2. 判断文件是否存在
任务自动获取文件的情况下需要判断任务是否存在：
自动获取渠道对账单：不存在需要设置轮询，每间隔一段时间重新获取。重试次数和间隔的设置需要小心，重试太频繁，容易把服务器打死.；时间间隔太大，又会阻塞后续处理步骤。5～10分钟是一个合适的重试间隔区间。
手动导入渠道对账单：要设计导入入口，导入成功后任务状态也要做相应的变更。
3. 下载文件
技术实现上可以做成工厂模式，不同的支付渠道有不同的下载类，如果是http接口将文件写入到对账单，如果是ftp服务器，将服务器中的对账单下载到本地带解析的目录中。主要涉及的代码ftp工具类、http(s)工具类，相关IO读写。
4. 判断来源渠道
获取到上游对账单文件后，很有可能多个渠道的对账单在同一个SFTP地址，根据文件名匹配到对应的对账任务，文件名一般会包含账单时间、渠道商户号，然后再执行下一步。
五、文件解析
1. 解析文件
解析文件主要是将下载的对账文件解析成我们可以对账的数据类型并且入库。
解析的文件不同渠道有不同的类型，因此也可以设计成不同的解析模板，使用工厂模式将不同格式的文件解析成可以对账的统一数据类型。
解析的文件类型一般包括：json、text、cvs、excle等，另外部分银行会对账单做加密或者提供zip打包的格式，这里就需要额外开发zip工具类和加解密工具类进行处理。
对账文件中包含的主要信息有：商户订单号、交易流水号、交易时间、支付时间、付款方、交易金额、交易类型、交易状态这些字段。
2. 转换入库
每个渠道的账单格式都不尽相同， 在得到账单后，下一步是对账单做标准化处理，这样轧帐以及后续工作就可以统一处理了。
标准化后的账单数据可以放在文件系统或者数据库中，这取决于交易数据量；每天百万以上的量，还是使用文件系统，比较合适，数据库操作相对比较慢，也浪费资源。
基于文件系统的标准化涉及如下内容:
- 文件格式标准化统一使用csv或者json或者xml格式，如果是使用hadoop或者spark来对账，也可以使用csv。
- 文件存储统一化文件目录，文件名都需要遵循统一命名规范。
六、对账单处理
1. 获取对方对账单
将事前准备的上游对账单标准文件放入缓冲对账池。
2. 获取我方对账单
本地交易记录的准备，总的来说有如下方法:
啥都不做，直接用订单表的原始数据：鉴于大部分系统使用的是MySQL，这也意味着在MySQL上做对账。对账时需要大量的数据查找工作，必然会影响线上业务。在数据规模较大，比如超过100万时，就不太合适了。
使用备库来执行对账：这样既简单，也不影响线上业务，这是典型的空间换时间的做法。
采用分表分库对账：如果业务大到需要分表分库才能处理，那对账数据准备也不一样。
3. 逐一匹配
前文有提到对账方式有三种，不对账、以渠道为准、以平台为准，大部分的情况下的对账方式都以渠道为准，信息流的传递方向，支付成功结果是由上游渠道通知平台的，平台很有可能会因网络或系统问题而没有收到通知。
一般按照交易金额、交易状态、手续费金额逐一匹配，对账方式选择以渠道为准的处理逻辑为例：
1）交易金额不匹配：记入异常订单。
2）交易状态不匹配：若上游为支付成功，我方为未支付或支付失败，则以上游为准。
- 若我方订单为支付成功，上游只会推送支付成功的订单为对账单，上游对账单不存在的情况，将我方订单记入为挂账订单；
- 若上游对账单存在，我方不存在的情况，记入异常订单。
3）手续费金额不匹配：记入异常订单。
4. 挂销账处理
常会存在因日切时间点不一致或网络延时等情况，导致我方平台订单时间与上游渠道时间不一致，同一个订单在渠道交易时间是1月1号，但在平台是1月2号。
- 挂账，对账时若上游无我方有，订单放入挂账订单中。
- 销账，若匹配中挂账订单匹配上了，记录为当日平台账单，挂销账状态改为已销账。
七、差错处理
关于差错流程，每个系统的业务特性、运营团队流程、公司财务管理办法不一样，不能生搬硬套，但原则是一样的，所有的异常订单的报销账必须有理有据，多重审核。
1. 异常原因
（1）若出现订单金额不一致的情况，一般是平台调用上游交易接口时，双方字段的定义不匹配导致的。
（2）若出现手续费金额不一致的情况，一般是平台手续费计算规则和上游不匹配导致的，差额不会太大，可以设计阀值若在可以接受的范围类不计为异常。
（3）若出现上游对账单存在，平台订单不存在的情况，通常是有第三方绕过平台系统与上游系统发生支付或退款交易。需要及时核查是否存在交易密钥泄露或被绕过商户去上游系统平台操作。
2. 修正
选择以平台为准或以上游为准，修改订单金额、订单状态、手续费金额。此时写入修正原因很重要，便于后期业务追踪考求。
3. 平账
将平台异常订单状态改为平账，并将平账时的时间作为账单时间，合入至平台账单。平台会根据平台账单计算渠道分润金额和商户结算金额。
八、业务规则系统化
最后，每个平台产品细节都会有其特定的业务规则，就不具体说明平台页面和和平台操作功能，笔者不做详情说明。以上业务规则系统化，系统流程图如下，读者可以结合自己平台业务情况提取细化。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>在上期文章关于异步处理在支付环节的思考，笔者跟大家介绍了支付环节的一般流程。支付业务的关键在于入金，即把资金从消费者的银行卡转入第三方支付机构的备付金账户，然后在虚拟户上实现资金的流转，从而实现订单的支付。
其实充值操作也是典型的入金业务，主流程跟支付差别不大，只不过是少了订单付款环节，金额直接进入用户的钱包。
本篇文章笔者会跟介绍与入金恰好相反的业务流程，即出金，典型的业务形态就是提现。
我们都肯定使用过微信、支付宝或者电商平台的提现功能，用户在前端的感知就是发起提现申请，然后等待银行卡到账，关于到账时间，不同的平台也是有差异，有的几分钟，有的几个小时，有的甚至大于1天。
到账时效有差异主要是支付平台的出金处理流程、央行的清算系统决定的，接下来笔者跟大家介绍提现的业务流程。
什么是提现？
提现是跟支付是完全相反的业务流程，用户基于自己的账户余额发起提现申请。在信息流上体现为用户的虚拟账户资金扣减，在资金流上体现为资金从备付金账户转入到用户绑定的银行卡账户的过程。一般电商平台涉及到场景为C端用户的钱包账户余额提现和B端用户收益账户的余额提现。
提现的核心流程如下（以电商平台为例）：
电商侧处理
用户主动发起提现申请，电商平台内部根据实际业务做好风控，确认无误后根据提现金额、费率、时效性等因素选择最优化的出金渠道，向渠道侧提交出金指令。
因为有些电商平台会同时对接多个支付渠道，包括第三方支付平台、银行存管系统、银联等，所以在出金之前，需要有相关的规则来判断哪个是最优的渠道，简称渠道路由。当然，有些平台走的是人工处理。
渠道侧处理
电商平台提交的提现申请成功到达渠道侧后，会按照自己的业务逻辑进行风控与出金处理。
需要特别说明，不同的支付平台、银行存管、其他支付机构，在出金环节的处理规则可能有所差异。
以笔者对接的第三方支付平台为例，它并不是单笔实时处理，而是根据固定的时间批次，把所有的交易打包并做批量审核与处理。一般工作日下午4点半之前提交的提现申请，当天就能做出金处理并到账，超过4点半提交提现申请，则需要此日才能做结算出金。而如果是非法定工作日提交的提现申请（因为人家非工作日不上班），则需要延迟到下个工作日处理。
清算机构处理
第三方支付平台或者银行存管系统等提交的出金指令，最终会通过行内清算系统或者央行的跨行清算系统完成资金从备付金账户到用户银行卡账户的划拨。
在这里需要注意的是，有些平台表面走的银联的通道，但是银联最终还是得调用央行的清算系统，这是属于支付领域最底层的系统，任何渠道都无法绕过央行的清算系统独自完成清算工作，这也是不被允许的。
跨行清算系统包括大额系统、小额系统以及超级网银系统，这三个系统在金额限制、运行时间段等方面都有差异。
综上，用户发起一笔提现申请，资金什么时候到达用户的银行卡，主要取决于两点：第一、渠道侧什么处理这笔交易，执行出金指令。第二、渠道侧选择的出金通道，走的是大额系统、小额系统还是超级网银系统，都会影响资金的到账时效。
回想一下，有时候我们在某些平台进行提现的时候，是不是都一段提示文案或者在帮助文档上写着，类似“提现申请已提交，具体到账时间以银行通知为准”。
行内清算系统与跨行清算系统
行内清算系统：是各个银行内部的清算系统，同行业务通过它处理。一般金额不受限，7*24小时受理，实时到账。
跨行清算系统：主要提供商业银行之间跨行的支付清算服务，是为商业银行之间和商业银行与中国人民银行之间的支付业务提供最终资金清算的系统。
最开始央行的CNAPS一代系统包括，大额支付系统与小额支付系统。
2013年，央行的CNAPS二代系统投产运行，其中就包括超级网银系统，是对大小额支付系统的一个补充。
提现业务流程与系统交互说明
提现业务流程简单泳道图
01、步骤一：用户发起提现
用户在电商平台填写金额，申请提现。一般要求遵循同名出金原则，即用户需要提前绑定与实名认证信息一致的银行卡。有些平台会限制最低提现金额，如果提现需要收费，那么电商平台还需要在这个环节计算出对应的手续费，前置要求是提现金额+手续费≤可用余额。
关于手续费的扣除，一般有两种处理方式：第一种，直接在用户填写的提现金额基础上扣除，即用户提现100元，扣除1元的手续费，最终到账99元。第二种，额外在用户的钱包余额扣除，即用户提现100元，实际到账100元，并额外从钱包余额扣除1元，用户最终的钱包余额最终支出101元。
02、电商平台处理提现申请
电商平台接收到用户提交的提现申请后，需要进行一系列的校验规则，包括是否完成银行卡的绑定、账户余额的查询、手续费的计算，然后再提交出金支付订单给到渠道侧(第三方支付平台、银行存管等)。
渠道侧会同步返回受理结果，并从用户的虚拟户中预先扣除相应的金额。但是具体提现结果需要电商平台主动查询或者异步回调。
如果状态为交易成功，即证明渠道侧已经成功将出金指令下发到央行清算系统了，如果状态为交易失败，即证明本次出金失败，需要退回资金到用户的账户余额。失败的原因一般是因为银行卡出现异常了，但是这种情况比较少。
03、渠道侧出金处理
渠道侧（第三方支付平台、银行存管）接收到电商平台提交的出金请求后，处理流程可能有所差异，比如笔者对接的第三方支付平台采用的批量审核并且仅在工作日执行出金操作，包括9点30、11点30、14点30、16点30，所以用户在工作日提交的出金申请，最快可能几分钟可以到账，最慢得需要十几个小时。
而笔者对接的银行存管系统，由于是平台与银行直连，在出金上是采用逐笔实时处理的方式执行出金操作，电商平台可以提前设定规则，规则要素主要包括提现金额、提现发起日期与时间、手续费，最终决定采用大额、小额还是超级网银，基本实现了7*24出金服务，在用户体验上跟我们平常使用的银行转账差不多。
04、银行清算系统处理
支付平台把出金指令提交给网联、银联等清算机构，最终通过行内或者跨行清算系统完成资金的划拨。
提现流程的产品设计
提现流程的用户前端界面没有很复杂的地方，基本上各个平台都大同小异，正常有差异的地方在于提现发起后状态流转过程，由于平台背后对接的支付机构不尽相同，出金规则也有差异，所以要根据真实业务逻辑展开设计，当你去体验一个产品的提现流程的时候，看到的只是表面，其背后的资金处理流程、规则才是关键。
关于提现流程的到账成功标志，这个视支付平台的返回为准，因为大额支付系统与超级网银系统都是实时结算的，所以第三方支付平台的结算成功时间可以视为到账成功的标志。但是如果使用的是小额系统，因为是非实时结算的，所以实际到账的时间可能还会比支付平台返回的结算成功时间会晚些。如果担心给用户带来困扰，也可以把到账成功的文案改为提现成功。不管怎么样，资金的最终是否到账，都要以用户的银行收入流水为准。
关于提现要避免的一个坑
在前面有提到，有些支付平台是同步通知提现受理成功的，但是不代表提现已经成功到账了，如果电商平台的产品经理把这个当成是提现成功的标识，并在前端界面显示提现成功或者到账成功，那么会给用户带来困惑，为什么还没到账，这时候客服就比较忙了。而且还不排除后续支付平台结算出金失败，电商平台需要告知用户提现失败，前面显示提现成功，后面又显示提现失败，用户体验就不太好。
写在最后
关于提现流程，本文就介绍在这里了。做支付的，一定要对资金流跟信息流有清楚的认知，同时也要知道电商系统与支付系统、银行清算系统之间的交互是怎么样的，只有这样，我们才能将业务流程转化为便于用户操作的前端界面，同时处理好复杂的后端业务。
免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！
]]>