钱包系统是用来管理余额的进出、记录余额变化的虚拟账户，钱包系统内发生的余额变动并不一定有对应的资金流。
钱包记录了单个账户的资金变动情况，资金的变动主要分为两种，即进项（充值、退款等）和出项（扣费、转账转出等)，下面主要介绍几种常见的交易类型：充值（打款）、支付、退款和提现。
（1）现金的充值方式
线上充值：支付宝/微信/网银转账，以及第三方支付渠道。
线下充值：对公汇款。公司的银行账户收到客户的打款后，业务系统通过银企直联，获取打款金额和相关信息，生成一笔银行充值记录，再匹配相关信息，比如公司名称、用户id、历史分配记录等，将该流水分配到正确的UID上，在账户内生成一笔充值流水。
没有银企直联的情况下，也可以由财务人工将收到的流水录入业务系统，再在业务系统完成流水分配和认领工作。
现在还有一种解决分配银行流水的做法，就是开设银行父子账户。简单说，就是企业向银行申请能够开设多个账户的服务，然后企业再将账户分配给自己的客户，一个客户分配一个专属的银行账户，客户打款到专属的银行账户内，银行再转账到企业的银行卡内，完美解决款是谁打的问题。
（2）虚拟货币的充值
虚拟货币一般是作为客情赠送或返利赠送给客户的，由商务在业务系统发起充值流程。
（3）充值的消耗
充值进入钱包后，会记录为一笔充值流水（实收款项），充值流水会按发生顺序支付账户内的未付清的扣费流水（即应收款项），付清的过程就是预收对冲应收。
充值流水上，需要记录充值金额、已支付金额、剩余金额、充值时间、充值方式和外部交易号等信息，充值流水下还需要记录每一笔消耗情况，包括发生时间、消耗金额、所付清的扣费流水、充值余额等，来表明充值金额的具体流向。充值流水下消耗记录与扣费流水的执行记录应该是1：1对应的。
（4）充值的会计处理
充值流水是公司的实收金额，但在财务收入确认上实收没有意义。充值流水中，未消耗的充值和已消耗但是未提供商品/服务的账款按预收账款处理，记为负债类科目。这代表以后需要用商品服务来偿还的。后续实际提供商品/服务后，预收账款转为业务收入，相关会计处理如下。
收到预收账款时：
借：银行存款
贷：预收账款
实际提供商品/服务时：
借：预收账款
贷：主营业务收入
余额扣费
（1）扣费流水（应收金额）
前面说到对账单其实是多条计费明细的汇总，那么账单执行扣费后，这每条的计费明细会产生一条扣费流水（应收金额），流水会详细记录交易类型、交易细分、发生金额、待完成金额、是否完成、发生时间、关联交易和描述等。
（2）扣费核销（实收金额）
扣费流水被实际支付后，扣费流水下会记录执行流水，即实收金额，一笔扣费流水可以对应一笔或多笔执行流水，执行流水上会记录支付币种、执行前后的金额、变更金额、支付时间等。
一般而言，账户余额会按照扣费发生的先后顺序来付清扣费流水。某些业务场景下，也可以让用户指定支付的账单，而不是按先后顺序付清。
TO C的业务更喜欢说支付，因为基本都是是用户主动付清账单，而云行业主要是后付费的计费模式，需要用户在账户内预留资金，生成账单后系统会主动付清账单，其实区别在于行为的主体是人还是系统。
（3）扣费流水的细分
扣费类型其实是反映资金出项的一级分类，还需要根据业务类型和交易场景来细分和定义细分类型，以便后续区分交易场景入账。下文提到的提现也是扣费流水的细分类型之一。
（4）扣费的会计处理
扣费流水其实并不等同于会计上的应收金额，但业务环境中，大家一般会理解成只要交易发生，那么商品服务费用都是应收金额。差别就在于财务收入确认采用权责发生制（又称应收应付制），与之相对的是收付实现制。
权责发生制：只要交易发生且商品服务已交付，不管是否收到款或未收款，都应该计入收入。
收付实现制：以实际收款付款的时间确认收入和费用，而不是以商品服务提供的时间。
具体要看，商品服务是否已经提供给了客户，已经提供商品服务却没收到账款的按应收账款处理，计入资产类科目。
已提供商品服务但未收到打款：
借：应收账款
贷：主营业务收入
收到打款：
借：银行存款
贷：预收账款
退款/账单调整
退款其实是扣费的逆向流程，发生在用户需要退货或账单调整的情况下。
退款时，需要判断扣费流水（即应付金额）的实付情况，将实付资金退回至对应的充值流水下钱包，同时将商品状态改为已退款。
账单调整，通常需要用新的计价规则计费结算，因此需要对原账单退款、并生成新的账单&执行扣费。
需要注意的是，如果扣费流水没有执行完就发起退款，那么未支付完的差额需要被冲销，不然这个差额仍需要用户支付。
冲销的方式有多种，可以单独生成一笔充值，专门支付差额，也可以做正负向流水冲销差额。
提现
前面说到退款是扣费的逆向流程，其实提现也是充值的逆向流程，将用户充值的钱退回给用户。
（1）提现退回的方式
原路退回：哪儿来的退哪儿去。根据充值流水的支付渠道，发起退款，一般第三方支付系统都会支持原路退回，但是仅支持退近3个月的充值流水，超过就需要走线下提现。
线下退回：需要用户填写或绑定收款银行账户，或是支付宝账号（这里需要做好风控，判断账户主体和持卡人一致），由财务打款至客户的银行账户上。
（2）提现的处理
首先，要校验提现金额是否超过可提现金额。其次，不管是哪种退回，在账户内都会发生一笔提现类型的扣费流水，并由申请提现的充值流水专门支付。付清后，资金系统再通过支付渠道发起退款/打款流程，注意顺序要先扣后出。
可用余额
可用余额是将各类可用资金和额度汇总计算得出的可使用金额的总和。
可用余额=现金余额+赠送金+信用额度-未支付金额-冻结金额
需要注意的是：
抵用券并不会列入计算。因为抵用券通常是有使用限制，并不能抵扣全部产品，不能作为类现金的通用货币。
冻结金额。
冻结金额是用来锁定用户的一部分余额，避免用户花费后账户欠费。应用场景包括申请中的提现金额、预估消费等等。
一般有两种实现方式，根据是否计入流水分为：
1）计入流水。新增冻结类型的扣费流水和解冻类型的充值流水，冻结类型需要指定扣费/锁定的资金类型和占用顺序。解冻流水即为冻结流水的逆向处理。
2）不计入流水。将冻结金额作为负值计入可用余额的计算，流水上不做区分，解冻时只要将冻结金额调整为0即可。麻烦的是，由于未真正抵扣，因此需要明确冻结占用的资金类型和数量。不然用户分不清其他资金的实际可用额度。
（3）信用额度
我们这里的信用额度代表的是一个欠费额度，即允许客户赊销/欠费的最大额度，区别于信用卡的授信额度是一种支付工具。通常应用于有账期的客户上，用信用额度来判断用户的是否应该还款，以及是否要进入欠费管控流程。
信用额度是要设计成额度还是支付工具，大家可以衡量下业务需要。设计成额度会更简单点，如果设计成支付工具，那么作为一类资产，还需要考虑它的进销存，以及抵扣顺序和退款逻辑等。
结尾
除了上述提到的充值、扣费、提现、退款，其实还有很多其他业务场景和流水类型。
总结一下，在设计钱包时需要注意：
考虑钱包内的资金种类和使用规则，并设置相应的子账户、做好进销存，比如现金账户、赠送金账户等。
考虑各种场景的逆向流程，并留好审计日志。由于钱包系统涉及到钱需要非常谨慎，如果弄错需要考虑好逆向流程，并保留回退记录。
根据交易类型和场景，细分好进出项类型。
