Accepting online payments in Algeria: the two paths, and who each one suits

Two card schemes carry online payment in Algeria: the interbank CIB card issued by banks, and the Edahabia card issued by Algérie Poste. You can accept them either by arranging acceptance with a bank on the interbank network, or by integrating a payment gateway that processes the same cards. Which path suits you depends less on technology than on who holds the money, and who answers the phone when a payment is stuck. Neither path is worth the work if your entire catalogue sells cash on delivery in small baskets — that is the case where the honest answer is "not yet".

Which cards are we actually talking about?

Two issuers, one customer habit: people pay with the card they already carry. The CIB card comes from the banking network; the Edahabia card comes from Algérie Poste, which documents its card and account services on the Algérie Poste site. A shop that accepts only one of the two refuses a share of its own customers — so that is the first decision, and it is a business one.

Path one: an arrangement with your bank

You become a merchant of the bank, and the bank is the party that processes the card. Onboarding runs through your existing relationship: an account, a file, a contract, an approval — and the timeline belongs to the bank, not to you.

What changes in daily operation: settlement arrives from the bank into the account it already knows, refunds go back through the bank's process rather than an API call you control, and support is a person you can visit. For a shop with no technical team, that last point is worth more than it sounds: when a customer's payment is deducted and the order did not confirm, a branch is a real answer.

Path two: a gateway that integrates the same cards

You integrate once, and the gateway handles the card side. The onboarding is the gateway's, the API is documented, and the money reaches you through the gateway's settlement rather than directly from a bank.

This path suits a shop that already ships software: the integration is code, the states are events, and reconciliation can be automated because a statement exists in machine-readable form. A gateway such as the one documented at Chargily's developer documentation publishes its integration surface, which is the thing to read before you commit — not the marketing page.

The trade is real: you gain an API, and you lose the branch counter. Support splits between the gateway, which handles the integration, and the institution behind the card rail, which handles the money.

What actually differs between them?

What changes	Bank arrangement	Gateway
Onboarding	Through your bank	Through the provider
Integration	Minimal, often none	API and webhooks
Money arrives from	The bank	The gateway
Refunds	Bank process	API call
First support line	Your branch	Provider's support

For most shops, the deciding row is the refund.

What do you have to build either way?

Card acceptance is an integration into your order system, and the order system is yours regardless of path.

Order states. At minimum: created, awaiting payment, paid, failed, refunded, abandoned. Ambiguity here produces the double charge and the order that ships without payment. A payment attempt must be its own record, attached to the order, because a customer can try three times.

A callback you can trust. Never mark an order paid because the browser came back to a success page: the customer can close the tab, the network can drop the redirect, the page can be visited twice. The confirmation must arrive server to server from the provider, be verified, be idempotent — the same event delivered twice must not create two payments — and be stored raw before you act on it. Compare the amount against the order you created; a mismatch is a fraud signal, not a rounding error.

A reconciliation file. Once a day, match the provider's statement to your orders by reference. Unmatched lines are where money goes missing quietly: a payment captured for an order that failed to save, a refund issued twice, a settlement short by one transaction.

Why does card payment not remove cash on delivery?

Because the two solve different problems. A card removes the cash-handling risk from your side; cash on delivery removes the customer's risk of paying for something they have not seen. Where buyers inspect the parcel before paying, removing that option costs orders rather than saving fees.

So the outcome of adding cards is a mix: cards for repeat customers and known addresses, cash for first orders, remote wilayas and categories where refusal is common. The delivery operation carries both, which means the order record has to be the same for both.

What about fees, limits and settlement timing?

They change, and they are set by the bank or the gateway, not by an article. No figure here would survive a year, and a quoted one would be wrong by the time you negotiate.

So ask, in writing, before signing: what onboarding requires, when settlement lands, how a refund is initiated and how long it takes, what happens when a customer disputes a charge, who is liable when a payment is captured but the order is not confirmed. Then confirm the answers with the institution itself. Terms change; a page cannot be your contract.

In what order do you do this?

1. Decide the mix first: what share of orders you expect through cards. Without that, neither path can be judged.
2. Ask a bank and a gateway the same questions, in writing, and compare answers rather than brochures.
3. Build the order states and the payment-attempt record before integrating anything.
4. Integrate the callback with verification and idempotency, then test it against duplicate and out-of-order events.
5. Run one month with manual reconciliation. You are learning which lines fail.
6. Automate the statement match, and keep a human who can explain every unmatched line.
7. Only then consider turning cash off for specific categories, and only if the numbers support it.

Where this goes wrong

• The success page is treated as proof. An order ships on a redirect, and the payment never completed.
• The callback is not idempotent. A retried webhook marks the same order paid twice and fires the confirmation email twice.
• Refunds live in a spreadsheet. The customer's card is credited, your order still says paid, and the month's revenue is overstated by the difference.
• Cards are launched with no plan for the cash majority. The catalogue becomes card-only at checkout, and orders drop for a reason nobody attributes to the change.

What this does not cover

It does not tell you which bank or which gateway to choose, and it names no price because prices are negotiated and change. It does not cover accepting payment from outside Algeria, or how card settlements are accounted for. And it says nothing about mobile wallets, which are a different rail.

We build the payment side of this: order states that hold, a verified callback, and a reconciliation that can explain every line.