Statuts et traitement asynchrone
L’API HTTP, les échanges avec PI et les opérations CBS ne se terminent pas au même instant. Distinguez la prise en charge, le résultat financier et la comptabilisation.
Conserver les identifiants
| Identifiant | Utilisation |
|---|---|
businessReference | Référence métier fournie par le canal |
endToEndId | Lien entre la recherche préalable et le transfert |
id de l’initiation | Recherche puis confirmation du payé |
transferId | Consultation du transfert et de sa chronologie |
batchId | Consultation du lot et de ses éléments |
Les identifiants ne sont pas interchangeables. Gardez-les avec le participant et le résultat de chaque appel. Suivez Location lorsqu’il est retourné.
Consulter le résultat
GET /api/v1/{participantCode}/transfers/{id} expose status, accountingStatus, returnStatus, cancellationStatus et lastError. Les valeurs autorisées figurent dans les énumérations de la référence. GET /transfers/{id}/timeline expose les événements de la saga.
Ne déduisez pas le succès d’un seul code HTTP. Un transfert peut avoir un résultat PI connu avec un traitement comptable encore à résoudre. Les états finaux absorbent les événements tardifs ; un callback dupliqué ne doit pas créer une seconde écriture.
Absence de réponse
Un état UNKNOWN signale une issue incertaine. Le cœur conserve les identifiants et les octets signés, puis suit son mécanisme de résolution. La recherche de statut ne doit pas être envoyée avant l’expiration du délai applicable. L’appel POST /transfers/{id}/status-inquiries peut donc être refusé s’il est prématuré.
Continuez la consultation du même transfert et transmettez ses références à l’exploitation. Recréer un ordre avec une autre référence peut créer un second effet financier.