码支付接入后，常见故障之一是用户已经付款，但业务系统的订单仍停留在“待支付”。这通常不是单一环节造成的，而是支付监控、通知请求、服务器接收和业务更新之间某一步没有完成。排查时应保留订单号、通知时间和原始日志，避免直接手工改状态掩盖真实原因。
一、先区分“未识别到账”和“回调未处理”
先在码支付后台确认该订单是否已经识别到账。如果后台也没有成功记录，应检查金额匹配、收款账户监控和订单有效期；如果后台显示支付成功，而业务网站仍未更新，则重点检查异步通知地址和业务处理逻辑。把两种问题分开，可以避免在错误方向上反复修改。
二、核对通知地址是否可以公网访问
通知地址必须是完整、稳定且可从公网访问的 URL。不要使用 localhost、内网 IP、临时测试地址或需要登录后才能打开的页面。确认域名解析已经生效，路径没有拼写错误，并避免把通知接口放在会被前端路由接管的位置。接口应支持平台使用的请求方法，并能正确读取约定参数。
三、检查 HTTPS 证书和跳转
证书过期、证书链不完整、域名不匹配，都会使通知请求在建立连接时失败。若 HTTP 自动跳转 HTTPS，还要确认跳转后不会改变请求方法或丢失参数。建议通知地址直接使用最终 HTTPS URL，减少 301、302 多次跳转带来的不确定性。
四、排查防火墙、CDN 与安全插件
Web 应用防火墙、CDN Bot 防护、频率限制和来源白名单可能误拦截通知请求。查看对应时间段的访问日志和拦截日志，确认请求是否到达源站。不要为了测试长期关闭全部安全防护，可以为准确的接口路径制定最小范围规则，同时保留签名校验和频率控制。
五、确认接口响应内容
通知接口完成验签和订单更新后，应返回平台要求的成功标识，并使用正确的 HTTP 状态码。若返回整页 HTML、登录页、PHP 报错、超时或 500 错误，平台通常会认为通知失败并重试。处理流程应尽量简短：先验签、校验订单、幂等更新，再返回成功；耗时任务可放入队列异步执行。
六、用日志定位失败环节
建议至少记录通知时间、商户订单号、平台订单号、金额、签名校验结果、处理结果和响应耗时。敏感密钥不能写入日志。排查时对照 Web 访问日志、程序错误日志和数据库订单记录：没有访问记录说明请求未到达；有访问但返回 4xx 或 5xx，说明路由、权限或程序异常；返回 200 但状态未更新，则继续检查验签和数据库事务。
七、必须做好幂等和补单
异步通知可能因为网络原因重复发送，因此不能把“收到一次通知”直接等同于“执行一次发货”。应以商户订单号建立唯一约束，只允许待支付订单转换为已支付；已完成订单再次收到相同通知时直接返回成功。补单操作也要校验真实到账记录、金额和订单归属，并留下审计记录。
常见问题
浏览器能打开通知地址，为什么仍收不到？
浏览器 GET 访问成功不代表平台的 POST 请求、参数格式和网络路径都正常。应以真实通知日志或安全的测试订单为准。
可以用固定 IP 白名单吗？
只有在平台明确提供并维护通知出口地址时才适合配置；否则地址变化可能造成误拦截。无论是否使用白名单，都不能替代签名、时间戳和订单金额校验。
总结
码支付回调排查应按“到账识别—公网连通—HTTPS—安全策略—响应内容—业务日志—幂等补单”的顺序进行。先用证据确定请求停在哪一层，再做最小修改，能够在避免重复发货的同时更快恢复订单自动更新。
