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

New to Rust? Hyperswitch is the perfect place to start this hacktoberfest! 😁

⭐️ If you're new to Hacktoberfest, you can learn more and register to participate here. Registration is from September 26th - October 31st.

Hyperswitch is an open source payments switch to make payments fast, reliable, and, affordable. It lets you connect with multiple payment processors and route traffic effortlessly, all with a single API integration.

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

Hyperswitch is wire-compatible with top processors like Stripe, making it easy to integrate.

Ways to get started with Hyperswitch:

1. Try it in our Sandbox Environment: Fast and easy to start. No code or setup is required in your system, learn more

2. A simple demo of integrating Hyperswitch with your React App, Try our React Demo App.

3. Install in your local system: Configurations and setup required in your system. Suitable if you like to customise the core offering, setup guide

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, 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.

🦀 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:

• Read and subscribe to the official Hyperswitch blog.
• Join our Discord server.
• Join our Slack workspace.
• Ask and explore our GitHub Discussions.

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! 🥂