CN118154336A - 一种对账方法、系统及相关设备 - Google Patents

Abstract

本申请提供了一种对账方法、系统及相关设备，该方法包括以下步骤：从支付渠道系统获取多笔交易的交易数据，基于计费模型确定每笔交易的支付渠道成本的计费结果，接收银行系统反馈的每笔交易的支付渠道成本的扣款结果，将多笔交易的计费结果进行合并获得合并计费结果，将多笔交易的扣款结果进行合并获得合并扣款结果，确定合并计费结果和合并扣款结果之间的差值，在差值超过预警阈值的情况下，向用户发送预警信息以指示用户更新该计费模型，使得渠道成本对账出现差错时，用户更新计费模型即可，提高对账效率，降低人力成本，提高用户的使用体验。

Description

一种对账方法、系统及相关设备

技术领域

本申请涉及计算机领域，尤其涉及一种对账方法、系统及相关设备。

背景技术

第三方支付平台是为买卖双方提供资金结算渠道的公司或机构，在第三方支付模式下，买家选购商品之后，将货款支付给第三方支付平台，第三方支付平台通知卖家发货，买家确认收货之后，第三发支付平台再将货款转至卖家账户，从而完成买卖双方的一次交易。第三方支付平台接入了多种支付渠道，比如网银、手机二维码、银行卡等，以满足买卖双方不同的支付习惯。

但是，用户通过支付渠道支付的每一笔交易，第三方支付平台都需要向支付渠道公司交手续费，因此第三方支付平台需要额外维护一个渠道成本账单，用来记录每一笔交易应付的渠道手续费，并且需要将该渠道成本账单与银行反馈的渠道扣款账单进行比对，这个过程也称为渠道成本对账，如果应付手续费和实付手续费之间保持一致，这笔账单可以进行核销，如果不一致则需要财务员工去排查原因，调整渠道成本账单。而第三方支付平台一天可能会有成千上万笔交易，需要大量的员工对存在问题的账单一笔一笔进行调账，不仅人力成本高，对账效率低，而且对账的准确率也依赖于员工的专业性，影响第三方支付平台财务总账的准确性和及时性。

发明内容

本申请提供了一种对账方法、系统及相关设备，用于解决渠道成本对账需要大量的员工对存在问题的账单一笔一笔进行调整，导致渠道成本对账人力成本高、对账效率低的问题。

第一方面，提供了一种对账方法，该方法应用于对账系统，该方法包括以下步骤：从支付渠道系统获取多笔交易的交易数据，基于计费模型确定每笔交易的支付渠道成本的计费结果，计费模型包括计费要素和对应的计费规则，计费要素用于确定交易数据进行渠道成本计费时使用的计费规则，计费要素和计费规则之间的对应关系是用户通过可视化界面配置的，从银行系统获取每笔交易的支付渠道成本的扣款结果，将多笔交易的计费结果进行合并获得合并计费结果，将多笔交易的扣款结果进行合并获得合并扣款结果，确定合并计费结果和合并扣款结果之间的差值，在差值超过预警阈值的情况下，向用户发送预警信息，预警信息用于指示用户更新计费模型。

实施第一方面描述的方法，对账系统可以从支付渠道系统获取多笔交易的交易数据，基于计费模型确定每笔交易的支付渠道成本的计费结果，然后从银行系统获取每笔交易的支付渠道成本的扣款结果，再将多笔交易的计费结果进行合并获得合并计费结果，将多笔交易的扣款结果进行合并获得合并扣款结果，确定合并计费结果和合并扣款结果之间的差值，在差值超过预警阈值的情况下，向管理用户发送预警信息以指示用户更新该计费模型，使得渠道成本对账时可以进行合并对账，不需要一笔一笔进行对账，提高对账效率，同时，管理用户可以根据预警信息更新计费模型即可，不需要再对存在问题的交易进行一笔一笔调账，提高对账效率，降低人力成本，提高用户的使用体验。

在一可能的实现方式中，该方法还包括以下步骤：在差值不超过预警阈值的情况下，对多笔交易进行渠道成本的核销操作。

上述实现方式，在合并记账结果与合并扣款结果之间的差值较小的情况下，多笔交易可以直接核销，应理解，在合并记账之后，如果多笔交易的差值较小，比如1000笔交易的差值为1分钱，说明这个对账失败的原因可以忽略不计，直接对1000笔交易进行核销后，用户不需要在1000笔交易中去一笔一笔核实产生1分钱差值的原因，降低人力成本，提高对账效率。

在一可能的实现方式中，获取多笔交易的交易数据，基于计费模型确定每笔交易的支付渠道成本的计费结果时，可以先获取多笔交易的交易数据，确定每笔交易的多个交易属性，交易属性用于描述交易数据，再根据每笔交易的多个交易属性，生成交易属性表，交易属性表包括多个字段，每个字段代表一个交易属性，交易属性表中的每一行数据对应拥有多个相同交易属性的一批交易数据，根据交易属性确定每一批交易数据对应的计费模型，根据每一批交易数据对应的计费模型，确定每一批交易数据中每笔交易数据对应的渠道成本的计费结果。

进一步地，由于交易数据的数据量往往会非常庞大，为了确保数据的高效查询，可以为每一批交易数据分配一个索引，具体可以在交易属性表中额外维护一个索引字段，该索引可以是多个字段的哈希值，这样每行数据可以对应一个索引，使用索引可以查询出每一行交易数据，提高数据查询的效率。

进一步地，若存在哈希值相同的多行交易数据，可以将相同哈希值对应的多行数据拼接成一条链表，一行数据可以对应链表的一个链表节点，具体可以在交易属性表中额外维护一个用于确定链表节点的字段，比如链表节点序列，或者前置节点序列等，使得相同哈希值的多行交易数据可以拼接成一条链表，每行交易数据对应不同的链表节点。这样在查询数据时，如果根据索引获得多行交易数据，可以先读取该哈希值对应的整个链表，然后按照链表节点字段描述的节点顺序，依次遍历每个链表节点对应的交易数据，直至找到满足查询条件的交易数据，从而避免由于哈希冲突导致索引失效的问题。其中，链表节点可以是按照添加顺序进行排列。

上述实现方式，通过交易属性表，可以将多笔拥有相同交易属性的交易进行合并，使得交易属性表中的一行数据可以使用同一个计费规则完成计费，提高计费效率。

在一可能的实现方式中，对账系统包括多个计费位图，其中，一个计费结果对应一个计费位图，计费位图包括多个比特位，每个比特位对应一个计费属性，每个比特位的值用于指示对应的计费结果中是否存在对应的计费属性，计费属性用于描述计费结果。

进一步地，每个位图可对应一个明细表，位图用于记录计费结果中包含的计费属性，明细表用于记录计费属性对应的值。举例来说，位图包括5个比特位，第一位表示网络服务，第二位表示品牌费，第三位表示银行手续费，第四位表示业务参与价(一些特定业务需要参与方额外支付的费用，比如入场费、入会费等)，第五位表示推广费用，如果计费结果包括渠道成本总金额为5元，其中包括1元网络服务费，2元品牌费，2元银行手续费，那么该计费结果的位图可以为：(1,1,1,0,0)，该位图对应的明细表中包括网络服务费的金额为1元，品牌费的金额为2元，银行手续费的金额为2元。应理解，上述举例用于说明，本申请不作具体限定。

上述实现方式，通过将每笔交易的计费结果以位图的方式记录每笔交易的计费结果所包含的计费属性，然后通过明细表记录每个计费属性具体的值，该种实现方式下，位图不仅可以有效地节省存储空间，还可以通过掩码、位运算等方式快速筛选出满足特定计费属性的计费结果，检索方式更加快速，提高数据查询效率，同时位图也容易扩展，添加新的计费属性时，可以通过扩展位图和明细表来支持新的计费属性，不需要修改整个数据结构，使得计费结果更加容易维护。

在一可能的实现方式中，将多笔交易的计费结果进行合并获得合并计费结果时，可以先获取一个或者多个合并计费属性，基于一个或者多个合并计费属性和多个计费位图，将多笔交易分为多个合并组，其中，一个合并组中多笔交易包括相同的合并计费属性，将每个合并组中的多笔交易的计费结果进行合并，获得每个合并组的计费结果，根据每个合并组的计费结果，获得多笔交易的合并计费结果。

具体实现中，基于一个或者多个合并计费属性和多个计费位图，将多笔交易分为多个合并组时，可以先根据一个或者多个合并计费属性，确定一个或者多个掩码，再将一个或者多个掩码应用于多个计费位图，获得包含一个或者多个合并计费属性的多个合并组。可以根据合并计费属性生成掩码，使用掩码对位图进行按位与操作，如果操作后的比特位得到的结果非零，说明该计费结果包含该比特位所表示的计费属性，如果操作后的比特位得到的结果是零，说明该计费结果包含该比特位所表示的计费属性。根据掩码的操作结果，可以获取出符合条件的位图，然后根据位图对应的明细表，获取满足合并计费属性的多个计费结果，进而获得合并记账结果。

具体实现中，在通过位图获得每个合并组的计费结果之后，将合并组中多笔交易的计费结果进行合并时，可以先对多笔交易的渠道成本进行合并，获得合并计费金额，然后再基于合并计费金额生成合并记账结果，该合并记账结果包括合并计费金额以及其他信息。合并计费金额包括多笔交易的渠道成本总金额以及多个类目的总金额，一个类目可以是多笔交易中的某一类手续费，比如清分费用总额、结算费用总额、网络费用总额、技术支持费用总额、风险管理费用总额、合规和监管费用总额、推广和时长费用总额、品牌费用总额等，一个类目还可以是多笔交易中某个计费属性筛选出的合并手续费，比如计算出多笔交易中，需要向A银行支付的渠道成本的总额，比如计算出多笔交易中，T1-T2时刻的需要支付的品牌费用总额等，比如计算出多笔交易中交易状态为已完成的渠道成本总额，具体可根据实际的业务需求确定，本申请不作具体限定。其他信息可包括交易信息，比如每笔交易的交易时间、交易号、交易金额、支付渠道、交易状态等；合并记账结果还可包括计费结果，比如每笔交易的计费结果、计费规则、计费时间等；合并记账结果还可包括合并信息，比如合并日期、合并交易数量、合并总金额等；合并记账结果还可包括渠道成本信息，比如渠道名称、渠道费用、渠道成本合并总金额等；合并记账结果还可包括总计信息，比如交易总数量、交易总金额、计费总金额、渠道成本总额等，上述举例用于说明，合并记账结果还可包括更多的内容，具体可根据实际渠道成本对账时的业务需求来确定，本申请不作具体限定。

需要说明的，对账系统可以提前设置有合并记账结果的模版信息，该模版信息包括合并记账结果中的一些必要的字段，比如上文描述的交易信息、计费结果、合并信息、渠道成本信息、总计信息等。这样，对账系统根据模板信息中所需填充的字段，获得各种合并金额，填充字段，生成合并记账结果。

上述实现方式，基于合并计费属性读取一个合并组的计费结果，然后对合并组内的多笔交易的计费结果进行合并，使得用户可以通过配置合并计费属性，灵活读取不同合并组的计费结果，对账时可以根据业务需求灵活对账，提高用户的使用体验。同时，由于计费位图的存在，合并计费属性无论如何改变，都可以通过掩码的方式从计费位图中读取出符合条件的多笔交易，读取方式灵活、准确、快捷，进而提高对账效率。

在一可能的实现方式中，将每个合并组中的多笔交易的计费结果进行合并，获得每个合并组的合并结果时，可以将每个合并组中的多笔交易的多个单笔计费结果发送给不同的实例进行处理，获得每个实例完成的合并结果，其中，实例包括物理机、虚拟机或容器，每个合并组中的交易笔数根据每个实例的处理能力确定。

可选地，对账系统可以基于大数据平台，根据合并计费属性，筛选出多组计费结果，然后将多组计费结果进行合并，获得多个合并计费结果。上述大数据平台可包括但不限于hivesql、saprksql等。具体地，可以使用批处理或流处理的方式，获取多个计费结果、交易属性表以及位图等数据存储于hive、spark等这样的大数据平台的数据仓库中，hive、saprk等大数据平台提供了类似SQL的查询语言，方便进行复杂的数据分析，使得大数据平台可以根据不同的合并计费属性筛选出多组计费结果，完成每一个合并组的多个计费结果的合并，生成合并计费结果。

可选地，对账系统可以建立微服务架构，通过微服务架构分配计费合并任务至各个实例，一个计费合并任务用于实现对一个合并组的多个计费结果进行合并。其中，微服务架构包括多个实例，每个实例用于执行特定的任务，每个实例可以在物理机、虚拟机或容器中运行。进一步的，微服务架构还可以与分片流(sharding stream)技术结合，根据合并计费属性，生成多个计费合并任务，将多个计费合并任务分配各个微服务实例，使得多个实例并行完成多个计费合并任务。

上述实现方式，通过将合并任务分发给不同的实例进行处理，各个实例并行处理合并任务，可以提高合并计费结果的处理效率，并且，通过分片流技术可以合理分配计费合并任务，确保每个计费合并任务的处理压力适中，避免单个计费合并任务处理负担过重，通过微服务架构实现实例的动态扩缩容，根据计费合并任务自动调整实例的数量，更好地满足业务的变化和发展。

在一可能的实现方式中，将多笔交易的扣款结果进行合并获得合并扣款结果时，可以先将每个合并组中的多笔交易的扣款结果进行合并，获得每个合并组的扣款结果，再根据每个合并组的扣款结果，获得多笔交易的合并计费结果，这样，当确定合并计费结果和合并扣款结果之间的差值时，可以确定每个合并组的扣款结果与计费结果之间的差值。

上述实现方式，通过同样的方式将扣款结果进行合并，获得合并扣款结果，然后将同一个合并组的合并计费结果与合并扣款结果进行核对，一次性完成一整个合并组的渠道成本对账，用户不需要一笔一笔去核对计费结果和扣款结果，提高渠道成本对账的效率。

第二方面，提供了一种对账系统，该系统包括单笔计费单元，用于从支付渠道系统获取多笔交易的交易数据，基于计费模型确定每笔交易的支付渠道成本的计费结果，计费模型包括计费要素和对应的计费规则，计费要素用于确定交易数据进行渠道成本计费时使用的计费规则，计费要素和计费规则之间的对应关系是用户通过可视化界面配置的，接收单元，用于从银行系统获取每笔交易的支付渠道成本的扣款结果，第一合并单元，用于将多笔交易的计费结果进行合并获得合并计费结果，第二合并单元，用于将多笔交易的扣款结果进行合并获得合并扣款结果，对账单元，用于确定合并计费结果和合并扣款结果之间的差值，分析单元，用于在差值超过预警阈值的情况下，向用户发送预警信息，预警信息用于指示用户更新计费模型。

实施第二方面描述的系统，对账系统可以从支付渠道系统获取多笔交易的交易数据，基于计费模型确定每笔交易的支付渠道成本的计费结果，然后从银行系统获取每笔交易的支付渠道成本的扣款结果，再将多笔交易的计费结果进行合并获得合并计费结果，将多笔交易的扣款结果进行合并获得合并扣款结果，确定合并计费结果和合并扣款结果之间的差值，在差值超过预警阈值的情况下，向管理用户发送预警信息以指示用户更新该计费模型，使得渠道成本对账时可以进行合并对账，不需要一笔一笔进行对账，提高对账效率，同时，管理用户可以根据预警信息更新计费模型即可，不需要再对存在问题的交易进行一笔一笔调账，提高对账效率，降低人力成本，提高用户的使用体验。

在一可能的实现方式中，分析单元，用于在差值不超过预警阈值的情况下，对多笔交易进行渠道成本的核销操作。

在一可能的实现方式中，单笔计费单元，用于获取多笔交易的交易数据，确定每笔交易的多个交易属性，交易属性用于描述交易数据，单笔计费单元，用于根据每笔交易的多个交易属性，生成交易属性表，交易属性表包括多个字段，每个字段代表一个交易属性，交易属性表中的每一行数据对应拥有多个相同交易属性的一批交易数据；单笔计费单元，用于根据交易属性确定每一批交易数据对应的计费模型，单笔计费单元，用于根据每一批交易数据对应的计费模型，确定每一批交易数据中每笔交易数据对应的渠道成本的计费结果。

在一可能的实现方式中，对账系统包括多个计费位图，其中，一个计费结果对应一个计费位图，计费位图包括多个比特位，每个比特位对应一个计费属性，每个比特位的值用于指示对应的计费结果中是否存在对应的计费属性，计费属性用于描述计费结果。

在一可能的实现方式中，第一合并单元，用于获取一个或者多个合并计费属性，基于一个或者多个合并计费属性和多个计费位图，将多笔交易分为多个合并组，其中，一个合并组中多笔交易包括相同的合并计费属性，第一合并单元，用于将每个合并组中的多笔交易的计费结果进行合并，获得每个合并组的计费结果，第一合并单元，用于根据每个合并组的计费结果，获得多笔交易的合并计费结果。

在一可能的实现方式中，第一合并单元，用于根据一个或者多个合并计费属性，确定一个或者多个掩码，第一合并单元，用于将一个或者多个掩码应用于多个计费位图，获得包含一个或者多个合并计费属性的多个合并组。

在一可能的实现方式中，第一合并单元，用于将每个合并组中的多笔交易的多个单笔计费结果发送给不同的实例进行处理，获得每个实例完成的合并结果，其中，实例包括物理机、虚拟机或容器，每个合并组中的交易笔数根据每个实例的处理能力确定。

在一可能的实现方式中，第二合并单元，用于将每个合并组中的多笔交易的扣款结果进行合并，获得每个合并组的扣款结果，第二合并单元，用于根据每个合并组的扣款结果，获得多笔交易的合并计费结果，对账单元，用于确定每个合并组的扣款结果与计费结果之间的差值。

第三方面，提供了一种计算设备，该计算设备包括处理器和存储器，存储器用于存储指令，处理器用于执行指令，以使得计算设备实现如第一方面描述的方法。

第四方面，提供了一种计算机可读存储介质，计算机可读存储介质中存储有指令，指令被计算设备或者计算设备集群运行时实现如第一方面描述的方法。

第五方面，提供了一种计算设备集群，该计算设备集群包括至少一个计算设备，至少一个计算设备中的每个计算设备包括处理器和存储器，至少一个计算设备的处理器用于执行至少一个计算设备的存储器中存储的指令，以使得计算设备集群实现如第一方面描述的方法。

第六方面，提供了一种包含指令的计算机程序产品，计算机程序产品包括指令，该指令能够运行在计算设备上或被储存在任何可用介质中的软件或程序产品，当计算机程序产品在计算设备或者计算设备集群上运行时，使得计算设备或者计算设备集群执行第一方面描述的方法。

附图说明

图1是本申请提供的一种对账系统的架构图；

图2是本申请提供的一种对账方法的步骤流程示意图；

图3是本申请提供的一种配置界面的示例图；

图4是本申请提供的一种位图的示例图；

图5是本申请提供的另一种位图的示例图；

图6是本申请提供的一种基于掩码读取包含合并计费属性的计费位图的步骤示例图；

图7是本申请提供的一种渠道成本对账界面的示例图；

图8是本申请提供的一种计算设备的结构示意图。

具体实施方式

首先，对本申请涉及的部分术语进行解释说明。

支付渠道：指的是第三方支付平台上支持平台用户完成支付操作的渠道，比如信用卡、借记卡、电子钱包、移动支付、虚拟货币等，这些支付渠道不仅帮助平台用户完成交易金额的支付，而且支持平台与银行之间的资金流转、对账和清分。

清分：对交易过程中每个参与方需要支付和收取的金额进行计算，确定每个参与方的交易明细，比如应付款项和应收款项等。

计费：计费的通用含义为计算费用，在本申请实施例中，计算的费用指的是通过支付渠道的每一笔交易中，被支付渠道公司收取的手续费。

计费规则：被支付渠道公司收取的手续费是按照一定的计费规则确定的，这个计费规则是与支付渠道公司约定的计费规则，比如按比例、按固定金额、按单笔阶梯、按累计阶梯等。

渠道成本：使用渠道成本完成支付动作花费的成本，该成本至少包括渠道手续费，还可包括一些其他费用，比如推广费用、品牌费用等，渠道成本可以理解为是第三方支付平台在完成一笔交易的过程中需要额外支付的费用。

对账：在本申请实施例中，对账指的是第三方支付平台将计费得到的渠道成本与银行收取的渠道成本比对。

核销：在财务领域，核销通常指确认账目或交易的准确性，比如一笔债务被清偿时，财务可以核销该笔债务对应的财务记录。

其次，对本申请涉及的应用场景进行解释说明。

第三方支付平台是为买卖双方提供资金结算渠道的公司或机构，在第三方支付模式下，买家选购商品之后，将货款支付给第三方支付平台，第三方支付平台通知卖家发货，买家确认收货之后，第三发支付平台再将货款转至卖家账户，从而完成买卖双方的一次交易。第三方支付平台接入了多种支付渠道，比如网银、手机二维码、银行卡等，以满足买卖双方不同的支付习惯。

平台用户通过支付渠道支付的每一笔交易，第三方支付平台都需要向支付渠道公司交手续费，因此第三方支付平台需要额外维护一个渠道成本账单，用来记录每一笔交易应付的渠道手续费。银行也需要维护一个渠道扣款账单，用来记录每一笔交易实际扣除的渠道手续费，在进行渠道成本对账时，第三方支付平台需要将渠道成本账单与银行下发的渠道扣款账单进行比对，确保应付手续费和实付手续费之间保持一致，如果不一致则需要员工去排查原因，调整渠道成本账单。

但是，由于各种常态化原因，非常容易导致第三方支付平台计算的应付手续费与实付手续费不一致，比如，银行和第三方支付平台可能在不同的时间节点处理交易，如果一方计算了手续费，另一方还未完成相应的处理，可能导致应付手续费与实付手续费不一致的问题；比如，当存在大量交易时，第三方支付平台和银行所记录的交易顺序很可能会出现不一致的问题，此时也可能导致手续费的计算结果不同；比如，银行和第三方可能使用不同的手续费计算规则，也可能导致手续费的计算结果不同，例如银行临时上调了手续费率，或者银行临时对手续费率进行打折等；比如，在涉及多个系统和平台的复杂网络环境中，可能因为通信延迟等问题导致交易信息难以及时同步，从而引起手续费计算的不一致。而第三方支付平台一天可能会有成千上万笔交易，这样常态化的出现应付手续费与实付手续费不一致的问题，需要大量的员工对渠道成本账单进行调账，不仅人力成本高，调账效率低，而且调整准确率也依赖于员工的专业性，影响第三方支付平台财务总账的准确性和及时性。

为了解决上述渠道手续费的对账的人力成本高、调账效率低，影响财务总账的准确性和及时性的问题，本申请提供了一种对账方案，该方案中，对账系统可以从支付渠道系统获取多笔交易的交易数据，基于计费模型确定每笔交易的支付渠道成本的计费结果，然后从银行系统获取每笔交易的支付渠道成本的扣款结果，再将多笔交易的计费结果进行合并获得合并计费结果，将多笔交易的扣款结果进行合并获得合并扣款结果，确定合并计费结果和合并扣款结果之间的差值，在差值超过预警阈值的情况下，向管理用户发送预警信息以指示用户更新该计费模型，使得渠道成本对账时可以进行合并对账，不需要一笔一笔进行对账，提高对账效率，同时，管理用户可以根据预警信息更新计费模型即可，不需要再一笔一笔调整账目，提高对账效率，降低人力成本，提高用户的使用体验。

图1是本申请提供的一种对账系统的架构图，如图1所示，该架构可包括客户端100、支付渠道系统200、银行系统300以及对账系统400，其中，客户端100、支付渠道系统200、银行系统300以及对账系统400之间存在通信连接，可以是有线连接也可以是无线连接，本申请不作具体限定。与对账系统400建立通信连接的支付渠道系统200、银行系统300以及客户端100的数量可以是一个或者多个，本申请不作具体限定。

客户端100用于实现人机交互，可以部署于终端设备，终端设备包括个人电脑、智能手机、可穿戴设备、掌上处理设备、平板电脑、移动笔记本、增强现实(augmentedreality,AR)设备、虚拟现实(virtual reality,VR)设备、一体化掌机、穿戴设备、车载设备、智能会议设备、智能广告设备、智能家电等等，智能家电可以是扫地机器人、拖地机器人等等，此处不作具体限定。

客户端100的持有者是维护对账系统400的管理用户，是第三方支付平台的企业员工，一般为企业的财务人员或者信息技术(information technology,IT)人员，本申请不作具体限定。应理解，平台用户是使用第三方支付平台购买商品的消费者，本申请提供的对账系统主要面对管理用户使用，需要根据平台用户触发的交易数据完成渠道成本对账。

具体实现中，客户端100可以是管理用户所控制的终端设备或计算设备上运行的软件或者应用程序，比如个人电脑(personal computer,PC)客户端，也可以是基于浏览器访问的万维网(world wideweb,web)客户端，还可以是在移动终端上运行的应用(application,APP)客户端，还可以是云平台的控制台(console)，本申请不作具体限定。

可选地，客户端100可以是专门用于实现对账功能的客户端，比如对账软件、对账助手等客户端。或者，客户端100可以是包含对账功能或模块的综合性客户端，比如财务会计软件，该软件提供对账功能，使管理用户能够比对账户、交易和财务记录。比如企业资源规划系统，该类系统包括财务管理、供应链管理、人力资源管理等模块，其财务管理模块可用后对账、记账、报表生成等功能。比如第三方支付平台，该平台通常包括订单管理和对账功能，以确保订单、库存和支付的一致性。上述举例用于说明，本申请不对客户端的具体形式进行限定。

可选的，客户端100还可以是云平台的客户端，比如云平台的控制台(console)，具体可以是基于web的console，也可以是基于应用程序接口(applicationprogramminginterface,API)的console，本申请不作具体限定。该console可以向用户提供对账云服务，管理用户可通过购买云服务的方式，获得本申请提供的对账系统400的使用权限。

支付渠道系统200、银行系统300以及对账系统400可以部署于计算设备或者计算设备集群，其中，计算设备包括裸金属服务器(bare metal server,BMS)、虚拟机、容器或者边缘计算设备。BMS指的是通用的物理服务器，例如，ARM服务器或者X86服务器；虚拟机指的是通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。在实体计算机中能够完成的工作在虚拟机中都能够实现。在计算设备中创建虚拟机时，需要将实体机的部分硬盘和内存容量作为虚拟机的硬盘和内存容量。每个虚拟机都有独立的基础输入/输出系统(basic input/output system,BIOS)、硬盘和操作系统，可以像使用实体机一样对虚拟机进行操作；容器是一种便携式软件单元，可以将应用及其所有依赖项合并为一个软件包，该软件包不受底层主机操作系统的限制，这样无需再构建复杂的环境，简化了应用开发到部署的过程；边缘计算设备是指更加接近数据源或者用户持有的终端的设备，且该设备具有低延迟、高带宽特点，比如智能路由、边缘服务器等等。计算设备集群可包括多个上述计算设备，比如数据中心，本申请不作具体限定。

其中，支付渠道系统200是支付渠道公司维护的系统，主要用于接收到第三方平台的商城系统发送的支付指令，然后根据支付指令生成交易数据，再将交易数据发送给第三方平台的对账系统400以及银行系统300，支付渠道的解释可参考前述术语部分的描述，这里不重复赘述。

银行系统300是银行维护的系统，主要用于接收支付渠道公司的支付渠道系统200发送的交易数据，根据交易数据完成渠道手续费的扣款，生成渠道扣款账单，将渠道扣款账单发送给第三方平台的对账系统400完成渠道成本对账。其中，银行系统300可以是一个银行维护的系统，或者，是多个银行共同维护的系统，比如银联、网联或者银网联系统等，本申请不作具体限定。

对账系统400是第三方支付平台维护的系统，主要用于接收支付渠道系统200发送的交易数据以及银行系统300发送的渠道扣款账单，然后基于交易数据和渠道扣款账单，完成渠道成本的对账。需要说明的，图1所示的对账系统400是第三方支付平台中的一个子系统，第三方支付平台还会包括商城系统，用于完成平台用户的购买操作，生成交易指令，然后将交易指令发送支付渠道系统200，使得支付渠道系统根据支付指令生成交易数据。由于本申请的发明重点在于对账，因此未绘制出第三方支付平台以及第三方支付平台中的商城系统。

可选地，客户端100可以与对账系统400部署于相同的计算设备上，比如客户端100以及对账系统400均部署于公司财务部门维护的服务器上；或者客户端100部署于终端设备，对账系统400部署于计算设备，比如客户端100部署于财务员工私人手机上，对账系统400部署于公司的服务器；或者客户端100与对账系统400部署于同一个计算设备集群中的不同计算设备，比如客户端100可以部署公司的办公电脑，对账系统400可以部署于公司的服务器，办公电脑和服务器同属于同一个计算设备集群，使用同一个公司内部网络；或者客户端100与对账系统400部署于不同计算设备集群中，比如客户端100部署于公司的办公电脑上，对账系统400部署于公有云的云服务器。上述举例用于说明，本申请不作具体限定。

可选地，支付渠道系统200和银行系统300可以部署于相同的计算设备或者相同的计算设备集群，此时支付渠道系统是银行的支付渠道系统。应理解，银行也可以为第三方支付平台提供支付渠道，比如付款时选择工行、农行等支付渠道进行付款时，该支付渠道系统200和银行系统300可以部署于同一个计算设备或同一个计算设备集群。支付渠道系统200和银行系统300也可以部署于不同的计算设备集群中，此时支付渠道系统200可以是非银行类的支付渠道，这里不再举例说明。

可选地，对账系统400可以支付渠道系统200部署于相同的计算设备或者相同的计算设备集群，此时的第三方支付平台拥有自己的支付渠道，换句话说，对账系统、支付渠道系统属于同一个第三方支付平台。应理解，一些第三方支付平台拥有自己的支付渠道，比如第三方支付平台为华为商城，支付渠道为华为钱包，此时支付渠道系统是第三方支付平台的子系统，所以支付渠道系统200和对账系统400可以部署于同一个计算设备集群或者相同的计算设备上。上述举例用于说明，本申请不作具体限定。

进一步地，图1中的对账系统400可进一步划分为一个或者多个单元模块，示例性地，如图1所示，对账系统400包括配置单元410、单笔计费单元420、第一合并单元430、接收单元440、第二合并单元450、对账单元460、分析单元470以及存储装置480。应理解，图1是一种示例性划分方式，对账系统400还可以包括更多或者更少的单元，本申请不作具体限定。

需要说明的，图1所示的结构可以是对账系统400部署于单个计算设备的实现方式，当对账系统400部署于多个计算设备组成的计算设备集群时，该计算设备集群中的不同的计算设备可以分别存储有用于实现配置单元410、单笔计费单元420、第一合并单元430、接收单元440、第二合并单元450、对账单元460、分析单元470以及存储装置480的指令，比如计算设备集群中的计算设备A存储有用于实现配置单元410、单笔计费单元420、第一合并单元430、接收单元440、第二合并单元450指令，计算设备B存储有用于实现对账单元460、分析单元470以及存储装置480的指令，上述举例用于说明，本申请不做具体限定。当然，不同的计算设备也可以存储有相同的指令，比如计算设备A和计算设备C均存储有配置单元410、单笔计费单元420、第一合并单元430、接收单元440、第二合并单元450的指令，用于组合实现配置单元410、单笔计费单元420、第一合并单元430、接收单元440、第二合并单元450的功能，本申请不作具体限定。

下面基于对账系统400中各个单元模块的功能进行解释说明。

配置单元410用于生成计费模型，并将其存储于存储装置480中。

可选地，计费模型可包括计费要素和计费规则，其中，每个计费规则对应一组计费要素，根据每个交易数据包含的计费要素，可确定该交易数据需要使用的计费规则。

具体实现中，计费要素可包括一些用于判定交易数据需要使用的计费规则的必要信息，这些必要信息可以是交易数据中与支付渠道相关的信息，比如支付渠道名称、支付渠道产品名称、机构代码、渠道类型、渠道子类型、银行名等，其中，支付渠道名称指的是支付渠道的名字，比如X宝、X钱包等；支付渠道产品名称指的是支付渠道下的具体产品名，比如X宝包括余额支付、信用支付、分期支付等；机构代码是一个唯一标识符，用来区分银行、金融机构、支付渠道公司等，有助于确保在不同系统和交易中准确识别这些银行、金融机构和支付渠道公司；渠道类型指的是交易方式，比如物理渠道(实体店)、在线渠道(电子购物、移动应用等)、代理商渠道等；渠道子类型指的是对于渠道类型更具体的分类，比如物理渠道的渠道子类型可包括专卖店、自动售货机、展览会等，在线渠道的渠道子类型可包括电子商务平台、社交媒体、移动应用、官方网站等，代理商渠道的渠道子类型可包括经销商、代理商、合作伙伴计划等；银行名称可以是完成渠道手续费扣款的银行的名称。上述举例用于说明，计费要素还可以包括更多的内容，比如银行卡类型、行业等，本申请不作具体体现定。

应理解，计费要素越详细，对应的计费规则越准确，但是对应关系就会越复杂，因此可根据实际的业务需求和系统的处理能力确定计费要素的内容以及对应关系，上文给出了一部分可能的计费要素，本申请不作具体限定。同时，如果用户需要修改或者新增计费规则，都不会对其他计费规则产生影响，使得对账系统400更加灵活，可扩展性强。

具体实现中，计费规则可包括渠道手续费的计费方式，比如计费规则可包括计费类型、费用生效时间以及计费模式。其中计费类型用于区分计费方式，费用生效时间用于定义计费的生效时间范围，计费模式用于描述计费类型下的计费细节，计费类型、费用生效时间以及计费模式可以组成一个完整的计费规则。不同的计费规则对应的计费类型、费用生效时间或者计费模式不同，比如计费规则1和计费规则2的计费类型相同、计费模式相同，但是费用生效时间不同，比如计费规则3和计费规则4的计费类型不同，但是计费生效时间以及计费模式相同。

下面分别对计费规则中的计费类型、费用生效时间以及计费模式进行解释说明。

计费类型包括单笔计费、单笔梯度计费、金额累计梯度计费等计费方式，具体可根据实际的业务场景确定计费类型，本申请不作具体限定。其中，单笔计费指的是每笔交易按照某个计费模式完成计费，单笔梯度计费指的是根据交易金额的不同部分，分阶段收取费用，也就是说，将交易金额分为几个梯度，每个梯度按照不同的计费模式完成计费，比如前100元按照1％收费，101至200元按照0.8％收费，200元以上按照0.5％收费。金额累计梯度计费指的是在一定时间范围内，根据累计交易金额收取不同阶段的费用，比如在一个月内，交易累计达到1000元收取1％手续费，2000元至5000元收取0.8％手续费，5000元以上收取0.5％手续费。应理解，计费类型还可以包括更多内容，本申请不作具体限定。

费用生效时间可包括即时生效、每日生效、每月生效等生效时间，具体可根据实际的业务场景确定，本申请不作具体限定。其中，即时生效指的是每个交易发生之后立即计费扣款，每日生效指的是按日统一计费扣款，每月生效指的是按月统一计费扣款。上述举例用于说明，本申请不作具体限定。

计费模式可包括固定费用、百分比费用、混合计费等，具体可根据实际的业务场景确定计费类型，本申请不作具体限定。固定费用指的是每笔交易收取固定的金额，百分比费用指的是按照交易金额百分比收取费用，混合计费指的是部分按照固定费用、部分按照百分比费用进行收费。计费模式还可包括更详细的内容，比如固定费用下还可进一步划分为品牌费用、网络服务费用、应付业务参与价格等，具体可根据实际的业务场景决定，这里不一一举例说明。

需要说明的，不同计费类型下可选的计费模式也不同，比如单笔计费下的计费模式不包括阶梯信息，而单笔梯度计费、金额累计梯度计费等计费类型下的计费模式需要额外包括阶梯信息，比如阶梯序号、阶梯起始、阶梯截止等。再举例来说，固定费用可包括保底手续费、封顶手续费等，保底手续费指的是支付渠道公司设定一个最低阈值和保底金额，如果这个月的手续费总额未超过该最低阈值，那么将按照保底金额收取费用，同理，封顶手续费指的是设置一个最高阈值和封顶金额，如果超过最高阈值将按照封顶金额收取固定费用。上述举例用于说明，本申请不作具体限定。

应理解，计费规则通过上述计费类型、计费模式和费用生效时间自由组合，使得计费规则的配置更加灵活，提高用户的使用体验。当然，计费规则还可以通过更多的元素组合实现，比如计费规则还可包括计费累计周期、退款退费模式等，这里不一一举例说明。

可选地，计费模型不仅包括上述计费要素和计费规则，还可包括更多的内容，比如结算模式、手续费收取方式、手续费收取周期等，具体可根据实际的业务场景确定计费模型的内容，这里不一一举例说明。

可选地，对账系统400可以预先建立多组计费要素和计费规则之间的对应关系，管理用户可以从中选择计费要素和计费规则，完成计费模型的配置。具体地，管理用户可以使用可视化界面(graphical user interface,GUI)发起配置请求，客户端100可以向管理用户显示可选择的计费要素和计费规则，对账系统400可以根据管理用户所选择的计费要素和计费规则，生成计费模型存储于存储装置480中，使得后续对交易数据进行计费时，可以根据计费模型完成计费。

可选地，对账系统400也可以接收管理用户上传的计费要素和计费规则，生成计费模型。具体地，管理用户可以通过修改配置文件、通过GUI导入模型等方式实现计费模型的配置，本申请不作具体限定。

应理解，本申请通过预先配置计费要素和计费规则，然后管理用户通过选择的方式来配置计费模型，使得模型的配置更加简单、快捷、灵活，提高用户的使用体验。

具体实现中，该计费模型是一个计算模型，交易数据输入该计费模型即可获得计费结果，计费模型可以将交易数据与计费模型中的计费要素进行匹配，确定该交易数据对应的计费规则，然后使用该计费规则完成计费，计费模型可包括需要计算的手续费种类以及对应的费用计算方式，手续费种类包括渠道手续费、清分费用、结算费用、网络费用、技术支持费用、风险管理费用、合规和监管费用、推广和时长费用、品牌费用等，费用的计算方式可根据具体的业务场景来确定，本申请不作具体限定。

单笔计费单元420用于获取交易数据，基于计费模型获得交易数据中每笔交易的计费结果。

可选地，商城用户通过第三方支付平台的商城系统下单后，商城系统可生成支付指令，然后将支付指令发送给支付渠道系统200，支付渠道系统200根据支付指令生成交易数据，然后将交易数据发送给第三方支付平台的对账系统400的单笔计费单元420，同时将交易数据发送给银行系统300完成渠道手续费的扣款，银行系统300生成渠道扣款账单后将其反馈给对账系统400，使得对账系统400可以根据交易数据和渠道扣款账单完成渠道成本对账。

具体实现中，支付指令是生成的支付指令，该支付指令可包括支付金额、支付方式、收款方信息、支付发起方信息、交易描述、交易流水号、支付时间戳等信息。交易数据是支付渠道系统200根据支付指令生成的，交易数据可以是多笔交易的交易数据，每笔交易数据包括交易金额、交易状态、交易时间、支付流水号、支付渠道信息、支付渠道流水号、商户信息、商城用户信息等。上述举例用于说明，支付指令和交易数据还可以包括更多的内容，这里不一一举例说明。

可选地，单笔计费单元420可以在获取到交易数据之后，根据每笔交易的交易数据，确定每笔交易的交易属性，交易属性用于描述该笔交易的交易数据的相关特征，比如交易属性可包括交易时间、支付渠道编码、银行编码、交易金额、交易状态、交易类型、货币类型、商户编码、结算模式等等，其中，交易时间指的是交易的具体时间；支付渠道编码指的是支付渠道的编码，该编码通常为唯一的编码；银行编码是银行的编码；交易金额指的是商城用户通过支付渠道支付的金额；交易状态指的是该笔交易的处理状态，可以是待处理、已完成、失败等；交易类型指的是该笔交易的交易类型，可以是购物、转账、退款等；货币类型指的是该笔交易的货币种类，比如人民币、美元、日元等；商户编码指的是该笔交易的收款方，同理交易属性也可以包括用户编码，也就是该笔交易的付款方；结算模式指的是该笔交易在渠道成本对账过程中的结算类型，包括不涉及结算、全额结算和轧差结算等，不涉及结算指的是渠道成本对账中不存在具体的货币交换，例如一方向另一方提供了某项服务；全额结算指的是渠道成本是按照全部应付款项进行计算的，支付的金额是全额结算；轧差结算指的是结算的金额是在应付款项的基础上进行调整的，可能存在优惠、折扣、退款等。应理解，上述交易属性的举例用于说明，本申请不作具体限定。

具体实现中，单笔计费单元420可以将拥有多个相同交易属性的多笔交易数据合并为一批交易数据，写入交易属性表中，该交易属性表包括多个字段，每个字段代表一个交易属性，交易属性表中的每一行数据用于指示一批拥有相同交易属性的多笔交易的交易数据。需要说明的是，一笔交易可以拥有多个交易属性，那么一批拥有相同交易属性的多笔交易，可以是全部交易属性都相同，也可以是部分交易属性相同，比如一笔交易拥有10个交易属性，那么9个交易属性都相同的多笔交易可以作为一批交易，写入交易属性表的一行数据中，也可以是10个交易属性都相同的多笔交易可以作为一批交易写入交易属性表的一行数据中，本申请不作具体限定。

示例性地，下表1是交易数据的一种交易属性表示例。如表1所示，一行数据表示一批交易数据的多个交易属性，比如序列1对应的一行交易数据包括以下多个交易属性：交易日期为2023年8月11，支付渠道编码为0001，银行编码为0102，交易金额为100万元，交易类型为购物，交易状态为已完成。同理，可以确定序列2、序列3、序列4对应的多组交易数据的交易属性，表1是一种示例，交易属性表还可以包括更多或者更少的字段，本申请不作具体限定。

表1交易数据的一种交易属性表示例

可以理解的，通过交易属性表，可以将多笔拥有相同交易属性的交易进行合并，使得交易属性表中的一行数据可以使用同一个计费规则完成计费，提高计费效率。

可选地，由于交易数据的数据量往往会非常庞大，为了确保数据的高效查询，可以为每一批交易数据分配一个索引，具体可以在交易属性表中额外维护一个索引字段，该索引可以是多个字段的哈希值，比如表1所示的例子中，可以将序列1的交易日期、支付渠道编码、银行编码的哈希值作为序列1的索引。同理，序列2的交易日期、支付渠道编码、银行编码的哈希值作为序列2的索引，这样每行数据可以对应一个索引，使用索引可以查询出每一行交易数据，提高数据查询的效率。

进一步地，若存在哈希值相同的多行交易数据，可以将相同哈希值对应的多行数据拼接成一条链表，一行数据可以对应链表的一个链表节点，具体可以在交易属性表中额外维护一个用于确定链表节点的字段，比如链表节点序列，或者前置节点序列等，使得相同哈希值的多行交易数据可以拼接成一条链表，每行交易数据对应不同的链表节点。这样在查询数据时，如果根据索引获得多行交易数据，可以先读取该哈希值对应的整个链表，然后按照链表节点字段描述的节点顺序，依次遍历每个链表节点对应的交易数据，直至找到满足查询条件的交易数据，从而避免由于哈希冲突导致索引失效的问题。其中，链表节点可以是按照添加顺序进行排列。

示例性地，表2是交易数据的一种交易属性表示例。表1与表2的区别在于，表2额外增加了哈希值字段和前置节点字段，其中，哈希值字段即为索引，在查询数据时可以根据哈希值读取对应的交易数据。如果多行数据的哈希值相同，那么可以根据前置节点字段，确定该哈希值对应的链表中的多个链表节点的顺序，比如序列4的一批交易数据中，前置节点为1，也就是说哈希值为hash1的链表中，首个链表节点为序列1，第二个链表节点为序列4，如果序列5对应的哈希值也是hash1，那么其前置节点即为序列4。应理解，表2用于举例说明，前置节点字段也可以直接用链表序列字段进行代替，该字段直接用于确定该行数据在链表中的序列号，那么序列1的链表序列为1，序列4的链表序列为2，应理解，上述举例用于说明，本申请不作具体限定。

表2交易数据的另一种交易属性表示例

应理解，上述方案通过链表的方式解决哈希冲突，具体实现中，也可以通过其他方式解决哈希冲突，比如随机取一个新的哈希值，本申请不对解决哈希冲突的具体方式进行限定。

可选地，计费结果可包括每笔交易的渠道成本明细，其中，渠道成本指的是交易过程中，第三方支付平台需要额外支付的成本。具体实现中，渠道成本可包括需要支付给支付渠道公司的渠道手续费，还可包括其他手续费，比如清分费用、结算费用、网络费用、技术支持费用、风险管理费用、合规和监管费用、推广和时长费用、品牌费用等，具体可根据实际的业务场景决定渠道成本包含的手续费项目，本申请不作具体限定。其中，渠道成本明细可包括渠道成本包含的每个手续费项目的名称以及金额，还可包括每个手续费的计算过程，本申请不作具体限定。

可选地，计费结果可包括每笔交易的清分结果，其中，清分指的是对交易过程中每个参与方需要支付和收取的金额进行计算，确定每个参与方的应付款项和应收款项，参与方可以是发起方、接收方、银行、支付渠道公司、第三方支付平台、品牌公司、支付网关等，并且，每个参与方的应付款项和应收款项也可以进行细分，比如支付渠道公司的应付款项包括渠道手续费、品牌费用，应收款项包括商城用户支付的货款和商家支付的平台手续费。简单来说，渠道成本明细计算的是第三方支付平台需要支付的一些渠道成本的详细内容，清分结果是多个参与方需要支付和收取的款项，清分结果和渠道成本明细计算有一定的重合度，但是清分结果包含的内容更加详细和丰富。

应理解，计费结果还可包括更多的内容，具体可根据实际的应用场景确定，本申请不作具体限定。

可选地，单笔计费单元420可以根据存储装置480中的计费模型完成每笔交易的计费结果，具体的，单笔计费单元420将每笔交易数据的交易属性与计费模型中的计费要素进行匹配，确定每笔交易对应的计费规则，然后使用计费规则完成该笔交易的计费，获得该笔交易的计费结果。参考前述内容可知，交易属性表中的每一行用于指示一批拥有相同交易属性的交易数据，因此每一行的交易数据可以使用同一个计费规则完成计费，从而提高计费效率。

可选的，单笔计费单元420可以在获得每笔交易的计费结果之后，生成每笔交易的计费结果对应的位图。其中，位图包括多个比特位，每个比特位用于描述计费结果中的一个计费属性，比特位的值用于指示该计费属性是否存在，示例性的，比特位的值可以是二进制值，比如0代表该计费属性不存在，1代表该计费属性存在。应理解，位图中的比特位用二进制值进行表示，使得后续数据读取时，可以通过掩码、位运算等方式快速筛选出满足特定计费属性的计费结果，检索方式更加快速，提高数据查询效率。

具体的，计费属性用于描述计费结果中的相关特征，计费属性包括计费结果对应的交易数据的交易属性，比如交易日期、支付渠道编码、银行编码、交易金额、交易状态、交易类型、货币类型、商户编码、结算模式等等；计费属性还包括计费结果中与渠道成本明细相关的属性，比如渠道手续费、清分费用、结算费用、网络费用、技术支持费用、风险管理费用、合规和监管费用、推广和时长费用、品牌费用等；还可包括与清分结果相关的属性，比如参与方得名称、参与方应付的费用名称等，本申请不作具体限定。

应理解，位图中的每个比特位所代表的计费属性可以根据实际的业务场景来确定，在对账时可能筛选的计费属性都可以作为位图中的比特位，比如用户有需求筛选支付渠道为某个银行的全部交易的计费结果，那么银行编号可以作为一个比特位，比如用户有需求筛选某一天所有交易数据的计费结果，那么交易日期可以作为一个比特位，因此位图中每个比特位所代表的计费属性是可以根据用户需求灵活设定的，也可以使得后续对账读取计费结果的效率更高，提高对账效率。

进一步地，单笔计费单元420可以根据位图建立明细表，其中，明细表与位图之间存在映射关系，一个位图对应一个明细表，位图用于记录计费结果中包含的计费属性，明细表用于记录计费属性对应的值。比如位图记录计费结果包含网络服务费，那么位图对应的明细表记录有网络服务费的金额为2元。需要说明的，明细表也可以存储于存储装置480中，明细表与位图之间的映射关系也存储于存储装置480中。

举例来说，位图包括5个比特位，第一位表示网络服务，第二位表示品牌费，第三位表示银行手续费，第四位表示业务参与价(一些特定业务需要参与方额外支付的费用，比如入场费、入会费等)，第五位表示推广费用，如果计费结果包括渠道成本总金额为5元，其中包括1元网络服务费，2元品牌费，2元银行手续费，那么该计费结果的位图可以为：(1,1,1,0,0)，该位图对应的明细表中包括网络服务费的金额为1元，品牌费的金额为2元，银行手续费的金额为2元。应理解，上述举例用于说明，本申请不作具体限定。

应理解，将每笔交易的计费结果通过位图记录每笔交易的计费结果所包含的计费属性，然后通过明细表记录每个计费属性具体的值，该种实现方式下，位图不仅可以有效地节省存储空间，还可以通过掩码、位运算等方式快速筛选出满足特定计费属性的计费结果，检索方式更加快速，提高数据查询效率，同时位图也容易扩展，添加新的计费属性时，可以通过扩展位图和明细表来支持新的计费属性，不需要修改整个数据结构，使得计费结果更加容易维护。

第一合并单元430用于将多个计费结果进行合并，获得合并记账结果。

可选地，第一合并单元430可以将包含相同合并计费属性的多个计费结果进行合并，获得合并记账结果，其中，合并计费属性可以是管理用户设置的，或者对账系统400默认设置的，比如合并计费属性是某个时间点或者时间段，第一合并单元430将该时间点或时间段内的全部计费结果进行合并，获得合并记账结果。或者合并计费属性是某个银行和某个时间段，第一合并单元430将该时间段内涉及该银行的全部计费结果进行合并，获得合并记账结果，本申请不对合并计费属性进行具体限定。

可选地，第一合并单元430可以根据合并计费属性，从位图中获取多个计费结果，然后进行合并。具体可以根据合并计费属性生成掩码，使用掩码对位图进行按位与操作，如果操作后的比特位得到的结果非零，说明该计费结果包含该比特位所表示的计费属性，如果操作后的比特位得到的结果是零，说明该计费结果包含该比特位所表示的计费属性。根据掩码的操作结果，可以获取出符合条件的位图，然后根据位图对应的明细表，获取满足合并计费属性的多个计费结果，进而获得合并记账结果。

举例来说，假设位图的定义为(网络服务费、品牌费、银行手续费、推广费)，位图1为0100，表示计费结果1包含品牌费，位图2为1101，表示计费结果2包含网络服务费、品牌费以及推广费，合并计费属性为推广费，使用掩码0001与位图进行按位与操作，位图1的操作结果为0000，位图2的操作结果为0001，所以位图2对应的计费结果包含推广费，可以被读取出。应理解，通过位图和掩码的方式来存储和读取计费结果，可以快速读取出大量满足条件的计费结果进行合并记账，提高合并记账的效率。

需要说明的，如果位图中不存在合并计费属性对应的比特位，可以从交易属性表中获取合并计费属性对应的多个交易数据，然后获取上述多个交易数据对应的位图，进而完成合并记账。

具体实现中，第一合并单元430可以在将多个计费结果进行合并时，可以先对多笔交易的渠道成本进行合并，获得合并计费金额，然后再基于合并计费金额生成合并记账结果，该合并记账结果包括合并计费金额以及其他信息。

合并计费金额包括多笔交易的渠道成本总金额以及多个类目的总金额，一个类目可以是多笔交易中的某一类手续费，比如清分费用总额、结算费用总额、网络费用总额、技术支持费用总额、风险管理费用总额、合规和监管费用总额、推广和时长费用总额、品牌费用总额等，一个类目还可以是多笔交易中某个计费属性筛选出的合并手续费，比如计算出多笔交易中，需要向A银行支付的渠道成本的总额，比如计算出多笔交易中，T1-T2时刻的需要支付的品牌费用总额等，比如计算出多笔交易中交易状态为已完成的渠道成本总额，具体可根据实际的业务需求确定，本申请不作具体限定。

其他信息可包括交易信息，比如每笔交易的交易时间、交易号、交易金额、支付渠道、交易状态等；合并记账结果还可包括计费结果，比如每笔交易的计费结果、计费规则、计费时间等；合并记账结果还可包括合并信息，比如合并日期、合并交易数量、合并总金额等；合并记账结果还可包括渠道成本信息，比如渠道名称、渠道费用、渠道成本合并总金额等；合并记账结果还可包括总计信息，比如交易总数量、交易总金额、计费总金额、渠道成本总额等，上述举例用于说明，合并记账结果还可包括更多的内容，具体可根据实际渠道成本对账时的业务需求来确定，本申请不作具体限定。

需要说明的，对账系统400可以提前设置有合并记账结果的模版信息，该模版信息包括合并记账结果中的一些必要的字段，比如上文描述的交易信息、计费结果、合并信息、渠道成本信息、总计信息等，该模版信息可以是用户配置的，也可以是对账系统400预先推荐配置的，本申请不作具体限定。这样，第一合并单元430可以根据模板信息中所需填充的字段，获得各种合并金额，填充字段，生成合并记账结果。

进一步的，第一合并单元430可以根据不同的合并计费属性，获取多个合并组，然后对每一个合并组中的多个计费结果进行合并，获得多个合并组对应的多个合并记账结果。举例来说，合并计费属性分别为1月1日、1月2日、1月3日，那么1月1日的多个计费结果获得一个合并记账结果，1月2日的多个计费结果获得一个合并记账结果，1月3日的多个计费结果获得一个合并记账结果，上述举例用于说明，本申请不作具体限定。

可选地，第一合并单元430可以部署于多个实例，一个实例用于对一个合并组的多个计费结果进行合并，一个实例获得一个合并记账结果。应理解，通过多台实例并行生成合并记账结果，可以提高合并记账的效率。具体实现中，上述实例可以是物理机，也可以是虚拟机、容器，本申请不做具体限定。

需要说明的，一个或者多个合并计费属性可以筛选出一组或多组计费结果，一个合并组的多个计费结果分配给一个计算设备进行处理。一个或者多个合并计费属性可以筛选出多组计费结果，比如1月1日的多个计费结果数量拥有1000笔，那么可以500笔交易由A实例完成合并，500笔交易由B实例完成合并。

在一可能的实现方式中，对账系统400可以建立微服务架构，通过微服务架构分配计费合并任务至各个实例，一个计费合并任务用于实现对一个合并组的多个计费结果进行合并。其中，微服务架构包括多个实例，每个实例用于执行特定的任务，每个实例可以在物理机、虚拟机或容器中运行。进一步的，微服务架构还可以与分片流(sharding stream)技术结合，根据合并计费属性，生成多个计费合并任务，将多个计费合并任务分配各个微服务实例，使得多个实例并行完成多个计费合并任务。

应理解，通过分片流技术可以合理分配计费合并任务，确保每个计费合并任务的处理压力适中，避免单个计费合并任务处理负担过重，通过微服务架构实现实例的动态扩缩容，根据计费合并任务自动调整实例的数量，更好地满足业务的变化和发展。

具体实现中，分片流技术可以通过多种方式生成计费合并任务，比如根据合并计费属性筛选出多个计费结果之后，对每个计费结果的唯一标识符(比如交易号)进行取模分片，确保多个计费结果可以均匀地分配在不同的实例上，从而避免某个ID范围的计费结果被集中到同一个实例上，导致性能瓶颈，分配完毕后，每个实例分配到的多个计费结果是同一组的计费结果，多该组计费结果进行合并计费结果即为该实例需要完成的计费合并任务。应理解，上述举例用于说明，分片流技术还可以使用其他方式生成计费合并任务，比如基于分布式调度任务系统、消息队列、负载均衡器等技术手段实现计费合并任务的合理划分，本申请不作具体限定。

具体实现中，微服务架构可以通过多种方式实现动态扩缩容，比如利用容器编排平台实现自动化实例(容器)的部署、扩展和管理，举例来说，k8s的垂直自动扩缩容组件(vertical pod autoscaler,PVA)可以根据定义的指标(比如CPU使用率、内存使用率等)自动调整微服务实例的数量，确保在高峰期处理更多的请求，在低谷期减少资源占用。应理解，上述举例用于说明，微服务架构还可以结合更多的方式实现动态扩缩容，本申请不作具体限定。

在另一可能的实现方式中，对账系统400可以基于大数据平台，根据合并计费属性，筛选出多组计费结果，然后将多组计费结果进行合并，获得多个合并计费结果。上述大数据平台可包括但不限于hivesql、saprksql等。具体地，可以使用批处理或流处理的方式，获取多个计费结果、交易属性表以及位图等数据存储于hive、spark等这样的大数据平台的数据仓库中，hive、saprk等大数据平台提供了类似SQL的查询语言，方便进行复杂的数据分析，使得大数据平台可以根据不同的合并计费属性筛选出多组计费结果，完成每一个合并组的多个计费结果的合并，生成合并计费结果。

应理解，上文示例性给出了获取合并计费结果的两种可能的实现方式，本申请还可以通过其他实现方式获取合并计费结果，本申请不作具体限定，并且，还可以通过多种实现方式混合的方案实现合并计费，具体可根据实际的应用常见灵活设定合并方案，本申请不作具体限定。

接收单元440用于获取银行系统300发送的多笔交易的扣款结果。

具体实现中，银行系统300完成支付渠道扣款之后，会生成扣款结果，然后将扣款结果发送给第三发支付平台，以便第三方支付平台完成支付渠道的对账。其中，多笔交易的扣款结果可包括每一笔交易的单笔扣款结果，通常情况下，每个单笔扣款结果可包括该笔交易的交易属性以及扣款明细，交易属性可以参考前述内容，比如合并的每笔交易的交易时间、交易号、支付渠道编码、银行编码、交易金额、交易状态、交易类型、货币类型、商户编码、结算模式等，扣款明细可包括银行扣除的渠道成本包含的手续费类别以及各个手续费的金额，具体可根据实际的应用场景确定，本申请不作具体限定。

需要说明的，银行系统300发送的扣款结果可包括多笔交易的扣款结果，具体可根据银行系统300的实际业务常见确定，比如银行系统300可以每完成M笔扣款，向第三方支付平台发送M笔交易的扣款结果，也可以每小时发送一小时内完成的多笔交易的扣款结果，还可以每天固定时间，比如凌晨12点发送当天完成的多笔交易的扣款结果，还可以每个月发送月账单，每季度发送季度账单等，具体可根据实际的业务需求确定扣款结果所包含的交易笔数。

需要说明的，银行系统300是完成扣款的金融机构所维护的交易系统的统称，可以是一个银行的系统，比如X市Y区Z支行的交易系统，也可以是一类银行的系统，比如工行系统、交行系统、农行系统等，还可以是多个银行的系统，比如银联系统、网联系统、银网联系统等，本申请不作具体限定。

可选地，接收单元440可以根据扣款结果，生成扣款结果的交易属性表，以及扣款结果对应的位图，其中，交易属性表和位图的描述可参考前述第一合并单元430的相关描述，这里不重复赘述。

第二合并单元450用于根据合并计费结果对应的多笔交易，将多笔交易的扣款结果进行合并，获得合并计费结果对应的合并扣款结果。

具体实现中，第二合并单元450可以根据第一合并单元430所使用的合并计费属性，对多笔交易的扣款结果进行合并，获得合并扣款结果，使得合并扣款结果所对应的多笔交易，与合并计费结果所对应的多笔交易相同，合并计费结果所合并的多个计费结果所对应的多笔交易，即为合并计费结果对应的多笔交易。简单来说，合并计费结果与合并扣款结果的合并粒度需要保持一致，这样粒度一致的两个账目才能够完成对账。

同理，第二合并单元450可以将多个扣款结果进行合并时，先对多笔交易的扣款结果中所包含的各种手续费进行合并，获得合并扣款金额，再基于合并扣款金额生成合并扣款结果，该合并扣款结果不仅包括合并扣款金额，还可包括一些渠道成本对账时所需的信息，与第一合并单元430所生成的合并记账结果拥有相同的类目，比如每个合并扣款结果至少包括所合并的每笔交易的交易属性以及扣款信息，交易属性可以是每笔交易的交易时间、交易号等信息，扣款信息可以是每笔交易的扣款明细等，以便完成渠道成本对账。

同理，合并扣款金额与合并计费金额类似，合并扣款金额包括多个类目的总金额，多个类目包括多笔交易的渠道成本总金额，还包括渠道成本中的一种或者多种手续费的总金额，比如清分费用总额、结算费用总额、网络费用总额、技术支持费用总额、风险管理费用总额、合规和监管费用总额、推广和时长费用总额、品牌费用总额等，或者使用一些计费属性筛选出的合并手续费也可以作为一个类目，比如多笔交易中需要向A银行支付的渠道成本的总额等，具体可根据合并计费金额中所包含的类目来决定合并扣款金额所包含的类目，本申请不作具体限定。

应理解，合并扣款结果与合并计费结果所包含的字段是类似的，因为二者需要进行对账，所以生成合并扣款结果的过程与生成合并计费结果的过程是类似的，比如合并扣款结果可以与合并计费结果使用的相同的模版信息，或者二者使用的模版信息存在共同字段，对账时可以对共同字段下的值进行匹配，这里不重复赘述。

同理，第二合并单元450也可以部署于一个或者多个实例上，每个实例用于完成一个扣款合并任务，每个扣款合并任务用于实现一个合并组中多个扣款结果的合并，获得对应的合并扣款结果。一个或者多个合并计费属性可以筛选出多组扣款结果，比如1月1日的多个扣款结果数量拥有1000笔，其中400笔交易由实例C完成合并，600笔交易由实例D完成合并。

需要说明的，第二合并单元450对于扣款合并任务的划分粒度与第一合并单元430对于计费合并任务的划分粒度是一致的，也就是说，一个扣款合并任务可以与一个计费合并任务相对应，扣款合并任务所处理的多笔交易，与对应的计费合并任务处理的多笔交易是同一组交易，计费合并任务合并的是该组交易的计费结果，扣款合并任务合并的是该组交易的扣款结果。比如第一合并单元430对于200笔交易的计费结果进行了合并，那么第二合并单元450也需要对这200笔交易的扣款结果进行合并，获得与合并计费结果对应的合并扣款结果。

应理解，合并扣款结果的获取方式与前述合并记账结果的获取方式类似，具体可参考前述第一合并单元440的相关描述，比如第二合并单元450也可以通过微服务架构分配扣款合并任务至各个实例，通过分片流技术合理划分扣款合并任务，并且第二合并单元450使用的微服务架构的参数以及分片流技术的参数与第一合并单元430所使用的保持一致，确保最终获得的合并扣款结果与合并计费结果是同一组交易的合并结果，这里不再重复赘述。

需要说明的，接收单元440在接收到银行系统300发送的扣款结果之后，需要根据扣款结果生成交易属性表和位图，这样后续第二合并单元450也可以根据交易属性表和位图读取出需要合并的扣款结果，图1中只绘制出了单笔计费单元420生成的位图，但是实际存储装置480中还额外存储有接收单元440根据扣款结果生成的位图以及交易属性表，本申请不对此进行限定。应理解，为了便于区分，本文将计费结果的位图称为计费位图，将扣款结果的位图称为扣款位图。

可选的，对账系统400会建立合并扣款结果与合并记账结果之间的映射关系，同一个合并组的合并扣款结果与合并记账结果之间建立有映射关系。

对账单元460用于根据存在对应的关系的合并记账结果和合并扣款结果完成渠道成本对账，获得对账结果。

应理解，由于第二合并单元450和第一合并单元430使用了相同的合并粒度完成扣款结果以及计费结果的合并，因此可以将同一个合并组的交易对应的合并记账结果和合并扣款结果进行对账，获得对账结果，不属于同一组交易对应的合并结账结果和合并扣款结果不能进行对账。

可选地，对账结果包括合并记账结果与对应的合并扣款结果之间的差异信息。该差异信息可包括合并计费金额与合并扣款金额之间的差值，该差值也可以进一步进行细分，包括多个类目的手续费总额之间的差值，比如清分费用总额差值、结算费用总额差值、网络费用总额差值、技术支持费用总额差值等，还包括使用一些计费属性筛选出的合并手续费差值，比如多笔交易中需要向A银行支付的渠道成本的总额差值等，具体可根据实际的业务场景决定差异信息的详细内容，本申请不作具体限定。

应理解，合并扣款金额与合并计费金额如果相同则表示该组交易的多个交易数据的计费和扣款是一致的，这一组交易的交易数据都可以进行核销，不需要对该组交易中的每一笔交易进行对账，这样通过多笔交易合并后进行渠道成本对账的方式，可以提高对账的效率。

可选地，对账结果不仅包括上述差异信息，还可包括其他信息，比如参与对账的多笔交易的交易属性，比如对账的时间等，具体可根据实际的业务需求确定对账结果所包含的内容，本申请不作具体限定。

分析单元470用于根据对账结果和预警策略，获得预警信息，将预警信息发送给客户端100进行处理。

可选地，预警策略可包括差异阈值，如果上述差异信息中的差值超过该差异阈值即可生成预警信息。具体实现中，差异阈值的数量可以是一个或者多个，不同差异阈值对应不同类目的手续费差值，比如计费总额与扣款总额之间的差值对应一个差异阈值，某个类目的手续费总额的差值对应一个差异阈值，本申请不作具体限定。

可选地，当差异信息中的差值不超过该差异阈值，该差值对应的一组交易的交易数据可以进行核销。应理解，如果差值较小，比如只差了几分钱或者几块钱，那么可以忽略不计，不需要再一笔一笔进行对账。比如1000笔交易合并后进行渠道成本对账，发现合并计费金额与合并扣款金额差了1块钱，那么为了这1块钱去对1000笔交易一一核对，十分浪费人力物力财力，此时可以通过设置差异阈值的方式对这一类差值较小、可以忽略不计的交易直接进行核销，提高渠道成本对账的效率。

可选的，当差异信息中的差值超过该差异阈值，分析单元470可以生成预警信息，该预警信息可包括上述差异信息，还可包括一些用于供管理用户定位分析差异原因的其他信息，比如其他信息可包括对账时间、交易状态、差异明细等，其中，差异明细可包括存在差异的交易的交易数据，以及该交易具体是哪一部分手续费核对不上的信息，以供管理用户定位对账失败的原因。

具体实现中，在确定差异明细时，可以通过计费位图和扣款位图读取每一笔交易的计费结果和扣款结果，然后将每一笔交易的计费结果与扣款结果进行核对后，确定存在差异的交易，然后对每笔存在差异的交易，进一步核对每一项手续费的计费和扣款是否一致，从而确定是哪一笔交易的哪一项手续费的计费和扣款核对不上，生成差异明细，以供管理用户定位对账失败的原因。上述举例用于说明，本申请不对差异明细的具体内容进行限定。

应理解，如果使用传统的渠道成本对账方式，每一笔交易的计费结果需要与每一笔交易的扣款结果进行核对，如果一笔交易核对不齐，都需要人工进行分析问题原因，然后进行调账，使得计费结果与扣款结果正确，效率低下。本申请将多笔交易多个计费结果进行合并，将多个扣款结果进行合并，然后将合并计费结果与合并扣款结果进行核对，如果二者差值较小，可以将多笔交易直接核销，如果差值较大，管理用户再根据差异明细中多笔差异交易，确定差异原因，该方式可以提高对账效率，不需要对每一笔账单都进行核对。

进一步的，管理用户通过客户端100获取到预警信息之后，可以根据预警信息中的差异明细，定位对账失败的原因，然后调整计费模型，更新计费位图以及计费位图对应的明细表，获得信息合并记账结果，将合并记账结果与合并扣款结果进行对账，如果差异低于阈值则进行核销，如果差异仍然高于阈值，则需要管理人员重新调整计费模型。应理解，该方式中，用户只需要查询账目然后定位对账失败原因，调整计费模型即可，不需要对成千上万笔对账不一致的账目进行调账，调账是一个非常繁杂的步骤，而且非常依赖人工操作，本申请提供的对账方式不需要进行调账，整个对账流程可以自动化实现，管理人员只需要分析定位对账失败原因，调整计费模型即可，极大降低人工处理压力，提高管理人员的工作效率。

举例来说，传统方式核对1000笔渠道成本账目时，需要对1000笔交易一一核对计费结果和扣款结果，从中核对出200笔错误账单之后，管理人员需要对200笔错误账单一一定位人工定位原因，比如确定不一致原因为银行手续费百分比临时调整，管理人员需要将200笔计费结果按照新的手续费百分比，对200笔交易的渠道成本账目进行调账。使用本申请提供的对账方法，对账系统400通过计费模型自动获得1000笔交易的计费结果后，多个实例并行计算每200笔交易的合并记账结果和合并扣款结果，然后自动核对5组合并记账结果和合并扣款结果，若这200笔对账失败的交易的差值低于阈值，可以直接自动核销，对账效率极大加快；若这200笔交易的差值高于阈值，可以生成差异明细显示给管理用户，管理用户人工定位原因之后，只需要修改计费模型，对账系统400即可自动更新合并记账结果，自动核销这1000笔交易。该方式中，管理用户不需要一笔一笔调账，只需要修改计费模型即可完成渠道成本对账的核销，整个流程十分简单、快捷，提高用户的使用体验。

综上可知，本申请提供了一种对账系统，该系统可以从支付渠道系统获取多笔交易的交易数据，基于计费模型确定每笔交易的支付渠道成本的计费结果，然后从银行系统获取每笔交易的支付渠道成本的扣款结果，再将多笔交易的计费结果进行合并获得合并计费结果，将多笔交易的扣款结果进行合并获得合并扣款结果，确定合并计费结果和合并扣款结果之间的差值，在差值超过预警阈值的情况下，向管理用户发送预警信息以指示用户更新该计费模型，使得渠道成本对账时可以进行合并对账，不需要一笔一笔进行对账，提高对账效率，同时，管理用户可以根据预警信息更新计费模型即可，不需要再一笔一笔调整账目，提高对账效率，降低人力成本，提高用户的使用体验。

上文详细描述了本申请提供的对账系统，下面结合图2-图8对本申请提供的对账方法进行解释说明。

图2是本申请提供的一种对账方法的步骤流程示意图，该对账方法可应用于如图1所示的对账系统400中，如图2所示，该方法可包括以下步骤：

S201：客户端100向对账系统400发送计费模型的配置请求。该步骤可由图1实施例中的配置单元410实现。

可选地，配置请求可包括用户请求设置的计费模型的信息，该计费模型的信息可包括计费要素和计费规则，每个计费规则对应一组计费要素，根据每个交易数据包含的计费要素，可确定该交易数据需要使用的计费规则。

可选地，计费要素可包括一些用于判定交易数据需要使用的计费规则的必要信息，比如支付渠道名称、支付渠道产品名称、机构代码、渠道类型、渠道子类型、银行名等，具体可参考图1实施例的相关描述，这里不重复赘述。

可选地，计费规则可包括渠道手续费的计费方式，比如计费规则可包括计费类型、费用生效时间以及计费模式。其中计费类型用于区分计费方式，费用生效时间用于定义计费的生效时间范围，计费模式用于描述计费类型下的计费细节，计费类型、费用生效时间以及计费模式可以组成一个完整的计费规则，具体可参考图1实施例的相关描述，这里不重复赘述。其中，计费类型包括单笔计费、单笔梯度计费、金额累计梯度计费等计费方式。费用生效时间可包括即时生效、每日生效、每月生效等生效时间等。计费模式可包括固定费用、百分比费用、混合计费等。具体可参考图1实施例的相关描述，这里不重复赘述。计费模型还可包括更多的内容，这里不一一举例说明。

可选地，对账系统400可以预先生成多种计费要素和计费规则，管理用户可以从中选择计费要素和计费规则进行映射，获得计费要素和计费规则之间的对应关系，完成计费模型的配置。具体地，管理用户可以使用可视化界面(graphical user interface,GUI)发起配置请求，客户端100可以向管理用户显示可选择的计费要素和计费规则，对账系统400可以根据管理用户所选择的计费要素和计费规则，生成计费模型存储于存储装置480中，使得后续对交易数据进行计费时，可以根据计费模型完成计费。

示例性的，图3是本申请提供的一种配置界面的示例图，客户端100可以向管理用户显示该界面，管理用户可以从中选择需要配置的计费要素和计费规则，完成计费模型的配置，进而发起携带有该计费模型的配置请求给对账系统400。如图3所示，该配置界面可包括计费要素配置区域310、计费规则配置区域320以及确认控件330。

计费要素配置区域310可显示多个计费要素，示例性的，图3给出了一些可能的计费要素。在图3所示的例子中，渠道产品名称、渠道名称、分支机构名称、机构代码、渠道类型、渠道子类型、银行分组、银行名称可以是交易属性这一类的计费要素，结算模式、手续费收取方式、手续费收取周期可以是计费属性这一类的计费要素。其中，交易属性是与交易数据相关的，描述交易本身的一部分字段、信息，计费属性是与渠道成本计费过程相关的，描述渠道成本计费的一部分字段、信息。具体可参考图1实施例中的相关描述，这里不重复赘述。

计费规则配置区域320可显示多个计费规则，示例性的，图3给出了一些可能的计费规则。在图3所示的例子中，计费类型包括单笔计费、单笔梯度计费、金额累计梯度计费。其中，以选择单笔计费为例，其需要配置的参数报考费用生效时间、计费模式、手续费金额、品牌费金额、网络服务器金额、应付业务参与价金额等，应理解，如果选择单笔梯度计费，图3中计费规则中需要配置的参数可能会发生变化，本申请不作具体限定。

确认控件330用于供用户确认配置的计费规则和计费要素，用户点击确认控件330之后，客户端100可以发送携带有上述计费规则和计费要素的配置请求给对账系统400。

应理解，本申请通过预先配置计费要素和计费规则，然后管理用户通过选择的方式来配置计费模型，使得模型的配置更加简单、快捷、灵活，提高用户的使用体验。当然，管理用户可以通过修改配置文件、通过GUI导入模型等方式实现计费模型的自定义配置，本申请不作具体限定。

可选地，对账系统400根据配置请求生成的计费模型是一个计算模型，交易数据输入该计费模型即可获得计费结果，计费模型可以将交易数据与计费模型中的计费要素进行匹配，确定该交易数据对应的计费规则，然后使用该计费规则完成计费，计费模型可包括需要计算的手续费种类以及对应的费用计算方式，手续费种类包括渠道手续费、清分费用、结算费用、网络费用、技术支持费用、风险管理费用、合规和监管费用、推广和时长费用、品牌费用等，费用的计算方式可根据具体的业务场景来确定，本申请不作具体限定。

S202A：支付渠道系统200向对账系统400发送多笔交易的交易数据。该步骤可由图1实施例中的单笔计费单元420实现。

可选地，商城用户通过第三方支付平台的商城系统下单后，商城系统可生成支付指令，然后将支付指令发送给支付渠道系统200，支付渠道系统200根据支付指令生成交易数据，然后将交易数据发送给第三方支付平台的对账系统400的单笔计费单元420，同时将交易数据发送给银行系统300完成渠道手续费的扣款，银行系统300生成渠道扣款账单后将其反馈给对账系统400，使得对账系统400可以根据交易数据和渠道扣款账单完成渠道成本对账。

具体实现中，支付指令是生成的支付指令，该支付指令可包括支付金额、支付方式、收款方信息、支付发起方信息、交易描述、交易流水号、支付时间戳等信息。交易数据是支付渠道系统200根据支付指令生成的，交易数据可以是多笔交易的交易数据，每笔交易数据包括交易金额、交易状态、交易时间、支付流水号、支付渠道信息、支付渠道流水号、商户信息、商城用户信息等。上述举例用于说明，支付指令和交易数据还可以包括更多的内容，这里不一一举例说明。

S202B：支付渠道系统200向银行系统300发送多笔交易的交易数据。该步骤可由图1实施例中的接支付渠道系统200以及银行系统300实现。

应理解，该交易数据与S202A的交易数据相同，但是交易数据的数量可以相同或者不同，具体可根据实际的业务需求确定，本申请不作具体限定。

S203：对账系统400基于计费模型，确定每笔交易的计费结果。该步骤可由图1实施例中的单笔计费单元420实现。

可选地，对账系统400可以根据每笔交易的交易数据，确定每笔交易的交易属性，生成交易属性表，其中，交易属性表包括多个字段，每个字段代表一个交易属性，交每一行数据对应拥有多个相同交易属性的一批交易数据。这样，对账系统400可以根据每一行数据的交易属性，确定每一批交易数据对应的计费模型，根据每一批交易数据对应的计费模型，确定每一批交易数据中每笔交易的计费结果。应理解，将多笔拥有相同交易属性的交易进行合并，可以使得交易属性表中的一行数据可以使用同一个计费模型进行渠道成本的计费，提高计费效率。

具体实现中，交易属性用于描述该笔交易的交易数据的相关特征，比如交易属性可包括交易时间、支付渠道编码、银行编码、交易金额、交易状态、交易类型、货币类型、商户编码、结算模式等等，应理解，上述交易属性的举例用于说明，本申请不作具体限定。需要说明的，每笔交易可以是表数据，因此交易属性可以理解为该表数据中包含的字段。

可选地，由于交易数据的数据量往往会非常庞大，为了确保读取交易数据计算渠道成本时，数据可以被高效读取，此时可以为每一批交易数据分配一个索引，具体可以在交易属性表中额外维护一个索引字段，该索引可以是多个字段的哈希值，这样每行数据可以对应一个索引，使用索引可以查询出每一行交易数据，提高数据查询的效率。

可选地，若存在哈希值相同的多行交易数据，可以将相同哈希值对应的多行数据拼接成一条链表，一行数据可以对应链表的一个链表节点，具体可以在交易属性表中额外维护一个用于确定链表节点的字段，比如链表节点序列，或者前置节点序列等，使得相同哈希值的多行交易数据可以拼接成一条链表，每行交易数据对应不同的链表节点。这样在查询数据时，如果根据索引获得多行交易数据，可以先读取该哈希值对应的整个链表，然后按照链表节点字段描述的节点顺序，依次遍历每个链表节点对应的交易数据，直至找到满足查询条件的交易数据，从而避免由于哈希冲突导致索引失效的问题。其中，链表节点可以是按照添加顺序进行排列。其中，链表和索引字段的举例可参考前述内容中的表1和表2实施例，这里不重复赘述。

可选地，对账系统400可以根据交易属性表，确定每一批交易数据中每笔交易的渠道成本的计费结果，计费结果可包括每笔交易的渠道成本明细以及清分结果，其中，渠道成本明细和清分结果的描述可参考图1实施例的相关描述，这里不重复赘述。具体实现中，对账系统400在确定每一批交易数据的计费结果时，可以根据S201配置好的计费模型中的计费要素和对应的计费规则，将交易数据与计费要素进行匹配，确定该交易数据需要使用的计费规则，然后基于计费规则确定交易数据的计费结果。

可选的，对账系统400可以在获得每笔交易的计费结果之后，生成每笔交易的计费结果对应的计费位图。其中，位图包括多个比特位，每个比特位用于描述计费结果中的一个计费属性，比特位的值用于指示该计费属性是否存在。其中，计费属性用于描述计费结果中的相关特征，计费属性包括计费结果对应的交易数据的交易属性，还包括计费结果中与渠道成本明细相关的属性，还可包括与清分结果相关的属性，本申请不作具体限定。

进一步地，对账系统400还可根据位图建立明细表，其中，明细表与位图之间存在映射关系，一个位图对应一个明细表，位图用于记录计费结果中包含的计费属性，明细表用于记录计费属性对应的值。比如位图记录计费结果包含网络服务费，那么位图对应的明细表记录有网络服务费的金额为2元。需要说明的，明细表也可以存储于存储装置480中，明细表与位图之间的映射关系也存储于存储装置480中。

应理解，将每笔交易的计费结果通过位图记录每笔交易的计费结果所包含的计费属性，然后通过明细表记录每个计费属性具体的值，该种实现方式下，位图不仅可以有效地节省存储空间，还可以通过掩码、位运算等方式快速筛选出满足特定计费属性的计费结果，检索方式更加快速，提高数据查询效率，同时位图也容易扩展，添加新的计费属性时，可以通过扩展位图和明细表来支持新的计费属性，不需要修改整个数据结构，使得计费结果更加容易维护。

举例来说，图4是本申请提供的一种位图的示例图，在图4所示的例子中，位图的每个比特位用于指示一个计费属性，如果计费结果包括该计费属性，该比特位的值为1，如果不包括该计费属性，该比特位的值为0。

在图4所示的例子中，每个比特位所指示的计费属性可以分为三种类型，分别为结算模式类型、费用类型和计费类型，其中，结算模式类型包括不涉及结算、全额结算和轧差结算等计费属性，费用类型包括业务参与价、品牌费、网络服务费和银行手续费等计费属性，计费类型包括金额累计阶梯、包量梯度和单笔梯度等计费属性。示例性的，图4给出了一个位图的示例：1001101101，表示该笔计费结果的结算模式类型为不涉及结算，费用类型报考业务参与价、品牌费以及银行手续费，计费类型为金额累计阶梯和单笔梯度。

再举例来说，图5是本申请提供的另一种位图的示例图，图5与图4的区别在于，图4所示的位图中的多个比特位按照不同的类型横向排列，图4所示的位图类似于一个向量，图5所示的位图中的多个比特位按照不同的类型纵向排列，类似于一个矩阵。图5中第一行的多个比特位用于指示结算模式类型，第二行的多个比特位用于指示费用类型，第三行的多个比特位用于指示计费类型。因此图4所示的位图1001101101也可以表示为图5所示的矩阵。应理解，图4和图5用于举例说明，本申请不作具体限定。

进一步的，图4和图5所示的位图对应的明细表中，可以记录有业务参与价、品牌费、银行和手续费的明细，还有计费类型中接累计阶梯的参数，单笔梯度的参数等，在读取每笔交易的计费结果时，用户可以发送携带有计费属性的查询请求，对账系统400可以根据查询请求中的计费属性，读取包含该计费属性的位图和对应的明细表，从而读取出用户请求查询的计费结果。

需要说明的，图4所示的例子中，位图只有一行类似一个向量，具体实现中，位图也可以存在多行，类似一个矩阵，每一行的每个比特位都可以用来指示一个计费属性，每一行可以代表一类计费属性，比如图4所示的例子中，第一行可以是结算模式类型的多个比特位，第二行可以使费用类型的多个比特位，第三行是计费类型的多个比特位，图4用于举例说明，本申请不作具体限定。

S204：银行系统300向对账系统400发送多笔交易的扣款结果。该步骤可由图1实施例中的接收单元440实现。

具体实现中，银行系统300完成支付渠道扣款之后，会生成扣款结果，然后将扣款结果发送给第三方支付平台，以便第三方支付平台完成支付渠道的对账。其中，多笔交易的扣款结果可包括每一笔交易的单笔扣款结果，通常情况下，每个单笔扣款结果可包括该笔交易的交易属性以及扣款明细，交易属性可以参考前述内容，比如合并的每笔交易的交易时间、交易号、支付渠道编码、银行编码、交易金额、交易状态、交易类型、货币类型、商户编码、结算模式等，扣款明细可包括银行扣除的渠道成本包含的手续费类别以及各个手续费的金额，具体可根据实际的应用场景确定，本申请不作具体限定。

可选地，对账系统400可以根据扣款结果，生成扣款结果的交易属性表，以及扣款结果对应的扣款位图，其中，交易属性表和位图的描述可参考前述S203的相关描述，这里不重复赘述。

S205：对账系统400将多笔交易的计费结果进行合并获得合并计费结果，将多笔交易的扣款结果进行合并获得合并扣款结果。该步骤可由图1实施例中第一合并单元430以及第二合并单元450实现。

下面对合并计费结果的获取过程进行详细说明，合并扣款结果的获取过程与其类似，这里不重复展开赘述。

可选的，对账系统400可以将包含相同合并计费属性的多个计费结果进行合并，获得合并记账结果，其中，合并计费属性可以是管理用户设置的，或者对账系统400默认设置的。具体实现中，对账系统400可以根据合并计费属性生成掩码，使用掩码对每笔交易的计费位图进行按位与操作，如果操作后的比特位得到的结果非零，说明该计费位图对应的计费结果包含该比特位所表示的计费属性，如果操作后的比特位得到的结果是零，说明该计费结果不包含该比特位所表示的计费属性。根据掩码的操作结果，可以获取出符合条件的位图，然后根据位图对应的明细表，获取满足合并计费属性的多个计费结果，进而获得合并记账结果。需要说明的，如果位图中不存在合并计费属性对应的比特位，可以从交易属性表中获取合并计费属性对应的多个交易数据，然后获取上述多个交易数据对应的位图，进而完成合并记账。

图6是本申请提供的一种基于掩码读取包含合并计费属性的计费位图的步骤示例图，仍以图4所示的位图格式为例，假设位图1为1001101101，位图2为0100111011，位图3为0010011001，假设掩码1为0000100000，表示需要筛选出费用类型包含品牌费的计费结果，掩码2为0000010000，表示需要筛选出费用类型包含网络服务费的计费结果，那么使用掩码1对位图1～位图3进行操作后，可以筛选出位图1和位图2，使用掩码2对位图1～位图3进行操作后，可以筛选出位图2和位图3。应理解，通过掩码对位图进行操作的方式读取包含某种计费属性的计费结果，该方式无需逐一比较每个字段的值，更加简单快捷，提高数据读取的效率。同时，位图这种紧凑的存储形式可以减少数据的存储空间需求，节省内存。

可选的，对账系统400在通过位图和合并计费结果读取到需要合并的多个计费结果之后，先对多笔交易的渠道成本进行合并，获得合并计费金额，然后再基于合并计费金额生成合并记账结果。最终生成的合并记账结果可包括合并计费金额以及其他信息，其中，合并计费金额包括多个类目的总金额，多个类目包括多笔交易的渠道成本总金额，还包括渠道成本中的一种或者多种手续费的总金额。其他信息可包括一些渠道成本对账时所需的信息，比如交易信息、计费结果、合并信息、渠道成本信息、总计信息等，本申请不作具体限定。

可选的，对账系统400可以根据不同的合并计费属性，获取多个合并组，然后对每一个合并组中的多个计费结果进行合并，获得多个合并组对应的多个合并记账结果。进一步地，对账系统400可以部署于多个实例，一个实例用于对一个合并组的多个计费结果进行合并，一个实例获得一个合并记账结果。应理解，通过多台实例并行生成合并记账结果，可以提高合并记账的效率。具体实现中，上述实例可以是物理机，也可以是虚拟机、容器，本申请不做具体限定。需要说明的，一个或者多个合并计费属性可以筛选出一组或多组计费结果，一个合并组的多个计费结果分配给一个计算设备进行处理。一个或者多个合并计费属性可以筛选出多组计费结果，比如1月1日的多个计费结果数量拥有1000笔，那么可以500笔交易由A实例完成合并，500笔交易由B实例完成合并。

在一可能的实现方式中，对账系统400可以建立微服务架构，通过微服务架构分配计费合并任务至各个实例，一个计费合并任务用于实现对一个合并组的多个计费结果进行合并。微服务架构还可以与合分片流技术结合，根据合并计费属性，生成多个计费合并任务，将多个计费合并任务分配各个微服务实例，使得多个实例并行完成多个计费合并任务。具体实现中，分片流技术可以通过多种方式生成计费合并任务，比如对每个计费结果的唯一标识符(比如交易号)进行取模分片，确保多个计费结果可以均匀地分配在不同的实例上，从而避免某个ID范围的计费结果被集中到同一个实例上，导致性能瓶颈，分片流技术还可以使用其他方式生成计费合并任务，比如基于分布式调度任务系统、消息队列、负载均衡器等技术手段实现计费合并任务的合理划分，本申请不作具体限定。微服务架构可以通过多种方式实现动态扩缩容，比如利用容器编排平台实现自动化实例(容器)的部署、扩展和管理，本申请不作具体限定。

在另一可能的实现方式中，对账系统400可以基于大数据平台，根据合并计费属性，筛选出多组计费结果，然后将多组计费结果进行合并，获得多个合并计费结果。上述大数据平台可包括但不限于hivesql、saprksql等。

应理解，上文示例性给出了获取合并计费结果的两种可能的实现方式，本申请还可以通过其他实现方式获取合并计费结果，本申请不作具体限定，并且，还可以通过多种实现方式混合的方案实现合并计费，具体可根据实际的应用常见灵活设定合并方案，本申请不作具体限定。

同理，可以根据合并计费属性，对多笔交易的扣款结果进行合并，获得合并扣款结果，需要注意的是，合并计费结果与合并扣款结果的合并粒度需要保持一致，这样粒度一致的两个账目才能够完成对账。因此，合并扣款结果与合并计费结果所包含的字段是类似的，对账时可以对相同字段下的值进行匹配。

同理，在合并多笔交易的扣款结果时，也可以生成多个扣款合并任务，将多个扣款合并任务交给一个或者多个实例进行处理，每个扣款合并任务用于实现一个合并组中多个扣款结果的合并，获得对应的合并扣款结果。需要说明的，扣款合并任务的划分粒度与计费合并任务的划分粒度是一致的，也就是说，一个扣款合并任务可以与一个计费合并任务相对应，扣款合并任务所处理的多笔交易，与对应的计费合并任务处理的多笔交易是同一组交易，计费合并任务合并的是该组交易的计费结果，扣款合并任务合并的是该组交易的扣款结果。其中扣款合并任务的划分和处理可参考前述计费合并任务的划分和处理方式，比如微服务架构和分片流技术来实现，或者基于大数据平台实现，这里不重复赘述。

需要说明的，生成的每个合并扣款结果可以对应一个扣款位图，扣款位图的描述与计费位图的描述类似，并且，对账系统400会建立合并扣款结果与合并记账结果之间的映射关系，一个合并组的合并扣款结果与合并记账结果之间建立有映射关系。

S206：对账系统400确定合并计费结果与合并扣款结果之间的差值是否大于预警阈值。该步骤可由图1实施例中的对账单元460实现。

具体实现中，合并计费结果与合并扣款结果之间的差值可以是一个或者多个，每个差值可以对应合并计费结果和合并扣款结果中的一个类目的手续费的差值，比如渠道成本总金额的差值，清分费用总额的差值、结算费用总额的差值、网络费用总额的差值等，预警阈值的数量也可以是一个或多个，一个类目的手续费的差值对应一个预警阈值，比如渠道成本总金额预警阈值用于判断渠道成本总金额的差值是否超额，清分费用总额预警阈值用于判断清分费用总额的差值是否超额等，本申请不作具体限定。

可选的，在差额不大于预警阈值的情况下，执行S207，在差额大于预警阈值的情况下，执行S208和S209。应理解，在差值不大于预警阈值的情况下，说明一个合并组的多笔交易的合并计费结果与合并扣款结果十分接近，对于多笔交易来说，出现很小的差额对整体财务影响不大，此时可以直接忽略不计，比如1000笔交易的合并计费结果与合并扣款结果之间差了1分钱，那么去一笔一笔的查账确定这1分钱的差别十分消耗人力物力，本申请通过合并对账的方式，可以将这一类差额较小的多笔订单直接核销，提高渠道成本对账的效率。

需要说明的，如果存在多个差值和多个预警阈值，可以根据多个差值与对应预警阈值的比较结果，来确定合并计费结果与合并扣款结果之间的差值是否高于预警阈值。比如当3个以上的差值超过其对应的预警阈值后，确定合并计费结果与合并扣款结果之间的差值是高于预警阈值，当然还可以用其他规则来根据多个差值与对应预警阈值的比较结果，确定合并计费结果与合并扣款结果之间的差值是否高于预警阈值，本申请不对此规则进行限定。

S207：对账系统400对多笔交易进行渠道成本的核销操作。该步骤可由图1实施例中的分析单元470实现。

应理解，核销操作的描述可参考前述内容，这里不重复赘述。

S208：对账系统400向客户端100发送预警信息。该步骤可由图1实施例中的分析单元470实现。

具体实现中，该预警信息可包括上述多个差值，还可包括一些用于供管理用户定位分析差异原因的其他信息，比如其他信息可包括对账时间、交易状态、差异明细等，其中，差异明细可包括存在差异的交易的交易数据，以及该交易具体是哪一部分手续费核对不上的信息，以供管理用户定位对账失败的原因。

具体实现中，在确定差异明细时，可以通过计费位图和扣款位图读取每一笔交易的计费结果和扣款结果，然后将每一笔交易的计费结果与扣款结果进行核对后，确定存在差异的交易，然后对每笔存在差异的交易，进一步核对每一项手续费的计费和扣款是否一致，从而确定是哪一笔交易的哪一项手续费的计费和扣款核对不上，生成差异明细，以供管理用户定位对账失败的原因。上述举例用于说明，本申请不对差异明细的具体内容进行限定。

S209：客户端100向对账系统400发送计费模型的修改请求。该步骤可由图1实施例中的配置单元410实现。

可以理解的，管理用户通过客户端100获取到预警信息之后，可以根据预警信息中的差异明细，定位对账失败的原因，然后调整计费模型，更新计费位图以及计费位图对应的明细表，获得信息合并记账结果，将合并记账结果与合并扣款结果进行对账，如果差异低于阈值则进行核销，如果差异仍然高于阈值，则需要管理人员重新调整计费模型。应理解，该方式中，用户只需要查询账目然后定位对账失败原因，调整计费模型即可，不需要对成千上万笔对账不一致的账目进行调账，调账是一个非常繁杂的步骤，而且非常依赖人工操作，本申请提供的对账方式不需要进行调账，整个对账流程可以自动化实现，管理人员只需要分析定位对账失败原因，调整计费模型即可，极大降低人工处理压力，提高管理人员的工作效率。

为了使本申请能被更好地理解，下面结合图7对本申请提供的对账方法的有益效果进行具体说明，图7是本申请提供的一种渠道成本对账界面的示例图，该界面可以在管理用户通过图3所示的界面配置好计费模型，对账系统400开始按照该计费模型进行渠道成本对账之后，执行S203～S208之后向用户显示的界面。如图7所示，该界面可包括查询区域710、工具栏720以及对账结果显示区域730。

查询区域710用于输入需要查询的查询属性，比如图7所示的渠道产品名称、渠道名称和交易时间，用户点击查询之后，下方的对账结果显示区域730可以显示出符合查询属性的数据。其中，输入的查询属性可以是前述内容中的合并计费属性、交易属性、计费属性、扣款属性等任意属性，本申请不作具体限定。

工具栏720包括多个控件，图7示例性给出了几个可能的控件，比如预警控件、分析控件、对账控件、核销控件、修改模型控件以及重新统计控件，其中，预警控件用于向用户发送预警信息，在图7所示的例子中，预警信息可以包括差额和差额笔数，将需要分析的合并组的差额和差额笔数用深色标识出，用户可以通过对账结果显示区域730中的深色标识，快速定位需要处理的差额；分析控件用于查询差额超出预警阈值的合并组的差异明细；对账控件用于开始渠道成本对账，使得对账系统400开始执行S202A～S209；核销控件用于指示对账系统400开始执行S207，将差额低于预警阈值的合并组内的多笔交易进行渠道成本核销处理；修改模型控件用于供管理用户修改计费模型的配置参数；重新统计控件用于供管理用户在修改好计费模型的配置参数之后，使用新的计费模型更新合并计费结果、差额、差额笔数等信息。应理解，工具栏720还可以根据使用需求配置更多控件，本申请不作具体限定。

对账结果显示区域730用于显示对账结果和预警信息。

在图7所示的例子中，序列1和序列5的合并组均存在差额，也就是合并计费结果与合并扣款结果不相同，假设预警阈值为1元，那么序列5的合并组的差额只有0.01元，差额低于预警阈值，可以与其他不存在差额的合并组一起进行核销操作。而序列1的合并组差额远超于预警阈值，需要管理用户分析定位差异原因，修改计费模型参数，重新统计合并计费结果，直至序列1的合并组也可以完成核销操作。

应理解，管理用户可以通过工具栏720中的修改模型控件，修改计费模型的配置参数，比如管理用户点击修改模型控件之后，客户端100可以向管理用户显示图3所示的界面，用户定位差异原因之后，比如确定是银行临时下调手续费，此时可以修改计费规则中银行手续费的金额，然后回到图7所示的界面中，点击重新计费控件。

应理解，通过图7所示的界面，用户可以直观、快捷的获知对账失败的多笔交易，而不需要一笔一笔查看账目；并且，一组账目的异常是相同的，用户可以一批一批定位分析异常原因，提高处理效率；同时，用户确定分析原因之后，不需要一笔一笔进行调账，修改计费模型参数即可，整个流程十分简单、快捷，提高用户的使用体验。

综上可知，本申请提供了一种对账方法，该方法可以从支付渠道系统获取多笔交易的交易数据，基于计费模型确定每笔交易的支付渠道成本的计费结果，然后从银行系统获取每笔交易的支付渠道成本的扣款结果，再将多笔交易的计费结果进行合并获得合并计费结果，将多笔交易的扣款结果进行合并获得合并扣款结果，确定合并计费结果和合并扣款结果之间的差值，在差值超过预警阈值的情况下，向管理用户发送预警信息以指示用户更新该计费模型，使得渠道成本对账时可以进行合并对账，不需要一笔一笔进行对账，提高对账效率，同时，管理用户可以根据预警信息更新计费模型即可，不需要再一笔一笔调整账目，提高对账效率，降低人力成本，提高用户的使用体验。

上文详细描述了本申请提供的对账系统以及对账方法，下面结合图8对本申请提供的计算设备进行解释说明。

图8是本申请提供的一种计算设备的结构示意图，该计算设备800可以是前述内容中的对账系统。进一步地，计算设备800包括处理器801、存储单元802、存储介质803和通信接口804，其中，处理器801、存储单元802、存储介质803和通信接口804通过总线805进行通信，也通过无线传输等其他手段实现通信。

处理器801由多个通用处理器构成，例如CPU。上述硬件芯片是专用集成电路(application-specific integrated circuit,ASIC)、编程逻辑器件(programmablelogic device,PLD)或其组合。上述PLD是复杂编程逻辑器件(complex programmablelogic device,CPLD)、现场编程逻辑门阵列(field-programmable gate array,FPGA)、通用阵列逻辑(generic array logic,GAL)、数据处理单元(data processing unit,DPU)、片上系统(system on chip,SoC)或其任意组合。处理器801执行各种类型的数字存储指令，例如存储在存储单元802中的软件或者固件程序，它能使计算设备800提供较宽的多种服务。

具体实现中，作为一种实施例，处理器801包括一个或多个CPU，例如图8中所示的CPU0和CPU1。

在具体实现中，作为一种实施例，计算设备800也包括多个处理器，例如图8中所示的处理器801和处理器806。这些处理器中的每一个可以是一个单核处理器(single-CPU)，也可以是一个多核处理器(multi-CPU)。这里的处理器指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。

存储单元802用于存储程序代码，并由处理器801来控制执行，以执行上述图1-图7任一实施例中对账系统的处理步骤。程序代码中包括一个或多个软件单元。上述一个或者多个软件单元是图1实施例中的单笔计费单元、第一合并单元、接收单元、第二合并单元、对账单元以及分析单元，其中，单笔计费单元，用于从支付渠道系统获取多笔交易的交易数据，基于计费模型确定每笔交易的支付渠道成本的计费结果，具体用于执行图2实施例中的S202A、S203及其可选步骤；第一合并单元，用于将多笔交易的计费结果进行合并获得合并计费结果，具体用于执行图2实施例中的S205及其可选步骤；接收单元，用于从银行系统获取每笔交易的支付渠道成本的扣款结果，具体用于执行图2实施例中的S204及其可选步骤；第二合并单元，用于将每个合并组中的多笔交易的扣款结果进行合并，获得每个合并组的扣款结果，进而获得多笔交易的合并计费结果，具体用于执行图2实施例中的S205及其可选步骤；对账单元，用于确定合并计费结果与合并扣款结果之间的差值，具体用于执行图2实施例中的S206及其可选步骤；分析单元，用于在差值超过预警阈值的情况下向用户发送预警信息，该预警信息用于指示用户更新计费模型，在差值不超过预警阈值的情况下对多笔交易进行渠道成本的核销操作，具体用于执行图2实施例中的S207～S209及其可选步骤。

存储单元802包括只读存储器和随机存取存储器，并向处理器801提供指令和数据。存储单元802还包括非易失性随机存取存储器。存储单元802是易失性存储器或非易失性存储器，或包括易失性和非易失性存储器两者。其中，非易失性存储器是只读存储器(read-only memory,ROM)、编程只读存储器(programmable ROM,PROM)、擦除编程只读存储器(erasable PROM,EPROM)、电擦除编程只读存储器(electrically EPROM,EEPROM)或闪存。易失性存储器是随机存取存储器(random access memory,RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM用，例如静态随机存取存储器(static RAM,SRAM)、动态随机存取存储器(dynamic random access memory,DRAM)、同步动态随机存取存储器(synchronous DRAM,SDRAM)、双倍数据速率同步动态随机存取存储器(doubledatadate SDRAM,DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM,ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM,SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。还是硬盘(hard disk)、U盘(universal serial bus，USB)、闪存(flash)、SD卡(secure digital memory Card,SD card)、记忆棒等等，硬盘是硬盘驱动器(hard disk drive,HDD)、固态硬盘(solid state disk,SSD)、机械硬盘(mechanicalhard disk,HDD)等，本申请不作具体限定。

存储介质803是存储数据的载体，比如硬盘(hard disk)、U盘(universal serialbus，USB)、闪存(flash)、SD卡(secure digital memory Card,SD card)、记忆棒等等，硬盘可以是硬盘驱动器(hard disk drive,HDD)、固态硬盘(solid state disk,SSD)、机械硬盘(mechanical hard disk,HDD)等，本申请不作具体限定。

通信接口804为有线接口(例如以太网接口)，为内部接口(例如高速串行计算机扩展总线(Peripheral Component Interconnect express,PCIe)总线接口)、有线接口(例如以太网接口)或无线接口(例如蜂窝网络接口或使用无线局域网接口)，用于与其他服务器或单元进行通信。

总线805是快捷外围部件互联标准(Peripheral Component InterconnectExpress，PCIe)总线，或扩展工业标准结构(extended industry standard architecture，EISA)总线、统一总线(unified bus，Ubus或UB)、计算机快速链接(compute express link，CXL)、缓存一致互联协议(cache coherent interconnect for accelerators，CCIX)等。总线805分为地址总线、数据总线、控制总线等。

总线805除包括数据总线之外，还包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图中将各种总线都标为总线805。

需要说明的，图8仅仅是本申请实施例的一种可能的实现方式，实际应用中，计算设备800还可以包括更多或更少的部件，这里不作限制。关于本申请实施例中未示出或未描述的内容，可参见前述图1-图7实施例中的相关阐述，这里不再赘述。

本申请实施例还提供了一种计算设备集群，该计算设备集群可以是前述内容中的对账系统，该计算设备集群包括至少一个计算设备800。计算设备集群中的一个或多个计算设备800中的存储单元802中可以存有相同或者不同的用于执行对账方法的指令。

本申请实施例还提供了一种包含指令的计算机程序产品。计算机程序产品可以是包含指令的，能够运行在计算设备上或被储存在任何可用介质中的软件或程序产品。当计算机程序产品在至少一个计算设备上运行时，使得至少一个计算设备执行对账方法。

本申请实施例还提供了一种计算机可读存储介质。计算机可读存储介质可以是计算设备能够存储的任何可用介质或者是包含一个或多个可用介质的数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，高密度数字视频光盘(digital video disc,DVD))、或者半导体介质(例如固态硬盘)等。该计算机可读存储介质包括指令，指令指示计算设备执行对账方法。

上述实施例，可以全部或部分地通过软件、硬件、固件或其他任意组合来实现。当使用软件实现时，上述实施例可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括多个计算机指令。在计算机上加载或执行计算机程序指令时，全部或部分地产生按照本发明实施例的流程或功能。计算机可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输。

以上，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修复或替换，这些修复或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (18)

1.一种对账方法，其特征在于，所述方法应用于对账系统，所述方法包括：

从支付渠道系统获取多笔交易的交易数据，基于计费模型确定每笔交易的支付渠道成本的计费结果，所述计费模型包括计费要素和对应的计费规则，所述计费要素用于确定交易数据进行渠道成本计费时使用的计费规则，所述计费要素和计费规则之间的对应关系是用户通过可视化界面配置的；

从银行系统获取每笔交易的支付渠道成本的扣款结果；

将所述多笔交易的计费结果进行合并获得合并计费结果，将所述多笔交易的扣款结果进行合并获得合并扣款结果；

确定所述合并计费结果和所述合并扣款结果之间的差值；

在所述差值超过预警阈值的情况下，向用户发送预警信息，所述预警信息用于指示所述用户更新所述计费模型。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述差值不超过所述预警阈值的情况下，对所述多笔交易进行渠道成本的核销操作。

3.根据权利要求1或2所述的方法，其特征在于，所述获取多笔交易的交易数据，基于计费模型确定每笔交易的支付渠道成本的计费结果包括：

获取多笔交易的交易数据，确定每笔交易的多个交易属性，所述交易属性用于描述所述交易数据；

根据每笔交易的多个交易属性，生成交易属性表，所述交易属性表包括多个字段，每个字段代表一个交易属性，所述交易属性表中的每一行数据对应拥有多个相同交易属性的一批交易数据；

根据交易属性确定每一批交易数据对应的计费模型；

根据每一批交易数据对应的计费模型，确定每一批交易数据中每笔交易数据对应的渠道成本的计费结果。

4.根据权利要求1至3任一权利要求所述的方法，其特征在于，所述对账系统包括多个计费位图，其中，一个计费结果对应一个计费位图，所述计费位图包括多个比特位，每个比特位对应一个计费属性，每个比特位的值用于指示对应的计费结果中是否存在对应的计费属性，所述计费属性用于描述所述计费结果。

5.根据权利要求4所述的方法，其特征在于，所述将所述多笔交易的计费结果进行合并获得合并计费结果包括：

获取一个或者多个合并计费属性，基于所述一个或者多个合并计费属性和所述多个计费位图，将所述多笔交易分为多个合并组，其中，一个合并组中多笔交易包括相同的合并计费属性；

将每个合并组中的多笔交易的计费结果进行合并，获得每个合并组的计费结果；

根据所述每个合并组的计费结果，获得所述多笔交易的合并计费结果。

6.根据权利要求5所述的方法，其特征在于，所述基于所述一个或者多个合并计费属性和所述多个计费位图，将所述多笔交易分为多个合并组包括：

根据所述一个或者多个合并计费属性，确定一个或者多个掩码；

将所述一个或者多个掩码应用于所述多个计费位图，获得包含所述一个或者多个合并计费属性的多个合并组。

7.根据权利要求5或6所述的方法，其特征在于，所述将每个合并组中的多笔交易的计费结果进行合并，获得每个合并组的合并结果包括：

将每个合并组中的多笔交易的多个单笔计费结果发送给不同的实例进行处理，获得每个实例完成的合并结果，其中，所述实例包括物理机、虚拟机或容器，所述每个合并组中的交易笔数根据每个实例的处理能力确定。

8.根据权利要求5至7任一权利要求所述的方法，其特征在于，所述将所述多笔交易的扣款结果进行合并获得合并扣款结果包括：

将每个合并组中的多笔交易的扣款结果进行合并，获得每个合并组的扣款结果；

根据所述每个合并组的扣款结果，获得所述多笔交易的合并计费结果；

所述确定所述合并计费结果和所述合并扣款结果之间的差值包括：

确定每个合并组的扣款结果与计费结果之间的差值。

9.一种对账系统，其特征在于，所述系统包括：

单笔计费单元，用于从支付渠道系统获取多笔交易的交易数据，基于计费模型确定每笔交易的支付渠道成本的计费结果，所述计费模型包括计费要素和对应的计费规则，所述计费要素用于确定交易数据进行渠道成本计费时使用的计费规则，所述计费要素和计费规则之间的对应关系是用户通过可视化界面配置的；

接收单元，用于从银行系统获取每笔交易的支付渠道成本的扣款结果；

第一合并单元，用于将所述多笔交易的计费结果进行合并获得合并计费结果，第二合并单元，用于将所述多笔交易的扣款结果进行合并获得合并扣款结果；

对账单元，用于确定所述合并计费结果和所述合并扣款结果之间的差值；

分析单元，用于在所述差值超过预警阈值的情况下，向用户发送预警信息，所述预警信息用于指示所述用户更新所述计费模型。

10.根据权利要求9所述的系统，其特征在于，所述分析单元，用于在所述差值不超过所述预警阈值的情况下，对所述多笔交易进行渠道成本的核销操作。

11.根据权利要求9或10所述的系统，其特征在于，

所述单笔计费单元，用于获取多笔交易的交易数据，确定每笔交易的多个交易属性，所述交易属性用于描述所述交易数据；

所述单笔计费单元，用于根据每笔交易的多个交易属性，生成交易属性表，所述交易属性表包括多个字段，每个字段代表一个交易属性，所述交易属性表中的每一行数据对应拥有多个相同交易属性的一批交易数据；

所述单笔计费单元，用于根据交易属性确定每一批交易数据对应的计费模型；

所述单笔计费单元，用于根据每一批交易数据对应的计费模型，确定每一批交易数据中每笔交易数据对应的渠道成本的计费结果。

12.根据权利要求9至11任一权利要求所述的系统，其特征在于，所述对账系统包括多个计费位图，其中，一个计费结果对应一个计费位图，所述计费位图包括多个比特位，每个比特位对应一个计费属性，每个比特位的值用于指示对应的计费结果中是否存在对应的计费属性，所述计费属性用于描述所述计费结果。

13.根据权利要求12所述的系统，其特征在于，

所述第一合并单元，用于获取一个或者多个合并计费属性，基于所述一个或者多个合并计费属性和所述多个计费位图，将所述多笔交易分为多个合并组，其中，一个合并组中多笔交易包括相同的合并计费属性；

所述第一合并单元，用于将每个合并组中的多笔交易的计费结果进行合并，获得每个合并组的计费结果；

所述第一合并单元，用于根据所述每个合并组的计费结果，获得所述多笔交易的合并计费结果。

14.根据权利要求13所述的系统，其特征在于，

所述第一合并单元，用于根据所述一个或者多个合并计费属性，确定一个或者多个掩码；

所述第一合并单元，用于将所述一个或者多个掩码应用于所述多个计费位图，获得包含所述一个或者多个合并计费属性的多个合并组。

15.根据权利要求13或14所述的系统，其特征在于，

所述第一合并单元，用于将每个合并组中的多笔交易的多个单笔计费结果发送给不同的实例进行处理，获得每个实例完成的合并结果，其中，所述实例包括物理机、虚拟机或容器，所述每个合并组中的交易笔数根据每个实例的处理能力确定。

16.根据权利要求13至15任一权利要求所述的系统，其特征在于，

所述第二合并单元，用于将每个合并组中的多笔交易的扣款结果进行合并，获得每个合并组的扣款结果；

所述第二合并单元，用于根据所述每个合并组的扣款结果，获得所述多笔交易的合并计费结果；

所述对账单元，用于确定每个合并组的扣款结果与计费结果之间的差值。

17.一种计算设备，其特征在于，所述计算设备包括处理器和存储器，所述存储器用于存储指令，所述处理器用于执行所述指令，以使得所述计算设备实现如权利要求1至8任一权利要求所述的方法。

18.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，所述指令被计算设备或者计算设备集群运行时实现如权利要求1至8任一权利要求所述的方法。