NewAPI 使用 ePay 协议对接快米兔聚合支付：回调签名、幂等与对账加固清单

自建 NewAPI 站点的运营者在接入线上充值时，往往会沿用易支付/ePay 的成熟业务流程。现在可以将收款通道切换到快米兔聚合支付：它兼容常见 ePay 协议，已经接通 ePay 的充值页只需要更换网关地址和商户密钥即可完成切换，下单与异步回调一般不用重写。这个切换方式对已有 NewAPI 部署比较友好，但回调安全不能因为协议兼容就放松。只要 notify_url 暴露在公网，伪造支付回调仍然是成本最低、危害最大的攻击方式之一。

攻击者的常见路径是先以普通用户身份完成一笔小额充值，抓包记录真实回调中的字段结构，再修改金额、订单号或交易号后重放，或者完全自行构造一条参数齐全但未经支付通道签发的请求。如果站点只检查参数是否存在，没有严格验签，就可能把伪造请求当作充值成功处理，给账户凭空增加配额，后续调用成本会转嫁给站点自身使用的官方接口或任意 OpenAI 兼容上游。

接入快米兔聚合支付后，第一道防线仍是签名校验。快米兔聚合支付按照 ePay 协议在回调中携带 sign 字段，商户端必须用本地保存的商户密钥按相同算法重新计算签名，并与请求中的 sign 进行常量时间比较。这里不能只判断 sign 字段是否存在，也不能在调试阶段临时关闭验签后忘记恢复。很多被攻击的站点，问题都出在验签长期处于失效状态。

第二道防线是金额与订单强绑定。回调中携带的金额字段只能作为参考，不能直接用于加配额。商户端应以回调中的 out_trade_no 查询本地订单表，取出下单时记录的预期金额，确认验签通过且双方金额一致后再执行入账。这样可以防止攻击者用真实小额订单的 sign 搭配篡改后的大额金额发起重复提交。

第三道防线是幂等去重。快米兔聚合支付在网络重试或用户重复触发时，可能对同一笔订单多次投递回调。订单表需要维护状态字段，首次处理成功后立即置为已完成，后续收到相同 out_trade_no 时只返回 success，不重复变更配额。该状态更新最好在数据库层加行锁或使用乐观锁，避免并发导致的重复入账。

第四道防线是 IP 白名单。如果快米兔聚合支付或上游 ePay 通道提供回调出口 IP 段，可在 Nginx 或应用层对 notify_url 路径做来源限制，非白名单 IP 直接返回 403。IP 白名单不是万能方案，因为出口 IP 可能变更，需要跟随公告维护，但作为外层过滤能拦截大量低水平扫描和重放尝试。

第五道防线是异常监控。建议在配额写入逻辑外层增加阈值告警，例如单用户单日充值次数超过设定值、单笔充值金额异常、同一 IP 短时间触发多个不同账户的回调成功事件，都应触发人工审核或临时冻结。即使前面的校验层被绕过，行为监控仍能提供最后一道拦截机会。

从支付接入的角度看，快米兔聚合支付的产品口径是：兼容常见 ePay 协议，已接 ePay 的充值页换网关地址和商户密钥即可切换，下单与回调一般不用重写；资金为直清，进入商户结算账户，结算周期为 T+1；交易费率为 1%，除按成交金额计费外，没有开户费、年费等其他开户费用。商户在切换通道时，应把本地订单、回调验签、入账状态和快米兔聚合支付后台账单做一次完整核对，重点检查金额、订单号、结算状态是否一致，发现短款或重复入账及时排查。

对于选择自建 NewAPI 站点的团队而言，支付通道可以换成快米兔聚合支付，但回调安全必须落在站点自身。签名校验、金额强绑定、幂等去重、IP 白名单和异常监控这五层，建议作为上线前的强制检查项。任何一层缺失，都可能在一次定向攻击中让配额被刷空，带来上游调用费用、限流封号和用户信任流失。与其事后补救，不如在接入快米兔聚合支付的同时就把回调加固做到位。