这篇文章里，作者结合实际项目案例，对账户体系、商户管理、交易系统等内容都做了一定阐述，想了解支付系统、对账功能的同学，或许可以来看一下。

本文结合在支付领域工作一年的经验，结合跨境支付公司的实际业务场景和理论知识，系统阐述一笔资金再支付系统的流转过程，并结合实际项目，针对对账模块中的渠道对账和账账对账功能搭建进行详细阐述；供大家学习和参考。

以电商平台为例，常见电商交易平台的支付系统有账户、支付、记账、清算、账务等核心功能。在设计系统功能架构时、要权衡功能范围、关联系统、交易规模等因素，基础系统可以分为“业务、账务、财务”三个角色。

目录

一、账户体系

支付账户是支付机构为客户开立的具有记录客户资金交易及余额功能的点子账簿。账户体系是支付系统的底层基础，账户的类型可以根据用途和会计科目设置。

1. 账户的概念

• 账户：可以类比为一本银行存折；
• 账号：与存折保定大哥银行卡号，是一一对应的关系；
• 用户：账户的归属者，属于账户的个体。
• 账户的基本信息：账户号、账户类型、余额、币种、开户状态、开户时间等。

2. 账户的类型和功能

1）账户类型

支付机构的账户管理，其用户/子商户都有独立的账户。下图中跨境汇款系统中的账户体系关系。系统层面的账户记录客户参与交易的账户余额的增减和账务流水历史，以完成会计记账与具体金额、借记或贷记等，为用户提供资金收、付、管的基础服务。

不同的视角、账户的分类不同；具体分类如下图所示。从业务视角看账户可以理解为用于记录某个主体、某类型资金的余额、以及余额变动明细的数据载体；所以可以理解账户的功能功能为：

• 账户余额：这个账户还剩多少钱；
• 账户流水：这个账户的资金每进每出的详细明细记录；
• 账户交易：账户资金是怎么放进去和怎么取出来的详细记录。

2）账户功能

账户管理功能包括以账户开设、修改、冻结、余额限额设置、受限操作属性设定和账户查询等。账户系统的基本功能主要包括账户管理、账户权限、账户信息管理、配置、支付交易等模块，具体功能如下图所示。

3）账户体系资金流动

在交易体系中、支付机构是按照平台、用户、商户的收款金额进行分账的，实际系统层面的结算是各参与方账户的数字变动。相应银行亲结算过程是在内部完成资金划转、即银行内部以账户为核心的账务操作，改变资金所属权。支付机构账户体系中的资金流动如图所示。

4）账户系统资金流转

账户系统的核心职能在于财务管理。其首要职责包括向上游客户中心提供注册和账户信息查询服务，其中包括银行卡绑卡鉴权、账户余额以及交易流水等查询功能。在接收来自上游订单系统和清结算系统的记账请求时，系统必须遵循规范流程进行入账处理。

另外，当商户发出账户提现请求后，必须通知下游结算系统，以进行审核和资金划拨程序。整个用户、三方支付机构和商户间的资金流转路径如下图所示。

二、商户管理

1. 商户收单及商户层级管理

支付机构在给商家及渠道签约的过程中，与通道建立支付协议及清算规则，适应不同场景订单对应的支付产品、通道、费率等要求。在多商户收单及商户层级管理方面，支付系统要根据商户类型制定入网流程、分账需求、结算周期、费率阶梯、是否可垫资及退款等功能。

入网流程：即商户自助进件过程，在实际业务中登录注册后，走onboard流程进行kyc审核。涵盖商户资料审核与签约，线上入网、建档、授权、企业资料、合同等信息采集与审查。有时，商户入住平台需要缴纳保证金，在商户充值后，平台方冻结该笔资金。

注意：如果平台没有提供商户入网功能，则商户入网需要和支付渠道直接签约，授权平台方代理自身向支付机构发起交易。

2. 商户的资金结算规则

在商户的资金结算规则方面，每笔交易在执行之前，平台已经清晰地确定了参与方的角色。交易的完成状态是通过双方（消费者与商户）之间达成的，以反映交易是否成功完成，同时在财务层面完成了资金同步，资金流水记录则代表了真正的财务记账过程。在每个结算周期结束时，根据资金流水记录以及相关费率因素，计算应当结算的金额。

1）结算费用涉及内容（以金融产品服务为例）

① 根据金融产品收费模式确定结算模式：包括Blend和IC++两种模式。

A. blend模式：Blend收费模式是将不同类型的费用（例如，交易手续费、汇率差异费用、固定服务费等）合并或混合在一起，以创建一个综合费用结构，使费用更加透明和简化。Blend收费模式适用于小型企业或新兴市场，因为它提供了较为简化的费用结构，降低了计算和预测费用的复杂性。

用具体业务场景说明：假设一家电子商务公司在国际市场上销售商品。他们使用Blend收费模式，将不同的费用合并为一个统一的费用。这包括每笔交易的固定费用、一定比例的交易金额作为交易手续费以及根据当天的汇率差异计算的费用。这使得商户和客户能够更容易理解和预测他们的费用，而不必关心不同类型的费用。

B. IC++收费模式：IC++收费模式是一种费用结构，其中商户支付交易的成本，加上支付处理方的固定交易费用。IC++模式通常透明，因为它明确显示了交易的成本，例如银行卡发行方的交换费用和支付处理方的固定费用。适用于大型企业或高交易量企业，因为它提供了更多的费用透明度和控制，适用于那些愿意深入了解和管理其交易费用的企业。

一家在线零售商使用IC++收费模式来处理其跨境支付。当客户使用信用卡付款时，商户支付基于交易的具体成本的交换费，这包括卡协议费用、交换费和清算费。此外，商户支付支付处理方的固定费用，以覆盖服务成本。这种透明的模式允许商户清楚地了解他们支付的费用是多少，并确保交易的可持续性。

2）结算费用的内容和结算规则

① 收单费：指支付收单机构为处理商户的支付交易（通常是信用卡或借记卡交易）所收取的费用。通常包括：固定服务费和其他费用。

• 固定费用：一些支付收单机构可能会收取每月或每年的固定费用，以覆盖其服务成本。
• 交易手续费：针对每笔成功交易，商户通常需要支付一定的费用，这个费用通常是一个百分比，也可能包括最低金额。
• 3ds费用：3ds是一个为了增加支付安全性而设计的协议，需要额外的身份验证步骤，通常涉及到消费者提供密码、验证码或其他验证信息。3DS费用是用于支持和维护3D Secure协议的费用，通常由支付处理方或卡网络收取。
• 争议费：争议费是支付处理方或银行机构向商户收取的费用，用于处理涉及争议的支付交易。争议交易是指消费者或持卡人对一笔交易提出异议，通常是因为他们认为交易存在问题、欺诈或其他争议情况。
• 授权费：指支付处理方或银行机构向商户收取的费用，以获得交易授权。这个费用通常涵盖了交易的实时验证和授权过程，以确保卡账户的有效性和可用性。
• 交易费：交易费是指支付给支付处理方或银行机构的费用，以便处理、促成和结算支付交易。这些费用通常涵盖了交易处理、清算、结算、风险管理和其他相关服务的成本。
• 保证金：指一种在金融和商业交易中使用的款项，以确保合同的履行或满足特定的义务。

注：具体的费用项的费率根据计费规则进行计算。

② 结算周期：影响结算周期的因素有：支付渠道所在国家和结算币种所在国家。

• 支付渠道所在国家为美国时，假设结算周期为T+7（T+7个工作日）；当结算周期中包含美国节假日时，则需要跨过当地的节假日时间再往后数七个工作日；
• 当结算的币种所在地区为香港时，假设结算周期为T+3（T+3个工作日）；当结算周期中包含香港节假日时，则需要跨过当地的节假日时间再往后数3个工作日。

三、交易系统+收银台

1. 交易系统

在电商交易平台的设计中，交易系统的主要职责在于连接业务订单与支付订单，接收上游的业务订单，处理交易请求，负责处理业务逻辑、订单管理、计费等各个方面，并将各种具体的交易类型抽象成下单服务，以完成订单的完整生命周期管理。

订单可以单笔支付，也可以合并支付，对于购物车里有不同商家订单的场景，用户可基于多笔订单发起合并付款。

常见支付订单的几种状态如图所示，交易流水通常不含订单的内容和状态，只关注各个账户的收款额、退款金额、支付类型和时间等信息。

2. 收银台

收银台，即交易系统的前端界面，是为用户在日常支付前选择支付渠道的界面，通过引导路由确定可供选择的支付方式，协助业务平台完成支付交易，以确保用户能够获得一致的支付体验。

支付机构会根据不同终端类型制定不同的收银台，以供外部调用，为业务系统提供收款和付款操作的用户界面，同时接受并转发交易请求，并根据不同场景的特定需求呈现不同的支付选项。收银台的功能与支付渠道管理相关，每个支付渠道都具备各自的支付产品，以满足各种不同场景的需求。

• 用户：支付行为的发起者，可以理解为电商场景下执行购买行为的消费者。
• 商户：收银台的商户或者业务线，可以理解为电商卖家。
• 聚合收银台：提供收付款服务的收银系统。
• 支付渠道：提供支付、清结算能力的三方支付机构。

收银台的业务流程一般分为付款和充值，功能与界面设计取决于业务流程和支持的支付渠道。

收银台的客户体验优化一般分为两种：

1. 商户接入开发及生产维护更便捷：支持多种支付渠道及灵活配置，可自动跳转或在商户界面以实时接口完成支付；
2. 用户操作便捷：需引导用户快捷方便的完成支付。

注意：

• “站内支付”将整个支付页面内嵌到商家网站，使整个下单支付过程在商家网站一个页面完成。
• 常见收银台用户侧异常情况：网络延迟、误录账号、密码错误、限额等，对这些异常要进行友好性提示。

四、支付-清分-结算

• 支付：所有涉及资金转移的行为都可视作支付。
• 清算：清算发生在结算前的预处理环节，等同于“清分+汇算”，是对交易数据依据机构和交易类型进行分类汇总、记账，并计算应结算金额的过程，不涉及债权/债务的转移，是对数据流的处理。
• 结算：结算是资金所有权、债权/债务关系的转移，根据清分结果对交易数据进行净额轧差和提交并完成资金划拨的全过程，分账、扣费、转账等是资金流的动作。

注：清结算属于后台系统，消费者和商户通常不会直接接触，银行与银行之间构成清算关系，银行、商户、支付机构之间构成结算关系。

国内第三方支付只能通过中间清算机构间接互连，不能直连银行，其交易流程如图2-13所示。其中，银联与网联的区别是：银联占据线下市场，覆盖境内、境外、线上、线下的银行卡网络；网联主要处理支付机构发起的、涉及银行账户的网络支付业务与各家银行之间的资金清算，替代此前支付机构与银行多头直连。

1. 跨境支付公司收单业务

收单侧，当跨境电商进入某个新市场时，首先需要解决的就是收单问题，支付机构要帮助商户从境外的客户收钱(Pay-in)，并依据交易单据和分账规则，扣除手续费后打款给商户(Pay-out)。外卡收单的手续费仍保持较高水平，且有本地化资质门槛；境外收单需要提供本地化支付体验与结算方案，只有进一步延伸合作链条，与本地支付互通合作，才能为消费者带来便利。

支付机构主要业务环节及盈利点如下图所示，通道手续费是支付机构稳定的收入来源，可以按照交易规模流水收费或按照支付笔数收费，或将两种方式混合收费，规定比例与上限。

跨境汇款的收费差异较大，分挡付费、有最低收费；跨境收款、收汇整体费率处于下行状态，赚取汇差收益风险较高，合规性不足。现阶段，跨境支付行业的集中度还不高，很难获得费率溢价，快速抢占市场是生存关键，要能尽快获得更多商户，拓展跨境金融等增值收益；作为商户，可能会选择两家以上支付企业进行合作，如此可便于比较。

2. 支付处理+记账

支付行为是账户资金的流转，每笔支付订单对应着一笔甚至多笔指令。

常见支付指令类型包括以下几种。

3. 渠道网关+前置

支付网关具有通信前置、渠道管理和风险控制等功能，这些功能偏向于对外提供，支付处理的逻辑仍在系统后端各环节完成。

业务类型决定选择什么支付渠道，从而促成支付。支付渠道由提供支付受理能力的具体提供方来划分，属于外部系统。支付渠道具有资金转移的多种通道，只有先对接渠道才能支付，如卡组织、直连银行或电子钱包、汇款机构等。

4. 交易对账

随着交易链条的逐渐延伸，数据在多个系统之间的传输过程中，难免会面临丢失或错误的风险。为了保障业务的正常运营，并能够及时侦测问题，有必要确保不同系统之间数据的一致性。对账即为完成相关数据核对或复核的过程，以确保数据的准确性和一致性。

交易对账即核对账簿记录，在系统上体现为逐一核对交易明细数据，以此验证支付过程的准确性。

1）对账内容

对账主要是保证三项数据的一致性：支付订单、支付流水、渠道流水。

这三项是分别是业务系统、支付系统、支付渠道的支付主数据，保证三者的ID关系和状态吻合既保证了支付流程的正确性。而渠道需要保障的渠道流水中的应结金额和实际结算金额的一致性，这个是支付渠道内部对账需要解决的问题。

即对账的内容包括一下几个方面：

业务交易状态核对：当出现支付状态没有被前端接收到，或重复支付、支付失败掉单、金额不等、渠道标识错误等异常情况，使交易状态未实时更新，或各种网络通信、系统交互异常引起异步漏数时，可通过对账直接更新状态。

交易流水对账：一条交易信息可能有多条账务流水信息。下载每个渠道的账单明细，然后按照渠道与交易流水一对一对账，多账、少账的流水根据流水分类进行汇总“挂账”。创建对账批次防止重复对账，正确无误的交易会结合批次生成结算流水或付款文件。

差错处理：差错处理是对账的关键，当发生记录不一致的情况时，差错账记录汇集成“差错数据池。若某个扣款渠道的流水文件存在差错交易，则这个渠道的所有交易都不会生成结算流水文件，等待完成差错处理后，系统再对该渠道的所有交易生成结算流水文件。

资金对账：俗称对银行账，核对支付系统与资金账户发生额的一致性，记账的变动流水与账户资金出入明细进行逐笔勾核。资金对账的本质是支付端交易账户与扣款端渠道账户的一一对照，包括结算划转记录。如果明细及总的金额都无问题，则平账（对账一致）。

五、对账实例

1. 以实际项目来阐述账账对账功能

1）需求背景

财务在进行每月对账时，核对订单状态和支付流水发现有50W元的缺口对不上；财务反馈希望我们将对账功能线上化，通过自动对账筛选出异常的订单并进行差错处理。

2）需求分析

调研市面上关于对账功能设计的参考，考虑一下几点：

① 对账原则：对的是平台订单交易流水和渠道流水的明细；即对明细账或者对总额的核账规则进行对账；包括支付和退款。如果账账对账不能核对匹配，就会对账单中交易的长款、短款进行差错处理。

② 处理渠道侧和交易侧对账的原理：

• 不能多收钱；
• 不能少收钱；
• 不能收错钱。

③ 对账基准：实际中以渠道侧流水为基准；

原因：支付通道侧的付款规则基于其账单记录，不受我方账单平衡与否的影响。为确保资金入账后的账单与资金核对顺利进行，即账证对账和账实对账，我们可在确认对方账单无差错后，将其纳入批次一并处理。

④ 对账的内容：对明细和对总账

• 对明细：是将自身的账单与渠道账单中每一条记录进行核对。在支付中，根据账单订单号或者支付流水号、交易类型、交易金额、交易日期、交易手续费进行比对。
• 对总额：是将自身交易订单与渠道流水的总金额、笔数、订单状态进行核对。在支付中，根据交易日期与结算日期核对总交易金额、交易笔数等，整体金额一致就算对上。

⑤ 对账时间和文件获取：以日切时间为准；每日定时任务读取渠道文件

注：日切时间指的是金融机构或支付系统在每个工作日结束时进行的账户结算和交易清算的时间点。这个时间点标志着一天的交易结束，通常用于计算每日的账户余额、处理交易、清除未完成的交易和准备下一个工作日的交易。

⑥ 文件解析：判断渠道-判断类型-解析文件-转换入库。主要是将下载的对账文件解析成我们可以对账的数据类型并且入库

⑦ 对账结果：对平、长款、短款、金额不一致；

• 对平：交易侧和渠道侧的总金额、订单状态、支付和退款流水明细一致；
• 长款：多收了钱；即通道侧记录多收了钱；公司少收钱——平台无订单或无有效订单；
• 短款：少收了钱；即渠道侧无订单、平台侧有订单——支付平台认为支付成功、实际银行没有收到请求；
• 两边金额不一致：流水明细可以对账，但记录的金额不一致。

⑧ 账对不平的原因：存在差异和瞬时交易与交易系统的交互存在时间差异

A. 长款：平台侧多收钱，渠道侧少收钱；即渠道侧记录20条、平台侧记录19条，多结算了一笔。

出现长款原因：

• 系统掉单；
• 系统BUG；
• 由于瞬时交易和交易系统交互反应时间过长，系统轮询时没有询到导致查找无结果。

解决方式：

1. 平台侧进行补单；
2. 平台侧对所补订单进行退款；由于找零为退还导致金额不一致；
3. 设置一定时间范围定时轮询，超过此时间范围返回还是无结果判定失败，根据具体的对账详情判别是否要进行差异处理。

B. 短款：通道侧记录多收了钱；公司少收钱；即渠道对账生成19条，我方生成20条；

出现短款原因：平台认为成功了，实际上银行并没有收到请求。

解决方式：

• 去调单：需要判断是否为渠道侧的失误；去查看渠道侧的报文，判断是否追回。
• 平台侧发起补偿；即重新联系用户发起扣款或冻结订单。

注：若用户拒绝重新发起支付，会造成掉单；避免此种场景的方式可以免密支付或者快捷交易在支付里不仅能用于改善用户体验、提升支付成功率，也能用于事后代扣、避免资损。

C. 双边金额不一致：账单明细可以对上，但是最终显示的金额不一致。

造成的原因：系统BUG，流水一致但最终总金额轮询时，没有询上。

解决方式：修改金额，且设置轮询机制。

D. 金额和订单状态不一致：流水明细和金额一致，但订单状态未更正。

造成原因：

• 订单状态没有轮询成功；
• 找零金额未退还给用户。

解决方案：找零的钱退还给用户，对于订单状态字段新增轮询机制。

⑨ 差错处理：

1. 修正：上传校验记录；
2. 订正差异状。

3）方案目标

• 对账核对渠道侧支付和退款流水明细、支付与退款总金额与我方支付&退款流水明细、我方支付与退款总金额及订单状态；
• 对账完成后，对有差异问题的订单给予差异处理功能；
• 系统对账后，通过给出的差异原因对系统其他功能进行优化迭代。

① 产品方案

页面信息展示：

A. 信息栏：包含字段业务类型/订单号/订单状态/订单金额/三方支付流水号/三方支付流水总额/实付金额/三方退款流水号/我方退款流水号/累计退款总额/找零金额/差异金额/差异处理状态/操作人/操作时间/管理。

• 找零金额：即用户实付金额-订单金额=找零金额；有找零则显示找零额度，无则显示“—”；
• 找零状态：已找零/未找零；没有找零金额时，则显示为“-”；
• 差异金额：即用户实际付款-累计退款=差异金额；
• 三方支付流水号：由于三方支付流水号＝我方支付流水号，故我方支付流水号不做展示。

B. 搜索栏：业务类型/订单号/三方流水号（三方支付流水/三方退款流水/我方退款流水号）/差异类型/核对时间/差异处理状态。

• 业务类型：参与对账的业务线；
• 订单号：由于是由数字组成，故对字符串/空格等符号不兼容；
• 三方流水号：兼容字符串；
• 差异类型（原因）：选项包括订单状态和金额不一致/三方流水大于我方流水/实付金额和售价不一致/我方流水大于三方流水/累计退款和退款流水不一致/未找零退款；
• 核对时间：自动对账的时间；
• 差异处理状态：已处理/待处理/无差异。

详情页展示：

A. 基本信息详情展示：包括业务类型/顶堤干号/订单金额/实付金额/累计退款/三方支付流水总额/三方退款流水总额/订单状态/差异金额/差异净额净额/找零金额/找零状态/差异id/对账时间/差异处理状态/差异原因

差异原因：对存在差异的订单，系统会给出差异原因，方便工作人员更好的排查。

B. 支付流水信息：包括订单号/三方支付流水号/三方支付流水金额/三方支付方式/我方支付流水号/我方支付流水金额/我方支付方式。

C. 退款流水信息：包括退款订单号/三方退款流水号/三方退款流水金额/三方退款方式/我方退款流水号/我方退款流水金额/我方退款方式。

差异处理：对存在差异的订单进行处理。

1. 根据差异状态筛选出有差异待处理的订单；
2. 在差异处理模块中提交支付流水号（支付上传多个流水号）；支持上传支付/退款凭证；系统原因导致的差异，要求处理差异解决的代码；同时对差异原因进一步说明；
3. 提交到后台系统自动审核。

2. 以实际项目来阐述渠道对账

1）需求背景

目前渠道对账是资金根据渠道侧给的文件脚本生成，为方便资金更快的查看处理对账结果，上线渠道对账功能；同时核对渠道侧和我方交易侧的账单明细后将，渠道对账面板功能将结算金额按照计费规则拆解成费用项展示在面板上方便后续计费。

2）需求分析

目的：是确保所有交易都被正确无误地记录在账户或账单上，获取渠道和交易侧的匹配情况，方便资金处理对账结果，同时对无误的账单明细渠道对账后根据计费规则罗列对账单具体的收费项总的费用。

跨境支付的渠道对账的内容：对的是账单明细和总额，由于wechat和alipay渠道目前只有支付，无退款；所以这两个渠道只对支付明细；对退款不进行对账。

① 对明细：对的是渠道金融机构拿到的报表（明细）和公司数据库里的交易明细对账；最终显示的条目只展示交易侧和渠道侧的明细需要匹配多少条，成功匹配了多少条；未匹配多少条。

对账的条目内容

② 对总额：最终展示在页面上的是无差异账单明细中每个收费项的总额；不同的渠道匹配规则不同。主要展示结算总金额信息、和计费相关的具体收费项金额信息。

3）对账时间和文件获取

① 文件上传模式：由于渠道侧的账单明细无法从数据库直接获取，是渠道那边发给我们的excel文件，因此；我们通过上传文件的形式进行匹配；支持excel\csv文件上传。

② 对账时间：由于负责资金的同事在中国，结合工作习惯以北京时间为准进行对账，每日0点，根据渠道侧的不同的币种，系统自动生成待上传账单的基本表头信息的条目；即根据币种不同显示渠道待上传的条目。

• 考虑提前生成脚本的好处：由于是对账文件是人工上传，系统根据渠道所支持的币种多少，对应生成多少条目；这样根据币种来划分方便后续资金结算；同时避免上传的文件有误；
• 由于负责资金的同事在中国，所以对账时间按照中国时间为准，但公司总部在国外的话结算日期按照总部所在国家为准，即当结算周期遇到节假日时，按照国外的节假日为准。

4）文件解析

• 北京时间0点系统按照渠道的结算币种数量生成对应的渠道对账条目，次日资金上传从渠道那边获取的excel文件，通过人工上传进行对账；
• 由于渠道侧的文件来源于不同渠道方给的excel文件；文件取名或内容格式不一，因此该功能对上传的文件名格式不做限定；但是文件中字段的内容需要和渠道方核实，做格式兼容处理；

上传完成后系统自动解析，解析完成后对应以下几点：

① 当解析成功时，弹出弹窗【解析成功，是否开始对账】；

② 当解析失败时，有几点原因导致：

1. 上传文件内容格式有误——找渠道侧确认文件内容；
2. 上传的文件内容重复——需要把历史上传的文件删除后才能二次上传；
3. 网络加载错误。

5）对账匹配规则

① 交易侧的匹配账单以当天账单的post_time字段为准进行匹配

比如10.17号获取账单、其账单内的post_time记录的是5.10号，则对应在系统中生成的条目是匹配时间是5.10号；开始对账时间是10.17号。

② 渠道侧和商户侧的账单明细按照PI号进行匹配

“PI号”是指付款信息号码（Payment Instruction Number），通常用于跟踪和匹配交易。PI号的达标意味着PI号字段的信息是准确、一致和完整的，这使得渠道侧和交易侧的账单能够按照PI号进行匹配。

③ 币种和对账条目一一对应

由于渠道涉及多币种；考虑到不同币种汇率差异会导致对账金额不一致；随意不同渠道的对账条目按照币种划分；即以wechat为例，涉及到结算币种由GBP、HK和USD；即0点时系统准备拉取交易对账脚本，按照币种数量生成对应的条目，当天资金上传渠道侧文件时，同一份文件按照币种不同上传三次，每一次只解析和对账币种所对应的账单。

6）对账结果

① 匹配无差异：平账；无需处理。

② 匹配有差异：对账金额不一致即交易或渠道的某一侧少钱。

由于具体的收费项是根据计费规则确定的；影响最终收费项金额的因素由：费率、汇率、费用计算公式，结算金额、和系统等因素组成。

A. 时间差导致：由于不同地区和国家之间的时差和时区差异，会导致交易日期和时间的不匹配。

解决方案：对上传的渠道侧的数据，该日未对平的数据在数据库中回溯七天；并在差异处理中记录该条数据，如果七天内对平了该数据最终，则差异处理中该条数据自动删除；如果七天后仍未对平，则系统不再回溯，差异处理功能中仍会显示该条信息，对账结果显示有差异；状态显示待处理。

B. 通信问题：由于渠道对账涉及多个系统和平台之间的数据传输，会存在通信问题，可能导致交易数据未能正确传递或同步，从而引起不平账。

解决方案同上。

C. 汇率差异：在跨境支付中，涉及不同货币的交易可能会受到汇率波动的影响。如果汇率不一致或不准确地应用于交易，可能会导致金额不匹配，从而引起不平账。

上线汇率面板功能，将汇率和计费系统联动；汇率面板中的数据每日从从中国银行和海云汇中直接拉取。当发掘拉去的汇率不合适时，支持人工修改。

7）对账完成后的结果处理

对账完成后，会在【对账笔数】字段中显示匹配结果，即交易侧和渠道侧的各自明细要匹配多少条；在【匹配结果】字段中显示成功匹配了多少条；有差异的有多少条；需要回溯的有多少条。

注：需要回溯的数据是指渠道侧或交易侧某一侧有这条数据；另一侧没有获取。

• 由于对账时间是以的post_time时间为准；获取的是post_time当天的渠道侧账单明细数据；当对账完成后，功能页面显示改天各收费项明细的总金额；方便内部人员知道公司在渠道这边计费相关的财务状况；
• 对账完成后，支持系统对渠道侧和交易侧对账结果账单的下载；同时系统会把对账结果的excel文件自动推送的到通知群里，文件包括渠道侧、交易侧的对账结果明细以及差异处理的文件。

注意：下载的文件中除了包括原始的账单明细外，还要加上对账的匹配结果字段，以及对需要回溯的数据，后面加上回溯天数。

差异处理：对账完成后，对有差异的账单明细系统推送给到差异处理功能中；去处理差异；同时也会生成excel文件自动发送到通知群里；提醒工作人员去处理。

• 对由于时间差异导致交易侧数据未录入，需要等待回溯的订单，回溯完成后渠道自动对账，对平后，差异处理面板中该条数据系统自动删除，如未对平则保留该条；等待差异处理。
• 差异处理面板中的数据处理完成后，数据重新进入对账流程和交易侧数据进行对账，直到账单对平为止。进入对账流程还是以该渠道的post_time时间为准。

8）下载与推送文件格式

• 渠道侧的文件命名：渠道名_matched_report_年_月_日
• 交易侧的文件命名：渠道名_Merchant_matched_report_年_月_日
• 差异明细的文件命名：渠道名_差异明细_年_月_日

产品方案：

渠道对账涉及到的渠道：不同渠道匹配规则不同，现以wechat和Alipay+渠道为例。

页面信息展示：

A. 信息栏

① 渠道：可选择wechat 和Alipay+

② 结算币种：来源于渠道侧给到的结算币种，我方从账单报表中进行提取可得：

• Wechat结算币种对应GBP/USD/EUR
• Alipay的结算币种对应HKD/GBP/USD/EUR

③ 交易币种：客户通常使用其本地货币（交易币种）进行支付，但商家或供应商可能需要以另一种货币（结算币种）来收款。

• Wechat交易币种有CNY/GBP
• Alipay+交易货币有CNY/GBP

注：即根据前面【对账时间】中关于对账条目获取的规则描述，可知，在次日0点时，系统根据渠道对应币种数量自动生成对应的条目；每一个条目需要上传一次渠道对账文件；待此时工作时间资金上传渠道报表，按照比重条目生成对应的对账结果数据。

④ 时间：由于渠道侧和交易侧的对账是根据匹配对应时间进行对账，所以时间按照匹配对应时间获取相应的条目

⑤ 账单解析状态：解析成功&解析中&解析失败

⑥ 账单笔数：分别显示渠道侧和交易侧对账文件中各自有多少条目；即显示渠道侧：200条；交易侧：200条

⑥对账结果：显示：对平：XX条；待回溯：XX条；差异处理：XX条

待回溯指的是交易侧由于汇率时间差或其他原因还没有接收到对应的账单条目；需要等待一段时间才会显示。

⑦ 渠道侧总额：由于匹配的账单明细都是同一天，故渠道侧总额等于当天渠道侧账单明细的所有条目交易总额；同理交易侧总额等于交易侧账单明细所有条目的交易总额=tran_amount字段之和

⑧ 文件上传时间：为资金开始操作对账时间；

⑨ 操作人：操作对账对应的工作人员名称

⑩ 管理：详情/差异处理/下载账单/重新解析/删除

• 详情：由于渠道除了为将账对平，方便资金人员了解财务状况及后续审计外，对公司侧我们该环节的目的是将公司渠道计费涉及到的费用项提出，方便老板了解渠道侧财务状况；故详情中重点罗列
• 差异处理：同一匹配对应时间下，同一渠道下上传渠道文件后，按照渠道下币种数量生成条目，对应币种下有差异的账单明细进行差异处理；
• 下载账单：对账完成后，支持下载对账后的渠道账单和交易账单 i 下载的渠道账单和交易账单在原文件的基础上新增对账结果字段以及回溯天数字段（需要回溯的显示回溯天数，不需要的显示—）
• 重新解析：由于网络加载错误等原因导致需要重新上传解析的，可以点击重新解析按钮，避免二次上传文件；
• 删除：资金会出现对同一天的渠道文件进行二次上传的场景，二次上传时必须把前一条上传的文件数据删除，才能二次上传；

B. 搜索栏

① 页面信息展示：页面一开始展示所有渠道的数据，按照渠道名称首字母和匹配对应时间两个条件倒叙配列；

② 渠道：支持Wechat 和Alipay+搜索；

③ 结算币种：包括HKD/GBP/USD/EUR；

④ 时间：选择时间后对应【匹配对应时间】字段的的检索结果。

每日0点系统按照渠道对应货币拉取条目：

比如wechat渠道，对应结算货币有GBP/USD/EUR，即系统自动拉取三个条目。

上传解析：

上传渠道文件后解析过程提示分为解析成功和解析失败。

① 解析成功：上传—上传中—正在解析—解析成功并判断是否开始对账—开始对账—对账成功/对账失败。

• 对账成功后，即可在对应条目上显示计费信息；同时需要差异处理的账单条目显示在差异处理模块中；
• 对账失败后，请重新上传；——解析结果栏中显示解析失败。

② 解析失败：上传—上传中—正在解析—解析失败；

• 解析失败，请重新上传；
• 网络加载超时，解析失败请重新上传；
• 文件内容格式错误，解析失败请重新上传。

对账完成后页面展示的信息如上图所示。

详情：

详情中主要展示计费相关的信息条目；主要包括：

① 对账信息：渠道名称/匹配对应时间/结算币种/文件上传时间/账单笔数/对账结果

② 渠道侧账单明细：即展示post_time当天从渠道侧获取的账单中计费项的总金额，包括Total Settlement Amount/Total Acq_fee/Total Ic_fee/Total Scheme_fee/Total Other_fee/Total 3ds_fee/Total Settlement net Amount；

③ 交易侧账单明细：即展示post_time当天交易侧（即公司数据库中）获取的账单中计费项的总金额，包括Total Settlement Amount/Total Acq_fee/Total Ic_fee/Total Scheme_fee/Total Other_fee/Total 3ds_fee/Total Settlement net Amount；

④ 具体的费用项根据计费规则系统进行计算

部分渠道相关费用项，渠道侧会算好给我们；有的渠道需要我们自己按照计费规则，系统进行计算。

差异处理：

差异处理页面展示信息：

① 信息栏：展示字段包括渠道名称/匹配对应时间/订单号/未匹配天数/订单金额/渠道流水总金额/交易流水总金额/差异处理状态/操作时间/差异原因/操作人/管理。

订单号：用于标识商户或支付发起方系统中特定订单或交易的唯一标识符。

注：如何根据订单号追踪PI号：

获取订单号和相关支付信息：首先，您需要获取包含订单号的商户或支付发起方的相关交易信息。这可能是从您的系统中提取订单号，或者从商户或客户提供的相关信息中获取。

查找相关支付交易：使用订单号，您可以联系相关的支付渠道或银行来查找与该订单号相关的支付交易。这通常涉及与支付渠道或银行的客户支持或运营团队进行联系。

确认PI号：一旦找到相关支付交易，您可以请求支付渠道或银行提供与订单号相关的PI号。PI号通常可以在他们的支付指令或结算文件中找到。它是用于跟踪国际支付和结算的重要标识符。

进行对账或差异处理：一旦获得了PI号，您可以将其用于对账或差异处理。通过将订单号与相关PI号关联，您可以验证支付是否已经成功处理，或者解决可能存在的不匹配或差异。

• 未匹配天数：由于交易侧数据获取滞后导致部分数据未匹配，故允许在数据库中回溯7天；当回溯时间为第四天匹配成功时，未匹配天数＝4；
• 订单金额：即交易金额；
• 渠道结算净额：由于该渠道只对支付，不含退款；且仅对订单状态处于成功时的订单进行对账；所以渠道结算净额=结算金额-手续费
• 交易结算净额：交易结算净额=结算金额-手续费；
• 差异处理状态：已处理、待处理和处理中；
• 操作时间：等于差异处理时间；
• 差异原因：差异取决于交易侧金额、渠道侧金额于订单金额不一致和订单状态；故差异原因包括：交易侧金额与订单金额不一致/渠道侧金额与订单金额不一致/金额与订单状态不一致/渠道侧与交易侧金额不一致/汇率差异/交易侧无数据；
• 管理：【差异处理】按钮提交证据进行差异处理。

差异处理功能：

• 订单号：自动获取；
• 上传凭证：支持上传原始交易记录/三方支付渠道或银行记录/我方订单和交易记录/汇率信息/手续费信息等截图；要求上传JPG//PNG/JPEG格式，文件不超过20M；
• 差异处理记录日志：上传差异处理过程的操作日志/处理代码等；
• 差异原因：系统自动给出的原因有交易侧金额与订单金额不一致/渠道侧金额与订单金额不一致/金额与订单状态不一致/渠道侧与交易侧金额不一致/汇率差异/交易侧无数据；该字段需要在系统给定的基础上加以补充。

注：差异处理中的数据包括：渠道侧和交易侧确实存在差异（即账没有对平）和交易侧数据由于时间差未及时获取而无法和渠道侧匹配对账造成的差异。

① 渠道侧和交易侧确实存在差异：给出差异原因并进一步追溯解决；

• 金额导致的差异：修改金额并提交支付凭证截图；
• 系统导致的差异：迭代BUG后，提交差异处理证明；
• 汇率导致的差异：系统目前是每日线上从官方渠道拉取汇率值，若汇率不是想要的数值，后期支持手动修改，修正汇率。

② 时间差未及时获取而无法和渠道侧匹配对账造成的差异：系统预留出7天的回溯时间，七天内如果该明细和交易侧对平了，则差异处理中该条记录自动删除，同时渠道对账中的相关费用随着也要变化——具体根据匹配的PI号和匹配时间确定对应条目。

下载：支持下载渠道侧和交易侧的对账结果明细。

对账完成后，下载按钮由置灰状态变成可点击状态；同时选择想要下载的账单（支持多选）。

对账成功后，除了页面支持下载外，系统自动将交易和渠道侧的对账单明细以及差异明细文件发送到通知群中。

下载与发送：

• 渠道侧的文件命名：渠道名_matched_report_年_月_日
• 交易侧的文件命名：渠道名_Merchant_matched_report_年_月_日
• 差异明细的文件命名：渠道名_差异明细_年_月_日

总结复盘：

① 明确目标—明确对账业务逻辑和计费数据逻辑后：最后进行功能设计。

② 目标拆解：

A. 确保渠道提供商提供的账单与实际交易记录一致：

• 渠道侧账单明细和交易侧账单明细具体涉及的金额由哪些，进行对账；
• 跨境国际对账需要考虑币种问题，不同的结算币种对应的汇率不同，最终的结算金额也不同；
• 如何展示最终对账结果——遵从交互逻辑简单，清晰展示涉及到的信息。

B. 跟踪和解决渠道侧和交易侧之间的不平账或差异，并解决：

• 差异处理：展示差异和设计差异处理功能；
• 搞清楚造成差异的原因：多收钱/少收钱/订单状态和金额不一致/两边金额不一致。

③ 对账方法归纳总结为：

3. 清结算

清分：在清分阶段，资金与账单的计算和核对是核心任务。这一过程涉及对资金流动的准确计算，以及核实账单的一致性。清分确保了在交易中的所有各方都得到了应有的款项，而且交易记录得到了妥善处理。上述实际对账案例就是清分的内容。

结算：结算阶段是在清分后进行的，它涉及资产的实际转移和完成交割。结算根据事先约定的结算方式和结算周期，将资金划拨给涉及的各方，如商户、用户和支付通道。这一步骤确保了资金的真正转移和归属。

结算规则：

① 影响结算周期的因素有：

• 商户进行结算时所在的国家；
• 结算币种所在国家。