去年帮一个做园区WiFi运营的团队做技术评估的时候，他们的CTO问了一个特别实在的问题："我们现在的WiFi网络计费系统跟支付系统对接这块总是出问题，要么是支付成功但用户没激活，要么是用户付了钱但财务系统查不到记录，这种问题到底该怎么从根本上解决？"我把他遇到的问题梳理了一遍以后发现，这其实不是他们一家的问题，几乎所有自建WiFi计费体系的团队在支付对接上都踩过类似的坑。

WiFi网络计费系统跟微信支付、支付宝对接的时候，大部分人关注的是接口调通没调通，能不能成功发起支付、能不能收到回调通知。但实际上这种思维本身就是有问题的——接口调通只是万里长征第一步，真正要解决的是回调的可靠性问题。

什么叫回调可靠性？就是当用户支付成功以后，支付平台发来的回调通知能不能百分百被你收到并正确处理。这里面的坑比大多数人想象的多得多。我见过一个案例：运营商的网络出口偶尔会有几秒钟的波动，恰好在这几秒钟里微信支付发了一个回调，没送达。微信支付默认会重试，但重试次数是有限的，而且有间隔。如果你的WiFi网络计费系统没有主动查询订单状态的机制，只依赖被动接收回调，那这条订单就永远卡在"待支付"状态，用户那边钱已经扣了但WiFi没激活，只能打电话投诉。

解决这个问题的标准做法是双保险机制：回调通知是第一道防线，定时主动查询是第二道防线。每一条超过五分钟没收到回调的订单，WiFi网络计费系统应该主动向支付平台查询支付状态。这个机制在技术上没难度，但很多系统在设计初期根本没考虑，等到上线规模大了才开始打补丁。

支付对接里还有一个特别容易出问题的地方，就是套餐映射。WiFi网络计费系统里定义了一个"月卡套餐30元"，支付请求发出去的时候金额是30.00，但支付宝或者微信的回调里返回的实际付款金额可能因为各种优惠券、红包、随机立减变成28.50。这时候你的系统要怎么处理？是按30元激活还是按实际付款金额来折算时长？

这个事情没有一个标准答案，但你的WiFi网络计费系统必须有一个明确的处理规则。我在项目里见过两派做法：一派是严格按照实付金额折算，付多少钱就给多少时长；另一派是只要支付成功就按套餐标准激活，差额由平台补贴或者走营销预算。两种做法都有道理，但不管选哪种，规则必须写死在系统里，不能让运营人员每次遇到都手工处理。

WiFi网络计费系统的支付对接还有一个经常被遗忘的环节——财务对账。很多人觉得对账是财务系统的事，跟计费系统没关系。但实际上，每天的对账结果是否一致，直接决定了运营团队对这个系统的信任度。

一套合格的WiFi网络计费系统，至少应该有每日自动对账的功能：拿本系统的订单数据和支付平台的账单数据进行逐条比对，标记出差异项，生成对账报告。这项工作如果靠人工来做，量小的时候还能应付，一旦日订单量破百，人工对账的成本就会迅速膨胀。

只要涉及到在线支付，退款和争议就不可避免。WiFi网络计费系统在处理退款的时候，不能只是简单地把订单状态改成"已退款"，还要同步处理两件事：第一，通知RADIUS或者NAS把对应用户的会话断开；第二，根据已使用时长按比例折算应退金额。

第二点特别容易出错。比如用户买了一个月卡，用了三天以后要求退款。如果你的计费系统只能退全款或者不退，那既不合理也不符合监管要求。合理的做法是按天数折算——但折算公式要提前定义好，是按自然天还是按24小时为一个单位，都要有明确的规则并且能体现在财务对账里。

最后提一下安全。WiFi网络计费系统跟支付系统对接的时候，有几个安全底线是绝对不能突破的：支付回调接口必须是HTTPS的、必须验证签名、必须做金额校验（防止金额被篡改）、必须做幂等处理（同一个订单号不能激活两次）。这些虽然都是常规的安全措施，但实际项目中漏掉其中任何一项都会带来严重的事故风险，而且是那种一旦出事就非常难追回的风险。支付对接本质上是跟钱打交道，跟钱打交道的事情容错率极低。一封投诉邮件、一条微博曝光、一次对账的巨额差异，都可能在短时间内对业务造成不可逆的信任损失。与其上线以后到处救火，不如在系统设计阶段就把双保险机制、套餐映射规则、对账流程和退款处理逻辑全部想清楚并且落实到位。