Access the entire payment ecosystem with a Single API. Hyperswitch connects you to multiple payment processors to embrace diversity. It improves payment success rates and reduces payment costs, ops & dev efforts. Built on Rust as an open-source product.
This is the 3rd launch from Juspay Hyperswitch. View more
Hyperswitch Prism
Launched this week
Prism is a stateless payments library that connects your app to multiple payment processors. You can integrate once and point to any payment processor; add fallbacks for redundancy, switch processors based on routing rules - all by swapping a few lines of code.
No sign-up needed. No infra setup needed.
Actively maintained within the Juspay Hyperswitch production environment. Apache-2.0 licensed, polyglot ready, with SDKs for Node, Python, Java and Rust.
Free
Launch Team / Built With
Juspay Hyperswitch
Hello Product Hunters 👋
I’m Jeeva from Juspay, the team behind Hyperswitch, the open-source payments platform with 42K+ GitHub stars.
Today, we’re launching Prism: an open-source library that gives developers one common integration layer across payment processors like Stripe, Adyen, Braintree, Checkout, and others.
Most teams start with a single payment processors. That works well early on. But as the business grows, payments get more complex:
Early growth: new markets need new processors, and customers expect local payment methods.
Scaling up: finance teams want pricing leverage, engineering teams need reliability, and maintaining payment processor integrations becomes ongoing work.
Prism helps teams avoid locking in to a single payment processors from the start.
With Prism, you get:
one schema across multiple payment processors
a stateless integration layer
no database and no stored PII
SDKs for Node, Python, Java, and Rust
open-source flexibility without infra setup or sales conversations
Our goal is simple: make payment processors integrations easier to build, maintain, and change over time.
When did payments start getting operationally complex for your business?
1Page
@jeeva_ramachandran This is awesome
Since it's polyglot ready, do you provide unified SDKs that maintain consistent error handling across all supported languages, or is the logic primarily at the library level?
Juspay Hyperswitch
@rivra_dev The SDKs provide unified error handling across all languages through language-specific wrappers generated from a single source of truth.
Congrats on the launch! I like the stateless approach - makes sense for teams that don’t want a full payment orchestration platform yet. One thing I’d look for in a business app is good examples around retries, idempotency, and status changes.
Do you have sample flows for failed payment -> retry -> reconciliation?
Juspay Hyperswitch
@ihorperkovskyi Thanks! Retries, idempotency, and reconciliation are handled at the application layer. The SDK focuses on providing the processors integration, while teams can implement their own retry logic, idempotency handling, and reconciliation flows based on their specific requirements.
We don’t provide built-in samples for these flows since the implementation usually varies from team to team.Prism is all about unification for payment processors
@jeeva_ramachandran Got it, that makes sense. Processor unification is a clean boundary.
A short guide with recommended patterns for retries/idempotency/reconciliation could still be useful later, even if those flows stay at the app layer.
The plug-n-switch primitive maps almost perfectly onto how project finance modelers handle module swaps — you don't rewrite the model when the offtake structure shifts from PPA to merchant; you swap the revenue module while the rest of the workbook keeps integrating cleanly. Hyperswitch's redundancy-and-routing layer is the same idea applied at the payments edge. The hard part in both worlds is contract surface: making the swap zero-rewrite means the interface has to anticipate every parameter the new module might want.
This is also the half of project-finance template design that's painfully underrated. I host a small library of these on Eloquens (https://www.eloquens.com/channel/samir-asadov-cfa) and the templates that get reused most aren't the ones with the fanciest formulas — they're the ones where the module boundaries hold up under change. Curious how you decided on what's inside vs. outside the Prism interface contract — did you back-solve from the messiest real-world processor migration?
Juspay Hyperswitch
@samir_asadov Absolutely, the contract part is the most important to keep up with underlying diversity.
In the case of Prism's interface boundary - we had the experience of building and running processor abstraction on Juspay hyperswitch payment orchestration platform for many years. It had integrations that evolved over time and we had a clear picture of what stays inside the module boundary.
Payment processor domain stays inside the interface(data transformations, error mappings, status mappings).
Everything else stays outside the library (business logic to wire API calls, API credentials)
All the data transformations lies, processor endpoint stay inside the library.
How do you handle tracking events and reconciliation if Prism itself doesn’t store anything?
Juspay Hyperswitch
Hi @othman_katim Prism's goal is to unify events, statuses, errors across payment processors.
The user of prism is expected to store the unified events, statuses and errors on the application.
Payment orchestration platforms are a stateful solutions which can unify as well as store events (which Juspay hyperswitch does). But Payment orchestration platforms may become an overkill for some businesses who just need the diversity layer. Hence Prism was intended to solve that problem.
Flexprice
Congratulations on the launch @Juspay Hyperswitch team!
This is exactly what we need. Please add golang sdk as well (our stack is on golang)
Juspay Hyperswitch
@nikhil_mishra7 Thanks for the support!
Great to hear Hyperswitch-Prism fits your needs. We’re actively working on adding new SDK's and it’s currently under development. Stay tuned — we’ll be sharing updates soon
Cool! Does the system automatically determine which payment method is best to use for a specific user, or does it only work based on predefined rules? We have a travel service with traffic from 200+ countries, and different regions require different payment providers, otherwise there will be a high decline rate. Do you solve this problem?
Juspay Hyperswitch
@natalia_iankovych Thanks. We do solve the problem you stated with Juspay Hyperswitch. I would recommend checking out https://hyperswitch.io/, which solves for authorization rates with
(i) dynamic checkpout page presentation with the appropriate payment methods
(ii) ML based dynamic routing decisions
(iii) routing rules (predefined rules),
(iv) smart retries based on error codes from payment providers.
Prism is an extraction of the integrations from the Juspay Hyperswitch platform, to make it easy for platforms which only need the integrations to multiple providers.
If the problem is
- too much engineering effort in implementing and maintaining integrations -> Prism is the solution
- solving for authorization uplift, dynamic routing, cost reduction in addition to integration -> Juspay hyperswitch platform is the solution