| 账户体系是支付系统的基础，它的设计直接影响整个系统的特性。这里探讨如何针对电子商务系统的支付账户体系设计。我们从一些基本概念开始入手，了解怎么建模。
支付账户和登录账号
账户体系设计首先要区分两个概念，支付账户和登录账号。 这是两个不同业务领域的概念：支付账户指用户在支付系统中用于交易的资金所有者权益的凭证；登录账号
指用户在系统中的登录的凭证和个人信息。 一个用户可以有多个登录账户，一个登录账户可以有多个支付账户，比如零钱账户，储值卡账户等。
一般来说，支付账户不会在多个登录账户之间共用。如果没有特殊说明，下文中的账户，都默认指支付账户。
账户的设计需求
在支付系统中，账户的设置，主要是从如下几个方面来考虑：
交易的需求，比如检查账户是否被锁定、余额是否足够、是否有效等。
记账的需求，按照公司会计需求记录账户上的所有行为，包括支出、充值、转账等。
对账的需求，包括和支付渠道、商户、个人的对账需求，核对交易和账户余额是否正确。
风控的需求，如反洗钱、反欺诈等，都需要依赖于账户体系来提供核心数据。本文暂不分析这个内容，将在《支付风控》、《支付反洗钱》这两篇文章中详细分析
信用的需求，对用户、资产、商户等主体进行信用评估时，也需要依赖账户体系来提供的核心数据。本文也暂不分析这内容，将在《信用与支付》一文中分析。
这五个需求，按照其设计的优先级，也是从支付、记账、对账、风控来进行。
支付系统根据其发展所处的阶段，逐步将新增需求纳入设计中。
交易与账户
账户设置，一般是从交易开始的。 交易的实现必须有账户的支持，账户是交易的基本构成元素。
从支付系统的角度，交易中涉及到的资金流是资金从一个账户流向另一个账户。 发起交易的一方，被称之为交易主体，他可以是个人，也可以是一个机构。
资金从该主体所拥有的账户中流出。 而接收交易的一方，被称为交易对手，他也可以是个人，或者机构。
和第三方支付或者金融机构的交易不同，电商系统中，交易还会涉及到渠道。
由于电商系统本身并无清结算的资质，所有资金从交易主体到交易对手的账户的流动，在大部分情况下，并没有经过电商系统，而是由电商系统调用支付渠道提供的接口，由它来完成真正的支付过程。
当然，渠道也不是活雷锋，在这过程中，渠道要收取费用。
所以，在电商系统中，一次交易会涉及到三个账户： 交易主体账户、交易对手账户以及支付渠道账户。
如何在这三个账户中完成一次交易，我们将在后续的《交易和记账》一文中详细分析。
记账与账户
公司的会计需要对每一笔交易都要做详细的记录，即记账。 公司每天都产生大量的交易行为，为了便于管理和统计，一个简单的方法是对交易进行分类，比如食品、带宽、办公用品等等。
这个分类，按照公司的规模和业务复杂度，可以有一级，二级，三级或者更多级的结构，这被称之为会计科目。 记账时，除了交易明细，还需要在每个级别上对交易额进行汇总。
一般来说，一级科目上汇总称为总帐科目，而详细记录称为明细科目。 在电商系统中，由于涉及到的参与方较多，记账也相对复杂，但基本方法也是类似的。
电商的参与者可以分为商户、买家和渠道，对这三类参与者，都需要分别建立总帐账户和明细账户。
内部账户和外部账户
当用户使用银行卡来支付时，电商支付系统需要和银行对接，从用户银行卡所代表的账户上扣除资金。对接了银行，第三方支付等机构的电商支付系统，它需要连接到用户在这些机构的账户来执行扣款或者充值操作，这些账户或称为外部账户。对外部账户，支付系统只能记录账户在本系统的明细以及累计消费额，无法得知账户真正余额。
不少电商在玩零钱的概念，也就是让用户充值到零钱，使用的时候就直接从零钱中扣除。这就需要零钱账号。这是电商系统中自己设立的账号，所以也叫内部账号，可以知道账号的全部消费明细和余额。
当然，除了零钱账号，也可以有储值卡账号，信用账号等。
那问题来了，什么时候需要建立账户，比如优惠券，需要账户吗？ 一次消费的储值卡和可以充值的储值卡，需要建立账户吗？这里先埋个雷，后续介绍支付和记账时，给出答案。
收款账户和收单账户
当电商要对接银行时，往往都会被要求开设一个收款账户。用户通过这个银行来支付时，钱就被转到这个账户上。
对第三方支付也是一样。收款账户是开设在银行或者第三方支付这边的， 即渠道侧。 一般来说，渠道每天都可以提供这个账户的交易流水供电商对账用。
这样在电商这边，渠道就成为一个收单机构。 所以在电商这边，建立这个收款账户对应的对账用的收单账号，用来记录通过这个渠道进行的各项交易流水。
账户建模
说了这么多，目的是为了对账户建模。 账户模型是和公司业务密切相关的，公司不同规模，发展的不同阶段需要不同的模型。
账户建模本身包括三大核心模型：实体模型、账户模型和交易模型。 从交易模型中可以衍生出针对各个角色的账户流水，即明细模型，用于支持对账。
实体模型
实体模型和用户、商户模型有重叠的地方，这里专门针对支付而设置的各个实体属性。
一般来说，支付相关的实体模型需要包括如下的属性：
用户ID，一般直接映射到登录账户的ID；
是否允许执行支付； 支付密码；
用于设置或者重置支付密码的手机号；
用户设置或者重置支付密码的邮箱；
用户的安全等级，根据业务需要来设置。
账户模型
根据业务需要，可以设置多种账户，如支付账户、预付卡账户、代扣账户、零钱账户、结算账户等。
从类别上来说，这里的账户，一般指总账账户。一般来说电商系统中涉及的账户类型有：
虚拟币账号：用户和使用奇点奇豆的商户都需要建立虚拟币账户。
代扣账号： 用来支持订阅类型的定期代扣；
零钱账号：即电商的内部账号，用户、商户、清算单位需要建立零钱账户
第三方支付账号：用户在第三方支付机构建立的账户。
银行卡账号：用户的银行卡信息，每个卡对应一个账户。
结算账号：用来支持和第三方支付公司、银行进行结算用。 第三方支付需要为每个商户号建立结算账号；银行需要为借记卡、贷记卡分别建立结算账号（有必要吗？银行卡直连时使用）。
代扣代缴账户：用来支持代扣税款业务。 对这些账户，需要设置如下属性：
基本属性，包括：
账户号，或称为账户ID，一般是系统自动生成。特别注意的是，要事先约定好账户ID的规则。比如头三位用来表示账户类型，后几位用来表示账户编号等。务必保证根据账号号能够快速确定账户类型，并且保证账户号是不重复的。
账户名称，一般是由用户自己设置的，显示用。
账户使用的货币类型，注意虽然一张银行卡可以支持多个币种，实际在内部，还是针对每个币种建立独立的子账户。
涉及到多币种的账户，也可以采用类似的建模方案。
会计科目代码，一般是一级会计科目的代码。 账户控制相关：
是否允许充值；
是否允许提现；
是否允许透支；
是否允许支付；
是否允许转账进入；
是否允许转账转出；
是否有安全保障；
是否激活；
是否冻结。
资金相关：
当前账户余额：等于可用余额+冻结余额；
当前账户可用余额；
当前账户冻结的余额。
冻结余额指在账户上暂不能使用的额度。在支付的时候，往往是先冻结，商品出库后，
再实际执行扣款。
银行卡、第三方支付信息：
第三方实体的ID；
第三方账号，如银行卡号或者在第三方支付的open_id等；
第三方的app_id；
账号的失效日期，该账号什么时候失效。
注意，有些第三方信息是不能保存的，如用户的账号密码、信用卡的CV号等。
为了避免账户信息被爬库或者数据库信息意外泄露，一般还需要对敏感字段，如密码等，进行加密保存，甚至保存到另外的表中。
更进一步，为了避免账户信息被意外修改，还可以增加一个校验字段，在写入数据时设置该字段，在读取数据时做校验，一旦发现数据有问题，则关闭该账号。
交易模型
交易记录，交易流水，账户流水，交易台账，这三个容易混淆的概念，从数据上来说，却并不复杂，它们的核心是交易流水，账户流水是从账户视角的交易流水。那对一笔交易，涉及到的方方面面内容很多，有哪些需要记录的呢？考虑到交易记录将被用于风控和信用分析，能收集到的信息是越全面越好。
流水号：每一笔交易的流水号都不一样。需要根据业务情况详细设计流水号。这个号往往也是对交易表做分表分库的依据。
交易记录创建时间；
交易记录最后修改时间； 会计科目代码< 关联的订单号，由商户提供； 订单名称、描述、关联的地址等信息；
费用信息，包括： 结算货币类型、原始费用、实际费用等；
交易主体信息，记录主体ID、类型、名字、账号、账号类型、使用的IP地址、手机号、平台、通知邮箱、当前位置等。
这些信息虽然可以从主体表中获取，但考虑主体表信息随时会被修改，所以这里需要记录详细的各原始信息。
交易对手信息，记录对手主体的ID，类型，名字，账号，账号类型，手机号，平台，通知邮箱等。
交易渠道信息，记录所使用的交易渠道的实体id，渠道账户，渠道执行支付的时间、渠道侧返回的订单号等。如果有错误发生，还需要记录从渠道接收到的错误信息和错误码。
总结
如上内容，不管是账户还是交易，模型都很复杂。是否有必要记录这么多信息，如何在交易中使用这些模型，请关注后续文章。 |
