juspay/hyperswitch

Worth a serious look if you run multiple payment processors and want routing, retries and reconciliation in one place you control; overkill if you just need a single gateway's checkout.

The problem

A team adding a second or third payment processor usually ends up writing bespoke integration code for each one, then duplicating the logic that decides which processor handles a given transaction, what happens when an authorization fails, and how settlements are matched. That work spreads across the payment flow, retry handling and back-office reconciliation. Hyperswitch changes the middle of that workflow: instead of your application calling processor APIs directly, it calls one payments API, and the switch holds the connector logic, routing rules and retry behavior behind it. The result is that adding a processor or changing routing becomes configuration rather than another integration project.

What's different

The design bet is composability: the Rust app server is the core, but routing lives in a separate decision-engine service, vaulting and encryption sit alongside the core, and a lighter connector library can be used directly against processors without running the full switch. That matters if you want to adopt only one piece — for example, centralized routing while keeping your existing checkout. The README also describes hosted dashboards that can be embedded in partner or merchant apps, and web and mobile SDKs built on a shared client core, so checkout and operations tooling are part of the same story.

The trade-off is surface area. Being the integration point for cards, payouts, fraud, vaulting and tokenization means the switch becomes a system you operate, not a library you import; the local setup itself offers standard, full and minimal profiles for that reason. The connector coverage is also uneven by nature: the README advertises 100+ processors and dedicated guides covering credentials, webhooks and supported payment methods, but each guide is the authority for what that processor can actually do.

Who should try it

A good fit is a team already using two or more processors, or planning to, that wants routing and retry logic outside application code and is willing to run or host the service. It also suits partners and platforms that want to embed payments configuration into their own product, given the embeddable control-center components and client SDKs. A poor fit is a small product that is happy with one gateway and its hosted checkout — the operational overhead buys nothing there.

There are two realistic entry paths: a hosted sandbox for exploring the control center and testing payments without setup, or a local Docker-based setup described in the project instructions and the setup guide. The hosted path lowers the cost of evaluating the UI; the self-hosted path is the one that reflects what running it in production looks like.

Requirements and limitations

The main commitment is operational: the app server, and optionally monitoring, schedulers, vault and dashboard, need to be deployed and kept running, with deployment tooling offered through Terraform and Helm. Connector credentials and webhook configuration are per-processor work that follows each connector guide, not something the switch can guess. The README describes the platform as PCI compliant, but it does not turn compliance into a turnkey property — scoping, storage of sensitive data and the vault's role still need to be understood for your setup. Choosing the lighter connector library avoids running the full switch, but it also means giving up the routing and operational features that live in the core.

HotRepo's take

HotRepo's only dated signal is a Rust monthly-board rank of #15 with +1,643 for the month on 2026-10-25; there is no comparable daily history, so persistence of interest cannot be judged from that snapshot. The repo is about four years old, and the payments primer thread from 2023 shows discussion around payments education rather than this implementation. Before committing, verify the specific connector guide for your primary processor, since the supported payment methods and failure modes documented there determine whether migration is realistic.