上线检查清单

A 账号与团队 0/5B 生产 API Key 0/6C Webhook 0/7D 回跳地址 0/2E 幂等与重试 0/4F 结果未知 0/4G 金额与币种 0/2H 卡数据与日志 0/5I 错误处理 0/3J 3DS 与收银台 0/3K 对账 0/3L 收款账户 0/1M 退款与争议 0/2N 运维与监控 0/3

• A 账号与团队

  A1所有者、管理员、财务、开发者都已绑定 MFA各自在商户后台「登录安全」绑定身份验证器在哪里：登录安全（在新标签页打开商户后台）A 账号与团队 · 所需角色：各成员本人 · 为什么 具有生产密钥或资金权限的人员必须开启 MFA
• A2成员角色符合最小权限开发者不持有资金权限；只读人员按需开启“可查看资金”（「员工」页面）在哪里：员工（在新标签页打开商户后台）（需要所有者或管理员）A 账号与团队 · 所需角色：所有者、管理员 · 为什么 最小权限
• A3至少有一名管理员可在所有者不在时处理事务「员工」页面确认在哪里：员工（在新标签页打开商户后台）（需要所有者或管理员）A 账号与团队 · 所需角色：所有者、管理员 · 为什么 避免单点；最后一名所有者不能被删除
• A4离职人员已停用，其生产密钥已处理「员工」页面停用；「API Key」页面“待复核密钥”中撤销或转交在哪里：员工（在新标签页打开商户后台）（需要所有者或管理员）、API Key（待复核密钥）（在新标签页打开商户后台）（需要所有者、管理员或开发者）A 账号与团队 · 所需角色：所有者、管理员 · 为什么 不能留下无人负责的密钥
• A5通知联系人已填写（技术、财务、争议、业务）「通知联系人」页面在哪里：通知联系人（在新标签页打开商户后台）A 账号与团队 · 所需角色：所有者、管理员 · 为什么 Webhook 失败、争议、结算等通知能送达

• B 生产 API Key

  B1平台已为你开通生产环境在后台顶栏切换到“生产”，能看到数据页而不是“生产环境尚未开通”B 生产 API Key · 为什么 生产由平台在开通检查通过后激活
• B2在生产环境创建 Key 并立即存入密钥管理服务所有者或管理员在「API Key」页面创建（需二次认证）；完整密钥只显示一次在哪里：API Key（在新标签页打开商户后台）（需要所有者、管理员或开发者）B 生产 API Key · 所需角色：所有者、管理员 · 为什么 密钥只展示一次
• B3按系统拆分 Key、只授予需要的权限范围例：收款服务 payments:read + payments:write；退款服务 refunds:read + refunds:write；对账任务只给 finance:read在哪里：API Key（在新标签页打开商户后台）（需要所有者、管理员或开发者）B 生产 API Key · 所需角色：所有者、管理员 · 为什么 最小权限
• B4配置 IP 白名单为你的服务器出口 IP「API Key」页面创建或编辑时填写在哪里：API Key（在新标签页打开商户后台）（需要所有者、管理员或开发者）B 生产 API Key · 所需角色：所有者、管理员 · 为什么 限制密钥只能从你的服务器使用
• B5有轮换计划并演练过紧急撤销轮换重叠期不超过 24 小时；撤销后 60 秒内阻断（见本页“轮换 API Key”）在哪里：轮换 API KeyB 生产 API Key · 所需角色：所有者、管理员、开发者 · 为什么 密钥泄漏时能快速止损
• B6生产 Key 不出现在前端、App、代码仓库、CI 日志；测试与生产 Key 分开配置你的配置与密钥管理B 生产 API Key · 为什么 服务端密钥只能用于服务端

• C Webhook

  C1生产端点已配置（HTTPS、公网可达、不重定向）并订阅所需事件「Webhook 配置」页面（修改需二次认证）在哪里：Webhook 配置（在新标签页打开商户后台）（需要所有者、管理员或开发者）C Webhook · 所需角色：所有者、管理员、开发者 · 为什么 平台只向 HTTPS 公网地址投递，不跟随重定向
• C2生产签名密钥已立即单独存入密钥管理服务（遗失只能轮换）；验签实现通过测试向量（整串密钥含 whsec_ 前缀）Webhook 文档“测试向量”小节在哪里：测试向量C Webhook · 为什么 签名密钥只在创建端点与轮换时显示一次
• C3300 秒时间容差、常量时间比较、先验签再解析；服务器时钟 NTP 同步你的接收端C Webhook · 为什么 防重放与时序攻击
• C4按事件 ID 持久化去重；按 version 处理乱序；不认识的事件类型返回 2xx你的接收端（Webhook 文档“最佳实践”）在哪里：接收方最佳实践C Webhook · 为什么 至少一次、无序投递
• C55 秒内应答、业务异步；Webhook 路由不经过登录跳转与 WAF 拦截你的接收端与网关C Webhook · 为什么 超过 5 秒判定超时并重投
• C6在生产环境发送一次测试事件并看到成功「Webhook 配置」页面发送测试事件，「事件投递记录」页面查看结果在哪里：Webhook 配置（在新标签页打开商户后台）（需要所有者、管理员或开发者）、事件投递记录（在新标签页打开商户后台）（需要所有者、管理员或开发者）C Webhook · 所需角色：所有者、管理员、开发者 · 为什么 测试发送不产生真实业务
• C7投递失败有人接收通知，有补齐遗漏事件的流程技术联系人能收到投递失败通知；用 GET /v1/events/{event_id} 补齐在哪里：补齐遗漏事件C Webhook · 为什么 最终失败的事件不会再自动投递

• D 回跳地址

  D1生产域名下的 return_url、cancel_url 已登记「回跳地址」页面在哪里：回跳地址白名单（在新标签页打开商户后台）（需要所有者、管理员或开发者）D 回跳地址 · 所需角色：所有者、管理员、开发者 · 为什么 未登记的地址会被拒绝
• D2return_url / cancel_url 页面只展示，由服务端查询状态；不依据 URL 参数履约你的页面（3DS 与托管收银台文档“履约规则”）在哪里：履约以服务端状态为准D 回跳地址 · 为什么 浏览器回跳可以被伪造

• E 幂等与重试

  E1所有写请求都带 Idempotency-Key，并在发送前持久化你的支付服务（幂等文档“生成与保存幂等键”）在哪里：生成与保存幂等键E 幂等与重试 · 为什么 重试时才能复用原键
• E2网络重试复用原键；只有换卡等新提交才用新键同上在哪里：生成与保存幂等键E 幂等与重试 · 为什么 换键重试可能重复扣款
• E3正确处理 409、429（Retry-After）与 503 temporarily_unavailable409 payment_in_progress：查询原支付；409 idempotency_conflict：属于集成缺陷，先确认原请求的结果，修复幂等键的生成并告警；不要改参数后重放原键，也不要为了绕过冲突直接换键重试；429：按 Retry-After 等待后用原键重试；503 temporarily_unavailable：本次未受理，稍后用原键重试在哪里：错误码E 幂等与重试 · 为什么 不同的 409 处理方式不同，为绕过冲突换键重试可能重复扣款
• E4创建、确认支付的客户端超时不少于 20 秒你的 HTTP 客户端E 幂等与重试 · 为什么 平台同步等待上游约 15 秒

• F 结果未知

  F1202、processing、超时、5xx 时向付款人显示“正在确认支付结果”，不判失败你的页面与订单状态机（503 temporarily_unavailable 除外：本次未受理，提示稍后再试）F 结果未知 · 为什么 结果未知不等于失败
• F2代码中不存在“超时后换键或换订单号重新扣款”的路径代码评审F 结果未知 · 为什么 避免重复扣款
• F3有按支付号或商户订单号查单的兜底任务，频率符合建议幂等文档“查单频率”在哪里：查单频率F 结果未知 · 为什么 Webhook 可能延迟或遗漏
• F4manual_review 的订单有人工跟进流程超过 24 小时未确认时联系平台技术支持F 结果未知 · 为什么 超过自动查询窗口转人工，平台不会自动判失败

• G 金额与币种

  G1金额按币种小数位换算为最小货币单位整数，不用浮点；USD、JPY 等已验证快速开始“关键规则”在哪里：关键规则G 金额与币种 · 为什么 USD 10000 = 100.00，JPY 10000 = 10,000
• G2只使用已为你启用的币种；你的报表不跨币种相加「基本信息」页面查看能力与币种在哪里：基本信息（在新标签页打开商户后台）G 金额与币种 · 为什么 不同币种的金额不能相加

• H 卡数据与日志

  H1生产已开通直接传卡能力，你已评估并满足自身的卡数据安全义务联系平台运营确认H 卡数据与日志 · 为什么 直接传卡需要平台单独开通
• H2卡号、有效期、CVC 不写入你的数据库、日志、队列、错误上报、分析工具；请求体日志已脱敏你的日志与 APM 配置H 卡数据与日志 · 为什么 卡数据安全
• H3description、metadata 不含卡号等敏感信息你的下单代码H 卡数据与日志 · 为什么 命中会被平台拒绝
• H4认证地址与收银地址不记录、不分享、不放进你自己页面的 URL你的前端与日志配置（3DS 文档“处理跳转”）在哪里：处理认证跳转H 卡数据与日志 · 为什么 地址中带有短时凭据
• H5你的页面上没有收集卡号的表单前端代码评审H 卡数据与日志 · 为什么 托管收银台由平台采集卡信息

• I 错误处理

  I1按 error.code 编程，容忍未知错误码、未知状态、未知事件类型错误码文档、API 参考“兼容性”在哪里：错误码、兼容性约定I 错误处理 · 为什么 平台会以兼容方式新增取值
• I2每次请求记录 request_id你的日志；排查时在「API 调用记录」页面查询在哪里：API 调用记录（在新标签页打开商户后台）（需要所有者、管理员或开发者）I 错误处理 · 所需角色：所有者、管理员、开发者 · 为什么 技术支持据此定位
• I3向付款人展示脱敏的 failure.message 或你的通用文案，不展示内部错误你的页面I 错误处理 · 为什么 不泄漏内部信息

• J 3DS 与收银台

  J1requires_action 时整页跳转 next_action.url，并处理过期与关闭页面3DS 文档“处理跳转”在哪里：处理认证跳转J 3DS 与收银台 · 为什么 认证必须由付款人在浏览器完成
• J2浏览器信息来自付款人真实浏览器；付款人 IP 按受信代理链获取3DS 文档“浏览器信息”在哪里：浏览器信息采集J 3DS 与收银台 · 为什么 不能用服务器信息替代
• J3收银台 locale 按你的用户语言设置创建收银会话时传入J 3DS 与收银台 · 为什么 付款人看到熟悉的语言

• K 对账

  K1有每日对账流程用 listPayments、listRefunds、listBalanceTransactions、listSettlements（finance:read 专用 Key）或「对账单与报表」核对你的订单系统在哪里：对账单与报表（在新标签页打开商户后台）（需要所有者、管理员或财务）K 对账 · 所需角色：所有者、管理员、财务 · 为什么 及时发现差异
• K2财务理解 7 个余额桶与结算单 S、F、S − F，按币种分别对账「余额概览」「结算单详情」页面在哪里：余额（在新标签页打开商户后台）（需要所有者、管理员或财务）、结算单（在新标签页打开商户后台）（需要所有者、管理员或财务）K 对账 · 所需角色：所有者、管理员、财务 · 为什么 只有 available 可用于打款
• K3结算单生成与打款结果有人跟进settlement.* 事件或站内 / 邮件通知；需要时按结算单的 payout_id 调用 getPayout 查询K 对账 · 为什么 打款结果未知时平台先查证

• L 收款账户

  L1收款账户状态为“生效中”所有者在「收款账户」页面提交（二次认证）→ 平台审核 → 冷静期（至少 24 小时）→ 生效；未生效时不会生成结算单在哪里：收款账户（在新标签页打开商户后台）（需要所有者、管理员或财务）L 收款账户 · 所需角色：所有者 · 为什么 账户变更有冷静期

• M 退款与争议

  M1明确谁可以发起退款，团队了解退款默认人工审核、资金不足会提示差额所有者、管理员、财务可发起在哪里：支付订单（在新标签页打开商户后台）M 退款与争议 · 所需角色：所有者、管理员、财务 · 为什么 生产退款默认人工审核
• M2争议联系人已设置，团队知道在哪里上传材料与证据截止时间「争议」页面在哪里：争议（在新标签页打开商户后台）M 退款与争议 · 所需角色：所有者、管理员、财务 · 为什么 错过截止时间会影响结果

• N 运维与监控

  N1监控 API 错误率与耗时、Webhook 失败「API 调用记录」「事件投递记录」页面；你的监控系统在哪里：API 调用记录（在新标签页打开商户后台）（需要所有者、管理员或开发者）、事件投递记录（在新标签页打开商户后台）（需要所有者、管理员或开发者）N 运维与监控 · 所需角色：所有者、管理员、开发者 · 为什么 尽早发现问题
• N2能收到 API Key 即将过期的提醒失效前 7 天、1 天发送提醒N 运维与监控 · 为什么 避免密钥过期导致中断
• N3有联系平台技术支持的渠道与上报模板提供 request_id、时间（带时区）、环境、对象 ID；不提供密钥与卡号在哪里：联系技术支持N 运维与监控 · 为什么 快速定位问题