优先队列
支付回落、鉴权失败、批量报错先给临时绕行方案
全程值守
夜间与节假日照常接收，4 小时内确认工单已到
结论留痕
每个工单给出成因、处理动作与复测结果三项记录
接入过程中问得最多的六个问题
按提交频次整理，每条回答都给到可以直接上手的动作，而不是笼统的说明。
工作时间内提交的工单 2 小时内给出首次响应，夜间与节假日值守通道 4 小时内确认收到。涉及支付回落、鉴权失败与批量报错的工单进入优先队列，先给临时绕行方案，再约定修复时间点，全程留在同一个工单里跟进。
先确认请求时间戳与本机时间的偏差在 5 分钟以内，再核对参与签名的字段是否按字典序拼接、空值字段是否剔除。多数失败来自密钥取错环境，或者拼接时混入了多余的换行符与空格。
域名与协议不变、只调整路径的，在控制台保存即可生效，无需等待。更换域名、新增端口或改动协议需要重新提交审核，审核期间原地址继续可用，线上业务不受影响。
不能。两套环境分别签发凭证，密钥单独保存，互不通用。切换环境时先更新配置中心再发布版本，避免灰度节点连回旧环境产生脏数据；发现混用后立即在控制台重置密钥并复查最近一小时的请求。
提供接口直连、服务端 SDK 与网关转发三种方式。需要准备的包括一个可用的回调域名、对应的备案信息、回调路径，以及一台能够访问外网的服务端。其余参数在开通后按引导逐项填写，联调阶段可随时提工单核对。
保留订单号、请求流水与返回报文提交工单，按对账口径逐笔核对。确认后走冲正流程，通常一个工作日内回退到原路，同时附上防重复的处理建议，例如把幂等键下沉到业务侧生成并延长有效期。
提交之前，先走完这四步
把现场信息备齐，绝大多数问题在第一次回复里就能给出方向。
记录现场
留下请求时间、订单号、返回码与原始报文，后续判断都依赖这几项。
自检三项
密钥是否取错环境、时间戳偏差是否超过 5 分钟、签名拼接是否按字典序。
带证据提交
在工单里附上流水与截图，系统按异常类型分到对应队列，减少一轮往返。
先恢复再确认
按回复的临时方案恢复业务，等修复版本上线后复测一次并回写结果。
带上请求流水与返回报文，定位时间通常缩短一半以上。
联调建议提前对齐
双方各留一位对接人，统一用采集到的真实报文沟通，避免用截图转述字段名导致误判。
三类问题最容易反复出现
先看成因，再看处理动作，能省掉一次完整的排查回合。
签名、重试与对账，占了工单量的大头
这三类问题的共同点是：日志里看不出明显异常，但业务侧已经开始丢单或重复下单。处理时优先恢复链路，再回头补成因说明。
- 签名与时间戳 多环境共用一套密钥，切换时漏改配置。处理方式：按环境隔离密钥，发布前校验配置中心取值。
- 回调与重试 路径调整后未做连通性验证，重试全部落空。处理方式：改完先打一次测试通知，确认应答码再切流量。
- 对账与冲正 只核金额未核状态，出现状态不一致。处理方式：按订单号与流水双向比对，缺一边先补日志再判定。
