顾客已经付款，业务系统却没有更新；同一张订单又被重复发货。这两类问题看似相反，往往都与支付结果处理有关。可靠的回调处理需要把来源验证、业务核对、状态更新和应答组织成完整流程。
回调和页面跳转有什么区别？
本站支付结果通知包含服务器异步通知 notify_url 与页面跳转通知 return_url。异步通知用于服务器之间传递结果，页面跳转用于把顾客带回业务页面。
页面可能没有成功打开，也可能被重复访问。发货、会员开通或预约确认应以服务器完成核验后的结果为依据。回跳页可以查询并展示当前业务订单状态，但不应仅凭地址中的参数直接改变订单。
先验签，再处理订单
本站当前文档使用 RSA 签名规则。请求由商户私钥签名，接口响应和异步通知使用平台公钥验签，算法为 SHA256WithRSA。用于签名的参数排序、非空值处理以及排除字段，应与接入文档保持一致。
不要只取几个熟悉的字段拼接验签字符串。文档明确要求兼容新增回调字段；遗漏参与签名的扩展字段可能导致合法通知也无法通过验证。可以优先对照 SDK 与签名文档处理，而不是在业务代码里维护一份不完整的字段列表。
验签失败时不执行交付。日志记录订单标识、请求时间和失败环节即可，不应写入商户私钥或将完整敏感配置暴露给前端。
验签通过后还要核对什么？
- 商户：通知中的
pid是否对应当前商户配置。 - 订单：
out_trade_no是否属于本业务，trade_no是否与已有记录一致。 - 金额：
money是否与订单应付金额相符。金额比较宜使用整数分或准确的十进制运算。 - 状态：按文档检查
trade_status是否为TRADE_SUCCESS，再进入已支付处理。
合法签名能够证明通知的数据来源与完整性，但不能代替业务归属检查。商户、订单或金额不匹配时，应保留异常记录并进一步核对。
同一结果处理多次，也只交付一次
幂等处理指的是：同一笔付款结果重复到达，最终只产生一次预期的业务变化。可以用商户订单号建立唯一约束，并通过数据库事务或条件更新，把“待支付”变为“已支付”与交付任务的登记一并持久化。
例如，第一次合法通知将订单更新为已支付并登记发货任务；后续相同通知只确认已处理状态，不再次扣库存或创建发货任务。若交付依赖外部服务，可采用可靠任务队列，持续跟进任务结果，避免把网络调用塞进无法恢复的临时步骤。
文档要求收到异步通知后返回 success。应在核验通过且必要状态可靠保存后应答。不要在业务更新之前就返回成功，也不要把调试文字、整段 HTML 或错误栈混入应答正文。
用查询补齐状态差异
对于长时间待支付、顾客反馈已付款或通知处理异常的订单，可由服务器调用订单查询接口，验签后再次核对商户、订单与金额，再通过同一套幂等逻辑更新状态。查询补偿不应绕开已有核验规则。
上线验证应覆盖合法通知、签名错误、金额不符、重复通知和暂未收到通知等情况。保留可检索的订单号、处理结果与时间，才能把偶发问题变为可以追踪的记录。