Skip to main content

Format

Toutes les erreurs suivent le même format JSON :
Lorsqu’une validation échoue sur plusieurs champs, message est un tableau :

Codes HTTP

Messages fréquents

Les en-têtes x-api-key et/ou x-api-secret sont absents. Vérifiez que votre client HTTP les envoie bien (certains proxies les suppriment).
Le secret ne correspond pas à la clé. Si vous avez régénéré le secret, l’ancien est invalidé immédiatement : mettez à jour votre configuration.
Le JWT authenticationtoken est absent, expiré ou invalide. Reconnectez-vous via POST /user/login-merchant.
Le montant minimum d’un paiement est de 101 FCFA.
Votre compte n’a pas encore été activé par Djonanko, ou a été désactivé. Contactez le support.
Le merchant_reference (ou reference) ne correspond à aucun compte. Vérifiez la casse : la référence est sensible à la casse.
La payment_reference ne correspond à aucun paiement. Vérifiez que vous utilisez bien la référence PAY… renvoyée à la création, et non l’id UUID.
Le montant du reversement demandé dépasse votre solde. Consultez GET /web-merchant/get-balance.
Un reversement doit être d’au moins 500 FCFA.
Ajoutez un compte de reversement et définissez-le comme principal, ou fournissez destination et operator dans la demande.
L’IP (ou la plage CIDR normalisée) existe déjà dans votre liste.
Supprimez une entrée inutilisée, ou regroupez vos serveurs dans une plage CIDR.
Les rapports mensuels ne peuvent être générés que pour un mois écoulé.

Bonnes pratiques

  • Journalisez le corps complet de chaque erreur avec la requête qui l’a provoquée.
  • Ne réessayez pas automatiquement une 400 ou 404 : l’appel échouera de la même façon.
  • Réessayez avec backoff les 500 et les erreurs réseau, en gardant la même metadata.order_id pour éviter de créer deux liens pour une même commande.
  • Avant de conclure qu’un paiement a échoué, vérifiez son statut avec GET /web-merchant/payment/status : un lien peut être PENDING alors que votre appel de création a expiré côté réseau.