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 :
SUCCESSFAILED
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
referenceDOIT correspondre à l’ordre interrogéreasonCodeetreasonMessagesont :- **OBLIGATOIRES si **
status = FAILED
- **OBLIGATOIRES si **
processed_atest la date de traitement bancaire