Deploy Hyperswitch Stripe

Deploy and Host self hosted Hyperswitch Stripe (Open-Source Payment Orchestration in Front of Stripe) on Railway

This template runs self-hosted Hyperswitch in front of your existing Stripe account.

About Hosting Hyperswitch Stripe open-source software on Railway (self hosted Hyperswitch with the Stripe connector template)

This template runs the Hyperswitch router, the Control Center dashboard, Postgres and Redis as four services in your own Railway project.

Why Deploy Hyperswitch Stripe, the Stripe alternative on Railway (Railway Free Trial)

Stripe is a solid processor, but one acquirer means one fee structure and no fallback when authorizations fail.

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Hyperswitch Stripe on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Railway vs Other Hosting Providers and VPS for Hyperswitch Stripe self hosting

Hyperswitch in front of Stripe means keeping four services running: the router, the dashboard, Postgres and Redis.

Choose Railway to get a Stripe test payment routed through Hyperswitch quickly, or a VPS if you want full control over every layer.

Common Use Cases for hosted Hyperswitch Stripe

• Keeping Stripe while adding a backup processor: You keep your existing Stripe account as the primary connector and add a second processor in the Control Center, so a Stripe outage or a decline spike doesn't take your checkout down with it.
• Retrying failed payments on another connector: When a card fails on Stripe, you can configure smart retries that send the same payment to a second connector instead of just asking the customer to try again.
• Testing routing rules in sandbox: Set up volume splits or priority rules against Stripe test mode and a sandbox from another processor, then watch how traffic moves before you touch production.
• One payments API across Stripe and regional processors: Your backend keeps calling POST /payments, and you add regional processors later without rewriting your integration.
• Comparing auth rates per connector: Run the same test traffic through Stripe and a second processor and compare results side by side to see which one approves more transactions for your mix of cards.

Dependencies for Hyperswitch Stripe Docker hosted on Railway

Hyperswitch Stripe runs as four services on Railway: the router that exposes the payments API, the Control Center dashboard where you connect Stripe, Postgres, and Redis.

Deployment Dependencies for Managed Hyperswitch Stripe Service (Payment Orchestration)

• hyperswitch-router: image ghcr.io/onepush-dev/hyperswitch-router:v1.128.0, public port 8080, health check at /health.
• control-center: image juspaydotin/hyperswitch-control-center:v1.38.10, public port 9000, the merchant dashboard.
• Postgres 18 and Redis 8.2 as managed database services.
• Stripe account: a test mode secret key (sk_test) from Developers, API keys.

Implementation Details for Hyperswitch Stripe (Using Hyperswitch official docker image)

The router reads its database and Redis settings from variables that reference the Postgres and Redis services, so you rarely edit them by hand.

How does Hyperswitch Stripe compare against other ways to add a second processor next to Stripe

Hyperswitch vs Stripe alone (Stripe Direct Integration)

• Single processor: Stripe alone means one acquirer and no orchestration layer, so every payment goes to Stripe regardless of its performance that day.
• Stripe wins on simplicity: If you only need Stripe, calling its API directly means fewer moving parts. Hyperswitch adds a router, a dashboard, Postgres and Redis that you now run.
• Hyperswitch adds options: Keep Stripe as the primary connector and add a second processor behind the same payments API.

Hyperswitch vs Spreedly (Spreedly Alternative)

• Open source vs SaaS: Hyperswitch is Apache-2.0 and you run it yourself, while Spreedly is a commercial hosted service.
• Spreedly wins on maturity: It has a long track record, a large gateway catalog and a support team you can call. Hyperswitch is younger and you debug more yourself.
• Hyperswitch wins on control: Card data and the vault live in your infrastructure, though that also means you carry the PCI scope.

Hyperswitch vs Primer (Primer Alternative)

• Commercial orchestration: Primer is a hosted product with no-code workflows aimed at checkout optimization.
• Primer wins on workflows: Its visual builder is likely more polished than anything you assemble from a self-hosted router.
• Hyperswitch wins on ownership: You can read the Rust source, change routing logic in code, and skip a platform fee layered on your processors.

Hyperswitch vs building your own processor abstraction (Custom Payment Abstraction)

• Engineering cost: A home-built layer means you design retries, routing, webhook normalization and reconciliation yourself, which takes months to maintain.
• Custom wins on fit: It can match your exact business rules and data model with no unused features.
• Hyperswitch wins on time to test: Connectors, the unified API and routing already exist, so you can test a second processor in sandbox in an afternoon.

How to use Hyperswitch Stripe (the OSS payment orchestrator)?

Here's the first-day path. Your backend will call the Hyperswitch router, and Hyperswitch will call Stripe as a connector.

1. Open the control-center domain and sign up.
2. Create a merchant and a business profile.
3. Open Connectors and choose Stripe.
4. Paste your Stripe test secret key and enable payment methods.
5. Copy the webhook URL Hyperswitch shows, then add it in Stripe under Developers, Webhooks.
6. Create a Hyperswitch API key for your backend.
7. Test with POST /payments and a Stripe test card:

curl -X POST https://your-router-domain/payments \
  -H "api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"amount": 1000, "currency": "USD", "confirm": true, "payment_method": "card", "payment_method_data": {"card": {"card_number": "4242424242424242", "card_exp_month": "12", "card_exp_year": "30", "card_cvc": "123"}}}'

If the payment returns succeeded, the Stripe connector is wired correctly.

How to self host Hyperswitch Stripe on other VPS Services (Hyperswitch self hosting guide)

Running Hyperswitch yourself on a VPS means you manage the router, the dashboard, Postgres and Redis. Here is the short path.

Clone the Repository

Pull the upstream code from GitHub so you get the official compose file and setup helper.

git clone https://github.com/juspay/hyperswitch
cd hyperswitch

Install Dependencies

You need Docker and the Docker Compose plugin on the VPS. The repo's setup script is the easiest way to prepare the stack.

sudo apt-get update && sudo apt-get install -y docker.io docker-compose-plugin
./scripts/setup.sh

Configure Environment Variables

Generate the secret keys (admin API key, JWT secret, and the 64-character hex keys), and back them up. Point the dashboard at your router domain.

# keep these secret and back them up
ROUTER__SECRETS__ADMIN_API_KEY=your-admin-key
MASTER_ENC_KEY=64-hex-characters

Start the Hyperswitch Stripe Application

Bring the stack up in the background, then check the router health endpoint.

docker compose up -d
curl http://localhost:8080/health

Railway handles the Postgres and Redis wiring, the database migrations and the public domains for you, which is the part you would otherwise maintain yourself.

Official Pricing of Hyperswitch Stripe (Hyperswitch pricing)

Hyperswitch is open source under Apache-2.0, so self hosting the router and Control Center costs nothing in software fees.

Hyperswitch Stripe cloud vs self hosted comparison (Pricing, features, costs, and more)

Hyperswitch is free to self host under Apache-2.0, so the real choice is who runs the router, dashboard and databases.

Monthly cost of self hosting Hyperswitch Stripe on Railway

Expect roughly $15-30 per month for the router, Control Center, Postgres and Redis at light use.

System Requirements for Hosting Hyperswitch Stripe on a VPS

Running it yourself means a Linux host with Docker and Docker Compose, enough RAM for Postgres, Redis and the Rust router, and a public domain with TLS in front of ports 8080 and 9000.

Frequently Asked Questions (FAQs)

Do I need a new Stripe account to use Hyperswitch?

No, you can keep your existing Stripe account.

Why does Stripe ask about raw card data?

Raw card data means card numbers pass through Hyperswitch to Stripe's API instead of going through Stripe Elements.

Can I keep Stripe Checkout?

Stripe Checkout runs on Stripe's hosted pages, so it does not go through Hyperswitch's payments API.

Where do refunds happen?

Refunds are issued through Hyperswitch's API and forwarded to Stripe as the connector.

Which webhooks matter?

Two sets matter.

Is this production ready?

Not as deployed here.