一、背景

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

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

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

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

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

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

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

二、支付系统2.1 什么是支付系统

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

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

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

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

2.2 主流支付系统整体架构

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

支付宝

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

京东金融

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

去哪儿

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

美团

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

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

参考架构

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

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

支撑层：用来支持核心系统的基础软件包和基础设施， 包括运维监控系统、日志分析系统等。

核心层：支付系统的核心模块，内部又分为两个部分： 支付核心模块以及支付服务模块。

产品层：通过核心层提供的服务组合起来，对最终用户、商户、运营管理人员提供的系统。

支付基础设施

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

运维监控：支付系统在下运行过程中不可避免的会受到各种内部和外部的干扰，光纤被挖断、黑客攻击、数据库被误删、上线系统中有bug等等，运维人员必须在第一时间内对这些意外事件作出响应，又不能够一天24小时盯着。这就需要一个运维监控系统来协助完成。

日志分析：日志是支付系统统计分析、运维监控的重要依据。公司需要提供基础设施来支持日志统一收集和分析。

短信平台：短信在支付系统中有重要作用： 身份验证、安全登录、找回密码、以及报警监控，都需要短信的支持。

安全机制：安全是支付的生命线。 SSL、证书系统、防刷接口等，都是支付的必要设施。

统计报表：支付数据的可视化展示，是公司进行决策的基础。

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

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

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

应用管理:同时支持公司多个业务系统对接。

商户管理:支持商户入驻，商户需要向平台方提供相关的资料备案。

渠道管理:支持微信、支付宝、银联、京东支付等多种渠道。

账户管理:渠道账户管理，支持共享账户（个人商户）及自有账户。

支付交易:生成预支付订单、提供退款服务。

对账管理:实现支付系统的交易数据与第三方支付渠道交易明细的自动核对（通常T+1），确保交易数据的准确性和一致性。

清算管理:计算收款交易中商户的应收与支付系统收益。

结算管理:根据清算结果，将资金划拨至商户对应的资金帐户中。

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

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

三、账户体系

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

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

3.1 资产类账户

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

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

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

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

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

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

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

3.3 所有者权益类账户

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

3.4 损益类账户

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

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

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

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

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

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

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

3.6 共同类账户

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

3.7 账户体系

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

四、支付账户4.1 什么是支付账户？

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

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

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

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

4.2 三户模型

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

三户体系架构

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

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

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

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

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

4.3 支付账户设计

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

4.3.1 支付平台

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

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

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

4.3.2 开户

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

个人账户：是面向个人用户开设的电子账户。

企业账户：是面向企业、机构等开设的账户。

内部账户：是平台为自身业务开展的需求而为自己设立的账户。

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

用户账户的基本信息用户ID账户号：特别注意的是，要事先约定好账户ID的规则。比如头三位用来表示账户类型，后几位用来表示账户编号等。务必保证根据账号号能够快速确定账户类型，并且保证账户号是不重复的。账户名称主账户：客户类型：个人、企业、内部账户类型：余额账户、理财账户、信用账户账户总金额：账户可用金额：等于总金额减去冻结金额账户冻结金额：包括交易冻结和风控冻结币种会记科目账户状态：待实名、正常、已冻结、已停用、已销户开户时间用户的身份认证信息个人身份证号身份证正反面照片手机号邮箱企业营业执照法人身份证号身份证正反面照片联系电话邮箱

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

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

4.3.3 设置

用户对账户的设置

设置提现密码申请注销账户

平台对账户的设置

是否允许充值；是否允许提现；是否允许透支；是否激活；是否注销；4.3.4 绑卡签约

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

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

接口概述

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

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

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

1 .输入卡号

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

2 获得银行卡信息

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

3 .验证预留手机号

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

注意：

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

4 进行绑定

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

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

总的来说，账户的结构如下图所示，包括基本信息、关联实体、权限控制、余额和账务相关信息。

五、交易

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

电子钱包账户交易包括很多种操作，如：支付（消费、充值、转账）、查询、转账、退款、关闭、对账、提现等，每一种类型至少提供一个接口。

5.1 API 列表

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

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

5.2 充值

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

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

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

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

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

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

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

5.3 支付

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

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

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