合作伙伴等级与活跃商户数

合作伙伴费率在 Paymos 不是一次授予的，而是每天从一个数字里读出来的。四档里的前三档——被推荐商户产生的处理费的 20%、25% 和 30%——跟着这些商户里有多少个处于活跃状态走。

活跃要求两个条件同时成立：账户未被暂停、封禁或拒绝，并且近 30 天内完成过至少一笔正式环境的结算付款。这个窗口是滚动的，费率每天从窗口里重新读一次，降档和升档走同一条规则。

合作伙伴计划页面上有等级、费率和一个计算器。这篇写的是它们下面那一层：商户怎么进入计数、又怎么退出，每天那次重算动的是什么，分成从哪一笔钱里出，以及哪一档任何数量都够不着。

为什么推荐总数不决定费率？

费率读的是活跃商户数，不是累计推荐数。这两个数字在第一个月看起来一样，之后就一直分开走——第一个商户停下来的那天开始分。

累计推荐数是一个历史数字，等级从来不看它。进入计数的只有今天同时满足两个条件的商户，所以去年攒下的注册量对今天的费率没有贡献。

反过来也成立。停止拉新的那个月费率不会掉，只要名下商户还在正常收款，数字就停在原地。撑住等级的不是新增速度，是存量商户的运转。

等级表是结果的一张照片。照片里没有产生这个结果的规则：什么算数、按多长的周期算、以及这个数字会不会被再读一遍。这三个答案决定了阶梯到底值多少，下面按顺序把三个都答完。

什么样的商户才算活跃？

活跃商户是在同一天满足两个条件的商户。账户未被暂停、封禁或拒绝，并且近 30 天内完成过至少一笔正式环境的结算付款。两个条件都按今天的状态读。

30 天是滚动的。等级背后没有一个从头累计的总数，所以一月推荐、上周结算过的商户今天算数；一月推荐、最后一笔付款停在六月的商户不算数。

进入计数的事件是结算，不是注册。注册完、接完接口、测完，却始终没收过一笔真实付款的商户，对计数没有任何贡献，因为计数根本不读注册记录。推动等级的是在做生意的商户，不是加入过的商户。

第一个实际结论就在这里。一周带来二十个注册的活动当天不会动费率；要等这些账户真的开始收款，而且只在他们持续收款期间，费率才会动。

哪些付款能把 30 天续上？

能把窗口续上的事件有两个：一张已支付的账单，或者一笔已确认的支付通道入账。任意一个都让这个商户重新拿到 30 天，而计数不关心钱是哪一边带来的。

这是两个不同的产品。账单按订单创建，带金额和有效期——它从创建走到已支付的全过程本身就是一篇指南；支付通道是一个长期存在的收款身份，既不带金额也不带有效期。只用通道的商户，和只开账单的商户一样活跃。

定义里的正式环境四个字同样是硬条件。沙盒用另一套凭据，在虚拟余额上运行，模拟出来的入账不是结算，永远进不了计数。花一个月调接口的商户，不是活跃商户。

两条路通向同一个结果，所以两边都用的商户，留在计数里就有两次机会。订单流停摆的那段时间，通道上收到的一笔确认入账，也足够把这个商户的 30 天重新起算。

账户状态会把谁排除在外？

状态这一条排除三种账户情形：暂停、封禁、拒绝。处在其中任何一种的商户，无论最近结算过什么，都在计数之外。看的是账户今天的状态，不是它的历史。

两个条件必须同时成立，不是二选一。状态正常但 31 天没结算过的商户，卡在付款那一条；昨天刚结算过但账户被暂停的商户，卡在状态那一条。谁也救不了谁。

所以名下商户一个没变，计数照样会动。没有新推荐，也没有丢掉谁——是某个账户状态变了，或者某个日期过去了，今天早上费率读到的就是另一个数字。

从复盘的角度看，这样理解更省事。降一档不需要一个事件来解释，它只是两个条件在每个自然日重新量一次之后的当天结果。

分成是从哪一笔钱里出的？

分成从 Paymos 处理费里切出来，不是加在处理费上面。被推荐商户付的就是价格页上写的数：标准价每笔结算账单 1.0%，企业价 0.3%，按申请开通。

这个百分比算的是哪一笔钱，是这里最值得记住的区别。合作伙伴拿的是手续费的一部分，不是产生这笔手续费的交易量的一部分；在标准价下，同一个百分比的两种读法差两个数量级。

两头都没有封顶：名下商户能跑多少交易量不设限，累计能拿多少佣金也不设限。手续费只是整张成本表里的一行，一笔收款从头到尾的成本把其余部分讲完了。

商户那边什么都没变，所以这件事在谈客户时也好讲。被推荐商户和没被推荐的商户付一样的手续费；合作伙伴那份是从里面分的，不是往上加的。

等级变了，之前推荐的商户跟着变吗？

等级变化覆盖名下全部商户，升降都一样。费率是合作伙伴身上的一个值，不是挂在单个推荐上的，所以不会出现两个费率并行——一个管变更前带来的商户，另一个管变更后的。

推导出来的三档挂在两个门槛上：20% 从第一天起生效，没有门槛；25% 要 5 个活跃商户，30% 要 20 个。活跃数越过 5 的那天，前四个商户和第五个一起换成新费率。向上时覆盖全部的那一个费率，向下时同样覆盖全部：跌回门槛以下时，名下商户整体换费率，不是只换一部分。

升档是自动的，读取数字的那次每日重算把两个方向的变化都落到位。一条规则、一个节奏；数字是在涨还是在跌，同一个门槛的读法不变。

对账那边因此简单不少。同一天只有一个费率生效，不需要按推荐时间把账单拆成两批来算。

40% 能靠数量攒出来吗？

40% 是任何数量都够不着的那一档。它是 Strategic 档，背后没有门槛——没有高门槛，也没有隐藏门槛。它由人按申请授予，推荐再多商户也生不出来。

这改变了等级表当作计划来读时的含义。四行里有三行是算术：数一遍活跃商户，找到对应那行，那就是今天早上的费率。第四行是一次沟通，把它当成同一段楼梯的顶层，得到的是一个没有路径的目标。

它也是每日重算唯一跳过的那一档。推导出来的等级每天从一个可能下降的数字里重新算；授予的费率不从任何地方读出来，也就没有可重读的东西。

从做计划的角度差别很清楚。前三档的目标是一个数字，可以照着攒；第四档的目标不是数字，所以把名下商户做大并不会让它更近。

佣金什么时候入账？

分成在被推荐商户结清一张账单时入账，就在结清的那一刻。没有要等的月结，也没有打款周期；入账挂在结算这个动作上，不挂在之后的某个日期上。

程序背后的两次判定宽窄并不一样，这个差别很容易看漏。活跃计数两种结算都收：已支付的账单，和支付通道上已确认的入账。分成则是按账单表述的——被推荐商户结清的每一张账单都付分成。

于是已支付的账单成了同时干两件事的那个事件。它既把这个商户在计数里的 30 天续上，也把分成记进去。计数和分成是两次独立的读取，而账单同时满足这两次。

把入账绑在结算上，也就没有月末悬念。没付、过期或取消的账单不产生处理费，分成同样只按真正结清的那部分记。

淡旺季会把等级拉下来吗？

淡旺季是费率问题，不只是流水问题。在同样的年交易量下，一批小而稳定的商户能让高费率覆盖一年里更多的月份，一批大而季节性的商户做不到。

十二个每月都结算的商户，计数就是十二。三十个一年只做两波的商户，一年里读到两次三十，其余时间读到零。同样的年度总量，摊在十二个月上就是两种费率。

高峰之间会清空的名下商户，在那几个月被读成更小的一批，费率先跟着降下去、之后再回来。选谁来推荐时，这个结论有点不舒服：对等级来说，商户的节奏比体量更要紧。

还有一点容易算错：这 30 天从最后一笔结算往回数，不按自然月切。大促收尾在 3 号和收尾在 28 号，对计数是同一回事，掉出计数的日子也就落在下个月的不同位置上。

每天该盯哪个数字？

要盯的数字是近 30 天里有过结算的商户数。累计推荐总数是一个历史值，等级从来不读它，而这两个数字在第一个商户停下来的时候就不再一致。

在两个门槛之间，多一个活跃商户值它自己那份佣金。踩在门槛上时，它还额外值一次给已有商户的整体加价——等级变化会把名下全部商户重新定价，所以第五个活跃商户把另外四个的费率也抬了上去。第二十个同理。

这就把维护摆到了拉新旁边。停了一个月的商户离开计数，和从没启动的商户一样干净；把一个已有商户拉回正常运转，价值不亚于带来一个新商户——计数正好卡在门槛上时，还要更高。

推荐链接和当前生效的费率都在控制台里。上面的每一笔记账，都从一张账单走到最终已支付状态开始，而一笔加密货币付款走到那一步的路径，不会因为商户是合作伙伴带来的而改变。