这篇文章详细讲述回流平台规避“二清”问题的历程，其中也会提及要如何解决大量散户的合规分账的问题。希望能给后面遇到此类问题的企业一些帮助吧。原文链接： https://step-by-step.tech/posts/talking-about-pay

前言

下周要回老东家Beansmile做一次技术分享，Leon 让我把离开豆厂之后的深刻经验跟前同事们分享一下。

回过头看其中印象最为深刻的经历莫过于对接各种支付系统了。这篇文章主要针对去年在支付坑里的挣扎做一个总结。作为一个平台型商户要如何规避“二清”问题，为何分账系统这么重要，有哪些比较好的分账系统可以选择，其中又有哪些坑需要规避，要如何兼容多种支付渠道，这些问题都记文章中了。

平台，支付，二清，分账

回流从一开始就打算做平台（一个闲置玉翠的二手交易平台），这似乎也注定了我们要直面“二清”这个绕不太过去的槛。不过在开始讲平台“二清”问题之前，请允许我花少量的笔墨来讲讲一般平台的演化过程，毕竟不是所有公司一开始就打算做平台的。

传统商城模式

在传统的商城模式下，商品一般归商城主所有，这也就意味着，所有商城的收入都应该归商城主，而直连商家支付就能满足绝大多数的应用场景。我们常规对接的微信支付/支付宝支付/银联云闪付基本默认就是这种直连商家的模式。

换句话说，这里面自始至终都只有一个商家。这种模式的特点就是单商户，资金流简单，资金的最终流向都是商城主。商城的主体可以把收入提取出来做工资结算，覆盖材料成本等等。

随着商城的发展，品类一般都需要扩张，商城就会去开发更多的供货商，而商城也会渐渐演变成一个平台。京东就是一个很好的例子，其实京东一开始都是自营为主，可以归结为一个“当天买当天到”的大商城，然而随着京东自身的发展，它开始有了很多渠道商，渐渐地也演变成一个平台。

平台 - 供应商模式

其实现在也有不少人会选择做平台（比如我们回流），跟传统的商城模式不同，平台上有些货品并不是来自商城主自身的而是各种不同的供应商/渠道商。

形象一点我们也用京东商城来作为例子，京东商城里面大致可分为“自营”以及“非自营”两种商品，所谓“自营”就是京东自己的仓库，可以说这些商品是属于京东自己的。而“非自营”我们可以想像成其他的供货商与京东合作“借”京东这个平台来卖东西，京东可能会收取一定的平台服务费，而交易的大部分收益应该归给供货商。

这种场景下我们依旧可以把所有钱都平台收着，然后按月结算给其他渠道商。京东如果这样干的话其实没啥问题的，因为京东是有自己的支付的，换句话说它肯定有价值十几亿的支付牌照，它想怎么结算都可以。然而市面上绝大多数的平台其实都买不起牌照，因此不能这样做结算。这样就面临两个选择了

• 在没有牌照的情况下强行结算，涉嫌“二清”。
• 承认所有收入都是平台所得，平台统一收取。然而一旦承认所有收入都是平台的，减去成本之后剩余的部分都要交税，这样一来多了许多不必要的税务。

这实在是两难。

对于普通平台来说较为常见的解决方案就是借助第三方支付平台的分账结算。

在这种模式下自家平台作为一级商户，众多的供应商作为二级商户。支付完成之后资金会先行冻结在第三方支付平台中，然后通过分账接口来进行资金结算，以此做到供应商的钱平台无法触碰，平台只结算到自己应得的金额。这对于资金安全有一定保障。

为什么要防止“二清”

既然供应商跟平台是合作关系，平台先收钱然后再转给合作方不是一样的吗？何必做得这么麻烦，为何监管这么严格，国家为什么要求有牌照才能进行结算呢？这确实需要掰扯掰扯。

如果平台统一收款，会有一定的资金风险。资金得不到监管，一些居心不良的平台可能等收入达到上百万上千万之后就会卷钱跑路。这样不仅仅会造成普通客户的资金损失，最大的受害者其实还是供应商们。而且近期跑路的平台是在太多了，国家也不得不严加监管。当然对于那种想踏踏实实做平台的公司来说可能会被误伤，当然这也没啥办法，法制社会在制定法律的时候还是以“人性本恶”为前提来定，以防止一些不必要的事故发生。

至于惩罚，其实不小，据说美团/蘑菇街这些平台就因为涉嫌“二清”被罚了几百万的巨款，对一般公司来说这一罚下来可能一年都白干了，实在是得不偿失，所以中国的企业真的是夹缝中生存。

对于刚起步的小平台来说一开始做得这么正规几乎是不可能的，有很多的坑要去踩，一般刚起步的企业监管机构也不会觉得风险系数有多高。然而随着生意做起来，平台方收款越来越多了，便要逐步寻求合法正规化了。前面也说过，收那么多不属于自己的钱，如果承认是平台收入，扣除成本之后税务就不太好办了。如果不承认是平台收入，平台只是作为结算方，然而没有牌照就涉嫌“二清”。

“罗马不是一天建成的”，回流也走过不合法不合规的时期，我觉得也是必经之路吧，都是慢慢整改过来的。回流刚开始的时候其实也是全额收款，然后再私下打款的，后来是担心“二清”问题，我们换成用微信的电商收付通分账，平台的钱结算到平台，剩余的打到某个私人账户中去（私户统一收款），然而这种模式还是换汤不换药，后来因为到私账的钱太多了，风险太大，微信逼迫整改，而且分账有限额，很难跟支付宝结合使用。最后辗转几次才选定了如今 Adapay 聚合支付解决方案。关于聚合支付可以参考我之前的文章《关于聚合支付》。

微信电商收付通

其实为了规避“二清”问题，几乎所有第三方支付平台都提供了相应的解决方案。比如微信的电商收付通，支付宝的互联网平台直付通，汇付 Adapay，都是类似的，只是底层技术对接多少有些不一样。毕竟支付宝那个我还没用过，这里说说微信的电商收付通，简单讲讲它的利与弊，以及回流为啥最后没有继续使用它。

简单来说，要解决“二清”问题还是要依赖具有“一清”能力平台（支付宝，微信，银联，银行等等）所提供的分账解决方案，让资金能够在“一清”平台上结算完毕，就不用担心“二清”的问题了。而这些“一清”平台所提供的解决方案其实都大同小异。基本逃不过以下步骤

1. 一级商户资质申请（平台方），完成了这步才能收款。
2. 二级商户入驻（供应商们），入驻之后可作为分账对象，可以想像成在特定平台上创建了一个虚拟账户/分账账户。
3. 交易 + 分账 + 各自绑定银行卡提现，线上账期一般是 T1，D1。

对于电商收付通，一级商户资质申请比较简单，一般注册之后提供资料就行，搞定之后就可以使用电商收付通了。二级商户入驻，需要入驻方提供一定的材料证明，不同身份（个人，企业，组织等等）要求的资料可能不太一样。

假设一件货品来自供应商 A（二级商户），价格 100 元，交易成功之后平台要收取 5% 的服务费。那么当客户使用微信支付 100 元之后，资金会冻结在微信，此期间资金不可挪动。要解冻这部分资金，需要调用微信的分账接口，分账之后其中 95 元会到供应商 A 的账户中，5 元到达了平台的账户中，平台与供应商可以对各自账户的资金进行提现。这便是交易 + 分账 + 各自提现的整套流程。

然而对于回流来说，微信的电商收付通会有种种问题，请容我一一列举，仅供参考。

1. 二级商户入驻麻烦，审核最宽松的个人商户都要提供身份证号，身份证正反面照片，手机号，姓名才能入驻成功。对于用户而言需要提交的资料太多了，体验不佳。
2. 回流是一个二手交易平台，几乎所有货主都是二级商户，要维护的二级商户账户太多了，不利于维护。鉴于第一点需要提交的资料过多容易吓跑客户，不利于获客。
3. 所开的商户号都是微信下的虚拟账户，只能用于微信支付。如果要对接支付宝支付，必须支付宝端也要完成商户入驻，同时要维护两套二级商户账号（一套微信一套支付宝），维护成本过高，如果后面要添加更多的支付渠道，而且用户也有可能需要提供额外的资料，维护成本会更高，用户体验不稳定。
4. 如果支持多个支付渠道的情况下，可能资金会分散到多个渠道（支付宝支付的话资金到支付宝二级商户号中，微信支付的话就到微信的二级商户号中），这会给用户带来一定的困扰，体验相对较差。
5. 分账限额，分账比例只能是 30%（比如一笔订单支付了 100 块钱，那么一级商户最多只能分走 30 块，不具备实现五五分账的条件）。微信几乎不给予开通高比例分账，我们尝试了很多次都没能申请成功，身边的朋友也问了一下，目前没有成功案例。
6. 一级商户不能收款，收款方必须是二级商户，且用户支付之前就要设置好收款方。

不管怎么说电商收付通还是陪伴我们度过了一段艰难的时期，为了对接它我还开发了wechat-pay这个 Gem。那时候我们只开通少量的二级商户用于收款。平台的钱直接结算到一级商户，而客户的钱统一用某一个开通了二级商户的私人账户进行代收款。这其实也是另一种“二清”，只是相对没那么容易被发现。微信也风控到了警告了我们好几次，最终给了一个多月的时间去整改（春节前夕，这年过不好了）。

Adapay 聚合支付方案 - 支付界的 React Native

鉴于微信电商收付通的种种限制，考虑到以后要对接其他支付渠道时的维护难度，再加上我们用私户代收款的方式已经被微信风控，要求必须要在一个多月之内完成整改，故而我们不得不寻找别的解决方案。

聚合支付平台无疑是一个不错的选择，现在能做聚合支付的平台很多，老实说靠谱的却很少，那些广告做得好的很容易就能够被搜索得到，但不一定好用。而聚合支付里面，比较出名的应该是 Ping++，至于我们为什么不用 Ping++ 我将放到后面的章节再聊。

前面也说了，很多的聚合支付平台其实都是半桶水，不是文档不健全就是支持的支付渠道太少。又或者是就是一个“基于聚合支付平台上做二次开发的聚合支付平台”，我们首次合作的Mallbook其实就是这类，后来因为没有开放文档，对接实在十分不顺畅，只能毁约。最终，我们选择了汇付的Adapay，无疑是目前最适合我们的解决方案。这里就不秀代码了，针对它我封装了一个名为adapay的 Gem，只是文档还没空补，有需要的可以上去试试。

简单讲讲它的优缺点

优点：

1. 支持的支付渠道很多，微信支付（小程序，APP，公众号等等），支付宝支付（小程序，APP，生活号等等），银联云闪付，银联收银台，汇付快捷支付（自研支付，支持众多银行），接口统一，开发便捷。可以参考这里。
2. 持续迭代更新，有专门的服务团队。他们有一个自己的控制台，交互还算舒服，并且有个专门的对接群，里面各种专家老师都有也有技术人员，基本上对接比较顺畅，响应速度快，服务也比较专业。
3. 二级商户入驻十分便捷，只需要提供身份证号，手机号码，姓名，即可开通分账户。这应该算是最小输入了，利于获客，目前回流已经有 3000+ 的分账账户。
4. 分账账户统一，资金统一流入分账虚拟户，用户绑定银行卡可以各自提现。
5. 除了商户号被风控/被客户投诉需要提供申诉材料之外，几乎不用直接跟支付宝/微信这些平台打交道，汇付解决了大部分麻烦的事情，并向客户提供统一接口。
6. 手续费较低，可能是合作平台的关系，手续费比直接对接第三方支付要低一些。
7. 针对不同的应用场景可以开通多个应用账户。
8. 分账比例没有限制。

其实汇付的优点还是不少的，只是客观起见，还是列一列它的缺点吧。

缺点：

1. APP 微信支付不算流畅，不过这个也不能算是汇付的锅。因为微信 APP 不支持间连模式，所以微信的 APP 支付是需要跳转到小程序，然后用小程序的支付来完成后面的事情的，这个过程比起直接用微信 APP 原生的支付体验还是差了一丢丢。
2. 年费较高，如果要成为汇付的客户则必须要每年交 50000 元。日交易额稳定超过 50w 的话第二年开始开始可以免年费。
3. 接口文档错误不少，有些功能需要参考官方其他语言的 demo 才能实现。
4. 风控比较严格，可能这也与国家政策有关，当他们发现他们所对接的第三方支付渠道（支付/微信）有关闭支付的推送的时候，他们这边也会不问情由地拉闸，毫无征兆。所以对接汇付平台也要时刻留意来自微信/支付宝方面的推送，有啥异常立即申诉并跟汇付协调，以防拉闸。（汇付只是作为支付机构是不会管你平台死活的，他们平时要服务的客户也多，自己的事还是自己多上点心）。

任何平台都有它的优缺点，不过对比起汇付的优点，这些缺点其实都不算啥了。单从门槛，编码简易性以及代码可维护性来看，汇付真的是一个不错的选择。目前回流所遇到的资金流问题，在他的帮助下基本得到了较为妥善的解决，不过如果条件允许的情况下，我们还是想尝试 Ping++ 的解决方案。

我们为什么没有选择 Ping++

在中国，只要提到聚合支付 + 分账，几乎所有人都要给你推荐 Ping++。但我不得不问，你们当中真的能把 Ping++ 用上的有多少家呢？Ping++ 无疑是个很好的聚合支付平台，这点我并不否认，然而它那个高门槛（几百万的留存资金）却不是一般企业（特别是初创企业）能够跟得上的。但不管怎么说如果有可能，我们还是想试试它，毕竟在我们看来它跟银行合作，由银行来分账的解决方案才算是“终极”的解决方案。

Ping++ 跟 Adapay 的异同

总的来说 Ping++ 跟 Adapay 都是聚合支付平台，都打通了支付宝/微信，不过他们的底层却有很大的不同。其中较大的区别就是，汇付的 Adapay 其实是自身研发了一个类银行的支付&分账系统，借助第三方渠道来收款，资金在 Adapay 内部进行结算。然而 Ping++ 的解决方案里面，在收款过后完成结算的其实是银行。Ping++ 会根据你的业务需求来给你寻找愿意合作的银行，双方签署协议，然后进行对接。有经验的人都知道，只要涉及银行，对接成本跟对接门槛就不会太低，而且往往时间线很长。Adapay 就不一样，我们从付费到完成代码上线只花了 2-3 周时间。

为啥最后没用 Ping++

我们其实也有联系过 Ping++ 的顾问，不过最终还是没有谈成合作，主要有以下原因

1. 留存金额不够，这连人家合作门槛都没达到，后面的事情就不用再谈了。
2. 虽然有 Ping++ 做方案，但是跟银行打交道也不是一件容易的事儿。由于中途走了些弯路只剩下三周的时间整改（微信只给了一个多月），Ping++ 的方案根本就来不及。
3. 我们需要的分账户数量有点多，很大一部分的散户都需要分账功能，这也就意味着开户的流程不能太复杂，Ping++ 那边至今没有接触过有类似的客户也不确定能不能做。
4. 年费的金额大同小异，据说 Ping++ 要高一点。每年除了手续费之外还要交几万的年费。不过 Ping++ 是每年都要交的，Adapay 在业务达标之后是有可能减免。总的来说可能 Adapay 成本要低一些。

总的来看 Ping++ 的接入成本高，流程冗长，一般公司经不起这般折腾。然而 Ping++ 直接跟银行合作，系统可靠性方面肯定是没问题的。而且通过银行来分账，微信支付方面说不定就能够走原生流程，体验方面肯定要比 Adapay 只能跳转微信小程序支付要好一些。所以在我看来 Ping++ 才是终极的解决方案。只是成本高，门槛高，目前却也只能想想了。

展望

回流这一年多以来在支付领域遇到了不少门槛，总算是一步步走到了今天，找到了一个还算适用的分账解决方案。不过一切还没到高枕无忧的地步，下面提一些支付领域的展望

• 接入更多的支付渠道。正常来说绝大多数人都只会用微信跟支付宝。不过多一个支付渠道就意味着在出问题的时候（某一方拉闸）能多一个备用方案。这也是我们对接银联云闪付的原因。因为我们支付宝经常被拉闸，然后有些打死不用微信支付的客户就无法支付订单了，导致平台十分被动。
• Ping++ 解决方案。Ping++ 跟银行合作直接分账的做法很有吸引力，但是对我们来说门槛太高，难以触及。当然也有可能，银行的灵活性远不如 Adapay，风控却更严格，这样就不太适用于我们了。不过这依旧是一条值得探索的道路，有机会还是想试试看。
• 境外分账。虽然我们生意还没做到海外，但目前已经有些海外散户想要参与进来了，境内外资金流如何打通，且不触碰法律红线可能会是后面需要考虑的事情。

尾声

这篇文章有点长，详细地总结了一下回流这一年多以来在支付领域的血泪史，以及今后的展望。如今在 Adapay 的支持下系统还算稳定，现在回过头想想自己当初遇到“二清”，分账这些概念的时候的迷惘状态，真的是恍如隔世。一个不慎就被拉闸，被迫整顿的日子着实不太好受。

不过我还是挺感激这段旅程的，经历过这些之后业务能力还是有一些成长的。抗压能力多少还是提高了一点儿，很多危急关头都扛过来了。不过悲哀的是，我们几个产品的核心人员都感觉，可能更大的危机还在后头呢。

PS：当如果能够早点遇见橙陌科技的联合创始人 wikimo 可能会少走许多弯路，我发现这段时间躺过的雷，他们早就经历了，完全就是我们的前辈。而且现在正用 Ping++ 的解决方案来支撑着目前的业务，还算挺稳定的。只是因为有些内部信息未经授权不太好展示在文章里面，如果有 Ping++ 相关的东西想要咨询他们可以通过Ruby China来联系他（回不回复我就不知道了，这里只提供一个公开的联系的渠道）。

参考连接

• adapay Gem Github: https://github.com/lanzhiheng/adapay
• wechat-pay Gem Github: https://github.com/lanzhiheng/wechat-pay
• 直连和间连微信支付/支付宝的区别：https://zhuanlan.zhihu.com/p/385787756
• 支付老司机：https://www.zhihu.com/people/hust-chenqi/posts
• Adapay 官网：https://www.adapay.tech/
• Ping++ 官网：https://www.pingxx.com/
• PPT PPT