手续费不是简单的交易额乘费率。通道方给你的报价单上写的0.38%，落到你账上可能是0.42%。那0.04%去哪了？看完老许这事你就明白了。
去年十一月，老许接了个生鲜配送的单子
老许是我们商户群里的老人了，自己搞了个同城生鲜配送的小平台，一天流水大概两三万。
他之前一直用的官方直连，微信支付那边给的费率是千分之六。算下来每天光手续费就得出去一百多块，一个月三千多。他觉得肉疼。
于是就想着切到聚合支付通道去。服务商给他报了个价：千分之三点八。老许拿计算器一摁，好家伙，一个月能省下将近一千块。当场就签了。
切通道的第一个月，账怎么都对不上
切过去跑了大半个月，老许翻后台账单的时候总觉得哪里不对。名义上费率是0.38%，但实际到账金额除以交易总额，算出来的比例大概是0.42%左右。
他以为是自己算错了，又拉了Excel逐笔对。每一笔的扣款金额都不一样，有的多有的少，完全没有规律。
老许当时想的是：这服务商是不是偷偷加价了？他直接截图甩到对接群里问怎么回事。对方商务回了一句：这是四舍五入的正常误差，全行业都这样。
老许不信邪。他把后台的原始数据导出来，用Python跑了一遍。发现手续费的计算逻辑跟他想的完全不是一回事——服务商不是按整笔交易算的，而是按三笔拆开算，然后再加总。
举个例子。一笔100块的订单，正常的算法是 100 × 0.38% = 0.38 元。但通道那边的算法是：微信手续费算一次、代付算一次、结算再算一次。分三次计费，每次都向上取整到分，最后加起来就是0.42元。
单笔差4分钱，听起来不多。但老许一天九百多笔订单，积少成多，一个月差了一千三百多。等于说切完通道，省下来的钱又被"计算误差"吃回去了大半。
真正的原因出在签约协议里的一行小字
老许把合同翻出来仔细看了一遍。在费率说明那页，有一行灰色的小字写着：手续费按子项分别计算后汇总，单笔保留两位小数。这个"子项分别计算"就是命门。
很少有人知道，聚合支付服务商的真实利润率不在那个明面上的费率差，而在这些结算细节里。官方直连的千分之六是一口价，没有拆分。但服务商的千分之三点八是总费率，底下拆成三四个子项，每个子项单独取整。取整的损耗全部由商户承担。
我跟老许说，你这是碰上了行业内公开的秘密。之前写过一篇关于费率的实测对比，里面专门提过这个坑：支付宝和微信支付费率到底差多少？2026年实测对比，当时测了三家服务商，两家都有类似的取整逻辑。
老许的破局办法：直接改结算周期
老许跟服务商磨了整整一周。对方一开始死活不松口，说这是标准合同没法改。后来老许提了一个条件：把T+1结算改成D0实时结算，费率按千分之四签，但取消所有子项拆分。
对方同意了。因为D0结算对服务商来讲资金占用压力小，他们反而愿意在费率结构上让步。老许算了一下：千分之四虽然比千分之三点八高一丢丢，但因为没了取整损耗，实际到账反而多了。
跑了两周数据对比，日均到账额比之前那个"低费率"方案多了大概四十多块。不多，但胜在透明，每笔账都能对上。
- 签约前问清楚：费率是总包一口价还是子项汇总
- 合同里看到"分别计算""汇总"字样的，直接要求改成单笔计费
- 测试期用
grep抓取后台日志里的手续费字段，跟自己的计算对比，跑够三天数据再签正式合同
如果重来，老许说他第一件事是改这个
他跟我说，如果再搞一次，他会在测试环境里先放五百笔模拟交易，把手续费的实际扣款比例跑出来再说。不看报价单，只看账本。
报价单上的数字是给人看的，账本上的数字才是通道真正的费率。这话老许现在挂在办公室白板上。
对了，后来他那个生鲜配送的生意做到了一天四万多的流水，又对接了别的支付方式。关于回调地址的坑他也没少踩，感兴趣可以翻翻这篇：易支付回调地址设置后不生效？一个案例复盘，里面有他踩过的另一个坑。
上个月老许请我吃饭，席间突然冒出一句：你说这些通道方搞那么复杂的计费规则，到底是防刷单还是防商户算账？
我想了想，没接话，低头继续涮毛肚。