hyperswitch-prism

Was ist hyperswitch-prism?

hyperswitch-prism ist eine stateless, einheitliche Connector-Bibliothek für die Integration mit Payment-Processoren. Sie ist so konzipiert, dass sie ein einheitliches Request-/Interaktions-Schema bietet, damit dieselben Aufrufmuster bei mehreren Payment-Processoren mit weniger Code-Änderungen verwendet werden können.

Prism wurde vom Team hinter Hyperswitch extrahiert und gepflegt, einer Open-Source-Zahlungsplattform. Das Repository beschreibt Prism als Transformationsschicht, die sich auf die Konsistenz der Connector-Integration konzentriert, während Themen wie Vault/Tokenization, Retries und Routing-Logik Hyperswitch überlassen werden.

Wichtige Funktionen

• Ein einheitliches Request-Schema über alle Connectoren: Derselbe Authorize-Aufruf funktioniert bei mehreren Processoren (z. B. Stripe, Adyen), ohne zusätzliche Codezeilen pro Prozessor.
• Stateless-Bibliothek (keine Datenbank, keine gespeicherten PII): Prism benötigt keine Datenbank und speichert keine personenbezogenen Daten; es wird angegeben, dass Credentials nicht gespeichert oder geloggt werden und nur für die Lebensdauer des HTTP-Clients existieren.
• PCI-Scope-Kontrolle durch Design: Die Bibliothek kann Karten-Daten aus Prism heraushalten; der Datenfluss (oder Nichtfluss) von Karten-Daten durch die Bibliothek wird als Wahlmöglichkeit positioniert, mit der Option, einen Payment-Processor-Vault oder einen benutzerseitigen PCI-zertifizierten Vault zu nutzen.
• Kontinuierliches Connector-Testing mit publiziertem Status-Modell: Connectoren werden kontinuierlich gegen echte Sandbox-/Produktionsumgebungen getestet, mit einer Status-Legende für unterstützt, in Arbeit/teilweise und validierungsbedürftig.
• Idiomatische, mehrsprachige Schnittstelle (laut Repository-Docs): Prism wird als type-sichere, idiomatische Schnittstelle beschrieben, verpackt als Multi-Language-SDK.

So verwenden Sie hyperswitch-prism

1. Wählen Sie das Prism-SDK für Ihre Sprache und prüfen Sie den SDK-Leitfaden zu Authentifizierung und Request-Mustern.
2. Schreiben Sie Payment-Requests mit dem einheitlichen Schema von Prism (z. B. denselben Authorize-Aufruf-Shape über verschiedene Payment-Processoren).
3. Wählen Sie, wo sensible Payment-Daten gehandhabt werden: Nutzen Sie Ihren eigenen PCI-zertifizierten Vault oder einen Vault des Payment-Processoren, passend zur Repository-Notiz, dass Vault/Tokenization-Dienste nicht in Prism integriert sind.
4. Validieren Sie die Connector-Abdeckung für Ihre Anforderungen über die Connector-Coverage-/Status-Seite des Projekts, da Prism unterschiedliche Unterstützungsstufen über die Connectoren beschreibt.

Anwendungsfälle

• Multi-Processor-Checkout-Integration: Sie möchten Payment-Operationen an mehr als einen Payment-Prozessor routen, während App-Code-Änderungen klein bleiben durch Prism’s einheitliches Request-Schema.
• Reduzierung von State und gespeicherten Daten in Ihrer Integrationsschicht: Ihr Team bevorzugt eine stateless Connector-Schicht, bei der Prism selbst keine Datenbank benötigt und Credentials nicht speichert oder loggt.
• Ausrichtung auf PCI-Verantwortlichkeiten via Vault-Wahl: Sie möchten steuern, ob Karten-Daten in Ihrer Infrastruktur gehandhabt werden, und zwischen Payment-Processor-Vault oder eigenem PCI-zertifiziertem Vault wählen.
• Engineering-Teams, die Connector-Logik langfristig warten: Sie benötigen eine Connector-Integrationsschicht, die kontinuierlich gegen Sandbox/Produktion getestet und mit Connector-spezifischem Status verfolgt wird.
• Transformationsschicht-Integration in einer größeren Payments-Plattform: Sie nutzen Prism als Transformationsschicht, während Retries/Routing-Logik anderswo implementiert wird (das Repository verweist auf Juspay Hyperswitch für diese Aspekte).

FAQ

Ist Prism für Retries und Routing-Logik verantwortlich?
Nein. Das Repository gibt an, dass Retries oder Routing-Logik in Juspay Hyperswitch liegen; Prism ist eine Transformationsschicht.

Enthält Prism einen integrierten Vault oder Tokenisierungs-Service?
Nein. Dies wird als Designentscheidung beschrieben; Sie können Ihren eigenen Vault mitbringen oder den Vault des Payment-Processors nutzen.

Speichert Prism Credentials oder PII?
Das Repository gibt an, dass Credentials nicht von der Bibliothek gespeichert oder geloggt werden, sie ist stateless ohne Datenbank und speichert keine PII. Credentials existieren nur für die Lebensdauer Ihres HTTP-Clients.

Wie erkenne ich, welche Payment-Processor und Payment-Methods unterstützt werden?
Prism veröffentlicht Connector-Coverage mit einer Legende für unterstützt (vollständig implementiert und getestet), nicht anwendbar/unsupported, in Arbeit/teilweise und Implementierungen, die gegen Live-Umgebungen validiert werden müssen.

Wie viele Payment-Calls muss ich für mehrere Processor implementieren?
Das Repository behauptet, dass ein einziges Request-Schema denselben Authorize-Call über Processor wie Stripe und Adyen ermöglicht – ohne zusätzliche processor-spezifische Codezeilen.

Alternativen

• Direkte Integrationen pro Processor (mehrere SDKs / APIs): Jeder Payment-Processor separat implementieren. Dies erhöht processor-spezifischen Code und Wartungsaufwand im Vergleich zu einem einheitlichen Schema.
• Payment-Orchestrierungs-Plattformen / SaaS-Connector: Third-Party-Orchestrierung nutzen, um mehrere Processor zu abstrahieren. Diese Alternativen verlagern Komplexität typischerweise auf die Plattform statt eine Integrationsbibliothek als Transformationsschicht zu verwenden.
• Andere stateless Connector-Bibliotheken oder Middleware-Layer: Middleware wählen, die Payment-Requests über Provider normalisiert. Unterschiede liegen in Vault/Tokenization-Handhabung, State-Management und Connector-Coverage/Testing.
• Hyperswitch-Connector-Logik direkt nutzen (ohne Prism als Extraktion): Bei Nutzung von Hyperswitch können Sie auf breitere Plattform-Komponenten setzen statt Prism als eigenständige einheitliche Bibliothek zu adoptieren.