GOV.UK Pay 迁移实战：从 Stripe 到 Adyen 的千服务级支付提供商切换

英国政府数字服务（GDS）于 2026 年 6 月初宣布，旗下支付平台 GOV.UK Pay 将把非皇冠机构（non-Crown）的银行卡支付服务从 Stripe 迁移至荷兰支付服务商 Adyen。此次迁移涉及约 1,000 个公共服务机构，涵盖地方政府、警察部队和武装部队等，但仅占平台交易量的 17%。作为自 2016 年上线以来处理超过 90 亿英镑交易的核心基础设施，这次迁移为大规模支付提供商切换提供了极具参考价值的工程实践。

迁移背景与规模

GOV.UK Pay 自 2016 年上线以来，已为 608 个组织的 1,718 项服务提供支付处理能力。平台累计处理 1.375 亿笔交易，金额达 92 亿英镑。此次迁移的核心驱动力是引入 "银行直付"（pay by bank）功能 —— 基于开放银行（Open Banking）标准，允许用户直接从银行账户转账付款，无需输入银行卡信息。

根据 GDS 官方博客披露，新合同为期三年（2026 年 5 月至 2029 年 5 月），总价值最高达 2,530 万英镑。值得注意的是，中央政府、NHS 及 arm's-length bodies 仍继续使用 Worldpay，形成 "双供应商" 架构：Adyen 负责非皇冠机构的银行卡和银行直付，Worldpay 继续服务中央政府体系。

API 兼容性挑战与应对策略

支付提供商迁移的最大技术难点在于 API 兼容性。Stripe 与 Adyen 虽然都提供 RESTful API，但在数据模型、Webhook 事件结构和错误码定义上存在显著差异。

数据模型差异：Stripe 使用扁平化的对象结构，如 PaymentIntent 对象直接包含金额、货币、状态等字段；而 Adyen 采用嵌套结构，支付信息封装在 paymentRequest 和 paymentResponse 对象中。迁移过程中需要建立字段映射层，确保现有服务无需修改业务逻辑即可适配新接口。

Webhook 事件映射：Stripe 的 Webhook 事件如 payment_intent.succeeded 需要映射到 Adyen 的 AUTHORISATION 通知类型。关键差异在于 Adyen 使用 HMAC 签名验证，而 Stripe 使用签名头验证，这要求更新接收端的验证逻辑。

幂等性处理：支付系统对幂等性要求极高。Adyen 的 reference 字段与 Stripe 的 idempotency_key 行为略有不同 ——Adyen 在 24 小时内拒绝重复引用，而 Stripe 的幂等窗口更长。迁移期间需要确保重复提交不会导致重复扣款。

分阶段切换的工程实践

GDS 采用分阶段迁移策略，核心原则是 "对用户无感知，对服务方低侵入"。

阶段一：影子模式（Shadow Mode） 新支付请求同时路由至 Stripe 和 Adyen，Adyen 端仅做模拟处理不实际扣款。此阶段验证数据映射准确性、Webhook 接收稳定性和错误处理逻辑。建议持续 2-4 周，覆盖至少 10 万笔测试交易。

阶段二：流量灰度（Canary Release） 按服务维度逐步切流，从低频服务（如社区活动报名缴费）开始，逐步过渡到高频服务（如停车罚款、市政税）。GDS 计划迁移约 1,000 个服务，按此策略预计需要 3-6 个月完成全量切换。

阶段三：KYC 合规过渡 根据英国 "了解你的客户"（Know Your Customer）法规，每个服务机构需完成 Adyen 的商户入驻流程。GDS 承诺 "让变更尽可能简单"，通过集中化处理减少各机构的合规负担。关键是在切换前完成所有商户的 KYC 审核，避免支付中断。

开放银行集成的技术要点

"银行直付" 是此次迁移的核心收益之一。基于开放银行标准的账户到账户（A2A）支付相比传统银行卡有三大优势：降低欺诈风险（无需共享卡号）、减少交易费用（绕过卡组织网络）、提升用户体验（无需手动输入卡信息）。

技术实现上，Adyen 的 Open Banking 方案需要处理以下关键环节：

银行选择界面：用户选择其开户银行后，系统需跳转至银行授权页面。这要求前端实现银行列表动态加载，支持按 popularity 或字母排序，并处理银行 API 的可用性状态。

授权流程管理：开放银行支付采用 OAuth 2.0 授权码模式。与银行卡的一次性授权不同，银行授权涉及多步跳转，需要维护会话状态并处理用户取消或超时场景。

异步确认处理：银行直付的确认通常是异步的 —— 用户授权后，资金可能需要数秒至数分钟才能到账。系统需要设计轮询或 Webhook 机制来捕获最终支付状态，并妥善处理 "授权成功但扣款失败" 的边缘情况。

迁移中的可落地参数清单

基于 GOV.UK Pay 的迁移实践，整理以下可复用的技术参数：

兼容性层设计

• 字段映射表：维护 Stripe ↔ Adyen 的字段对照文档，标注数据类型差异（如金额单位：Stripe 用分，Adyen 用主货币单位）
• 错误码映射：建立 HTTP 状态码和业务错误码的转换矩阵，确保客户端错误处理逻辑无需重写
• Webhook 适配器：实现统一的事件接口，底层根据来源提供商路由到对应的解析器

监控与回滚

• 关键指标：支付成功率（目标 >99.5%）、平均处理时长（P95 <3s）、Webhook 延迟（P99 <10s）
• 熔断阈值：单服务错误率超过 5% 自动回滚至原提供商
• 数据一致性校验：每小时比对两端的交易记录，检测金额、状态不一致

合规 checklist

• PCI DSS 范围重新评估：确认迁移后敏感数据的存储和处理边界
• 商户协议更新：确保服务条款、退款政策与 Adyen 要求一致
• 审计日志保留：支付日志保留期限不少于 7 年（英国税务要求）

对工程团队的启示

GOV.UK Pay 的迁移案例揭示了一个关键原则：支付基础设施的供应商切换不应被视为简单的 "配置变更"，而应作为完整的工程项目来管理。GDS 强调 "让服务团队尽可能少做工作"，这意味着平台层需要承担更多的适配和抽象工作。

对于正在评估支付提供商的团队，此次迁移提供了重要参考：在选型阶段就应考虑供应商锁定的风险，通过抽象层（如 GOV.UK Pay 本身）隔离底层提供商差异。当迁移不可避免时，分阶段、可观测、可回滚的策略是保障业务连续性的最佳实践。

参考来源

• GDS Blog: Building for the future: Making change simple on GOV.UK Pay
• The Register: GOV.UK goes Dutch on payments as it dumps Stripe

web