One merchant-facing API, dozens of processors behind it
Hyperswitch is a payments switch maintained by Juspay. The merchant backend talks to one API, and the Rust server forwards each payment to whichever processor the routing picks: Stripe, Adyen, Braintree, Worldpay, Checkout.com or one of dozens of other connectors. Adding a processor means configuring a connector in the Control Center. The core is Apache-2.0, and Juspay also sells a hosted version called Hyperswitch Cloud.
Rule, split and auth-rate routing, plus a vault that can stay at VGS
- Six routing strategies in the docs: rules on payment method, amount, currency, country or card type; percentage traffic splits; recent auth rates; auth rates re-ranked by processing cost; the cheapest eligible debit network; and a fallback order for when no rule applies or the chosen processor isn't eligible.
- A separate card vault: cards, tokens, wallets and bank credentials go to
hyperswitch-card-vault, which the project describes as PCI compliant. Merchants already on VGS or TokenEx can keep that vault and skip re-tokenizing or migrating stored cards. - Client SDKs for the web (ReScript, with a React wrapper), Android, iOS, React Native and Flutter, all listed as officially supported. Drop-in widgets handle PayPal, Apple Pay, Google Pay, Samsung Pay, Pay by Bank and Klarna.
- Control Center: the merchant dashboard for connectors, routing rules, API keys and analytics. A hosted sandbox lets anyone try it without installing anything.
Moving off a single Stripe or Braintree integration
- Going from one Stripe, Stripe Connect or Braintree integration to routing across several processors, the first starting point the README lists.
- Replacing a payment gateway with direct connections to acquirers such as TSYS or JP Morgan Payments.
- Bringing a new processor online gradually through a percentage split.
- Calling processors through a single interface from an existing app with Prism, a stateless connector library extracted from the project that doesn't need the full switch.
Add-ons sold separately, AGPL routing and PCI scope on the operator
Three modules cost extra even when self-hosted. The README calls Hyperswitch a "commercial open-source" payments stack, and the pricing page shows where the line falls: Revenue Recovery (retries for failed subscription payments), Cost Observability (fee audits) and Reconciliation (transaction matching) are paid add-ons on the free Community edition and on Enterprise alike. The same page lists 90+ payment integrations for both self-hosted editions and 210+ for Hyperswitch Cloud.
Dynamic routing lives in a second service under AGPL-3.0. A self-hosted instance hands its auth-rate routing decisions to decision-engine, deployed separately with its own database and Redis. That repository is AGPL-3.0, while the switch, the vault and the Control Center are Apache-2.0.
PCI DSS compliance is on the operator. According to the pricing page, the Community edition is for businesses that run their own payments stack and "manage compliance end to end". The local Docker setup uses a mocked locker (mock_locker = true); in production, the master key of hyperswitch-card-vault is encrypted by two keys held by two separate custodians. The main server needs PostgreSQL and Redis, and cloud deployment goes through Helm charts on Kubernetes (AWS, GCP or Azure).
Auth-rate routing is meant for traffic spread over several processors. The routing docs suggest starting with the fallback order, adding rules or percentage splits next, and turning on auth-rate routing once several processors carry meaningful traffic for the same payment segment.
Eight minor releases between February 24 and October 16, 2026, up to 1.128.0. The last commit landed on October 26, and the README carries no alpha or beta warning.