序言

        5月初，企微官方上线了《针对服务商接口收费政策》，细究后发现除了常规的订单/支付模块外，还涉及到“阶梯收费”（划重点）。这一块属实知识盲区，本来想着先找找相关博客研究研究，借鉴一下前人的对接经验，然而翻遍各大论坛都没有找到相关的资料，于是决定自己把坑踩一遍后写一篇！

结论

    先看结论，下方正文有对每个“坑点”进行详细讲解。

    1、当上一个订单未完成时，不允许生成下一个订单；

    2、非首次下订单时（购买/续费）的时候，需要判断当前存量帐号的最长剩余时间，以此作为判断当前所处阶梯的依据；

    3、默认购买时长的取舍；

    4、退款原则：遵循“先下后退”；

    5、“试用期”和“许可帐号激活”是2个概念，不要混在一起。

正文

1、当上一个订单未完成时，不允许生成下一个订单；

    1.1 解释

        由于是阶梯收费，所以每次用户下单的时候，都要去查询他当前已购买的数量，这样才能继续计算到他之后的收费标准，然而下单和支付是2个割裂的流程，用户有可能最终不支付，也就是说我们无法获取到用户前几次累计的真实购买数量（这段话有点绕，不理解没关系，直接看下面的案例）。

    1.2 举例

        商家小A在卖西瓜，规定买5个西瓜，1个2元；买超出5个的那部分，1个1元（比如买8个，正常情况下是5*2+3*1=13元），但某顾客小B钻漏洞操作如下：

        a. 小B下第一个订单，买了5个西瓜，单价2元，总价10元，此时系统生成第一个订单（但是小B不付款，先搁着）；

        b. 小B再下第二个订单，买3个西瓜，单价1元，总价3元，此时第二个订单也生成，小B对第二个订单进行付款，拿走3个西瓜。之后再取消掉第一个订单。

        最终效果：小B只花了3元就买到了3个西瓜（正常情况下只买3个是要6元的），很明显钻了我们的漏洞。

    1.3 Q&A

        Q：在计算第二个订单的价格时，为什么不去查一下第一个订单的付款状态呢？如果查到第一个订单未付款，说明小A还没购买成功前面5个西瓜，那么在计算第二张订单的时候，可以还是按照第一个梯度（2元/个）去计算，给他生成第二张订单6元。

        A：如果按照上面这个说法去操作，那么第一张订单总价是10元，第二张订单总价是6元，如果最后小B2张订单都付款，那么他需要支付16元。而上面说了正常情况下是13元的。

        Q：那这就不怪我们了，谁叫他非要这样骚操作，我们多收3元就算对他惩罚。

        A：上面举的例子只是方便大家理解，实际上不管BC端的收费，这是都很常见的一个场景（比如聚合支付，清空购物车之类的），有些情况用户的出发点不是为了钻漏洞，但代码就是这样跑的，当普通增删改查的代码无法赋予人的思维判断用户的操作意图，只能从源头杜绝这种操作允许（开发大哥别打我，是我才疏学浅只能理解到这个程度了）。

    1.4 小结

        基于以上，最好的办法就是当上一张订单未完成时，不支持用户再提交新的订单（要么把上一张订单取消了，要么把钱给了），如果你有更好的办法欢迎交流~

2、非首次下订单时（购买/续费）的时候，需要判断当前存量帐号的最长剩余时间，依次来判断当前所处的阶梯

    2.1 解释

        企微这套阶梯收费逻辑，除了数量的属性外，还要时间的属性，由这2个属性共同组成这的收费算法。当用户在进行二次付费的时候，阶梯起始帐号数为企业客户已激活的帐号中当前剩余使用时长≥购买时长的帐号数。简单点说就是需要检查一下当前存量帐号的剩余时长，如果二次付费订单的时长大于存量帐号的剩余时长，就要按照第一梯队来收费（把它当成一个全新的订单）。

    2.1 举例

        1月份的时候买了5个帐号一年，250元。2月份有新员工入职，再买4个帐号1年。那么这4个帐号还是按50元计算，因为1月份买的5个帐号，当前剩余时长只有11个月，但我们买第二批帐号的时候，是按1年买的，1年>11月，剩余第二批帐号无法享受到第二阶梯的价格优惠

    2.3 Q&A

        Q：明明已经超出5个帐号了，为什么还是按照第一梯队购买？

        A：上面这种情况，如果支持按第二梯队购买，那么用户直接购买5个账号1个月，再购买4个帐号3年时间，等前面5个帐号过期后，后面的4个帐号的3年时间不就白嫖第二阶梯的优惠了吗。

        再举个通俗易懂的例子，目前住宅的水电费都是按照比如一个月内达到多少水量就按另外一个价格收费，但下个月就又开始归零计算。

3、默认购买时长的取舍

    3.1 解释

        上面说到，当用户第二次下单的时候，所购买的帐号价格梯队计算逻辑是需要参考当前存量帐号的剩余时长的，那么如果当我们目标购买时长不足一个月的时候，是要多买一个月，还是直接省略掉那一个月?

    3.2 方案1：不满1个月也按1个月购买

        优势：买多几天兜底，保证客户的企微在版本到期内都能正常使用；

        劣势：每次购买/续费都会用【本次购买时长】与【当前存量帐号的剩余时长】作比较，如果超出存量帐号剩余时长都是按第一梯队计费的，这样用户在续费/二次付费的时候，永远都是按照第一梯队的价格购买。

        比如：系统版本剩余11个月20天，直接购买12个月。

    3.3 方案2：非首次购买，不满1个月的直接不算

        优势：上面说到的这种场景，客户可以少花一点钱，按照第二梯队购买；

        劣势：极端情况下，在版本到期内，可能有一段时间用不了企微功能。

    3.4 小结

        2个方案各有优劣，需要结合实际业务场景评估。

4、退款遵循：先下后退

    4.1 解释

        用户如果有多张订单，用户需要退款，需要按下单时间倒序进行退款，也就是把最后一张单退了，再退倒数第二张...，直到第一张订单，跟堆栈的原理是一样的。

    4.2 举例

        用户先下订单1，再下订单2、3、4，那么用户在退款的时候，只能先退订单4，再退订单3，以此类推。

    4.3 Q&A 

        Q：为什么要这样做？

        A：假设用户在订单1购买了5个帐号（5*50=250元），订单2购买了5个帐号（5*40=200元），退了订单1。那么最终这个用户只花了200元就买到了5个帐号，然而按照正常的流程，只购买5个帐号，是需要按照第一梯队50元的单价的。

5、“试用期”和“许可帐号激活”是2个概念，不要混在一起

    5.1 解释

        试用期：在试用期内，企微不阻止第三方服务商为某个企业的某个员工接口相关调用；

        许可帐号激活：超出试用期后，没有绑定许可帐号的员工，企微会阻止调用该员工相关接口；

        试用期和许可帐号都有时间范围，当这2个时间范围重叠的时候，并不会累计叠加上，而是2条时间线会并行。

    5.2 举例

        举个极端的例子，企业授权安装应用后，有90天的试用期，比如今天是1月1日，那么试用期就是到3月29日，如果用户在1月2日买了许可帐号1个月，这一个月时间并不会延长到4月29日，而是包含在试用期的90天内，也就是相当于白买了。 所以这里可能会建议用户等试用期（快）结束再去购买许可帐号。

总结

      第一次做对接第三方支付系统的需求，历经3个礼拜的踩坑填坑，有些场景企微官方的文档根本没有明确记录到，需要开发者自己一步步猜测/测试（真够恶心的）。虽然最后没有自己独立跟着企微的收费规则写一套逻辑，直接拿了企微的计费结果来用，但上面这几点也可以给未来需要设计类似支付逻辑的朋友提供参考。如果还有我还没踩到的坑，欢迎交流～