Skip to main content

Codes d’erreur

Format de réponse d’erreur

  • code est stable : basez votre logique dessus, pas sur message.
  • Les erreurs de validation des champs renvoient 400 avec code: "BAD_REQUEST", le premier message en message et la liste complète en details.
  • Quand une erreur n’a pas de code métier, code reprend le statut HTTP (BAD_REQUEST, NOT_FOUND, RATE_LIMIT_EXCEEDED…).
  • Les erreurs 5xx renvoient le code du statut HTTP (SERVICE_UNAVAILABLE, INTERNAL_ERROR…) et un message générique, sans détail technique.

Authentification

Création de paiement

Programme Partenaires SPAY

Liens de paiement

Système

Certaines routes renvoient encore 200 avec { "success": false, "message": "..." } quand une ressource est introuvable (GET /v1/payments/{id}/status, /details, /search). Testez toujours success.

Billing — SDK 1.3.0

Le SDK conserve le code renvoyé par l’API. Les six créations Billing supportent le rejeu persistant avec X-Idempotency-Key. Sans ce header, seules les références naturelles de checkout/import dédupliquent ces créations.
  • 400 INVALID_IDEMPOTENCY_KEY : clé vide ou longueur hors 1–128.
  • 409 IDEMPOTENCY_KEY_REUSED : même clé/portée/route avec un autre corps JSON.
  • 400 BAD_REQUEST : curseur invalide ou incompatible avec la portée/les filtres.
  • 409 INVOICE_PAYMENT_SETTLEMENT_PENDING : paiement réussi en cours d’imputation ; relire l’état et ne pas demander au client de payer encore.
Voir le contrat Billing.