按照嘉宾的要求，本文不对外公开。如果你是意外看到这篇文章，请勿将链接发送给其他人。

大家好，今天以某公司的共享汽车业务的一个案例给大家分享下

一、背景

某互联网公司要搞共享汽车业务，又苦于没有支付牌照，所以拉着上海某银行一起搞了个三类账户方案。 所谓的三类账户方案，就是给用户在上海某银行开一个三类账户，共享汽车平台上的用户余额充值需要同步到银行三类账户。 同时用户余额消费也需要从用户三类账户上扣除，并由银行内部账户转账至共享汽车平台在银行开立的结算账户（俗称98账户）。

二、业务流程

2.1 用户开户

1. 平台注册用户使用共享汽车
2. 引导用户进行开户
3. 填写身份信息并上传身份证照片
4. 调用银行实时开户借口|调用银行影像上传接口将用户身份证照片上传值SFTP
5. 完成银行三类账户开通
6. 平台记录用户银行三类账户号

2.2. 用户余额充值

由于采用此类方案后，用户在支付渠道的选择上就不在那么随意。 因为考虑到需要将第三方支付的银行结算对公户迁移至上海某合作银行的对公户上，不同的支付渠道结算后还需要根据用户支付记录生产用户结算文件，涉及到系统系列改造，所以前期只做了微信渠道的，也就是说用户选择使用共享汽车，暂时只能使用微信进行余额充值。 如果是实时付车费什么的，由于这类钱不需要监管，所以走之前的支付流程。

2.3 流程一

  1. 用户选择共享汽车余额支付
  2. 选择微信支付
  3. 平台记录用户支付信息
  4. T+1微信将昨天收到的余额充值结算款，将其结算给平台在上海某合作银行开立的98账户（监管账户）

至此，就完成了微信侧收到的钱向监管账户整体转移的过程。 注意：微信方面是无法区分你是车费的钱，还是余额充值的钱，所以不能和其他业务共用一个微信支付商户号。 这里我们是采用的单独的主体申请了在微信渠道下另外一个新的支付商户号，专门用给用户用来进行余额充值。

如何将这一大笔用户余额充值的钱，分别一个一个充值到用户在银行开立的三类账户里面了？

2.4 流程二

  1. 平台T+1日需要将T日用户余额充值的钱从平台在上海某银行开立的98账户里逐笔代发至用户在银行开立的个人三类账户中。
  2. T+1日支付渠道进行微信对账
  3. 生成差错信息
  4. 处理差错
  5. 完成后由运营人员根据实际情况触发用户余额三类账户结算动作
  6. 生成银行批量代发结算记录（平台自身记录）
  7. 生成结算文件
  8. 通过银行批量代发接口，上传至银行SFTP服务器

至此，完成系统用户余额从对公98户到个人三类账户的存管动作。 这里有个问题，如果直接根据用户在平台进行余额充值的支付订单给银行生成批量代发文件，会存在如果系统支付存在掉单情况下导致用户的余额充值无法正常到账，并且平台也不会显示用户这笔余额充值到账了。所以，需要进行T+1日的对账，这里就需要与支付对账系统进行关联。

如果批量代发文件上传银行后，由于各种xx原因，全部或部分处理失败怎么办？

所以，系统在这里还有个回盘处理流程，需要每20分钟（银行具体规则）轮询银行SFTP服务器，找到相应结算代发文件的回盘文件。

系统轮询平台未回盘结算文件记录, 轮询银行SFTP, 找到对应回盘文件, 根据回盘文件逐笔更新平台结算代发记录回盘状态。 系统运营人员每日关注处理失败用户代发记录， 进行原因分析及处理（例如开户问题，解决用户开户问题）， 根据失败记录重新生成批量代发文件， 上传银行SFTP处理， 回盘及后续逻辑循环进行， 直到批次下所有代发记录处理成功。

20180916_111442

三. 用户余额消费

用户余额充值的钱被放到银行监管以后，用户余额在平台上消费的钱，就不再属于用户了，而是花出去的钱，属于平台的收入了，所以这部分消费资金，是需要再从用户的三类账户中扣回来的，这部分钱也不再会收到平台在银行的监管户，而是在平台在银行开的另外一个结算账户，这部分账户不受监管，属于可以让平台提现使用的钱。

从系统层面，用户的余额除了真正的钱存放在银行三类账户中，在平台的虚拟账户中也是需要存储用户的余额，这样平台的业务逻辑在T日是不受监管逻辑影响的，这种方案在P2P行业最早搞银行存管的时候就是这种方案（流程是异步T+1日的），对系统实时流程的侵入比较小，当然至于是否100%的合规，就看双方怎么忽悠监管机构了。

所以平台需要根据自身的余额消费流水，生成消费代扣文件，上传给银行分别从用户的三类账户中将消费的钱，扣到平台在银行开的结算账户。

事实上，这里也会有个问题，就是平台余额虚拟账户的消费流水是否能够准确反应用户的消费情况？正常情况下，这里也是需要进行对账的，就是在T+1日对每个用户的余额流水与其账户余额进行对账，流水加加减减的余额=账户当前余额。

由于之前要求上线时间太急，这块就省略了，因为从用户角度看，无非就是钱被少扣了，平台大不了损失点，互联网公司以用户为中心在这个时刻就体现出来了！

20180916_112207

在余额消费流程里，在与银行批量交换交易文件时都会存在余额充值中提到的回盘问题，所以需要做一个通用的回盘处理流程：

20180916_112257

四、坑&痛点

在很多公司发展过程中，最开始是很难预料到会有这种业务逻辑的，即使你预料到了，由于当时公司所处的发展阶段及团队环境，也会很难说为了以后怎么怎么样，我们应该怎么做，这样会让人觉得很扯淡，这一点，如果你们一直在支付公司可能体会不出来，如果来一个处于快速发展阶段的互联网公司做支付这点就深有体会了。

但是作为一名有经验的PM或者Enginer，为了给自己或团队少埋点坑，所以还是需要考虑下的，涉及资金的交易经过这几年的工作，发现很多也差不多。 例如：我们在上面提到过的，因为同样是微信支付，公司早期可能就这样，一个商户号收很多交易类型的钱，所以支付系统很简单，搞个配置文件配置下就好了。 但是进入快速发展阶段，发现不同的业务可能就需要一个渠道开很多不同的渠道商户。 像这里，需要新加个微信支付商户号，本来其实就是配置配置的，支付系统并不需要改动太多，如果是硬编码，就得额外改造，需要对实时流程做适配增加好多工作量。

今天的分享就这么多了，谢谢大家。

Q&A

Q1、 请问如果不和银行合作还有什么办法，用户充值直接存到公司结算账户不行么？
A: 没有支付牌照, 监管不让，这也是为啥滴滴，美团都要搞自己支付牌照的原因。

Q2: 用户可以通过网银或快捷方式，将该银行三类帐户资金提走吗？若可以，平台反应的个人虚拟帐户余额可能就不准了
A: 不可以，三类账户是存管账户，不同于二类现金账户，不可以直接用第三方支付绑卡操作。 如果用户需要退款，可以通过平台发起退款，平台调用银行退款接口，然后更新自己的余额，然后走代付。

Q3: 请问对于t日充值，t日消费的，98户、存管户、平台户资金流程在t+1是怎么处理的？
A: t+1先处理充值，在处理消费，分别处理

Q4: 这里的三类帐户应是银行内部自定义的，不是人行定义的1,2,3类帐户的概念
A: 可能是，银行实际的使用方式可能不一样

Q5: 应该不是银行三类户，银行二三类户都是要绑定一类户作为入金出金吧？银行的这个98账户是银行一个内部户吗？
A: 应该是的

本文档来自支付产品技术交流群的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验（2年以上）的产品经理、软件工程师、架构师等，提供交流平台。如想加入本群，请在本文评论中留言（不公开），说明所在的公司、负责的工作、入群分享的主题和时间。