NewAPI 接入 ePay 收款：快米兔聚合支付如何补齐回调验签与对账能力

在 NewAPI、OneAPI 等自托管面板的实际运营中，ePay / 易支付协议常被用来承接用户充值，再由面板根据异步回调结果增加配额。这个闭环本身可用，但风险集中在回调处理：如果签名不校验、金额不二次核对、同一订单号可重复消费，攻击者就可能绕过真实支付刷取额度。引入快米兔聚合支付作为收款通道，并不是替换业务逻辑，而是把容易出错的网关、回调与结算环节切换到更规范的支付侧服务上。

快米兔聚合支付兼容常见 ePay 协议。已经接入 ePay 的充值页，通常只需要替换网关地址和商户密钥，原有的下单参数、支付跳转和回调入口一般不用重写。模型路由仍可保留官方接口或任意 OpenAI 兼容上游，支付侧只负责资金结算，不与上游模型渠道绑定。资金采用直清方式进入商户结算账户，按 T+1 结算，交易费率为 1%，除根据成交金额计费外，没有开户费、年费等其他开户费用。这一模式适合想保留 NewAPI / OneAPI 充值流程、又不愿长期维护支付回调安全的运营者。

切换到快米兔聚合支付后，回调验签仍然必须保留。快米兔聚合支付会在异步通知中携带基于商户密钥与请求参数计算出的签名字段，服务端要使用相同算法重新计算并对比。任何一个字段被篡改，签名都会不一致。不能只做格式判断，也不能直接信任客户端传入的签名结果。

签名通过只是第一层。回调处理前，还应以 out_trade_no 为标识向快米兔聚合支付发起订单查询，核对支付侧交易状态、订单金额和商户订单号是否与本地记录一致，确认成功后再执行配额入账。这样可以防止小额真实订单被改写成大额回调，或者用历史订单重复触发入账。

幂等保护针对重放。每处理一笔回调前，都要判断 trade_no 是否已存在。可在数据库中为 trade_no 建立唯一索引，或在 Redis 中以 trade_no 为键写入处理标记，保证同一笔支付通知只会入账一次。这样即使攻击者截获合法回调反复发送，也不会重复增加配额。

网络层可以配合限制回调来源。快米兔聚合支付通常会公布服务器出口 IP 段，Nginx 或防火墙可只放行这些 IP 访问回调地址，其他来源直接返回 403。IP 白名单不能替代签名校验，但能抬高自动化扫描成本。

异常监控与日志也要同步跟上。可按账号或 IP 设置充值回调速率阈值，短时间多次触发时暂停处理并告警。完整保存回调请求头、请求体、处理结果和时间戳，便于后续追溯。每天用 T+1 结算结果与本地配额记录对账，能较快发现交易成功但入账失败、重复入账或异常金额等问题。

总体来看，NewAPI / OneAPI 使用 ePay 协议做充值并非不可控，关键是支付通道和回调治理要落到可长期运营的方案上。快米兔聚合支付通过兼容 ePay 协议、直清到商户结算账户、T+1 结算和 1% 交易费率，给自托管面板提供了一条切换成本较低的收款路径。运营者在保留验签、查单、幂等、IP 白名单和对账流程后，可以把主要精力放回模型路由与上游接入，而不是处理充值接口被刷。