Passer au contenu principal

Endpoint

Authentification

Utilisez votre clé secrète dans l’en-tête Authorization :
Sécurité de la clé secrète : La clé secrète doit rester confidentielle et ne doit jamais être exposée dans le frontend ou le code client. Elle doit uniquement être utilisée côté serveur.

Corps de la requête

Structure payment_method_data

Exemple de requête

Réponse

200 OK

Lorsque le décaissement a été créé avec succès, l’API renverra une réponse 200 OK. Le statut du décaissement est processing car le paiement est toujours en cours de traitement et n’a pas encore été exécuté.

200 OK : décaissement en revue

Certains décaissements en production sont retenus pour vérification avant tout envoi à l’opérateur. L’API répond alors 200 OK comme d’habitude : le status reste processing, mais le champ review est renseigné. Les fonds sont réservés sur votre portefeuille, aucun envoi n’a lieu tant que la revue est ouverte.
review vaut null pour un décaissement qui n’est pas en revue (cas général), et toujours en Sandbox.
Un décaissement en revue n’est jamais autorisé d’office : sans décision sous 48 h, il est annulé. Vous êtes prévenu à l’ouverture par le webhook disbursement.review_opened, puis à l’issue par disbursement.succeeded ou disbursement.failed. Une revue peut aussi s’ouvrir lorsque l’évaluation n’a pas pu être réalisée : le comportement est identique.

Statuts du décaissement

400 Mauvaise requête

401 Non autorisé

403 Décaissement refusé

Le décaissement est refusé avant toute écriture : aucun décaissement n’est créé, aucun fonds n’est réservé, aucun webhook n’est émis. Ne rejouez pas la même requête ; contactez le support si ce refus vous paraît injustifié. Une clé de production restreinte à une liste d’IP renvoie aussi un 403 (E_IP_NOT_ALLOWED) lorsque l’appel vient d’une adresse hors liste. Voir Gestion des erreurs.
Les décaissements sont traités de manière asynchrone. Utilisez les webhooks pour suivre leur statut en temps réel.