Un switch de paiement Rust entre le marchand et ses PSP
Hyperswitch est un switch de paiement maintenu par Juspay. Le backend du marchand appelle une seule API, et le serveur Rust transmet chaque paiement au processeur retenu par le routage : Stripe, Adyen, Braintree, Worldpay, Checkout.com ou des dizaines d'autres connecteurs. Le cœur est sous licence Apache-2.0 ; Juspay vend aussi une version hébergée, Hyperswitch Cloud.
Routage en six stratégies, coffre compatible VGS et TokenEx
- Six stratégies de routage dans la documentation : règles sur le moyen de paiement, le montant, la devise, le pays ou le type de carte ; partage du trafic en pourcentages ; taux d'autorisation récent ; ce même taux pondéré par le coût de traitement ; réseau de débit le moins cher ; ordre de repli quand aucune règle ne s'applique ou que le processeur choisi n'est pas éligible.
- Coffre de cartes séparé : cartes, tokens, wallets et identifiants bancaires vont dans
hyperswitch-card-vault, un service annoncé conforme PCI. Un marchand déjà équipé chez VGS ou TokenEx garde son coffre, sans re-tokeniser ni migrer les cartes stockées. - SDK clients pour le web (en ReScript, avec un wrapper React), Android, iOS, React Native et Flutter, tous listés comme officiellement supportés. Des widgets prêts à poser couvrent PayPal, Apple Pay, Google Pay, Samsung Pay, Pay by Bank et Klarna.
- Control Center : le tableau de bord marchand pour les connecteurs, les règles de routage, les clés d'API et les analyses. Un bac à sable hébergé permet de l'essayer sans rien installer.
Quitter une intégration Stripe ou Braintree unique
- Passer d'une intégration Stripe, Stripe Connect ou Braintree unique à un routage entre plusieurs processeurs, premier cas cité par le README.
- Remplacer une passerelle de paiement par des connexions directes aux acquéreurs, TSYS ou JP Morgan Payments par exemple.
- Mettre en service un nouveau processeur par paliers, en pourcentage du trafic.
- Appeler les processeurs depuis une application existante avec Prism seul, une bibliothèque de connecteurs sans état extraite du projet.
Modules payants, routage dynamique sous AGPL et PCI DSS à assumer
Trois modules restent payants, même auto-hébergés. Le README revendique un modèle « commercial open source », dont la page des tarifs trace la limite : Revenue Recovery (relance des paiements d'abonnement échoués), Cost Observability (audit des frais) et Reconciliation (rapprochement des transactions) sont des options payantes dans l'édition Community gratuite comme dans l'édition Enterprise. La même page compte 90+ intégrations de paiement pour ces deux éditions, contre 210+ pour Hyperswitch Cloud.
Le routage dynamique tourne dans un second service, sous AGPL-3.0. Une instance auto-hébergée confie ses décisions de routage au taux d'autorisation à decision-engine, déployé à part avec sa base de données et son Redis. Ce dépôt est sous AGPL-3.0, alors que le switch, le coffre et le Control Center sont sous Apache-2.0.
La conformité PCI DSS revient à l'hébergeur. La page des tarifs destine l'édition Community à qui héberge sa pile de paiement et gère sa conformité de bout en bout. L'installation Docker locale tourne avec un coffre simulé (mock_locker = true) ; en production, la clé maîtresse de hyperswitch-card-vault est chiffrée par deux clés confiées à deux dépositaires distincts. Le serveur principal exige PostgreSQL et Redis ; le déploiement cloud passe par des charts Helm (AWS, GCP ou Azure).
Le routage au taux d'autorisation suppose du volume sur plusieurs processeurs. La documentation conseille de commencer par l'ordre de repli et les règles, et de n'activer ce routage qu'une fois que plusieurs processeurs traitent un trafic significatif sur un même segment de paiement.
Huit versions mineures entre le 24 février et le 16 octobre 2026, jusqu'à la 1.128.0. Le dernier commit date du 26 octobre, et le README ne porte aucune mention alpha ou bêta.