Statuts de transaction

Branchez-vous sur la partition, pas sur la liste

La seule chose qui compte dans un statut est la case dans laquelle il tombe. Écrivez votre logique sur cette partition ; ne l'écrivez pas sur une énumération exhaustive, qui peut s'enrichir.

Terminaux — l'issue est acquise

cancelled est un échec financier, au même titre que failed. Si votre code teste status === "failed" pour conclure à un échec, il laissera passer les transactions annulées.

Non terminaux — ne concluez rien

created, initiated, pending, processing.

Ces quatre statuts ne signifient rien d'autre que « en cours ». Ils ne sont ni un succès partiel, ni un échec imminent. N'expédiez pas de marchandise dessus, et n'annulez pas de commande dessus.

Les transitions sont monotones

Un statut terminal ne bouge plus. Une transaction completed ne redeviendra jamais pending ; une transaction failed ne deviendra jamais completed.

Vous pouvez donc traiter la première notification terminale comme définitive, et ignorer sans risque une notification ultérieure qui porterait le même statut.

pending_approval

Ce statut existe et n'apparaît jamais pour un appelant porteur d'une clé d'API. Il concerne les pay-outs initiés depuis le tableau de bord par un utilisateur qui n'a pas le droit de les exécuter, et qui attendent l'approbation d'un tiers. Une clé d'API contourne ce circuit.

Où lire le statut

Le statut d'une transaction vous parvient par le webhook sortant. C'est le canal prévu pour ça, et le seul disponible avec une clé d'API.

Le reçu public porte bien un status, mais ses plafonds de requêtes en font un point d'affichage pour le payeur, pas une source de polling serveur.