电子钱包/支付系统设计与分析

一、背景

由于印度尼西亚的某众筹机构需要开发一个站内电子钱包系统，所以基于此需求特意做了一番调研。

如今，一些平台如：P2P理财、旅游、游戏等平台都有自身的虚拟钱包系统，像这种站内的电子钱包系统应该如何设计呢？

首先让我们搞清楚什么是站内电子钱包？和商业的支付系统有什么区别？

站内电子钱包，就是用于站内支付的、非商业的、仅限于为公司内部的业务提供支付支持的支付系统。

商业的支付系统，如：支付宝、微信支付、京东支付等，设计一套完整的商业支付系统是非常复杂的。

和商业的支付系统相比这类系统没有开放平台、开放接口、商户注册等。

所以站内电子钱包，本质上就是一套小型的支付系统。麻雀虽小五脏俱全！下面让我们看看主流的支付系统是如何设计的。

二、支付系统

2.1 什么是支付系统

支付系统是连接消费者、商家（或平台）和金融机构的桥梁，管理支付数据，调用第三方支付平台接口，记录支付信息（对应订单号，支付金额等），金额对账等功能，根据不同公司对于支付业务的定位不同大概有几个阶段：

第一阶段：支付作为一个（封闭）的、独立的应用系统，为各系统提供支付功能支持。一般来说，这个系统仅限于为公司内部的业务提供支付支持。

第二阶段：支付作为一个开发的系统，为公司内外部系统、各种业务提供支付服务，支付服务本身应该是和具体的业务解耦。

下面让我们了解下支付系统的整体架构体系，以及主要功能模块。

2.2 主流支付系统整体架构

每个公司根据其业务和公司发展的不同阶段，所设计的支付系统也会有所不同。我们先看看互联网公司的一些典型的支付系统架构。

支付宝
先看看业内最强的支付宝系统，支付宝的支付系统整体架构设计

京东金融

来自京东支付平台总体架构设计 。

去哪儿

来自去哪儿公司分享的支付产品架构

美团

来自美团的支付平台规划架构 。这是2015年的文档。 2016年美团才拿到支付牌照。

这些架构文档全部来自互联网公开资料。 对于架构是否真实反映实际系统情况，需要大家自行判断。

参考架构

一般来说，支付系统典型架构会包含如下模块：

支付系统从架构上来说，分为三层：

支撑层： 用来支持核心系统的基础软件包和基础设施， 包括运维监控系统、日志分析系统等。
核心层： 支付系统的核心模块，内部又分为两个部分： 支付核心模块以及支付服务模块。
产品层： 通过核心层提供的服务组合起来，对最终用户、商户、运营管理人员提供的系统。

支付基础设施

支撑系统是一个公司提供给支付系统运行的基础设施。 主要包括如下子系统：

运维监控： 支付系统在下运行过程中不可避免的会受到各种内部和外部的干扰，光纤被挖断、黑客攻击、数据库被误删、上线系统中有bug等等，运维人员必须在第一时间内对这些意外事件作出响应，又不能够一天24小时盯着。这就需要一个运维监控系统来协助完成。
日志分析： 日志是支付系统统计分析、运维监控的重要依据。公司需要提供基础设施来支持日志统一收集和分析。
短信平台： 短信在支付系统中有重要作用： 身份验证、安全登录、找回密码、以及报警监控，都需要短信的支持。
安全机制： 安全是支付的生命线。 SSL、证书系统、防刷接口等，都是支付的必要设施。
统计报表： 支付数据的可视化展示，是公司进行决策的基础。

远程连接管理、分布式计算、消息机制、全文检索、文件传输、数据存储、机器学习等，都是构建大型系统所必须的基础软件，这里不再一一详细介绍。

2.3 支付系统的主要功能模块

上面这些大厂的支付系统由于已经商业化了，所以比较复杂。让我们简化下一个支付系统的主要功能模块有哪些。

应用管理: 同时支持公司多个业务系统对接。
商户管理: 支持商户入驻，商户需要向平台方提供相关的资料备案。
渠道管理: 支持微信、支付宝、银联、京东支付等多种渠道。
账户管理: 渠道账户管理，支持共享账户（个人商户）及自有账户。
支付交易: 生成预支付订单、提供退款服务。
对账管理: 实现支付系统的交易数据与第三方支付渠道交易明细的自动核对（通常T+1），确保交易数据的准确性和一致性。
清算管理: 计算收款交易中商户的应收与支付系统收益。
结算管理: 根据清算结果，将资金划拨至商户对应的资金帐户中。

Ok，到此我们已经了解了一个支付系统的基本架构和主要模块。那么接下来如何从零开始设计一个支付系统呢？这个我觉得应该从账户体系开始。

一个好的支付系统，离不开一个好的支付账户体系，而一个支付账户的设计又依赖于账户体系，所以在开始设计支付系统之前应该先了解并梳理清楚账户体系。

三、账户体系

账户是用来记录会计科目所反映的业务内容的工具，它根据会计科目来开设的。账户有多种维度的分类。 按照经济内容来说，账户分为资产类账户、负债类账户、所有者权益类账户、损益类账户、成本类账户和共同类账户。 按照会计周期内期末是否有余额，也分为实账户和虚账户。

既然支付账户的建立和和会计科目有关，那我们首先来了解下这些会计科目。

3.1 资产类账户

用来反映资产增加、减少以及增减变动结果的账户。和支付系统相关的主要资产类账户有： 银行存款、应收账款、预付账款、库存商品、发出商品等。 资产增加登记在借方，减少登记在贷方，期末有余额的话，一般出现在借方。 在一个会计期间，所有借方金额的累加为“借方本期发生额”，所有贷方金额的累加为“贷方本期发生额”。

资产账户的余额=借方期初余额+借方本期发生额-贷方本期发生额。

为了跟踪在每个银行的存款变更情况， 需要对公司在各个银行开通的收款账户设置对应的银行存款账户、应收账款账户。在小明购买会员卡的案例中，资产类账户包括：

1. 银行存款，这是一个总账账户，记录电商公司在各个银行的总存款。
2. 应收账款，这是一个总账账户，记录在银行的应收账款，这是虚账户，期末无余额。
3. 银行存款-工行，这是一个明细账户，对应在工行的对公账户的存款变化；
4. 应收账款-工行，这是一个明细账户，记录在工行的收款情况，这是虚账户，期末无余额。

3.2 负债类账户

负债类账户也是实账户，记账规则跟资产类相反，负债增加记为贷，负债减少记为借，期末如有余额，一般在贷方，表明期末有债务实有额，负债类账户的余额计算：

贷方期末余额=贷方期初余额+贷方本期发生额-借方本期发生额。

从支付系统的角度， 电商公司的自有账户，包括针对个人的账户和针对商户的账户，一般放在负债类账户下，此外，应付账款、预收账款、应交税费等，也是负债类账户。

3.3 所有者权益类账户

所有者权益类账户用来反映所有者权益增加、减少和变动结果的账户， 记账规则跟负债类账户一致：所有者权益增加记为贷，减少记为借。和支付系统有关的所权账户包括 本年利润、利润分配等账户。 企业取得的收入最终会使得所有者权益增加，因此收入类账户的记账方法跟所有者权益一致：增加记为贷，减少或者转销记为借，通常该账户期末无余额（因为期末收入都会转为所有者权益，如未分配利润等），属于虚账户。

3.4 损益类账户

损益类账户分为收入类和费用类账户。

收入类账户指各种收入、补贴、投资收益，如主营业务收入、其他业务收入和营业外收入等，增加记为贷，减少记为借。

企业在日常经营活动中会发生各种各样的耗费，这些耗费在会计学上称为成本费用，它们是收入的抵减项目，在抵销收入之前，可以视为一种资产，因此成本费用类账户的记账规则跟资产类一样：增加记为借，减少或者转销记为贷。费用类账户包括：主营业务成本、其他业务成本、营销费用等。

按照企业会计制度的规定，损益类账户的科目余额，应该结转入利润分配科目，期末余额为零，为虚账户。

在本案例中，损益类账户包括：

1. 主营业务收入，这是总分类账户。
2. 主营业务收入-会员卡，针对会员卡业务的收入。
3. 营销费用，这是总分类账户。
4. 营销费用-优惠券，用来跟踪优惠券相关的支出。
5. 渠道费用，这是总分类账户。
6. 渠道费用-工行： 用来跟踪在工行的渠道费用支出。

3.5 成本类账户

有成本核算的企业需要设立的账户，包括生产成本、劳务成本等，本文暂不涉及。

3.6 共同类账户

这是反映特殊经济业务的账户， 本文暂不涉及。

3.7 账户体系

Ok, 科普了账户体系，那么接下来需要考虑如何设计支付账户了。

四、E-Wallet 系统设计

4.1 准备工作

开通备付金账户

对于支付平台来说，首先应在银行设立一个或多个账户，用于归集客户或商户的备付金（粗俗地可以理解为，客户/商户充值、支付、交易等待结算的资金）

其次，对于首次申请开户的用户，支付平台为每个用户（基于用户身份证）开通一个唯一的主账户，和一个余额账户（子账户），主账户下可以添加多个子账户。

以支付宝为例，一个身份证可以认证6个支付宝账户，除其中1个主账户外，其他5个都是子账户。

为什么需要有备付金账户？

如果用户钱包里的钱都存放到企业对公账户，那么这部分钱是企业的收益呢？还是用户的存款呢？根本分不清楚。企业会将用户的存款挪为他用，这样用户的资金没发监管，风险极大。

备付金管理办法的核心是什么？

核心就是三种账户，分别为存管账户、收付账户、汇缴账户。

存管账户就是大老婆，每家支付公司只能有在一家银行开立存管账户。你选择了工商银行，就不能选择华夏银行。存管账户里的钱可以跨行划款、同行划款、用起来和普通的对公账户完全一模一样，不受限制。但一般存管账户只能开一个，也有的支付公司，会选择在同一个银行不同地区的分行之间开账户。

收付账户就是姨太太，每家支付公司可以在每一家银行都开立一个收付账户，但收付账户不能跨行划款，除非收款账户是存管账户。收付账户只能同行划款，A支付公司可以在工行开一个收付账户、在农行也开一个收付账户，但一旦在农行上海分行开一个账户，就不能在农行深圳分行再开收付账户了。

汇缴账户就是一夜情的情人，随便在哪家银行随便开几个，但是这个账户日终清零，只能把这个账户里的钱每天归集到本行收付账户或是跨行归集到存管账户，好可怜。有的人问，那汇缴账户有啥用？比如某个支付公司和某家分行合作了一个网上收单业务，那么这个汇缴账户就是这家银行每天把收单的钱结给这个支付公司的账户。

备付金账户之间头寸是如何调拨的？

存管账户、收付账户、汇缴账户之间的钱是如何调拨的？

首先明确的一点，这个钱不会走银联的系统的，这事情和银联没有啥关系。那么汇缴账户到收付账户，就是通过每家银行的行内转账进行调拨。汇缴账户、收付账户到存管账户，就是通过人行的大小额系统、跨行清算系统（俗称超级网银）或是同城系统进行调拨。

当然我们说的系统，都是背后的系统，实际上前端的产品就是各家银行的企业网银、银企直联，甚至极端点，你去柜台把这个钱完成调拨都没问题。

每家银行现在陆续的都上了备付金管理系统，这个系统对接了每家支付公司，让银行能够掌握支付公司在自己银行开设的所有备付金账户的每日余额和资金调拨明细，并且做到汇缴账户能每日清零，控制收付账户、汇缴账户的跨行转账权限，并且每日能生成报表报送给人行。

这些措施都上了的话，基本可以杜绝支付公司卷款跑人的问题了。

4.2 支付账户

先来解释下什么是支付账户？

支付账户是指支付机构根据客户的真实意愿为其开立的，用于记录预付交易资金余额、客户凭以发起支付指令、反映交易明细信息的电子薄记。（摘自《非银行支付机构网络支付业务管理办法》） 例如我们熟悉的支付宝余额账户、微信钱包账户。

还有另一个容易混淆的概念--用户账号。用户账号是用户在支付机构的唯一识别编码，一般是用户登陆时使用的账号，例如你的支付宝账号。

同一个用户账号下，可以有多个不同用途的支付账户，即1 ：N的关系。例如余额账户、储值卡账户。

4.3 三户模型

实际上不同公司对底层账户体系的搭建依托于本身的场景及账号基础服务等，但大体上都是围绕三户模型做的设计。

三户体系架构

客户：为自然人或法人，分为个人、企业、商户等，不依托于第三方企业属性；需要一些具有法律效应的证件去佐证客户是真实存在的，因此需要有身份证、护照、营业执照等作为证明。互联网2C和2B的业务会有针对客户的实名认证、资质审核等以便做客户管理。一个自然人可能会有多个账号，如一个人同时有微信、支付宝或京东账号；也可能会有多个账户，如一个人有多张银行卡、白条或小金库账户。

用户：为账号层面的属性，依托于第三方企业属性。如小明是用户，需要满足注册/登录体系条件，注册为用户，登录密码、昵称、账号等级、联系方式等都是基于账号层面的管理。一个账号下可以有多个账户；同时用户层面会有基本信息，如实名信息等。

账户：一般是对资金信息的管理，如资金余额、资金账。对于金融科技而言，一般都是虚拟账户管理而非真实的资金（真实资金一般都通过银行账户管理）。账户系统跟账务系统挂钩，有单式记账法和复式记账法，一般会结合交易订单管理及相关场景（信贷还是储蓄等）。

支付平台为了方便管理不同场景的资金或不同客户的资金，会有主账户、子账户之分，这样也有利于不同子业务的灵活开展。支付平台一边连着用户，一边连着银行，为了方便归集管理资金，支付平台不会为用户一一对应的设计银行账户，而是在银行设立一个总账户管理不同场景的用户资金。

因需要严格的记账及对账逻辑，所以要有虚拟资金帐管理及结算系统管理。不同支付平台采用的方式不一样，有的采用资金池模式（基于总虚拟账户管理），有的采用虚拟账户模式。

4.4 支付账户体系设计

可以说支付账户体系的设计是整个支付系统中最重要的一块，因为它是整个系统的基石。

4.4.1 支付系统数据结构

Ok，了解了三户模型，现在我们需要根据三户模型构建账户结构了。

支付账户结构图

根据此结构关系，下面先给出整体的、关键的数据结构设计。

账户相关表结构

交易相关表结构

以上基本是最核心的数据结构了，当然，不是全部的。

接下来需要梳理下个人、企业开户、充值、支付的流程，以及结合上面的数据结构做一些讲解。

4.4.2 开户

每个用户必须开通支付账户，开通支付账户必须进行实名认证。账户按照所有权可以区分为个人账户、商户/企业账户、内部支付账户。

个人账户：是面向个人用户开设的电子账户。
企业账户：是面向企业、机构等开设的账户。
内部账户：是平台为自身业务开展的需求而为自己设立的账户。

除此之外，支付系统还可以根据业务需要设置各种不同的账户类型。

由于我们是开发一个内部使用的电子钱包，未来有可能会对外提供支付服务。所以在设计上我尽量兼容以后的业务。

开户会设计到以下4张表

客户实体：是完全独立的个人、企业身份信息，是需要认证的。

客户账号：支付系统相对于整个平台来说，是作为独立的基础服务系统存在的，所以会有自身的独立账号体系，而业务平台业务需要，平台业务的passport系统账号，可以和支付系统账号绑定。另外，客户账号ID，可以看作是主账号。

客户实体-客户账号关系：是1:N的关系。

客户帐户：是客户账号下的资金账户，可以是有多个账户。特别注意的是，要事先约定好账户ID的规则。比如头三位用来表示账户类型，后几位用来表示账户编号等。务必保证根据账号号能够快速确定账户类型，并且保证账户号是不重复的。

客户账号-客户账户关系：是1:N的关系。

在支付账户体系中，以客户为唯一要素，关联不同的账户。 客户有唯一的用户 ID，余额账户、理财账户，每个账户有各自的账户 ID。一个用户 ID 关联多个账户 ID。

支付账户体系内的所有涉及客户的资金，本质上是属于客户，而不属于开发账户体系的互联网公司。第三方支付机构的账户系统设计和账户真实资金的管理，要求每一种账户体系，支付机构都会在银行开设一个备付金账户，由银行来管理备付金账户的资金。备付金账户的资金是这个账户体系的全部资金，账户体系内每个实体（如：收款商户、充值用户）所对应的资金金额，由第三方支付机构内部系统进行记录和管理。

4.4.3 设置

用户对账户的设置

• 资金密码（用于提现和支付）
• 申请注销账户

平台对账户的设置

• 是否允许充值；
• 是否允许提现；
• 是否允许透支；
• 是否激活；
• 是否注销；

4.4.4 绑卡签约

为什么要求用户绑卡？这和快捷支付有关。

快捷支付指用户在电商网站上执行支付时，不需要输入卡信息，仅根据短信或者其他的验证方式确认身份后，就可以执行扣款的支付方式。 这是目前电商网站采用的主要支付方式。 在快捷支付中，用户首次支付，需要提供卡的信息，之后就可以凭短信验证码，甚至不需要密码，也可以执行扣款。

接口概述

一般来说，快捷支付需要提供如下接口：

1. 签约， 也叫“绑卡签约”、“开通交易”等，指用户在商户网站上开通快捷支付的功能，他需要将银行卡相关信息提供给电商。
2. 解约， 也叫“解绑卡”， 指用户取消在该网站上的快捷支付功能。一般也会删除该用户在该网站上的相关的银行卡信息。
3. 扣款， 也叫“支付”， 指用户使用签约的卡来执行一笔扣款。
4. 退款， 针对已经扣款成功的交易执行退款操作，一般同时也会把用户权益或者对应的订单撤销。并不是所有订单都可以执行退款。
5. 查单, 查询某次交易的处理状态。
6. 签约查询， 即检查某个用户是否已经开通了签约功能。

我们以支付宝绑卡为例，一般支付机构对用户进行实名后，用户只能绑定自己的银行卡，这主要从安全角度考虑。

1 .输入卡号

用户输入卡号，系统对卡号进行初步验证。验证是基于卡bin和LUHN算法。当然，有些系统提供了OCR功能，即可通过扫描方式获取卡号信息。一般来说，你可以通过卡bin知道哪个银行，因为每个银行都有自己的卡号规则，你可以通过这些规则知道是哪个银行

2 获得银行卡信息

第一次绑定需要卡的信息。借记卡需要卡号，用户的真实姓名和身份证，所有的都是一样的。信用卡是复杂的。一些渠道验证信用卡还需要提供CV码和信用卡有效期。

3 .验证预留手机号

这里有一个四要素验证的概念。由于实名制，所有银行卡都是实名，银行可以核实姓名、身份证号码、银行卡号码和电话号码。如果验证通过，就会发一条短信到你的手机。
注意：

1. 关于预留手机号。我们都知道，银行预留的手机号码通常都是办卡时候留的。几年后，许多人换了手机号，忘记了去银行更改手机号。因此，许多银行就不验证电话号码。
2. 关于短信验证码，电话号码有时候都是不必要的，短信可能就不会发送。那么银行不发，支付机构就可以自己发；
3. 重复绑卡问题。如果系统支持多个帐户，那么一个人必然会被绑定到多个帐户。有些渠道支持重复绑卡，有些渠道不支持；

4 进行绑定
用户输入短信验证码并确认绑卡。支付机构就会将用户的银行卡信息和短信验证码组合发送给银行进行签约操作。在银行成功签约后，它将把签约号码返还给商户。这种处理逻辑是在支付渠道方面引入的。银行将返回以下结果:

1. 签约成功：这意味着可以建立签约关系。下次就可通过签约号来进行扣款操作。
2. 重复签约：按照业务考虑是否支持重复签约。 一般针对一个银行卡仅保留一个签约关系。
3. 签约失败：会提示具体失败原因。

4.5 充值

以用户在第三方支付平台（支付宝）用银行卡给自己虚拟账户在线充值为例，为简化流程，均以最理想情况进行说明：

1. 用户在第三方支付平台执行充值操作。
2. 平台根据用户充值指令，跳转到银行网关进行支付。
3. 用户支付成功后，银行会实时从用户的银行账户上执行扣款操作（资金转移到第三方支付平台在银行的存管账户）。
4. 银行网关通知支付平台用户支付成功（成功扣款）。
5. 支付平台在自己账户体系中给对应用户虚拟账户增加对应资金。
6. 平台通知用户充值成功。

银行和支付平台然后按照约定的结算周期（例如T+1）进行对账、清结算等操作，将用户充值的资金结算给支付平台在银行设立的账户（备付金账户，平台在银行开设一个实体对公账户）。

以上只是简化的充值流程，其中在第三步一般银行只扣划用户款项，待到日终才会将款项划转到支付宝备付金账户，第五步一般也不会增加支付宝备付金账户，而是先通过中间账户，如充值待清算账户，等到日终银行头寸和对账文件下发时，通过对账逻辑进行处理，若涉及到异常流程，会更复杂些。

从简化的流程图里还是可以看出支付平台只处理虚拟资金，实资金仍在银行体系内。

从账户关系也可以看出，实资金变动从个人银行卡划转到了支付平台的银行账户，虚资金是支付平台为每个注册用户建立的虚拟账户，与用户的银行卡可以说没有直接关系；说的再直白些，用户充值的款项都划转到支付平台在银行开立的大账户，业务主体为“某支付平台”，然后支付平台在系统内为每个用户建立台账。

上面的充值，如果绑定了银行卡，充值会很方便。为什么要求用户绑卡？这和快捷支付有关。绑卡是将用户卡信息提供给电商，以后电商就用这个信息去银行完成支付。绑卡实际上是一个授权，让用户允许商家自动从他的账户上扣除资金。所以绑卡也叫签约，用户和银行，商家的三方签订的支付合约。

4.6 使用E-Wallet支付

当开户及充值完成后，接下来就是使用E-Wallet作为支付渠道了支付了。

Ok, 下面是一个常见的电子钱包支付流程。

作为支付系统，这个过程一共分两步：收单和支付。

4.6.1 收单

用户在业务平台上提交支付订单后，支付系统收到用户的订单支付请求并验证请求后，并记录下来。

通常情况下，根据用户使用的终端是h5还是app应用，支付系统会返回二维码或者deeplink连接。

不过如果是内部钱包支付，收单和支付可以同时进行，但是为了以后的扩展性，流程和结构还是要分两步。

具体参见上面的“统一收单”表。

4.6.2 支付

这里需要同步和异步处理收单表里的订单，处理完之后需要事务写入支付记录和账户账单流水。

这里以支付宝的支付流程为例说一下：

整个支付流程就是这五大块之间的交互，具体的实现上图也给的很清晰了，下面对图中重要的步骤简单的介绍：

• 添加购物车，生成待支付订单，产生唯一订单号
• 请求商户服务端（自己的后台），在后台对订单信息进行签名操作，这里应用为了安全考虑，会把似钥放在服务端，客户端只要报订单号传给服务端，具体签名在后台进行。
• 服务端把签名好的订单信息返回给客户端
• 调用支付接口，把签名好的订单信息，通过调用支付宝API，发送给支付宝客户端SDK
• 支付宝客户端发起向支付宝服务端发起支付请求
• 支付宝客户端输入支付密码。完成支付
• 返回同步结果给支付宝客户端
• 支付宝客户端将接口返回支付结果给我们的商户端口，9000支付成功
• 同时也将支付结果发送给了商户服务端。验签，解析支付结果。将客户端与服务端的支付信息进行比对，确保订单支付正确无误
• 确认订单无误之后，返回最终支付结果给商户端
• 客户端将订单支付完成信息在界面显示，告知用户支付完成

4.7 API 列表

既然支付账户已经开通，那么作为一种支付渠道，自然可以用于各种场景的消费。作为支付渠道，就需要提供相应的SDK，用于消费场景的支付流程开发。

此列表包含支付平台电子钱包系统所涉及的几乎所有接口，参考支付宝：

接口英文名	接口中文名
alipay.trade.page.pay	统一收单下单并支付页面接口
alipay.trade.refund	统一收单交易退款接口
alipay.trade.fastpay.refund.query	统一收单交易退款查询接口
alipay.trade.query	统一收单线下交易查询接口
alipay.trade.close	统一收单交易关闭接口
alipay.data.dataservice.bill.downloadurl.query	查询对账单下载地址

参考

https://zhuanlan.zhihu.com/p/58624171

http://doc.cocolian.cn/essay/account/2017/02/03/clearing-account/

https://zhuanlan.zhihu.com/p/31198490

https://zhuanlan.zhihu.com/p/55592943

https://juejin.im/post/5c2345c0518825235a0554bb

https://zhuanlan.zhihu.com/p/33897440

https://kuaibao.qq.com/s/20181026G0D0WV00?refer=spider

https://www.banana.ch/doc/zh-hans/node/3826