Self-Hosted / Projects / HyperSwitch
HyperSwitch
StableSpecs verified September 25, 2026 · against vcurrent repository release
Overview
Self-hosted open-source payment orchestrator for routing transactions across multiple processors.
HyperSwitch is a payment orchestration platform for businesses that need to connect one application to multiple payment processors. It sits between a merchant integration and payment providers, providing a unified interface for routing, retries, connector management, and payment operations.
Why people choose HyperSwitch
The search intent is a self-hosted open-source alternative to payment orchestration and gateway abstraction services, sometimes framed as an alternative to parts of Stripe, Adyen, or Spreedly. Its value is strongest for teams that need multi-processor control and do not want payment-provider behavior hard-coded into every storefront or service.
What is included
Official HyperSwitch material covers a unified payments API, multiple payment connectors, routing and retry logic, payment methods, tokenization or vaulting components, webhooks, refunds, disputes, and an operator control center. Provider availability, regional support, and compliance responsibilities remain deployment-specific.
Requirements and tradeoffs
HyperSwitch is production payment infrastructure, not a homelab toy or drop-in Stripe clone. Plan databases, secrets, observability, webhook delivery, provider credentials, backups, high availability, fraud/compliance processes, and a carefully reviewed card-data boundary. Self-hosting gives control but leaves reliability, upgrades, certification, and incident response with the operator.
Best fit
Choose HyperSwitch when an engineering team operates a real multi-provider payments stack and needs an extensible orchestration layer. A hosted gateway is simpler for a small store, while a direct provider integration may be cheaper when one processor and one region are enough.
Interface previews
Screenshots of the HyperSwitch interface.
Feature support
| Feature | Support |
|---|---|
| Unified payments APIThe official project positions HyperSwitch as a single API over payment operations and provider connectors. | Supported |
| Multiple payment connectorsThe project maintains connector integrations for multiple payment processors; availability depends on region and payment method. | Supported |
| Rule-based payment routingOfficial product material describes routing logic for selecting processors and improving payment outcomes. | Supported |
| Retries and fallback routingRetry and fallback capabilities are documented parts of the orchestration model. | Supported |
| Payment methods and webhooksThe platform documents payment flows, methods, and asynchronous webhook-based status handling. | Supported |
| Refunds and disputesThese operations are supported through the payment stack, but exact behavior depends on connector capabilities and configuration. | Partial support |
| Vaulting and tokenizationThe project includes vaulting/tokenization components, but merchants must review the selected deployment and compliance boundary. | Partial support |
| Self-hosted deploymentHyperSwitch is open source and publishes self-hosting and deployment material. | Supported |
| Drop-in replacement for StripeIt is an orchestration layer, not a universal replacement for a processor, merchant account, fraud service, or all Stripe product areas. | Not supported |
Community signals
- Stars
- 45.3k
- Forks
- 6.4k
- Open issues
- 2.2k
- Last commit
- 22h ago
- Latest release
- v1.127.0
- Repo created
- Oct 2022
Includes open pull requests
3d ago
Refreshed nightly from the GitHub API.
Questions
What is HyperSwitch used for?
HyperSwitch is used to orchestrate payments across multiple processors through a unified API with routing, retries, and operational payment workflows.
Is HyperSwitch a self-hosted Stripe alternative?
It can replace parts of a hosted payment abstraction for teams that need self-hosted orchestration, but it does not replace every Stripe product, merchant-account relationship, fraud control, or compliance obligation.
Why use a payment orchestrator?
A payment orchestrator can centralize provider integrations, route transactions, retry failures, and reduce application-level coupling to one processor.
Does HyperSwitch support multiple payment providers?
Yes. The official project is built around connectors to multiple payment processors, although exact methods and regional support vary by connector.
Can HyperSwitch be self-hosted?
Yes. HyperSwitch publishes its source and deployment guidance, but production operation requires serious attention to secrets, databases, webhooks, availability, monitoring, and compliance.
Does HyperSwitch handle card-data compliance for me?
No. The operator and merchant still need a compliant payment architecture and must understand what data crosses each component. Self-hosting does not remove PCI, privacy, fraud, or regional obligations.
Is HyperSwitch suitable for a small homelab project?
It can be useful for learning payment architecture, but it is substantial production infrastructure. A hosted processor or direct integration is usually safer and simpler for a small store.
support // the lab
Found this write-up useful?
If it saved you time or a rebuild, you can support more practical homelab guides.