Skip to main content
Toutes les erreurs du Guichet ont la même forme :
Branchez votre logique sur error.code, jamais sur error.message. Les codes sont stables et font partie du contrat ; les messages peuvent être reformulés ou traduits à tout moment.
requestId est également renvoyé dans l’en-tête x-request-id de chaque réponse, succès compris. Journalisez-le de votre côté et citez-le dans vos demandes de support : il relie l’appel, son traitement et la notification associée.
Vous pouvez fournir votre propre x-request-id en requête. Il est repris tel quel dans la réponse et dans nos journaux — pratique pour corréler avec votre propre identifiant de trace.

Erreurs d’appel

Les quatre causes renvoient le même code, volontairement : les distinguer permettrait de tester des clés jusqu’à trouver celles qui existent.
Un champ non reconnu dans le corps provoque un VALIDATION_ERROR, il n’est pas ignoré. C’est volontaire : une faute de frappe sur amount doit échouer bruyamment plutôt que de passer un montant par défaut.
Rappel : c’est available (balance − reserved) qui compte, pas balance. Voir Portefeuille.
Sur ces codes, l’issue est inconnue : l’opération a peut-être été enregistrée avant la coupure. Réessayez impérativement avec la même Idempotency-Key — une nouvelle clé en créerait une seconde.

Erreurs d’opération

Celles-ci n’apparaissent pas en réponse HTTP mais dans operation.failure.code, et dans les notifications cashin.failed / cashout.failed. L’opération a été acceptée, c’est son exécution qui a échoué.
OPERATOR_REFUSED est volontairement vague : quand un opérateur ne fournit pas de motif exploitable, nous préférons rester général plutôt que de risquer un diagnostic faux. Conseiller à tort « rechargez votre compte » à un client dont le solde est suffisant est pire que de rester imprécis.

Faut-il réessayer ? Récapitulatif