指南
微信支付接入两天，把派宝变成了 4 个项目的支付中转站
中国市场 SaaS 才有的一种架构变形——ICP 备案约束直接重塑了系统拓扑。微信/支付宝 notify_url 必须指向已 ICP 备案的域名，于是派宝成了整个家族的统一支付 webhook 入口。
先看答案
中国市场 SaaS 才有的一种架构变形——ICP 备案约束直接重塑了系统拓扑。微信/支付宝 notify_url 必须指向已 ICP 备案的域名，于是派宝成了整个家族的统一支付 webhook 入口。
关键事实
参考来源
最近复核
常见问题
为什么微信支付回调必须指向已备案域名？
在中国内地，支付宝和微信支付的商户后台要求回调地址使用已完成 ICP 备案的域名，未备案域名会被直接拒绝。
统一支付中转会不会把密钥集中到一个项目？
不会。中转站只搬运原始请求字节，不解密、不预验签；私钥留在各项目里，由下游收到转发后自己验签，信任边界没有下移。
转发失败时支付结果会丢吗？
中转站会对网关立即返回成功，转发失败由网关侧的指数退避重试覆盖；下游验签失败的补偿机制（异常队列加告警）是下一步要补的开放问题。
Day 1：补齐第三个支付渠道
| 项目 | 域名 | ICP 状态 | 能直接收 notify_url |
|---|---|---|---|
| 派宝 | 派宝.com | ✅ 已备案 | ✅ |
| Portal | ip.digitalforce.cc | ❌ digitalforce.cc 未备案 | ❌ |
| AutoGlobal | autoglobal.ai | ❌ .ai 不可备案 | ❌ |
| Realnator | realnator.com | ❌ 未备案 | ❌ |
| ClawOps | clawops.digitalforce.cc | ❌ 同上 | ❌ |
| 原则 | 为什么 |
|---|---|
| 派宝不预验签 | 私钥/AES-GCM key 留在每个项目里，不让派宝看见。派宝只搬运字节。 |
| 派宝透传原始 POST body | 微信 APIv3 的签名是 timestamp + nonce + body 的 SHA256-RSA。改一个字符整个签名废掉。 |
| 派宝立即返回成功 | 支付宝 5s、微信 10s 内必须收到 success token，否则触发重试风暴。派宝即返即转。 |
| 下游自己验签 | 收到转发的 alipay-* / wechatpay-* 头之后，目标项目用自己的私钥重新验签。Trust 边界没下移。 |
| fire-and-forget 转发 | 转发失败不影响派宝给网关回 success。网关侧的指数退避重试覆盖瞬时网络故障。 |
| strip hop-by-hop headers | Connection/Keep-Alive/Transfer-Encoding 不应该跨 hop 透传，但 Content-Type 和签名头要保留。 |
单看一个 commit 是"feat: 加个微信支付"。 单看下一个 commit 是"feat: 加个 webhook relay"。 串起来看，是中国市场 SaaS 才有的一种架构变形——ICP 备案约束直接重塑了系统拓扑。
派宝早就接了 Stripe + 支付宝。微信支付一直缺，直到这周才补上：
设计上的一个小决定：wechat_sign.py 用纯 stdlib 实现，139 行。
不是图省事。微信官方 Python SDK 拖一长串依赖（cryptography、requests、urllib3 老版本），上线就要重打镜像。stdlib 实现意味着：
升级路径也复用了 Alipay 那套：PLANPRICEFENCN 和 PLANQUOTAS 两个常量被两个 router 共享——保证微信付费的租户和支付宝付费的租户拿到完全一致的配额。
到这里都还是工程上的"add another channel"故事，没什么稀奇。
微信支付商户后台让我们填 notify_url——这是支付成功后微信回调的目标地址。
填了派宝的回调地址（派宝.com 域名下）——✅ 通过。
填到下一个项目 Portal 的回调地址（ip.digitalforce.cc 域名下）——❌ 拒绝。
理由：该域名未经 ICP 备案。
中国内地的事实：支付宝 + 微信支付的 notify_url 必须指向已 ICP 备案的域名。我们 4 个 CN 业务项目里，只有"派宝.com"（punycode: xn--pbt132b.com）走完了备案：
正常解法是给每个项目单独备案——周期 20-40 工作日 × 4，加上各种公司材料反复来回。我们等不起。
所以做了另一个选择：让派宝成为整个家族的统一支付 webhook 入口。
┌─────────────────────┐ ┌───────────────────────┐ │ Alipay / WeChat Pay │ ────notify_url────────► │ 派宝.com (派宝) │ │ (商户后台填的) │ (备案域名) │ 支付转发入口 │ └─────────────────────┘ └──────────┬────────────┘ │ 透明转发原始 │ POST body + headers ┌───────────────┼────────────────┐ ▼ ▼ ▼ ip.digitalforce autoglobal.ai realnator.com /webhook/... /webhook/... /webhook/... (Portal 自己验签 + 处理) 新增两个转发入口：一个转发支付宝 form-encoded 回调，一个转发微信 APIv3 加密回调。
路由表用环境变量覆盖：PAYMENTRELAY{PROJECT}{GATEWAY}——例如 PAYMENTRELAYPORTALWECHAT 指向 ip.digitalforce.cc 的 webhook 地址。
很容易把转发器写成"先解密 + 验签，再转发已验证的数据给下游"。这是错的。我们的设计：
这个设计让派宝在合规边界上只承担"备案域名"这一项责任，密钥管理和支付逻辑还是各项目自治。
意料之外的好处：现在 4 个项目的支付回调全部经过派宝同一个 access log。
[wechat-relay] target=portal forwardok=true upstreamstatus=200 60ms [alipay-relay] target=realnator forwardok=true upstreamstatus=200 42ms [wechat-relay] target=autoglobal forwardok=false upstreamstatus=503 timeout=5s 一个 grafana panel 看穿所有项目的支付健康度。以前要登 4 台服务器分别 tail -f。
下游项目验签失败时，回滚机制还没设计好。当前的"派宝立即对网关回 success + 转发失败被吞掉"模式意味着：如果 Portal 验签失败（比如配置过期的 platform cert），用户的钱已经付了，但 Portal 的订单状态不会变。
正在做的改进方向：
这块还在草案阶段，等下个迭代落实。
这个故事的全部价值不在"我们写了一个转发器"——而在：
某个看似无关的政策约束（"必须 ICP 备案才能填 notify_url"）会向上传导，重塑你的系统拓扑。
如果你的 SaaS 要进中国市场，提前问自己：
跨过这个坑的成本可能是两天，也可能是两个月。
创建订单：返回支付地址，前端渲染成二维码
订单查询：用户在微信里付钱时，前端轮询订单状态
支付回调：验签 + AES-256-GCM 解密 + 升级租户
容器层不变
portal 那边 TypeScript 可以做镜像实现（static-ip-portal/lib/payment/wechat-sign.ts），两端签名逻辑可逐行对照审计
升级到 APIv4 时只需要改这一个文件，不用换 SDK 版本
派宝侧 AuditLog 记每次转发结果
下游验签失败必须主动 webhook 回到派宝的 /relay/dlq 异常队列
dlq 触发运营告警
你的网关回调域名能不能备案？
你的多产品矩阵里有没有可以备案的"母舰域名"？
你的转发器有没有正确处理签名透传？
需要把这个方法，用到您的业务中？
带上当前网站、重点市场和客户问题，一起判断最值得先做什么。
INQUIRY
读完有想法？聊聊你的业务
留下你的情况，我们带着具体建议回复你——不推销，先给判断。