How to accept online payments in Algeria (2026): CIB, Edahabia, SlickPay and OneClick

Last reviewed: October 2026. Payment providers change their terms, fees and onboarding requirements; check each provider's current documentation before you commit.

The short answer

Algerian customers pay online with two domestic cards: CIB (issued by banks, on the SATIM interbank network) and Edahabia (issued by Algérie Poste). To accept them you go through:

1. A payment gateway such as SlickPay — CIB and Edahabia on a hosted payment page, with one integration.
2. OneClick — another local option, which Odigix offers next to SlickPay.
3. A direct e-payment contract with your bank on the SATIM network — possible, but with more paperwork.

Many customers still prefer cash on delivery; that's handled through your courier, not a payment gateway. International gateways like Stripe and PayPal don't work with Algerian cards.

The options side by side

Option	What the customer uses	How you integrate it	Watch out for
SlickPay	CIB or Edahabia card	Create an invoice, redirect the customer to SlickPay's hosted page, confirm the result with SlickPay	The customer's return to your site is not proof of payment
OneClick	OneClick's payment flow	Its API, behind the same interface as your other provider	Different flow and timing from SlickPay — test both end to end
Direct SATIM	CIB card	An e-payment contract with your bank, then SATIM's technical onboarding	Bank paperwork and a longer setup
Cash on delivery	Cash to the courier	Your courier's API, plus reconciliation of what it collects and pays out	Delivered is not the same as paid — track payouts separately

I've shipped SlickPay and OneClick to production on Odigix. I haven't shipped a direct SATIM integration.

What a correct integration looks like

Connecting a pay button is the easy part. These are the rules that keep money from going missing:

1. Never mark an order paid because the customer came back. Customers close tabs and redirects can be forged. Confirm the payment with the provider — a signed notification, a status check against its API, or both — before the order moves.
2. Make payment handling idempotent. Notifications get retried and customers double-click. Key every payment by provider and reference, and treat one you've already recorded as a no-op.
3. Record the payment before touching the order. Write every incoming payment to a ledger table first, then update the order in the same transaction. If something fails halfway, the ledger still says what came in.
4. Don't guess. A payment that can't be matched to exactly one order goes to a human. Fixed prices make identical amounts common.
5. Don't wait forever. Some confirmations take minutes, some never arrive. Check the status with the provider before a pending order expires.
6. Make everything after payment idempotent too. If fulfilment calls a third-party supplier, a retried job must not buy twice — give each purchase its own idempotency key.
7. Test every method with small real payments before launch. A card type you didn't test is a card type that doesn't work.
8. Show the customer the status. A page that shows "payment received → processing → done" prevents most "I paid, where's my order?" messages. On Odigix it cut support tickets by about 40%.

The shape of it in 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 is your own interface; SlickPay and OneClick each get one small class that implements it. Read field names and signature rules from each provider's current documentation.

Frequently asked questions

Can I use Stripe or PayPal for Algerian customers? Not for local cards. CIB and Edahabia are domestic cards, and Stripe and PayPal don't process them.

Do I need a company to accept card payments? Each provider has its own onboarding requirements for your legal status and documents. Ask before you build, not after.

Should I still offer cash on delivery? In most consumer stores that ship physical goods, yes — many customers won't order without it. Offer card payment alongside it, and track cash-on-delivery orders separately until the courier pays out.

What if I already have a website? Payments can usually be added to an existing site without rebuilding it. The work is mostly on the order side: statuses, the ledger and reconciliation.

---

I build and fix payment integrations for Algerian stores and for foreign companies selling in Algeria — see online payment integration in Algeria, or the Odigix case study for how this works at 30,000+ registered users.