Par Thales & Claude -- CEO & AI CTO, ZeroSuite, Inc.
Quand on construit un produit SaaS pour les États-Unis ou l'Europe, les paiements sont un problème résolu. On intègre Stripe, on configure quelques endpoints de webhook, et on passe à la fonctionnalité suivante. Quand on construit un produit SaaS pour l'Afrique de l'Ouest et Centrale, les paiements sont la fonctionnalité. C'est le problème d'ingénierie le plus difficile, et il reste fragile longtemps après le lancement.
La raison est simple : l'infrastructure de paiement en Afrique subsaharienne est fragmentée entre des dizaines de fournisseurs de mobile money, chacun opérant dans un seul pays, chacun avec sa propre API, son propre format de webhook, son propre calendrier de règlement et ses propres modes de défaillance.
Cet article explique comment nous avons construit le système de crédits et l'infrastructure de paiement pour Deblo.ai.
Le système de crédits : monnaie universelle pour une plateforme IA
Les crédits sont la monnaie universelle à l'intérieur de Deblo. Chaque interaction coûte des crédits, mais le coût varie selon la complexité :
- Mode K12 (élève) : 1 crédit par question texte, 2 crédits par analyse photo.
- Mode Pro (professionnel) : tarification par tokens -- 1 crédit pour 3 000 tokens standard, 1 crédit pour 2 000 tokens pour les tâches de raisonnement complexe.
- Appels vocaux : 5 crédits par minute.
Tarification en cents USD avec affichage en monnaie locale
Tous les prix dans Deblo sont stockés en interne en cents USD. L'alternative -- tarifier directement en FCFA, Naira, Cedi, Shilling et Franc -- signifierait recalculer les prix à chaque mouvement de taux de change. En tarifiant en cents USD et en convertissant à l'affichage, nous avons une source de vérité unique pour la tarification et l'utilisateur voit toujours les prix dans sa monnaie locale.
Le CreditLedger : source de vérité unique
Tôt dans le développement, nous suivions les mouvements de crédits dans plusieurs tables. Cela devint rapidement un cauchemar de débogage. La solution fut le CreditLedger -- une table unique en ajout seul qui enregistre chaque mouvement de crédit, dans n'importe quelle direction, pour n'importe quelle raison. Chaque mouvement -- bonus d'inscription, recharge, utilisation par coupon, utilisation IA, ajustement admin, bonus de parrainage -- passe par une seule fonction.
Crédits gratuits : le moteur de générosité
Nous donnons beaucoup de crédits gratuitement. C'est intentionnel. Le système de crédits gratuits a quatre composantes :
- Bonus d'inscription : 200 crédits. Chaque nouvel utilisateur commence avec 200 crédits.
- Recharge quotidienne : 30 crédits. Chaque jour à minuit, les crédits gratuits de chaque utilisateur sont réinitialisés à 30.
- Bonus IA : 1-5 crédits par interaction. Après chaque échange, l'IA peut attribuer des crédits bonus pour encourager le comportement studieux.
- Bonus de parrainage : 150 crédits. Quand un utilisateur parraine un ami qui s'inscrit et fait sa première recharge, les deux reçoivent 150 crédits.
Trois passerelles de paiement, dix pays
Collecter de l'argent en Afrique nécessite plusieurs passerelles de paiement car aucun fournisseur unique ne couvre tous les pays et tous les moyens de paiement. Nous intégrons trois passerelles :
1. Zerofee (0fee.dev) -- Notre passerelle principale pour le mobile money en Afrique de l'Ouest francophone. Zerofee est un agrégateur qui se connecte à Orange Money, Wave, MTN MoMo et d'autres fournisseurs de mobile money.
2. Stripe -- Pour les paiements internationaux (cartes bancaires, Apple Pay, Google Pay) et les utilisateurs de la diaspora.
3. PaiementPro / XPaye -- Une passerelle de paiement africaine francophone qui supporte l'intégration directe du mobile money via un SDK JavaScript. PaiementPro couvre 10 pays avec 16 canaux de paiement.
Quand un utilisateur en Côte d'Ivoire ouvre la page de recharge, il voit Orange Money, MTN MoMo, Moov Flooz et Wave. Un utilisateur au Sénégal voit Orange Money, Free Money, E-Money et Wave.
Confirmation par webhook
Chaque passerelle nous notifie des résultats de paiement via des webhooks. Les gestionnaires de webhook suivent tous le même schéma : vérifier la signature, trouver l'enregistrement CreditPurchase par référence de paiement, créditer l'utilisateur si le paiement a réussi, et journaliser dans le ledger.
Le poller de paiement : parce que les webhooks échouent
Voici la vérité inconfortable sur les webhooks en Afrique : ils échouent. Régulièrement. Se fier uniquement aux webhooks pour la confirmation de paiement signifie que certains utilisateurs paieront de l'argent et ne recevront jamais leurs crédits.
Notre solution est le poller de paiement -- une tâche de fond qui tourne toutes les 30 secondes et vérifie tous les paiements en attente auprès des API des passerelles. Le calendrier de vérification est volontairement front-loaded : les trois premières vérifications surviennent dans les 5 minutes suivant la création du paiement, puis s'espacent à des vérifications horaires, et s'arrêtent entièrement après 24 heures.
Cette approche de double confirmation (webhooks plus polling) a sauvé des dizaines de paiements qui auraient autrement été perdus. Dans notre premier mois d'exploitation, environ 8 % des paiements réussis ont été crédités par le poller plutôt que par le webhook.
Ce que nous avons appris sur les paiements en Afrique
- Les webhooks sont nécessaires mais pas suffisants. Ayez toujours un fallback de polling.
- Le mobile money n'est pas une seule chose. Orange Money en Côte d'Ivoire et Orange Money au Sénégal sont des systèmes différents.
- Tarifez dans la plus petite unité. Stocker les prix en FCFA (sans centimes) ou en cents USD (entiers, pas de virgule flottante) élimine toute une classe de bugs d'arrondi.
- Donnez des crédits généreusement. Le coût marginal d'un crédit gratuit est quasi nul, mais la valeur pour l'utilisateur est immense.
- Le ledger est sacré. Une fois passés à une seule table
CreditLedger, le débogage des problèmes de paiement est passé de « vérifier cinq tables et prier » à « interroger une table et voir l'historique complet ».
Ceci est l'article 6 de 20 dans la série « Comment nous avons construit Deblo.ai ».