本文中描述的和解是非金融机构中的对帐情况。它适用于公司自发和购买的电子商务系统。在这种情况下，该平台背后的付款渠道可以连接到微信，支付宝或其他第三方聚合支付公司。

1。付款系统摘要

在下面显示的系统中，和解的目的是确保以下等式为真：

客户支付的钱 - 支付渠道处理费=要解决的付款

由于不同的定居周期或其他操作因素，一些渠道需要处理费用。在这种情况下：和解支付费用=收据金额。

在完整的电子商务交易平台中，还将涉及折扣，积分赎回，全额折扣和余额之类的付款方案，并将多家商人汇总以支付。这种情况将使新来者陷入淡人。

上述两种情况的逻辑不应由付款系统（付款模块）处理，而应由交易模块的订单管理处理。

付款系统仅关注实际付款金额的处理，订单的订单金额，折扣等不是付款系统所关心的。在复杂的电子商务系统（，，）中，交易模块的核心任务之一是处理业务订单和付款订单之间的关系。

业务订单的核心属性：业务订单号，订单日期，订单金额，订单状态，折扣信息，商家信息和客户信息。

付款订单的核心字段：付款订单号，业务订单号，付款时间，付款金额，商人信息，付款状态。

2。和解摘要

一旦了解了支付系统的劳动力定位和分工，您将清楚您需要注意和解阶段需要注意的核心工作。

对帐主要确保三个数据的一致性：付款单，付款流和渠道流。

这三个项目是业务系统，付款系统和付款渠道的付款主数据。确保三个关系的ID关系和状态是一致的，并确保付款过程的正确性。在付款渠道的内部对帐中需要解决的问题，确保渠道需要确保的渠道流量中的结算金额和实际结算金额之间的一致性。

对帐的第一阶段涉及成员点的验证和操作折扣的匹配，因此该主题将在以后共享；第二阶段与第三阶段非常相似，并且根据下游系统以及本地订单或交易所产生的对帐文件对它们进行检查。有关详细的对帐过程，请参见下一节。

3。对帐过程

如下图所示，通常将在第二天生成对帐文件，因为下游系统需要处理前一天的内部对帐，仅在下游系统完成前一天的内部对帐之后，为上游生成了对帐文件。

获取对帐文件：格式的存储，原始数据的所有字段都存储；创建对帐批次：由于某些系统涉及许多商人或与多个付款渠道联系，因此可以根据实际需求创建对帐批次，并且易于分类和管理。通常用作批处理。但是，当下游对帐文件有问题时，可能有必要在同一天重新创建批次或完全覆盖。对帐处理：从格式的对帐文件中提取关键字段，例如六个流数，类型，状态，金额，商人编号，以匹配此系统的顺序；如果ID +金额 +状态相同，则订单将直接注销并用对帐标记标记。

ID是指向下游发送请求时该系统中唯一存储的主密钥。

情况有三种情况，情况不一致，与不同的治疗计划相对应：

当地有一个ID，下游具有ID；它可以匹配，但状态不正确；呼叫状态查询接口同步状态；当地有一个ID，但没有ID下游；根据ID检查下游订单；本地没有ID，下游具有ID；根据ID或查询日志检查本地订单。

在实际实践中，建议保留手动处理工具，然后根据操作稳定后的实际情况自动处理一些经常发生的方案。

4。摘要

本文的对帐是电子商务系统，付款系统和付款渠道之间的订单对帐，并且不涉及钱包和基金监护模型下的财务和解。

本文提供的方法主要基于业务需求，并解决了如何在平台的交易过程相对复杂时确保订单信息和付款信息的一致性的问题。

资本流量，结算基金，和解基金设计，财务ERP和公司在线银行（通过银行企业互联网的帐户流）的其他核对将被一一引入。

标题图片来自CC0协议。