Skip to main content
GET
Obtenir une Transaction par Référence

Vue d’ensemble

Retrouve une transaction à partir du ref que vous avez envoyé au démarrage de la découverte. Elle retourne exactement le même objet que Obtenir une Transaction par ID. C’est le chemin de récupération. Lorsqu’une réponse est perdue à cause d’un timeout, d’un plantage ou d’un redéploiement, recherchez le ref — ne renvoyez jamais l’écriture.
Un ref est unique par partenaire, pas globalement. Si vous réutilisez la même chaîne ref pour deux partenaires différents, transmettez également partner afin que la recherche soit sans ambiguïté.

Paramètres de requête

string
requis
La référence que vous avez fournie lors de la création de la découverte. 100 caractères maximum.
string
Facultatif. Une valeur parmi ADE, SONELGAZ, SEAAL, AADL, Algérie Télécom. Restreint la recherche à ce facturier.

Réponse

Identique à Obtenir une Transaction par ID — l’objet transaction complet, encapsulé dans l’enveloppe standard. Consultez cette page pour la référence champ par champ et pour savoir quels champs apparaissent dans quel statut.
boolean
requis
true lorsqu’une transaction a été trouvée.
object
requis
object
requis
string
requis
Identifiant de corrélation, également envoyé dans l’en-tête de réponse X-Request-Id.

Exemples

Réponse de succès

Réponses d’erreur

Le ref était manquant, trop long, ou partner n’était pas une valeur connue.
Que faire : envoyez ref en paramètre de requête, encodé pour URL, avec 100 caractères au maximum.
La clé était absente ou a été rejetée.
Que faire : vérifiez la clé avec Valider la Clé API.
Aucune transaction portant ce ref n’appartient à votre compte dans cet environnement.
Que faire : après une écriture échouée, un 404 ici est la preuve que la requête n’est jamais arrivée — vous pouvez l’envoyer à nouveau avec le même ref en toute sécurité. Vérifiez aussi que vous utilisez la clé de l’environnement dans lequel la transaction a été créée.
Nous n’avons pas pu vérifier votre clé à temps, ou l’API est en maintenance planifiée.
Que faire : respectez l’en-tête Retry-After (5 secondes) et réessayez. Une recherche peut toujours être répétée sans risque.

Récupérer après une réponse perdue

Le schéma est le même pour une découverte et pour un paiement : si l’écriture a échoué d’une manière que vous ne pouvez pas expliquer, demandez à quoi le ref correspond avant de renvoyer quoi que ce soit.
Un 404 renvoyé par cet endpoint n’a de sens que si vous interrogez un ref que vous avez réellement envoyé. Ne vous en servez jamais pour conclure qu’un paiement n’a pas eu lieu alors que c’est le ref de la découverte que vous avez recherché — un paiement vit sur la même transaction que sa découverte, sous le ref de la découverte.

Bonnes pratiques

Rechercher, Ne Pas Renvoyer

Chaque timeout et chaque DUPLICATED_REF trouve sa réponse ici, pas dans une seconde écriture.

Transmettre le Partenaire

Cela ne coûte rien et lève toute ambiguïté lorsque la même chaîne ref existe pour deux facturiers.

Stocker le Ref avec Votre Commande

Un ref que vous ne pouvez pas reconstituer est une transaction que vous ne pouvez pas récupérer.

Interroger par ID une Fois Obtenu

Utilisez cet endpoint pour récupérer, puis interrogez par transactionId — un paramètre de moins à se tromper.

Endpoints associés

Obtenir une Transaction par ID

L’objet transaction complet

Lister les Transactions

Filtrez et paginez l’historique

Découvrir les Factures

Là où un ref est créé

Interrogation du Statut

Un système d’interrogation de qualité production