Hyperswitch: open source payment orchestration platform
/hyperswitch
hyperswitch earns its place in any payment stack that has outgrown a single processor. The Rust core delivers high throughput without GC pauses that affect JVM-based gateways, the routing layer learns from auth rates instead of round-robining, and the modular architecture lets you use only the vault or retry engine without adopting the full stack.
The multi-processor fragmentation problem
Every payment team eventually hits the same wall: a single processor goes down, auth rates drift for a specific card type or region, or interchange fees quietly eat into margins with no visibility. Integrating a second processor by hand means redoing webhooks, retry logic, and tokenization from scratch. A third processor multiplies the problem. Most teams end up either locked into their first provider or buried under a maintenance nightmare of custom glue code.
What is Hyperswitch?
Hyperswitch is an open source payment orchestration platform written in Rust that sits between your application and 120+ downstream processors. It exposes a single REST API to your code, then handles routing, retries, vaulting, and cost visibility internally. You can deploy the full stack or pick individual modules to bolt onto an existing gateway.
Key capabilities
- โIntelligent routing across 120+ processors โ routes each transaction to the PSP with the highest predicted auth rate for that card type, region, and amount
- โRevenue recovery with configurable retry strategies tuned by BIN, region, payment method, and penalty budget โ not a naive fixed-interval retry loop
- โPCI-compliant vault that stores cards, tokens, and bank credentials, with a bring-your-own-vault option to connect existing VGS or TokenEx setups without re-tokenizing
- โCost observability dashboards that surface hidden fees, downgrades, and penalties per processor and transaction type
- โAutomated reconciliation supporting 2-way and 3-way matching with backdated support, staggered scheduling, and custom output formats
- โControl Center โ a web UI for configuring connectors, routing rules, retry budgets, and API keys without touching code
- โModular deployment: each service (app server, card-vault, encryption-service) runs independently, so teams can upgrade or scale individual components
- โDecision-engine as a standalone routing control plane โ works without the full orchestrator, enabling rule-based gateway selection against any payment stack
Common starting points
- โขMoving from a single Stripe or Braintree integration to multi-PSP routing with per-transaction gateway selection
- โขReplacing a monolithic payment gateway with direct acquirer connections (TSYS, JP Morgan Payments) while keeping existing vault infrastructure
- โขAdding revenue recovery to an existing stack โ drop in the retry engine without migrating processors
- โขBuilding a reconciliation pipeline that reconciles transactions across multiple PSPs into a single view
- โขRunning a multi-tenant SaaS where each tenant gets isolated routing rules and connector configurations
- โขSelf-hosting a fully owned payment stack to avoid vendor lock-in and reduce per-transaction processing costs
Running Hyperswitch locally
Clone the repo and run the setup script โ that's the whole story for local dev. The command sequence is: bash git clone --depth 1 --branch latest https://github.com/juspay/hyperswitch cd hyperswitch scripts/setup.sh The script detects Docker or Podman, then offers three deployment profiles: Standard (app server + Control Center), Full (adds monitoring and schedulers), or Minimal (standalone app server only). It prints access links when complete. No manual environment variable juggling for the happy path.
Configuring connectors and routing
After setup, open the Control Center UI to add a payment processor connector โ you supply credentials and it validates the connection. Routing rules are configured per-transaction: you define conditions (card BIN, region, amount) and assign a priority order of processors. The retry engine runs separately and respects configured penalty budgets per processor, so failed transactions get retried at appropriate intervals without hammering a degraded gateway. Webhook endpoints are normalized โ your application receives one webhook format regardless of which processor processed the original transaction.
Strengths
- โModular architecture means you plug in only the modules you need โ routing, vault, retries, or observability โ without inheriting a monolithic stack you have to operate end-to-end.
- โRust underneath delivers the kind of memory safety and throughput that payment routing at scale actually demands, without the GC pauses that come with JVM or Node.js alternatives.
- โ120+ processor connectors ship out of the box, including Stripe, Adyen, Braintree, Worldpay, Checkout.com, and Cybersource, so multi-PSP routing is wiring you already have rather than something you build.
- โThe Control Center gives you a visual dashboard for routing rules, connector config, retry strategies, and analytics โ not just an API to manage everything through scripts.
- โSelf-host is a real option: Docker setup in one script, Helm charts for Kubernetes across AWS, GCP, and Azure, plus an optional bring-your-own-vault path that lets you reuse existing VGS or TokenEx tokens without re-tokenization.
Limitations and tradeoffs
- โณRust expertise is effectively required to extend connector implementations or modify core routing logic โ the language choice is intentional but it narrows the contributor pool compared to Node.js or Go payment stacks
- โณMulti-service coordination adds operational overhead: card-vault, encryption-service, decision-engine, and the app server must be kept in compatible versions, and upgrading one can require careful sequencing
- โณThe retry engine can silently drop transactions if penalty budgets are misconfigured โ the behavior is intentional (you set the budget) but the failure mode is easy to miss in testing
- โณSome connectors are more mature than others; early-stage integrations may lack full feature parity with what Stripe or Adyen offer natively
- โณSelf-hosting production infrastructure requires you to own PCI DSS compliance scope, which is non-trivial for teams without existing cardholder data environment experience
Hyperswitch vs alternatives
Frequently asked questions
Yes. Hyperswitch is Apache-2.0 licensed, which permits commercial use, modification, and redistribution with no royalties or per-seat fees. You only pay your downstream payment processors.
Absolutely. Self-hosting is a first-class option. Docker, Helm charts for Kubernetes, and a Terraform suite are all available. The Control Center, routing engine, vault, and encryption service run entirely on your own infrastructure.
120+ processors are supported, including Stripe, Adyen, Braintree, Worldpay, Checkout.com, and Cybersource. Each connector ships with its own setup guide for credentials and webhook configuration.
Hyperswitch does not provide legal advice on licensing requirements. Whether you need a payment facilitator or payment processor license depends on your jurisdiction, transaction flows, and how you structure your business โ consult a payments lawyer before self-hosting in production.
Hyperswitch's Vault module supports a bring-your-own-vault mode. You can connect an existing VGS or TokenEx setup without re-tokenizing stored cards or migrating existing card data โ it integrates at the token exchange layer.
Production-ready options include Helm charts for Kubernetes on AWS, GCP, or Azure, and a Terraform suite that wires together the app server, vault, encryption-service, and control center as a full-stack deployment.
Who should try it โ and who should skip
Hyperswitch is worth evaluating if your team is processing enough volume that a few basis points saved through intelligent routing or failed-payment recovery justifies the operational investment. E-commerce platforms, SaaS products with marketplace payments, and fintech companies running on multiple PSPs will get the most value. You need at least one engineer comfortable with Rust or willing to become comfortable โ the extension model assumes it. If your transaction volume is modest and a single managed gateway covers your needs, the complexity is not worth it yet.
Related repositories
Is hyperswitch worth your time?
ChatGPT, Claude and Perplexity can all read this page. Ask one of them what it makes of hyperswitch.