支付平台扣款后会把结果回调到订单服务。网络超时触发重试，或有人截获旧请求重复提交，同一通知就可能抵达两次。若接口每次都加余额、创建订单，正确签名也挡不住重复业务。因此不仅要验明真假，还要确认来源真实性、请求新鲜度和业务唯一性。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：agiletechsolutions（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
从请求头取出时间戳、事件标识和签名，按双方约定用服务端密钥对“时间戳.事件标识.原始请求体”计算 HMAC-SHA-256，并与请求头签名做恒定时间比较。必须使用原始请求体，不能解析 JSON 后重新序列化；字段顺序、空格变化都会造成差异。结果也不能用普通字符串直接比较，以免泄露可计时推测的信息。
签名只能证明报文由持钥方生成，不能让旧报文失效。因此还要检查时间戳有效期与服务器时间的差值，例如仅接受最近 60 秒的请求，并预留少量时钟偏差。窗口过短会误伤正常回调，过长则扩大重放机会，应按业务延迟设定并监控拒绝量。
旧通知即使仍在时间窗口内，也可能被立即重放。可信来源应提供稳定、唯一的事件标识；没有时可用原始请求体摘要作候选键，但要评估正文变化和碰撞风险。接收时先验签，再判断是否处理过。不要“先查、未查到再写入”，并发会同时通过检查。应按来源和事件标识建立数据库唯一约束，以插入或条件更新原子地抢占处理权，冲突时返回已接收，不再执行业务。
业务写入还需要幂等键。订单回调可用支付流水号关联，入账设置流水号唯一约束，状态只允许从待支付转为已支付。事件标记与业务结果应处于同一事务；队列消费需持久化去重记录或启用去重能力，不能把“已验签”当成“已处理”。
可检查四点：签名是否基于原始字节并恒定时间比较？时间窗口是否符合延迟且可观测？事件标识是否有唯一约束？业务表是否另有幂等键？任一项缺失，正常重试或攻击者都可能重复写入。还应防范密钥泄露、请求头被改写、时间戳单位混用。ServLlama 可记录回调摘要、处理状态和关联流水辅助排查，但日志不能替代数据库约束。
签名只能证明报文由持有密钥的一方生成，不能证明它是刚刚发送的。接收端应读取请求头中的时间戳，与服务器当前时间比较，超出允许偏差就直接拒绝，例如将有效期设为 300 秒。时间戳过旧可能意味着重放，明显位于未来也可能是在绕过校验，二者都不应放行。实际窗口要覆盖正常网络延迟和任务排队时间，同时保留足够的服务端时间校准余量。
计算 HMAC报文签名 时，要对未经解析、未经重新序列化的原始请求体执行摘要。只验签不校验时间戳，或先解析 JSON 再计算签名，都会留下重放与格式转换漏洞。签名比较应采用恒定时间函数，避免攻击者通过响应耗时逐字节猜测；缺失签名、长度异常、时间戳非法和校验失败应返回一致的错误，并写入安全日志。还要确认反向代理没有改写请求体、字符集或参与签名的请求头。
时间戳窗口只能缩小重放范围，不能替代事件去重。接收端应提取稳定的事件标识，例如事件唯一 ID 或投递 ID，并在数据库中建立唯一约束。处理前先检查该标识是否已经写入；重复事件直接返回成功，不再执行业务逻辑。若旧系统没有事件 ID，可由事件类型、对象标识、版本号和时间字段组合生成幂等键，但必须评估字段变化与并发冲突。
幂等写入要求同一事件无论投递多少次，都只能产生一次业务效果。创建订单、扣减余额、发送通知等操作应使用唯一键、条件更新或事务，不能仅依靠“先查询、再插入”，否则并发请求仍可能写入重复数据。事件状态应与业务结果绑定，并记录处理中、成功或失败，防止进程在处理过程中退出后无法判断事件是否已完成。失败事件可以有限重试，重试间隔应逐步增加，避免故障恢复瞬间形成流量尖峰。
回调重放窗口应覆盖客户端最长的重试周期和服务端异步任务队列的存活时间。客户端可采用指数退避，在五分钟、十分钟、三十分钟等时间点重试；服务端则应至少保留同等时长的去重记录。若业务要求更长时间内可追溯，可以把去重记录归档或转入长期存储，而不能只依赖内存缓存和单机锁。多实例部署时，数据库唯一约束比本地锁更可靠。
上线前逐项确认：请求体是否保持原始字节；HMAC报文签名是否覆盖时间戳与事件标识；时间戳有效期是否为明确数值并拒绝未来报文；是否拒绝旧时间戳；签名比较是否使用恒定时间函数；事件标识是否建立数据库唯一约束；重复投递是否不会重复扣款、创建订单或发送通知；客户端是否设置有限重试与退避；回调重放窗口是否大于最长重试周期；多实例、并发和进程重启场景是否仍然有效。最后使用过期报文、篡改报文、同一事件并发投递及处理中断后重试进行验证，并持续监控验签失败率、重复事件量、事件积压和重试次数。
