Skip to main content

Structure de la Réponse d’Erreur

Toutes les erreurs suivent un format cohérent :

Codes de Statut HTTP

Codes d’Erreur Courants

MISSING_ACCESS_TOKEN

  • Message : Access token is required
  • Cause : L’en-tête X-Access-Token est manquant
  • Action : Incluez votre clé API dans l’en-tête

INVALID_ACCESS_TOKEN / ERR_AUTH

  • Message : The provided access token is invalid
  • Cause : La clé API est incorrecte, expirée ou révoquée
  • Action :
    • Vérifiez que la clé API est correcte
    • Générez une nouvelle clé si nécessaire
    • Ne journalisez pas les valeurs de clé sensibles
    • Contactez le support si le problème persiste

NO_BALANCE / INSUFFICIENT_BALANCE

  • Message : Insufficient balance
  • Cause : Le solde du compte est trop faible
  • Action :
    • Vérifiez le solde via /v3/account/balance avant les opérations
    • Affichez le solde actuel à l’utilisateur
    • Proposez une option de rechargement
    • N’effectuez pas de nouvelle tentative sans avoir ajouté des fonds

DUPLICATED_REF

  • Message : This reference ID is already in use
  • Cause : La référence a déjà été utilisée dans une requête précédente
  • Action :
    • Vérifiez le statut de la commande existante
    • Générez une nouvelle référence unique
    • Ne créez pas de commandes en double

IP_BLOCKED

  • Message : Your IP has been temporarily blocked
  • Cause : Trop de tentatives d’authentification échouées
  • Action :
    • Attendez 15 minutes pour le déblocage automatique
    • Vérifiez la clé API correcte
    • Contactez le support si le problème persiste

IP_NOT_ALLOWED

  • Message : Your IP address is not whitelisted
  • Cause : La liste blanche d’IP est activée
  • Action : Ajoutez votre IP à la liste blanche dans le tableau de bord

ERR_VALIDATION

  • Message : Validation error
  • Cause : Les paramètres de requête ne respectent pas les exigences
  • Problèmes Courants : Champs manquants, types de données invalides, non-correspondance de motif
  • Action :
    • Validez les entrées côté client en premier
    • Vérifiez error.details pour les problèmes de champs spécifiques
    • Ne réessayez pas sans corriger le problème

ERR_PHONE

  • Message : Invalid phone number
  • Cause : Le numéro de téléphone est incorrect ou n’existe pas
  • Action : Utilisez /v3/internet/check-number pour valider en premier

ERR_STOCK

  • Message : Product out of stock
  • Cause : Le produit/la valeur de carte demandé(e) n’est pas disponible
  • Action :
    • Vérifiez le stock avant de commander
    • Proposez des dénominations alternatives
    • Réessayez ultérieurement

NOT_FOUND - Message : Resource not found - Cause : La ressource

demandée n’existe pas - Cas Courants : ID de commande invalide, référence invalide, ressource supprimée - Action : - Vérifiez que l’ID/la référence est correct(e) - Vérifiez les fautes de frappe - Gérez de manière élégante dans l’interface utilisateur

RATE_LIMIT_EXCEEDED

  • Message : Too many requests
  • Cause : La limite de taux a été dépassée
  • Limites : Sandbox : 60 req/min, Production : 120 req/min
  • Action : Implémentez un backoff exponentiel avec une logique de nouvelle tentative

INTERNAL_SERVER_ERROR / INTERNAL_ERROR

  • Message : Developer was notified and will check shortly
  • Cause : Erreur inattendue sur nos serveurs
  • Action :
    • Ne remboursez pas immédiatement - attendez 24 heures
    • Sauvegardez le requestId pour le support
    • Implémentez une logique de nouvelle tentative avec backoff
    • Contactez le support avec les détails
    • Nous sommes automatiquement notifiés

ERR_SERVICE

  • Message : Service temporarily unavailable
  • Cause : Maintenance du service ou problème temporaire
  • Action :
    • Affichez un message de maintenance
    • Réessayez après un délai
    • Surveillez la résolution

Bonnes Pratiques d’Implémentation

1. Vérifiez Toujours le Champ success

2. Gérez les Codes d’Erreur Spécifiques

3. Logique de Nouvelle Tentative Intelligente avec Backoff Exponentiel

4. Messages d’Erreur Conviviaux

5. Enregistrez les Request IDs

Patterns Avancés

Pattern Circuit Breaker

Évitez les défaillances en cascade en interrompant les requêtes lorsque le taux d’erreur est élevé :

Surveillance des erreurs

Suivez les patterns d’erreurs pour identifier les problèmes tôt :

Gestion de UNKNOWN_ERROR

Important : Ne remboursez jamais immédiatement lors d’un UNKNOWN_ERROR. Attendez toujours 24 heures pour la résolution.

Test des scénarios d’erreur

Utilisez le mode sandbox pour tester la gestion des erreurs :

Référence rapide

Valider tôt

Valider les entrées côté client avant les appels API

Réessayer intelligemment

Utiliser le backoff exponentiel pour les erreurs 5xx, jamais pour les 4xx

Journaliser le contexte

Toujours inclure requestId et contexte dans les logs

Retour utilisateur

Afficher des messages d’erreur clairs et actionnables aux utilisateurs

Erreurs du Paiement de factures

Cette section couvre les points de terminaison Paiement de factures sous https://api.oneclickdz.com/v3/bills. Ils ajoutent les codes ci-dessous aux erreurs de clé décrites plus haut, qui s’appliquent également ici.
Le Paiement de factures retourne la même enveloppe que tous les autres services — success, error.code, error.message, requestId — et chaque réponse porte également un en-tête X-Request-Id.

Erreurs synchrones

Elles sont retournées par la requête elle-même. Cette liste est complète. AUTH_UNAVAILABLE porte un en-tête Retry-After: 5 et rien n’a été démarré : la même requête peut être renvoyée. PARTNER_UNAVAILABLE et SERVICE_UNAVAILABLE n’en portent pas — appliquez votre propre backoff, et pour SERVICE_UNAVAILABLE récupérez avec GET /v3/bills/transactions/by-ref plutôt que de renvoyer.

Erreurs terminales

Elles n’apparaissent jamais dans un corps de réponse à elles seules. Elles apparaissent dans l’objet error d’une transaction, et uniquement lorsque son status est FAILED ou REFUNDED. Branchez sur code, jamais sur message.

Deux règles qui comptent plus que les autres

Une transaction étrangère est un 404, pas un 403. Une transaction qui appartient à un autre partenaire — ou à l’autre environnement — est signalée comme introuvable, par conception, afin que l’API ne confirme jamais l’existence de la transaction de quelqu’un d’autre. Traitez le 404 comme « vérifiez l’identifiant et la clé », pas comme « accès refusé ».
UNKNOWN n’est pas une erreur. C’est un statut qui signifie que le résultat n’a pas encore été confirmé, et il se résout de lui-même en SUCCESS ou REFUNDED. Tant qu’il dure : ne remboursez jamais votre client, ne renvoyez jamais le paiement, et n’affichez jamais « paiement échoué ». Continuez à interroger le statut.

Où aller ensuite

Aperçu du Paiement de factures

Comment tout le flux s’articule

Polling du statut

Gérer UNKNOWN et REFUNDED

Obtenir une transaction par ID

L’objet transaction et ses statuts

Tests en sandbox

Reproduire chaque erreur à la demande

Étapes suivantes

Endpoints principaux

Explorer tous les endpoints

Format de réponse

Comprendre les réponses API