43.6k stars · Apache-2.0 · v1.126.0 (2026-08-24) · Track this in Rising ↗
Open, composable payments orchestration across many processors, with routing and revenue recovery.
Radar check
What we found when we opened it. Every bar is one fact, with its date.
Last code pushed 26 Oct 2026, one day before this check.
Latest release v1.128.0 on 16 Oct 2026.
Public since October 2022, about 4 years.
45,411 stars and 6,454 forks.
638 commits and 376 new issues in the last 90 days.
264 contributors. 725 pull requests merged in 90 days.
A security policy says how to report a problem. No published security advisories.
How the bars are scored
- Alive. Days since the last code push: a week or less 100, a month 90, three months 70, six months 50, a year 30, eighteen months 15, older 0.
- Releases. Age of the latest GitHub release, on a similar scale; no bar when the project publishes no releases.
- Maturity. Age of the project: eight years 100, five 90, three 70, two 55, one 40, six months 25, younger 10.
- Adoption. Stars on a log scale: 100,000 stars is 100, 10,000 is 80, 1,000 is 60, 100 is 40.
- Activity. Commits in the last 90 days: 300 or more 100, 100 85, 30 65, 10 45, any 25.
- Community. People who have contributed: 100 or more 100, 30 80, 10 60, 5 40, 2 25, one 10.
- Security. A published security policy 80, none 40; published advisories are listed, not scored.
Checked by Repo Radar on 26 Oct 2026 from the repository on GitHub. Covered in Edition 16.
▶Repo detailsthe review · specs · pros & cons · install
What it does
Hyperswitch is a payment layer written in Rust that puts one interface in front of many payment companies. It is built as separate modules, so a business can take one piece rather than the whole thing. The pieces cover routing a transaction to a chosen provider, retrying a failed payment through another, storing cards and tokens with the option of bringing your own vault, watching what payments cost, reconciling records two or three ways, and widgets for wallet and pay-later methods. The project names Stripe, Adyen, Braintree, Worldpay, Checkout.com and Cybersource among its connections and says more than a hundred processors work out of the box. There is a hosted sandbox for trying it before installing anything. Its setup script offers standard, full and minimal profiles and detects Docker or Podman, and cloud deployment uses Helm charts for the big three providers. The project lists no non-goals, and the honest boundary is that it moves money between a business and providers — it is not a shop, a subscription product or an accounting system.
Why it matters
Who it suits. It fits a business already taking money and feeling the cost of one provider: fees, a country that is not supported, or payments failing for one card type. The routing is the point — European cards one way and American cards another, and a failure retried with a second provider instead of a lost sale. Skip it entirely before the first payment has been taken, when a simpler service that handles tax and takes a percentage is the right size. Skip it too if nobody on hand wants to own card-industry compliance.
Verdict. Worth knowing about long before it is worth installing, because it is cheaper to know it exists than to unpick payment code later. Try the hosted sandbox first; it shows the whole thing working with nothing installed. The real cost is not the licence but the compliance: anything touching card numbers brings the card-industry rules onto whoever runs it. Releases come very fast, version 1.128.0 already, so pin the version and read the notes before upgrading. polarsource/polar is the right size for a first product, because it takes a percentage and handles tax and receipts itself.
Summary (Key Points)from the README
Key features
- Modular modules: Six payment modules (Cost Observability, Revenue Recovery, Vault, Intelligent Routing, Reconciliation, Alternate Payment Methods) can be adopted individually on top of an existing stack.
- Multi-PSP routing: Intelligent Routing sends each transaction to the processor with the highest predicted auth rate across Stripe, Adyen, Braintree, Worldpay, Checkout.com and 120+ others.
- Connector coverage: The README cites 100+ payment processors out of the box, each with a dedicated setup guide.
- Reconciliation: Automates 2-way and 3-way reconciliation with backdated support and staggered scheduling.
- Vault with bring-your-own: Stores cards, tokens, wallets and bank credentials, and can connect existing vaults such as VGS and TokenEx without re-tokenizing stored cards.
- Setup profiles: The Docker script offers Standard (app server plus Control Center), Full (adds monitoring and schedulers) and Minimal (standalone app server).
- Control Center: A merchant dashboard for configuring connectors, routing rules, retry strategies and logs, plus a visual workflow builder.
- SDK coverage: Web checkout (npm) and officially supported Android, iOS, React Native and Flutter SDKs.
Ways to install
| Platform or method | What it needs | Effort |
|---|---|---|
| Local setup via Docker or Podman | Docker or Podman; the setup script detects which is present | Low: a guided script with profile choices |
| Hosted Sandbox | A browser only; no setup | None |
| Cloud deployment with Helm charts | An account on AWS, GCP or Azure, plus Kubernetes and Helm | Higher: requires cloud infrastructure; the README links separate instructions |
Important
- Connector count differs: The README says "100+" processors in one place and "120+" in another, so check the current connector list before relying on either figure.
- Routing claims are unverified: The README describes predicted auth-rate routing and reduced retries but gives no benchmark data.
- Deprecated React Native package: The older hyperswitch-sdk-react-native has been removed from npm; use react-native-hyperswitch instead.
- iOS distribution: CocoaPods support is listed as "SPM in progress."
- Control Center needs the backend: The dashboard and embedded UI require the hyperswitch backend to be running.
- Connector setup is still required: After any install, you must configure a connector and test a payment; the README does not describe a ready-to-use payment setup.
- Standalone services: decision-engine and prism can run without the full switch, so they suit narrower use cases than the full stack.
- Vendor-specific details: Cloud deployment is documented only as Helm charts, and the README does not list supported Kubernetes versions or hardware requirements.
Written by an AI model from the project’s README; not part of the review, and it can be wrong.
- Apache-2.0, and it comes from a company that runs payments at scale rather than a side project.
- Routing rules, automatic retries across providers, and card storage in one place.
- There is a hosted sandbox, so the whole thing can be seen working before anything is installed.
- The setup script's full profile brings a monitoring stack with it. Use the minimal profile on a small machine.
- Running anything that touches card numbers yourself puts the card-industry compliance work on whoever runs it. That is the real cost, not the licence.
- Releases come very fast — version 1.128.0 already. Pin the version and read the notes before upgrading.
git clone --depth 1 --branch latest https://github.com/juspay/hyperswitch cd hyperswitch scripts/setup.sh
