Je vends des laptops. Les paiements, c’est mon casse-tête quotidien.
Je gère Kalinko Store, un e-commerce de vente d’ordinateurs portables en Guinée. Chaque vente m’oblige à jongler entre Orange Money, MTN MoMo, les virements bancaires et le cash. Des applis différentes. Des parcours différents. Des délais de règlement différents. Je fais la réconciliation à la main dans des tableurs parce que rien ne communique avec rien.
Un client veut payer par Orange Money mais mon checkout n’affiche que MTN ? Vente perdue. Un virement arrive deux jours en retard et je ne sais plus à quelle commande il correspond ? Je fouille les captures d’écran sur WhatsApp.
Ce n’est pas un problème théorique. Je le vis au quotidien.
Ce qui ne marche pas concrètement
La Guinée n’a pas de Stripe. Il n’existe aucune intégration unique qui permette à un commerçant d’accepter tous les moyens de paiement locaux. Chaque prestataire est un silo avec sa propre API (quand il en a une), ses propres règles de règlement, son propre tableau de bord.
Résultat : chaque entreprise qui veut accepter des paiements digitaux doit reconstruire le même code de liaison. Se connecter à Orange Money. Se connecter à MTN MoMo. Se connecter à une ou deux banques. Gérer les erreurs de chacun. Construire la logique de réconciliation. Recommencer.
La plupart des entreprises ne s’y risquent pas. Elles restent au cash et aux captures d’écran WhatsApp. Celles qui passent au digital finissent par maintenir des intégrations fragiles, propres à chaque prestataire, qui cassent quand les APIs changent sans prévenir.
Le résultat : l’adoption du commerce digital stagne, les développeurs reconstruisent la même plomberie de paiement encore et encore, et les clients subissent une expérience bien en dessous de ce qu’ils méritent.
Ce que je construirais
Une plateforme. Une API. Un checkout. Tous les moyens de paiement guinéens derrière une seule intégration.
Le client paie avec son numéro de téléphone ou son email. Il choisit sa source de financement — Orange Money, MTN MoMo, compte bancaire ou solde de portefeuille. Le commerçant voit une seule transaction, un seul tableau de bord, un seul règlement. Le développeur écrit une seule intégration.
Pensez PayPal, mais conçu pour Conakry. Une couche de portefeuille qui abstrait le chaos en dessous. Les commerçants obtiennent un widget de paiement ou une API. Les clients ont une expérience cohérente, quel que soit le prestataire qui détient leur argent. Tout le monde a une source unique de vérité pour l’historique des transactions.
Comment ça fonctionnerait
Le noyau, c’est une couche d’orchestration des paiements. Un seul point d’API reçoit une demande de paiement, identifie la source de financement, route vers le bon prestataire, gère la réponse et normalise le tout dans un format cohérent.
En dessous : des adaptateurs par prestataire pour Orange Money, MTN MoMo et les banques partenaires. Chaque adaptateur gère l’authentification spécifique, les bizarreries de l’API et la logique de règlement de ce prestataire. Quand l’API d’un prestataire change (et ça arrivera), on met à jour un seul adaptateur. Tous les commerçants en bénéficient.
Au-dessus : un moteur de portefeuille pour les soldes stockés, un service d’identité (basé sur le téléphone ou l’email), des tableaux de bord pour les commerçants et des SDKs pour les développeurs. L’expérience de paiement — que ce soit sur un site web, une app mobile ou en magasin — passe par le même système.
Les parties difficiles
Les APIs des opérateurs télécoms en Guinée ne sont pas au niveau de Stripe. Elles tombent en panne. Elles changent sans versioning. La documentation, quand elle existe, est incomplète. Construire des flux de paiement fiables sur une infrastructure instable, ça veut dire de la logique de retry, du fallback et beaucoup d’ingénierie défensive. J’ai déjà construit des systèmes sur des infrastructures instables — chez Hyphen, la plateforme de prêt que j’ai aidé à construire traitait de l’argent réel sur de vrais rails bancaires africains. Le même genre de problèmes.
La réglementation, c’est l’autre gros morceau. Paiements = KYC, conformité AML, licence de la banque centrale. Le cadre réglementaire guinéen pour la fintech est encore en évolution, ce qui est à la fois une opportunité et un risque. On peut aider à façonner les règles, mais on peut aussi se retrouver bloqué en attendant des approbations sans calendrier clair.
Ensuite, il y a la confiance. Les Guinéens sont prudents avec les applications qui touchent à l’argent, et pour de bonnes raisons. Le produit doit être irréprochable dès le premier jour. Pas de “avancer vite et casser des choses” quand on gère l’argent du loyer de quelqu’un.
Et la liquidité — gérer le float entre les prestataires, s’assurer que les retraits sont rapides et fiables, gérer les décalages de timing entre les différents systèmes de règlement. C’est là que la fintech devient opérationnellement complexe, pas juste techniquement complexe.
Connexions avec d’autres projets
Cette passerelle s’intégrerait directement dans la Suite Modulaire Unifiée que je conçois pour les entreprises guinéennes — le module commerce a besoin exactement de ce type d’infrastructure de paiement. Elle pourrait aussi servir de couche de paiement pour l’API LMS sans interface (frais de scolarité, frais de cours) et bénéficier de la Plateforme d’Identité Numérique pour les comptes utilisateurs vérifiés.
Statut actuel
C’est un concept que je recherche activement, nourri par les problèmes de paiement que je vis au quotidien en gérant Kalinko Store. L’expérience fintech acquise en construisant la plateforme de prêt d’Hyphen me donne une vision claire de ce que ça implique — techniquement et opérationnellement.
Si vous travaillez sur l’infrastructure de paiements en Afrique de l’Ouest, ou que vous avez résolu des problèmes de fragmentation similaires sur un autre marché, je veux en discuter : laminekalinko2@gmail.com