FAQ API de paiement Fondeka : Mobile Money, crypto et frais

Par exemple, un client commande sur votre site. Votre serveur demande à Fondeka d’encaisser le paiement avec un moyen compatible. Fondeka traite la demande et informe votre serveur lorsque le résultat est connu. Votre application peut alors mettre à jour la commande.

L’API relie votre logiciel à Fondeka. Elle ne remplace ni votre site, ni votre application, ni votre service client.

• Les étudiants qui développent un projet, un prototype ou leur premier produit.
• Les freelances et développeurs indépendants qui ajoutent des paiements à leurs services ou aux applications de leurs clients.
• Les petites entreprises qui souhaitent encaisser et envoyer de l’argent depuis leur logiciel.
• Les startups qui construisent un MVP ou lancent leur activité avant d’avoir réuni tous leurs documents administratifs.

Les équipes établies peuvent aussi évaluer si le service répond à leurs besoins. Notre objectif principal est de faciliter les premières intégrations de paiement.

Il vous faut néanmoins un compte Fondeka éligible et les vérifications adaptées à votre situation. L’identité, les restrictions du compte et les règles de paiement restent applicables, notamment pour les paiements sortants réels. Commencer sans documents d’entreprise ne signifie pas utiliser le service anonymement.

Consulter les conditions d’accès à l’API de paiement.

Une relation directe peut toutefois nécessiter des documents d’entreprise, une configuration technique, le respect des règles de chaque fournisseur et un suivi des paiements. Fondeka simplifie l’accès aux routes prises en charge grâce à son API et à son portail.

Vous développez toujours votre tunnel de paiement, vos commandes, votre récepteur webhook et vos règles métier. Votre équipe s’appuie sur le parcours documenté de Fondeka plutôt que de gérer chaque connexion sous-jacente séparément.

L’API propose aussi la recherche de paiements, la consultation des soldes et des outils de test Sandbox.

Votre application définit ce qui est vendu et ce qui se passe après le paiement. Une application d’abonnements peut, par exemple, gérer ses échéances et demander chaque paiement via un parcours compatible. L’acceptation d’un paiement ne crée pas automatiquement un mandat de débit récurrent ni un service complet d’abonnement.

Selon l’offre affichée pour votre compte, l’API peut être incluse dans un pack Business Tools ou vendue séparément. L’écran d’achat précise les outils débloqués.

La présence d’une fonction dans l’application ou d’un nom dans une liste technique ne garantit pas sa disponibilité dans l’API de paiement. Consultez le catalogue et les guides actuels.

Pour un encaissement avec une interface prête à l’emploi, explorez les liens de paiement, boutiques ou POS Fondeka. Pour intégrer les paiements à votre propre produit, choisissez l’API.

D’autres pays et routes seront ajoutés avec l’expansion du service.

Ce tableau décrit la couverture et les devises concernées. Il ne garantit pas que chaque opérateur accepte chaque devise, les deux sens de paiement ou tous les choix de règlement. Vérifiez la route actuelle dans votre espace API avant de lancer un parcours.

Choisissez le moyen correspondant au pays réel du client ou du bénéficiaire. Des noms d’opérateurs similaires ne rendent pas les routes interchangeables. Vérifiez ensemble le numéro international, le pays et la devise.

La rubrique Moyens de paiement disponibles du portail Business donne les identifiants et informations utiles. Les encaissements et paiements sortants d’un même opérateur peuvent avoir des disponibilités, limites et frais différents.

Avant de proposer une option à vos clients, confirmez le pays, l’opérateur, la devise et le sens. Pour les paiements sortants, l’éligibilité du bénéficiaire et les fonds disponibles comptent aussi. Prévoyez un message utile lorsqu’une route devient indisponible.

Vérifiez la route dans le portail, puis le parcours Live concerné avant une ouverture large. Pour une activité transfrontalière, précisez les pays et devises nécessaires au support.

La présence d’une devise dans les portefeuilles ou un exemple ne suffit pas. Vérifiez la conversion, les frais et la disponibilité pour votre requête réelle. Affichez clairement la devise à côté de chaque montant.

L’actif et le réseau doivent correspondre. La prise en charge d’un jeton sur un réseau ne garantit pas sa prise en charge sur un autre. Présentez exactement le réseau, l’adresse, le montant en jetons et l’expiration renvoyés.

Prévoyez l’indisponibilité d’une route dans votre interface. Consultez les moyens et frais actuels plutôt que de considérer une capture ou une ancienne liste comme une promesse permanente.

Si votre projet dépend d’un pays, opérateur, actif, réseau ou d’une devise absents, contactez le support avec les détails. N’annoncez une route à vos clients qu’après confirmation de sa disponibilité.

Votre paiement finance l’environnement et les outils pour vous connecter, tester, gérer les identifiants, comprendre les routes et exploiter votre parcours via Fondeka. Le traitement des opérations est facturé séparément.

• Le paiement de l’accès active l’API ou l’offre Business Tools affichée pour votre compte.
• Les frais de transaction s’appliquent aux opérations effectuées, selon la route et la tarification actuelles.

Payer l’accès ne rend pas le traitement des paiements gratuit. Ce paiement n’est ni un dépôt dans votre portefeuille ni un solde à envoyer à vos clients.

L’offre peut couvrir le pack Business Tools ou l’API seule. Les prix et offres peuvent évoluer : un ancien message ou le prix d’un autre utilisateur ne définit pas votre offre. Le total peut aussi inclure les frais du moyen utilisé pour payer l’activation.

Cette FAQ ne remplace pas l’offre de votre compte. Le prix, la durée et les outils inclus peuvent différer d’un compte à l’autre. En cas de doute, demandez au support avant de payer.

Le choix de l’API peut afficher ses avantages alors que le paiement concerne le pack entier. Lisez les avantages et le périmètre. Le prix et la formule de l’écran d’achat identifient l’offre réelle.

1. Votre identité Business et son ID, pour identifier l’intégration.
2. La gestion des identifiants API, distincts en Sandbox et Live, selon les règles du compte.
3. Un secret de signature webhook distinct, pour vérifier les notifications.
4. Les guides des quatre parcours, ainsi que les montants, statuts et erreurs.
5. Le catalogue des moyens et réseaux crypto disponibles, avec leurs identifiants et frais actuels.
6. Les outils Sandbox : approvisionnement virtuel, soldes, historique et scénarios pris en charge.
7. Les vues Portefeuilles et Transactions API, avec l’environnement sélectionné clairement indiqué.
8. Les contrôles des identifiants, dont la modification du webhook et la révocation d’une clé.

L’acceptation des paiements Live dépend toujours de leur disponibilité et des vérifications du compte et de la route. L’achat ne fournit ni fonds pour les paiements sortants, ni clients, ni site terminé, ni garantie d’approbation des transactions.

Enregistrez la clé API et le secret webhook lorsqu’ils s’affichent. Les secrets complets ne sont visibles qu’à leur génération. Une clé masquée affichée ensuite sert d’identifiant, pas de remplacement du secret.

Lisez les guides et posez vos questions avant d’acheter si votre projet dépend d’un pays, d’un opérateur, d’une fonction ou d’une date de lancement Live. Achetez en comprenant le service dont vous avez besoin.

La Sandbox dispose d’un approvisionnement virtuel pour les tests. Ces fonds ne peuvent être retirés ni devenir de l’argent réel. Pour le Live, approvisionnez le portefeuille réel adapté par un parcours Fondeka pris en charge.

Vérifiez le montant d’accès, les frais de traitement et le total avant de confirmer. Suivez exactement les instructions. Les moyens d’achat de l’accès sont distincts des moyens que votre application peut utiliser via l’API.

Certains moyens aboutissent de manière asynchrone. La soumission du paiement ou le débit d’un compte externe ne prouve pas, à elle seule, l’activation. Ne rachetez pas immédiatement. Si le paiement semble terminé mais l’outil reste fermé, contactez le support avec la référence et l’adresse e-mail du compte.

À votre retour, vérifiez ce paiement avant d’en démarrer un autre. Si vous avez déjà effectué un virement ou un transfert crypto, ne l’envoyez pas à nouveau simplement parce que l’écran indique encore une attente.

Utilisez les instructions de cet achat et vérifiez son statut. Pour changer un moyen non payé, utilisez uniquement l’option du portail. Une ancienne référence ne peut pas être supposée valable pour un autre montant ou de nouvelles instructions.

L’accès au POS ou aux boutiques seules n’inclut pas automatiquement l’API. Vérifiez votre offre réelle. Contactez le support si un paiement ou un accès antérieur semble absent.

Votre projet doit correspondre aux parcours pris en charge. Si vous prévoyez de gros volumes ou une activité spécialisée, parlez-en à Fondeka avant de vous appuyer sur une configuration opérationnelle particulière.

Ce sont des moyennes, pas un tarif fixe pour chaque paiement. Les frais réels varient selon l’opérateur, la route, le sens, la devise et le montant. Le détail actuel est disponible dans votre espace API après activation.

Pour une base illustrative de 100 USD, 3 USD pour l’agrégateur et 2 USD pour Fondeka donnent 5 USD au total. La réponse de paiement expose un seul champ fee, sans ventilation des composants.

Les frais par opération ne signifient pas de nouveaux frais de traitement chaque fois que vous consultez le même paiement ou recevez une notification répétée. Ces actions ne créent pas un nouvel encaissement ou paiement sortant.

Cet exemple explique la moyenne ; ce n’est pas un devis opérateur. Le calcul réel peut dépendre du montant traité, du mode de frais, de minimums, de paliers, de conversions et d’arrondis. Utilisez les frais et montants renvoyés pour l’opération réelle.

Appliquer systématiquement 5 % dans votre code serait donc trompeur. La moyenne explique le modèle ; les informations actuelles de la route et les montants calculés par le serveur déterminent l’opération.

Un catalogue ou une fourchette aide à comprendre le prix. Le montant et la destination réels peuvent modifier le routage et le calcul final. Utilisez les montants actuels calculés par le serveur plutôt qu’une estimation issue de la FAQ ou d’une ancienne capture.

L’écran d’activation affiche ses frais et son total. Le catalogue de l’espace API explique la tarification des opérations. Les frais d’activation ne constituent pas un crédit prépayé pour vos transactions futures.

• EXCLUSIVE — frais en plus : vous voulez recevoir 100 USD. On ajoute 5 USD de frais : le client paie 105 USD et vous recevez 100 USD.
• INCLUSIVE — frais compris : le client paie 100 USD au total. On retire 5 USD de frais de cette somme : vous recevez 95 USD.

Les 5 USD servent uniquement à illustrer le calcul ; les frais réels dépendent de l’opération. Affichez toujours le total au client avant son approbation. Si vous ne précisez pas de mode, la politique par défaut de la route s’applique.

Les frais sont supposés déjà calculés. Ces exemples ne signifient pas que toute demande de 100 USD entraîne 5 USD de frais. En crypto, le montant en jetons provient des instructions de conversion renvoyées.

• amount est le montant fiat net. Pour un encaissement terminé, il représente le crédit de portefeuille rapproché.
• fee est le frais consolidé de l’opération.
• grossAmount est le montant net plus les frais.
• currency indique la devise fiat de ces montants.

Pour un paiement sortant, le brut correspond à la somme réservée ou débitée. Lisez ces champs ensemble : un chiffre sans devise ou sans mode de frais peut induire en erreur.

Les requêtes utilisent les unités monétaires normales : 10 avec currency: "USD" signifie 10 USD, pas 10 cents. Les montants acceptent au maximum deux décimales. Utilisez une arithmétique décimale et ne multipliez pas systématiquement les montants par 100.

Lire le guide des montants et modes de frais en anglais.

Utilisez les montants et devises renvoyés pour le paiement réel. En crypto, suivez la quantité de jetons, l’actif et le réseau indiqués. Ne supposez pas que 100 USD équivalent à 100 jetons, qu’un taux vaut toujours 1:1 ou qu’un taux de test est un cours de marché.

Vérifiez le total du paiement Fondeka et les frais distincts annoncés par l’opérateur ou le portefeuille externe. Demandez au support de clarifier le cas d’une route précise si nécessaire.

Les frais d’un encaissement ne rendent pas le paiement sortant suivant gratuit. La moyenne de 5 % ne décrit pas le coût total d’un parcours comprenant plusieurs paiements. Estimez votre modèle économique à partir de ses opérations réelles.

Un statut d’échec ne prouve pas que les fonds ou frais ont été restitués. Le remboursement dépend de l’opération et de la politique applicable. Vérifiez le portefeuille et contactez le support en cas de doute. N’envoyez pas automatiquement un paiement compensatoire.

Vous pouvez tester les soumissions, statuts, webhooks signés, échecs et effets sur les portefeuilles virtuels. La Sandbox ne contacte pas les fournisseurs réels et ne déplace pas d’argent réel. Commencez ici avant d’utiliser les fonds de vos clients.

Lire le guide de test Sandbox en anglais.

Il faut les bons identifiants, l’accès et l’éligibilité du compte, une route compatible et l’ouverture des nouveaux paiements Live par Fondeka. Une intégration Sandbox fonctionnelle prépare le Live ; elle ne constitue pas, à elle seule, une autorisation d’utiliser de l’argent réel.

Ouvrir une démo n’équivaut pas à tester votre serveur avec une clé Sandbox. Gardez l’environnement visible pendant le développement et la consultation des transactions.

L’environnement dépend de l’identifiant enregistré. Changer une étiquette, un préfixe ou ajouter « sandbox » à une URL ne change pas les droits d’une clé. D’anciens formats valides peuvent rester acceptés : suivez l’environnement enregistré.

Configurez explicitement l’environnement sur votre serveur. Stockez séparément les identifiants Sandbox et Live et vérifiez l’environnement renvoyé pour chaque paiement ou webhook.

Ces fonds n’ont aucune valeur réelle. Ils ne modifient pas votre solde réel, ne paient aucun achat réel et ne peuvent pas être retirés. Utilisez uniquement les outils Sandbox ; n’envoyez jamais d’argent ou de crypto réels vers une instruction Sandbox.

Ces conversions servent à tester les montants, soldes et historiques. Elles n’établissent ni le taux réel, ni les frais Live, ni la disponibilité d’une route de conversion en production.

Utilisez l’en-tête documenté X-Simulate-Error-Code avec une valeur prise en charge. Certaines simulations rejettent immédiatement la requête ; d’autres acceptent le paiement puis produisent un résultat ultérieur. Votre application doit gérer ces deux situations.

Cela permet de vérifier que votre application ne livre pas, ne libère pas de fonds et ne soumet pas un paiement sortant en double pendant l’attente. L’expiration de votre propre délai ne transforme pas le paiement en réussite.

Ce sont des données de test, pas une offre commerciale. Utilisez les frais Live réels pour calculer vos marges et informer les clients. La moyenne de 3 % plus 2 % concerne la tarification réelle ; elle n’impose pas 5 % à chaque exemple Sandbox.

Avant le lancement, confirmez la route, l’éligibilité, les limites, frais et disponibilité Live. Lorsque le service est activé, vérifiez le parcours concerné avec une petite opération réelle adaptée.

Si vous recevez BUSINESS_API_LIVE_PAYMENTS_DISABLED, continuez en Sandbox et vérifiez la disponibilité auprès de Fondeka. Ne multipliez pas les tentatives pour contourner la restriction. Les paiements déjà acceptés conservent leur traitement et leur suivi habituels.

1. Confirmez l’accès, les vérifications du compte et la disponibilité Live.
2. Vérifiez les moyens, pays, devises, réseaux, limites et frais réels nécessaires.
3. Testez les réussites, échecs, doublons et paiements non résolus en Sandbox.
4. Déployez un webhook HTTPS public qui vérifie les notifications et gère les doublons.
5. Créez et stockez séparément vos identifiants Live.
6. Approvisionnez le portefeuille réel concerné avant les paiements sortants.
7. Effectuez un petit test Live adapté et rapprochez le statut final, la notification et l’effet sur le portefeuille.

Séparez les identifiants et données Sandbox pour éviter qu’un développement ne déclenche un paiement de production.

Lire la liste de préparation au Live en anglais.

Prévoyez aussi une destination webhook HTTPS publique avant de compter sur les notifications automatiques. Vous pouvez préparer votre site et serveur pendant la configuration du compte. Vérifiez la route visée avant de la promettre à vos clients.

1. Créez un compte par le parcours Fondeka pris en charge ou utilisez votre compte existant.
2. Connectez-vous au portail Business.
3. Ouvrez l’espace API et consultez l’offre si une activation est nécessaire.
4. Après activation, vérifiez votre Business ID, les moyens et frais actuels.
5. Générez les identifiants Sandbox et enregistrez les deux secrets en sécurité.
6. Consultez les guides API du portail pour tester les parcours utiles et vérifier les webhooks.
7. Terminez les étapes de préparation Live avant d’utiliser l’argent de vos clients.

Il diffère du secret API et de la référence d’un paiement. Une clé appartient à un Business précis : changer l’ID dans l’URL ne l’autorise pas à opérer pour un autre Business.

Les identifiants et références de paiement sont propres au Business. Les Business d’un même compte partagent toutefois les soldes concernés de ce compte. Ne supposez pas qu’un profil dispose automatiquement d’un portefeuille financièrement séparé. Contactez Fondeka pour des soldes distincts ou une plateforme destinée à des marchands indépendants.

Conservez-le côté serveur ou dans un gestionnaire de secrets. Ne l’intégrez pas à une page publique, une application mobile, un dépôt Git, une capture ou un exemple partagé. Vos clients utilisent votre application, sans recevoir votre clé secrète.

La clé API sert aux requêtes ; le secret webhook sert à vérifier les notifications entrantes. Ils ne sont pas interchangeables. Le guide webhook décrit la vérification exacte, notamment la conservation des octets originaux du corps reçu.

Enregistrez les deux en sécurité à leur création. En cas de perte, générez un remplacement et mettez à jour votre serveur. Un préfixe masqué ne permet pas de reconstruire le secret original.

Pour une clé active, le portail permet de modifier la destination sans changer la clé ni le secret. Préparez d’abord le nouveau récepteur à vérifier le secret existant. Gardez l’ancien disponible pendant la transition : une tentative déjà en cours peut encore l’utiliser.

En développement, utilisez un tunnel HTTPS public adapté ou un récepteur de test déployé qui relaie vers votre environnement local. Vérifiez la réception et la signature d’un événement Sandbox réel avant de vous y fier.

La révocation n’annule pas les paiements déjà acceptés. Leurs événements webhook restent associés à l’identifiant et au secret d’origine. Conservez le récepteur et la configuration de vérification nécessaires jusqu’au rapprochement de ces paiements.

La documentation fournit aussi une référence OpenAPI et une collection Postman Sandbox. Ces aides ne remplacent pas une configuration sécurisée, des enregistrements durables, la gestion des erreurs et un récepteur webhook vérifié pour la production.

Selon l’opérateur, le client doit approuver sur son téléphone. Votre application suit le paiement jusqu’à sa réussite ou son échec. Ne livrez qu’après une fin vérifiée et les contrôles de montant nécessaires.

Lire le guide d’encaissement Mobile Money en anglais.

En Mobile Money, le payeur utilise le compte compatible associé à son téléphone. En crypto, il suit les instructions de facture depuis un portefeuille ou service externe adapté. Il doit toujours respecter les exigences du moyen utilisé.

Vérifiez le numéro avec le client et sa correspondance avec le pays et l’opérateur. Un format valide ne prouve pas que le compte existe, dispose des fonds ou peut approuver l’opération.

Tant que le résultat final n’est pas établi, ne lancez pas automatiquement une demande de remplacement. Après un échec confirmé, si le client veut réessayer, créez volontairement une nouvelle tentative avec sa propre identité.

Lorsqu’elles sont disponibles, affichez l’actif, le réseau, l’adresse, la quantité de jetons, l’expiration ou le lien de facture renvoyés. N’inventez pas d’adresse, ne substituez pas de réseau et ne calculez pas les jetons à partir d’un taux supposé.

Lire le guide d’encaissement crypto en anglais.

Le mode de frais, la conversion et la route peuvent modifier la quantité. Même si un jeton cherche à suivre une devise, affichez les instructions cotées plutôt que de supposer un rapport universel de 1:1.

Prévoyez une politique pour les écarts, par exemple une vérification manuelle de commande si le crédit est insuffisant. Ne demandez pas de payer une facture expirée et ne supposez pas qu’un transfert sur un autre réseau réglera la facture originale.

Une page de succès, une capture client, une réponse HTTP 202 ou un webhook non vérifié ne suffisent pas. Conservez le lien entre commande et paiement et vérifiez le règlement terminé avant de livrer.

Le portefeuille doit couvrir le débit brut, frais compris. À l’acceptation, le montant concerné est réservé ou débité, puis traité. Confirmez le statut final avant d’annoncer au bénéficiaire que le paiement est terminé.

Lire le guide des paiements sortants Mobile Money en anglais.

Le bénéficiaire reçoit la quantité de jetons cotée sur le réseau choisi. Vérifiez soigneusement l’adresse et le réseau : une erreur peut être irrécupérable. Des adresses d’apparence similaire ne prouvent pas leur compatibilité.

Lire le guide des paiements sortants crypto en anglais.

Un paiement EXCLUSIVE de 100 USD avec 5 USD de frais nécessite 105 USD. Utilisez le prix réellement renvoyé. La Sandbox utilise des fonds virtuels ; le Live, des fonds réels. Un encaissement en attente ne finance pas un paiement sortant avant sa réussite et son crédit.

Certaines routes peuvent dépendre de l’éligibilité du bénéficiaire ou d’un approvisionnement antérieur. Le catalogue aide à choisir les identifiants et comprendre les frais ; il n’approuve pas tous les bénéficiaires ou toutes les demandes.

Conservez la référence et l’identifiant de nouvelle tentative d’origine. Soumettre un nouveau paiement logique parce que le précédent semble lent peut créer un paiement distinct. Évitez les doublons et rapprochez d’abord l’opération originale.

Vérifiez les écritures du portefeuille et la référence. Si la restitution est incertaine, contactez le support. Un paiement non résolu peut rester en traitement avec des fonds réservés ; en envoyer un autre peut créer un doublon indésirable.

Contactez le support avec la référence. La récupération dépend du statut, du moyen et du résultat financier réel. N’envoyez pas automatiquement un paiement sortant compensatoire.

La soumission seule ne rend pas l’argent disponible. Vérifiez la fin, la devise réglée et le net réel. Pour plusieurs Business ou commandes, conservez vos propres enregistrements d’affectation.

Un transfert ultérieur constitue une action distincte, via un parcours de compte ou paiement sortant pris en charge, avec ses frais, disponibilités et conditions. Confirmez tout besoin de règlement bancaire particulier avant de construire vos opérations autour de cette hypothèse.

• La devise fiat de la requête ou du portefeuille représente la valeur monétaire, par exemple USD, CDF ou KES.
• Le moyen de paiement identifie l’opérateur ou l’actif crypto utilisé.
• Le réseau crypto et le montant en jetons, le cas échéant, décrivent les instructions blockchain.

Gardez-les distincts dans votre application. Sélectionner un moyen USDT ne signifie pas remplacer la devise fiat USD de la requête par USDT.

Les paiements API ont leur propre historique. La liste générale de l’application mobile ne contient pas nécessairement chaque paiement API. De même, une vue Live ne permet pas de retrouver une activité virtuelle Sandbox.

Dans un même environnement, les soldes concernés appartiennent au compte propriétaire. Plusieurs Business de ce compte peuvent donc les partager, même avec des identifiants, références et profils distincts. Organisez votre comptabilité en conséquence.

Les minimums, maximums, vérifications et conditions de solde varient aussi selon la route et le compte. Vérifiez votre cas actuel. Une requête acceptée peut rester non résolue : l’expiration d’un délai dans votre interface ne prouve pas un échec.

« En attente » est une description utile pour les clients, mais PENDING n’est pas un statut supplémentaire de ce contrat marchand.

Lire la référence des statuts de paiement en anglais.

L’opération peut réussir ou échouer plus tard. Ne marquez pas une commande comme payée, ne livrez pas et n’annoncez pas un paiement sortant terminé sur la seule base d’un code 202.

orderReference est votre référence facultative de commande, facture ou événement métier. Stockez un lien fiable entre votre enregistrement et le paiement. Elle ne remplace pas la clé d’idempotence distincte qui évite les soumissions en double.

Les événements couvrent les encaissements et paiements sortants réussis ou échoués. Les paiements acceptés ou en traitement ne produisent pas d’événement final simplement parce que le temps passe. Vous pouvez aussi consulter le point d’accès de recherche du paiement.

La livraison peut se répéter, notamment si un accusé de réception est perdu. Stockez les identifiants d’événements vérifiés et rendez la livraison de commande idempotente pour une même référence. Deux réceptions ne doivent ni livrer deux fois un produit numérique ni déclencher un autre paiement sortant.

Lire le guide des signatures webhook et des doublons en anglais.

Votre application doit aussi consulter la référence enregistrée pour rapprocher le résultat. Réparez le récepteur plutôt que de créer un nouveau paiement. Changer l’URL ne rejoue pas automatiquement tous les événements déjà livrés ou dont les tentatives sont épuisées.

Utilisez une autre clé pour un paiement réellement nouveau. Stockez durablement la clé et la requête originales côté serveur. Réutiliser une clé avec des informations différentes provoque un conflit plutôt qu’une modification sûre de l’opération.

Lire le guide de l’idempotence et des reprises sûres en anglais.

Ne générez pas automatiquement une nouvelle clé pour un nouvel encaissement ou paiement sortant. Un délai réseau dépassé indique l’absence de réponse chez vous, pas l’absence d’un paiement accepté. Faites examiner les attentes prolongées par le support en gardant leurs références.

Des informations peuvent être demandées pour vérifier votre compte ou examiner votre activité. Certaines opérations, surtout les paiements sortants, ont des conditions supplémentaires. Demandez au support ce qui s’applique à votre situation avant le Live.

Si votre modèle implique d’encaisser pour d’autres marchands, de conserver des fonds pour des tiers ou un parcours spécialisé, expliquez-le avant le lancement. Une intégration standard n’inclut pas automatiquement une plateforme, un séquestre ou l’ouverture de comptes pour d’autres marchands.

Vous restez responsable de votre application et des échanges avec vos clients. Fondeka fournit la connexion de paiement et les outils associés ; le service ne résout pas automatiquement les litiges sur vos produits ou services.

Le support peut enquêter avec le Business ID, l’environnement, la référence Fondeka, l’identifiant de requête, l’heure approximative et la description. Ne communiquez les données client sensibles que par le canal approprié et seulement si nécessaires.

Empêchez aussi les soumissions accidentelles par double clic et rendez la livraison idempotente. Ces contrôles complètent les validations et protections de l’API ; ils font partie d’une fonction paiement fiable.

Gardez vos informations Business à jour et soyez prêt à expliquer l’activité à l’origine des transactions si nécessaire. Le suivi continue pendant votre développement ; l’accès ne remplace pas un profil exact.

Fondeka vous aide à démarrer et construire une activité qui fonctionne. En grandissant, une connexion directe peut mieux répondre à vos besoins de prix, d’exploitation et de gestion. Nous en discutons avec vous plutôt que de présenter la moyenne Fondeka comme l’unique option à long terme.

Cette recommandation ne garantit ni l’acceptation ni un tarif particulier. L’agrégateur décide de l’entrée en relation et peut demander des documents, vérifications et informations supplémentaires. Votre préparation et votre historique restent importants.

Tenez à jour vos informations, vos démarches administratives et vos enregistrements de paiement. Préparez l’équipe technique à la prochaine intégration. En cas de migration, rapprochez correctement les paiements Fondeka existants, les soldes et les obligations webhook.

Vérifiez que votre offre inclut l’API et que l’activation est terminée. Si vous avez déjà payé ou eu accès, actualisez l’état et contactez le support avec la référence avant d’effectuer un autre paiement.

Lisez l’erreur. Pour BUSINESS_API_LIVE_PAYMENTS_DISABLED, utilisez la Sandbox et vérifiez l’ouverture auprès de Fondeka. Pour une autre exigence, corrigez le problème avant de réessayer.

Vérifiez le code exact et l’identifiant de requête. Les appels marchands utilisent la clé API Business ; la gestion du portail utilise la session du propriétaire connecté. Ne les substituez pas.

Une valeur d’énumération ou un ancien exemple ne garantit pas chaque route. Affichez l’erreur et ne proposez une alternative compatible que lorsqu’elle convient. Ne changez pas silencieusement la route ou le réseau.

Par exemple, 100 USD disponibles ne couvrent pas un paiement EXCLUSIVE de 100 USD si le débit total vaut 105 USD. Un solde Sandbox ne finance pas non plus un paiement Live.

Récupérez et rapprochez l’opération originale avant de décider d’en créer une nouvelle. Ne répondez pas automatiquement au conflit par une autre clé, surtout pour un paiement sortant : cela pourrait provoquer un second paiement indésirable.

Les quotas peuvent varier selon le point d’accès. L’approvisionnement Sandbox permet actuellement jusqu’à 1 000 000 d’unités virtuelles par ajout et 100 nouveaux ajouts par portefeuille de compte et devise, par jour UTC. Rejouer un ajout identique réussi ne consomme pas de place supplémentaire. Ces limites de test ne décrivent pas la capacité Live. Discutez de vos volumes de production avec Fondeka.

Vérifiez le Business et l’environnement. Les enregistrements Sandbox sont séparés du Live. Si le paiement manque toujours dans la bonne vue, transmettez sa référence et l’identifiant de requête au support.

• Le problème et le résultat attendu.
• Votre Business ID et l’environnement Sandbox ou Live.
• L’opération : encaissement, paiement sortant, activation, gestion d’identifiants ou autre.
• La référence de paiement ou d’achat Fondeka, si elle existe.
• L’identifiant de requête, le code d’erreur et la date et l’heure approximatives.
• Le pays, l’opérateur ou le réseau crypto, la devise et le montant concernés, si utiles.
• Les vérifications déjà effectuées, avec tous les secrets retirés des captures et exemples.

Ces éléments aident à distinguer un paiement en traitement d’un problème d’accès, de configuration, d’intégration ou de fournisseur.

Contactez-nous avant l’achat si votre décision dépend d’un opérateur, d’un couple pays/devise, d’une date Live, d’une exigence documentaire, d’un accord de frais ou d’un modèle à fort volume. Décrivez votre projet et son parcours de paiement pour que nous vous aidions à évaluer les étapes adaptées.

Vous payez l’accès API ou le pack, puis les frais applicables aux opérations utilisées. Le modèle moyen regroupe environ 3 % de frais agrégateur et 2 % de frais Fondeka en un seul frais d’environ 5 % par opération ; les tarifs réels sont visibles après activation. Testez avec de l’argent virtuel en Sandbox, confirmez séparément le Live et intégrez la sécurité et les confirmations. Avec votre croissance, Fondeka peut vous guider et vous recommander pour une intégration directe avec un agrégateur.