Si vous développez une application ou un site e-commerce en Algérie, vous devez intégrer CIB (Carte Interbancaire) et Edahabia (Algérie Poste). C'est obligatoire pour les paiements en ligne. Et c'est l'intégration la plus mal documentée de tout l'écosystème tech algérien. Ce guide est ce que nous aurions aimé avoir quand nous avons fait notre première intégration SATIM en 2020.
CIB vs Edahabia — quelle différence ?
CIB (Carte Interbancaire) est la carte bancaire classique émise par les banques algériennes (BNA, BEA, BDL, CPA, etc.). Gérée par le réseau SATIM. Environ 8 millions de cartes en circulation. Utilisée principalement par les salariés et les fonctionnaires.
Edahabia est la carte prépayée d'Algérie Poste. Gérée aussi par SATIM mais via un réseau séparé. Environ 20 millions de cartes — la carte la plus répandue en Algérie. Si vous ne supportez pas Edahabia, vous excluez 70% de vos clients potentiels.
Les deux passent par SATIM (Société d'Automatisation des Transactions Interbancaires et de Monétique). C'est le point d'entrée unique. Vous n'intégrez pas CIB et Edahabia séparément — vous intégrez la passerelle SATIM qui gère les deux.
«Si vous ne supportez pas Edahabia, vous excluez 70% de vos clients potentiels en Algérie.»
Architecture d'intégration — le flux complet
Le flux standard SATIM est un redirect flow en 5 étapes :
1. Votre app envoie une requête POST à l'API SATIM avec : montant, devise (DZD), URL de retour, identifiant commande. 2. SATIM redirige le client vers une page de paiement hébergée par SATIM (pas chez vous). 3. Le client entre ses informations carte. 4. SATIM traite le paiement et redirige vers votre URL de retour avec un code de résultat. 5. Votre backend vérifie le code, confirme la commande, et affiche un reçu.
Point critique : ne faites JAMAIS confiance à la redirection seule. Utilisez toujours le callback serveur-à-serveur (S2S) pour confirmer le paiement côté backend. Des clients ferment leur navigateur avant la redirection — sans le callback S2S, vous pensez que le paiement a échoué alors qu'il a réussi.
Les 5 pièges que la documentation ne mentionne pas
Piège 1 : Le sandbox SATIM est souvent hors service. L'environnement de test tombe régulièrement. Gardez une journée de marge dans votre planning pour les périodes où le sandbox ne répond pas. Testez le week-end — le sandbox est plus stable.
Piège 2 : Les codes d'erreur ne sont pas tous documentés. Vous recevrez des codes qui n'apparaissent dans aucune documentation. Loggez tout. Envoyez les codes inconnus au support SATIM par email — ils répondent en 2 à 5 jours ouvrés.
Piège 3 : Le callback S2S arrive parfois AVANT la redirection client. Votre backend doit gérer cette race condition. Utilisez un état « paiement en attente de confirmation » dans votre base de données, pas un simple « payé / non payé ».
Piège 4 : Edahabia et CIB ont des limites de transaction différentes. CIB : 200 000 DA par transaction (variable selon la banque). Edahabia : 100 000 DA par transaction standard. Si votre panier dépasse ces montants, le paiement sera refusé sans message d'erreur clair.
Piège 5 : Le certificat SSL de votre domaine doit être parfait. SATIM vérifie le certificat de votre URL de retour. Un certificat auto-signé, expiré, ou mal configuré = paiement qui aboutit mais callback qui n'arrive jamais. Utilisez Let's Encrypt et vérifiez la chaîne de certification complète.
«Ne faites JAMAIS confiance à la redirection seule. Le callback serveur-à-serveur est obligatoire.»
Stack technique recommandée
Après 20+ intégrations SATIM livrées, voici notre stack recommandée :
Backend : Node.js (NestJS) ou Python (Django/FastAPI). Les deux ont des bibliothèques HTTP robustes pour gérer les appels SATIM. Évitez PHP pour les nouvelles intégrations — la gestion des callbacks asynchrones est plus fragile.
Base de données : PostgreSQL avec une table dédiée `payment_transactions` contenant : ID commande, montant, statut (pending/success/failed/callback_received), timestamp, code SATIM retourné. Indexez sur le statut — vous allez beaucoup querier les pending.
File d'attente : Redis ou Bull pour les jobs de vérification différée. Si le callback S2S n'arrive pas en 5 minutes, lancez un job de vérification manuelle via l'API SATIM.
Monitoring : Logguez chaque requête SATIM et chaque callback avec timestamps. Quand un client dit « j'ai payé mais ma commande n'est pas confirmée », vous avez besoin de ces logs. C'est le premier outil de debug.
Délai et coût réels d'intégration
Si vous avez déjà un backend avec une base de données : 3 à 6 semaines de développement, 300K–800K DA. La majorité du temps est passée à gérer les edge cases (timeouts, doublons, race conditions) et à attendre les réponses du support SATIM.
Si vous partez de zéro (nouveau site e-commerce) : 8 à 12 semaines incluant le backend, 1.5–3M DA. L'intégration SATIM elle-même est ~30% du travail. Le reste est le panier, les commandes, les emails transactionnels, le dashboard admin.
Coût SATIM : commission de 1.5 à 2.5% par transaction (négociable selon le volume). Pas de frais mensuels fixes. Compte marchand à ouvrir auprès de votre banque + contrat SATIM (compter 2 à 4 semaines pour les formalités administratives).