Erreurs
Codes de statut, objet errors, et comment aiguiller votre code après un échec.
Wajub utilise les codes de statut HTTP conventionnels : 2xx signifie que la requête a réussi,
4xx que le problème vient de votre requête, 5xx qu'il vient de chez nous. Chaque erreur porte
la même enveloppe qu'un succès, plus un objet errors lorsqu'un champ est en cause.
Codes de statut
| Code | Signification |
|---|---|
200 | Succès. |
201 | Ressource créée. |
202 | Accepté. Le paiement ou le transfert est en cours chez le prestataire ; attendez le webhook. |
400 | Requête mal formée, ou version d'API non prise en charge. |
401 | Clé absente, inconnue, révoquée ou expirée. |
403 | Scope manquant, IP absente de la liste autorisée, clé privée utilisée depuis un navigateur, ou fonctionnalité réservée au live appelée avec une clé sandbox. |
404 | Ressource introuvable. |
405 | Mauvaise méthode HTTP pour ce chemin. |
406 | Une clé privée ou restreinte est requise et une clé publique a été envoyée. |
409 | La reference que vous avez fournie existe déjà sur un autre paiement. |
422 | Échec de la validation. Voir errors. |
429 | Limite de requêtes dépassée. |
500 | Erreur interne de notre côté. |
501 | L'endpoint existe mais n'est pas disponible dans cet environnement, aujourd'hui uniquement POST /identity/resolve en live. |
502 | Le prestataire de paiement a refusé ou n'a pas pu être joint. |
Forme d'une erreur
status est toujours le libellé HTTP, jamais la chaîne littérale error. message est une phrase
destinée à vos logs, pas à un switch.
Le message du 404 nomme la ressource : Payment Not Found, Customer Not Found,
Transfer Not Found, Invoice Not Found, Link Not Found, Beneficiary Not Found,
Account Not Found, et Resource Not Found pour tout le reste.
Erreurs de validation
Un 422 ajoute un objet errors qui associe chaque champ rejeté à sa liste de messages. Les champs
imbriqués utilisent la notation pointée, qui reprend le chemin dans le corps de votre requête.
errorsobjectfacultatif422 et les 409.messagestringfacultatifDeux échecs qui ne relèvent pas de la validation arrivent aussi en 422 sur le champ
idempotency_key : un en-tête Idempotency-Key mal formé, et une clé réutilisée avec un payload
différent. Voir Idempotence.
Chaque réponse a un identifiant de requête
X-Request-Id est défini sur chaque réponse, erreurs comprises. Journalisez-le à côté de votre
propre identifiant de corrélation, et indiquez-le quand vous ouvrez un ticket au support. Vous
pouvez aussi envoyer votre propre valeur, jusqu'à 64 caractères : elle vous est renvoyée au lieu
d'être générée.
curl https://api.wajub.com/payments/trx_01JXXXXXXXXXXXXX \
-H "Authorization: $WAJUB_API_KEY" \
-H "X-Request-Id: order-4172-attempt-1"Aiguiller votre code après un échec
Aiguillez sur le code de statut, jamais sur message. Trois familles méritent un traitement
différent : un 422 est un bug dans votre payload et une nouvelle tentative n'y changera rien ; un
429 est un problème de rythme et la réponse vous indique combien de temps attendre ; un 5xx ou
un 502 est transitoire et justifie un nombre limité de nouvelles tentatives.
const res = await fetch(url, { method: 'POST', headers, body });
if (res.status === 422) {
const { errors } = await res.json();
return showFieldErrors(errors);
}
if (res.status === 429) {
const wait = Number(res.headers.get('retry-after') ?? 1);
return retryAfter(wait * 1000);
}
if (!res.ok) {
throw new Error(`Wajub ${res.status} ${res.headers.get('x-request-id')}`);
}Le SDK PHP transforme chaque code de statut en exception dédiée : un bloc catch suffit donc à
séparer les trois familles.
| Statut | Exception | Propriété supplémentaire |
|---|---|---|
401 | AuthenticationException | |
403 | PermissionException | |
404 | NotFoundException | |
400, 422 | InvalidRequestException | errors |
429 | RateLimitException | retryAfter |
| tout autre code | WajubError | httpStatus, raw |
| réseau | ApiConnectionException |
Chacune expose errorCode, httpStatus, errors et raw, le corps de la réponse décodé.
Les nouvelles tentatives sont déjà intégrées
Le SDK relance lui-même deux fois les 429, 500, 502, 503 et 504, en respectant
Retry-After et, à défaut, avec une attente progressive exponentielle et une part d'aléa
(jitter). Quand une exception vous parvient, l'appel a déjà eu ses chances.
Relisez la requête échouée
Toute requête, y compris celles qui ont échoué, reste visible dans Konsole → API Logs : le corps que vous avez envoyé, la réponse exacte et le prestataire concerné.