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
I was reading through the comments about Prism being stateless. Since it doesn’t store PII or transaction state, does the team have a recommended way for us to map our internal Order IDs to the different Processor IDs (like a Stripe PI or Adyen reference) while keeping the implementation clean? Would love to know the best practice here!
Juspay Hyperswitch
@om_harsh You're right that Prism is fully stateless — it doesn't generate IDs, store PII, or persist transaction state.
The team has actually documented the recommended pattern for exactly this — there's a doc on ID and Object Modeling that's worth a read. The TL;DR:
Prism's interface uses a consistent entity_domain_id grammar across every connector, so you don't have to maintain per-processor ID handling. The fields you'll care about:
- merchant_transaction_id — your internal payment ID (you generate it, Prism just forwards it to the processor)
- merchant_order_id — your order reference
- merchant_refund_id — your refund reference
- connector_transaction_id — the processor's ID (Stripe's pi_xxx, Adyen's pspReference, etc.) — Prism returns this on the Authorize response
So the clean pattern is:
1. On PaymentServiceAuthorize, send your Order ID as merchant_transaction_id / merchant_order_id.
2. From the response, capture connector_transaction_id and store the mapping (merchant_transaction_id → connector, connector_transaction_id) in your DB.
3. For PSync / Capture / Refund / Void, pass both back — Prism stays stateless, your DB is the source of truth, and the grammar is identical whether you route to Stripe, Adyen, or anything else.
Same pattern extends to merchant_charge_id for recurring and merchant_event_id for webhooks.