Accepter le paiement en ligne en Algérie (2026) : CIB, Edahabia, SlickPay et OneClick

Dernière mise à jour : octobre 2026. Les prestataires de paiement changent leurs conditions, leurs frais et leurs exigences d'inscription : vérifiez leur documentation à jour avant de vous engager.

La réponse courte

En Algérie, on paie en ligne avec deux cartes domestiques : la carte CIB (émise par les banques, sur le réseau interbancaire SATIM) et la carte Edahabia (émise par Algérie Poste). Pour les accepter, on passe par :

1. Une passerelle de paiement comme SlickPay : CIB et Edahabia sur une page de paiement hébergée, avec une seule intégration.
2. OneClick : une autre solution locale, proposée par Odigix à côté de SlickPay.
3. Un contrat e-paiement direct avec votre banque sur le réseau SATIM : possible, mais avec plus de démarches.

Beaucoup de clients préfèrent encore le paiement à la livraison ; il se gère via votre société de livraison, pas via une passerelle. Les passerelles internationales comme Stripe et PayPal ne fonctionnent pas avec les cartes algériennes.

Les solutions comparées

Solution	Ce qu'utilise le client	Comment l'intégrer	Point d'attention
SlickPay	Carte CIB ou Edahabia	Créer une facture, rediriger le client vers la page hébergée de SlickPay, confirmer le résultat auprès de SlickPay	Le retour du client sur votre site n'est pas une preuve de paiement
OneClick	Le parcours de paiement OneClick	Son API, derrière la même interface que votre autre prestataire	Parcours et délais différents de SlickPay : testez les deux de bout en bout
SATIM en direct	Carte CIB	Un contrat e-paiement avec votre banque, puis l'intégration technique SATIM	Démarches bancaires et mise en place plus longue
Paiement à la livraison	Espèces remises au livreur	L'API de votre société de livraison, plus le rapprochement de ce qu'elle encaisse et reverse	Livré ne veut pas dire payé : suivez les reversements à part

J'ai livré SlickPay et OneClick en production sur Odigix. Je n'ai pas encore livré d'intégration SATIM directe.

Une intégration correcte, concrètement

Brancher un bouton de paiement, c'est la partie facile. Voici les règles qui évitent de perdre de l'argent :

1. Ne passez jamais une commande en « payée » parce que le client est revenu. Les clients ferment des onglets, une redirection se falsifie. Confirmez le paiement auprès du prestataire — notification signée, vérification du statut via son API, ou les deux — avant de faire avancer la commande.
2. Rendez le traitement idempotent. Les notifications sont renvoyées, les clients double-cliquent. Identifiez chaque paiement par prestataire et référence, et ignorez celui que vous avez déjà enregistré.
3. Enregistrez le paiement avant de toucher à la commande. Chaque paiement reçu va d'abord dans un journal, puis la commande est mise à jour dans la même transaction.
4. Ne devinez pas. Un paiement qui ne correspond pas à exactement une commande va à un humain. Les prix fixes rendent les montants identiques fréquents.
5. N'attendez pas indéfiniment. Certaines confirmations prennent des minutes, d'autres n'arrivent jamais. Vérifiez le statut auprès du prestataire avant l'expiration d'une commande en attente.
6. Rendez aussi idempotent tout ce qui suit le paiement. Si l'exécution appelle un fournisseur tiers, un job relancé ne doit pas acheter deux fois : chaque achat porte sa propre clé d'idempotence.
7. Testez chaque moyen avec de petits paiements réels avant le lancement.
8. Montrez le statut au client. Une page « paiement reçu → en cours → terminé » évite la plupart des messages « j'ai payé, où est ma commande ? ». Sur Odigix, cela a réduit les demandes au support d'environ 40 %.

La forme que ça prend en Laravel

// Called from the provider's notification AND from the customer's return URL.
// Both paths end here; neither one is trusted on its own.
public function confirm(PaymentProvider $provider, string $reference): void
{
    $status = $provider->fetchStatus($reference); // ask the provider, don't trust the request

    if (! $status->isPaid()) {
        return;
    }

    // The reference is the one you sent when creating the payment.
    $order = Order::where('payment_reference', $reference)->firstOrFail();

    DB::transaction(function () use ($provider, $status, $order) {
        // Unique index on (provider, reference): a second call is a no-op.
        $entry = LedgerEntry::firstOrCreate(
            ['provider' => $provider->name(), 'reference' => $status->reference],
            ['order_id' => $order->id, 'amount' => $status->amount, 'currency' => 'DZD'],
        );

        if ($entry->wasRecentlyCreated) {
            $order->markPaid(); // then queue fulfilment
        }
    });
}

PaymentProvider est votre propre interface ; SlickPay et OneClick ont chacun une petite classe qui l'implémente. Lisez les noms de champs et les règles de signature dans la documentation à jour de chaque prestataire.

Questions fréquentes

Puis-je utiliser Stripe ou PayPal pour mes clients algériens ? Pas pour les cartes locales. CIB et Edahabia sont des cartes domestiques, que Stripe et PayPal ne traitent pas.

Faut-il une société pour accepter la carte ? Chaque prestataire a ses propres exigences selon votre statut juridique et vos documents. Renseignez-vous avant de développer, pas après.

Faut-il garder le paiement à la livraison ? Dans la plupart des boutiques qui expédient des produits physiques, oui : beaucoup de clients ne commandent pas sans. Proposez la carte à côté, et suivez les commandes à la livraison à part jusqu'au reversement du livreur.

J'ai déjà un site, faut-il tout refaire ? En général non. Le paiement s'ajoute à un site existant ; le travail porte surtout sur les commandes : statuts, journal et rapprochement.

---

J'intègre et je répare les paiements pour les boutiques algériennes et pour les entreprises étrangères qui vendent en Algérie : voir l'intégration de paiement en ligne en Algérie, ou l'étude de cas Odigix pour ce que ça donne à plus de 30 000 utilisateurs inscrits.