Productivity
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:
The fastest and easiest way to try Hyperswitch is via our CDK scripts
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.
Sign-in to your AWS console.
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:
git clone --depth 1 --branch latest https://github.com/juspay/hyperswitch
cd hyperswitch
docker compose up -d
This will start the app server, web client and control center.
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:
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
Value Added Services
Enterprise Support
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.
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.
payments_core
) is written to be more readable than pure-idiomatic.Get updates on Hyperswitch development and chat with the community:
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! 🥂