Hyperswitch Prism - Library to plug-n-switch payment processors
by•
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.
Replies
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
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
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.
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.
skillsync
Let’s go!!
Station
The stateless approach here is pretty interesting. A lot of teams just want the flexibility layer without adopting a whole payment orchestration stack.
Feels like a clean middle ground. Congrats on the launch!
Juspay Hyperswitch
@campritchard Thanks for the feedback and support.
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.
Been waiting for this one. Congrats team 👏
We're rolling Hyperswitch and Prism into a large financial services group to give us a cleaner path through a tangled legacy payments stack. The stateless library approach is the right call for us, it slots in without forcing teams to adopt a whole platform, and the routing/fallback story means we can move at our own pace instead of doing a big-bang migration.
Great work on shipping something this thoughtful as open source + polyglot SDKs is the cherry on top.
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