Chaque requête API vers 0fee.dev traverse une pile middleware avant d'atteindre un gestionnaire de route. Cette pile gère trois préoccupations : vérifier que l'appelant est autorisé, s'assurer qu'il ne dépasse pas sa limite de débit et prévenir les paiements en double quand des problèmes réseau provoquent des retentatives. Ce ne sont pas des fonctionnalités optionnelles pour une plateforme de paiement -- ce sont les fondations de la confiance entre la plateforme et ses marchands.
Authentification par clé API
0fee.dev utilise des clés API à préfixe qui encodent les informations d'environnement et de type directement dans la chaîne de la clé :
| Préfixe | Type | Environnement | Usage |
|---|---|---|---|
sk_live_ | Clé secrète | Production | Appels API côté serveur |
sk_sand_ | Clé secrète | Sandbox | Tests côté serveur |
pk_live_ | Clé publique | Production | Côté client (widget de checkout) |
pk_sand_ | Clé publique | Sandbox | Tests côté client |
La convention de préfixe a été empruntée à Stripe, et pour une bonne raison : elle permet aux développeurs de distinguer instantanément les types de clés.
Vérification de suspension de facturation
Après l'authentification, le middleware vérifie si le compte du marchand est suspendu pour factures impayées. Le code de statut 402 -- Payment Required -- est rarement utilisé en pratique, mais il est sémantiquement parfait pour ce cas.
Limitation de débit basée sur Redis
La limitation de débit utilise un algorithme de fenêtre glissante implémenté dans DragonflyDB. Chaque clé API obtient un budget de requêtes configurable par fenêtre temporelle.
La décision de conception la plus importante du limiteur de débit est la dégradation gracieuse. Quand DragonflyDB est indisponible, le limiteur de débit laisse passer les requêtes. C'est un compromis délibéré : pour une plateforme de paiement, un limiteur de débit temporairement absent est bien moins nocif que le blocage de requêtes de paiement légitimes.
Gestion des clés d'idempotence
Considérez ce scénario : le serveur d'un marchand envoie une requête de paiement à 0fee.dev. La requête réussit et 5 000 XOF sont débités du compte Orange Money du client. Mais la réponse HTTP est perdue à cause d'un timeout réseau. Le serveur du marchand, ne sachant pas que le paiement a réussi, relance la requête. Sans gestion de l'idempotence, le client est débité deux fois.
Les clés d'idempotence préviennent cela. Le marchand inclut un en-tête Idempotency-Key avec un identifiant unique. Si la même clé est envoyée deux fois, la seconde requête renvoie la réponse mise en cache de la première -- aucun nouveau paiement n'est créé.
La chaîne middleware complète
La requête arrive
|
v
[1] Extraire la clé API ou le token de session
|
v
[2] Valider les identifiants (consultation BD)
|
v
[3] Vérifier la suspension de facturation
|-- 402 Payment Required ? -> Renvoyer erreur
|
v
[4] Vérifier la clé d'idempotence
|-- Doublon ? -> Renvoyer réponse mise en cache
|
v
[5] Vérifier la limite de débit
|-- Dépassée ? -> Renvoyer 429
|
v
[6] Gestionnaire de route (logique métier)
|
v
[7] Stocker la réponse d'idempotence
|
v
[8] Ajouter les en-têtes de limite de débit à la réponse
|
v
Réponse envoyéeChaque étape peut court-circuiter la chaîne. L'ordonnancement est intentionnel : l'authentification est la moins coûteuse, donc elle vient en premier. La logique métier est la plus coûteuse, donc elle vient en dernier.
Cet article fait partie de la série « Comment nous avons construit 0fee.dev ». 0fee.dev est un orchestrateur de paiement couvrant 53+ fournisseurs dans 200+ pays, construit par Juste A. GNIMAVO et Claude depuis Abidjan sans aucun ingénieur humain. Suivez la série pour l'histoire complète de la construction.