More than a payment gateway
Hyperswitch sits between an application and payment processors. Your checkout talks to one orchestration API; Hyperswitch translates requests for Stripe, Adyen, Braintree, Worldpay, Checkout.com, Cybersource, and more than 100 other processors. The point is not merely a shared request format. It can route transactions, retry failures, connect alternate payment methods, store payment credentials, reconcile records, and expose costs and outcomes through a control center.
That scope makes it attractive to merchants whose payment stack has become a product of its own. A company can route different countries or card types to different processors, retain a second path during an outage, or change an acquirer without rebuilding checkout from zero. The Apache-2.0 core is written mainly in Rust, so the crucial routing code is available for inspection and modification.
It also makes Hyperswitch a poor fit for many businesses. If Stripe alone meets your needs, adding an independent switch creates another network hop, another database, another deployment, and another place where states can disagree. Open source gives control, not simplicity.
The quickstart is only the showroom
The local experience is thoughtfully packaged. Clone the repository's latest branch, run scripts/setup.sh, and choose a minimal, standard, or full profile. The script detects Docker or Podman. Standard adds the app server and Control Center, while full also includes monitoring and schedulers. A hosted sandbox lets a team explore connectors, logs, routing rules, retries, and test payments before installing anything.
This is the right way to evaluate a complex platform. Configure one test processor, make a payment, inspect its lifecycle, send a webhook, refund it, and watch the dashboard. Do not mistake that success for a production readiness test. Real deployment means durable state, backups, migrations, high availability, processor secrets, encryption, webhook authenticity, observability, incident procedures, and careful control over who can change routing.
Even local reproducibility can bite. Open issue 13072 reports that docker compose up failed after the unpinned postgres:latest image moved to PostgreSQL 18 and encountered an older data volume. Deleting the volume works for disposable development data, not for a real merchant database. The broader lesson is to pin every production dependency and test migrations against a restored copy.
Connector count is not connector equivalence
More than 100 integrations is a major advantage, but a connector name alone says little about the exact flow you need. Cards, bank debit, wallets, mandates, partial capture, disputes, refunds, payouts, three-domain secure authentication, and regional methods can have different coverage within the same processor. Hyperswitch provides dedicated connector guides, and the latest release notes show constant connector-specific additions and fixes. Treat the capability table and tests as the contract, not the headline count.
Two open reports illustrate the operational risk. Issue 13180 says some connector HTTP 500 and 502 failures return HTTP 200 from Hyperswitch with processing or pending, leaving error details in secondary fields. An integration that trusts only HTTP status could mistake an unsent payment or refund for ongoing work. Issue 13182 reports that two simultaneous refunds can both pass a pre-check and together exceed the captured payment amount. These are user reports, not findings independently reproduced for this review, but both include detailed test setups and material failure modes. A prospective operator should verify their status and build regression tests before live traffic.
Issue 13164 separately reports Stripe test-mode warnings when the connector sends raw card numbers rather than a pre-created PaymentMethod identifier. That choice affects architecture and compliance scope, even when transport and storage protections are correct. Decide early whether Hyperswitch, a separate vault, or the processor should ever see primary account numbers in your chosen checkout flow.
Compliance stays with the operator
The README describes a PCI-compliant vault service and support for external vaults such as VGS and TokenEx. That is useful architecture, but deploying open-source components does not automatically make the resulting merchant environment compliant. Network boundaries, access controls, key custody, logging, patching, retention, incident response, and yearly validation still belong to the organization operating the system.
Bring-your-own-vault support may reduce migration pain for an established merchant. A small team without payments security expertise should prefer hosted tokenization and keep sensitive card data out of its systems. The expensive part of payment infrastructure is not accepting the first successful test charge; it is preserving correct money and state through retries, timeouts, duplicate events, regional rules, fraud, disputes, and outages.
Releases and project health
Hyperswitch had 43,466 stars, an Apache-2.0 license, and 2,059 open issues and pull requests when researched. The large open count includes a heavy pull-request stream and should not be described as 2,059 bugs. The last push was August 12, 2026, and dozens of connector, recovery, database, and test changes were active that day. Development velocity is exceptional.
The latest GitHub release was v1.125.0, published July 10, 2026. Its long notes contain connector features, API changes, analytics work, storage changes, and many fixes. That is evidence of maintenance, but also a warning to pin versions and read every upgrade note. Payment behavior can vary in details that application teams normally regard as business logic.
Who should choose it
Choose Hyperswitch when processor diversity is already necessary, authorization rates or routing costs justify investment, and named engineers will own the system. Begin in the hosted sandbox, then run the Docker stack with test accounts for every required processor and method. Exercise success, decline, timeout, duplicate webhook, partial capture, concurrent refund, and processor-outage paths. Only then compare self-hosting with the managed Hyperswitch offering or another provider.
For a startup taking its first payments, Stripe or another managed processor is usually the better decision. For a larger merchant trapped behind custom integrations to several processors, Hyperswitch can replace expensive glue with a coherent, inspectable platform. It earns a serious evaluation, but only organizations prepared to operate financial infrastructure should put it in the critical path.