先区分“支付成功”和“业务到账”
创建订单接口返回成功，只能说明支付平台接受了请求并生成订单，不代表用户已经付款，更不代表商户系统已经收到有效通知。排查时要把状态分成四段：订单创建、用户付款、平台识别到账、商户业务更新。
先记录商户订单号、平台订单号、创建时间、应付金额、实际付款时间和当前状态。不要通过反复点击支付按钮制造多个相同订单，否则会增加对账难度。
第一步：检查订单创建结果
确认接口返回的订单号已写入本地数据库，金额单位和小数精度正确，回调地址是公网可访问的HTTPS地址。测试环境与正式环境的商户号、密钥和网关地址不能混用。
检查要点：商户订单号必须唯一且不可重复使用；金额应使用固定精度处理，避免浮点误差；服务器时间偏差过大可能导致签名或超时判断失败；回调地址不要依赖登录状态、Cookie或浏览器跳转。
第二步：确认平台是否识别付款
如果用户已付款但平台订单仍为待支付，应核对付款金额、收款渠道、到账时间和监控端在线状态。支付备注、金额尾数或收款码发生变化时，自动匹配可能失败。不要仅凭用户截图修改订单，应以收款账户的真实流水和平台订单记录为依据。
第三步：查看异步通知日志
平台订单已支付但商户订单未更新，重点检查回调日志。记录请求时间、来源、订单号、签名验证结果、HTTP状态码和响应正文，但日志中不要明文保存密钥、完整Cookie或其他敏感信息。
常见问题包括回调域名解析错误、HTTPS证书异常、防火墙拦截、CDN缓存动态接口、PHP报错以及处理超时。回调接口应快速完成验签和落库，再把耗时业务交给队列处理。
第四步：按协议重新计算签名
签名失败时，必须严格按照接口文档规定的字段集合、排序方式、字符编码和拼接规则计算。空字段是否参与、金额格式、URL编码以及密钥放置位置都可能影响结果。不要为了让回调通过而关闭验签，也不要只校验订单号。
第五步：保证回调幂等
支付平台可能重复发送通知，这是正常的可靠性机制。商户系统应以唯一订单号和当前状态作为幂等条件：未支付订单首次收到有效通知时完成入账；已支付订单再次收到相同通知时直接返回成功，不得重复发货、重复加余额或重复记账。
订单状态更新和权益发放最好放在同一个数据库事务中，或使用唯一流水号约束。仅依赖“先查询再写入”在并发请求下仍可能重复执行。
补单应该怎么做
补单前先主动查询平台订单并核对真实资金流水。人工补单需要记录操作者、时间、原因、原订单状态和关联流水，重要业务可增加复核。补单接口也必须幂等，不能绕过金额和商户校验。
排查清单
1. 核对本地订单号与平台订单号。
2. 确认实际付款金额、时间和收款渠道。
3. 检查平台状态及监控端是否正常。
4. 查看回调请求、验签结果和服务器错误日志。
5. 主动查询订单，确认后再执行安全补单。
6. 修复后模拟重复通知，验证不会重复入账。
个人网站接入收款能力时，应遵守当地法律、支付平台规则和账户使用要求，不得使用技术手段规避实名、风控或资金监管。业务规模扩大后，应优先使用适合自身资质的正规支付服务。
