一、专题分享
1.1 关于积分子账户
感谢各位老师支持，今天要讲的主题是积分子账户，是基于账务系统进行拓展的积分子账户的记账系统，主要用于营销和会员管理。
账务系统之前秋秋老师讲的比较多，账务系统主要区分为对私和对公账户2种，分别对应C端客户和B端客户，而C端客户以身份证号维度区分每个自然人，每个自然人因为其不同的业务性质可以分为余额账户、理财账户、积分账户、点卡账户、游戏币账户等等。
围绕这个自然人为属性，拓展各种业务类型的子账户，即能够增加业务的灵活性，有能够围绕这个自然人提供全方位的服务。
今天重点要讲的是积分子账户，众所周知，积分目前广义来说是有2个重要一个，会员等级和消费返利。
1.2 会员等级
先说会员等级吧，举个简单的例子，支付宝黄金、白金、铂金会员。这个就像升级打怪一样，利用大家的虚荣的心理，让更多的人使用产品内的服务，增加积分，形成正向激励。
1.3 消费返利
其次再说消费返利，目前主要的就是京东的消费返回京豆，其类似于一个预付卡性质，能够进行消费抵扣和优惠券购买，促进用户的多次消费。
1.4 业务场景
积分的业务场景使用很多，不一定拘泥于此，进一步拓展，例如理发店的理发卡（次数）、健身卡（分级次数）、医疗卡（次数+金额）等等，可以通过积分灵活多变的性质来开展各类不同的业务场景需要进行计量的需要。
1.5 积分账户设计
接下去就要说如何去设计这个积分账户。
综上，积分账户首先存在与等值人民币的兑换比例多变，因业务需要的不对积分类型设置不同的兑换比例，例如京豆1:100，美发豆1:1000、健身豆1:10000。
因此在设计上需要采用类似外币兑换的方式，允许开展灵活多变的积分比例配置，通过这个积分比例的配置，实现人民币与积分的灵活切换，便于后续的清结算的资金处理。
其次积分账户需要关心的是有效期，这里的有效期又可以细分为活动有效期和个人积分累计有效期，活动有效期顾名思义指的是具体某一个单一活动的有效期，例如消费双倍送积分，赠送积分仅在6-30使用有效，这个有效期就必须以这个活动节点作为控制阀门；同时也有类似京豆等，自积分发放至个人账户之日起的180内有效，这样个人积分账户就会随着时间的推移逐步减少，提醒用户尽快使用。
因此在积分有效期的设计上2种情况都需要考虑，通过逻辑的变化互换有效期的判断以谁为准。
最后积分很重要的一点，就是积分消费组合性质。
当产品推出积分作为营销手段时，往往会组合上人民币+积分+优惠券+会员等级折扣这样的四重组合。
因此在这积分消费设计的时候需要考虑积分消费与其他消费类型的组合联动，例如订单退货，则需要联动退回积分，优惠券同时需要重新更新会原积分消费时候的有效期日期。
同时积分消费时，需要考虑积分消费的具体积分类型，积分类型间可以进行不同的转化，例如浦发银行卡积分可以转化为京豆，再使用京豆进行消费抵扣，其中需要通过过渡子账户将浦发银行卡积分记录并转化为京东积分，并在后续的清结算流程中在对账单中进行体现，确认应收应付，实现内外部积分相互转化，提高用户对产品的集中使用。
今天分享的内容就这些，关于前端积分发放规则的设计可以千变万化，这里就不做具体展开，下午也对DROOLS工具做了具体讨论，通过该工具可以实现前端例如消费满1000送10000积分等等多种规则的组合，满足前端多种营销的诉求。
二、在线问答
Q：积分用哪个科目核算？
A：一般就是积分科目，人民币科目借贷调整到积分科目，可以类似看做外币兑换分录
Q：归到哪个总账？
A：都是归属到一个支付账户总账；积分当做一个有价科目。一般有2种设计：一种是把积分当做负债，负债科目转换；还有一种是先有钱，购买积分的会计设计。目前普遍还是以负债科目设计为主。
Q：如果作为负债，资产表怎么平衡？
A：应付和实付，一般做计提
Q：对于区块链做积分互换，有什么建议吗？
A：风控产品经理刚才也提到了，需要考虑多重积分比例，通过不同子账户下转化。
Q：从财务上看，银行等积分发型主题希望被用掉还是不被用掉？
A：当然是被用掉啦~否则积分的营销的意义就很小了，积分可以看作是激励补偿，用户才会愿意获得更多的积分。
Q：积分和资金如何对接清分结算的？
A：把积分转换当做外币和人民币的转换~通过积分类型实现设计好的积分兑换比例，等价转换为人民币。
Q：需要把钱提前充到对应的现金账户吗？
A：刚才提到了，有2种，不充钱的就是负债模式，作为应付科目，最终兑换了才是实付；而充钱的就是类似预付卡，将钱买入积分的性质
Q：区块链还做积分意义何在，直接发币不就好了？
A：区块链做积分清洁算呀，可以交易积分；可以做个各种积分的交易平台，中央清洁算
Q：区块链做积分互换？中央清结算，我问问有啥优势？说实话我没看明白
三、话题整理
3.1 分布式事务一致性
Q：请问一个比较经典的分布式事务问题，比如A出账100元，B入账100元，如何保证一致，一般银行或支付宝什么解决方案，2PC, tcc,事务消息？还是其他解决方案？他们优缺点？适用场景是什么？谢谢
A1：不用分布式事务啊，现在微信、支付宝都分2阶段做的，你看微信转账，还要点一下收钱呢，把这一步做成程序一步处理就好了。
A2：异步处理，网上有支付宝架构图的，一搜一大把
A3：不需要分布式事务，分成两部，两种方案 先冻结，冻结成功可以保证转账可继续成功，第二部就可以慢慢做了。还有一种方案走中间户，a到中间户在一个本地事物，中间户到b在一个本地事物。
- 你这种是不是tcc了？
- 不是tcc 分成两部来做，可能有个疑问，第一部成功如何保证第二部，可以使用补偿 事物型消息等，tcc 的话就把两部放在一个分布式事物中了，同生同死，这种可以只要第一部成功，第二部就不急了
- 请问你的意思是出账先保证成功，入账再慢慢弄？如果入账失败是通过补偿处理，如果补偿死活失败，通过人工处理？
- 是的，补偿死活失败一般有bug吧，概率很低；tcc 模式业务入侵较大，有一定理解维护成本；
A4：2阶段处理得有核对机制
-
如果采用异步的话，可能会导致如果入账无法成功的话，是采用人工处理？
- 加钱入帐不成功几率很低的，可以重试几次，还不行那肯定某些服务有问题了。服务可用性问题，影响不是这一点点了。分2阶段还有个问题，比如B账户止入会导致入帐不了，这个可以通知人工处理，或者自动做反向入A账户的。A B都止入只能人工先处理了，当然这种情况少。当然通常来说不会单独止入。
- tcc 2阶段没有这个问题，同生同死，直接回滚了。 两步走会有这个概率
3.2 收单费率和分润
Q：线下收单费率改成千六之后，分润还是按照721比例吗？
A：待回应
3.3 快接通、畅捷和用友
Q：快接通是啥？
A1：第三方支付公司。有互联网支付、基金支付牌照，海尔13年收购，还是有远见的，现在牌照炒的…
- 今年很多人和我说快捷通的销售很爽，反正没几个人，业绩指标也不大，还打打价格战什么的，说是个好坑
- 恩，开始推外部业务，之前主要集团内部
A2：听说畅捷支付也不错，也是适合销售
- 畅捷支付有你说那么好吗 哈哈
- 畅捷？也是个坑吧。。
- 虽然畅捷通号称是用友旗下唯一一家自己做不了自己的业务系统的公司，创造了一个奇迹，别的方面，绝对杠杠的！
- 畅捷和用友是两回事，除了内部网络还在一起，业务基本没关系
3.4 e收和升润支付
Q：有了解信e收吗和上海这家升润支付的吗
A：待回应
3.5 最新联行表
Q：群友们有最新联行号表吗，求表一份~！
A：待回应
3.6 乐富全国收单牌不续期
Q：群里面有没有人知道乐富的全国收单牌照是确定不给续期了吗？
A1：央行一般不开玩笑，乐富这次玩大了
A2：以后乐富的高管怎么在这个圈混，牌照玩没了
A3：看昨天央行的通报，看样子是得罪人了
A4：这可是全国收单牌呀，非常值钱的
Q：乐富被人趁火打劫买了？有大神知道消息嘛？
A：待回应
3.7 兴业通道调整
Q：各位机构有没有收到兴业的通道调整消息啊
A：待回应
3.8 规则引擎框架
Q：哪位朋友推荐一个比较好的规则引擎框架？谢谢
A1：drools
A2：JLisa
- 你们在用这个吗？
- 木有
A3：一般都用 drools~ 挺方便的~ 淘宝有一款轻量级的 阿里云QLExpress
A4：这里面分析了常用的几种方式的优缺点从0到1：构建强大且易用的规则引擎
A5：drools正准备想用，真有文章里说的那么不友好么……
A6：我上次问了同样问题，现在刚整合。感觉挺好用，没有那么不友好。有时间再写个解析就更友好点。
A7：把执行器部分隔离出来，有问题无缝切换
A8：规则引擎 最难的不是执行层而是 抽象上层模型 执行层drools groovy spel 甚至Java都可以搞
- 你说的抽象是业务模型还是规则引擎系统抽象？
- 引擎系统的抽象
- 那叫接盘吧？能否分享一下经验？谢谢
- 大家可以交流讨论，分享谈不上
- ibm以前有个wsad的工具 很强大 可以支持java的语法
3.9 传化支付
Q：传化支付哪位了解？
A1：传化支付是什么背景，能在这种情况下申请牌子成功，而且一次性有互联网支付和预付卡两个类型，牛逼呀
A2：貌似15年就已经审批通过了，只是没有公告。
3.10 同盾
Q：有接同盾的兄弟吗？效果怎样？
A1：我家接了，还有聚信立；直接结论，没有任何过程性，80%爬虫类工具，唯一的就是电商啥的数据来交叉验证和侧面验证。个人信贷，可以直接买个人出行数据和旅游数据，再配合同盾会更好。
- 了解，经营数据一般哪里有卖的？
- 待回应
3.11 国内商业银行内部系统
Q：群里有很多业务前辈与技术大拿，哪位朋友能否介绍一下国内商业银行内部大概都有哪些系统？
A1：银行系统比较多了；总行分行各部门各业务条线都有不同的系统，涉及客户的营业性的，内部监管报送的。
- 例如企业/个人在银行开户，然后开通网银，进行存款，进行转账等一系列操作，银行内部应该有一系列的系统提供服务。
- 开通网银和存取款并无直接关系
- 好比在一个制造型企业视角来看，需要ERP系统，有预测，销售，采购，库存，财务等子系统。
- 普通I类账户开户主要涉及核心 cif 前置/esb这些系统。还会调用联网核查、短信平台等外接服务。涉及到卡 还会有重控管理 柜员尾箱 加密机 密码键盘。
- A2：这问题好大。。我之前在浦发，浦发系统分了几大块，基础平台类，个人业务，公司业务，渠道，中间业务，管理信息系统，每一块都n多系统。
- 只是想了解一下系统名字罢了
- 平台类的有核心系统，ECIF，ESB，影像系统，工作流等，这些基本上各家都有；渠道有网点柜面，网银，手机银行，微信银行，移动业务平台，VTM，支付网关，收单系统，这些基本上各家也都有。对私的有个贷，有发卡，发卡又有芯片卡的加密系统等等配套系统；个贷基本都有，发卡不同行不同做法，不一定独立系统；对公业务比较复杂，会有很多个性化系统，银企直联，银关通，验印，票据等等等等。中间业务主要就基金，理财，国债，三方存管，企业年金这种。管理信息就是内部管理信息系统，还有数据仓库，报表平台。商业银行一般外包，有新业务一般会新做系统，买外包厂商比较成熟的解决方案。比如前几年做网贷，做新渠道，系统太多，我举的这些基本是各家行都有的，比较通用的。
- 对银行而言，无论同业机构，企业，个人信息相对个产品线应该是集中管理的，一般是什么系统承担？
- 客户信息都是在ECIF，为各产品线提供信息服务，基本都是各家咨询公司卖了这家行卖那家行，都差不多。。
A3：确实是个系统性的问题，可能要写一本书 有商业银行系统介绍的书籍可以看看
- 产品同质化严重，系统五花八门
- 外汇 贵金属 保险 现金管理 供应链金融 消费信贷，国际贸易 SWIFT 西联汇款
- 对。。前几年很火的代客外汇、代客贵金属，浦发也是新做系统，区别原有的外汇系统和黄金系统
- 1104 反洗钱
- 各分行还有一大堆分行特色业务，比如为分行大客户建立的某些特殊的系统，缴费 资金存管 银企直连 现在很多重要系统的开发都被收归总行 不然杂七杂八安的系统多了去了。
- 核心系统包括 账户和 交易吗？
- 嗯 包括 但是细节 各家情况不一样 核心和会计系统有的是分开 有的是合在一起
- 信用卡一般是分开的，也有对公系统和个人业务剥离的
本文档来自支付产品技术交流群的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验（2年以上）的产品经理、软件工程师、架构师等，提供交流平台。如想加入本群，请在本文评论中留言（不公开），说明所在的公司、负责的工作、入群分享的主题和时间。
- 长按或者扫描二维码来打赏，感谢支持群管理工作！
- 请扫码关注“凤凰牌老熊”的微信公众号。
