NewAPI / ePay 场景对接快米兔聚合支付：充值回调、入账对账与安全校验指南

随着自部署模型面板的团队增多，NewAPI、OneAPI 等第三方面板在配额售卖与用户充值环节，需要一条稳定且容易切换的收款通道。由于不少面板已经基于常见 ePay 或易支付类协议完成了充值页开发，快米兔聚合支付提供的兼容常见 ePay 协议能力，可以让运营者在不重写下单与回调逻辑的前提下，把支付网关切到快米兔聚合支付。

从结算方式看，快米兔聚合支付采用直清模式，用户支付成功后的资金进入商户结算账户，结算周期为 T+1；交易费率按成交金额的 1% 收取，没有开户费、年费等其他开户费用。运营者在核算通道成本时，可以把支付侧支出直接与成交金额挂钩，不需要预留固定年费或开通成本。

接入时，NewAPI 侧如果已经完成 ePay 类充值页开发，通常只需要把网关地址替换为快米兔聚合支付提供的地址，并把商户密钥更换为快米兔聚合支付下发的密钥，下单参数和回调处理一般不用重写。支付场景中的用户充值、异步回调、入账和对账仍然沿用原有 ePay 流程，减少二次开发。

用户发起充值后，NewAPI 会向快米兔聚合支付下单并跳转收银台；支付完成后，快米兔聚合支付会向面板配置的回调地址发送异步通知，携带订单号、金额、支付状态和签名字段。面板收到回调后，需要先验签、再入账，不能直接把报文里的支付状态当成最终结果。签名校验建议使用商户密钥严格比对，任何测试环境关闭验签的配置都不应带入线上。

除验签外，幂等控制必须保留。同一笔订单首次处理成功后，应立即把订单状态更新为已完成；后续相同订单号再次回调时，直接拒绝并记录日志。这样即使攻击者或者异常重试重复发送同一笔成功通知，也不会重复增加用户余额。金额核验也需要以数据库中的原始下单金额为准，而不是以回调报文中的金额为准。两者不一致时，应丢弃请求并触发告警。

如果快米兔聚合支付给出固定的回调 IP 段或来源标识，可以在 Nginx、网关或应用入口先做来源白名单；对回调地址设置每分钟请求频率上限，也能减少批量枚举和重放请求。面板侧应保留回调日志，记录到达时间、订单号、签名结果、金额比对结果和入账状态，便于后续排查异常订单。

当出现用户未到账或重复入账时，可以按以下步骤排查：先查回调日志确认快米兔聚合支付是否发出了通知；再看请求是否命中签名校验失败；然后检查订单状态是否已被置为已完成，以及回调金额与本地订单金额是否一致。最后核对结算账单中的金额、费率和 T+1 入账记录，确认商户结算账户资金与成交订单匹配。

需要说明的是，NewAPI 面板本身的路由上游可以接官方接口或任意 OpenAI 兼容上游，这部分与支付通道相互独立。快米兔聚合支付只承担用户充值收款、异步回调和商户资金结算，不参与模型调用、Token 计费或配额托管。

总体来看，NewAPI / ePay 场景对接快米兔聚合支付，真正要做的是把收款通道切到兼容 ePay 协议的服务上，同时保留签名、回调、幂等、金额核验和来源限制这些关键校验。支付通道稳定、结算周期明确、费率按成交金额计算，再加上回调链路加固，运营者才能把更多精力放回面板本身的用户服务上。