账户系统接口设计（账户体系设计）

本篇文章给大家谈谈账户系统接口设计，以及账户体系设计对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享账户系统接口设计的知识，其中也会对账户体系设计进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、如何设计支持使用第三方帐号登陆的帐户系统的数据库表
• 2、三层架构用户服务系统的设计与实现
• 3、业务系统与财务系统的接口是怎么接的，有几种方法
• 4、基本账户的基本架构
• 5、简述互金帐户设计
• 6、电商平台支付结算系统设计 - 产品向

如何设计支持使用第三方帐号登陆的帐户系统的数据库表

实现用户认证授权系统账户系统接口设计的方法如下账户系统接口设计：

首先账户系统接口设计，统一用户管理系统在设计时就要能建立一个能适应各种系统权限管理要求的权限模型。

对于己建立的老系统账户系统接口设计，各系统将自己的用户角色管理账户系统接口设计，角色一权限管理等部分抽离出来，统一放在统一用户管理系统中。

而对于新建立的系统，各系统在建设的初期就要把自己权限设计的要求提交给统一用户管理系统，按照其需求在本身统一用户管理系统的权限模型上去构建出该系统的实例。

那么管理员就可以通过统一授权系统为各用户在不同系统的权限进行配置。

在登陆时各系统就调用相关的统一认证和授权接口，获取用户相关的权限信息，进到各系统后再创建用户，将相关的权限信息赋予给用户类。

然后就可以在应用系统中进行权限验证。

   这是一个终极目标的做法，这个方法是将所有系统的权限控制部分都建在统一用户管理系统中。这种方式既能对用户进行统一的授权和认证，也能展现各用户的统一权限视图。

三层架构用户服务系统的设计与实现

三层架构用户服务系统的设计与实现

基于三层架构的用户服务系统的设计实现了用户的集中管理和授权，为不同信息平台提供了验证授权及信息管理的接口，进一步理顺了组织机构的层层关系，方便用户使用。具体如何实现的呢，一起来看看下面的文章!

1、三层体系架构简介

随着信息技术的不断发展，三层架构(C/S或B/S)现已经成为主流技术。三层结构模式是目前流行的协同开发模型，这种模式将应用开发中的部件划分为三层：表示层、业务逻辑层、数据访问层。它的优点是联机的用户数比较多，每次交易的时间都比较短，伸缩性和容错性强。同时支持客户端应用程序的开发和分布，能通过客户端计算机与应用程序逻辑分开。三层模式都在其安全环境中进行。软件的开发工作和维护工作可相对独立进行。

2、用户服务系统的架构

用户服务系统的设计思想是建立一个相对独立于各个应用系统，能够统一管理用户帐户信息和组织机构，方便用户使用和管理的接口系统，解决原有信息系统中，不同应用平台中同一用户有多个的用户账户的问题。

本系统定位针对于各级部门，面向各级部门所有人员，提供统一、完善的、易用的用户认证和组织机构管理平台，对用户的身份认证和组织机构进行统一管理和维护。

2.1 需求分析

2.1.1 统一认证的需求分析

统一认证的前提是不同应用系统平台所有用户信息的数据都存储在数据库中。应用ASP.NET技术将统一认证封闭为WEB服务，方便不同应用系统的调用，达到统一认证、管理、授权的目的。因此要求该部分功能支持单点登录，即所有应用系统在用户登录时能统一用户名和口令。同时能够设置用户权限，避免对原有应用平台进行规模较大的修改。由于用户服务系统要和其他应用系统集成才能为其提供服务，不同的应用系统可能会使用不同的数据库，或运行在不同的操作系统平台上，因此，要求具备良好的平台兼容性，屏蔽差异。在安全性方面，要杜绝漏洞和各种隐患，使信息的传递在安全保障范围内。

2.2.2 组织结构管理的需求分析

组织结构管理系统的体系模块划分需求如下：

(1)组织机构及机构间关系的建立、修改、删除等;如创建一个用户，将用户分配到某个部门、将用户赋予某个角色等。(2)组织机构(集)的检索：如获取某部门的所有用户、得到某用户的部门列表、获取某部门的.上级部门等。(3)各类机构提供方便获取关联对象的属性。如dept.Users可获取该部门的直属用户、org.Depts可获取该单位的直属部门。(4)机构(集)的排序功能。组织机构服务提供接口方法用以对各类实体排定次序。如部门在单位内的排序、用户在部门内的排序等。

2.2 功能设计

用户服务系统由两部分组成：统一认证和组织结构管理。

统一认证：负责提供用户身份认证服务。主要包括用户注册、帐号关联和用户认证。用户注册是指用户在统一身份认证服务中注册帐号，包括新用户注册和用户修改注册信息两部分。组织结构管理：管理信息平台所有用户的信息，为管理员提供操作界面管理用户、账号、角色、单位、部门等信息。主要由3部分组成：(1)数据库:用户信息与用户账号信息分开处理，分别在数据库的不同表中，这样操作对系统扩充性更为有利。(2)管理模块:主要包括组织结构及单位管理、部门管理、用户管理、账号管理、角色管理等。(3)管理端:为管理操作提供可视化管理界面。

3、系统关键技术的实现

3.1 用户密码进行MD5加密

MD5是一种单向加密的加密算法，经常用于系统用户登录认证方面。本系统中，新用户注册帐号时，若将密码直接保存到数据库中，万一信息遭遇泄露，不能保证数据的安全。因此，在密码数据存储时，对其进行MD5加密操作后再保存，这样，即使密码信息暴露，也不会泄露真正的含义。用户登录时，也将用户的密码数据进行加密后再和数据库中数据进行比较，即可达到验证身份目的。

.NET中System.Security.Cryptography命名空间包含的MD5CryptoServiceProvider类，提供专门用于MD5单向数据加密的方法。使用时只需在程序中实例化MD5CryptoServiceProvider类，调用MD5加密解密函数，并以明文作为参数就可以实现加密功能。具体语法如下：

System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile(txtPwd.Text.Trim()，”MD5”).ToString();

3.2 Remoting远程调用

在系统开发的后期，为了达到跨平台、跨地域的目的，我们采用了Remoting技术来实现。.NET Remoting就是传统DCOM的替代，主要实现进程间的通信，以一种对象通过应用程序域与另一对象进行交互为框架，实现协同工作。这也正是我们使用Remoting的原因。

;

业务系统与财务系统的接口是怎么接的，有几种方法

ERP账户系统接口设计的业务、财务数据一体化设计思路一、引言ERP(Enterprise Resource Planning账户系统接口设计，企业资源计划)是提高企业管理效率的重要手段，既是软件系统的应用，更代表账户系统接口设计了一种全新的管理理念，它以供应链为核心，基于流程的管理思想，与传统的基于职能岗位的管理思想完全不同，流程的规范化是企业成功实施ERP的必备条件，企业进行BPR业务流程重组以后才能实施ERP，产生预期的效益。对于生产制造企业而言，涉及生产、经营、管理的各个环节。企业实施ERP时，需要将财务数据与业务数据有效集成，业务信息输入系统后能够实时、准确生成财务信息，实现物流与资金流的统一。如果不能对企业业务流程重组或优化处理，流程达不到规范化要求，ERP的先进理念就得不到充分展现，就无法发挥其应有的效率，而只是软件系统的简单应用。因此，根据业务流程对会计流程重组或优化设计是ERP实施过程中必不可少的重要环节。研究企业运作过程的核心环节即供应链环节中物资和信息的流动过程，以及ERP系统实现业务信息与财务信息自动转化的方法。在此基础上设计出ERP环境下会计业务流程优化的策略是本文将要解决的问题。ERP环境下会计业务流程优化技术的设计ERP系统由若干模块组成，其处理过程与物流同步进行，企业生产的各个环节均伴随着物资流和信息流，在物资流动时，各种单据同步输入ERP系统并传递至财务子系统，自动产生查询、管理决策所需的数据。ERP中的财务子系统负责会计信息的集成化管理，即通过数据模型和共享数据库的建立，使用统一的数据管理和通用数据接口实现数据的集成、管理与控制。会计信息的处理模式由传统的“原始凭证一记账凭证一账簿一会计报表”转化为“原始凭证一数据库一账簿报表”的内部管理模式。会计业务流程的优化技术主要有自动凭证触发技术、会计业务多样化信息处理技术、引擎技术和联机事务处理技术。1、自动凭证触发技术 自动凭证触发的设计思想是账户系统接口设计：经济业务发生时，部门信息处理人员将单据信息输入数据库，数据库中变动的业务信息传递至ERP的财务子系统，即自动触发凭证模板，根据业务与账户之间的关系形成会计数据，再将业务单据的摘要、账户、日期、金额等数据填入凭证相应栏目。系统将自动产生会计凭证，并以凭证形式显示或打印。从原始凭证（单据信息）录入业务子系统开始到记账凭证的形成，再到账簿的产生，其本质都是通过指定条件从数据库中调出记录和字段内容，自动触发形成，在这一过程中，凭证及其账户系统接口设计他数据的源头都是业务单据，由于数据源头的唯一性，保证了数据的准确性与一致性。2、会计业务多样化信息处理技术财务数据库所存贮的数据流不仅隐含改变企业资产、负债、所有者权益的财务会计事项的数据，而且还包含管理人员所需的企业战略决策、计划、控制和业绩评价方面的作业细节数据，呈现多样化。信息使用者可根据决策需求，选择各种会计处理方法对其再加工处理，生成所需的决策视图。通过引入事件驱动规则构成会计凭证生成方法，形成会计业务多样化(diversification)处理过程。将规则划分为事件、条件和过程3个部分，当事件发生时，从多种可能条件中选择一个条件，执行相应的过程，而这个动作可能就是一个套用凭证模板，产生一张机制凭证。3、引擎技术引擎(Engineer)是一个连接数据库和应用系统的程序段，用来采集、处理、输出会计相关信息，是基于数据库语言来设定整个应用系统运作模块的参数，可以重置数据库结构，还能够主动引导设计过程。引擎与使用者问处于一个互动性的关系，具有很高的自主性，会保护系统免于不当设计的损害。通过引擎能够建立各环节数据的自动传递，实现各子系统的联动和同步处理。4联机事务处理技术事务(transaction)是指作为单个逻辑工作单元执行的一系列操作。是确保“同时成功则成功，任何一步失败则全部失败”的一种机制。一个事务往往包括3种动作：开始事务、提交事务和撤销。从开始事务到提交事务过程中所发生的一切数据库修改全部成功才能提交到数据库保存，只要有一个动作失败，必须恢复修改前的状态。在ERP中，通过联机事务处理系统(On-Line Transaction Processing，OLTP)实现，例如在银行存款时，先锁定账号，到存款过程结束才释放账号，保证账号与金额的一致性。二、ERP环境下会计业务流程的优化设计ERP是在MRP(制造资源计划)的基础上发展起来的，对于制造企业而言，核心是供应链，包括3个环节：企业的采购环节、生产制造环节、销售环节。1、供应链会计业务流程的优化目标企业从原材料和零部件采购、运输、加工制造、分销直至最终送到顾客手中的过程被看成是一个环环相扣的链条，称为供应链(Supply Chain)。我们不是孤立地看待链上的各个企业，而是把从供应商、制造商到销售商、用户的整个供应链看成一个有机整体。供应链流程主要由物流、信息流及资金流3部分构成。在ERP环境下。信息流是核心，物流是保障，而资金流则是实现的手段。三者之间的有效互动构成了一个完整的同步处理模型。传统供应链管理存在的缺陷包括：基础管理薄弱、流程与制度不规范；业务处理效率低、部门职责不清晰；财务业务脱节，经营分析滞后，库存量大，信息传递速度不准时．处理需求单一。而在ERP环境下，企业可以及时掌握企业生产、库存情况。快速响应客户需求，有效管理控制销售价格，管理订单、发货、出库、开票全过程，配合采购、销售、生产等业务控制物料收发，随时掌握库存，做到账实相符，防止呆滞料和库存积压，减低库存成本。为企业决策提供数据支持。供应链会计业务流程的优化目标是：规范流程，去除人为因素，确保基础数据完善无误；减少库存量．通过JIT(敏捷制造)，努力实现零库存；系统内信息准确输送。及时反馈共享，与财务系统协同工作，自动完成供需协调，实现供应链的无缝连接。2、供应链会计处理流程的优化设计供应链会计业务流程优化设计的基本思路是：将供应链业务流程与会计处理流程融合，以业务流程为导向，利用自动凭证触发技术、业务多样化技术、引擎技术和联机事务处理技术，实现财务、业务信息协同处理，实时生成。数据信息实现数据的一方录入，多方使用，实现数据共享。其集成实现过程主要有3步：基础资料录入设计。主要完成对供应商信息、部门信息、职员信息、物料信息、计量单位信息、会计科目信息、物料供货信息等基础资料的录入，基础资料的准确与否，直接关系到会计信息的质量，所以必须录入准确、完整的基础资料数据。 系统参数设计。这是优化设计的关键一步，ERP系统既要保证通用性，也要满足用户的特殊需要．通过设置多种事务处理方法，用户要根据企业实际情况认真确定参数，实现由通用软件到个性化定制的转化。如暂估业务处理方式的选择、预警数目的设置、多级审核的设置等。当然，这些参数设计的难易、优劣完全依赖于ERP系统本身所提供的系统参数，不同的ERP系统其参数的设计原理及操作的易用性是有很大区别的。 凭证模板设计。即设置事务处理对应的会计科目(包括总账科目和明细账科目)及会计科目上的借贷关系。生成凭证是业务系统与财务系统的接口，系统通过实时生成凭证，实现财务与业务数据的集成，而要实现实时、自动生成凭证，凭证模板的设置是关键。当经济业务发生时，通过凭证触发机制自动选择相应凭证模板，自动生成凭证。供应链的凭证模板主要有采购入库凭证模板、销售出库凭证模板、采购费用发票凭证模板、付款凭证模板、收款凭证模型、转账凭证模型等。通过执行以上3个步骤，基本能够实现与供应链业务有关的采购、生产、仓管、销售、财务等各部门的集成。 ERP系统之所以能够实现财务与业务数据的集成，引擎机制起着非常重要的作用。它实时检测数据库中的数据变化情况，一旦金额字段发生改变。则自动触发相应代码，自动处理记账、过账业务．并为报表系统提供相关的报表数据，结果存人数据库或者以表单方式显示，同时通过其智能分析程序处理分析，向相应的管理会计报表系统提供数据支持，生成决策所需的各种报表、报告等信息。三、供应链会计业务流程优化过程的实现网络及数据库技术的发展，为供应链信息的集成提供了技术上的支持，为实现ERP先进的管理目标提供了可能，供应链业务流程优化的基本思想是将企业业务处理和会计信息处理流程融合为一体，融合财务会计和管理会计职能，从全局的角度构建整体化的供应链流程体系。下面以采购环节为例进行具体描述，其他业务与此方法相同。企业的采购环节包括获取原材料并支付现金或银行存款，通常包括下单、稽催、入库、退货、对账和付款等基本环节。按照业务流程重组的思想，企业要以企业目标为导向调整业务流程和组织结构，打破传统职能部门的界限。由一个人或一个工作团队来完成某一业务的所有步骤，让决策产生在信息生成的地方。 在ERP系统中记账工作也已经变得非常简单，只需要工作人员按一下按钮发出指令，就可以由系统自动完成整个记账过程。在ERP环境下，甚至可以设置凭证审核以后由系统自动记账．其实记账操作只是指挥计算机在相应数据库中的记录上做个标志。随着ERP系统的完善，针对各种可能出现的业务情形，设置了相应的会计凭证模板与之对应，企业经济业务发生时，能由系统自动生成准确无误的会计凭证。或者根据单据直接登记账簿。对于采购环节应付账款的处理，遵循决策产生在信息生成的地方这一原则，在输入发票的同时系统能够自动检查有关的采购单和收货单，进行三方匹配，匹配成功即可以执行付款，而不必再等到财务部发出付款指令。即在处理业务单据的同时处理相关会计业务信息，当流程走完，则整个采购过程结束。四、结束语在传统岗位分工的情况下，作业流程被分割成各种简单的任务，经理们将精力集中在个别任务效率的提高上，而忽略了最终目标，即满足顾客的需求。通过优化设计，形成全局思想，从整体上确认企业的作业流程，追求全局最优，而非个别最优。通过业务信息处理流程与会计信息处理流程的整合，运用集成思想，集成业务处理与会计信息处理。使会计业务和其他业务协同实现整个采购流程的最优化，加速企业整体效益的提升。但要完成企业的整体目标，仅有优秀的ERP系统还远远不够，现代管理理念更加重要。

基本账户的基本架构

指导思想和基本原则
建立个人基本帐户，首先必须树立以客户为中心，以市场为导向，整体联动，分户核算，集约经营，保证安全的指导思想。同时，应坚持以下四个主要原则：一是先进性。要发挥新技术的优势，利用计算机和网络通讯等现代化手段，不仅快速、准确地处理现有业务交易和信息服务的所有内容，而且要扩大电话银行、ATM、自助银行、网上银行等新工具的转帐和查询业务。二是便利性。一方面，要与现有业务体系并轨运行，处理好与现有业务的关系，为银行零售业务的整体发展提供支持和促进，以适应不同客户群体的多样化需求；另一方面，利用电子技术，简化业务流程，方便客户操作，减少柜台人员的操作环节，提高工作效率。三是可扩充性。设计个人基本帐户，一定要具备良好的扩充能力，要能为未来的发展留有足够的空间和接口。四是安全性。设计个人基本帐户，要贯彻强化基础管理，严格业务操作，规范流程和控制，切实防范风险方针，确保帐户系统的稳定运行和业务的顺利推展。
系统结构及目标
开发个人基本帐户，必须充分利用现有的城市综合网络系统。通过城市综合网络系统，建立以客户为中心的业务交易、客户服务和信息管理三个互为关联的系统。
从业务交易系统看，它应是个人基本帐户的主体功能系统，要实现对客户的综合性金融服务，同时为客户服务系统和信息管理系统提供基础信息。
从客户服务系统看，它是以业务交易系统为基础的后台服务管理系统，对系统内的有关信息加工分析，评定客户服务等级，确定客户信用状况，为客户提供差别化服务，并为前台交易提供服务与支持。
从信息管理系统看，它是以业务交易系统、客户服务系统为基础，为银行提供客户信息管理、资金管理、零售业务效益管理服务，同时为银行的资金、成本、效益管理提供基础数据的系统。
上述三个系统一方面满足客户的账户管理，一方面满足银行的帐务管理，从而实现对个人基本帐户业务信息的最大利用，将客户和银行的资产、负债、权益、成本和损益增减变化的情况和结果都反映出来。
账务核算体系
个人基本账户系统，应按客户设置户头，以个人基本账户为核算基点，分类连续记录个人客户的金融业务活动。从账户组织体系看，一方面，银行应按照客户的要求，将其资产、负债业务归集在个人基本账户下统一管理。客户凭个人基本账户和款项代码，即可处理各类个人存取款业务、个人贷款业务、个人投资理财业务等。同时，银行也要根据客户需要，为其提供信息加、统计报表和特惠服务。另一方面，银行要按照现行会计核算的要求，对个人基本帐户发生的业务进行帐务管理。在此基础上采集、加工、维护相关信息，建立信息资料库，形成银行和客户的有关会计报表。然后分析客户信息，评定为客户服务的等级，根据客户对银行贡献大小提供差别化服务。不仅如此，要按安全性、流动性和效益性原则，管理好银行自身的资产、负债和所有者权益，实现商业化管理。
系统的功能定位
通过建立个人基本账户系统，最终应实现为客户服务的多项功能。当前至少要有三大功能：一是业务交易系统功能。包括在网点柜台实现存、贷、汇、结、理等服务，在ATM、商户POS、电话银行、网上银行实现存、取、查、转等一般性业务和特殊业务。二是客户服务系统功能。包括客户信息管理，评定客户服务等级，确定客户信用额度，授权授信管理等。三是信息管理系统功能。包括客户的资产负债和贡献评价，业务成本效益分析，信息维护等。以满足客户对自身资产的管理及投资理财业务需求，同时满足银行培植优秀客户群体、提高经营效益的要求。

简述互金帐户设计

这篇本来没有计划写的，但，由于某友的要求且考虑其正在从事这块业务，所以，奋笔疾书，写上一发。
声明: 本人虽然是在支付领域挥洒热(ban)血(zhuan)，但是，互金并不是主业，且不同受众群提供的产品和服务还是有很大差别的，所以，只能从较为宏观的层面谈谈互金账户设计的事儿。

互金行业涉及的行业有6个大方向：三方支付、P2P、大数据金融(类似花呗，白条等，众筹等)，信息化金融机构，和互联网金融门户。但是，从账户角度来说，个人觉得大同小异，所以，本文拿大家最为熟悉的p2p作为案例。

1. 纯线上，线上理财，线上借款；
2. o2o：理财端线上，资产端线下，线下主要负责风控、催款等；
3. 债权转让模式：p2p流行的定期模式
p2p是互金的一个分支，而贷款对于大家来说是比较了解的，有支付、p2p、花呗、微粒贷、京东白条做的信用贷的产品，还有其他一些东西等等形成的在互金行业的一些特色；

纯线上的模式来说，企业通用做法是：

线上获取贷款，线上理财操作 ；

对于线上线下结合的方式，从国家对金融监管来说，理财端只能从线上发展；对于资产端，可以从线下进行风控和审批、或者催收；从优质资产考虑和统计数据表明，线上线下结合的模式比纯线上模式坏账率要低很多(我X贷网的朋友分享而知)；

下面是债券转让模式。这个本人其实不是非常的懂。了解到的是，这一块主要在理财端，以定期和活期为主。最早买p2p以散标的模式，现在已经很少了。目前主要是债权转让的模式做定期和活期，而且以定期为主，活期因为监管被下架。

从p2p的整个业务链条看，两部分： 资金端、资产端。

资金端 。这方面主要是理财为主，以线上为主要方式，合规。资金端主要是理财人以散标、活期、定期等几种方式进行投资。理财人登录p2p平台，选择理财产品，有散标、活期、定期，目标基本以定期为主，散标目前比较少，原因是散标在点对点情况下，借款人的时间太长导致回访过高 。活期，比如各种宝，由于不合规，各平台正在换其他方式。

定期 。按照1，3，6，12个月这种模式比较流行，大家在在各大平台都有接触； 根据你选择的产品进行投标，以合适的身份进行匹配后，在满标后进行放款。

资产端 。本人个人的理解是，这一块比较复杂。
p2p平台通过门店、电销、线上推广、资产购买等模式发展，经过相应的进件，审批，合格后进行签约，线上的话流程比较简单，线下就比较复杂，主要是按照贷款产品的额度进行区分。资产签约后，需要上标与理财人进行匹配，然后才能放款，后期按还款计划进行还款。
据本人不完全观察，业务流分为：充值，投资，红包，赎回，放款，提现，还款，代充值，代偿，代扣（还有其他的欢迎补充）

充值 。分为理财充值和借款人充值。对于理财充值，后期购买哪些产品即可理解为是投资了。购买类型是定期、活期还是散标；对于借款人充值，则目的是为了进行还款。

红包 。p2p平台竞争已经是非常激烈了，所以很多平台会做活动；如注册之后就送优惠券、体验金和代金劵等一些营销活动方面的推广， 对于业务活动都会有资金投入的，涉及到后期的业务处理；

赎回 。投资赎回，涉及本金和利息；
放款 。标的满标之后才能向债权人进行放款；对于提现可能会有余额的提现，剩余多少提现金额；

还款 。对于借款人来说，有还款方式和还款业务不同。怎么理解？比如，蚂蚁借呗，是线上还款方式；而有些传统业务比较多的p2p公司，可能会有门店还款、代扣(代收)或者对公的还款方式；

代垫 。这块解释了为什么p2p要接支付公司通道的原因。因为p2p有支付牌照的很少，基本上需要通过支付平台或者银行来走；早期，支付平台一般选择T+1结算，而部分是T＋0，因为费率比较高，原因是，T＋0提现是支付公司代垫，然后在T＋1支付公司自行和银行结算；

代扣 。对借款人银行卡进行定时扣款，比如买房公积金贷款。另外，公积金还款也是以代扣模式进行；
凯撒这里再强调一次，为什么要说这么多业务的事情，因为搞清楚了这些，我们聊账户才比较顺当。

是的，聊这一块，起点必然是资金流。资金流涉及的账户如下
我们从一个正常的投资放款流程来看，张三（投资人）向结算户充值、然后进行投资，资金进入债权户（如果，投资失败，返回至投资人结算户）；接下来，平台通过撮合满标后放款到借款人债务户，在债务户进行各种费用的收取后放款到借款人结算户或者银行卡。反之亦然。
对账务来说，需要关心的只是各个账户对象，资金在各个账户流入流出，即资金转移的过程；至于资金从哪里来的，资金应该属于谁，这些不在账务处理范围内；对于借款人来说，一个还款的过程是：

1. 借款人通过充值或者代扣的方式进行还款到结算户，

2. 结算户根据账单把还款金额冻结到债务户，通过债务户还款到债权人（张三）的债权户。

假如有复投，债权人（张三）进行复投到其他标的；假如没有复投，就赎回到结算户，债权人（张三）可以选择自己提现或者进行其他标的的投资。

聊到这里，引出了一个问题，那就是—财务处理和会计处理的差别

对于账务处理来说，是根据账户的设置进行流水的处理，以收付实现制为基础。很难理解？想想支付宝的账单，是不是清楚很多？然后，根据流入流出的方式更新余额。

对于会计处理来说，是以科目为主，以权责发生制为基础，资产、负债、所有者权、损益、成本、共同类进行复式记账。

咱们拿 充值 为例，这样比较好理解。

从 账户 的角度，是以收付实现制为基础的；对于会计处理来说，是以科目为主，以权责发生制为基础；收付实现制法则设定相应的目标账户以资金的流入、流出和余额为标准的，只是解决流入和流出；对于 会计科目 来说，解决的是为流入这笔钱来自哪里，流出这笔钱要去哪里，要有一个权责确认的过程；

所以，针对用户充值这个场景，对于账户来说，只是一条资金流入，多少钱、余额多少；对于会计科目来说需要分全面考虑：

1. 对账前，跟支付机构（或银行）进行确认，有一个待清算款；

2. 在 T+1，对帐流水出来后，需要进行对账；（支付公司但凡有提供t+0，对账的事情支付公司T+1找银行清算了）

3.对账完成后，相当于把待清算转成应收账款；然后，这个充值场景的一笔充值记录在后台对应多笔会计分录 ；
这地方要理解一个概念，那就是，从账务处理来讲虚拟户是解决资金归属问题，而不关心资金的存放问题。这里涉及到的有两个账户： 实体账户和虚拟账户

实体账户 ，即资金存放的账户，在银行，有如下三类：银行存管专户；银行自由资金专户；银行垫资账专户

虚拟账户 ，即资金归属；两种：用户虚拟存管账户（投资人账户，借款人账户，合作机构账户，担保机构账户）；平台虚拟存管账户（收入账户，分润账户，代偿账户，代充值账户；派息账户）

是解决资金存放问题的，与虚拟户成对应关系。从 会计处理 讲，实体户属于资产，虚拟户属于负债及其他。而实体账户和虚拟户组成，的角度来说，需要跟银行有一个开户的过程，用来解决资金存放的问题（是存放在银行存管户、银行自由资金户还是银行垫资专户，这个要看具体情况而定）；对于 虚拟户 来说，钱是从投资人、借款人或者居间人一方来的，是属于收入的还是营销的，这个也是要具体情况而定。

小结一下，对于 实体户 ，只关心资金存放；对于 虚拟户 （比如说投资户、借款户还有收入户），关心资金归属。举例：在平台银行账户存入一笔钱，是属于投资人还是借款人；从实体户的角度来说是资产，从虚拟户的角度来说是负债（属于平台欠投资人／借款人的钱，对于平台来说是负债）。

鉴于p2p的特殊性，不止有收入的问题，还会有营销款支出、代偿、代垫、分润等有相关业务，对于没有按时还款进行代偿代垫等这些内容要说估计篇幅太长了，和这个账户设计没有太大关系。

从四个方面（交易，账务，会计，对账）同一笔交易所涉及到的账务处理、会计处理、对账等事宜。从交易处理、账务处理、会计处理和对账处理，形成一个完整的企业数据流；
我们拿 放款 为例：

交易处理 ：放款就是一笔支付；

账务处理 ：从债权户到债务户，从债务户到结算户然后到结算户的银行卡，同时还涉及到收益户的处理；

那么，为什么有这么多处理步骤? 我们不妨站在平台角度：

1. 需要在放款的时候才确认从债权到债务的处理；

2.在债务处理的时候，需要把钱放在借款人债务户，并相应把钱划到结算户和收益户（会收取一定的费用）；

3. 针对部分客户有需求是打款到银行卡，所以平台需要记录从债权户到债务户、债务户到结算户、结算户到银行卡的这条流水处理过程，以保证账务流水处理的一致性；

会计处理 ：比如贷款，债权户到债务户的确定，会记待发放款项；待发放款项放款，放款金额和合同金额会有差距，所以，放款金额会单独形成待清算目录，假如T+1账单来了，形成清算，对于收益户来说计入收益；

对账处理 ：支付流水和确认银行流水对账以后，形成应收账款；然后对于结算来说，形成相应的银行余额进行结算，并形成结算的单据凭证；
下面我们从财务处理角度去看这个问题：

从业务架构上，业务端统一对接支付平台进行现金的收支转等。支付平台在完成支付过程中，同步数据到账务管理和清结算平台。账务管理和清结算在数据处理后，传递到会计处理。这一个过程说起来挺简单的，但是实际由于公司自身发展不均衡，很多公司业务平台先于支付平台建立，这样的话就需要对各条业务线进行梳理，进行标准化设计，对业务系统查缺补漏，统一业务流程和接口方式。

从结构设计上，支付负责进行现金账务管理负责资金的变动，清结算负责对账，进行账实核对，会计处理负责复式记账(啥是复式记账，自行百度吧)，试算平衡及日切等等。

总体流程是：支付订单向账务管理写入账务的流水数据，向清结算写入清洁算的流水数据，并在清结算的过程中进行对账处理，这样从系统设计上来说两边互不干涉。会计处理分别获取账务管理的数据和清洁算的数据，这样分别获得交易的确认和账务的确认，在会计处理这块儿相当于两个合一。

另外，业务的发展速度会快于系统的整体规划速度，这样会导致同样的功能点，同样的业务处理，在不同的系统处理方式不一致。没有形成一个的统一系统的处理。然后从设计的角度上，不仅要考虑系统架构的适用性方面，而且要考虑公司逐步实现的步骤。

这里多说一句还款的事儿，因为上图画得比较差
还款涉及到的资金项目有本金、XX费、利息；这些类型还到借款人账户上，这些钱会有几个步骤：从本金还到投资人债权户上，xx费放在收入账户和分润账户，利息放在派息账户；相当于还款部分，异地还款在债务户里面的资金处理是不一样的，流向自然也就不一样了，那么，相应的后台会计处理也就不一样了。（xx费，可以理解为车贷行业）

以上。

电商平台支付结算系统设计 - 产品向

写在前面：这篇文章是笔者近期学习支付相关知识，在知乎、人人都是产品经理、掘金等等各个地方拜读各位大神大作后，梳理摘录汇总而成，仅供自己学习备忘，如有冒犯还请指出，谢谢~

整体分为交易系统（OMS）、支付系统、清结算系统、对账系统、会计报表（非必须）等几个部分。

支付系统是负责电商系统收款和出款的子系统，需要支持电商平台与外部渠道间，所有收款和出款的功能，以及电商平台内部账户间转账的功能。简单来说，支付平台需实现充值、提现、转账、退款四方面的功能。

一般来说，支付系统由以下几个功能组成。

第三方支付：微信和支付宝占据国内移动支付的绝大部分份额，因此是一定要接入的。
按照结算类型来分，收款类一般有即时到账、担保交易两种，出款类有转账、银行卡代付等。
如果电商平台有支付牌照，可以自己分账，或者收款类型为年费等无需分账的交易，那么可以选择即时到账方式收款。
如果电商平台没有支付牌照且需要给实现二级商户分账，则可以选择微信的收付通或支付宝的直付通等产品。但用户通过微信支付的订单才能通过微信的产品来分账结算，支付宝支付的订单才能通过支付宝的产品来结算，对于平台对接、商户收款皆有不便之处，因此电商平台很少选用这种方式。

银行卡支付
一般来说，电商平台接入了微信和支付宝后，已经可以满足大部分支付需求，无需再接入银行卡支付。而对于购买了支付牌照的大型电商平台，想要打造自己的支付工具，才会对接各大银行，接入快捷支付功能。或者有一定规模的电商平台也可以直接与银行签约，开通快捷支付接口。

和第三方支付不同的是，银行卡收单、退款，一般都不是实时结算的。而支付公司与电商商户的收单交易，是实时结算的，实际是支付公司提前垫资。

快捷支付
现在市面上大部分电商app中，银行卡支付功能都是使用的快捷支付方式。对于电商平台，如果需要接入银行卡快捷支付功能，有两种方式：

例如电商平台在工行开通了快捷支付接口，用户签约了工行卡快捷支付，用户付款后，资金扣款成功结算后，会进入电商平台在工行的结算账户。注意快捷支付是有经营业务种类限制的，只允许在签约经营范围内的业务收款，即MCC码。

如果是第三方支付公司，因为不允许与银行直连，需使用银联或银行提供的网联接口，用户支付后，网联结算后，金额会转移到支付公司在银行开设的备付金账户。

对于电商平台，与银联对接要方便快捷得多，一次接入即可搞定大多数银行卡的快捷支付；而对于有支付牌照的电商平台或第三方支付公司，为了更低的手续费，才会选择与银行直接对接。

银行卡快捷支付，需要先绑卡签约，后续则无需任何验证完成扣款，而为了安全性，电商平台会加上指纹、人脸、短信或支付密码验证，仅小额支付可以免验证。

快捷支付的签约，需要提供三要素（姓名，身份证号，银行卡号）或四要素（银行预留手机号），信用卡可能额外需要有效期和背后后三位数cvv。注意支付公司或电商平台是不允许保存用户的cvv码的。在快捷支付签约前，用户需先完成实名认证或更高级别的认证，以保证签约卡为本人银行卡。国家法规对于第三方支付用户的信息验证有3个等级，三级为最高安全等级，对应的付款限额和支付范围限制也更大。

对于第三方支付公司，为了安全性、手续费等原因，会与同一家银行，不同的总行分行，或者银联等其他通道，分别签约快捷支付；用户在绑卡签约时，或者后续签约支付时，可能在签约一个需短信验证的通道的同时，还签约了其他无需短信验证的通道。后续用户使用快捷支付时，支付渠道路由会自动选择当前最合适的支付通道发起扣款。对于同一张卡的快捷支付额度，使用不同的支付通道的额度是独立的，但总额不超过发卡行的限制。

对于产品侧来说，如果要实现快捷支付功能，前端需要实现签约卡管理、新增签约（录入卡信息 - 识别卡信息 - 签约结果返回）、解绑功能。

不管是第三方支付还是快捷支付，和支付公司签约时，都可以绑定多个收款账户，有时为了财务上的区分，不同业务可使用不同收款账户收款。

银行转账基础原理

跨行转账有超级网银和小额转账两种，限额都是5w以内，开放时间都是7*24小时，不同的是超级网银实时结算，小额转账银行跑批处理，是准实时的。大额转账是在5w以上，开放时间是工作日的 8:30 ~ 17:00，实时结算。银行提供的转账产品，基本都是基于上述三种方式包装的。

电商业务的退款、商户结算、佣金结算、供应商货款结算等业务都涉及到出款。

退款：一般来说，在支付后一段时间内（一般3到6个月），可以使用原支付渠道的退款功能，将资金原路返回。如果超过时间限制或部分退款次数限制，则无法原路返回。退款最多可能5~7个工作日才能确认返回状态；对于银行来说，一笔已经清算的收单交易，手续费已经扣取；就算产生退款，之前的收单手续费也不会退回。如果在结算之前退款，银行侧可能支持按比例退回手续费。第三方支付公司与电商平台之间退款手续费的收取，由双方协议决定。

银企直连：若电商公司已接入银行的银企直连产品，且支付对象已绑定银行卡，则可使用此方式。

第三方支付的代付功能：对于高频小额的付款需求，且用户已绑定第三方支付账号情况下，可使用此方式。
企业网银：一般用于2B的大额资金转账。资金结算或者用户提现。

对于第三方支付公司，用户提现时，同一个出款账户，会归集一定量（金额或条数）之后批量提交银行处理，所以提现不一定能够实时到账。

出款的前提是用户已实名认证，并绑定了实名对应的银行卡。绑卡需要验证四要素，会需要用到第三方支付提供的信息验证接口，或直接与银行对接。已经签约过快捷支付的借记卡，也可以用于该账户资金提现，无需再次验证。

各个支付渠道的接口指令各不相同，为了方便业务调用以及日后拓展维护，需要建立一个统一的支付网关，开放给业务使用；业务调用时同时指定支付渠道，支付网关请求渠道路由，按照事先配置的路由规则，返回最合适的支付通道，发起支付请求。
网关需实现不同类型的功能接口，一般来说就是支付通道侧接口能力的并集，如充值、提现、转账、退款、签约查询、实名认证校验等等。

引导路由：是指用户在付款时，给用户展示支付方式的规则，包含可见状态，可用状态，展示顺序等。引导路由的意义是，根据用户支付的场景，引导用户选择平台侧希望用户选择的支付方式。平台侧的需求一般是支付成功率高（通道稳定，额度充足）、费率低等，也有因不同支付渠道商务合作关系，限定额度分流的原因。
匹配接入的支付渠道比较少时，引导路由作用不大，一般可能只有一个简单的权重配置后台，即所谓的静态路由，或者直接记住用户上次选择的方式即可。

渠道路由：对于电商平台来说，如果只接入了第三方支付，则不存在渠道路由。对于支付公司来说，如果接入了不同银行、银联网联的快捷支付接口，且用户选择的银行卡签约了多个通道时，渠道路由则按照路由规则去匹配权重最高的渠道，发起扣款请求。

在断直连之后，支付公司的代收服务，只能通过银联或网联接口，因此渠道路由意义也削弱了。对于代付服务，支付公司会在各大银行都开设收付账户，将跨行转账都转化为同行转账，以提高转账速度免除手续费，同时支付公司需要做好备付金管理系统，自动或人工管理监控调拨各行备付金。

当业务向支付网关发起支付请求时，支付网关需要对业务方进行鉴权判断，确定请求是否合法。一次支付请求一般包含以下元素：业务标示，支付时间，支付金额，支付账号，支付客户端信息，支付订单信息等。支付网关需要确认各个元素都合法，比如支付时间是否在有效期内，此支付单是否过期；支付账号状态是否正常，支付订单是否是可支付的，商品是否有库存等等。同时还需要将这些信息过一遍风控，风控那边会根据各种规则判断此次支付是否有风险。风控是一个比较复杂的系统，属于另一个专业领域，在此不细说。

电商平台向支付渠道请求支付后，支付渠道会同步或异步返回支付结果信息。如果支付渠道不主动返回结果，电商平台侧则需要定时去轮询结果。同时电商侧需要将支付请求信息、结果信息、结果凭证等保存下来，也就是支付流水记录。支付流水记录是之后电商与支付渠道对账的凭证。

拿到支付结果记录后，支付系统需要向支付请求方返回支付结果，同时通知账务系统，触发对应的记账操作。

各个支付渠道都会按日和按月生成交易记录文件和资金流水账单，分为支付、退款、提现等类型。交易记录文件相当于信息流凭证，资金流水账单相当于资金流凭证。

银行渠道一般也会推送资金流水文件，但不是所有银行的交易都有业务对账文件，通常收单交易业务对账文件会普遍一些。

电商的支付系统或者对账系统，需要做的事情：

支付系统同样需要和上游各个业务系统进行对账，包装支付状态金额的一致性。一般采用明细轧帐的方式。

收单对账常见问题：
长款：用户支付了但是交易系统未确认支付成功，这种情况需要及时补单或者退款处理，一般如果业务侧订单状态是待支付则可转为支付成功，状态是已取消则自动退款；也有可能是测试数据混入了生产环境；也有可能能与之前的短款差错互相抵消；

短款：一般是日切问题导致，挂账后下个会计日继续对账；或者看是否能与之前的长款差错互相抵消；

重复支付：一般支付渠道都不允许重复支付同一个订单，发现重复支付也可以自动退款处理；
金额不一致：可能用户支付后，支付结果返回之前，交易系统订单金额变化了

退款常见问题：
网络问题或接口问题导致退款失败，这种情况可自动再次提交退款；
对方账户状态异常导致退款失败，这种无法走原路返回退款方式，只能转账/代付；
退款时需要处理好支付手续费的退款，以及退款手续费谁来承担的问题，一般是按比例退；
对于短款差错，可挂账7天处理。

提现常见问题：对方账户状态异常导致退款失败，需要及时通知用户处理。对于短款差错，可挂账3天处理。

产品侧需要设计对账管理后台，可查看支付流水，对账批次记录，差错处理后台等。对于固定处理方式的差错类型，可做成自动化处理。

合单支付是指用户一次支付多笔订单，在电商中很常见。电商业务侧需要自己做好订单拆分，支付系统中，如果使用支付渠道的合单支付接口，则会自动拆分记录支付流水，是最佳的方式；如果支付渠道没有合单支付接口，则可拆可不拆，按原始记录保存简单不易出错，拆分记录则可方便其他业务处理。

混合支付是通过多种支付方式，支付一笔订单，比如余额+快捷支付。混合支付会按照不同支付方式，生成多笔支付流水。

因为不同支付方式，支付成功率不同，可能会发生有的支付方式扣款失败的情况。因此混合支付需要按照支付成功率，优先扣款成功率较低的支付方式；如果有某些支付方式扣款失败，需要判断是取消支付，全部退款，还是提醒用户换其他方式继续支付；全部支付方式都扣款成功后，这比订单才支付完成。后续订单发生退款，如果是部分退款，需要判断，优先退款手续费最低的支付方式。

电商平台或支付公司有时候会做营销活动，出钱补贴支付，也可以用混合支付方式处理。

据说余额+卡的混合支付有洗钱风险，目前已逐渐少见。

对于大额订单，可以采用分次、分阶段支付的方式，实质也是一种混合支付。

订单完成时，电商平台需要扣取平台佣金，结算货款给商家；若涉及推广服务，则需要计算推广用户的佣金和税额，再结算给推广用户。

按照法规，没有清结算牌照的电商，不允许自行截存货款，之后再结算给商家。电商平台可以选择第三方支付公司或者使用银行的电商清结算产品，由他们代为保存货款，之后再结算给商家。此类产品需要先提交商户资料给支付渠道或银行审核，审核通过后，用户支付此商户订单，提交支付同时上送清分规则（分给哪些人，按照什么比例或金额）。在订单交易完成时，电商侧提交结算请求，支付平台按照此前支付时上送的清分规则进行分账结算。部分支付平台，需要在结算时由电商平台指定分账对象和金额，但这样略有二清嫌疑。

选择这类清结算产品时，还需要注意以下几点：

接入此类产品后，除了后端的支付、结算接口对接以外，电商平台商户侧客户端，也需要对接好商户入驻进件，提现账户绑定，结算账单等功能。

电商平台常见的分销、主播代销、拼团、淘宝客等销售模式，其中“分销商”或“团长”角色，本身不是销售主体，在订单完成后可获得推广佣金。一般来说，这部分推广费用，在订单生成后，商户侧可在订单费用明细中看到此支出项；在订单结算时，可将推广佣金与平台佣金一起扣除，再由平台将推广佣金结算给推广人员。

这类支出属于劳动报酬，平台有为推广人员代缴税的义务，需要按月计算税率和金额。因此部分平台采用月结的方式，每个月指定日期，计算每个待结推广人的税费，扣除后再将税后金额结算给推广人。也有部分平台（比如O2O，网约车平台等），会自己承担此部分税费（羊毛出在羊身上），在订单结算时，即时将推广佣金结算给推广人，次月再统计推广人税费，平台自己为推广人交税。

平台也可以采用各种税务筹划方式，比如“灵活用工”的方式，与推广人建立非全日制劳务关系，这样推广人可以享受更低税率。

平台自行结算给推广人，可使用银企直连、支付平台代付等功能进行出款。而平台代缴税需要推广人的实名信息，所以在推广人在提现佣金之前，需要先实名制认证。

不管采用哪种结算方式，电商平台都需要计算订单结算时的各类费用明细（清分），负责清分的模块，也叫做计费系统。

电商平台有花样百出的扣点规则，比如按商品、按商户、按品类、按营销活动等规则扣点，以及各类推广佣金等。扣点规则路由对应着各类扣点规则，比如针对商品、商家、类目的扣点规则管理后台，基本元素是扣点对象、扣点比例、扣点上线、规则生效时间范围、规则状态等。产品经理需要和运营人员确认好扣点规则判断逻辑，即根据怎样的条件判断顺序，确认订单适用的扣点规则。之后加入新的扣点规则时，也需要维护这个扣点规则路由。

扣点规则路由各电商平台都不一样，可能包含营销活动、下单/支付客户端、买家身份、扣点规则权重等等。

一般在订单创建时，扣点规则路由就需要根据订单相关的信息，判断出订单适用的扣点规则并记录下来。同时也需要将用于判断的信息元素保存下来，以作为之后核对凭证。

如果订单有推广员的参与，则也需要在订单创建时，计算出需要扣除的推广费用，并保存记录相关推广员信息。

在计算各方分账明细时，需要注意几点：

与订单交易相关的清算，一般来说，是在订单状态变为终态（交易完成，退款完成），且订单尚有待结算金额时，由交易系统向清结算系统提交清结算请求。也有一些多次结算的场景，比如订单里有部分商品先确认收货时，也可以先结算部分金额，后续再结算剩余金额。

对于有支付牌照的大型电商平台，为了提高商户的回款速度，也可以在订单尚未变为终态时给商家结算货款，比如用户确认收货时或者商家发货时。如果结算后订单发生退款，则再在商户钱包中扣除相应金额。此类结算方式需要平台侧有比较成熟的风控能力，通过风险控制和风险转移的方式，防止平台资金损失。比如和商户签约协议，设置商户保证金，商户买家风控，购买对应的赔付保险等等。

交易系统向清结算系统发起结算请求时，需提交结算订单、结算金额、结算类型（完全/部分结算）等字段。清结算收到结算请求后，可能实时结算，也可能异步周期结算，比如每X小时一次等，视业务量大小决定。

开始结算时，计费中心从账务系统获取订单待结金额，根据结算类型核对结算金额，核对无误后，冻结待结算金额，并提交到计费中心；计费中心找到订单快照中的扣点规则，计算分账明细。

计费中心计算出各方分账明细后，需要和账务中心进行实时或准实时的对账，保证需结算的金额等于各方分账明细之和。核对无误后生成预结算单。

大部分订单，此时结算中心可将结算单提交到支付系统，进行最终的资金转账。小部分订单，结算单可能需要人工审核，则需要审核通过后再提交到支付系统，或者驳回撤销此次结算。

各分账方一般会提前在支付系统内部开设好账户，支付系统会将资金结算到各方的资金账户中，对于支付系统来说，仅涉及内部账户间的资金转移，因此很少会出现结算支付失败的情形。

支付系统返回结算成功结果后，结算单状态变为结算完成；结算系统需要实时通知交易系统和账务系统，账务系统记录各账户资金变化，更新账户余额；交易系统则触发对应的消息通知等关联服务。如果有会计系统的话，也需要异步通知会计系统，进行会计分录记账。

对于成熟的支付公司，会有账务系统和会计系统两套系统。这两套都是以会计分户模型来设计，不同的是账务系统是直接面向业务使用，随着业务信息流实时记账并更新余额，账务流水更多记录交易相关内容；会计系统是面向财务会计使用，一般是异步入账，使用严格的复式记账法。
账务系统中的账户，必须是在是账务系统分户中的叶子科目下。两套系统之间的分户模型，会有多对多的关系。账务系统这套体系可称为分户账户（外），会计系统这套称为分户账户（内）。

按照复式记账法，一般分为资产、负债、损益、共同类等。

交易的实质就是各金额账户间资金的转移，因此首先需要建立好对应的账户。
账户设计遵守三户模型：客户、账号、账户。
客户：指自然人或企业，必须要实名认证才可以开通支付账户，客户以身份证号为唯一标识。

账号：登录账号，一个客户可以有有限多个账号，即一个身份证可以用于有限多个账户用来实名认证。但对于同一个支付公司，一个身份证下多个账号，支付额度上限是共享的。根据身份认证信息丰富程度，支付平台余额账号等级分为一二三类，3类拥有的支付额度和权限最高是20万/年。余额提现、余额宝支付、信用支付无年度额度限制。银行卡快捷支付签约、提现银行卡绑定等操作，也是以账号为主体操作。

账户：每个账号在支付平台或电商网站，都会有多个不同功能的账户。商户侧有货款结算账户，保证金账户；买家侧有支付账户，信用支付账户，积分账户；或者电商平台侧的内部账户，比如活动补贴账户，订单担保账户等。

账务核心主要有四张表：分录流水、分户账、明细账、总账。

首先需要有一个交易码 - 分录规则的分录规则表，用来维护每种用交易码区分的交易场景，发生时应该如何拆成会计分录的规则。比如定义交易码1001为订单银行卡快捷支付，那一笔订单付款流水，经过支付平台，同步到账务中心时，根据同步过来的交易码1001，找到对应的分录规则，按照规则中的定义，生成会计分录：

当一笔业务发生时，首先生成分录流水，然后驱动账户余额变化，账户余额变化后，生成明细账。日终根据分录流水生成总账。根据业务需要，也可以先修改账户余额，然后异步生成分录流水，但是无论先生成会计分录，还是缓冲异步生成会计分录，都要保证分录流水与分户账余额的一致性，这一点通过日终系统的检查来保证。

每天首先需要做支付渠道的对账，然后再进行账务系统和会计系统内对账。
需要做到：

错处理需达到2个效果，一个是完成对账，另外一个是将账务对平，常见的账务处理方式有挂账、登账、调账。
补单：通过人为干预方式，将原有业务进行下去，如通过接口人工干预订单状态
挂账：对于不平账单，先挂起，等查明后再进行相应处理
登账：会计记账，伴随虚拟资金从一个账户向另一个账户转移的过程（原始凭证）

1、多账
多账主要存在2种情况，一种是异步通知未收到，优先采用补单处理，另外一种是同订单2次支付，一般通过登账处理
2、短账
基本不会出现，一般通过签名防抵赖机制与第三方协调处理。协调一致后通过人工增加对账单进行平账。
3、金额不一致
出现概率极低，一般为电商平台内部计算有误。
首先得先解决此bug，然后根据异常订单相应处理，比如说撤销对账，修改系统或对账单金额后再进行对账。 关于账户系统接口设计和账户体系设计的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 账户系统接口设计的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于账户体系设计、账户系统接口设计的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。