hyperswitch-prism

What is hyperswitch-prism?

Hyperswitch Prism is a stateless, unified connector library for integrating with payment processors. It is designed to provide a single request/interaction schema so the same call patterns can be used across multiple payment processors with fewer code changes.

Prism was extracted and maintained by the team behind Hyperswitch, an open-source payments platform. The repository describes Prism as a transformation layer that focuses on connector integration consistency while leaving concerns like vault/tokenization, retries, and routing logic to Hyperswitch.

Key Features

• One unified request schema across connectors: The same authorize call works against multiple processors (e.g., Stripe, Adyen) without additional lines of code dedicated to each processor.
• Stateless library (no database, no stored PII): Prism does not require a database and avoids storing personal data; it states that credentials are not stored or logged by the library and exist only for the lifetime of the HTTP client.
• PCI scope control by design: The library can avoid bringing card data into Prism; the card data flowing (or not flowing) through the library is positioned as a choice, with the ability to use a payment-processor vault or a user-provided PCI-certified vault.
• Continuous connector testing with a published status model: Connectors are continuously tested against real sandbox/production environments, with a status legend covering supported, in-progress/partial, and needs-validation states.
• Idiomatic, multi-language interface (per repository docs): Prism is described as a Type-safe, idiomatic interface packaged as a multi-language SDK.

How to Use hyperswitch-prism

1. Select the Prism SDK for your language and review the SDK guide for authentication and request patterns.
2. Write payment requests using Prism’s unified schema (for example, using the same authorize call shape across different payment processors).
3. Choose where sensitive payment data is handled: use your own PCI-certified vault or a payment processor’s vault, aligned with the repository’s note that vault/tokenization services are not built into Prism.
4. Validate connector coverage for your needs using the project’s connector coverage/status page, since Prism describes varying levels of support across connectors.

Use Cases

• Multi-processor checkout integration: You want to route payment operations to more than one payment processor while keeping application code changes small by relying on Prism’s unified request schema.
• Reducing state and stored data in your integration layer: Your team prefers a stateless connector layer where Prism itself does not require a database and does not store or log credentials.
• Aligning with PCI responsibilities via your vault choice: You want to control whether card data is handled inside your infrastructure and choose between a payment-processor vault or your own PCI-certified vault.
• Engineering teams maintaining connector logic over time: You need a connector integration layer that is continuously tested against sandbox/production and tracked with connector-by-connector status.
• Transformation-layer integration within a larger payments platform: You use Prism as the transformation layer, while implementing retries/routing logic elsewhere (the repository points to Juspay Hyperswitch for these aspects).

FAQ

Is Prism responsible for retries and routing logic? No. The repository states that retries or routing logic live in Juspay Hyperswitch; Prism is presented as a transformation layer.

Does Prism include a built-in vault or tokenization service? No. This is described as a design choice; you may bring your own vault or use the payment processor’s vault.

Does Prism store credentials or PII? The repository states that credentials are not stored or logged by the library, it is stateless with no database, and it does not store PII. It also notes credentials live only for the lifetime of your HTTP client.

How can I tell which payment processors and payment methods are supported? Prism publishes connector coverage with a legend indicating supported (fully implemented and tested), not applicable/unsupported, in progress/partial, and implementation needing validation against live environments.

How many payment calls do I need to implement for multiple processors? The repository’s core claim is that a single request schema can let the same authorize call work across processors such as Stripe and Adyen without additional processor-specific code lines.

Alternatives

• Direct per-processor integrations (multiple SDKs / APIs): Implement against each payment processor separately. This can increase processor-specific code and maintenance compared to a unified schema.
• Payment orchestration platforms / SaaS connectors: Use third-party orchestration to abstract multiple processors. These alternatives typically shift complexity to the platform rather than using an integration library as the transformation layer.
• Other stateless connector libraries or middleware layers: Choose middleware that normalizes payment requests across providers. Differences will be in how they handle vault/tokenization, whether they keep state, and how connector coverage/testing is managed.
• Use Hyperswitch connector logic directly (without Prism as an extraction): If you already operate within Hyperswitch, you may rely on the broader platform components instead of adopting Prism as a standalone unified library.