支付接入自检表：上线前的逐项核对

支付接入最容易出问题的地方，不是写不出调用代码，而是配置项散落在多个地方、异常分支没人走过、上线后才发现某个环节缺了兜底。把接入当成一次交付，用一张自检表逐项打勾，比反复口头确认可靠。

一、配置层：把会变的东西集中登记
先列出所有需要人工填写或后台配置的项：商户身份标识、密钥与证书、回调地址、超时时间、币种与金额精度、可用的支付方式开关、退款权限。每一项都记录三件事：当前值、存放位置、谁负责更新。密钥类信息不要写进代码仓库，也不要散落在聊天记录里，统一放进受控的配置管理。检查金额单位是否统一，是分还是元，前后端与对账口径必须一致，这是最常见的一类低级错误。回调地址要区分测试与生产，且必须是外部可访问的地址，不能是本地回环。

二、流程层：把主链路走完整
按用户视角走一遍：下单、跳转或唤起、支付完成、回跳、结果确认、订单状态落库。每一步都要确认状态从哪来、以谁为准。结论是：前端回跳只作为体验提示，订单最终状态必须以服务端主动查询或异步通知为准。异步通知要能处理重复投递，做幂等；要能处理乱序，用状态机约束合法迁移；要能在通知丢失时由定时查询补偿。支付方式多于一种时，逐个走通，不要只测其中一条。金额边界要覆盖最小值、常规值、含小数位的值。

三、异常层：把没人愿意走的路走一遍
列一张异常清单：用户中途取消、支付成功但回跳失败、通知延迟、通知重复、网络超时、下游返回未知状态、退款部分成功。对每一种写出预期行为与兜底手段。超时不能简单判失败，应进入待确认状态并触发查询；未知状态不能直接改订单，要有对账任务兜底。日志要能凭一个订单号串起全链路，敏感字段脱敏。告警要覆盖通知失败率、查询补偿积压、退款异常。

四、合规与运营层：留下可追溯的记录
确认用户可见的金额、币种、退款说明与实际一致；确认退款、撤销等操作的权限边界与审批留痕；确认对账文件能按周期生成并核对差异。上线前做一次演练：模拟通知丢失与重复，观察系统是否自愈。上线后头几天盯住失败率与差异单，把处理过程记录成文档，供后续复用。

使用建议：把这张表放进发布流程，作为阻断项而非参考项；每次接入新支付方式时复制一份，只改差异部分；每季度回看一次，把踩过的坑补进异常清单。