Skip to main content
Ce mode est utilisé exclusivement lorsque la Banque est techniquement incapable d’émettre des appels sortants (Callback Push).

A. Principe général

  • Le Connecteur initie les requêtes
  • La Banque reste source de vérité du statut
  • Le Polling Inverse :
    • NE REMPLACE PAS le Callback Push
    • N’EST UTILISÉ QUE comme mécanisme de secours
  • Le Polling Inverse s’applique **uniquement aux ordres en statut **PENDING ou push async

B. Endpoint de requête de statut (côté Banque)

Endpoint

Authentification et sécurité

La requête DOIT être protégée par :
  • mTLS obligatoire
  • Authentification applicative obligatoire :
    • OAuth 2.0 (Bearer ou DPoP)
    • ou API Key selon le contrat

En-têtes requis

Paramètre de chemin

Exemple

C. Comportement attendu du Connecteur (client)

Fréquence de polling

Le Connecteur DOIT implémenter une stratégie de polling adaptative :
  • fréquence initiale courte (ex : 30s – 1min)
  • intervalle progressif (backoff exponentiel)
  • plafond maximal configurable (ex : 10–15 minutes)

Règles de sécurité

  • Chaque requête DOIT être signée via X-Signature
  • La signature DOIT couvrir :
    • la méthode HTTP
    • l’URI
    • les paramètres
    • les en-têtes critiques

Condition d’arrêt (CRITIQUE)

Le polling inverse s’arrête uniquement lorsque la Banque retourne un statut final.
Statuts finaux :
  • SUCCESS
  • FAILED

D. Format JSON de la réponse (côté Banque)

La Banque retourne une enveloppe JSON standard contenant un seul objet de mise à jour de statut.

Réponse – 200 OK

Règles associées

  • reference DOIT correspondre à l’ordre interrogé
  • reasonCode et reasonMessage sont :
    • **OBLIGATOIRES si **status = FAILED
  • processed_at est la date de traitement bancaire

E. Codes HTTP et comportements

F. Exemple de requête – Polling inverse (Mintlify)

cURL