Hyperswitch: A Rust-Based Open Source Payments Platform for Multi-PSP Routing
Hyperswitch is a composable open-source payments platform in Rust, linking multiple payment providers with intelligent routing, cost observability, and reconciliation.
At a glance
- What is it?
- Hyperswitch is an open source, composable payments platform in Rust that connects to 120+ processors. This review covers its modules, deployment paths, and where its complexity becomes a liability.
- Who is it for?
- Adopt Hyperswitch if you run a payment stack and want to break free from a single PSP, need PCI-compliant vaulting, or want intelligent routing without vendor lock-in. Skip it if you only need a simple Stripe integration or lack the ops capacity for a self-hosted Rust service.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Hyperswitch Actually Solves
Hyperswitch addresses a specific pain: payment stack lock-in. Merchants who start with Stripe or Braintree often find it hard to add a second processor, let alone switch acquirers. The README positions Hyperswitch as a modular layer that lets you keep your existing vault (VGS, TokenEx) while adding routing, retries, and reconciliation. The target user is a team that has outgrown a single PSP and wants direct acquirer connections to TSYS or JP Morgan Payments, but does not want to build the integration layer from scratch. It is also for teams that want to augment an existing stack with one module, like cost observability, without replacing everything. The phrase "Linux for Payments" in the README signals the ambition: an open standard layer that you own, not rent.
The Modular Architecture: Pick What You Need
The README lists six modules: Cost Observability, Revenue Recovery, Vault, Intelligent Routing, Reconciliation, and Alternate Payment Methods. Each is independent and purpose-built. That modularity is the core design choice. You can integrate only the routing module on top of your current PSP, or only the vault to store cards and tokens. The Vault module supports bring-your-own-vault, meaning you can connect VGS or TokenEx without re-tokenizing stored cards. That is a significant practical advantage for merchants who already have a vault and want to avoid migration risk. The Intelligent Routing module routes each transaction to the PSP with the highest predicted auth rate, across Stripe, Adyen, Braintree, Worldpay, Checkout.com, and 120+ others. The architecture is Rust-based, which the README claims is for performance and reliability, though it does not provide benchmarks.
Getting It Running: Docker, Helm, and a Hosted Sandbox
The quickest path is the one-click Docker setup. You clone the repo with `git clone --depth 1 --branch latest https://github.com/juspay/hyperswitch`, then run `scripts/setup.sh`. That script detects Docker or Podman and offers three profiles: Standard (App server plus Control Center), Full (adds monitoring and schedulers), and Minimal (standalone App server). After setup, you configure a connector and test a payment through the Control Center. For production, the README points to Helm Charts for AWS, GCP, or Azure. There is also a hosted sandbox at app.hyperswitch.io that requires no setup and lets you explore the Control Center, configure connectors, and view logs and routing rules. That sandbox is a smart way to evaluate before committing to a self-hosted deployment.
Intelligent Routing and Revenue Recovery: The Claimed Upside
The Intelligent Routing module is the headline feature. It uses predicted auth rates to route each transaction to the best PSP, with the goal of maximizing first-attempt success and reducing retries. The README claims it can reduce downtime and latency, but it does not specify the model or how predictions are trained. Revenue Recovery builds on that by offering retry strategies tuned by card bin, region, and method, with control over retry algorithms and penalty budgets. That granularity is useful for merchants with high-volume card traffic across geographies. However, the README does not provide evidence of uplift or recovery rates. The claims are plausible but unverified. You should treat them as marketing until you run your own tests in the sandbox.
Cost Observability and Reconciliation: The Ops Angle
Cost Observability is designed to audit and monitor payment costs, detecting hidden fees, downgrades, and penalties with self-serve dashboards. That is a concrete operational benefit for merchants who see inconsistent PSP invoices. Reconciliation automates 2-way and 3-way matching with backdated support and staggered scheduling. The README says it reduces manual ops effort, which is realistic for teams that currently reconcile spreadsheets. The trade-off is that these modules add complexity. You are not just running a payment API; you are running a platform with dashboards, schedulers, and monitoring. The Full deployment profile includes monitoring and schedulers, which implies a heavier operational footprint. For a small team, that may be more than they need.
Where Hyperswitch Is the Wrong Tool
Hyperswitch is overkill for a merchant that is happy with a single PSP and has no plans to expand. If you only need Stripe, adding Hyperswitch introduces a new service to operate, a new API to learn, and a new failure domain. The README does not mention migration effort, but moving from a direct Stripe integration to Hyperswitch means reworking your payment flow. Another limitation is that the README does not list the full set of 120+ processors, so you must verify that your target acquirers are supported. The hosted sandbox helps, but you cannot test a specific connector until you configure it. Also, the README is truncated, so details on security, compliance certifications (beyond the PCI claim in the description), and data residency are not fully covered. You should check the docs for those specifics before adopting.
Alternatives and the Difference in Approach
The obvious alternative is building your own integration layer on top of each PSP's API. That gives you full control but requires maintaining multiple SDKs, handling PCI compliance yourself, and writing routing logic from scratch. Hyperswitch packages that work into a reusable platform, which is the main value. Another alternative is a commercial payment orchestrator like Spreedly or Basis Theory, which also aggregate multiple PSPs. The difference is that those are closed-source SaaS offerings, while Hyperswitch is Apache-2.0 and self-hostable. That matters if you want to modify the routing logic or keep all payment data within your own infrastructure. However, open source also means you own the operational burden. A commercial orchestrator handles uptime and updates for you. The choice depends on whether you value control over convenience.
Maintenance, Upgrades, and License Considerations
Hyperswitch is under active development, with releases v1.124.0, v1.125.0, and v1.126.0 between June and August 2026. That cadence suggests frequent updates, which is good for features but means you need a process for upgrading. The README does not document an upgrade path, so you will likely need to follow release notes and test in staging. The license is Apache-2.0, which permits commercial use, modification, and distribution, with conditions around patent and attribution clauses. That is a permissive license, but it is not legal advice; you should review the full terms. The repo is not archived and the default branch is main, so the project is alive. The community Slack and GitHub issues are the support channels, but there is no mention of a commercial support SLA for the open source version.
Editorial conclusion
Adopt Hyperswitch if you run a payment stack and want to break free from a single PSP, need PCI-compliant vaulting, or want intelligent routing without vendor lock-in. Skip it if you only need a simple Stripe integration or lack the ops capacity for a self-hosted Rust service. Before adopting, verify your target processors are among the 120+ supported, test the reconciliation module against your provider's data formats, and confirm the license terms (Apache-2.0) fit your commercial use. If you go self-hosted, start with the Docker setup script and use the hosted sandbox to validate connector behavior before production.
Community notes