Hyperswitch: Open-Source Payments Orchestration in Rust

What Hyperswitch is

Hyperswitch is an open-source payments switch maintained by Juspay. It sits between a merchant's checkout and the payment processors behind it, so that one integration can reach Stripe, Adyen, Braintree, Worldpay, Checkout.com, Cybersource, PayPal and many others. The README cites 100+ supported processors in its connector section and 120+ in its feature descriptions.

The project describes itself as "Composable Open-Source Payments Infrastructure" and, in its own words, "Linux for Payments". The emphasis is on modularity: teams can adopt the full payment suite, or add individual modules such as routing, retries, vaulting or cost observability on top of an existing payment stack without replacing it.

It is aimed at engineering and payments teams at merchants and platforms that have outgrown a single-processor integration. The README lists typical starting points: moving from a single Stripe, Stripe Connect or Braintree integration to multi-PSP routing; replacing a gateway with direct acquirer connections to TSYS, JP Morgan Payments or other acquirers; and rearchitecting a payments platform while keeping an existing VGS, TokenEx or other vault in place. Juspay states it powers payment infrastructure for 400+ enterprises, and calls Hyperswitch a commercial open-source stack.

How it works

The core of the system is the Rust app server in this repository. It handles payment flows, routing, retries, vaulting and observability, and talks to processors through connectors. Around it sit several separate services and SDKs, which the README maps out explicitly:

• Core backend services (all Rust): the hyperswitch app server; hyperswitch-card-vault for PCI-compliant card storage; hyperswitch-encryption-service for encryption, decryption and KMS operations; hyperswitch-prism, a unified connector library usable directly against processors without running the full switch; and decision-engine, a standalone routing control plane that does rule-based and success-rate gateway selection and can work with any orchestrator.
• Dashboards: the Control Center (ReScript), a merchant dashboard for connectors, routing rules, analytics and API keys, plus an embeddable TypeScript variant for partners.
• Web checkout SDKs: hyperswitch-web, a ReScript-built React library for unified checkout, a shared hyperswitch-client-core, and a React wrapper published on npm.
• Mobile SDKs: officially supported Android (Kotlin, Maven), iOS (Swift, CocoaPods with SPM in progress), React Native and Flutter SDKs, all built on the shared client core.
• Deployment tooling: hyperswitch-suite (Terraform) wires the core, vault, Control Center and web SDK together and is the recommended starting point for the full stack; hyperswitch-helm provides Kubernetes Helm charts.

The app server depends on the card vault and encryption service; the vault in turn depends on the encryption service. Prism and decision-engine have no dependencies and can be used on their own.

Key features

The README groups capabilities into independent payment modules:

• Intelligent routing: route each transaction to the processor with the highest predicted authorization rate, with the stated aims of reducing retries, avoiding downtime and improving first-attempt success.
• Revenue recovery: retry strategies tuned by card BIN, region, payment method and other attributes to reduce passive churn, with control over retry algorithms and penalty budgets.
• Vault: a PCI-compliant store for cards, tokens, wallets and bank credentials, with bring-your-own-vault support for providers such as VGS and TokenEx without re-tokenizing stored cards.
• Cost observability: dashboards to audit payment costs and detect hidden fees, downgrades and penalties.
• Reconciliation: automated 2-way and 3-way reconciliation with backdated support, staggered scheduling and customizable outputs.
• Alternate payment methods: drop-in widgets for PayPal, Apple Pay, Google Pay, Samsung Pay, Pay by Bank and BNPL providers such as Klarna.
• Connector guides: each connector has documentation covering credentials, webhook configuration, supported payment methods and common failure modes.
• Visual workflow builder: routing and retry logic can be configured in the Control Center.

Getting started

The local setup uses Docker or Podman through a single script:

# One-click local setup

git clone --depth 1 --branch latest https://github.com/juspay/hyperswitch

cd hyperswitch

scripts/setup.sh

The script detects Docker or Podman and offers three deployment profiles: Standard (app server plus Control Center), Full (adds monitoring and schedulers) and Minimal (standalone app server). It prints access links when done. The next steps in the docs are to configure a connector in the Control Center and run a test payment.

To explore without installing anything, a hosted sandbox at app.hyperswitch.io exposes the full Control Center, connector configuration, logs, routing rules and retry strategies, and lets you try payments from the UI. For production, the README points to Helm charts for AWS, GCP or Azure.

Use cases

• Multi-processor routing: a merchant on one PSP adds a second or third and routes by success rate, cost or rules to improve authorization rates and resilience.
• Gateway replacement: connect directly to acquirers such as TSYS or JP Morgan Payments instead of going through an intermediary gateway.
• Vault portability: keep an existing VGS or TokenEx vault while adding orchestration, or use the Hyperswitch vault to avoid processor lock-in for stored cards.
• Subscription recovery: use the revenue recovery module to retry failed recurring payments with tuned strategies.
• Finance operations: automate reconciliation and audit processing fees with the cost observability module.
• Platforms and marketplaces: embed Control Center components into a partner-facing product using the embedded dashboard.
• Connector-only integration: use Prism as a library to talk to many processors without deploying the full switch.

How it compares

The README positions Hyperswitch against single-processor integrations and vendor lock-in rather than naming competing products. In practice it sits in the payment orchestration category, alongside commercial orchestration platforms and the routing features some processors offer within their own networks. The main differences it emphasises are that the core is open source under Apache-2.0, can be self-hosted, and is modular enough to adopt one piece at a time. Evaluating it against a commercial orchestrator usually comes down to connector coverage for your markets, compliance scope and how much of the stack your team wants to operate.

Things to know before adopting

• Compliance scope: running your own vault and handling card data brings PCI DSS obligations. The vault is described as PCI-compliant, but your deployment and operations still need to meet the standard.
• Multiple services: a full deployment involves the app server, card vault, encryption service, Control Center and SDKs. The Terraform-based suite is the recommended way to wire them together.
• Mixed language ecosystem: the backend is Rust, while the dashboard and web SDKs are written in ReScript, which matters if you plan to modify them.
• Deprecated SDK: the older hyperswitch-sdk-react-native package has been removed from npm; use react-native-hyperswitch instead.
• Commercial backing: Hyperswitch is maintained by Juspay and described as commercial open source, with a hosted offering alongside self-hosting.
• Maturity: the repository dates from October 2022 and maintains a CHANGELOG for versioned releases.

Project activity

As of October 2026 the repository has roughly 45,300 stars on GitHub. It was created on October 17, 2022, is written in Rust, and is licensed under Apache-2.0. CI runs on GitHub Actions, feature discussions happen in GitHub Discussions, and the community has a Slack workspace. Source code is at github.com/juspay/hyperswitch, and the project site and documentation are at hyperswitch.io.