31 lines
884 B
Markdown
31 lines
884 B
Markdown
|
|
# ADR-011: Hyperswitch pour les Paiements
|
||
|
|
|
||
|
|
**Date**: 2026-03-04
|
||
|
|
**Status**: Accepted
|
||
|
|
**Source**: ORIGIN_MASTER_ARCHITECTURE.md
|
||
|
|
|
||
|
|
## Contexte
|
||
|
|
|
||
|
|
Le projet nécessite un système de paiement pour la marketplace. Un vendor lock-in sur un seul PSP (Stripe) limite la flexibilité et augmente les coûts.
|
||
|
|
|
||
|
|
## Décision
|
||
|
|
|
||
|
|
Utiliser Hyperswitch, agrégateur de paiement open source, comme couche d'abstraction au-dessus des PSP.
|
||
|
|
|
||
|
|
## Conséquences
|
||
|
|
|
||
|
|
**Positives**:
|
||
|
|
- Multi-PSP (Stripe, Adyen, PayPal) sans changement de code
|
||
|
|
- Open source, auditable
|
||
|
|
- Pas de vendor lock-in
|
||
|
|
- Smart routing entre PSP
|
||
|
|
|
||
|
|
**Négatives**:
|
||
|
|
- Hébergement et maintenance de l'instance Hyperswitch
|
||
|
|
- Moins de documentation que l'intégration Stripe directe
|
||
|
|
|
||
|
|
## Alternatives rejetées
|
||
|
|
|
||
|
|
- **Stripe direct**: vendor lock-in, commissions non négociables
|
||
|
|
- **Développement interne**: trop risqué pour conformité PCI-DSS
|