Skip to main content

Objectif

Cette section définit les **règles de gestion des erreurs **applicables à tous les échanges entre la Banque et le Connecteur Bancaire. Elle vise à garantir :
  • une interprétation univoque des erreurs,
  • une gestion cohérente des rejets,
  • une traçabilité complète pour les équipes techniques et support.

Principes fondamentaux

  • Toute erreur doit être déterministe
  • Toute erreur doit être tracable
  • Une erreur de sécurité entraîne un **rejet immédiat**
  • Une erreur finale est **non rejouable**, sauf indication contraire

Catégorisation des erreurs

Typologie des erreurs supportées

Catégories

Les erreurs sont classées en trois catégories :

1. Erreurs de sécurité (`SECURITY`)

Erreurs liées à :
  • l’authentification,
  • la signature,
  • l’anti-rejeu,
  • l’intégrité des messages.
Ces erreurs entraînent un **rejet immédiat**.

2. Erreurs techniques (`TECHNICAL`)

Erreurs liées à :
  • indisponibilité système,
  • timeout,
  • erreurs réseau,
  • erreurs de format non métier.
Ces erreurs peuvent être **rejouées**.

3. Erreurs métier (`BUSINESS`)

Erreurs liées à :
  • règles bancaires,
  • solde insuffisant,
  • compte invalide,
  • devise non supportée.
Ces erreurs sont **définitives**.

4.1.1 Structure JSON d’une erreur

Description champ par champ

Table des codes d’erreur standardisés

A. Erreurs de sécurité (SECURITY)

B. Erreurs techniques (TECHNICAL)

C. Erreurs métier (BUSINESS)

Règles
  • Les erreurs métier sont **définitives**
  • Aucun retry automatique n’est autorisé
  • Le statut final est `FAILED`

5.6 Correspondance HTTP / Erreurs

Correspondance entre codes HTTP et erreurs métier

5.7 Traçabilité des erreurs

Suivi et analyse des erreurs. Les informations doivent permettre :
  • l’identification rapide de la cause,
  • la reconstitution du flux,
  • la résolution des incidents.
Les erreurs doivent être conservées conformément aux exigences réglementaires et contractuelles.