Algeria AgencyOnline payment
Online payment once it is live: reconciliation, refunds, disputes
Getting accredited takes a few weeks. Running the payments every day is the work nobody describes to you before the contract is signed.
There are two online payment projects and only the first one usually gets sold. The first runs from the paperwork to the first successful transaction: the file, the accreditation, the payment page, the test. It has an end, a date, and a screenshot to prove it. The second one starts the following morning and never stops.
That second project is what costs time every week, and it is almost always discovered afterwards. A payment that fails and nobody knows why. A dashboard total that does not match the bank statement. A buyer who asks for a refund, then calls their bank because the refund has not arrived. An order delivered whose money was never settled.
This article describes that work, in the order it turns up. It is written for the Algerian merchant who already accepts cards, or is about to and would like to know what they are really buying. The companion article covers the connection itself and the size of the market; none of that is repeated here.
It carries no chart, and that is not an oversight: the second section explains why the numbers you would want here exist nowhere in a citable form, and what we refuse to put in their place.
Connected is not the same as in service
On the day the first transaction goes through, it is tempting to call the job finished. Technically it is. Commercially nothing has been proven yet: a successful test uses a card you control, an amount you chose, a browser you know, and the connection in your own office.
The first real transaction differs on all four at once. The card belongs to somebody else and may have a ceiling. The amount is whatever the basket came to, not a token dinar. The browser is one embedded inside a messaging app. And the connection is mobile, somewhere it drops.
So the period that matters is not the handover but the first thirty days of operation. That is when the cases show up: the interrupted payment, the apparent double charge, the refund request, the late settlement. Each has an answer, and none of the answers is technical.
The useful rule is easy to state and rarely followed: until you have reconciled a first bank statement by hand, line by line, you do not yet know whether your setup works. You only know it has not failed loudly.
Why this page quotes no figure
A reader arriving here wants rates. What share of payments fail? How many refunds per hundred orders? How many disputes? What settlement delay, really? Those are the right questions, and we are not entitled to answer them with a number.
The figures exist. They are measured continuously and precisely by every payment provider, because they run its own operation. None of them publishes those figures and nothing obliges any of them to. That is different from a number quoted job by job, and different again from a study commissioned by a vendor: this is a number that exists, is reliable, and is kept.
We could publish ours. We see these rates across the installations we look after and they are real. They cover a few dozen shops, nearly all of one kind, over short periods — a population far too small and too alike for a reader in another trade to draw anything from. A percentage shown without that caveat would be believed; shown with it, it would be useless.
The usual substitute is worse. Taking a European or American failure rate and dropping it onto an Algerian page produces an exact number and a false conclusion, because the card base, the mobile network quality and the buying habits are all different. Where a dated local figure exists, our articles cite it; here none does, and saying so is more useful than replacing it.
The three families of failure, and which one is yours
A payment that does not go through is not one event but three different ones that look alike on the buyer screen. Telling them apart is the first skill to acquire, because each is repaired somewhere different and two of them are not yours to repair.
The first is an issuer refusal: the buyer bank says no. Ceiling reached, card expired, funds short, an operation judged unusual. You can do nothing about it and you will not learn which reason it was — the returned motive is deliberately vague, so as not to inform a fraudster. The buyer, though, can find out by calling their bank.
The second is abandonment along the way: the payment page opened and the buyer never came back. Connection lost, session expired, confirmation code never received, or simply a change of mind in front of one more form. That one is squarely yours, because it comes down with a better path and a follow-up message.
The third is an outage: the gateway does not answer, or answers too late. It is the rarest and the most visible, because it hits everyone at once. It cannot be repaired from your side but it can be established — and a merchant who cannot tell an outage from a bad day spends the week altering a site that had nothing wrong with it.
Reconciliation: three totals that never agree
You have three sources of truth and they will never say the same thing on the same day. Your shop knows the orders. The provider dashboard knows the authorised transactions. The bank statement knows the settlements received. Reconciling means explaining the gaps, not making them go away.
The normal gaps are few and worth knowing by heart. An order with no transaction: the buyer abandoned. A transaction with no settlement: the settlement has not arrived yet. A settlement smaller than the transactions total: the commission was taken, or yesterday refund was deducted. A grouped settlement: several days paid out on one line.
The abnormal gaps are whatever remains once those are removed, and they alone deserve a phone call. An authorised transaction with no matching order in the shop is the serious case: somebody paid and you do not know about it. They will not always come forward to tell you.
Do it once a week, on paper or in a spreadsheet, for the first two months. Only then automate what you have understood. Automatic reconciliation installed before you have seen the gaps by hand produces a green file nobody reads, and it hides exactly the case above.
The settlement delay decides your cash position
Money from a card sale is not in your account on the day of the sale. Between authorisation — the moment the buyer sees payment accepted — and settlement, when the sum becomes available to you, there is a delay. That delay is contractual, it varies by provider, and it is the one line in the contract that changes how you run the business day to day.
The consequence is mechanical and often discovered too late: you ship on the strength of the authorisation and are paid afterwards. If you buy stock for cash and sell by card, you are financing that gap yourself. On a small basket with fast turnover it does not show. On high baskets early in a business, it becomes the tightest item of the month.
Two questions settle it before signing: after how many working days does the settlement land, and is it daily, weekly or monthly? A monthly settlement with a short delay is still a monthly settlement. The rhythm matters as much as the delay, and the two are not always written in the same place.
Then check what is actually observed, on your own statements, over the first six weeks. A contractual delay is a ceiling rather than a promise of regularity, and a cash plan built on the average breaks on the slowest week rather than on the average.
Refunding: the act, the delay, and what it does not give back
A refund is not the reverse of a payment. It is a separate operation, starting on your side, following its own route to the buyer bank, and taking longer than the payment took. Somebody who paid in three seconds often waits several days to be refunded, and experiences that wait as bad faith.
The commission taken on the sale does not necessarily come back with the refund. Depending on the contract, a full refund can leave you paying the fees on a sale that did not happen. That is not abnormal, but it has to be known before building a generous returns policy: every return has a fixed cost on top of the goods.
The rule that avoids nearly every problem fits in one sentence: state the delay at the moment you accept the refund, and state it longer than you expect. Seven working days delivered in three is a pleasant surprise. Immediately delivered in five is a dispute in preparation, and the dispute costs more than the refund did.
Always refund to the original payment method, never in cash and never by an obliging bank transfer, even when the buyer asks. Refunding to the card leaves a trace symmetrical with the original operation, and that symmetry is what makes reconciliation possible and what protects you if the matter is contested later.
Disputes: when the buyer goes to their bank instead of to you
A dispute is what happens when somebody asks their bank to reverse a payment instead of asking you. The procedure is not yours: it runs between two banks, under rules and deadlines you are subject to, and in it you supply evidence rather than being a party.
The usual grounds are three: the goods never arrived, they were not as described, or the cardholder says they do not recognise the operation. The third is the most unpleasant because it is sometimes sincere — a card used by a relative, a statement label that looks nothing like your shop name — and sometimes not.
The label appearing on the buyer statement is, for that reason, a commercial setting rather than an administrative detail. If it carries your registered company name instead of the sign your buyers know, a share of your disputes will simply be people who do not recognise you. It is the most profitable setting on this whole page and it is done once.
The rest is a matter of evidence, and evidence is assembled before the dispute or not at all. A timestamped order confirmation, proof of handover to the carrier, a delivery receipt, the history of your exchanges with the buyer. Gathered afterwards, they nearly always arrive past the deadline.
The invoice, and what the administration expects of a distance sale
A sale collected by card is a sale, with the same documentary obligations as a sale over the counter. Online payment creates no special regime; it only creates a distance between collecting the money and issuing the document, and that distance is what produces the omissions.
The trap is the order of operations. Over the counter the document is made at the moment of collection because the buyer is standing there. Online, collection is automatic and the document is not, unless somebody made it so. A month of trading can go by before the gap is noticed, and it is then made good across dozens of orders at once.
So treat the document as a step in processing the order rather than as an end of month task: it is produced when the order is confirmed, it carries the same order number, and it is filed with the matching proof of payment. The reconciliation in section three then becomes a reading rather than an investigation.
On the exact tax treatment of any particular operation — territoriality, the applicable rate, sales to buyers outside the country — the answer does not come from us. It comes from your accountant and it depends on your trade. We build the circuit that produces and files the documents; we do not classify the operation on their behalf, and be wary of a technical supplier who does.
Answering a failed payment without losing the order
A payment that fails is not a lost sale while the buyer can still be reached. In most cases they did what was needed, something was interrupted, and they are waiting to learn whether they should try again. Silence, at that precise moment, is what turns an incident into a loss.
The useful message says three things and no more: that the order is recorded, that it is unpaid, and how to pay it now. It does not apologise at length, it does not explain the cause, and above all it never tells the buyer to check with their bank as the only answer — that is true, useless, and read as a refusal to help.
Always offer a second route. A payment link sent again, and cash on delivery where your trade allows it. Somebody who has failed twice on the card will not try a third time; they will buy elsewhere, or accept paying another way if it is offered within the hour.
The window is short. A recovered basket is recovered the same day, and usually in the first few hours; by the day after, the message reaches somebody who has already bought elsewhere or no longer wants it. This is the only part of this page where the speed of the answer is worth more than its quality.
What to log, and for how long
Every case above is settled with traces, and traces cannot be reconstructed. Whatever was not recorded at the time is gone, and it is gone precisely on the day somebody asks for it. Deciding what to keep is therefore a decision to take now, not at the first dispute.
The useful minimum is short: for each order, the transaction identifier at the provider, the timestamp, the amount, the final status, and the link to the order on your side. That fits in a column added to the orders table and it answers ninety per cent of questions without opening the provider dashboard.
There is one thing never to keep, and it is the most tempting: nothing resembling a card number, an expiry date or a verification code has any reason to exist in your system, not partially, not in a technical log, not while debugging. A correct architecture means those values never reach you at all; keeping them recreates a risk your provider exists to carry on your behalf.
For duration, align on the longest of the three constraints that apply to you: the window for contesting a payment, your own returns policy, and your accounting obligations. The last is almost always the longest, which simplifies the decision.
Questions to put to the provider before signing
Nearly everything above is decided by a contract signed before the first buyer arrives. The questions below are not technical ones: they are the ones whose answers change your daily work, and they go to the sales contact, in writing, before signature.
On money: what is the settlement delay in working days, at what frequency, and is the commission returned on a full refund? On incidents: what label will appear on the buyer statement, and can I choose it? On disputes: within what deadline must I supply my evidence, and through which channel?
Two more, which are never in the brochure. What happens if I change platform in two years — is the transaction history exportable, and in what form? And who answers when something breaks on a Thursday evening: a generic address, or a named contact with a stated response time?
Keep the answers in writing, in the same folder as the contract. That is not suspicion, it is the same logic as the previous section: the person who answered you may not be there in two years, and an answer you remember is worth nothing against an answer you can show.
What we do, and what we will not promise
Our share is the circuit: the payment page and its path, the link between shop and provider, the follow-up on unpaid baskets, automatic production of the documents, and the reconciliation sheet you will read every week. We install it, we document it, and we show you how to read it — because a reconciliation sheet only the supplier can read is worth nothing.
We promise no rate. Not a failure rate, not a dispute rate, not a settlement delay, because none of the three depends on us: they depend on your bank, your provider, your buyers card base and the quality of their connection. A technical supplier quoting you a number on any of the three is quoting a number they do not control.
Nor do we take the decisions that are yours: the returns policy, the tax classification of your operations, the choice of provider itself. On that last one we give a reasoned opinion and we take no commission for it, which is the only thing that makes an opinion about a provider worth hearing.
Finally, part of this page is done without us, and it is the part that pays back fastest: reconciling your first statement by hand, correcting the label that shows on your buyers statements, and writing the message that goes out when a payment fails. Those three need no development at all. If you only do three things after reading this, make it those.
Frequently asked questions
How long does a card refund take in Algeria?
It depends on the provider and on the buyer bank, and the delay is always longer than the payment itself was. Good practice is never to state a delay you have not verified on your own operations: state it wide, deliver it short. A refund announced as immediate and arriving five days later produces a dispute that the refund alone would have avoided.
Why does my dashboard total not match my bank statement?
That is normal and it has four usual causes: the settlement has not arrived yet, the commission was taken, a refund was deducted, or several days were paid out on one line. Remove those four; whatever remains is a real gap and deserves a call. The serious case is an authorised transaction with no matching order, because somebody paid without you knowing.
A buyer is disputing a payment with their bank. What must I supply?
The timestamped order confirmation, proof of handover to the carrier, a delivery receipt if one exists, and the history of your exchanges with the buyer. These are assembled at the time of the order: gathered after the dispute notice, they nearly always arrive past the deadline. The response window is set by the interbank procedure and is not negotiable.
Should I keep my buyers card numbers to make refunds easier?
No, never, and a refund does not need them: it is issued from the provider interface by referencing the original transaction. A correct setup means those values never reach your system. Keeping them, even partially and even briefly in a technical log, takes back a risk your provider exists precisely to carry.
Is cash on delivery still useful once cards are working?
Yes, and removing it is a common mistake. It remains the second route you offer to somebody whose payment has just failed, and that is what separates an incident from a lost sale. The two methods do not compete in the way people imagine: they cover different moments of the same purchase.
Why does this article give no percentage?
Because failure, refund and dispute rates are published by nobody in Algeria. They are measured precisely by each payment provider and kept. Our own sample covers a few dozen shops too alike for a reader in another trade to draw a conclusion from, and transposing a foreign rate would give an exact number with a false conclusion.
Where we come in
Reconciling a bank statement against your provider’s dashboard for the same week is the fastest-paying thing here, and you need nobody to do it.
- We fix the descriptor that appears on your customers’ statements.
- We take the payment page and the path that leads to it.
- We connect the shop to the provider so the two counts agree.
Failure rate, dispute rate, settlement delay: we will announce none of them, because nothing there is decided at our end.
Read next
Your first AI invoice: the lines that were not in the calculation
The estimate said one amount and the invoice says another. The gap is almost never an error: it is six lines nobody counted.Paying an AI supplier from Algeria
The project is scoped, the team is ready, and the card is declined. That is not a fault: it is the service-import regime.Integrating CIB and Edahabia online payment
Cards are no longer the constraint: there are 21.9 million of them. What is missing is merchants who accept them.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.