Session 2 : tableau de bord, SDK, widget de checkout et Celery en 60 minutes

La Session 001 a produit le backend. La Session 002, toujours le 10 décembre 2025 -- le même jour -- a produit tout ce dont une plateforme de paiement a besoin pour être utilisable : deux nouveaux fournisseurs de paiement, un tableau de bord SolidJS complet, un widget de checkout intégrable, des tâches Celery en arrière-plan et des SDK officiels en TypeScript et Python. Soixante minutes.

Ce que la Session 002 a livré

À la fin de la Session 002, 0fee.dev disposait de 7 fournisseurs de paiement, un tableau de bord frontend, un widget de checkout pour les marchands, un traitement de tâches en arrière-plan et deux SDK prêts pour npm et PyPI.

Phase 1 : deux nouveaux fournisseurs

Fournisseur BUI

BUI gère le mobile money en Afrique de l'Ouest francophone. Son implémentation nécessitait une gestion spéciale de deux flux distincts :

• Orange Money (Côte d'Ivoire) : Validation par OTP. Le client reçoit un OTP sur son téléphone, le saisit dans le flux de checkout, et BUI le valide.
• Wave : Flux de redirection. BUI renvoie une URL de paiement, le client est redirigé vers la page de Wave, et 0fee.dev fait du polling pour la complétion.

Fournisseur PaiementPro

PaiementPro est un agrégateur de paiement majeur pour l'Afrique francophone, supportant Orange Money, MTN, Moov, Wave, Free, Airtel et même les paiements par carte. Son intégration utilise un flux de redirection.

Avec BUI et PaiementPro, le nombre de fournisseurs a atteint 7 -- une couverture complète pour l'Afrique francophone avec plusieurs options de repli par pays.

Phase 2 : le tableau de bord SolidJS

Le tableau de bord est l'interface destinée aux marchands où les développeurs gèrent leurs applications, clés API, identifiants de fournisseurs et transactions. Il a été construit avec SolidJS, choisi pour sa réactivité fine et sa taille de bundle minimale (7 Ko de runtime).

Pages clés

Dashboard.tsx -- La page de vue d'ensemble principale montrant le volume de transactions, les taux de succès, le chiffre d'affaires et l'activité récente.

Apps.tsx -- CRUD complet pour les applications marchandes. Chaque application a ses propres clés API, identifiants de fournisseurs et configuration de routage.

Transactions.tsx -- Une liste filtrable et paginée de toutes les transactions de toutes les applications. Les filtres incluent le statut, le fournisseur, la plage de dates et la plage de montants.

Phase 3 : le widget de checkout

Le widget de checkout -- checkout.js -- est une bibliothèque JavaScript que les marchands intègrent sur leurs sites web. Il ouvre un modal, présente les méthodes de paiement en fonction du pays du client, collecte les détails de paiement et traite le paiement. Pensez au stripe.js de Stripe mais pour le mobile money africain.

Le widget implémente un flux de paiement en quatre étapes :

1. Sélection du pays. Le client sélectionne son pays dans une grille.
2. Sélection de la méthode de paiement. Les opérateurs disponibles s'affichent.
3. Détails de paiement. Pour le mobile money, le client saisit son numéro de téléphone.
4. Traitement et confirmation. Le widget affiche un état de traitement, fait du polling et affiche le succès ou l'échec.

Phase 4 : tâches Celery en arrière-plan

Trois catégories de tâches en arrière-plan tournent sur Celery avec DragonflyDB comme broker :

Retry de webhooks

Quand une livraison de webhook échoue, la tâche programme un retry avec backoff exponentiel : 1 min, 5 min, 30 min, 2 h, 8 h, 24 h.

Réconciliation des paiements

Toutes les 5 minutes, une tâche planifiée vérifie les paiements bloqués en statut « pending » et interroge le fournisseur pour leur statut actuel.

Traitement des règlements

Une tâche quotidienne à 00:30 UTC calcule les montants de règlement pour chaque marchand.

Phase 5 : SDK TypeScript

Le SDK TypeScript officiel fournit un client typé pour l'API 0fee.dev :

typescriptimport { ZeroFee } from "zerofee";

const zf = new ZeroFee("sk_live_your_key_here");

const payment = await zf.payments.create({
    amount: 5000,
    payment_method: "PAYIN_ORANGE_CI",
    customer: {
        phone: "+2250709757296",
        name: "Amadou Diallo",
    },
});

Phase 6 : SDK Python

Le SDK Python suit les mêmes patterns avec des modèles Pydantic pour la validation de type :

pythonfrom zerofee import ZeroFee

zf = ZeroFee(api_key="sk_live_your_key_here")

payment = zf.payments.create(
    amount=5000,
    payment_method="PAYIN_ORANGE_CI",
    customer={
        "phone": "+2250709757296",
        "name": "Amadou Diallo",
    },
)

Le bilan de la Session 002

Deux sessions. Deux heures au total. La plateforme disposait d'un backend complet, 7 fournisseurs de paiement, un tableau de bord frontend, un widget de checkout intégrable, un traitement de tâches en arrière-plan et des SDK officiels en deux langages. La Session 003 ajouterait un site marketing, 5 SDK supplémentaires et une configuration Docker -- en une seule session.

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.