Vue d’ensemble
La découverte est la moitié lecture du Paiement de Factures : vous demandez à un facturier ce qu’un compte doit actuellement, et vous recevez en retour une liste de factures payables. Rien n’est débité, et rien n’est engagé. Cela se passe en deux temps.POST /v3/bills/discover accepte la requête et vous donne un transactionId. Les factures elles-mêmes arrivent sur cette transaction un instant plus tard, quand son status devient READY.
Construire la requête
Trois champs, tous obligatoires.Choisir un ref
ref est ce qui rend une découverte sûre à réessayer. Si la réponse est perdue, vous consultez le ref au lieu d’envoyer une seconde découverte — un ref que vous ne pouvez pas reconstruire à partir de vos propres données est donc une transaction que vous ne pouvez pas récupérer.
Une recette qui fonctionne : un préfixe fixe, votre propre identifiant de commande ou de facture, et rien d’autre.
Un
ref est unique par facturier, pas globalement. disc-inv-2026-0042 pour ADE et la même chaîne pour SONELGAZ sont deux références différentes. Passer partner lors d’une consultation lève toute ambiguïté.Envoyer la découverte
Interroger jusqu’à READY
Lisez la transaction jusqu’à ce que son status quitte PENDING. Une découverte aboutit normalement en quelques secondes.
Lire bills[]
Une transaction READY porte les factures payables à cet instant.
Montrez
amount + fee au client. Cette somme est ce qui sera débité, et elle est renvoyée comme total sur la transaction une fois qu’une facture est sélectionnée.
bills[] n’est présent que tant que status vaut READY. Une fois qu’un paiement démarre, la transaction porte selectedBill à la place. Lisez les factures tant que vous les avez.Quand bills[] est vide
Un tableau vide est un résultat normal et réussi — pas une erreur.
- le compte ne doit rien, ou
- tout ce que le compte doit est sous le plancher de découverte de 200 DZD.
Récupérer une réponse perdue
Si la requête de découverte échoue d’une manière que vous ne pouvez pas expliquer — un timeout, un crash, un redéploiement — demandez ce qu’est devenu leref. N’envoyez jamais une seconde découverte.
403 DUPLICATED_REF. Cette erreur signifie que la découverte existe déjà ; ce n’est jamais une raison de réessayer avec un ref différent, ce qui lancerait une seconde découverte pour le même compte.
Les erreurs que vous rencontrerez
Une découverte
FAILED porte sa raison dans error.code : INVALID_ACCOUNT, PARTNER_UNAVAILABLE, BILL_ALREADY_PAID ou PAYMENT_DECLINED.
Chaque code, avec des exemples de corps →
Bonnes pratiques
Dérivez le ref
Construisez-le à partir de votre propre identifiant de commande afin de pouvoir toujours le reconstruire après un échec.
Interrogez, ne renvoyez jamais
Une découverte lente n’est pas une découverte perdue. Lisez la transaction au lieu d’envoyer une autre requête.
Ne mettez rien en cache au sujet des factures
Une découverte est un instantané. Si le client attend, relancez une découverte plutôt que de payer sur des chiffres périmés.
Dites payable, pas dû
Un
bills[] vide signifie que rien n’est payable. Cela ne signifie pas que le compte ne doit rien.Étape suivante
Étape 3 : Paiement des factures
Choisissez une facture, confirmez le total, et soumettez le paiement en toute sécurité
Pages liées
Découvrir les factures
La référence de l’endpoint
Obtenir une transaction par ID
L’objet transaction en entier
Obtenir une transaction par référence
Le chemin de récupération
Partenaires et comptes
Les règles d’identifiant par facturier

