聚合支付账户系统
随着聚合支付业务和技术的不断发展，为了更好地满足用户体验和资金处理原则，账户系统应运而生，现对一种聚合支付的账户系统进行介绍，以便相关人员能够对聚合支付的账户系统有一个清晰、直观的认识。
一、为什么建立账户系统（Why）
1.更精准的满足商户的退款需求
问题：商户A、商户B今天分别通过聚合支付平台支付了100元用于购买T恤，那么支付机构今天的账户余额有200元，而商户C今天并没有产生支付的交易，却发起了一笔100元的退款交易，因为支付机构账号余额充足，所以该笔退款成功，但其实该笔退款交易所退的钱为今天商户A和商户B的收益。
解决：为每个商户建立特定的账户，用于记录各自的资金情况，例如为商户A、商户B、商户C各自建立一个虚拟账户，因为商户C今天没有产生支付的收益，所以该笔退款请求（雷电符号）不会被立即处理或被拒绝处理，即上述退款所产生的问题不会出现，具体流程见下图。
2.合法资金清分的迫切需求，避免非法二清
科普：“二清”是相对“一清”而言。“一清”一般指资金直接通过银行或者获得支付牌照的第三方支付公司进行清算，交易结算款直接划转给商户。而“二清”是资金需要进行两次清算，即结算资金由银行或者第三方支付机构先转至“二清”公司自己开设的账户，经由该公司处理后，再结算给商户。简单地说，“二清”公司并不持有支付牌照，未获得央行支付业务的授权，却在持牌收单机构下实际从事收单业务，属于违规行为，其结果可能会造成平台“资金池”模式，进而产生“跑路”风险隐患。对于接入商户而言，“二清”公司可以通过违规手段做低商户收单成本，这对于很多商户尤其是正规手续费比较高的行业商户极具诱惑力。
问题：现阶段聚合支付之所以可以进行资金的清分是因为所有的资金都来同一企业，相当于企业内部进行了资金的流转，不涉及外部的企业。但是如果企业的二级单位有一些二级渠道，如房屋中介公司广东分公司下的二级商户以该企业名义承接了一部分租房中介的业务（代理分销），资金的流转通过聚合支付平台，那么该聚合支付平台就存在二清的风险，间接的会对广东分公司下的二级商户的资金造成威胁。
解决：大家都知道聚合支付平台一般都不持有支付牌照，所以可以选择与有支付牌照的机构对资金进行监管，如第三方支付机构或银行，经了解银行对聚合支付平台的资金监管采用的也是“账户”的理念，在一个实体银行账户下建立不同的虚拟账号来对资金进行合法的清分。由于银行资金清分的信息流都来源于聚合支付平台，所以建立聚合支付的账户系统迫在眉睫，这样既可以与银行进行无缝对接，也可以对银行清分的资金情况进行自稽核。
3.适应聚合业务的扩展性
优势：随着支付业务的快速发展，聚合支付的账户系统能够在一定程度上对支付业务的拓展起到帮助，现阶段聚合支付更多的是具备稳定、多样的支付能力，但是从个性化营销的角度来看，还存在很大的发展空间，如配合商户进行支付返现、赠送红包、赠送优惠券、评论打赏等营销活动，如果有了合理的账户系统这一系列的问题都会迎刃而解。
做法：就拿支付赠送优惠券来说，比如一家煎饼果子店推出了买煎饼果子赠送优惠券的营销活动，用户每支付20元就会赠送3元优惠券，优惠券共发放2000元，那我们可以在账户系统中为该煎饼果子店开设一个用于优惠券发放的虚拟账户，账户的余额为2000元，通过配置一定的业务规则实现支付过程中优惠券的发放。
二、账户系统如何建立（How）
1.规则引擎的建模与实现
引言：在聚合支付的账户系统中往往都有这样一个需求，我们会根据不同的业务指标来决定将交易记录到哪些账户（或账本）上，比如两个商户加盟了同一家煎饼果子店，商户分别坐落于北京市和天津市，那商户的每笔交易我们可能会根据他们省份的不同、支付方式的不同、销售产品的类型不同，记录到一个或多个账户中。类似于这种业务场景复杂，业务规则经常变化，还要求能够支持快速修改规则、快速匹配、即时生效的场景比比皆是，那面对这一问题我们有一种解决方案就是会采用“规则引擎”来解决此类问题，下面我通过一个例子来为大家介绍一下为什么要使用规则引擎。
问题：马上就快到端午节了，很多小伙伴会选择出行游玩儿，这时候大家会面临如何选择出行方式，大家会根据天气、预算、人数、交通等情况来选择出行方式，听起来很简单，现在我们来为选择出行方式写一段代码。
这四条规则的if嵌套就让人看着很头疼，而且随着不同业务指标的更改，更多的组合方式会让程序员写到崩溃，而且规则的制定者随着时间的推移看着这一段段代码也会忘记最开始制定的规则，更重要的是每增加这样的规则就要同步修改代码，还要安排开发的周期，大大的浪费了时间，但如果在这类问题上使用规则引擎就会有带来以下几个优点：
1）业务代码与决策代码分离
有了规则引擎，业务代码会与决策代码分离，在业务代码中您只需要安心的实现业务功能，将待决策的业务指标交给规则引擎，它自会告诉你最终的答案。
2）规则易懂、随时修改、随时生效
有了规则引擎，相关人员只需要配置业务规则即可，其他的都由规则引擎来自动化的处理分析，而且这种业务规则通俗易懂、便于理解，且修改了规则以后，可以随时生效，在上述的例子中业务人员可以将规则配置成类似于如下的这种形式。
distance<50000&bike=true&weacher=sunny -> bike
distance<50000&car=true&money>2000 -> car
3）规则匹配效率高
规则引擎的一般做法都是将规则引擎需要的匹配规则库和事实库加载到内存中，然后使用RETE快速匹配算法进行决策与匹配，这样存储方式和匹配算法在一定程度上提高了决策的效率。
科普：之前找了很多规则引擎的相关知识本来想给大家进行科普，但是后来发现描述的都比较抽象，还不如用浅显的语言来描述更让大家好理解。规则引擎在我看来分为三个部分，一个是规则的定义，一个是规则的加载，一个规则的判断。
1）规则的定义是通过一种特定的语言（如DSL）来对规则进行描述；
2）规则的加载是根据定义好的规则生成推理网络；
3）规则的匹配是将待匹配的数据经过推理网络得到最终结果。
总而言之，规则引擎的作用就是面对复杂、多变、繁多的业务规则得出业务结论的一个过程。
例子：
1）规则定义：
merid[0001]&paymentname[支付宝]&paytype[网店]=aid[101]
merid[0002]&paymentname[支付宝]&paytype[网店]=aid[102]
2）推理网络：根据不同的规则的生成推理网络，待匹配数据进入到推理网络后会根据快速规则匹配算法进行匹配，推理网络示意图如下图。
应用：规则引擎的快速匹配算法大多数都使用RETE算法，现阶段使用率较高的规则引擎为开源的Drools，聚合支付的规则引擎主要是用于通过一些业务规则数据得到对应的账户，而每个业务属性之间的关系也都为且，业务匹配规则也不是特别复杂，所以如果使用Drools会显得有一些“笨重”，结合这种特定的业务场景，应用RETE算法，我们自己开发了一个轻量级的规则引擎（规则引擎的具体设计过程与开发细节后续可以再给大家介绍）。经过实际的测试，350条业务规则构建的推理网络用时大约为90ms，4个线程，每个线程匹配200万次，每次匹配的平均耗时为0.107ms。
2.账户体系的设计
设计:聚合支付账户系统的设计主要来源于财务上账户的概念，基本上可以满足现阶段支付业务的所有需求，且具有一定的扩展性，账户体系的设计如下图，现对其中的重点（已经使用）部分做一下介绍，以便大家理解。
1）业务交易与类型：业务交易可以理解为聚合支付系统中的订单，每个业务交易都对应一种交易类型，交易类型分为支付和退款；
2）单据与凭证：在账户系统中每一个单据都对应一个业务交易，一个单据可能包含多个凭证。如有分润的业务场景，一笔收入100元的支付单据可能对应收入98元和收入2元的两条凭证；
3）账户余额与明细：账户下分为账户的明细与账户的余额，每一个凭证都对应一条账户明细，用于记录该账户的资金流水，账户的余额用于记录账户的总体资金情况，分为总额约、可用余额、冻结余额。
例子:煎饼果子店的一笔支付订单，支付金额为10元，要按照9比1的分润比例，将90%的收益归于该煎饼果子店，10%的收益归属该煎饼果子的加盟总公司，按照上述的账户体系，数据的关系如下图。
三、总结
本文从“为什么构建账户系统”和“如何构建账户系统”对聚合支付的账户系统进行了简单的介绍，总体看来构建一个账户系统虽然不是很容易，但的确会对支付业务的发展产生了一定帮助。
