2、账户信息：比较重要的属性是账户资金/余额。这里的账户资金其实只是虚拟账户的资金信息，并不是实际的资金。实际的资金存放在支付平台在银行设立的银行账户中。如果是银行账户体系，就代表实际的资金在相应的银行金库中，可以通过ATM随时提取。

会计方法

金融机构的核心账户/科目设计一般采用复式记账，如果要求不高或者技术储备有限，很多企业直接采用单式记账。虽然两者都能满足业务需求，但与复式记账相比，单式记账无法从借/贷、科目/科目多个维度进行交叉核对，保证核心账户的平衡。目前部分电商平台甚至支付公司采用单式记账，银行等金融机构通常采用复式记账。

会计科目

会计科目是对会计要素具体内容进行划分和计算的类别，会计对象的具体内容不同，管理要求也不同，这部分我就不详细介绍了，有兴趣的可以找本会计相关的书单独研究一下。

一般来说，会计科目分为资产、负债、所有者权益、费用、损益、一般六大类。

具体需要哪些科目、哪些账户，需要仔细分析业务场景、业务模型后才能确定。

记账流程

为了提高交易性能，必须将交易与会计分离，提高交易处理性能和效率，这样才能有针对性地解决复杂的业务逻辑。因此，在支付系统的设计中，我们一般将会计分为两步，支付成功后，系统同步记账，异步通知会计系统做复式记账。

传统的第一代支付系统通常在每日结束时进行批量记账；而当今流行的支付系统设计通常采用异步准实时记账，并在每日结束时根据银行对账单进行批量结转验证和记录当日日记账分录。

所以一般来说我们的支付流程和会计流程是分开的，我会另外写一篇文章来专门讲解这部分，大家也可以参考支付宝架构里的会计分析流程。

产品架构师

客户信息子系统技术设计

有关客户和用户的信息

顾客是一个社会化的概念，凡是自然人或者法人（任何社会、组织、事业单位等，具有密切社会关系和相似消费特征的群体）都称为顾客。

自然人的社会属性一般包括姓名、性别、年龄、职业、联系地址、联系电话、证件种类、证件号码、电子邮箱、工作单位、工作性质、职务等。

同样适用企业客户的概念，该实体应该包括企业客户社会属性的描述，如企业组织名称、证件类型、证件号码、联系人、联系地址、联系电话、企业组织性质等。

用户是客户使用产品或服务（签订协议）时产生的实体，如果一个客户使用多个产品，就会有多个用户。

客户信息子系统技术设计

一般来说，客户、用户信息都是比较静态的数据，数据量并不大，即便是只有几亿用户的微信，用单库单表就可以支撑，数据库只需要考虑主从高可用、读写分离，条件允许的话可以加集群做缓存，对外提供服务的应用直接提供数据库读写操作即可。

账户子系统

帐户子系统存储元素

此系统是整个账户体系的核心，按照产品设计划分会计科目后体现为单独的账户，这些账户在系统中具体实现为两类数据库表，一类是账户余额表（也叫账户表），主要用于记录账户基本信息：账户ID、名称、会计科目、可用余额、冻结余额等；另一类是账户交易表（也叫余额变动明细表），记录了这些账户所有相关变动的交易记录。

账户子系统技术设计

在存储层面，首先需要考虑的是，会有大量账户交易，所有的查询和检索都是按账户进行的，因此可以考虑按客户号进行水平切分，数据库和表分离，保证交易过程中只查询单表，不需要跨库或者多表查询。

在应用设计层面，对外提供单边借贷及冲销接口，对内提供灵活的产品工厂封装，另外对于一些异步通知功能如账务变更短信、报警等，都可以使用MQ异步完成，不影响正常交易。

会计子系统

系统可以作为在线异步或日终批处理系统，与科目系统隔离，独立完成记账、核销。此部分可以采用的技术有很多，各个公司可以根据自己的具体情况进行选择。