承诺一
一个清楚的入口
商户不再分别理解多个平台的接入方式；平台仍保留各自的业务职责。
这项设计要解决什么
把 WebPay Inbox、BPS、Zero Confirmation 及未来支付平台的商户入口统一起来，同时让每一次访问都能说清楚：谁在访问、从哪里来、能做什么、应被送往哪里，以及出问题时如何止损。
承诺二
权限必须说得清楚
每把 API Key 都明确对应来源网络和可执行的操作，默认不授予未声明的访问。
承诺三
故障不盲目扩大
系统不会为了可用性把支付写请求随意重放到其他地域；交易一致性仍由支付平台负责。
承诺四
变更与风险可追溯
权限、来源网络、路由和紧急封禁都有明确的发布与审计边界，便于定位和复盘。
承诺五
未来平台可按标准接入
新平台通过登记路由、权限和验证清单加入，不需要重写核心认证和安全规则。
一次请求如何被安全、可控地送达
只展示责任路径：规则在请求前发布，证据在处理后沉淀。缓存、数据库和地域细节留在对应主题页说明。
flowchart TB
RULES["已发布的规则<br/>谁可访问 · 送往哪里 · 紧急拒绝"]
subgraph REQUEST["一次商户请求"]
direction LR
MERCHANT["商户系统<br/>发起受保护的请求"] --> GATEWAY["统一 API Gateway<br/>安全接入 · 权限确认 · 按规则交付"] --> PLATFORM["支付平台<br/>WebPay Inbox · BPS · Zero Confirmation"]
end
AUDIT["审计与可观测性<br/>追踪 · 告警 · 复盘"]
RULES -.->|"请求前生效"| GATEWAY
GATEWAY -.->|"记录关键结果"| AUDIT
classDef external fill:#F7F9FC,stroke:#8A9AAF,color:#18212F,stroke-width:1.5px
classDef gateway fill:#EAF2FF,stroke:#1264D6,color:#12345B,stroke-width:2px
classDef support fill:#EDF8F3,stroke:#16835E,color:#124D3B,stroke-width:1.5px
class MERCHANT,PLATFORM external
class GATEWAY gateway
class RULES,AUDIT support
style REQUEST fill:#F8FBFF,stroke:#B8CDEA,stroke-width:2px
当前需要共同确认的事项
这是一份设计建议，不是生产就绪声明。下列决定需要业务、平台和运营团队共同给出事实输入。
平台能力
确认各平台的路由、读写语义、幂等能力、超时和故障转移约束。
商户接入
确认商户出口网络条件、Key 创建责任和高风险权限的审批方式。
基础设施
确认生产地域、数据驻留、现有入口保护、密钥管理和消息分发能力。
风险偏好
确认支付写请求使用的持有证明方式，以及读取与故障转移可接受的边界。
按你的角色阅读
不必从头读到尾。下面每页只承载一个清楚的责任边界或交付主题。
适合：业务负责人、产品负责人、平台负责人
背景与范围
说明为什么要建设统一入口、它要解决哪些业务问题，以及哪些职责不由网关承担。
适合：架构、平台、网络与安全团队
系统架构
从整体责任边界出发，说明请求如何安全进入一个合格地域，以及各类组件各自负责什么。
适合：安全、商户运营、平台研发团队
权限与安全
展开 API Key、来源网络、权限范围、重放防护和日志保护，明确默认拒绝的授权规则。
适合：网关研发、支付平台研发、测试团队
请求执行
说明已授权请求如何经过流量保护、写入安全门禁和后端调用，并保持稳定的对外语义。
适合：架构、平台、运维与合规团队
流量路由
说明策略如何由配置发布链路提供，并分别指导入口地域与认证后后端的选择。
适合：管理后台、SRE、安全运营团队
配置与运营
说明配置事实源、管理接口、本地域快照、紧急封禁和缓存一致性的责任边界。
适合：SRE、风控、测试、项目管理团队
可靠性与验收
聚焦审计证据、服务目标、容量输入和验证门禁，定义上线前如何证明系统可靠。
适合：项目负责人、架构评审者、业务与工程决策者
推进与决策
汇总实施阶段、已知风险、待确认事项、架构决策记录与会诊结论。