hyperswitch-prism

Cos'è hyperswitch-prism?

Hyperswitch Prism è una libreria connector unificata stateless per l'integrazione con payment processor. È progettata per fornire uno schema di richiesta/interazione unico, così da utilizzare gli stessi pattern di chiamata su più payment processor con minori modifiche al codice.

Prism è stata estratta e mantenuta dal team dietro Hyperswitch, una piattaforma di pagamenti open-source. Il repository descrive Prism come un layer di trasformazione che si concentra sulla consistenza dell'integrazione dei connector, lasciando aspetti come vault/tokenizzazione, retry e logica di routing a Hyperswitch.

Caratteristiche Principali

• Uno schema di richiesta unificato tra i connector: La stessa chiamata authorize funziona con più processor (es. Stripe, Adyen) senza linee di codice aggiuntive dedicate a ciascun processor.
• Libreria stateless (nessun database, nessun PII memorizzato): Prism non richiede un database e evita di memorizzare dati personali; specifica che le credenziali non vengono memorizzate o loggate dalla libreria e esistono solo per la durata del client HTTP.
• Controllo del scope PCI per design: La libreria può evitare di far transitare i dati delle carte in Prism; il flusso (o non flusso) dei dati delle carte attraverso la libreria è una scelta, con la possibilità di usare un vault del payment processor o un vault PCI-certificato fornito dall'utente.
• Test continuo dei connector con modello di stato pubblicato: I connector vengono testati continuamente su ambienti sandbox/production reali, con una legenda di stato che copre stati supportati, in-progress/parziali e da validare.
• Interfaccia idiomatica e multi-lingua (secondo i docs del repository): Prism è descritta come un'interfaccia type-safe e idiomatica, confezionata come SDK multi-lingua.

Come Usare hyperswitch-prism

1. Seleziona l'SDK Prism per il tuo linguaggio e consulta la guida SDK per autenticazione e pattern di richiesta.
2. Scrivi richieste di pagamento usando lo schema unificato di Prism (ad esempio, usando la stessa forma di chiamata authorize su diversi payment processor).
3. Scegli dove gestire i dati di pagamento sensibili: usa il tuo vault PCI-certificato o un vault del payment processor, in linea con la nota del repository che i servizi di vault/tokenizzazione non sono integrati in Prism.
4. Valida la copertura dei connector per le tue esigenze usando la pagina di copertura/stato connector del progetto, poiché Prism descrive livelli di supporto variabili tra i connector.

Casi d'Uso

• Integrazione checkout multi-processor: Vuoi instradare operazioni di pagamento su più di un payment processor mantenendo piccole le modifiche al codice dell'applicazione grazie allo schema di richiesta unificato di Prism.
• Riduzione di stato e dati memorizzati nel layer di integrazione: Il tuo team preferisce un layer connector stateless in cui Prism stessa non richiede un database e non memorizza o logga credenziali.
• Allineamento con responsabilità PCI tramite scelta del vault: Vuoi controllare se i dati delle carte vengono gestiti nella tua infrastruttura e scegliere tra un vault del payment processor o il tuo vault PCI-certificato.
• Team di engineering che mantengono logica connector nel tempo: Hai bisogno di un layer di integrazione connector testato continuamente su sandbox/production e tracciato con stato connector-per-connector.
• Integrazione layer di trasformazione in una piattaforma pagamenti più ampia: Usi Prism come layer di trasformazione, implementando logica retry/routing altrove (il repository indica Juspay Hyperswitch per questi aspetti).

FAQ

Prism è responsabile per i retry e la logica di routing? No. Il repository specifica che i retry o la logica di routing risiedono in Juspay Hyperswitch; Prism è presentato come uno strato di trasformazione.

Prism include un vault o servizio di tokenizzazione integrato? No. Si tratta di una scelta di design; puoi portare il tuo vault o usare quello del payment processor.

Prism memorizza credenziali o PII? Il repository specifica che le credenziali non vengono memorizzate o loggate dalla libreria, è stateless senza database e non memorizza PII. Nota inoltre che le credenziali esistono solo per la durata del tuo HTTP client.

Come posso sapere quali payment processor e payment method sono supportati? Prism pubblica la copertura dei connector con una legenda che indica supportato (pienamente implementato e testato), non applicabile/non supportato, in corso/parziale e implementazione da validare in ambienti live.

Quante chiamate di pagamento devo implementare per più processor? La claim principale del repository è che uno schema di richiesta unico permette alla stessa chiamata authorize di funzionare tra processor come Stripe e Adyen senza linee di codice specifiche per processor aggiuntive.

Alternative

• Integrazioni dirette per processor (multipli SDK / API): Implementa contro ciascun payment processor separatamente. Questo può aumentare il codice specifico per processor e la manutenzione rispetto a uno schema unificato.
• Piattaforme di orchestrazione pagamenti / connettori SaaS: Usa orchestrazione di terze parti per astrarre più processor. Queste alternative spostano tipicamente la complessità sulla piattaforma invece di usare una libreria di integrazione come strato di trasformazione.
• Altre librerie connector stateless o layer middleware: Scegli middleware che normalizza le richieste di pagamento tra provider. Le differenze sono in come gestiscono vault/tokenizzazione, se mantengono stato e come gestiscono copertura/testing dei connector.
• Usa direttamente la logica connector di Hyperswitch (senza Prism come estrazione): Se operi già entro Hyperswitch, puoi affidarti ai componenti più ampi della piattaforma invece di adottare Prism come libreria unificata standalone.