FidePay permet à un marchand d’encaisser par carte, mobile money, lien de paiement, QR code ou wallet. Pour une nouvelle intégration web, utilisez les Checkout Sessions. Pour un traitement strictement serveur à serveur, l’API historique Access token + Make payment reste disponible.
Checkout moderne :https://admin.fide-pay.com/api · API serveur :https://admin.fide-pay.com/api/merchant · Vos clés se trouvent dans l’espace marchand. La clé secrète ne doit jamais être placée dans un navigateur.
Parcours recommandé
Checkout Sessions
Créez une session avec la clé publique, ouvrez l’URL sécurisée retournée par FidePay, puis suivez son statut. Le mode Test de votre espace marchand route automatiquement les nouvelles sessions vers la sandbox.
Avant de passer en productionCommencez par POST /api/checkout-sessions.Vérifiez que le marchand possède le wallet du pays et de la devise à encaisser.Utilisez uniquement des domaines HTTPS dans allowed_domains en mode live.
Comment ça marche, étape par étape
1
Créez votre compte marchand
Inscrivez-vous, complétez le profil marchand, puis récupérez votre clé publique et votre clé secrète dans l'espace marchand.
Appelez POST /api/checkout-sessions avec la clé publique, le montant, la devise et vos domaines autorisés. FidePay renvoie un jeton public et une URL de checkout sécurisée.
Redirigez le client vers checkout_url ou utilisez le SDK navigateur en mode superposition ou intégré. Les URL de retour et d’annulation restent sous votre contrôle.
5
Vérifiez le statut
Interrogez GET /api/checkout-sessions/{public_token}/status ou laissez le SDK le faire. Ne considérez pas une simple redirection navigateur comme une preuve de paiement.
Clé secrète côté serveurStockez-la dans une variable d'environnement. Jamais dans le navigateur, le dépôt Git ou le front.
Vérifiez toujours la signature IPNNe marquez jamais une commande comme payée sans valider le HMAC reçu — c'est votre garde-fou anti-fraude.
Une référence unique par paiementUn transaction_id unique facilite l'idempotence et le rapprochement comptable.
Séparez pays et devisePour XOF et XAF, envoyez toujours country : BJ pour Bénin, CI pour Côte d'Ivoire, GA pour Gabon, CM pour Cameroun.
Répondez 200 rapidement à l'IPNSinon FidePay réessaie. Si le traitement est long, accusez réception puis traitez en asynchrone.
Versions & migration
La documentation conserve le parcours historique, mais toute nouvelle intégration doit utiliser la version actuelle du checkout.
Publié le 10 août 2026
Version actuelle
API v1.0.4
Ajoute les Abonnements : plans récurrents, page de souscription hébergée, prélèvement automatique (solde FidePay sous mandat, carte tokenisée), relance mobile money par lien, et webhooks subscription.*. Entièrement compatible avec les intégrations v1.0.3.
Historique
API v1.0.3
Clés d’API sandbox dédiées et webhooks par environnement (sandbox / production). Toujours fonctionnelle.
Historique
API v1.0.2
Webhooks configurables au niveau du compte et conversion de devise selon le pays du payeur. Toujours fonctionnelle.
Historique
API v1.0.1
Checkout Sessions, checkout hébergé, collecte des informations du payeur et confirmation fiable du paiement. Toujours fonctionnelle.
Historique
API v1.0
Conservée comme référence pour les intégrations existantes. Sa compatibilité avec les nouveaux écrans de checkout n’est plus garantie : migrez et retestez avant toute remise en production.
Nouveautés de la version 1.0.3
Clés d’API sandbox dédiéesChaque compte dispose d’une paire de clés de démonstration, préfixée sandbox_, générée depuis l’espace marchand (Développeurs → Documentation API → onglet Sandbox). Une clé sandbox est refusée sur les endpoints de production, et inversement les endpoints sandbox continuent d’accepter la clé live pour ne pas casser les intégrations écrites avant cette version.
Webhooks par environnementURL, événements et journal séparés pour la sandbox et la production. Les notifications sandbox sont signées avec la clé secrète sandbox — même formule qu’en production.
Nouveaux en-têtes de notificationX-Webhook-Event, X-Webhook-Environment, X-Webhook-Timestamp, X-Webhook-Delivery et X-Webhook-Retry accompagnent désormais chaque envoi. Le corps gagne un champ environment. Purement additif : vos vérifications existantes restent valables.
Webhook de paiement sandboxUn paiement de test mené à son terme déclenche la notification payment.succeeded sur votre URL sandbox — de quoi valider toute la chaîne sans argent réel.
Espace développeursLe tableau de bord regroupe désormais Clé API, Webhooks, Gateway, Couverture des pays, Applications et SDK & plugins.
Nouveautés de la version 1.0.2
Webhooks au niveau du compteEnregistrez une URL de notification une fois pour toutes depuis votre espace marchand, au lieu de transmettre ipn_url à chaque requête. L’ancien paramètre reste prioritaire et pleinement supporté.
Choix des événementsSélectionnez les événements à recevoir parmi payment.succeeded, payment.failed, payment.pending, payout.succeeded, payout.failed, subscription.renewed et subscription.cancelled. Sans sélection, tous sont envoyés.
Journal des livraisonsChaque tentative est tracée : événement, code HTTP, réponse, erreur et horodatage. Une notification échouée peut être relancée en un clic.
Notification de testValidez votre endpoint avant la mise en production, sans créer de vrai paiement.
Conversion selon le pays du payeurLe paramètre currency_mode convertit le montant d’un lien dans la devise du payeur. Voir Devise du payeur.
Signature inchangéeLe schéma reste hmac_sha256(secret_key, transaction_id + total_amount) : aucune modification à apporter à vos vérifications existantes.
Améliorations de la version 1.0.1
Le checkout carte collecte le nom, le prénom, l’adresse e-mail, le téléphone et l’adresse de facturation du payeur.
Le pays utilise un code ISO à deux lettres et la devise doit être activée pour le marchand et la passerelle choisie.
Le consentement aux conditions de paiement est demandé avant l’encaissement.
Les informations du payeur peuvent être transmises au partenaire par le statut de session, les métadonnées ou le webhook, selon l’intégration.
La réussite doit être confirmée côté serveur par un statut ou un webhook signé, jamais uniquement par la redirection du navigateur.
Migration depuis v1.0 : créez les nouveaux paiements avec POST /api/checkout-sessions, utilisez l’URL checkout_url renvoyée par l’API et ne dépendez jamais de la structure HTML interne du checkout. Les intégrations anciennes doivent être retestées en sandbox avant le passage en production.
Carte bancaire et devises
Le moyen « Carte bancaire » accepte Visa et Mastercard via une page de paiement sécurisée (3D Secure inclus). Le réseau de la carte est détecté automatiquement dans le champ sécurisé — aucune donnée de carte ne transite par FidePay.
Devises actuellement compatibles avec le paiement par carte :AUD, CAD, CHF, CZK, DKK, EUR, GBP, HKD, HUF, ILS, JPY, MXN, NOK, NZD, PLN, RON, SEK, SGD, TRY, USD et ZAR.
Le formulaire carte est identique pour ces 21 devises. Si la carte du payeur est libellée dans une autre devise, sa banque peut effectuer une conversion et appliquer ses propres frais. Les moyens de paiement alternatifs (portefeuilles, virements) sont traités séparément et ne sont pas présentés comme un paiement Visa ou Mastercard.
Test & go live
Test et production sont deux circuits séparés. Pour les Checkout Sessions, le sélecteur Test/Live de l’espace marchand est la source de vérité : en mode Test, les nouvelles sessions sont automatiquement envoyées vers la sandbox. L’API serveur historique conserve aussi ses routes sandbox dédiées.
Circuit sandboxPour tester l'intégration, les webhooks, les pays et les erreurs sans mouvement financier réel.
Circuit productionPour encaisser de vrais clients. Les échecs viennent alors des soldes, opérateurs, limites ou validations réelles.
Usage
Sandbox
Production
Checkout Session
POST /api/checkout-sessions avec le compte en mode Test
POST /api/checkout-sessions avec le compte en mode Live
Access token
POST /api/merchant/sandbox/access-token
POST /api/merchant/access-token
Paiement
POST /api/merchant/sandbox/make-payment
POST /api/merchant/make-payment
Clé publique
sandbox_… (onglet Sandbox de votre espace)
clé live (onglet Production)
Webhooks
URL et événements de l’onglet Sandbox, signés avec la clé secrète sandbox
URL et événements de l’onglet Production, signés avec la clé secrète live
Clés sandbox dédiées (v1.0.3) : générez une paire de clés de démonstration, préfixée sandbox_, depuis Développeurs → Documentation API → onglet Sandbox. Une clé sandbox est refusée sur les endpoints de production — impossible de mélanger les environnements par erreur. Les endpoints sandbox acceptent encore la clé live pour les intégrations écrites avant la v1.0.3.
Carte test (succès)Visa 4242 4242 4242 4242 ou Mastercard 4242 4242 4242 4242 · date future · CVV libre.
Carte test (échecs)4000 0000 0000 9995 fonds insuffisants · 4532 3367 4387 4205 carte expirée · 4242 4242 4242 4242 échec 3DS (montant ≥ 30 €).
Mobile money testNuméros de test pour les 12 pays couverts : voir Numéros de test. Envoyez 5000, pas 5000.00.
Webhook testUtilisez une URL HTTPS publique et répondez 200.
Page de paiement sandboxUID 12344567890 · mot de passe 12345678. Le paiement validé déclenche payment.succeeded sur votre URL de webhook sandbox.
Diagnostic rapide
Le paiement n'apparaît pas dans le CSV sandboxVérifiez que vous avez appelé /api/merchant/sandbox/make-payment. Si vous avez utilisé /api/merchant/make-payment, le paiement est parti sur le circuit live.
Erreur Bénin / montant invalideLes opérateurs Bénin n'acceptent pas les décimales sur PawaPay. Envoyez 5000 et non 5000.00.
Erreur pays ou mauvais opérateurLe champ country doit correspondre au wallet marchand et au numéro mobile. Exemple : BJ avec un numéro 229....
Webhook non reçuLe navigateur n'est pas la preuve du paiement. La confirmation fiable vient de l'IPN signé ou du contrôle de statut côté serveur.
Numéros de test mobile money
En sandbox, chaque opérateur expose des numéros qui simulent un résultat précis :
le paiement aboutit, reste en attente, ou échoue avec un motif donné. Utilisez-les avec
POST /api/merchant/sandbox/make-payment ou une Checkout Session en mode Test —
si votre intégration passe ces scénarios, elle passera en production. Les tableaux ci-dessous
couvrent uniquement les corridors actifs chez FidePay ; ils reprennent les numéros officiels
du bac à sable de notre partenaire mobile money.
Rappel : ces numéros concernent les paiements entrants (dépôts).
Le montant doit être un entier pour les corridors XOF/XAF (5000, pas 5000.00).
Aucun SMS n’est envoyé : la confirmation est simulée automatiquement.
Bénin
Opérateur
Numéro de test
Résultat simulé
MTN MoMo
22951345789
Paiement réussi
22951345129
Reste en attente
22951345039
Refusé par le payeur
22951345029
Payeur introuvable
22951345069
Échec générique
Moov Money
22995345789
Paiement réussi
22995345639
Reste en attente
22995345679
Refusé par le payeur
22995345529
Échec générique
Cameroun
Opérateur
Numéro de test
Résultat simulé
MTN MoMo
237653456789
Paiement réussi
237653456129
Reste en attente
237653456039
Refusé par le payeur
237653456029
Payeur introuvable
237653456019
Plafond payeur atteint
237653456069
Échec générique
Congo-Brazzaville
Opérateur
Numéro de test
Résultat simulé
Airtel Money
242053456789
Paiement réussi
242053456129
Reste en attente
242053456039
Refusé par le payeur
242053456049
Solde insuffisant
242053456069
Échec générique
MTN MoMo
242063456789
Paiement réussi
242063456129
Reste en attente
242063456039
Refusé par le payeur
242063456029
Payeur introuvable
242063456049
Solde insuffisant
242063456069
Échec générique
Congo-Kinshasa (RDC)
Opérateur
Numéro de test
Résultat simulé
Airtel Money
243973456789
Paiement réussi
243973456129
Reste en attente
243973456069
Échec générique
Orange Money
243893456789
Paiement réussi
243893456129
Reste en attente
243893456039
Refusé par le payeur
243893456029
Payeur introuvable
243893456049
Solde insuffisant
243893456069
Échec générique
M-Pesa (Vodacom)
243813456789
Paiement réussi
243813456129
Reste en attente
243813456039
Refusé par le payeur
243813456029
Payeur introuvable
243813456049
Solde insuffisant
243813456019
Plafond payeur atteint
243813456069
Échec générique
Côte d'Ivoire
Opérateur
Numéro de test
Résultat simulé
MTN MoMo
2250503456789
Paiement réussi
2250503456129
Reste en attente
2250503456039
Refusé par le payeur
2250503456029
Payeur introuvable
2250503456069
Échec générique
Orange Money
2250734567890
Paiement réussi
2250734567130
Reste en attente
2250734567030
Refusé par le payeur
2250734567060
Échec générique
Gabon
Opérateur
Numéro de test
Résultat simulé
Airtel Money
24174345678
Paiement réussi
24174345128
Reste en attente
24174345048
Solde insuffisant
24174345068
Échec générique
Kenya
Opérateur
Numéro de test
Résultat simulé
M-Pesa
254703456789
Paiement réussi
254703456129
Reste en attente
254703456039
Refusé par le payeur
254703456049
Solde insuffisant
254703456019
Plafond payeur atteint
254703456059
Transaction déjà en cours
254703456069
Échec générique
Ouganda
Opérateur
Numéro de test
Résultat simulé
Airtel Money
256753456789
Paiement réussi
256753456129
Reste en attente
256753456039
Refusé par le payeur
256753456049
Solde insuffisant
256753456019
Plafond payeur atteint
256753456069
Échec générique
MTN MoMo
256783456789
Paiement réussi
256783456129
Reste en attente
256783456029
Payeur introuvable
256783456019
Plafond payeur atteint
256783456069
Échec générique
Rwanda
Opérateur
Numéro de test
Résultat simulé
MTN MoMo
250783456789
Paiement réussi
250783456129
Reste en attente
250783456039
Refusé par le payeur
250783456029
Payeur introuvable
250783456019
Plafond payeur atteint
250783456069
Échec générique
Airtel Money
250733456789
Paiement réussi
250733456129
Reste en attente
250733456039
Refusé par le payeur
250733456049
Solde insuffisant
250733456069
Échec générique
Sénégal
Opérateur
Numéro de test
Résultat simulé
Orange Money
221773456789
Paiement réussi
221773456129
Reste en attente
221773456029
Payeur introuvable
221773456049
Solde insuffisant
221773456069
Échec générique
Free Money
221763456789
Paiement réussi
221763456129
Reste en attente
221763456049
Solde insuffisant
221763456069
Échec générique
Sierra Leone
Opérateur
Numéro de test
Résultat simulé
Orange Money
23276123456
Paiement réussi
Zambie
Opérateur
Numéro de test
Résultat simulé
MTN MoMo
260763456789
Paiement réussi
260763456129
Reste en attente
260763456039
Refusé par le payeur
260763456029
Payeur introuvable
260763456019
Plafond payeur atteint
260763456069
Échec générique
Zamtel Money
260953456700
Paiement réussi
260953456789
Reste en attente
260953456704
Solde insuffisant
260953456712
Échec générique
Checkout Sessions
C’est le point d’entrée recommandé pour une nouvelle intégration. Une session contient le montant, la devise, le client, les domaines autorisés et le mode d’exécution. FidePay retourne une URL de paiement hébergée et un jeton public utilisable pour suivre le statut.
POST/api/checkout-sessions
Authentification : envoyez la publishable_key du marchand. Cette clé peut être utilisée par le SDK navigateur. La clé secrète n’est jamais nécessaire pour créer une Checkout Session.
Code ISO sur 3 lettres pris en charge par FidePay.
allowed_domains
Oui
De 1 à 10 origines, sans joker. HTTPS obligatoire en production.
return_url / cancel_url
Non
URL de retour après succès ou annulation.
customer_email, customer_name, customer_phone
Non
Préremplissage du checkout. Téléphone au format international.
mode
Non
live ou sandbox. Le mode Test du compte marchand force la sandbox.
metadata
Non
Jusqu’à 20 valeurs texte pour votre rapprochement interne.
Suivre le statut
GET/api/checkout-sessions/{public_token}/status
Cette route publique est limitée en fréquence et prévue pour le suivi temporaire du checkout. Les statuts terminaux sont succeeded, failed, cancelled ou expired. Le SDK navigateur l’interroge automatiquement toutes les deux secondes pendant le paiement.
Access token
Échangez la clé publique du marchand contre un token Bearer court. Le token sert ensuite à créer la session de paiement.
var client = HttpClient.newHttpClient();
var req = HttpRequest.newBuilder()
.uri(URI.create("https://admin.fide-pay.com/api/merchant/access-token"))
.header("Content-Type", "application/json")
.POST(HttpRequest.BodyPublishers.ofString("{\"public_key\":\"pk_xxx\"}"))
.build();
var res = client.send(req, HttpResponse.BodyHandlers.ofString());
using System.Net.Http.Json;
var http = new HttpClient();
var response = await http.PostAsJsonAsync(
"https://admin.fide-pay.com/api/merchant/access-token",
new { public_key = "pk_xxx" }
);
var body = await response.Content.ReadFromJsonAsync<TokenResponse>();
var token = body?.Token;
Créez une session, puis redirigez votre client vers le champ payment_url retourné par l'API. Pour les devises utilisées dans plusieurs pays comme XOF et XAF, le champ country est obligatoire afin d'afficher les bons moyens de paiement.
Mac mac = Mac.getInstance("HmacSHA256");
mac.init(new SecretKeySpec(secretKey.getBytes(), "HmacSHA256"));
byte[] raw = mac.doFinal((transactionId + totalAmount).getBytes());
String expected = HexFormat.of().formatHex(raw);
if (!MessageDigest.isEqual(expected.getBytes(), signature.getBytes())) {
// return 401
}
mac := hmac.New(sha256.New, []byte(secretKey))
mac.Write([]byte(transactionID + totalAmount))
expected := hex.EncodeToString(mac.Sum(nil))
if !hmac.Equal([]byte(expected), []byte(signature)) {
// return HTTP 401
}
using System.Security.Cryptography;
using System.Text;
var message = transactionId + totalAmount;
using var hmac = new HMACSHA256(Encoding.UTF8.GetBytes(secretKey));
var expected = Convert.ToHexString(
hmac.ComputeHash(Encoding.UTF8.GetBytes(message))
).ToLowerInvariant();
if (!CryptographicOperations.FixedTimeEquals(
Encoding.UTF8.GetBytes(expected),
Encoding.UTF8.GetBytes(signature)
)) {
// return HTTP 401
}
require "openssl"
message = "#{transaction_id}#{total_amount}"
expected = OpenSSL::HMAC.hexdigest("SHA256", secret_key, message)
unless Rack::Utils.secure_compare(expected, signature)
halt 401
end
Moyens de paiement disponibles
Récupérez les moyens réellement activés pour le marchand et le pays du client. Cette route évite d’afficher un opérateur mobile money qui n’est pas disponible dans le corridor demandé.
Règle pays + devise : le filtrage mobile money utilise le pays du client et les devises disponibles dans les wallets du marchand. Les cartes et wallets internationaux restent proposés lorsqu’ils sont activés et compatibles avec la devise.
Mobile money et moyens de paiement
FidePay connecte les clients, marchands et agents aux moyens de paiement utiles entre l'Europe et l'Afrique : mobile money, carte, lien de paiement, QR et wallet.
Mobile moneyM-Pesa, Orange Money, Airtel Money, MTN selon pays.
CartesVisa, Mastercard et portefeuille virtuel lorsque le service est activé.
WalletSolde client, marchand ou agent avec suivi des transactions.
Pays, devise et opérateurs
Un wallet n'est pas seulement une devise. Pour les zones qui partagent une monnaie, FidePay sépare le pays afin d'afficher les bons opérateurs et d'éviter d'envoyer un client béninois vers un moyen de paiement ivoirien ou gabonais.
Bénincountry: BJ · XOF · MTN MoMo, Moov Money
Côte d'Ivoirecountry: CI · XOF · opérateurs activés localement
Gaboncountry: GA · XAF · opérateurs activés localement
Camerouncountry: CM · XAF · opérateurs camerounais uniquement
RDCcountry: CD · CDF ou USD · Airtel, Orange, Vodacom selon disponibilité
InternationalEUR, USD, cartes et wallet FidePay selon activation du marchand
Webhooks du compte
Depuis la v1.0.2, vous pouvez enregistrer une URL de notification une fois pour toutes
depuis votre espace marchand, au lieu de transmettre ipn_url à chaque requête.
L’ancien paramètre reste supporté et prioritaire lorsqu’il est fourni : vos intégrations
existantes continuent de fonctionner sans modification.
Configurer
Espace marchand → Webhooks. L’URL doit être en HTTPS, car la notification
transporte des données de paiement.
Méthode
Endpoint
Rôle
GET
/merchant/webhooks?environment=sandbox|live
Configuration, statistiques et 50 dernières livraisons de l’environnement.
POST
/merchant/webhooks
Enregistre l’URL et les événements souscrits. Champ environment : live (défaut) ou sandbox.
POST
/merchant/webhooks/test
Envoie une notification de test vers l’environnement choisi, sans créer de paiement réel.
POST
/merchant/webhooks/{id}/retry
Rejoue une notification échouée, dans son environnement d’origine.
Sandbox et Production
L’intégration est identique dans les deux environnements. Seules la clé de signature
et la configuration changent — votre code de réception, lui, ne change pas.
Aspect
Sandbox
Production
Clé de signature
clé secrète sandbox (sandbox_…)
clé secrète live
En-tête X-Webhook-Environment
sandbox
live
Champ environment du corps
"sandbox"
"live"
Configuration
Espace marchand → Webhooks → onglet Sandbox
Espace marchand → Webhooks → onglet Production
En-têtes de la requête
En-tête
Contenu
Content-Type
application/json
X-Webhook-Event
Le type d’événement, par ex. payment.succeeded.
X-Webhook-Environment
sandbox ou live.
X-Webhook-Timestamp
Horodatage Unix de l’envoi.
X-Webhook-Delivery
Identifiant unique de la livraison — utile pour l’idempotence.
En sandbox, la secret_key est votre clé secrète sandbox ; la formule est
identique. Ne marquez jamais une commande comme payée sans avoir validé la signature.
import hmac, hashlib, os
@app.post("/fidepay/webhook")
def fidepay_webhook():
payload = request.get_json(force=True)
secret = (os.environ["FIDEPAY_SECRET_SANDBOX"] # sandbox_…
if payload["environment"] == "sandbox"
else os.environ["FIDEPAY_SECRET_LIVE"])
expected = hmac.new(
secret.encode(),
(payload["data"]["transaction_id"] + payload["data"]["total_amount"]).encode(),
hashlib.sha256,
).hexdigest()
if not hmac.compare_digest(expected, payload["signature"]):
return "", 401
# Traiter l'événement, puis répondre 200.
return {"received": True}
Bonnes pratiques
Répondez viteVotre endpoint a 8 secondes. Si le traitement est long, répondez 200 immédiatement et traitez en tâche de fond.
IdempotenceLa même notification peut arriver plusieurs fois (relance). Utilisez X-Webhook-Delivery pour ignorer les doublons déjà traités.
HTTPS obligatoireLa notification transporte des données de paiement : aucune URL non chiffrée n’est acceptée.
RelanceUn échec (code non-2xx, délai dépassé) est journalisé et relançable en un clic depuis votre espace, dans son environnement d’origine.
Comportement d’envoi
Règle
Détail
Priorité
Un ipn_url transmis dans la requête prime sur l’URL du compte.
Délais
4 s pour la connexion, 8 s pour la réponse. Un endpoint lent n’impacte jamais le traitement du paiement.
Réponse attendue
Un code HTTP 2xx. Toute autre réponse est enregistrée comme un échec, relançable depuis votre espace.
Traçabilité
Chaque tentative est journalisée : code HTTP, extrait de réponse, erreur et horodatage.
Abonnements
Facturez vos clients de façon récurrente : vous créez un plan (montant, devise, intervalle, essai gratuit), vos clients s’abonnent, et FidePay déclenche chaque échéance automatiquement. Trois niveaux d’intégration, du zéro code à l’API complète.
Prélèvement automatique : réel uniquement pour le solde FidePay (mandat explicite accepté par le payeur, révocable) et la carte bancaire (méthode tokenisée — aucun numéro de carte ne transite ni n’est stocké chez FidePay). Pour le mobile money, aucun débit sans action du payeur : à chaque échéance, votre client reçoit un e-mail avec un lien de paiement, et l’abonnement avance dès qu’il paie.
1. Sans code : le lien d’abonnement
Créez votre plan dans Dashboard → Abonnements, cliquez « Copier le lien d’abonnement » et placez-le sur votre site. Vos clients arrivent sur une page hébergée FidePay (logos des moyens de paiement, mandat, badge MODE TEST en sandbox) :
Jeton public du plan (préfixe plan_), visible dans le dashboard.
customer_email
Oui
Reçoit la confirmation et les liens d’échéance.
method
Oui
wallet, card ou mobile_money.
account_number / account_password
Si wallet
Identifiants du payeur FidePay, vérifiés à la souscription — jamais stockés. En sandbox : 12344567890 / 12345678.
mandate_accepted
Si wallet
true obligatoire : mandat de prélèvement explicite du payeur.
customer_name, customer_phone
Non
Informations client optionnelles.
Abonnement par carte : à la souscription, le client est redirigé vers une
page de paiement sécurisée (3D Secure) où sa carte est enregistrée de façon tokenisée — elle n'est
jamais stockée chez FidePay. Les échéances suivantes sont prélevées automatiquement, avec relances
automatiques en cas d'échec (J+1, J+3, J+7). En sandbox, utilisez la carte
4242 4242 4242 4242 (date future, CVC 123) ; 4000 0000 0000 9995 simule un
refus et 4000 0000 0000 3220 un parcours 3D Secure.
Statuts d’un abonnement
Statut
Signification
trialing
Essai gratuit en cours, première facturation en fin d’essai.
active
À jour — la prochaine échéance est programmée.
pending_payment
Une échéance attend le paiement du lien (mobile money, premier cycle carte).
past_due
Prélèvement échoué, nouvelle tentative sous 24 h (3 tentatives).
unpaid
3 échecs consécutifs — l’abonnement est suspendu.
canceled
Résilié par vous ou par le client.
3. Webhooks
Chaque événement d’abonnement est envoyé sur l’URL webhook de votre compte, signé comme les webhooks de paiement (voir Webhooks du compte) et séparé par environnement — un plan sandbox n’émet que des webhooks sandbox.
Événement
Déclencheur
subscription.renewed
Une échéance vient d’être encaissée, la période avance.
subscription.payment_due
Échéance mobile money : le lien de paiement a été envoyé au client.
subscription.payment_failed
Prélèvement échoué (motif et numéro de tentative inclus).
subscription.canceled
Abonnement suspendu après 3 échecs ou résilié.
Astuces
Astuce
Pourquoi
Offrez un essai gratuit (trial_days)
L'abonnement démarre immédiatement en trialing sans paiement — la première facturation part en fin d'essai. Idéal pour convertir.
Proposez un plan annuel moins cher
Créez deux plans (mensuel + annuel avec remise) et placez les deux liens côte à côte : le prélèvement annuel réduit les échecs de paiement.
Écoutez subscription.payment_failed
Prévenez votre client dès le premier échec (il reste 2 tentatives automatiques) — la plupart des impayés se règlent avec un simple rappel.
Archivez, ne supprimez pas
Archiver un plan bloque les nouvelles souscriptions mais laisse vos abonnés existants continuer — aucun client coupé par erreur.
Privilégiez le solde FidePay en Afrique
C'est le seul prélèvement 100 % automatique sans carte : encouragez vos clients à alimenter leur compte FidePay pour ne jamais rater une échéance.
Un même client, plusieurs abonnements
Chaque souscription a son jeton sub_… indépendant : un client peut cumuler plusieurs plans (ex. logiciel + support).
Tester en sandbox : passez votre compte en Mode test, créez un plan (il sera automatiquement sandbox), ouvrez son lien /subscribe/… et abonnez-vous avec le solde de démonstration 12344567890 / 12345678. Aucun argent réel ne circule, et vos webhooks sandbox reçoivent les événements.
Devises
Code
Usage
Note
EUR
Europe
Compte marchand Europe.
USD
International
Wallet principal.
CDF
RDC
Mobile money et agents.
XOF
Afrique de l'Ouest
Obligatoire avec country : BJ, CI, SN, etc.
XAF
Afrique centrale
Obligatoire avec country : CM, GA, CG, etc.
KES, RWF, UGX, ZMW
Afrique de l'Est
Selon les opérateurs activés pour le marchand.
CAD, BRL, GBP
International
Selon les moyens de paiement activés.
Devise du payeur et conversion automatique
FidePay détecte le pays du payeur à partir de son adresse IP, uniquement pour lui présenter
le bon prix et les moyens de paiement disponibles chez lui. Cette détection ne sert à aucun
autre usage et le résultat est mis en cache 24 h.
Choix de la devise proposée
La devise retenue est la première, par ordre de préférence du pays, que le
marchand peut réellement encaisser — c'est-à-dire pour laquelle il possède déjà un
portefeuille. Aucun portefeuille n'est créé automatiquement. À défaut, la devise d'origine du
lien est conservée.
Pays du payeur
Devises par ordre de préférence
Zone euro (BE, FR, DE, ES, IT, NL, PT, IE, LU, AT)
EUR
US · GB · CA · AU
USD · GBP · CAD · AUD
CD — RDC
USD puis CDF
Afrique centrale (CG, CM, GA, TD, CF, GQ)
XAF
Afrique de l'Ouest (CI, SN, BJ, BF, ML, NE, TG)
XOF
KE · RW · UG · NG · GH · ZA · TZ · ZM · SL · MW · MZ
Devise nationale correspondante
Pays non listé
Devise d'origine du lien
Activer la conversion sur un lien de paiement
La conversion est désactivée par défaut : un lien reste dans la devise choisie à sa
création. Pour l'activer, envoyez currency_mode à la création du lien.
Valeur
Comportement
fixed(défaut)
Le montant et la devise restent ceux fixés par le marchand.
automatic
À l'ouverture du lien, le montant est converti dans la devise du payeur.
Garanties
Garantie
Détail
Conversion unique
Elle n'a lieu qu'une seule fois, à la première ouverture. Un rechargement depuis un autre pays ne modifie plus le montant.
Montant d'origine conservé
La devise et le montant de base, le taux appliqué, le pays détecté et l'horodatage restent enregistrés sur la transaction.
Transaction en attente uniquement
Un paiement déjà réglé, annulé ou échoué n'est jamais modifié.
Repli sûr
Si un taux de change est indisponible, la devise d'origine est conservée plutôt que d'appliquer un montant incertain.
Montant libre
Un lien sans montant prédéfini n'est pas converti : le payeur saisit lui-même le montant dans la devise proposée.
Exemple
Un abonnement facturé 10 USD par un marchand possédant les portefeuilles
USD, EUR et CDF :
Payeur
Devise proposée
Montant affiché
Belgique
EUR
8,70 €
RDC
USD
10,00 $
Côte d'Ivoire (marchand sans XOF)
USD
10,00 $
Les montants dépendent des taux en vigueur au moment de l'ouverture du lien.
SDK officiels
Les kits officiels FidePay couvrent le checkout navigateur, les appels serveur et la vérification des signatures. Téléchargez le kit correspondant à votre environnement et conservez toujours les opérations secrètes côté serveur.
Astuce : chaque SDK lit la clé secrète depuis une variable d'environnement (FIDEPAY_SECRET_KEY). Ne la mettez jamais dans un fichier versionné ni côté navigateur — seul le serveur signe les requêtes.
Intégration HTTP native
Pas de SDK pour votre stack ? Le contrat REST ci-dessus suffit. Voici les recettes recommandées par langage.
JVJava
java.net.http.HttpClient (JDK 11+) ou OkHttp + Spring Boot.
Voir l'exemple →
GOGo
net/http + crypto/hmac pour la vérification de signature.
Voir l'exemple →
Le SDK navigateur crée une Checkout Session, ouvre le paiement dans une superposition ou dans un conteneur de votre page, puis suit le statut jusqu’à la fin. Le kit est autonome et ne demande aucune dépendance d’exécution.
Ouvre le checkout au-dessus de votre page. C’est le mode recommandé pour démarrer.
inline
Monte le checkout dans un conteneur de votre interface. Indiquez le sélecteur dans container.
Redirection
Utilisez directement la valeur checkout_url si vous ne souhaitez pas charger de SDK.
Sécurité : vérifiez toujours que l’origine courante figure dans allowed_domains. Le SDK utilise uniquement la clé publique et le jeton de session ; ne placez jamais votre clé secrète dans le code livré au navigateur.
Plugins e-commerce
Installez un plugin, activez FidePay, collez les clés API et configurez les URLs IPN/callback de votre boutique.