Skip to main content

​
Frais multi-factures - 23 septembre 2026

Changement de tarification pour billIds. Les frais d’une commande multi-factures sont désormais la somme des fee annoncés pour chaque facture sélectionnée dans bills[] — comme si ces factures étaient payées une par une. Cela remplace les frais uniques sur le total cumulé annoncés ci-dessous. Un billIds de plus d’un identifiant n’est accepté que pour SEAAL.

​
Paiement multi-factures - Septembre 2026

Nouveau paramètre facultatif, aucun changement majeur. billId fonctionne exactement comme aujourd’hui. billIds en est une alternative, jamais un remplacement.
POST /v3/bills/pay accepte désormais billIds — jusqu’à 50 factures issues de la même transaction READY, réglées en une seule commande chez le facturier, un seul paiement par carte et des frais de service uniques sur le total cumulé.

​
🟢 Nouveautés

billId ou billIds — exactement l'un des deux

  • billId — une facture, une chaîne d’au plus 100 caractères. Inchangé.
  • billIds — de 1 à 50 identifiants, chacun d’au plus 100 caractères, sans aucun doublon.
Les deux ensemble, ou aucun des deux, répond 400 ERR_VALIDATION — « Provide exactly one of billId or billIds ». Un identifiant répété répond « billIds must not repeat the same bill id ».

Des frais uniques, sur le total cumulé

Les frais sont calculés une seule fois, sur la somme des factures sélectionnées — jamais comme la somme des frais par facture annoncés dans bills[]. Sous la règle SEAAL de 0,5 % avec son minimum de 30 DZD et son maximum de 60 DZD, trois trimestres de 327,00, 480,00 et 767,81 DZD totalisent 1574,81 DZD : 0,5 % de ce total font 7,87, sous le plancher, la commande porte donc des frais uniques de 30,00 DZD et un total de 1604,81 DZD. Payées une par une, ces trois mêmes factures atteindraient le plancher trois fois — 90,00 DZD. Une commande d’eau de cinq factures coûte 30,00 DZD de frais au lieu de 150,00 DZD.La transaction présente la commande comme une facture sélectionnée agrégée : amount est la somme des factures choisies, fee les frais uniques sur cette somme. Le sandbox fait la même arithmétique que la production : les montants que vous y validez sont ceux que la production débitera.

Une liste n'est jamais réglée à moitié

Chaque identifiant envoyé doit toujours figurer sur cette transaction READY ; un seul identifiant périmé ou inconnu fait refuser l’appel entier, et rien n’est payé. Les garde-fous « déjà payée » et « paiement en cours » s’appliquent ensuite à chaque identifiant de la liste, et ils reconnaissent une facture réglée plus tôt comme une ligne d’une commande plus large — un trimestre payé au sein d’un groupe répond donc toujours 409 BILL_ALREADY_PAID pris isolément.

Là où cela compte : SEAAL

Le regroupement n’a de sens que là où le portail du facturier règle lui-même plusieurs documents en une seule transaction. Aujourd’hui, c’est SEAAL : l’eau est facturée au trimestre et un compte doit couramment de nombreux trimestres impayés à la fois — 25 sur un compte vérifié en production. Tous les autres facturiers ne renvoient de toute façon qu’une seule facture : billIds avec une seule entrée équivaut donc simplement à billId.Le minimum de commande SEAAL de 200 DA porte sur le total sélectionné, pas sur chaque ligne : le regroupement ne fait que faciliter son franchissement.

Paiement des factures

L’exemple détaillé

Payer une facture

La référence de l’endpoint

​
Paiement de factures SEAAL - Septembre 2026

Nouveau facturier, aucun changement majeur. SEAAL est en production sur les endpoints /v3/bills que vous appelez déjà. Rien de ce que vous envoyez aujourd’hui ne change.
SEAAL — le distributeur d’eau d’Alger et de Tipaza — est intégré et règle de vrais paiements. Il rapporte ACTIVE dans la carte de disponibilité, aux côtés d’ADE, SONELGAZ, AADL et Algérie Télécom. Les versions précédentes décrivaient SEAAL comme inaccessible et définitivement UNAVAILABLE : ce n’est plus le cas, lisez donc la carte de disponibilité au lieu de masquer le partenaire sans condition.

​
🟢 Nouveautés

Un identifiant de compte imbriqué

SEAAL est le premier partenaire adressé par une paire plutôt que par une clé unique, car le facturier authentifie les deux moitiés ensemble :
  • code_client — de 2 à 6 caractères alphanumériques
  • code_contrat — de 2 à 10 chiffres
Les deux figurent sur la facture d’eau papier du client et les deux sont obligatoires ; il n’existe aucun raccourci à clé unique. La transaction relit l’identifiant à plat, dans account.codeClient.

Plusieurs trimestres, une commande, des frais uniques

L’eau est facturée au trimestre et un compte peut porter de nombreuses factures impayées à la fois — un compte vérifié à la mise en production en devait 45. En sélectionner plusieurs produit une seule commande et un seul paiement par carte, et les frais sont prélevés une seule fois sur le total, jamais additionnés facture par facture. La règle de frais SEAAL est de 0,5 % du montant, bornée à un minimum de 30 DZD et un maximum de 60 DZD — la même règle que les autres facturiers, et sur une facture d’eau elle tombe toujours sur le plancher de 30 DZD.
La sélection multi-factures est arrivée d’abord dans le tunnel de paiement grand public OneClickDz. Elle est désormais sur cette API aussi : POST /v3/bills/pay accepte un tableau billIds de 50 factures au maximum — voir l’entrée ci-dessus.

Cinq scénarios sandbox

Chaque scénario est déterminé par le code_client ; le code_contrat doit tout de même être présent et bien formé.

Règles du facturier à prendre en compte

  • Un minimum de 200 DA. SEAAL refuse toute commande dont le total sélectionné est inférieur à 200 DA.
  • Blocage temporaire du compte. Après plusieurs tentatives échouées, le facturier bloque ce compte pendant quelques heures et indique la durée. C’est propre au compte — ce n’est ni une panne ni un mauvais identifiant — et le seul remède est d’attendre.
  • « Rien à payer » est un résultat, pas une faute. Un compte entièrement soldé répond « Vous êtes à jour, merci pour votre fidélité. » et remonte en BILL_ALREADY_PAID. Le rapprochement se fait par absence : une facture payée cesse simplement d’être listée.

Partenaires et comptes

Les règles d’identifiant

Aperçu du Paiement de factures

Tout le parcours

​
API Paiement de factures - Août 2026

Nouveau produit, aucun changement majeur. Le Paiement de factures est une nouvelle section de l’API v3, sur l’URL de base et la clé que vous utilisez déjà. Rien d’autre n’a changé dans l’API Flexy.
Payez les factures algériennes de services publics et de télécommunications pour le compte de vos clients — ADE, SONELGAZ, SEAAL, AADL et Algérie Télécom.

​
🟢 Nouveautés

L'URL de base que vous utilisez déjà

Même hôte, même en-tête X-Access-Token, même clé — aucune nouvelle URL de base et aucun nouveau mécanisme d’authentification. Votre clé sandbox sélectionne l’environnement sandbox, exactement comme partout ailleurs en v3.

Découvrir, payer, interroger, télécharger

  • POST /v3/bills/discover — demander à un facturier ce qu’un compte doit
  • POST /v3/bills/pay — payer l’une des factures découvertes
  • GET /v3/bills/transactions/{transactionId} — la suivre jusqu’à un état final
  • GET /v3/bills/transactions/{transactionId}/receipt — télécharger la preuve de paiement
Les deux endpoints d’écriture sont asynchrones : un 200 est un accusé de réception, et le résultat apparaît dans le status de la transaction.

Un sandbox déterministe

Chaque clé est liée à un seul environnement. En sandbox, l’identifiant de compte que vous envoyez détermine le résultat : un refus, un remboursement et un paiement non confirmé peuvent donc tous être reproduits à la demande.

Aperçu du Paiement de factures

Commencez ici

Référence API

Les sept endpoints

​
v3.0.0 - Octobre 2025

Changements majeurs : v3 est une refonte complète. Consultez le Guide de migration pour les instructions de mise à niveau.

​
🔴 Ce que vous devez modifier

1. URL de base modifiée

2. En-tête d'authentification modifié

3. Structure de réponse modifiée

Toutes les réponses sont maintenant encapsulées dans un format standardisé :Avant (v2) :
Après (v3) :
Accédez aux données via response.data au lieu d’y accéder directement depuis la réponse.

4. Chemins des endpoints modifiés

5. Gestion des erreurs modifiée

Avant (v2) :
Après (v3) :
Vérifiez toujours le booléen response.success en premier.

​
✨ Nouveautés

  • API Cartes cadeaux : Système complet de livraison de cartes cadeaux avec plus de 100 produits
  • Clés sandbox : Clés API séparées pour les tests sans impact sur le solde de production
  • Liste blanche d’IP : Sécurité renforcée via les paramètres du tableau de bord
  • Suivi des requêtes : Chaque requête inclut un requestId unique pour le débogage
  • Meilleures erreurs : Codes d’erreur structurés avec des messages exploitables
  • Validation du schéma : La validation automatique empêche les requêtes invalides

​
📅 Date limite de migration

v2 sera dépréciée le 30 octobre 2026. Migrez avant cette date pour éviter toute interruption de service.

​
🔗 Ressources

​
v2.x - Avant octobre 2025

​
Août 2025

  • Ajout du mode sandbox pour les tests
  • Amélioration de la gestion des erreurs et des journaux

​
Juillet 2023

  • Implémentation initiale du sandbox
  • Ajout du support pour la recharge internet ADSL

​
Antérieur

  • Recharges mobiles pour Mobilis, Djezzy, Ooredoo
  • Suivi de base des transactions
  • Gestion du solde du compte

​
Besoin d’aide ?

Contacter le support

Des questions sur la migration ? Nous sommes là pour vous aider.