综合自托管 Hyperswitch：把多 PSP 路由、重试与保险库拆成可选的 Rust 服务

2026-10-10 21:31:08

自托管 Hyperswitch：把多 PSP 路由、重试与保险库拆成可选的 Rust 服务

它是什么

Hyperswitch 是 Juspay 开源的支付编排平台，Apache-2.0 许可，核心用 Rust 写。仓库 juspay/hyperswitch 目前 45.3k star、6.4k fork，官网在 hyperswitch.io。

它不自己做收单，而是插在商户和已有 PSP / 收单行之间做一层编排层，同时提供 SaaS 和自托管两种形态，支持 PCI 合规部署。除了整套 Payment Suite，也可以只挑其中某个模块接到现有支付栈上，不要求整体替换。

解决的问题

Intelligent Routing：把每笔交易路由到预测授权率最高的 PSP，覆盖 Stripe、Adyen、Braintree、Worldpay、Checkout.com 等 120+ 家，目标是减少重试、避开故障、压低延迟、提高首次成功率。
Revenue Recovery：按卡 BIN、地区、支付方式等维度调整重试策略，对重试算法、penalty budget、恢复过程有细粒度控制，用来对付被动流失（passive churn）。
Vault：PCI 合规的保险库，存卡、token、钱包和银行凭证。支持 bring-your-own-vault，对接 VGS、TokenEx 等现有提供商，不需要重新 token 化或迁移已存卡。
Reconciliation：2-way 和 3-way 对账自动化，支持回溯日期、错峰调度、可定制输出，减少人工对账并提高审计可追溯性。
Cost Observability：用自助仪表盘审计、监控和优化支付成本，发现隐藏费用、downgrade 和罚金。
Alternate Payment Methods：PayPal、Apple Pay、Google Pay、Samsung Pay、Pay by Bank，以及 Klarna 这类 BNPL 的 drop-in 组件。

本地起一套

Docker 方式三条命令：

git clone --depth 1 --branch latest https://github.com/juspay/hyperswitch
cd hyperswitch
scripts/setup.sh

脚本会检测 Docker / Podman，让你选部署档位：

Standard：App server + Control Center
Full：再加监控和调度器
Minimal：只跑独立 App server

结束后给出访问链接。接着在界面里配置一个连接器，跑一笔测试支付。

不想本地搭的话，官方有托管沙箱，可以直接在 UI 里探索 Control Center、配连接器、测支付。生产部署走 Helm Chart，支持 AWS、GCP、Azure。

架构与模块拆分

核心后端服务全部是 Rust：

hyperswitch：App server，负责路由、重试、保险库、可观测性，依赖 card-vault 和 encryption-service。
card-vault：PCI 合规的卡片存储，依赖 encryption-service。
encryption-service：加解密与 KMS。
hyperswitch-prism：统一连接器库，封装 100+ 处理器。可独立使用，直接对接处理器，不必运行完整 switch。
decision-engine：路由控制面，基于规则和成功率选择网关。同样可独立运行，能配任意编排器。

仪表盘有两个：control-center（ReScript，完整商户后台，含连接器、路由规则、分析、API key）和 control-center-embedded（TypeScript，可嵌入）。两者都要求 hyperswitch 后端。

Web 结账 SDK 包括 hyperswitch-web、client-core、react-hyper-js、sdk-utils，均为 ReScript / npm 包。

移动端有 Android（Kotlin）、iOS（Swift）、React Native、Flutter（Dart），都构建在 hyperswitch-client-core 之上。老的 hyperswitch-sdk-react-native 已废弃并从 npm 移除，改用 react-native-hyperswitch。

部署侧：hyperswitch-suite（Terraform，全栈伞形部署，串起 core、vault、control-center、web，全栈场景的推荐起点）和 hyperswitch-helm（GCP、Azure 或任意 K8s 集群）。

连接器方面，开箱集成 100+ 支付处理器，每个都有专门指南，覆盖凭据配置、webhook 设置、支持的支付方式和常见失败模式，例如 Global Payments、Stripe、PayPal、Adyen、Bank of America。

常见起点

从这些场景切进来比较多：团队原本只集成 Stripe / Stripe Connect 或 Braintree，要转向多 PSP 路由；商户想用 TSYS、JP Morgan Payments 等收单行直连替换掉支付网关；或者重新架构支付平台，但保留现有的 VGS、TokenEx 保险库不动。第三个场景风险最低，因为卡数据不迁移。

反过来，如果不打算自己运维这套 Rust 服务，或者只有单一 PSP、没有路由 / 重试 / 对账需求，加一层编排的收益就比较有限，直接对接收单方或网关更省事。

取舍

选 Rust 换来的是性能和可靠性，代价是团队得能读、能运维这些服务。模块可拆是另一面：可以只跑 app server，也可以单独拿 decision-engine 或 prism 用，不必整体替换现有栈。保险库同理，自带的 card-vault 和 BYO（VGS / TokenEx）都支持，对已有保险库的团队来说这是个低风险入口。

版本变更看仓库的 CHANGELOG.md，许可为 Apache 2.0。

综合 自托管 Hyperswitch：把多 PSP 路由、重试与保险库拆成可选的 Rust 服务