Pourquoi nous avons construit un orchestrateur de paiement from scratch

Si vous avez déjà essayé d'accepter des paiements à l'échelle mondiale, vous connaissez la douleur. Stripe couvre les cartes dans 46 pays. PayPal fonctionne dans 200+ pays mais exclut la majeure partie de l'Afrique. Le mobile money -- la méthode de paiement dominante pour plus de 500 millions de personnes -- nécessite des intégrations séparées avec MTN MoMo, Orange Money, Wave, M-Pesa et des dizaines de fournisseurs régionaux. Chaque fournisseur a sa propre API, son propre flux d'authentification, son propre format de webhook et son propre calendrier de règlement.

Nous avons construit 0fee.dev pour résoudre ce problème une fois pour toutes : une seule API, un seul SDK, un seul tableau de bord -- et vous couvrez le monde entier.

Le problème : la fragmentation des paiements

Considérez ce scénario. Vous construisez un produit SaaS en 2026. Vos clients sont aux États-Unis, en France, au Nigeria, au Kenya et en Côte d'Ivoire. Voici à quoi ressemble votre intégration de paiement sans orchestrateur :

Cela représente cinq intégrations séparées, cinq contrats d'API différents, cinq gestionnaires de webhooks, cinq processus de réconciliation. Et nous ne couvrons que cinq pays. Multipliez cela par 50 pays sur quatre continents et vous obtenez des mois de travail d'intégration, une équipe entière dédiée à la maintenance des paiements et un système fragile où un changement d'API d'un fournisseur peut casser votre flux de checkout.

Ce que fait un orchestrateur de paiement

Un orchestrateur de paiement se situe entre votre application et les fournisseurs de paiement. Il expose une API unique et unifiée qui abstrait la complexité du routage des transactions vers le bon fournisseur en fonction du pays, de la devise, de la méthode de paiement et de la disponibilité.

Votre Application
       |
       v
   API 0fee.dev (intégration unique)
       |
       +---> Stripe (cartes, mondial)
       +---> PayPal (portefeuilles, mondial)
       +---> Hub2 (mobile money, Afrique francophone)
       +---> PawaPay (mobile money, 21+ pays africains)
       +---> Paystack (Nigeria, Ghana)
       +---> Flutterwave (30+ pays africains)
       +---> BUI (Afrique de l'Ouest)
       +---> PaiementPro (Afrique de l'Ouest + cartes)
       +---> ... 45+ autres fournisseurs

Quand votre client en Côte d'Ivoire veut payer avec Orange Money, 0fee route la transaction vers Hub2 ou PaiementPro. Quand votre client aux États-Unis paie avec une carte Visa, 0fee route vers Stripe. Votre code ne change pas. Votre gestionnaire de webhooks ne change pas. Votre tableau de bord de réconciliation affiche tout au même endroit.

La vision : cinq lignes de code

Dès le début, nous voulions que l'expérience développeur soit absurdement simple. Installez le SDK, configurez votre clé API et commencez à accepter des paiements dans le monde entier :

typescriptimport { ZeroFee } from 'zerofee';

const zf = new ZeroFee({ apiKey: 'zf_live_...' });

const payment = await zf.payments.create({
  amount: 5000,        // 50,00 $ en centimes
  currency: 'USD',
  country: 'US',
  method: 'PAYIN_CARD',
  customer: {
    email: '[email protected]'
  },
  returnUrl: 'https://yourapp.com/thank-you'
});

// payment.checkoutUrl -> rediriger le client
// payment.id -> suivre le statut via les webhooks

La même structure de code fonctionne que le client paie avec une carte bancaire à New York, un virement bancaire à Lagos ou Orange Money à Abidjan. Les seules choses qui changent sont country, currency et method.

Pour les paiements mobile money en Afrique, cela ressemble à ceci :

typescriptconst payment = await zf.payments.create({
  amount: 10000,       // 10 000 XOF
  currency: 'XOF',
  country: 'CI',       // Côte d'Ivoire
  method: 'PAYIN_ORANGE_CI',
  customer: {
    phone: '+2250700000000'
  },
  returnUrl: 'https://yourapp.com/thank-you'
});

Le client reçoit une notification push sur son téléphone, confirme le paiement avec son code PIN et la transaction est réglée. Votre webhook se déclenche avec un payload standardisé, quel que soit le fournisseur qui a traité le paiement.

Architecture multi-tenant

0fee n'est pas qu'une simple passerelle de paiement -- c'est une plateforme d'orchestration multi-tenant. Chaque application enregistrée sur 0fee obtient :

• Des identifiants isolés : vos clés Stripe, vos clés PawaPay, vos clés Hub2 -- stockées chiffrées, jamais partagées entre les tenants.
• Des règles de routage personnalisées : définissez quels fournisseurs gèrent quels pays pour votre cas d'usage spécifique.
• Des endpoints de webhooks séparés : chaque application configure ses propres URLs de callback.
• Des limites de débit indépendantes : un pic de trafic d'un tenant n'affecte pas les autres.
• Des analyses par application : revenus, taux de succès, performances des fournisseurs -- tout est limité à votre application.

L'architecture supporte cela grâce à un modèle de données hiérarchique :

Organisation (votre entreprise)
  └── Application (votre produit)
       ├── Identifiants fournisseur (chiffrés)
       ├── Règles de routage
       ├── Endpoints de webhooks
       ├── Clés API (live + test)
       └── Transactions
            ├── Paiements
            ├── Virements
            └── Remboursements

Cela signifie qu'une seule organisation peut exécuter plusieurs applications -- un produit SaaS, une marketplace et une boutique e-commerce -- chacune avec sa propre configuration de paiement, le tout géré depuis un seul tableau de bord.

Pourquoi ne pas utiliser une solution existante ?

Nous avons évalué chaque grande plateforme d'orchestration de paiement avant de construire 0fee. Voici ce que nous avons trouvé :

Le fossé était clair. Aucun orchestrateur existant ne traitait l'Afrique comme un marché de premier plan. Le mobile money était soit non supporté, soit ajouté après coup. Et les solutions entreprise nécessitaient des appels commerciaux, un onboarding long et une tarification qui excluait les startups et les petites entreprises.

Les chiffres

Après 86 sessions de développement sur 80 jours, voici ce que couvre 0fee :

• 53+ fournisseurs de paiement intégrés et testés
• 200+ pays avec au moins une méthode de paiement disponible
• 117 méthodes de paiement couvrant cartes, mobile money, virements bancaires, portefeuilles et crypto
• 40+ devises dont le XOF, le XAF, le KES, le NGN, le GHS, le TZS, l'UGX, le ZAR et toutes les principales devises fiat
• 7 SDK disponibles : TypeScript/JavaScript, Python, PHP, Ruby, Go, Java et C#
• 90+ endpoints d'API couvrant les paiements, les virements, les remboursements, les webhooks, les analyses et l'administration

Le moteur de routage

Au coeur de 0fee se trouve le moteur de routage. Lorsqu'une demande de paiement arrive, le moteur évalue :

1. Le pays : quels fournisseurs sont disponibles dans le pays du client ?
2. La méthode de paiement : quels fournisseurs supportent la méthode demandée (carte, mobile money, virement bancaire) ?
3. La devise : quels fournisseurs peuvent traiter la devise donnée ?
4. La santé du fournisseur : quel est le taux de succès et la latence actuels de chaque fournisseur ?
5. Le coût : quel fournisseur offre les frais de traitement les plus bas pour cette transaction ?
6. Les préférences de l'application : le marchand a-t-il configuré des priorités ou des exclusions de fournisseurs ?

Le moteur note chaque fournisseur éligible et sélectionne le plus optimal. Si le fournisseur principal échoue, le moteur réessaie automatiquement avec le meilleur fournisseur suivant -- c'est ce qu'on appelle le basculement intelligent.

python# Logique de routage simplifiée
async def route_payment(request: PaymentRequest, app: Application) -> Provider:
    eligible = await get_eligible_providers(
        country=request.country,
        method=request.method,
        currency=request.currency,
        app_id=app.id
    )

    scored = []
    for provider in eligible:
        score = calculate_score(
            success_rate=provider.metrics.success_rate_24h,
            latency=provider.metrics.avg_latency_ms,
            cost=provider.fee_schedule.get_fee(request.amount),
            priority=app.routing_rules.get_priority(provider.id)
        )
        scored.append((provider, score))

    scored.sort(key=lambda x: x[1], reverse=True)
    return scored[0][0]

Ce moteur de routage est ce qui transforme 53 fournisseurs de paiement séparés en une plateforme de paiement cohérente.

Ce qui arrive dans la suite de cette série

Cet article pose les bases. Dans les articles qui suivent, nous approfondirons :

• Le problème des paiements en Afrique -- pourquoi le mobile money est fondamentalement différent des paiements par carte et pourquoi la plupart des orchestrateurs se trompent.
• La carte complète des fournisseurs -- chaque fournisseur, chaque pays, chaque méthode de paiement, avec des exemples de code.
• Les décisions d'architecture -- pourquoi nous avons choisi Python, FastAPI, SolidJS et SQLite (et ce que nous changerions).
• Construire depuis Abidjan -- l'histoire de 86 sessions, un CEO, un CTO IA et zéro ingénieur humain.

Le fossé dans l'infrastructure de paiement est réel, surtout pour les entreprises qui doivent opérer à la fois en Afrique et dans le reste du monde. Nous avons construit 0fee pour combler ce fossé.

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 avec zéro ingénieur humain. Suivez la série pour l'histoire complète de la construction.