Hyperswitch Prism

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?

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!

Let’s go!!

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?

Congratulations on the launch @Juspay Hyperswitch team!This is exactly what we need. Please add golang sdk as well (our stack is on golang)

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?

How do you handle tracking events and reconciliation if Prism itself doesn’t store anything?

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 processorsa stateless integration layerno database and no stored PIISDKs for Node, Python, Java, and Rustopen-source flexibility without infra setup or sales conversationsOur 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?