hyperswitch-prism

Qu'est-ce que hyperswitch-prism ?

hyperswitch-prism est une bibliothèque de connecteurs unifiée et sans état pour intégrer des processeurs de paiement. Elle est conçue pour fournir un schéma de requête/interaction unique afin que les mêmes motifs d'appel puissent être utilisés avec plusieurs processeurs de paiement avec moins de modifications de code.

Prism a été extrait et est maintenu par l'équipe derrière Hyperswitch, une plateforme de paiements open source. Le dépôt décrit Prism comme une couche de transformation qui se concentre sur la cohérence de l'intégration des connecteurs, tout en laissant les aspects comme le vault/tokenization, les tentatives de réessai et la logique de routage à Hyperswitch.

Fonctionnalités clés

• Un schéma de requête unifié pour tous les connecteurs : Le même appel d'autorisation fonctionne avec plusieurs processeurs (ex. : Stripe, Adyen) sans lignes de code supplémentaires dédiées à chaque processeur.
• Bibliothèque sans état (pas de base de données, pas de PII stockée) : Prism ne nécessite pas de base de données et évite de stocker des données personnelles ; il indique que les identifiants ne sont ni stockés ni journalisés par la bibliothèque et n'existent que pendant la durée de vie du client HTTP.
• Contrôle de la portée PCI par conception : La bibliothèque peut éviter d'importer des données de carte dans Prism ; les données de carte circulant (ou non) à travers la bibliothèque sont présentées comme un choix, avec la possibilité d'utiliser un vault du processeur de paiement ou un vault PCI certifié fourni par l'utilisateur.
• Tests continus des connecteurs avec un modèle de statut publié : Les connecteurs sont testés en continu contre de vrais environnements sandbox/production, avec une légende de statut couvrant les états supporté, en cours/partiel et nécessitant validation.
• Interface idiomatique et multi-langage (selon la doc du dépôt) : Prism est décrit comme une interface type-safe et idiomatique, packagée sous forme de SDK multi-langage.

Comment utiliser hyperswitch-prism

1. Sélectionnez le SDK Prism pour votre langage et consultez le guide SDK pour l'authentification et les motifs de requête.
2. Rédigez des requêtes de paiement avec le schéma unifié de Prism (par exemple, en utilisant la même forme d'appel d'autorisation pour différents processeurs de paiement).
3. Choisissez où gérer les données de paiement sensibles : utilisez votre propre vault PCI certifié ou un vault du processeur de paiement, en accord avec la note du dépôt que les services de vault/tokenization ne sont pas intégrés à Prism.
4. Validez la couverture des connecteurs pour vos besoins en utilisant la page de couverture/statut des connecteurs du projet, car Prism décrit des niveaux de support variables selon les connecteurs.

Cas d'usage

• Intégration de checkout multi-processeurs : Vous souhaitez router les opérations de paiement vers plus d'un processeur de paiement tout en minimisant les changements de code applicatif grâce au schéma de requête unifié de Prism.
• Réduction de l'état et des données stockées dans votre couche d'intégration : Votre équipe préfère une couche de connecteurs sans état où Prism lui-même ne nécessite pas de base de données et ne stocke ni ne journalise les identifiants.
• Alignement avec les responsabilités PCI via votre choix de vault : Vous voulez contrôler si les données de carte sont gérées dans votre infrastructure et choisir entre un vault du processeur de paiement ou votre propre vault PCI certifié.
• Équipes d'ingénierie maintenant la logique des connecteurs dans le temps : Vous avez besoin d'une couche d'intégration de connecteurs testée en continu contre sandbox/production et suivie avec un statut par connecteur.
• Intégration de couche de transformation dans une plateforme de paiements plus large : Vous utilisez Prism comme couche de transformation, tout en implémentant la logique de tentatives de réessai/routage ailleurs (le dépôt pointe vers Juspay Hyperswitch pour ces aspects).

FAQ

Prism est-il responsable des tentatives de réessai et de la logique de routage ?
Non. Le dépôt indique que les tentatives de réessai ou la logique de routage se trouvent dans Juspay Hyperswitch ; Prism est présenté comme une couche de transformation.

Prism inclut-il un coffre-fort ou un service de tokenisation intégré ?
Non. Il s’agit d’un choix de conception ; vous pouvez utiliser votre propre coffre-fort ou celui du processeur de paiement.

Prism stocke-t-il des identifiants ou des données PII ?
Le dépôt indique que les identifiants ne sont ni stockés ni journalisés par la bibliothèque, qui est sans état et sans base de données, et qu’elle ne stocke pas de données PII. Il est également noté que les identifiants existent uniquement pendant la durée de vie de votre client HTTP.

Comment savoir quels processeurs de paiement et méthodes de paiement sont pris en charge ?
Prism publie la couverture des connecteurs avec une légende indiquant les éléments pris en charge (entièrement implémentés et testés), non applicables/non pris en charge, en cours/partiels, et implémentations nécessitant une validation en environnements live.

Combien d’appels de paiement dois-je implémenter pour plusieurs processeurs ?
L’affirmation principale du dépôt est qu’un schéma de requête unique permet à un même appel d’autorisation de fonctionner sur des processeurs tels que Stripe et Adyen sans lignes de code spécifiques supplémentaires.

Alternatives

• Intégrations directes par processeur (plusieurs SDK / API) : Implémentez contre chaque processeur de paiement séparément. Cela peut augmenter le code et la maintenance spécifiques au processeur par rapport à un schéma unifié.
• Plateformes d’orchestration de paiements / connecteurs SaaS : Utilisez une orchestration tierce pour abstraire plusieurs processeurs. Ces alternatives déplacent généralement la complexité vers la plateforme plutôt que d’utiliser une bibliothèque d’intégration comme couche de transformation.
• Autres bibliothèques de connecteurs sans état ou couches middleware : Choisissez un middleware qui normalise les requêtes de paiement entre fournisseurs. Les différences résident dans la gestion du coffre-fort/tokenisation, le maintien de l’état, et la couverture/testing des connecteurs.
• Utiliser directement la logique de connecteurs Hyperswitch (sans Prism en extraction) : Si vous opérez déjà dans Hyperswitch, vous pouvez vous appuyer sur les composants plus larges de la plateforme au lieu d’adopter Prism comme bibliothèque unifiée autonome.