Quick Start Guide • Local Setup Guide • Fast Integration for Stripe Users • API Docs • Supported Features •
What's Included • Join us in building HyperSwitch • Community • Bugs and feature requests • FAQs • Versioning • Copyright and License

Hyperswitch is a community-led, open payments switch to enable access to the best payments infrastructure for every digital business.

Using Hyperswitch, you can:

• ⬇️ Reduce dependency on a single processor like Stripe or Braintree
• 🧑‍💻 Reduce Dev effort by 90% to add & maintain integrations
• 🚀 Improve success rates with seamless failover and auto-retries
• 💸 Reduce processing fees with smart routing
• 🎨 Customize payment flows with full visibility and control
• 🌐 Increase business reach with local/alternate payment methods

The fastest and easiest way to try Hyperswitch is via our CDK scripts

1. Click on the following button for a quick standalone deployment on AWS, suitable for prototyping. No code or setup is required in your system and the deployment is covered within the AWS free-tier setup.

   

2. Sign-in to your AWS console.

3. Follow the instructions provided on the console to successfully deploy Hyperswitch

You can run Hyperswitch on your system using Docker Compose after cloning this repository:

docker compose up -d

This will start the payments router, the primary component within Hyperswitch.

Check out the local setup guide for a more comprehensive setup, which includes the scheduler and monitoring services.

If you are already using Stripe, integrating with Hyperswitch is fun, fast & easy. Try the steps below to get a feel for how quick the setup is:

1. Get API keys from our dashboard.
2. Follow the instructions detailed on our documentation page.

As of Sept 2023, we support 50+ payment processors and multiple global payment methods. In addition, we are continuously integrating new processors based on their reach and community requests. Our target is to support 100+ processors by H2 2023. You can find the latest list of payment processors, supported methods, and features here.

In addition to all the features of the open-source product, our hosted version provides features and support to manage your payment infrastructure, compliance, analytics, and operations end-to-end:

• System Performance & Reliability

  • Scalable to support 50000 tps
  • System uptime of up to 99.99%
  • Deployment with very low latency
  • Hosting option with AWS or GCP

• Value Added Services

  • Compliance Support, incl. PCI, GDPR, Card Vault etc
  • Customise the integration or payment experience
  • Control Center with elaborate analytics and reporting
  • Integration with Risk Management Solutions
  • Integration with other platforms like Subscription, E-commerce, Accounting, etc.

• Enterprise Support

  • 24x7 Email / On-call Support
  • Dedicated Relationship Manager
  • Custom dashboards with deep analytics, alerts, and reporting
  • Expert team to consult and improve business metrics

You can try the hosted version in our sandbox.

Got more questions? Please refer to our FAQs page.

Within the repositories, you'll find the following directories and files, logically grouping common assets and providing both compiled and minified variations.

The current setup contains a single repo, which contains the core payment router and the various connector integrations under the src/connector sub-directory.

.
├── config                             : Initial startup config files for the router
├── connector-template                 : boilerplate code for connectors
├── crates                             : sub-crates
│   ├── api_models                     : Request/response models for the `router` crate
│   ├── cards                          : Types to handle card masking and validation
│   ├── common_enums                   : Enums shared across the request/response types and database types
│   ├── common_utils                   : Utilities shared across `router` and other crates
│   ├── data_models                    : Represents the data/domain models used by the business/domain layer
│   ├── diesel_models                  : Database models shared across `router` and other crates
│   ├── drainer                        : Application that reads Redis streams and executes queries in database
│   ├── external_services              : Interactions with external systems like emails, AWS KMS, etc.
│   ├── masking                        : Personal Identifiable Information protection
│   ├── redis_interface                : A user-friendly interface to Redis
│   ├── router                         : Main crate of the project
│   ├── router_derive                  : Utility macros for the `router` crate
│   ├── router_env                     : Environment of payment router: logger, basic config, its environment awareness
│   ├── scheduler                      : Scheduling and executing deferred tasks like mail scheduling
│   ├── storage_impl                   : Storage backend implementations for data structures & objects
│   └── test_utils                     : Utilities to run Postman and connector UI tests
├── docs                               : hand-written documentation
├── loadtest                           : performance benchmarking setup
├── migrations                         : diesel DB setup
├── monitoring                         : Grafana & Loki monitoring related configuration files
├── openapi                            : automatically generated OpenAPI spec
├── postman                            : postman scenarios API
└── scripts                            : automation, testing, and other utility scripts

Payments should be open, fast, reliable and affordable to serve the billions of people at scale.

Globally payment diversity has been growing at a rapid pace. There are hundreds of payment processors and new payment methods like BNPL, RTP etc. Businesses need to embrace this diversity to increase conversion, reduce cost and improve control. But integrating and maintaining multiple processors needs a lot of dev effort. Why should devs across companies repeat the same work? Why can't it be unified and reused? Hence, Hyperswitch was born to create that reusable core and let companies build and customise it as per their specific requirements.

1. Embrace Payments Diversity: It will drive innovation in the ecosystem in multiple ways.
2. Make it Open Source: Increases trust; Improves the quality and reusability of software.
3. Be community driven: It enables participatory design and development.
4. Build it like Systems Software: This sets a high bar for Reliability, Security and Performance SLAs.
5. Maximise Value Creation: For developers, customers & partners.

This project is being created and maintained by Juspay, South Asia's largest payments orchestrator/switch, processing more than 50 Million transactions per day. The solution has 1Mn+ lines of Haskell code built over ten years. Hyperswitch leverages our experience in building large-scale, enterprise-grade & frictionless payment solutions. It is built afresh for the global markets as an open-source product in Rust. We are long-term committed to building and making it useful for the community.

The product roadmap is open for the community's feedback. We shall evolve a prioritisation process that is open and community-driven. We welcome contributions from the community. Please read through our contributing guidelines. Included are directions for opening issues, coding standards, and notes on development.

• We appreciate all types of contributions: code, documentation, demo creation, or some new way you want to contribute to us. We will reward every contribution with a Hyperswitch branded t-shirt.
• 🦀 Important note for Rust developers: We aim for contributions from the community across a broad range of tracks. Hence, we have prioritised simplicity and code readability over purely idiomatic code. For example, some of the code in core functions (e.g., payments_core) is written to be more readable than pure-idiomatic.

Get updates on Hyperswitch development and chat with the community:

• Discord server for questions related to contributing to hyperswitch, questions about the architecture, components, etc.
• Slack workspace for questions related to integrating hyperswitch, integrating a connector in hyperswitch, etc.
• GitHub Discussions to drop feature requests or suggest anything payments-related you need for your stack.

Please read the issue guidelines and search for existing and closed issues. If your problem or idea is not addressed yet, please open a new issue.

Check the CHANGELOG.md file for details.

This product is licensed under the Apache 2.0 License.

Thank you for your support in hyperswitch's growth. Keep up the great work! 🥂