微信二清解决方案-收付通，来说说那些坑-迷路的老鼠

微信收付通上线刚好两个月，这两个月一直在填坑，趁现在理顺了一点，总结一下。

我们在业务架构上属于传统型，自营和POP都有。POP商家T+1月进行结算，结算账单以订单发货为节点，订单跨月发生售后，在次月的账单里体现，进行账扣。

微信收付通接入时，我们的方案是新老并行，也就是通过老的微信商户号支付、微信收付通支付，走不同的账单和提现流程。上线后，这个流程没有出现问题，顺利过渡到了全量的微信收付通。

但是在第一个结算周期的时候出现一个比较大的流程性问题：商家提现时，提示微信二级商户号余额不足。

我们首先想到的是商家自行登录二级商户号进行了提现操作？

让商家提供了二级商户号的资金账单，没有发现自行提现的记录。

下下之策，只能拿出我们自己的账单和商家的资金账单进行逐项核对，终于发现了问题。

我们的账单是基于上月整个未发生售后的已发货的订单，结算出来的一个金额。但是微信二级商户号的可用资金是动态的，即上月发生的已发货的订单，如果本月进行售后，那么会在可用资金里扣除这部分钱。而这部分的钱，在我们的账单上体现在了下个月。

所以，理所当然的对不上，而且这怎么可能会对的上呢？

临时的解决方案是，提前解冻一部分本月的资金，填补这部分的缺口。

完整的解决方案目前还没有想透彻，但是两个账单的方式显然是没办法去玩的，初步的想法是彻底革掉目前的结算体系，引入商家资金账户的概念。

即，商家资金账户和账单分离，账单采用微信+本地双向互对的模式，防止某一方出错（严格意义上）。资金账户一定与账单能对的上，但是资金流水必须是账单的延续和实时体现，方便查账。

最后，也列举一下其他的一些小坑和注意事项。

微信收付通的的合单支付是子单纬度，即每个子单都会有一个支付流水号，如果原有业务是基于父单的，那么改造的范围必须覆盖这一点，因为后续的流程全部都是基于这个子单。其中另外一个潜含的意思是，发起支付请求的子单包含的商品必须是同一商家的，但子单的商品种类不限制为同一个（即商品行可以是多个）。

要严格按照接口文档的描述回写和传递字段，比如业务单据号，最好每个业务一个独立的单据号，在整个电商体系内不要重复（切忌使用表主键ID作为业务单据号）。
所有单据号必须区分线上和测试环境
微信支付流水如果需要拉取，如何区分测试环境和线上？构造支付参数时，attach字段可以自定义，测试环境和线上环境可以传不同的值，用于区分。
项目上线前期一定要做好换单重试的逻辑，比如分账，微信对同一个订单进行分账时，如果失败是不能重试的（非技术问题），需要换个分账单号。
微信服务商后台功能比较简单，无法完整的形成对账报表，所以需要拉取服务商号以及二级商户号的资金账单、分账账单、支付流水等，做好双向对账。其中服务商号无法通过接口直接拉取二级商户号的资金账单，需要开通产品权限，所以需要提前做好准备。

另外，针对海淘的商家，如果需要向境外商家打款，有两种方式：

1.海淘商家在国内通过代理商进行进件，平台向代理商结算，然后通过该代理商做资金出境（无需代理商操作），但是由于资金是进了代理商的公司，所以部分海外商家是不愿意的，除非海外商家在国内有子公司，但是这样的话也不会存在资金出境的问题。

2.平台通过自己申请进件自营海淘商家，然后向国外的自有公司申请资金出境，国外的公司再向各个海外商家人工打款。这种方案的硬性要求是，平台必须拥有一家可以海外代账的公司。

微信收付通在资金的管理上，还是比较严格，资金的流向每个环节的控制都有前置检查，出现技术问题导致大规模资金损失的可能性比较小，所以正确理解本身的业务和微信流程很重要，设计流程时，一定需要考虑好，我们的系统如何靠上去，以及数据的回溯和修补，特别是上线前期，出现数据问题是很正常的现象，重要的是一定要做好业务预警、排查工具以及修复的手段。